[swift-server-dev] Crypto Library

[Zach Drayer]

<forking "HTTP Parser", thanks for reading and/or sorry in advance for any for threading issues that crop up>

> On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> P.S.: As a sidenote, can’t someone (hm hm, who would come to mind?) sponsor the CryptoSwift guy to do a java.security like Security standard framework (which includes TLS)? That would be pretty cool :-)
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

Assuming we want a pure-Swift crypto framework _right now_:

Before any crypto code can safely be written in Swift, there needs to be compiler support to prevent it from optimizing things incorrectly (for example, a memset() designed to clear a buffer of secret data). 

I may have missed discussions about this on swift-evolution (and maybe swift-server-dev is a place to flesh out a SE proposal to send their way?), but, i'm not sure if all that work's been scoped out anywhere, or if it has, what the timeframe is. ABI stability might even be a soft requirement here before anyone can reasonably get started on this.

So, I don't think we really want a pure Swift crypto library yet.

Instead: while in C, Security.framework, and CommonCrypto.framework from  are both fully open source, and battle-hardened. This is one of (rare) the cases where practicality and strongly deferring to the thing that already exists seem to be the safe option (and not only in opinion).

Anyway, (to me) the more interesting questions that we can talk about are over API:
- what constructs are needed (bignum? secure random? hmac? checksumming? key derivation? wrapping a socket in a big TLS hug?)
- what umbrella(s) do these constructs live in? (maybe bignum is in separate framework, or hugging sockets with TLS is an i/o construct rather than a crypto construct, or.. etc)
- is there anything to explicitly not support? securing a socket with sslv2 and sslv3 seem like obvious candidates here, but maybe the API is even more opinionated and doesn't let you create weak RSA keys, etc.
- ??? other exciting things to consider here

-z
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161107/8a3aab09/attachment.html>