[147838] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (Stephan Mueller)
Thu Oct 24 15:34:13 2013
X-Original-To: cryptography@metzdowd.com
From: Stephan Mueller <smueller@chronox.de>
To: cryptography@metzdowd.com, Alon Ziv <alon-lk@nolaviz.org>
Date: Thu, 24 Oct 2013 17:06:58 +0200
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
Am Donnerstag, 24. Oktober 2013, 05:06:16 schrieb Alon Ziv:
Hi Alon, Ted,
>Theodore Ts'o <tytso <at> mit.edu> writes:
>> On Thu, Oct 17, 2013 at 01:05:52PM -0400, Kent Borg wrote:
>> > There are certainly larger system issues, and anyone doing
>> > auto-provisioning of servers and generating keys before any entropy
>> > has accumulated could get burned. Though to be fair to
>> > /dev/random,
>> > isn't this a larger Linux distribution issue? Don't automatically
>> > generate keys on first boot. RNGs that need seed data should not
>> > be
>> > run empty.
>>
>> The major problem which could be considered a "Linux distribution
>> issue" is ssh host key generation, which is done by the boot scripts
>> if the ssh host keys do not exist. It would be much better if this
>> was done on the first TCP connection to the ssh server, but that
>> would
>> require changes to sshd.
>
>Can't this be solved (in some distros at least...) by switching SSHD to
>use on-demand activation (a la inetd / systemd)? [I know the SSHD
>manpage claims this is inadvisable, but I suspect the reason -
>response "may take tens of seconds" - is decades out of date even for
>small devices...]
This issue is larger than SSHD, it covers dm_crypt too. Especially
dm_crypt is vulnerable to this problem in case it is configured for full
disk encryption. In this case, the installer generates the volume key as
one of the first things during the initial installation. As this volume
key cannot be changed for the lifetime of the system, it is highly
important to have that generated properly (read: with good entropy).
Of course, you can say: well, installers have a graphical UI and
therefore there is lots of mouse movements, etc. for /dev/random. But
this is not always the case. Almost all distros allow an automated
installation (anaconda allows that, the Debian/Ubuntu installer allows
that, YaST too, ...), you can define automated installations with full
disk encryption which only interrupt at the time when you have to
provide the passphrase to protect the key. At that time, the key is
already generated by libcryptsetup. But there was no real user
interaction, no hard disk interaction and only limited interrupts to add
entropy to /dev/random.
Using console-based installers is a bit better, but the user only needs
to hit some keys before the volume key is to be created.
Now, you can say that is the responsibility of the Distros to catch that
(e.g. require the user to hit a number of keys before generating the
key), but I guess that approach is fragile.
I guess you can find many more examples of the issue where we need
entropy at the time the current /dev/random code cannot provide that. I
guess the only solution is to open up new entropy sources for that.
Ciao
Stephan
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography