[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180702203957.GA9081@brightrain.aerifal.cx>
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.
