Re: Web Security Is Hard

[Nate Lawson <nate () root org>]

Jamie Riden wrote:
> OK, might as well run this by everyone.
>
> IV ++ AES/CBC/PKCS7 padding - encrypted block ++ SHA1-HMAC of secret data
>
> if the HMAC doesn't come out same as computed for decrypt we just
> abort. What's wrong with the above? (assuming we get our PRNG suitably
> random.)

The devil is in the details that you left out. Where is the sequence
number to distinguish transactions? How are the contents of the message
interpreted and in what order? Is this a network server, disk drive
controller, or Pay TV smart card?

To rephrase for this list:

    snprintf(buf, sizeof(buf), fmt, data);

What's wrong with the above?

> ( SUN's example Java code uses DES in ECB mode - go figure. You do
> have to type A-E-S in if you're using Java.  )

Not if you're using a higher-level library. A higher-level library that
chose DES-ECB as the default cipher would indeed be broken.

However, once this bug was found, you could get a patch to the library
that fixed this default, re-gen keys, and you'd be secure. No changes
required for your code, assuming shared libs. Compare this to grepping
through all your binaries to be sure you've substituted CONSTANT_AES for
CONSTANT_DES everywhere.

Crypto is difficult and expensive to get right. Conversely, there are
good high-level libraries available. Sure there are a few cases where
you have to do custom development, incurring that cost. But making "roll
your own" the default development practice is like coding your own
webserver in assembly. You can eventually get it right, but you're
making your job much harder than it has to be and risking a lot for your
company for no real gain.

-- 
Nate
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave