Hello Mike, thanks for your answer. On 12.02.2013 21:05, Mike Mestnik wrote: > 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. Sorry for not being clear about that. I was refering to the cryptsetup because /usr/share/initramfs-tools/scripts/local-top/cryptroot (which is part of the cryptsetup package) performs the unlocking within the initial ramdisk. > Are you perchance taking about fully encrypted systems as in: > http://www.howtoforge.com/remotely-unlock-fully-encrypted-debian-squeeze Yes. I have stopped talking about fully encrypted systems, because some people then assume I don't have an unencrypted boot partition (which I have). > 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). 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. > 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. > 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. > 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 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. 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. Regards Lukas
Attachment:
signature.asc
Description: OpenPGP digital signature