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 < [email protected]> 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 < > [email protected]>, wrote: > > > > On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution < > [email protected]> wrote: > > > On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon <[email protected]> > wrote: > > On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
