<div dir="ltr">"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."<br><br>You're right, but there's nothing that can be done to help someone who enters "cat" as his password, either.<br><br>"I personally don't think you can blame any of that on the user : how should he know or care that it is important ?"<br><br>Because you print text in bold letters explaining this. Not reading "STOP" signs can also cause catastrophic problems, but that's not the fault of the highway administration.<br><br>"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"<br><br>Maybe mouse movement is a better source. At least, the installer can verify how far you move, back and forth, and how quickly, and thereby conclude with confidence that your neurology is operating outside the envelope in which any human could possibly control the cursor with pixel precision, to the tune of 128 bits. And you explain this to the user, anyway. If they push a button on their mouse to fake the movement so they don't need to move their wrist, it's their own fault.<br><br>"Another issue is in a lot of cases (think cloud/virtualization) OS are setup without human interaction."<br><br>True. I would just seed the child from the parent CSPRNG, so the chain of security authority remains intact.<br><br>"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"<br><br>No one would disagree with this. But if good security practices are in place, then I would expect this reseeding interval to be on the order of days, at least. That's well within the realm of "shake the mouse for a few seconds".<br><br>Russell Leidich<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, 2015 at 2:55 PM, Alexandre Anzala-Yamajako <span dir="ltr"><<a href="mailto:anzalaya@gmail.com" target="_blank">anzalaya@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I still think it's important that TRNGs be practical in real usage contexts.<br>
> As mundane as it sounds, perhaps the safest practice is just to ask the user<br>
> to enter 50 random digits when they install the OS (or shake the mouse or<br>
> whatever). At some point (100 digits?), even an uncreative person is going<br>
> to produce enough entropy to be worth 128+ bits. From that point on, it's<br>
> all CSPRNG. That way, we don't need to worry about timedelta predictability<br>
> or how to¬† securely acquire a new USB randomness device when it gets lost<br>
> somewhere far away from the IT department.<br>
<br>
</span>I see a few problems with that. First 128 bits of entropy is a lot to<br>
ask from a human and you'll end up with a string of however many 'a'<br>
character you asked for. I personally don't think you can blame any of<br>
that on the user : how should he know or care that it is important ?<br>
Where is he supposed to find those 100+ (that seems low actually)<br>
digits. passwords have thought us that when users don't care we end up<br>
with extremely low variability<br>
Another issue is in a lot of cases (think cloud/virtualization) OS are<br>
setup without human interaction.<br>
Last thing is you can't completely rely on a well seeded CSPRNG<br>
forever : you need to be able to reseed it in case of compromise and<br>
since you won't necessarily know when the compromise happened it's<br>
good practice to reseed from time to time<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Alexandre Anzala-Yamajako<br>
</font></span></blockquote></div><br></div>