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
signature.asc
Description: PGP signature
