<div><div><br><div class="gmail_quote"><div dir="auto">On Sat, Dec 2, 2017 at 19:02 Greg Parker &lt;<a href="mailto:gparker@apple.com" target="_blank">gparker@apple.com</a>&gt; 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"><br><div><blockquote type="cite"><div>On Dec 2, 2017, at 1:09 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_-2752601251149122803m_5800267766703138341Apple-interchange-newline"><div><div>On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon <span>&lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt;</span> wrote:<br><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"><span><div><blockquote type="cite"><div>On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_-2752601251149122803m_5800267766703138341m_4540314277911264936Apple-interchange-newline"><div><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">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 &quot;best&quot; 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></div></span><div>People will use it for crypto whether we want them to or not.</div></div></blockquote><div><br></div><div>People are going to do all sorts of unanticipated things, sure. But this doesn&#39;t mean that we shouldn&#39;t consider how we may best encourage users to avoid _unintentional_ common pitfalls.</div><div><br></div><div>There are options to explore here. Consider, for example--and I&#39;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..&lt;9).insecurePseudorandomElement`. Clearly, fewer people would use this method for crypto.</div></div></div></div></div></blockquote><br></div></div><div style="word-wrap:break-word;line-break:after-white-space"><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></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></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"><br></div></blockquote></div></div><div dir="auto"><br></div></div><div><div dir="auto">It’s not about OS-provided CSPRNG. It’s about the design and implementation of _this proposal_ on top of the CSPRNG.</div><div dir="auto"><br></div><div dir="auto">Earlier, we discussed how this API should minimize the number of optional return values to improve user ergonomics. Instead, the returned value should be a reasonable best-effort at randomness. This is sensible for a general-use API, but it is unsuitable for a crypto-oriented API.</div><div dir="auto"><br></div><div dir="auto">David Waite criticizes GameplayKit as lacking in crypto-oriented functions—the implication being that we ought to provide them here. I disagree. My point is that our entire design process has been geared towards a reasonable, best-effort general-use API: It is being designed by community members who are not specialized in this particular subfield. It is explicitly being design for common, general use cases in mind. And the implementation will come with no guarantee as to suitability for crypto, nor should it have to.</div><div dir="auto"><br></div><div dir="auto">Therefore, I reason, we ought not to extend the design with functions that are explicitly geared towards crypto using primitive operations that we haven’t audited for such suitability. 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.</div><div dir="auto"><br></div></div>