[swift-evolution] [Proposal] Random Unification

[David Waite]

> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> I agree with Felix’s concern, which is why I brought up the question, but ultimately the issue is unavoidable. It’s not down to global instance or not. If your source of random numbers is unseedable and may mix in additional entropy at any time, then it may fail at any time because when a hardware restart might happen may be transparent to the process. The user must know about this or else we are laying a trap (pun intended).

I'm of the mindset (which might be controversial) that we should attempt to expose legacy and cryptographically secure random number generators, even a mixed algorithmic/entropy source like /dev/urandom, but that we should not expose /dev/random at all. If someone is trying to use /dev/random legitimately (such as to generate one-time-pads) they will have to take into account that systems like linux still use algorithmic entropy to drive /dev/random. If someone really has this sort of use case, they have exceeded the bounds of the system randomness protocol.

Without /dev/random support as a requirement, the only failure cases I know of are reading too much random data in one operation (which could be solved by repeated calls) or calling before sufficient entropy has been set up in /dev/urandom (such as in a system startup process). I'd be fine with the second one being a special case, and such systems needing to know use of the /dev/urandom -backed generator before randomness has been set up will trap or return predictable information on certain platforms.

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171004/c9500396/attachment.html>