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.<br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 4, 2017 at 23:17 Alejandro Alonso via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
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?</div></div><div>
<div name="messageSignatureSection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
- Alejandro</div></div><div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<br>
On Oct 4, 2017, 6:26 PM -0500, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>, wrote:<br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #1abc9c">
<div dir="auto" style="word-wrap:break-word;line-break:after-white-space">
<br>
<div><br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #e67e22">
<div>On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div>
<br class="m_6510050013679445985Apple-interchange-newline">
<div>
<div style="word-wrap:break-word">
<br>
<div>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #3498db">
<div>On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:</div>
<br class="m_6510050013679445985Apple-interchange-newline">
<div>
<div style="word-wrap:break-word">
<div>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #d35400">
<div>On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div>
<br class="m_6510050013679445985Apple-interchange-newline">
<div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
- 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.</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div>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:</div>
</div>
<br>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #d35400">
<div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
- 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).</div>
</div>
</blockquote>
</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div><span class="m_6510050013679445985Apple-tab-span" style="white-space:pre-wrap"></span>1. The abstraction used to plug in different random number generators (i.e. an RNG protocol of some kind).</div>
<div><br>
</div>
<div><span class="m_6510050013679445985Apple-tab-span" style="white-space:pre-wrap"></span>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.)</div>
<div><br>
</div>
<div><span class="m_6510050013679445985Apple-tab-span" style="white-space:pre-wrap"></span>3. A default RNG with a conservative design that will sometimes be too slow, but will never be insufficiently random.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
</div>
<div>+1 to this general plan!</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>This pretty much exactly matches my preferences. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>(and no need for distributions other than uniform IMO, 🇫🇷🐟 or otherwise)</div>
<div><br>
</div>
<blockquote type="cite" style="margin:5px 5px;padding-left:10px;border-left:thin solid #e67e22">
<div>
<div style="word-wrap:break-word">
<div><br>
</div>
<div>-Chris</div>
<div><br>
</div>
<br>
</div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>