> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
