Am Montag, 25. April 2016, 09:55:14 schrieb Nikos Mavrogiannopoulos: Hi Nikos, > On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller <smueller@xxxxxxxxxx> wrote: > >> > ... DRBG is “minimally” seeded with 112^6 bits of entropy. > >> > This is commonly achieved even before user space is initiated. > >> > >> Unfortunately one of the issues of the /dev/urandom interface is the > >> fact that it may start providing random numbers even before the > >> seeding is complete. From the above quote, I understand that this > >> issue is not addressed by the new interface. That's a serious > >> limitation (of the current and inherited by the new implementation), > >> since most/all newly deployed systems from "cloud" images generate > >> keys using /dev/urandom (for sshd for example) on boot, and it is > >> unknown to these applications whether they operate with uninitialized > >> seed. > > > > One more item to consider: If you do not want to change to use > > getrandom(2), the LRNG provides you with another means. > > The main problem is not about willing to switch to getrandom() or not, > but finding any system where getrandom() exists. Today due to libc not > having the call, we can only use /dev/urandom and applications would > most likely continue to do so long time after getrandom() is > introduced to libc. Implement the syscall yourself with syscall(). If you get ENOSYS back, revert to your old logic of seeding from /dev/urandom. If you know you are on kernels >= 3.14, you could use the following steps in your library: - poll /proc/sys/kernel/random/entropy_avail in spaces of, say, one second and block your seeding process until that value becomes non-zero - if you unblock, seed from /dev/urandom and you have the guarantee of having a /dev/urandom seeded with 128 bits. > > regards, > Nikos Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
