Re: [dsfjdssdfsd] getentropy(2)

On Tue, Jul 15, 2014 at 6:13 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Jul 15, 2014 at 08:39:07AM -0400, Benjamin Kaduk wrote:
>>
>> I'm not confident that [all] application writers will even be competent to
>> correctly choose amongst the 5 listed uses [plus whatever others might be
>> added].  If it stays a small number of easily identified things, it might
>> still be better than only exposing the blocking/nonblocking-ness directly,
>> but it doesn't seem clear-cut to me.
>
> Well, a large number of these uses should be done in the crypto
> library -- since if the application writer can't tell the difference
> between an IV and a session key, I'm not sure I want that person
> anywhere near crypto code...

What is the difference in how random they should be? There isn't one,
and making it exposable in system policy invites
all sorts of issues.

>
>> BTW, FreeBSD exposes a sysctl MIB (CTL_KERN.KERN_ARND) to get entropy
>> directly, saving syscalls over open("/dev/[u]random")/read()/close().
>
> That only matters if you want to encourage applications to be
> constantly asking the kernel to generate numbers, though, yes?  I'm
> arguing that it might be better to have a standardized userspace
> library, ala OpenBSD's arc4random, which takes care of all of the OS
> specific issues, and also provides a crypto-based DRBG.  In that case,
> it saves even more syscalls, since it only needs to read entropy from
> the kernel at application startup time, and perhaps periodically every
> so often when it wants to reseed, but not every single time you need
> crypto-sensitive padding, IV's, session keys, etc.

getentropy(2) could  be getentropy(3). What's more important is what I
want it to do
- Block if the random system is not initialized (or return a return
value indicating failure)
- Return random numbers, even if I've forked or have a multithreaded process
- Do so promptly

Currently on Linux none of the available options work. Forking
requires a post-fork call, /dev/random blocks constantly, and
/dev/urandom
does not block on startup. I'm probably going to open /dev/urandom:
it's the best current alternative.

Perhaps arc4random is better to imitate: I don't really care. I just
need it to work and ship yesterday.

Sincerely,
Watson Ladd
(And don't use RC4 for it!)
>
> Cheers,
>
>                                                 - Ted
>
> _______________________________________________
> dsfjdssdfsd mailing list
> dsfjdssdfsd@ietf.org
> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin