[swift-evolution] [Proposal] Random Unification
xiaodi.wu at gmail.com
Sat Dec 2 15:08:46 CST 2017
On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon <brent at architechies.com>
> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution