[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dropbear delayed startup

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

> 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

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: