On second thought, there is this particular case, wherein you would need internally generated entropy:
1. You have a cloud server which has been compromised. 2. You issue a remote reboot, with the firmware instructed to boot from the network. 3. In order to obtain the new OS image, the cloud server needs to do a key exchange with a machine controlled by a human sysadmin. 4. However, to guard against replay attacks of a previous key exchange (which could be used to reinstall the vulnerable OS), the child must create a nonce. It cannot do this, absent local entropy. So in this particular scenario, unless the sysadmin can somehow walk over to the cloud server, I think you are correct: local physical entropy is required. Russell Leidich On Fri, May 29, 2015 at 2:55 PM, Alexandre Anzala-Yamajako < [email protected]> wrote: > > I still think it's important that TRNGs be practical in real usage > contexts. > > As mundane as it sounds, perhaps the safest practice is just to ask the > user > > to enter 50 random digits when they install the OS (or shake the mouse or > > whatever). At some point (100 digits?), even an uncreative person is > going > > to produce enough entropy to be worth 128+ bits. From that point on, it's > > all CSPRNG. That way, we don't need to worry about timedelta > predictability > > or how to securely acquire a new USB randomness device when it gets lost > > somewhere far away from the IT department. > > I see a few problems with that. First 128 bits of entropy is a lot to > ask from a human and you'll end up with a string of however many 'a' > character you asked for. I personally don't think you can blame any of > that on the user : how should he know or care that it is important ? > Where is he supposed to find those 100+ (that seems low actually) > digits. passwords have thought us that when users don't care we end up > with extremely low variability > Another issue is in a lot of cases (think cloud/virtualization) OS are > setup without human interaction. > Last thing is you can't completely rely on a well seeded CSPRNG > forever : you need to be able to reseed it in case of compromise and > since you won't necessarily know when the compromise happened it's > good practice to reseed from time to time > > -- > Alexandre Anzala-Yamajako >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
