-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lukas, cryptsetup does not encrypted filesystems, so you must be mistaken if you believe that you are "remote unlocking of encrypted filesystems" with cryptsetup. Be specific about your configuration, this is important in this case. Those looking for assistance are in no position to be determining what is and/or is not important.
Are you perchance taking about fully encrypted systems as in: http://www.howtoforge.com/remotely-unlock-fully-encrypted-debian-squeeze What issue do you have, sounds like you are just generally concerned. You should direct concerns to the authors of the software you are concerned about, no many others would care or be in any position to answer. If you followed the above instructions it's possible that during the start of dropbear there is vary little entropy required/used until you auth over ssh. If you skipped the step where of saving host keys into your initrd, then this could be your issue as dropbear's initscripts should 'block' startup while entropy is collected. Is that the behavior you are seeing? If each startup is generating ssh host keys, that's vary bad and should be avoided. AUMK urandom is not delayed if there is no entropy available. Applications should not be looking there for entropy, that would be a bug in the application. I'm unfamiliar with a method for determining the entropy of bytes read from urandom, an interesting concept. Only a dropbear developer would be able to insist that urandom is only used when appropriate. Only you can prevent the re-generation of ssh host keys. On 02/12/13 10:55, Lukas Schwaighofer wrote: > Hi, > > I started using remote unlocking of encrypted filesystems within > the initramdisk (as provided by the cryptsetup/dropbear packets) > some time ago. However I am worried because of the potentially low > entropy during the execution of the initramfs and dropbear using > /dev/urandom as a source for randomness. > > /usr/share/doc/cryptsetup/README.remote.gz from my installed > cryptsetup (2:1.4.3-4) states in the Issues section, that the ssh > daemon (dropbear) "might be delayed until enough entropy has been > retrieved". I couldn't find any other references of dropbear > delaying startup due to low entropy. In the dropbear code I could > only find graceful handling of a blocking random source but no > builtin delay mechanism. > > Can anyone confirm that dropbear does delay startup if the kernel > is low on entropy? > > Thanks Lukas > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGqB8AAoJEOPRqa2O3KuK4JsP/jmboZHlnlIO4qEMvXpHVwSA 0EMWj59MSjDdMsDjOfylQoGs4f1IybxYPt/OhFM+ZWnAutchacpz7AM2nodvi7G/ TbqzHb3+YX6Ee3M4iVql7SAUBNTd4bv0xkG7tCoiZm5uaPC2UMtxajGy9q66vB49 TNp6R1MFCfU2l8ymSFMI5/IpBtkN4e+swy66rxuKl0POTw0Gh84YfElReRyJt+mM jC7zYmUJY4rmp5wSYUpTNaUfMNRnFXfWSpji4odDB48MQRumsbvOdAgl/xcGYB5Q GdPLJBY0VpzU2RBQfrl8ugyFYy935uUlmhlOn9hIkf1+hj33yzQ1o9z5Vbn6U32m YYxi2wJ3CRiPuhSi786xJZ3Z6ZQAwlt6y1G9YdbZyEwry0zT/lzkX1rkzgZfbXjC WlxBG4b+Bez3d6sbU/F4LEps5wrthy+EZazlICDFKTRYjzEWPRWPwxr4mJlgW4V2 Njb1Srjhv5h7YVDshRn/Uu4OqSO4uepV6GvrPGjhrhMSlzB3+FwRx3F2KIb1gaWW un7HmFm/WXOweeJoheTzntfqxsxD2OSHglICgR+Nr0xl9rm/GZW2zIVpD4NyoNVR tmNcoREvDiY+FwWOE4wf5rFZGGUrModFcUTv34CtSFcKd0bHogAvW/ED3Idip3l2 aD4WHj8/F0BEqo6I8qHL =xWXO -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511aa082.6030...@mikemestnik.net
