[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

If trapping is OK, then surely returning Optional is superior; any user who
is OK with trapping can make that decision for themselves by writing
`random()!`. Everyone else can then see clearly that trapping is a
possibility, which is important.
On Wed, Oct 4, 2017 at 11:09 David Waite <david at alkaline-solutions.com>
wrote:

>
> 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/0fe3b6c1/attachment.html>