> 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.
– Steve
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
