[swift-evolution] [Proposal] Random Unification

[Jean-Daniel]

> Le 9 sept. 2017 à 21:03, Taylor Swift via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
> 
> On Fri, Sep 8, 2017 at 8:07 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon <scanon at apple.com <mailto:scanon at apple.com>> wrote:
>> On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto: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.
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> I would argue that anyone doing cryptography probably already knows how important RNG selection is

If it where the case, why is there so many security issues due to poor choice of random source ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170910/88d24366/attachment.html>