Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/lib/libc



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)


Home | Main Index | Thread Index | Old Index