Prev: Steganography with drawings
Next: The National Socialist Agency Goes Green
From: Paul Rubin on 16 Feb 2010 21:54
"Kevin W. Wall" <kevin.w.wall(a)gmail.com> writes:
> The average developer doesn't know about cipher modes, IVs, padding
> schemes, etc. The goal of this development was to provide something
> that was secure that could easily be used by a developer with no
> previous knowledge of cryptography.

You should handle that by supporting just one mode, like GCM mode, that
simultaneously encrypts and authenticates; and generate the IV's and
internal keys inside the library. That should handle every reasonable
need of such a programmer. Get rid of all other options or keep them
buried in an expert-only layer that normal users will never touch. The
cost of encrypt-authenticate modes is that the ciphertext comes out a
fixed amount (e.g. 32 bytes) bytes longer than the plaintext, which can
(e.g.) eat some database space, but paying that cost avoids a ton of
possible snags and complexity. If you let a naive programmer decide
whether they need authentication, they will usually get it wrong. So
tell them they should just live with the extra bytes unless they know
what they're doing.

You should think about also having a key management layer that generates
and encapsulates keys where the applications can't mess with them, can
store them in PKCS11 tokens, etc.
From: Tom St Denis on 17 Feb 2010 07:29
On Feb 16, 9:10 pm, "Kevin W. Wall" <kevin.w.w...(a)gmail.com> wrote:
> Java has some decent API with the JCE and JSSE. The problem with them
> is that almost every novice uses them naively. For example, almost
> every
> example that I've seen that's been written in instructions on the web
> uses
> ECB cipher mode which as you are probably aware, very weak, especially
> for general use. The average developer doesn't know about cipher
> modes, IVs,
> padding schemes, etc. The goal of this development was to provide
> something
> that was secure that could easily be used by a developer with no
> previous
> knowledge of cryptography.
>
> Hope that answers your question.

Show me a library that a non-cryptographer can use to make a secure
application and I'll show you a library that only handles one protocol/
activity and nothing else [and even then].

Consider comparing your generic crypto library against something like
OpenSSL. OpenSSL does SSL well. It does nothing else well [by
comparison].

So the question you have to ask yourself, are you writing a specific
protocol library like TLS, or are you writing a cryptographic library
meant to provide the tools required for a variety of protocols?

Tom
From: Kevin W. Wall on 17 Feb 2010 23:23
On Feb 16, 9:54 pm, Paul Rubin <no.em...(a)nospam.invalid> wrote:
> "Kevin W. Wall" <kevin.w.w...(a)gmail.com> writes:
>
> > The average developer doesn't know about cipher modes, IVs, padding
> > schemes, etc. The goal of this development was to provide something
> > that was secure that could easily be used by a developer with no
> > previous knowledge of cryptography.
>
> You should handle that by supporting just one mode, like GCM mode, that
> simultaneously encrypts and authenticates; and generate the IV's and
> internal keys inside the library.  That should handle every reasonable
> need of such a programmer.  Get rid of all other options or keep them
> buried in an expert-only layer that normal users will never touch.  The
> cost of encrypt-authenticate modes is that the ciphertext comes out a
> fixed amount (e.g. 32 bytes) bytes longer than the plaintext, which can
> (e.g.) eat some database space, but paying that cost avoids a ton of
> possible snags and complexity.  If you let a naive programmer decide
> whether they need authentication, they will usually get it wrong.  So
> tell them they should just live with the extra bytes unless they know
> what they're doing.

For better or worse, it was decided that whatever we choose would have
to
work with SunJCE, the default JCE provider, and as of JDK 1.6, SunJCE
does not support GCM or any other combined cipher mode that supports
confidentiality and authenticity. There was also the desire to be able
to
use ESAPI's crypto to support legacy encryption. So what we did was
choose what we think are reasonable defaults for the configuration
(128-bit AES/CBC/PKCS5Padding with random IV and include a
separate MAC (based on HMAC-SHA1 and a derived key) and
hope that the clueless don't change these things. (Note: That's been
my experience for the past 10 years at my day job where we did
a similar thing, but I digress.)

The next planned point release of ESAPI plans to have a configuration
mechanism
that allows an operations team to lock down any configuration
parameters that
they desire which would allow the operations team to select the crypto
parameters
based on some corporate security policy.

Anyhow, David Wagner and Ian Griggs made some suggestions as how to
generate the MAC based on a derived key and how to lay out the packet
in memory, etc. I mostly wanted someone to double check the code to
make
sure that I've implemented their suggestions correctly. All told, only
about 3300 LOC.

> You should think about also having a key management layer that generates
> and encapsulates keys where the applications can't mess with them, can
> store them in PKCS11 tokens, etc.

One step at a time. That's planned for a future release. I was mostly
trying to
clean up the "mess" that was in the 1.4 release and in the first two
release
candidates of the ESAPI 2.0 release. One thought was to integrate it
with
the key management solution that Arshad Noor has implemented in
StrongKey (http://sourceforge.net/projects/strongkey/), but I really
want to
crawl through that code and understand what threat model it was
designed
around before committing to that. As usual, lots to do and not enough
volunteers
to do it. So if you'd like to help, we certainly could use the
assistance.

-kevin
From: Kevin W. Wall on 17 Feb 2010 23:37
On Feb 17, 7:29 am, Tom St Denis <t...(a)iahu.ca> wrote:
> Show me a library that a non-cryptographer can use to make a secure
> application and I'll show you a library that only handles one protocol/
> activity and nothing else [and even then].

We tried, within reason, to choose reasonable defaults and simple
interfaces.
(Unfortunately, the earlier 1.4 release made the interface a bit "too
simple"
to the point of making things insecure. That interface is now
deprecated and
will be removed as of the 2.1 release.)

I'm pretty sure that there are problems with the rest of the other
crypto related
things as well such as signing, etc., but I didn't even touch those.
That also will
be visited in a future release. If there were more people who had a
bit more applied
cryptography experience helping out, things would go a bit faster. But
everything
is done by volunteers so we can't be choosy.

> Consider comparing your generic crypto library against something like
> OpenSSL.  OpenSSL does SSL well.  It does nothing else well [by
> comparison].
>
> So the question you have to ask yourself, are you writing a specific
> protocol library like TLS, or are you writing a cryptographic library
> meant to provide the tools required for a variety of protocols?

Well for right now, let's just focus on the symmetric encryption done
in memory
using block ciphers. That's *all* we are trying to do a this point. If
SunJCE was a
bit more complete, things would have been simpler. I would have loved
to have
a cipher mode like GCM or CCM to use, but we wanted something
compatible
with SunJCE because we figured that is what most people would use.
(However, we
did make it able accommodate other JCE providers such as Bouncy
Castle.)

Also, I'd like to address the key management problems in some future
release,
but if it's only me working on that, not sure how long it will take to
integrate into
ESAPI.

Hope this answers some of your questions.

-kevin
From: Paul Rubin on 17 Feb 2010 23:55
"Kevin W. Wall" <kevin.w.wall(a)gmail.com> writes:
> For better or worse, it was decided that whatever we choose would have
> to work with SunJCE, the default JCE provider, and as of JDK 1.6,

That is fine.

> SunJCE does not support GCM or any other combined cipher mode that
> supports confidentiality and authenticity.

GCM is probably inefficient to implement in pure Java. You could code
EAX mode instead, based on the JCE primitives.

> There was also the desire to be able to use ESAPI's crypto to support
> legacy encryption.

What legacy encryption? If there are specific protocols that you want
to interoperate with, then supply some completely packaged modules that
implement those protocols. Each module should implement exactly one
protocol, with no user options of any sort if you can possibly help it.
Don't expect non-crypto programmers to implement any nontrivial crypto
protocols themselves. Do it for them, or let them use JCE directly.

> So what we did was choose what we think are reasonable defaults for
> the configuration (128-bit AES/CBC/PKCS5Padding with random IV and
> include a separate MAC (based on HMAC-SHA1 and a derived key)

That is roughly comparable to EAX mode, so you should implement EAX
according to the standard instead of concocting something hoping to be
equivalent.

> and hope that the clueless don't change these things.

http://dilbert.com/strips/comic/2010-02-11/

> The next planned point release of ESAPI plans to have a configuration
> mechanism that allows an operations team to lock down any

The operations team will be even more helpless than the application
programmers, so it's better to do everything you can to completely
eliminate any configuration mechanism of any kind. I think you can and
should should make your package do all the right things automatically
with no configuration at all. (As you may have guessed, I've supported
this type of package in the past).

> Anyhow, David Wagner and Ian Griggs made some suggestions

Oh cool, David Wagner used to post here all the time, but hasn't in a
while, and I had figured that he gave up on us.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Steganography with drawings
Next: The National Socialist Agency Goes Green