<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></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="">On Dec 2, 2017, at 1:09 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon <span dir="ltr" class=""><<a href="mailto:brent@architechies.com" target="_blank" class="">brent@architechies.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><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" class=""><span class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_4540314277911264936Apple-interchange-newline"><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="">That said, I am not sure that this proposal should give any pretense of being suitable for cryptographic use. On implementation, the code will not have been audited for that purpose, although the author very rightly attempts to use the "best" possible sources of entropy available for each platform. Perhaps explicitly _not_ supporting cryptographic operations is the more Swifty way to go (in the sense that, where possible, Swift API design aims to help users avoid footguns).</div></div></blockquote><br class=""></div></span><div class="">People will use it for crypto whether we want them to or not.</div></div></blockquote><div class=""><br class=""></div><div class="">People are going to do all sorts of unanticipated things, sure. But this doesn't mean that we shouldn't consider how we may best encourage users to avoid _unintentional_ common pitfalls.</div><div class=""><br class=""></div><div class="">There are options to explore here. Consider, for example--and I'm not suggesting that we be this verbose, but it is illustrative of the trade-offs which are possible to keep in mind--if certain methods were very clear that the result is *pseudorandom* and potentially *insecure*: `(0..<9).insecurePseudorandomElement`. Clearly, fewer people would use this method for crypto.</div></div></div></div></div></blockquote><br class=""></div><div>But what *should* they use instead of our API? The OS-provided CSPRNG is almost certainly going to be the most secure thing available in the absence of specialized hardware. We should not deliberately scare users away from our API if there is nothing better on offer.</div><br class=""><div class=""><br class=""></div><div class="">-- </div><div class="">Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>