Syscall based entropy

[Guilhem Moulin]

Hi there,

N. Heninger, Z. Durumeric, E. Wustrow and A. Halderman have shown [0]
that a low entropy pool (for instance early in the boot process) during
key generation can lead to predictable keys.  (Worse, for DSA this can
lead to the exposure of the private host key material, but dropbear now
mitigates against this in dss.c:buf_put_dss_sign.)

Even when strong host keys have been generated using a properly seeded
entropy pool, I guess the early boot issue can bite again and yield
predictable ephemeral keys used in the Diffie-Hellman key exchange. 
(This looks especially bad when the server is installed in the initramfs
image to unlock the encrypted root partition for instance, as the server
is started very early in the initramfs stage.)

The problem arise because reading from /dev/urandom doesn't block when
the entropy pool hasn't been properly initialized.  As a workaround,
dbrandom.c:seedrandom implements its own logic to try to properly seed
the pool.  I wonder if you have considered to use getrandom(2) [1] on
Linux ≥3.17?  AFAICT it has the semantics one would naively expect from
reading from /dev/urandom.  I could provide with a patch if there is
interest.  (OpenBSD has its own getentropy() syscall, but I don't have
access to an OpenBSD box though.)

Cheers,
-- 
Guilhem.

[0] https://factorable.net/paper.html
[1] http://man7.org/linux/man-pages/man2/getrandom.2.html
    https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6e9d6f38894798696f23c8084ca7edbf16ee895
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20151230/473e9112/attachment.sig