[Cryptography] Mac OS 10.7.5 Random Numbers

[Jerry Leichter]

On Feb 3, 2014, at 12:30 PM, ianG wrote:
>> Any validation process you come up with is going to have the same feature: once you've gotten something validated, changing it is, in general, going to mess up your validation.  Otherwise the validation means nothing, because you could get a crypto device validated using RSA2048 and SHA256, and then change it over to using RSA512 and MD5.  
> Why can't validation say RSA2048 or longer, SHA1 or longer (SHAn) ?
> PRNG Has 160 bit state, or more, all else held constant?
"RSA2048 or longer" has a clear meaning:  The RSA algorithm is well defined, the key lengths it uses are well defined.  Sure, there are implicit assumptions (like that the modulus is actually a product of exactly two primes of close to equal size), but we can deal with that if we have to.

I have *no clue* what "SHA-1 or longer" means.  The SHA-1 algorithm is defined over 512-byte input blocks, with 160 bits of intermediate state and 160 bits of output.  You can readily decrease the  output block size (choose some subset of the bits).  It's not clear that there's a secure way to decrease the input block size - some kind of padding, but padding has proven to introduce vulnerabilities in the past.  You can do nothing meaningful about the intermediate state without changing the compression algorithm, which is specific to the state size.  How what everyone would agree is a "longer version of SHA-1" might be produced is anyone's guess.

Now, if you say "a one-way hash with all the properties of SHA-1 but with a longer intermediate state and output block size", well, that's kind of saying what you want - but not in a way that's actually useful unless you can pin down just what "all the properties of SHA-1" might mean.

In effect, you're making the validation dependent on the validation of something else (the hash function) - 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?

The sponge construction, for the first time, gives us a generic description of a family of hash functions whose strength is given by security parameters we can set pretty much as we want.  It'll take a bit of time before we have adequate confidence to say "just go ahead and change the security parameters; we understand the effects".  With luck, we might even end up with an appropriately parameterized family of stream ciphers out of the same construction as well.  There have been attempts to construct similar families of block ciphers - I vaguely recall MARS, an AES candidate, was one - but none so far has gotten broad acceptance.

*If* we have such accepted families of components, and *if* we come up with ways to approve entire families (note that some combinations of security parameters might, in principle, open an other-wise secure primitive much more vulnerable to side-channel attacks), and *if* we can come up with ways to specify appropriate combinations of security parameters for different primitives making up some reviewed component ... then we might be in a position to define "family approval" for a class of instantiations of some software module.

But we have enough trouble doing meaningful approvals for single implementations today that I don't see this happening soon.

                                                        -- Jerry