<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><br class=""><blockquote type="cite" class=""><div class="">Le 1 oct. 2017 à 07:24, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>&gt; a écrit :</div><div class=""><blockquote class="gmail_quote" 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; 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="">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></div></div></blockquote><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; -webkit-text-stroke-width: 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; -webkit-text-stroke-width: 0px;" class="">TOTP, used for two-factor authentication, takes a shared secret as seed and generates a deterministic sequence of cryptographically secure one-time passwords.</div></div></blockquote><div><div><br class=""></div><div>That case was specifically called out in the message you were replying to: any algorithm would have to be agreed upon. What is the benefit of a CSPRNG protocol in that case? You know exactly which random number generator you'll be using, and in fact, you might be using one that isn't even considered crypto-secure anymore (like a hypothetical RC4Random would be, if Swift had been around for long enough) because users haven't upgraded their TOTP yet.</div><div><br class=""></div></div><div>Besides, AFAIK, the common implementation of TOTP computes the HMAC of the timestamp with the shared secret as the key and doesn't involve random numbers. Do you have another example?</div><br class=""><blockquote type="cite" class=""><blockquote class="gmail_quote" 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; 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=""><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=""><div class="gmail_extra"><div class="gmail_quote"><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 class=""><br class=""></div></div></div><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><div class="">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></div></div></blockquote><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; -webkit-text-stroke-width: 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; -webkit-text-stroke-width: 0px;" class="">I think I’m not stating my question clearly. Regardless of how you spell it, what do you think is the optimal behavior when requesting a random number fails for lack of entropy? Should we return nil, throw, trap, or block? One of these has to happen either when you try to initialize a generator or when you try to first use the global/thread-local generator.</div></blockquote><div><br class=""></div><div>With a design where the random number generator creates the number, then if you have a PRNG instance, you will always be able to generate a number. Requesting a random number can't fail for lack of entropy in that design.</div><div><br class=""></div><div>The only failable part would be getting the PRNG instance: that never happens for a PRNG that you can seed, and the global crypto-secure one can go behind an Optional, or a Future if we want a waitable handle.</div><div><br class=""></div><div>Félix</div></div></body></html>