[cryptography] Explaining crypto to engineers (was: Duplicate primes in lots of RSA moduli)

Jeffrey Walton noloader at gmail.com
Sun Feb 26 01:46:30 EST 2012


On Sat, Feb 25, 2012 at 10:47 PM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
>
> [SNIP]
>
> Well, I wish it were, but I've seen several evidences of this. For example:
> 1) In ESAPI 2.0RC2 (release candidate 2), they security gurus insisted on
>   making the default crypto 256-bit AES, but in ECB mode.
> 2) At work, the Information Security team's "Encryption Technical Standards"
>   only mentions which algorithms are acceptable and what the minimim key
>   size is (128-bits) for symmetric block ciphers. It makes NO mention of
>   cipher modes, padding, choosing IVs, or anything else.
> 3) Later when my company was acquired, the new company had a standard of a
>   minimum key size of 256 bits for symmetric encryption, but said little
>   else. After much argumentation on my part, I finally convinced them that
>   128-bits was more than sufficient.
> 4) Why do snake oil crypto salesmen almost always refer to some obsessively
>   long key size, as if that is the only thing that matters? Could it be that
>   their development teams really think that that's true and their sales teams
>   also know that's what most other development teams believe and so that is
>   what gets emphasized?
Gotta love the marketing department and sales team for the AES-256
promises (bigger is better).

I know of one place in Annapolis, MD where paint ball outings happen a
few times a year. The engineers always look forward to hunting sales
guys....

>>
>> http://lists.opendnssec.org/pipermail/opendnssec-user/2012-January/001619.html
>>
>> See last paragraph about ECDSA keys. Someone might be interested in reading the
>> whole "Default ZSK sizes" thread - for example, we found that registrars shared
>> ZSKs for tens of thousands of domains (also tons of 512 bit RSA keys). The
>> registrars are slowly rolling them over ATM.
>
> Great link; thanks. Some have been urging that we should be moving from
> 1024-bit RSA keys to 2048 bit ones just because of the NIST push and all
> the commercial CAs saluting the NISt flag. This might help push against
> that trend. They apparently think that the extra key size comes for free.
I believe the use cases are different. CA signing keys are long term.
ZSK keys apparently have a much more frequent churn.

It seems prudent to me if a key lives until 2035 or 2040, then it
should be appropriately sized. Confer, Mozilla's list of CAs:
https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html.

I *believe* the list used to include a few keys with a 30 year
lifetime (valid from the early 1990s until about 2020) with a 512 or
768 modulus. It looks like Mozilla finally flushed the smaller moduli
from the list. (But again, I'm working from memory).

>> A good article explaining the Vaudenay padding oracle (mostly leaves imprint on
>> developers if they dedicate the 30-60 min to read it thoroughly), explains why
>> modes are important along the way and gives insight into "engineer's mind":
>>
>> http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html
>
> Thanks for the link. It took me a LONG time to convince the ESAPI team
> of this because I was the newb to them and I came in and said we
> need to at least need to add a MAC over the IV+ciphertext. But it
> took me a really long time to convince them because I could not remember
> Vaudenay's name (so sorry if you are out there reading this!) and neither
> could I recall the details of how it was done. I finally stumbled upon
> it while Googling for cryptographic attacks against IPSec, which I remembered
> was one of the things originally affected.
Also of interest is Wagner and Schneier's "Analysis of the SSL 3.0
protocol" from 1996 or so (www.schneier.com/paper-ssl.pdf). The Horton
Principal (Semantic Authentication) tells us to validate the IV and
Ciphertext. From the contrapositive: if there's no need to validate
the IV or ciphertext, then there is no need to send it because it has
no value. I often use the contrapositive to flush out useless junk in
a protocol.

> Unfortunately, they didn't want to use something like GCM or CCM, which
> were NIST-approved, because they were not in the standard SunJCE
> implementation and given that we already had somehting like 30 jar
> as dependencies, they didn't want to add another like Bouncy Castle's.
This happens a lot in practice on mobile devices with FIPS
requirements. You get stuck with AES/CBC and an HMAC. CMACs are not
available, and neither is ECC.

If you are being punished with a Windows Mobile or an early Apple
device, the best you can do is 2048 Diffie-Hellman. 2048 DH has a
security level of 112-bits. Its *impossible* to agree/transport an
AES-256 key (with a 256-bit security level). +1 to the marketing team
and sales guys.

> Thanks to feedback from a few of you on this mailing list (well, actually,
> it was Perry Metzger's list at metzdowd.com, but basically the same
> cast), I think we got it right...at least if we can believe the NSA.
> (Me, I'm still a bit skeptical for reasons that have to do with what
> in retrospect seems like something obvious that just turned up that
> the NSA did not mention. Can't say more until we get it patched.)
>
>> There was even better article from Matasano that showed the Vaudenay's attack
>> nicely step-by-step, included commentary about IV selection (can't find it
>> right now).
>
> If you do find it, please let me know. Usually I just point developers at
> the YouTube video by Duong and Rizzo using POET to crack ASP.NET's
> encryption and that convinces most of them.
>
>> NaCl library - should have sane enough defaults to make it hard for a
>> non-crypto-devoted developer to screw things up:
>>
>> http://nacl.cr.yp.to/
>
> I've looked at it. Unfortunately, there is only a C, C++, and Python
> implementation. We desparately need something like this for Java, C#,
> Ruby, etc.
You already have what you need :)

>> Question regarding the IVs: is there a cryptographically-secure pseudo-random
>> permutation generation function for that? I've seen notices in this thread but
>> can't remember if one was named explicitly. (Sure one could code one up from a
>> PRNG, but I wouldn't want to be the person that would guarantee its safety.)
>> Such function is generally useful in non-crypto ways, too.
>
> At work, I've seen *WAY TOO MANY* uses of crypto where the developers have
> used a fixed IV simply so they would not have to store the IV with the
> ciphertext in a DB. They claim that they need to do this because "we are
> storing millions of records". Right.
Until such time the database programmers have a CV on par with folks
like Krawczyk, Wagner, Schneier, Gutmann, Bellare, Bernstein, (and
many others on this list - no offense intended), their opinions will
be duly noted and should be thoroughly ignored (with prejudice).

>>> 6) They have a very naive concept of entropy...where/when to use it and
>>>     from where and how to obtain it.
>>
>> I admit that I don't fully understand entropy in crypto sense (though I'm fine
>> with its physical meaning). No offense to any of you, but my impression from the
>> entropy discussion is that no one can understand it fully, it's simply damn
>> complex subject to understand correctly (taking in account that we don't really
>> have a precise definition).
>
> Entropy in information theory surely is a much more difficult concept than
> it is in physics. It doesn't help that to know whether you are doing
> it correctly or not you have to have a fairly deep understanding of
> statistics which most developers don't have and don't even want to
> know about.
Random numbers are a cryptographic primitive. When in doubt, use an
EntropyKey (http://www.entropykey.co.uk/) or other hardware based
source of entropy to ensure the health of your random numbers. Then
you don't have to worry about software algorithms developing the bits
at boot time.

>> Obviously no one can tell this to a developer and expect the developer to
>> automagically do things right.
>
> Obviously, it depends a lot on experience. Sure, most developers will
> Google for something that don't know, but it's not always the reputable
> links that are highest on the hit list. So instead, you end up with
> developers sharing ignorance with each other on some developer forum.
> Part of it is that they just don't know any authorative sources and
> part of it no one thinks to try something like Google Scholar for
> their searches.
"When a project has cryptographic requirements, who is responsible for
cryptographic design and analysis of overall system security?",
http://www.codeproject.com/Surveys/1068/When-a-project-has-cryptographic-requirements-who-.aspx.

Jeff



More information about the cryptography mailing list