[147785] in cryptography@c2.net mail archive
Re: [Cryptography] [RNG] on RNGs, VM state, rollback, etc.
daemon@ATHENA.MIT.EDU (Kent Borg)
Mon Oct 21 17:54:45 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 21 Oct 2013 14:28:22 -0400
From: Kent Borg <kentborg@borg.org>
To: cryptography@metzdowd.com
In-Reply-To: <1382363303.6689.15.camel@heisenberg.scientia.net>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 10/21/2013 09:48 AM, Christoph Anton Mitterer wrote:
> On Sun, 2013-10-20 at 16:32 -0400, Russ Nelson wrote:
>> We *all* know that all cryptography can be cracked; it's just a matter
>> of resources and time.
> *cough* OTP...
Also, the universe is of limited size and life expectancy: the
"resources and time" bit really matters once the numbers get big.
In isolation of a larger analysis (of the threat and the definition of
the system boundaries being defended) there are still useful things to
say. Such as ROT-13 is extremely weak, DES medium weak, AES-256 likely
very much stronger, OTP completely strong.
But the system boundaries matter. I don't hold AES-256 responsible for
protecting the secrecy of the key, though that matters in a larger
system (try memorizing and accurately entering 256-bits, it ain't
easy). Similarly, I don't hold OTP responsible for key generation nor
key distribution, though those do become extremely important when
designing the larger system.
One has to look at the larger system if one wants to draw conclusions
about the security of the larger system (and so on for the system larger
than that, and the one larger than that). But components can still be
examined, at each level, weaknesses found, improvements made.
In the case of and RNG (as with much of crypto), failures can be
silent. It makes sense to build into an RNG the ability to refuse to
work absent any seed (or entropy, as the case may be). It makes sense
to make this facility have parameters that can be tuned by those using
it when carefully building a larger system. It further makes sense to
choose defaults that give those larger designers as much help as
possible, hurt as little as possible, and try to reduce the "fail
silently" property to fewer cases and lesser severity.
If the RNG also mixes in locally unique information that isn't
particularly secret (MAC addresses, time, etc.), as long as it doesn't
hurt, I conclude it doesn't hurt and it is worth doing. Even if you
don't know what the larger system is, it helps. A little like a crypto
angorithm having more rounds, it usually helps.
The refusal to look at the component without first being served your
cookies and milk is pedandic silliness. Like refusing to reduce the
failure rate of your bolts, nor examine their strength, because it is
the fault of the bridge builder for not doing the entire analysis and
using enough bolts. Yes, the bridge builder should do his/er job. But
it is still worth talking about bridges independent of any specific
structure. It is still worth studying bolts independent of specific
bridges.
Similarly, reducing the silent failure modes of RNGs, and making
residual failures less fatal, is worthwhile.
-kb
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography