[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMAJcuC4ZbGO5JbHeiAoi_2KjAKL+q8LHBrdn-t5mmP=X+5dUQ@mail.gmail.com>
Date: Wed, 28 Jan 2015 16:59:13 -0600
From: Josiah Worcester <josiahw@...il.com>
To: musl@...ts.openwall.com
Subject: Re: getrandom syscall
On Wed, Jan 28, 2015 at 4:02 PM, Rich Felker <dalias@...c.org> wrote:
>
> At this point I think what's clear is that we should provide the
> syscall wrapper for getrandom. What to do with getentropy is less
> clear, and it looks to be a fair bit of work/code-size to get a robust
> getentropy suitable for application usage.
>
> I don't want to copy the idiotic stuff libressl is doing, but I think
> the following fallback sequence would be reasonable:
For what it's worth the libressl stuff is nowhere near as idiotic as
what was there previously (though is still a bunch of stuff that is at
least theoretically determinable)
> 1. Try SYS_getrandom. Fails on even mildly-old kernels.
>
> 2. Try opening /dev/urandom. Fails under fd pressure or broken
> chroots/containers/lsms/etc.
>
> 3. Try AT_RANDOM+CSPRNG. Fails on ancient (what version?) kernels.
2.6.29+ have AT_RANDOM.
> I don't know what to after that, but I suspect/hope that any kernel
> too old to have AT_RANDOM is full of so many gaping security holes
> that lack of working entropy source is the least of anyone's problems.
2.6.12 and possibly earlier appears to have the RANDOM_UUID sysctl, if
you wish to use that.
> As for CSPRNG, what would be acceptably small and secure? CTR mode
> using a block cipher and AT_RANDOM as the key? Could we reuse crypto
> code out of crypt/*.c? Or just call crypt_r directly?
>
> 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.
