<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 30 sept. 2017 à 08:22, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" 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; -webkit-text-stroke-width: 0px;" class="">On Thu, Sep 28, 2017 at 12:16 PM, Félix Cloutier<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:felixcloutier@icloud.com" target="_blank" class="">felixcloutier@icloud.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><br class=""><div class=""><span class="gmail-"><br class=""><blockquote type="cite" class=""><div class="">Le 27 sept. 2017 à 17:29, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> a écrit :</div><div class=""><div dir="auto" 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;" class=""><br class=""></div><div dir="auto" 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;" class="">What I was trying to respond to, by contrast, is the design of a hierarchy of protocols CSPRNG : PRNG (or, in Alejandro's proposal, UnsafeRandomSource : RandomSource) and the appropriate APIs to expose on each. This is entirely inapplicable to your examples. It stands to reason that a non-instantiable source of random numbers does not require a protocol of its own (a hypothetical RNG : CSPRNG), since there is no reason to implement (if done correctly) more than a single publicly non-instantiable singleton type that could conform to it. For that matter, the concrete type itself probably doesn't need *any* public API at all. Instead, extensions to standard library types such as Int that implement conformance to the protocol that Alejandro names "Randomizable" could call internal APIs to provide all the necessary functionality, and third-party types that need to conform to "Randomizable" could then in turn use `Int.random()` or `Double.random()` to implement their own conformance. In fact, the concrete random number generator type doesn't need to be public at all. All public interaction could be through APIs such as `Int.random()`.</div></div></blockquote></span><div class=""><div class=""><br class=""></div><div class="">If there is globally-available CSPRNG that people are encouraged to use, what is the benefit of a CSPRNG : PRNG hierarchy?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">There are plenty of use cases that do not require cryptographically secure pseudorandom sequences but can benefit from the speed of an algorithm like xoroshiro128+. For instance, suppose I want to simulate Brownian motion in an animation; I do not care about the cryptographic properties of my random number source. However, the underlying function to generate a normally distributed random number can rely on either a source of cyptographically secure or cryptographically insecure uniformly distributed random numbers. Put another way, a protocol hierarchy is justified because useful functions that produce random values in various desired distributions can be written that work with any PRNG, while there are (obviously) uses that are suitable for CSPRNGs only.</div></div></div></div></div></blockquote><div><br class=""></div><div>It was never in question that a CSPRNG can act as a PRNG, as far as generating numbers goes. That doesn't explain the usefulness of the CSPRNG interface if we're going to prefer *the* CSPRNG.</div><div><br class=""></div><div><ul class="MailOutline"><li class="">For cryptographic applications, the expectation is that you'll use the global CSPRNG.</li><li class="">If you have a cryptographic application that requires you to initialize a CSPRNG with some seed, then that algorithm has been specified, and it doesn't matter if the generator implements a CSPRNG protocol (on top of a PRNG protocol) because you're working with concrete types.</li><li class="">If you have a non-crypto application that needs repeatable sequences of elements, then any seedable PRNG implementation is sufficient and there is no benefit to calling it crypto-secure (even if it is).</li></ul><div class=""><br class=""></div><div class="">It seems to me that a CSPRNG interface is useful if you need crypto-secure random numbers, but you can trust input from sources that don't come with the guarantees of the global CSPRNG, and from algorithms that you can't exhaustively list in advance. Does that sound right? Do you have a use case in mind, or an example of an application that has similar requirements?</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><div dir="ltr" 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; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><div class=""><div class="">What is the benefit of clearly identifying an algorithm as crypto-secure if the recommendation is that you use *the* crypto-secure object/functions?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">The default source of random numbers is unseedable, but the user may instead require repeatable generation of a sequence of random numbers. The user may have a use case that requires the use of a particular specified CSPRNG.</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class=""><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;" class="">Again, I'm not only talking about urandom. As far as I'm aware, every API to retrieve cryptographically secure sequences of random bits on every platform for which Swift is distributed can potentially return an error instead of random bits. The question is, what design for our API is the most sensible way to deal with this contingency? On rethinking, I do believe that consistently returning an Optional is the best way to go about it, allowing the user to either (a) supply a deterministic fallback; (b) raise an error of their own choosing; or (c) trap--all with a minimum of fuss. This seems very Swifty to me.</div></div></blockquote><div class=""><br class=""></div></span><div class="">With Linux's getrandom, if you read from urandom (the default) and ask for as much or less than 256 bytes, the <a href="http://man7.org/linux/man-pages/man2/getrandom.2.html" target="_blank" class="">only possible error is that urandom hasn't been seeded</a>. (With more than 256 bytes, it also becomes possible for the system call to be interrupted by a signal.) OpenBSD's getentropy is <a href="https://github.com/openbsd/src/blob/master/sys/dev/rnd.c#L889" target="_blank" class="">literally just arc4random running in the kernel</a>, and will only fail if you ask for more than 256 bytes because it is a hard-coded limit.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, but again, what do you think of the possible Swift API design choices to accommodate these errors? We have to pick one, but none of them are very appealing.</div></div></div></div></div></blockquote><div><br class=""></div><div>Is that still the right thing to do then? How do these not very appealing alternatives compare against instance methods on Random objects, like random.any(1...6)?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Meanwhile, getentropy() has the problem that, if there is insufficient randomness to initialize the entropy pool, it will block; on systems where there is never going to be sufficient randomness (i.e. a VM), it will block forever. By contrast, getrandom() permits a flag that will make this scenario non-blocking.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><div class="">Ironically, I don't know how you get entropy on Darwin. If it's more failable that this, I'd argue that it's time to improve a bit...</div><span class="gmail-HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Félix</div></font></span></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>