<div><br><div class="gmail_quote"><div dir="auto">On Wed, Dec 20, 2017 at 13:13 Jens Persson <<a href="mailto:jens@bitcycle.com">jens@bitcycle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Oh OK, I must have misunderstood this thread:</div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042034.html" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042034.html</a></div><div>(</div><div>"The strong opinion of the core team is that such an API should *not* be designed with an attempt to service people writing crypto code."</div><div>"It is general goodness if generality for crypto use cases somehow falls out of the design. However, the design for general use shouldn’t suffer because of that goal."</div><div>)</div><div><br></div><div>I assumed that the Random API would save the user from the trouble of making a good choice and implementation (fast and good quality) of a "standard" general purpose prng (as well as maybe a cryptographically secure one).</div></div></blockquote><div dir="auto"><br></div><div dir="auto">Providing a cryptographically secure PRNG is necessary but not sufficient for cryptography. However, many ordinary uses of a general purpose PRNG will assume that future “random” numbers cannot be guessed by observing a small number of previous ones. Xoroshiro has its uses, but it would not be the ideal basis for a general purpose PRNG, especially since we have easy access to true randomness.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Also, the most commonly recommended ways of converting from eg 64 random bits to an int range or a floating point range are unnecessarily bad and slow, so I figured the webpage was worth a read, in addition to C++ stdlib's implementation.</div></div><div><div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">I agree it will be critical to ensure that random floating-point values are truly uniform. All implementors would do well to study the state of the art.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>/Jens</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 20, 2017 at 4:55 PM, Xiaodi Wu <span><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">xoroshiro128+ is not a cryptographically secure algorithm and would not be incorporated into the Random API, though it is trivial to implement your own; the proposal outlines sources of randomness that are cryptographically secure.<div class="m_-1806901253599073460HOEnZb"><div class="m_-1806901253599073460h5"><br><br><br><div class="gmail_quote"><div>On Wed, Dec 20, 2017 at 09:46 Jens Persson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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>I'd like to add a pointer to the information here:<div><a href="http://xoroshiro.di.unimi.it" target="_blank">http://xoroshiro.di.unimi.it</a><br></div><div><br></div><div>since AFAICS, the xoroshiro128+ generator and the method of "Generating uniform doubles in the unit interval" should probably be implemented in any modern general purpose Random API.</div><div><br></div><div>Please correct me if there are more up to date (higher quality and faster) general purpose generators and ways of converting UInt64 bit patterns to floating point [0, 1).</div></div><div><div><br></div><div>/Jens</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 3, 2017 at 4:50 AM, Dave Abrahams via swift-evolution <span><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I don’t have much to say about this other than that I think the discussion seems way too narrow, focusing on spelling rather than on functionality and composability. I consider the “generic random number library” design to be a mostly-solved problem, in <span style="background-color:rgba(255,255,255,0)">the C++ standard library (<a href="http://en.cppreference.com/w/cpp/numeric/random" target="_blank">http://en.cppreference.com/w/cpp/numeric/random</a>). </span>Whatever goes into the Swift standard library does not need to have all those features right away, but should support being extended into something having the same general shape. IMO the right design strategy is to <u>implement and use</u> a Swift version of C++’s facilities and only then consider proposing [perhaps a subset of] that design for standardization in Swift.<div><div><br></div><div>Sent from my iPad<div><div class="m_-1806901253599073460m_1099187514501644030m_-3123303733990316353h5"><div><br>On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1806901253599073460m_1099187514501644030m_-3123303733990316353m_2884825403601079015Apple-interchange-newline"><div><span 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;float:none;display:inline!important">Instead, we ought to make clear to users both the features and the limitations of this API, to encourage use where suitable and to discourage use where unsuitable.</span></div></blockquote></div><br><div>I like that you're considering the balance here. I've been lightly following this thread and want to add my thoughts on keeping crypto and pseudorandomness out of the name of at least one <font face="Menlo">random</font> API intended for general use.</div><div><br></div><div>For someone who doesn't know or care about the subtleties of insecure or pseudorandom numbers, I'm not sure that the name <font face="Menlo">insecureRandom</font> is effectively much different than <font face="Menlo">badRandom</font>, at least in terms of the information it conveys to non-experts. To Greg's point, that's the opposite of the signal that the API name should suggest because it's what most people should use most of the time. As you say, this API is being designed for general use.</div><div><br></div><div>There's a cost to adding extra complexity to names, too. I don't think it's far-fetched to suspect that people who find <font face="Menlo">insecureRandom</font> in an autocomplete listing or search will think "Where's the plain random function?"... and then go looking for a community extension that will inevitably provide a trivial alias: <font face="Menlo">func random() { return insecureRandom() }</font>. That's the sort of adoption I'd expect from something for new programmers, like Swift Playgrounds. Someone's introduction to randomness in programming should probably involve no more than a straightforward mapping from the elementary definition, rather than forcing a teaching moment from more advanced math.</div><div><br></div><div>I think there are better places for caveat information than in the API names themselves; documentation being one clear destination. This is in contrast with <font face="Menlo">Unsafe*Pointer</font>, where the safety element is critical enough to be elevated to be more than caveat-level information. You can go really far and create really cool things before these caveats start to apply. Using randomness as a black box in an intro programming environment seems like a much more common scenario than someone attempting to roll their first crypto by only reading API names and hoping for the best.</div><div><br></div><div>-Kyle</div></div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></span></div></blockquote></div></div></div><br>_______________________________________________<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>
<br></blockquote></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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div></div>