Date: Mon, 2 Jul 2018 16:39:57 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: arc4random/csprng I haven't followed what's been happening with posix_random lately, but glibc has adding the arc4random interfaces and it seems reasonable that we should too, with the easy option to add the posix_random name for it and whatever interface details POSIX decides on. The glibc implementation looks like it's essentially CTR mode AES. This is probably a pretty good choice, but unless there are strong reasons not to I'd probably rather go with Hash-DRBG or HMAC-DRBG utilizing the existing SHA-256 code we already have. That would avoid the need to write or import any new cryptographic code (and the associated risks) and keep the size cost minimal. This seems better for forward-secrecy too, but I'd like to better understand the conditions under which Hash-DRBG and HMAC-DRBG provide forward-secrecy. One topic I thought was a huge bikeshed was the whole fork-detection or fork-safety thing, but apparently it's not for glibc and perhaps other implementations because they've opted to make their csprng lock-free and incurred a lot of complexity with safely replacing pseudo-immutable state. I want to avoid most or all of this issue by just using a proper lock, but it might still be necessary to do some nasty hack for the case where fork is called from a signal handler interrupting the csprng. The only way to avoid that entirely is to block signals while the csprng runs, which is probably unjustifiably slow. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.