On Di, 17.09.19 09:27, Linus Torvalds (torvalds@xxxxxxxxxxxxxxxxxxxx) wrote: > But look at what gnome-shell and gnome-session-b does: > > https://lore.kernel.org/linux-ext4/20190912034421.GA2085@darwi-home-pc/ > > and most of them already set GRND_NONBLOCK, but look at the > problematic one that actually causes the boot problem: > > gnome-session-b-327 4.400620: getrandom(16 bytes, flags = 0) > > and here the big clue is: "Hey, it only asks for 128 bits of > randomness". I don't think this is a good check to make. In fact most cryptography folks say taking out more than 256bit is never going to make sense, that's why BSD getentropy() even returns an error if you ask for more than 256bit. (and glibc's getentropy() wrapper around getrandom() enforces the same size limit btw) On the BSDs the kernel's getentropy() call is primarily used to seed their libc's arc4random() every now and then, and userspace is supposed to use only arc4random(). I am pretty sure we should do the same on Linux in the long run. i.e. the idea that everyone uses the kernel syscall directly sounds wrong to me, and designing the syscall so that everyone calls it is hence wrong too. On the BSDs getentropy() is hence unconditionally blocking, without any flags or so, which makes sense since it's not supposed to be user-facing really so much, but more a basic primitive for low-level userspace infrastructure only, that is supposed to be wrapped non-trivially to be useful. (that's at least how I understood their APIs) > Does anybody believe that 128 bits of randomness is a good basis for a > long-term secure key? Even if the key itself contains than that, if > you are generating a long-term secure key in this day and age, you had > better be asking for more than 128 bits of actual unpredictable base > data. So just based on the size of the request we can determine that > this is not hugely important. aes128 is very common today. It's what baseline security is. I have the suspicion crypto folks would argue that 128…256 is the only sane range for cryptographic keys... Lennart -- Lennart Poettering, Berlin
