[swift-evolution] [Proposal] Random Unification

[Taylor Swift]

On Fri, Sep 8, 2017 at 8:07 PM, Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> 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.
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170909/23e2a574/attachment.html>