On Thu, Apr 26, 2012 at 12:22 AM, Nico Williams <n...@cryptonector.com> wrote:
> Also,
>
> On Wed, Apr 25, 2012 at 10:11 PM, Zooko Wilcox-O'Hearn <zo...@zooko.com>
> wrote:
[big snip]
>> I don't question the usefulness of the Authenticated Encryption
>> abstraction for protocols that fall into that category.
>
> Right, me either. I can't even imagine not using AE in that context,
> whether by generic composition or -much better- via integrated AE
> ciphers/cipher modes.
Maybe a better question is to ask ourselves why developers are
*not* using AE where it _is_ appropriate. From where I sit as an
application security guy (or, more accurately, a developer who
just happens to have focused on application security for the past
dozen years), I think the answer to that question is multi-faceted.
First, your average developers doesn't even grok cipher modes at all.
In fact, most of them stop reading when they see the first example
of encryption, most often implementing something using ECB mode.
It's nice, it's simple, and it's almost always wrong.
Secondly, those like myself, who may desire to wrap some more
general crypto library to make it easy to use (i.e., pick some secure
defaults and take away the need to know about things like IVs,
cipher modes, padding schemes, etc.) are often left with crypto
primitives that do not include *any* AE cipher modes at all. Some
great examples are in the standard SunJCE that comes with the
JDK (you have to use something like BouncyCastle to get things
like GCM or CCM for Java and that's often a hard political sell so
most developers won't bother). Another example is with the .NET
framework. It too has no authenticated mode. Both Java and
.NET only support ECB, CBC, CFB, OFB modes and starting
with JDK 1.6, Java also offers CTR mode. (.NET may too; I haven't
actually looked in a while.)
Now there are a lot of libraries for C and C++ that are more
developer friendly and support AE, but for the most part, the world
has moved to Java and .NET, at least for web applications.
So that leaves the authenticated encryption via generic composition
of something like an HMAC and a derived key. With the help of a
few of you real cryptographers on this list, I managed to implement
that for OWASP ESAPI 2.0, but it was anything but simple. In
fact, had it not been for other experts looking at the code and not
finding anything blatantly wrong with it (at least that they were willing
to tell us about; one of those parties was the NSA after all ;-) I personally
would have had zero confidence in it. (Even now, I'm personally
skeptical.) Oddly enough, in hindsight, I could probably have implemented
an AE cipher mode and hooked up the plumbing to use it easier than
I did with the composition method. I was reluctant to do that because
I had someone keep telling me if I did ESAPI could never be used
with a JCE provider that was FIPS 140-2 compliant and a FIPS mode.
(Now, I think that was a red herring; at the time, I did not realize it.)
Plus I keep telling developers not to roll-their-own crypto implementations
so I felt implementing a cipher mode to use with ESAPI would be
hypocritical at best. There were other forces too. Could have just made
BouncyCastle a mandatory dependency and then had ESAPI use
it as a JCE provider with GCM or CCM, but given that it already had
30 jars as dependencies, I didn't want to pull in yet another one. Also,
in some companies, using another crypto provider is like pulling teeth;
for better or worse, the default one in the reference implementation is
usually trusted...at least in the case of Java and .NET.
But my main point here is two things...
#1) We have to change the way textbooks or other sources (and I'm
including Wikipedia articles here) introduce crypto to developers.
The need for message authenticity needs to be discussed front
and center when discussing the confidentiality that ciphers typically
provide.
#2) The standard toolkits that we provide need to support AE cipher
modes because there is no way that a naive developer with no
experience in applied cryptography is going to get all the details
right. (Case in point: the symmetric encryption in ESAPI 1.4 was
an epic fail. [Note: The asymmetric crypto is just useless as keys
cannot be saved across JVM processes so you restart your app
server and lose you key pair. Working on that for 2.1.])
So how to we get developers to where we want them to be? I, for one,
think it's time to blow up the old model where we introduce the raw
crypto and instead talk about the risks that we are trying to address
with crypto and how we must address both confidentiality *and*
authenticity. And most of all, move all the ECB examples to the
back of the book and only discuss them in a context where it is
safe to use them.
So that's my perspective. Would like to hear yours. Sorry for
rambling.
-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents." -- Nathaniel Borenstein
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
