Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets

[Dan Brown <[e-mail]>]

> -----Original Message-----
> From: Dan Brown (me)
> Sent: Tuesday, March 11, 2014 3:48 PM
> 
> The ANSI/NIST standards already require seeding with entropy equal to the
> security level before generating any outputs: i.e. your setup state A (minus the
> high-cost hash functions).  Also, aren't some linux RNGs blocking, isn't that a
> similar idea.  Maybe I should read the blog.
> 

Now I've actually read Bernstein's blog entry that you previously cited. It is well-written and raises some important and interesting issues. 

One of the blog entry's arguments is an instance of something more general: measures addressing one esoteric security feature (in this case, prediction resistance measures) may undermine another esoteric security feature (in this case, resistance to malicious seed sources).  In particular, it raises the questions of appropriateness of security definitions.  I may elaborate on security definitions in a separate email (perhaps after reviewing previous emails on the archive of this list). Meanwhile, here are a few small thoughts regarding blog entry:

First, as I understand the ANSI/NIST specs, the entropy source is presumed to be within the same security boundary as the whole RBG, i.e. free from observation or influence.  Maybe that is not too realistic in complex systems.  Anyway, that is how they "solve" (or wave away) the problem of a malicious entropy (seed) source, which is a different approach than DJB's blog proposal.  The blog entry's example about (EC)DSA is illustrative: the sensitivity of the long-term key private key to the ephemeral private key requires the ephemeral to be entirely within the same security boundary as the static private key.  Deterministic (EC)DSA is one way to do this without a live entropy source in the security boundary.  Arguably the ANSI/NIST spec for ECDSA can implicitly used in such a way: and an I-D or RFC explicitly describes one such way.

Second, the main situation that (at least) I have in mind where prediction resistance (i.e. RNG state compromise recovery) may be useful is if a device with a running RNG switches hands.  This switchover could occur at manufacture, at retail, at repair, at charging kiosk, or at an software installation/removal.  A state compromise might occur prior to the this switchover.  Are any of these realistic threats, or not?  Perhaps expert developers have such perfect control of their systems that they do not need such prediction resistance, and are more worried about a continuous persistent threat co-existing on the system.  

Third, the blog entry describes an adversary with two powers: effective RNG state compromise (by knowing x and y) and entropy source control.  If this is a realistic adversary, then this seems to suggest that RNG state compromise is a also realistic threat (going back to the second point).  Is the idea here that intermediate RNG state compromise only (but no entropy source control) adversary is no more realistic that this two-power adversary?

Fourth, I think the "conventional wisdom" alluded to in the blog entry is not correctly represented.  The conventional wisdom would be merely this: if x and y are secret, then  H(x,y,z) ought to be pretty good even if z is chosen maliciously, i.e. by an adversary that does not know x and y.  I think the blog entry is pointing out, correctly that the adversary may have two parts: an embedded malware that knows x and y, and an external adversary that only observes network communications, but has no idea of x and y. Perhaps the conventional wisdom ignores this latter split adversary.