[cryptography] Enranda: 4MB/s Userspace TRNG

Russell Leidich 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

Russell Leidich

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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20150529/dc88114c/attachment.html>

More information about the cryptography mailing list