[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon <scanon at apple.com> wrote:

> On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> This topic has been broached on Swift Evolution previously. It's
> interesting to me that Steve Canon is so certain that CSPRNGs are the way
> to go. I wasn't aware that hardware CSPRNGs have come such a long way and
> are so ubiquitous as to be feasible as a basis for Swift random numbers. If
> so, great.
>
> Otherwise, if there is any way that a software, non-cryptographically
> secure PRNG is going to outperform a CSPRNG, then I think it's worthwhile
> to have a (carefully documented) choice between the two. I would imagine
> that for many uses, such as an animation in which you need a plausible
> source of noise to render a flame, whether that is cryptographically secure
> or not is absolutely irrelevant but performance may be key.
>
>
> Let me be precise: it is absolutely possible to outperform CSPRNGs. They
> have simply become fast enough that the performance gap doesn’t matter for
> most uses (let’s say amortized ten cycles per byte or less—whatever you are
> going to do with the random bitstream will be much more expensive than
> getting the bits was).
>
> That said, yes, there should definitely be other options. It should be
> possible for users to get reproducible results from a stdlib random
> interface run-to-run, and also across platforms. That alone requires that
> at least one other option for a generator be present. There may also be a
> place for a very high-throughput generator like xorshiro128+.
>
> All I’m really saying is that the *default* generator should be an
> os-provided unseeded CSPRNG, and we should be very careful about
> documenting any generator options.
>


Agree on all points. Much like Swift's strings are Unicode-correct instead
of the fastest possible way of slicing and dicing sequences of ASCII
characters, Swift's default PRNG should be cryptographically secure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170908/6a5a9b30/attachment.html>