On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon <sca...@apple.com> wrote:
> On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution < > swift-evolution@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution