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...
> 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.
Cheers,
- Ted
_______________________________________________
dsfjdssdfsd mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
