-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/13 15:11, Lukas Schwaighofer wrote: > Hello Mike, > > thanks for your answer. > > On 12.02.2013 21:05, Mike Mestnik wrote: >> 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. > Yes, I'm generally concerned on the impact of little entropy for > the dropbear ssh server (if a Diffie–Hellman key exchange is > performed and the secret of the low-entropy server can be guessed, > the session key is compromised). > As indicated, this happens after the connection and thus there "can" be plenty of entropy even in the daemon is started when there is not. You can even create or push entropy by pinging the host at irregular intervals or a verity of other activities. You can have the initrd hit random.org a few times.
A really good solution can be employed if you have an HA setup, once past the point of loading the stored entropy, urandom can be securely served out to the other node over a local network or serial connection. > The manpage of random in section 4 (man 4 random) has some > recommendations about the using /dev/urandom. It states that using > /dev/urandom for network encryption keys is fine after the seed > file (which is saved across reboots and handled by > /etc/init.d/urandom in debian) has been reloaded. This is not yet > the case during execution of the initial ramdisk. > > I wrote a set of scripts that perform the reloading of a seed > already in the initramdisk and before dropbear starts which solves > my concerns. I posted to this list because I'm not sure if it's > really an issue or if I'm just being overcautious. In case you > agree this should be mitigated I'll happily share my work. > > Since my concern is specific to the integration into the > initramdisk (which is not part of the upstream packages of either > cryptsetup and dropbear afaik) I think this is the right place to > ask. > I'm not sure that having static entropy in an initrd would be good either. You wouldn't gain entropy, only randomness. I'd be concerned about using the same initrd image for more then 100 times or so. You could regenerate the initrd though, but this starts to fall into the category of custom solutions. >> 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. > My host-keys are pre-generated and built into the initramdisk (this > is taken care automatically by the dropbear package, at least in > wheezy). The dropbear ssh server in the initramdisk is usable > without any (noticable) delay, even without reapplying the seed > first. > Unless you point out you are running testing, you may only get suggestions for stable. >> 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. > /dev/urandom is non-blocking while /dev/random is blocking. The > amount of entropy currently available can be accessed using the > proc-interface: # cat /proc/sys/kernel/random/entropy_avail > However, I'm pretty sure dropbear does no such thing and as far as > I can tell does not wait for entropy. > entropy_avail has to do with the number of bytes one can read from random. Values read from urandom are based off a 1k seed, knowing how much this seed has ever been populated is not exported nor is the number of times the current seed has been given out to users. An attacker with local access could conceivably read the contents of the seed as long as one could do so without triggering an event that would cause the kernel to build more entropy. >> 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. > dropbear is especially targetted for embedded devices. I assume > that gathering enough randomness from /dev/random is especially > hard for those devices. The dropbear changelog > (https://matt.ucc.asn.au/dropbear/CHANGES) contains an entry > regarding the switch from /dev/random to /dev/urandom at version > 0.50: - Use /dev/urandom by default, since that's what everyone > does anyway > This is where the need for the kernel to export information on the viability of urandom would come into play. For example dropbear could kick out new connections if there was not yet enough seed data, after a few attempts there would be. > Sorry if my first E-Mail sounded like I want support for my setup > (that's not the case). I wanted to get second opinions if little > entropy and a running dropbear in the initramdisk is a problem. > I hope my pointers are helpful to you in the future. > The matter seems important, because when using an encrypted root > partition in wheezy, an installed dropbear package will > automatically case dropbear to be started during the execution of > the initramdisk. > Starting is not the same as handling connections. I don't believe when dropbear is started has any bearing outside of automatically generated hostkeys, which sounds like that's not applicable here. Since startup the system is constantly collecting entropy, network traffic sounds like the biggest source of entropy for your configuration. If this host is on a segment with a handful of windows machines then waiting a minute or two should generate more then enough entropy. > Regards Lukas > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGscGAAoJEOPRqa2O3KuKwicQAMfZfS9Wg2K4vW+XB9mV7ClN FoQ5udI/Nd+jros4+eTXU5KwusAd6mZ4dpnuDh+okaypkIhWVDDVDB3Ne010+wgX +U+tMxyqUn9m9FgPesxGinNLRK/AQQ+jWLTEgLzVhGLwHfX1bTEUV4uAgWJcjAUb 9OL26PQKIPfmTe8j4LsnKlDySlILwkRdhLqgW0MdE+gU+Cb0jhbEgqWdpxVWy51L vu/yhupJ/g9PG5MLgHb3HaLluAUChvw9psxLFwEXze20X4SG1R0vTLDE2uY+Uh8c QDx86DM0uWGVVQkcpK3AfFLMfLM0C/gD6gIQUVqYxFwnBpGUzAfzyL7YRSk5MLsS GDA/hZbjKyHIpTPXu9lW5IvIzhxJ37i/0+M+AR3V4MpJDWP1N/GftWRSuiwaHXV6 UgUpAVvyINe21Ovz1R/ZNYpJVtIlq7VTqUZc5p8eS2SvgFWA4PkBjiX0Cj1Pbw08 jcHr6oHPZLEb+JP+m3xnaPVguOmnj0r8iU8RWxkEXmKptapeYoAwExkzfu9tLn0t bNIZy6gLzm19x+xdnE8rrHtElJcfAjll6q/CXxGx+IViyE4wGA53gPjWPkJDw4Nm 9MTufcjSac+GrUj7uWeXDpWUr9NbN4/KG7/XlC8b7k33azA24tX0pOG0IP1PAGLX w7e+htWzpNeLaY1AIeEB =0Gkx -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
