[cryptography] Enranda: 4MB/s Userspace TRNG
pkejjy at gmail.com
Fri May 29 11:50:44 EDT 2015
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
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
On Fri, May 29, 2015 at 2:55 PM, Alexandre Anzala-Yamajako <
anzalaya at gmail.com> wrote:
> > I still think it's important that TRNGs be practical in real usage
> > As mundane as it sounds, perhaps the safest practice is just to ask the
> > 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
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography