[Owasp-leaders] NIST, the NSA and fun with crypto reviews
tim.morgan at owasp.org
Sun Sep 15 20:48:13 UTC 2013
> If you decide to use AES, I recommend open source crypto libraries such as
> http://www.keyczar.org/ which simplify the implementation complexities.
> (Java, Python and C++ support). They use CBC mode, but otherwise seem to
> get IV management, crypto authentication and padding correct. It's also a
> very active and well reviewed project. It's not reasonable to expect
> developers to otherwise get this right.
When we, as applied security experts, make recommendations to
developers on how to do crypto, this is what we need to be presenting.
We need to give developers a set of crypto APIs that do what they
need, and explicitly define the guarantees the encrypted payloads are
intended to provide in terms anyone can understand (e.g. "secrecy",
"prevention of modification", etc). If we ever find ourselves giving
recommendations to the typical developer on what cipher mode to use,
then we're doing it wrong.
NaCL (http://nacl.cr.yp.to/) also takes this approach, though I'm not
sure how far along the APIs are for higher level languages. I would
tend to trust it as a system that hasn't been backdoored, given DJB's
history with the govt.
> For AES alternatives, consider the "European version of AES", Camellia. (In
> addition to Serpent and Twofish).
Why don't we just use more than one? Yes, encrypting with more than
one cipher is provably as secure as the more secure one. One could
implement this efficiently by just combining AES and Camellia into a
single OFB-mode PRNG, or something along those lines.
> Conspiracy theories aside, applied crypto is brutally difficult. Even the
> best and brightest get it wrong.
Yup. Definitely why we should be taking protocol-oriented choices
away from developers. Provide one API that's good for simple
tokens/messages. One API that's efficient for streaming traffic.
Another API for efficient storage of encrypted data at rest.
What about creating an official OWASP standard for a crypto format we
trust and can provide an API for? We could just borrow from existing
projects as a starting point, but extend to the various situations
application developers most commonly need to deal with this stuff
(forgotten password tokens, config encryption, custom SSO, etc).
More information about the OWASP-Leaders