On Mar 15, 2014, at 11:50 AM, Krisztián Pintér <[email protected]> wrote:
> > Arnold Reinhold (at Friday, March 14, 2014, 5:20:56 PM): >> Here are some scenarios where recovery from a state compromise would be >> important: >> o A bug in system software that exposes PRNG state only rarely >> o An attack that that exposes PRNG state in a system that is well >> guarded against covert channels, limiting undetected outbound messages to >> very low bit rate > [...] > > and these are the attacks about which djb says: your system is broken. > don't patch it, fix it. if such attacks could be carried out, session > keys or long term keys might have been compromised. recovering your > prng won't help that, the damage has been done. > > it is not the way to reduce the chance of any attack by a small > factor, let the factor be a 100, or even a million, it is still small. > what we want is systems that are reliable and safe. and if our system > is safe, we don't need reseeding. I am not aware of anyone who even claims to have a system that is "safe", as in free from any security bugs, much less one that remains safe from bugs being added as new software is developed and other bugs are fixed. And note that not all the issues I raised are software related. Tempest, for example, is a very tricky business. The NSA specs for Tempest protection are not publicly available, but I have been told they require tight physical configuration control, as even a single wire change can destroy Tempest protection. Perhaps the best that can be achieved is to keep any attacker a safe distance from critical systems. A determined attacker might be willing to absorb the effort and risk to covertly penetrate physical security barriers if doing so will lead to a permanent compromise of a one-time-seeded PRNG, less so if the benefits will last only briefly as the PRNG reseeds after they leave. We now have something we never had before, an apparently thorough rigorous analysis of the reseeding issue. Of course, time should be allowed for responses and critiques to the Dodis paper to emerge, but planning new security guidelines that ignore this work seems foolhardy. Arnold Reinhold _______________________________________________ dsfjdssdfsd mailing list [email protected] https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
