[swift-evolution] [Proposal] Random Unification

[Xiaodi Wu]

Glibc random is not cryptographically secure, nor is it thread-safe.
getrandom() fails in more ways than arc4random and is therefore a primitive
on which we can base a shim but isn't suitable by itself. Swift used to use
libbsd internally on Linux but that dependency was removed. Currently, it
uses the C++ Mersenne twister engine on all platforms, which is not
cryptographically secure, with a device random seed that is not guaranteed
to be random by the C++ standard if no device is available. Likely,
therefore, a shim will have to be manually implemented.
On Wed, Oct 4, 2017 at 23:17 Alejandro Alonso via swift-evolution <
swift-evolution at swift.org> wrote:

> I think this is a good idea. I start asking questions about what our
> default generator for linux will be if we use Darwin’s arc4random(3). Do we
> use Glibc’s random()? If so, what do we seed it with?
>
> - Alejandro
>
> On Oct 4, 2017, 6:26 PM -0500, Ben Cohen via swift-evolution <
> swift-evolution at swift.org>, wrote:
>
>
>
> On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon <brent at architechies.com>
> wrote:
>
> On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> - I’d love to see several of the most common random kinds supported, and I
> agree it would be nice (but not required IMO) for the default to be
> cryptographically secure.
>
>
> I would be very careful about choosing a "simple" solution. There is a
> log, sad history of languages trying to provide a "simple" random number
> generator and accidentally providing a powerful footgun instead. But:
>
> - We should avoid the temptation to nuke this mosquito with a heavy handed
> solution designed to solve all of the world’s problems: For example, the
> C++ random number stuff is crazily over-general.  The stdlib should aim to
> solve (e.g.) the top 3 most common cases, and let a more specialized
> external library solve the fully general problem (e.g. seed management,
> every distribution imaginable, etc).
>
>
> That's not to say we need to have seven engines and twenty distributions
> like C++ does. The standard library is not a statistics package; it exists
> to provide basic abstractions and fundamental functionality. I don't think
> it should worry itself with distributions at all. I think it needs to
> provide:
>
> 1. The abstraction used to plug in different random number generators
> (i.e. an RNG protocol of some kind).
>
> 2. APIs on existing standard library types which perform basic
> randomness-related functions correctly—essentially, encapsulating Knuth.
> (Specifically, I think selecting a random element from a collection (which
> also covers generating a random integer in a range), shuffling a mutable
> collection, and generating a random float will do the trick.)
>
> 3. A default RNG with a conservative design that will sometimes be too
> slow, but will never be insufficiently random.
>
> If you want to pick elements with a Poisson distribution, go get a
> statistics framework; if you want repeatable random numbers for testing,
> use a seedable PRNG from XCTest or some other test tools package. These can
> leverage the standard library's RNG protocol to work with existing random
> number generators or random number consumers.
>
>
> +1 to this general plan!
>
>
> This pretty much exactly matches my preferences.
>
> If random numbers go into the std lib, they should  being able to
> customize the source of randomness for speed or test reproducibility, but
> default to something sensible without the user having to know it’s
> configurable. On Darwin that default should be based on arc4random(3). The
> std lib doesn’t need to provide other non-default random sources.
> Non-random sources for testing should be part of test frameworks and plug
> in easily.
>
> The proposal should include shuffle and random element from collection,
> which are much-requested and not really the controversial part so won't
> hold up the overall progress of the proposal.
>
> (and no need for distributions other than uniform IMO, 🇫🇷🐟 or otherwise)
>
>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171005/070f7949/attachment.html>