[swift-evolution] [Proposal] Random Unification
kelvin13ma at gmail.com
Sat Sep 9 14:03:12 CDT 2017
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
> 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...
More information about the swift-evolution