On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon <br...@architechies.com> wrote:
> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > 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). > > > People will use it for crypto whether we want them to or not. > 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. 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. None of the proposals involve actually writing cryptographic primitives, > just calling out to well-known functions like `arc4random()` or reading > from special devices like `/dev/urandom`. I would hope that Apple's > security team can spare the time to review the security-critical parts and > sign off on them, and I'd be perfectly happy to see this proposal be > approved but the final merge into the language be deferred until they've > taken a look at it. >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution