On Fri, Sep 8, 2017 at 8:07 PM, Xiaodi Wu via swift-evolution < [email protected]> wrote:
> On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon <[email protected]> wrote: > >> On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution < >> [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > I would argue that anyone doing cryptography probably already knows how important RNG selection is and can be expected to look for a specialized cryptographically secure RNG. I doubt they would just use the default RNG without first checking the documentation.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
