<div>On Wed, Oct 4, 2017 at 20:32 Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>FWIW, I agree with Ben here: if the true cryptographically secure random numbers force this complexity onto users, then we should settle for something close but not quite that bulletproof.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">As long as it's a conscious design choice, that's potentially fine. My purpose in raising this issue is to point out that there is a choice to be made. Another consideration is that, if primitives such as Int.random() silently degrade, they cannot be the basis upon which more sophisticated secure APIs are built.</div><div dir="auto"><br></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 dir="auto"><div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>On Oct 4, 2017, at 6:15 PM, Xiaodi Wu 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><div><br><div class="gmail_quote"><div dir="auto">On Wed, Oct 4, 2017 at 18:42 Ben Cohen <<a href="mailto:ben_cohen@apple.com" target="_blank">ben_cohen@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div>On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_7146444038684887867m_-3551158415542345594Apple-interchange-newline"><div>If trapping is OK, then surely returning Optional is superior; any user who is OK with trapping can make that decision for themselves by writing `random()!`. Everyone else can then see clearly that trapping is a possibility, which is important.<br></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>It’s important not to underestimate both the extent to which using `!` scares people, _and_ the extent to which beginners use it inappropriately. Both of these mean that it’s very important the standard library not include anything that makes force-unwrapping a common/routine operation (looking at you, UnsafeBufferPointer.baseAddress).</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto"></div></div></blockquote><div dir="auto"><br></div><div dir="auto">I agree; however, if given the choice of `random()` potentially trapping or `random()!` potentially trapping, I would argue that the latter is strictly superior to the former. If the latter option scares people, the former should scare people more, and its nicer appearance is a bug, not a feature.</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 style="word-wrap:break-word;line-break:after-white-space"><div dir="auto">Given that arc4random, the recommended source of random numbers on Darwin, is always successful, requiring a force-unwrap when the user is using the default source doesn’t seem like the right move.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">Always successful for some values of successful. We cannot design our way out of physics.</div><div dir="auto"><br></div><div dir="auto">Chris has indicated—and I agree—that the default random facilities should do the right thing in terms of cryptographic security. Since arc4random is guaranteed to be successful but the underlying hardware cannot be guaranteed to always have the entropy to make it secure, it must follow that some invocations of arc4random produce results unsuitable for cryptographic use.</div><div dir="auto"><br></div><div dir="auto">To reiterate, this is one of several options. When there isn’t enough entropy for secure random numbers, the function can:</div><div dir="auto"><br></div><div dir="auto">- block</div><div dir="auto">- return an insecure result</div><div dir="auto">- return nil</div><div dir="auto">- throw</div><div dir="auto">- trap</div><div dir="auto"><br></div><div dir="auto">This is an exhaustive list, as far as I can tell. None of these options are entirely desirable, but it is inescapable that one of these is the default, go-to design for Swift; of course, alternatives can be offered, but the question is, what should we tell the novice user to reach for?</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 style="word-wrap:break-word;line-break:after-white-space"><div dir="auto"></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><blockquote type="cite"><div></div></blockquote></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div class="gmail_quote"><div>On Wed, Oct 4, 2017 at 11:09 David Waite <<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_7146444038684887867m_-3551158415542345594m_-3604861847801050889Apple-interchange-newline"><div><br class="m_7146444038684887867m_-3551158415542345594m_-3604861847801050889Apple-interchange-newline"><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">I agree with Felix’s concern, which is why I brought up the question, but ultimately the issue is unavoidable. It’s not down to global instance or not. If your source of random numbers is unseedable and may mix in additional entropy at any time, then it may fail at any time because when a hardware restart might happen may be transparent to the process. The user must know about this or else we are laying a trap (pun intended).</span></div></blockquote></div><br></div><div style="word-wrap:break-word"><div>I'm of the mindset (which might be controversial) that we should attempt to expose legacy and cryptographically secure random number generators, even a mixed algorithmic/entropy source like /dev/urandom, but that we should not expose /dev/random at all. If someone is trying to use /dev/random legitimately (such as to generate one-time-pads) they will have to take into account that systems like linux still use algorithmic entropy to drive /dev/random. If someone really has this sort of use case, they have exceeded the bounds of the system randomness protocol.</div><div><br></div><div>Without /dev/random support as a requirement, the only failure cases I know of are reading too much random data in one operation (which could be solved by repeated calls) or calling before sufficient entropy has been set up in /dev/urandom (such as in a system startup process). I'd be fine with the second one being a special case, and such systems needing to know use of the /dev/urandom -backed generator before randomness has been set up will trap or return predictable information on certain platforms.</div></div><div style="word-wrap:break-word"><div><br></div><div>-DW</div></div></blockquote></div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div>
_______________________________________________</div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><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></div></blockquote></div></div>
</div></blockquote><blockquote type="cite"><div><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></div></blockquote></div></blockquote></div></div>