> Le 9 sept. 2017 à 03:07, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org> a écrit :
> 
> On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon <sca...@apple.com 
> <mailto:sca...@apple.com>> wrote:
>> On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution 
>> <swift-evolution@swift.org <mailto: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.

I agree too. Anyone that need a random generator but don’t know how it works 
and what’s a CSPRNG is need a CSPRNG.

For other users, we still need a couple of other implementations.



_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to