Peter Waltenberg wrote: > The next question you should be asking is: does our proposed design mitigate > known issues ?. > For example this: > http://www.pcworld.com/article/2886432/tens-of-thousands-of-home-routers-at-risk-with-duplicate-ssh-keys.html
Using the OS RNG won't fix the lack of boot time randomness unless there is a HRNG present. For VMs, John's suggestion that /dev/hwrng should be installed is reasonable. For embedded devices, a HRNG is often not possible. Here getrandom() (or /dev/random since old kernels are common) should be used. Often /dev/urandom is used instead and the linked article is the result. There are possible mitigations that some manufacturers include (usually with downsides). The question is should a security toolkit try to do a good job regardless? I've seen more cases than I care to count where long term cryptographic material is generated on first boot out of the factory. I've even seen some cases where this was done during the factory test. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
