Re: CVS commit: src/lib/libc

[Alan Barrett <apb%cequrux.com@localhost>]

On Tue, 24 Jun 2014, David Holland wrote:
> On Mon, Jun 23, 2014 at 07:46:15PM +0000, Taylor R Campbell 
> wrote:
> > Read from /dev/urandom.
>
> ...ugh. Can we provide a wrapper around this for transparent 
> casual use? (Even if it's in libutil and marked not for general 
> consumption?)

Yes please.  Note that we already have cprng_{fast,strong}{,32,64} 
functions in the kernel.

> > Or it may be worthwhile to mostly keep the way arc4random(3) 
> > works but replace the PRNG, as in the first reimplementation of 
> > arc4random(3) above, but rename it.
>
> yes please

Yes, I think that's what we are getting at.  Keep the way the 
interface works, to make it easy for callers to adapt to the new 
way, reimplement the internals, and rename to something that does 
not embed an algorithm name in the function name.

> > With either of the later two cases, perhaps we ought to just 
> > coopt random(3) for the purpose.
>
> no please (random(3) is not expected to be cryptographically 
> strong, so code that assumes it is becomes unportable in a 
> subtle and dangerous way)
>
> Also I think there's code out there that saves and restores the 
> random(3) state and expects to get repeatable results.

Yes, the random(3) functions need to be able to provide repeatable 
results, and state save/restore functionality.

I am not sure about repeatability requirements across OS 
upgrades.  I think it may be acceptable for different versions of 
the random(3) implementation (say before and after an OS upgrade) 
to produce different output streams from the same initial seed or 
state.

--apb (Alan Barrett)