[Cryptography] Mac OS 10.7.5 Random Numbers

[John Kelsey]

[This is from awhile back because I got busy with other stuff, but it seemed like there were a couple of points worth discussing a bit more. ]

> On Feb 4, 2014, at 12:23 AM, ianG <iang at iang.org> wrote:
> 
>> On 4/02/14 00:00 AM, Jerry Leichter wrote:

...
>> - but you aren't saying what *kind* of validation is appropriate for that "something else".  Can I substitute some particular variant of Salsa, because being accepted by DJB counts as "validation"?  How about a hash algorithm developed and published for general use by the Chinese government?  Or, for that matter, the NSA?
> 
> Yes, you can do all that.  Someone simply needs to state what
> substitutions are allowed, and you can rely on it.
> 
> In detail the process would be something like this:
> 
> NIST (or whoever) publishes a table that states:
> 
>     SHA1 < SHA2 <= Salsa20/HashVariant < SHA3/1234
> 
>     SHA2 == Chinese variant X not Y

The problem is, one part of what the labs do in their validation is verify that you are really using a specific set of algorithms, and (via known answer testing) that the algorithms are probably correctly implemented.  If you have a module validated with 3DES, and now you want to use AES, someone somewhere needs to go back and verify that your module does, in fact, correctly implement AES.  

...
> Etc.  Now, you dial into the table and can 'rely' on what they say.  To
> some extent, NSA does this with Suite B.  OpenSSL could do it with their
> ciphersuites, but that would ruin everyone's fun.
> http://www.keylength.com/ does it from an academic pov.

Adding algorithms and modes and such to the list of approved algorithms is relatively painless.  It's removing them that's hard.  But just because a new algorithm is approved and you claim to do it doesn't mean anyone has verified that you're really doing what you say, or that you got the implementation right.  

This seems kind-of trivial, but I've heard that a surprising fraction of modules fail one of the algorithm tests.  And when you buy or download software that does crypto, you're usually left trusting that the documentation is telling you the truth about what crypto they're doing.  (If it's open source, you can at least check to see if they're *implementing* AES or RSA or whatever, but it's a lot of work to verify even that they're actually doing the crypto they claim they're doing.)  

...
> Speaking of Keccak, did the controversy over the change in emphasis over
> the various pre-image resistances ever get resolved?  The sort of change
> that had been mooted would have ramifications for this table idea.

Yep.  Since so many people hated the idea of reducing the capacities, we decided to go back to the original capacities in the Keccak SHA3 submission for all the fixed hash functions.  If you want the faster performance from a smaller capacity hash, you can use one of the variable output-length modes (the SHAKEs) with a 128 bit security level, but the fixed length hashes all have the capacity = twice the output length. 

...
iang

--John