[swift-server-dev] Crypto Library

[Zach Drayer]

> On Nov 7, 2016, at 2:45 PM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> On 07 Nov 2016, at 13:48, Zach Drayer <zachary.drayer at gmail.com> wrote:
>> 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 :-)
> 
>> Instead: while in C, Security.framework, and CommonCrypto.framework from  are both fully open source, and battle-hardened.
> 
> Do they provide a clean Linux story too? (.framework in the name kinda suggests they don’t :-)
> 
> Do they work with non-blocking I/O? The API read/write/handshake API suggests that they may not?
> 
> Looks like the approach people currently use is either Security.framework on Darwin and Open/LibreSSL on other platforms, or using OpenSSL on both. Some even forking OpenSSL.

Good question. My assumption was “yes, of course”, but, it looks like that isn’t correct in the way I expected it to be.

CommonCrypto looks like it makes some assumptions about Darwin (e.g. importing TargetConditionals or Availability.h) but looking one level deeper, we find `corecrypto` at the bottom of https://developer.apple.com/security/ <https://developer.apple.com/security/> that is also open source, is what underlies CommonCrypto + Security, and, has the necessary `#if`s to build on Linux (even if it is lacking a Makefile at the moment).

>> 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).
> 
> This is all true, but then someone also thought it makes sense to have Security.framework despite OpenSSL being available. Or java.security. Or Windows SChannel/security. Just saying …
> 
> The thing which makes a pure-Swift thing attractive is that it would be cross platform and readily available. The C libs are really diverse between the platforms and forking OpenSSL into an embedded module is not exactly 1337 either.

No disagreement that there are a number of benefits to living in a pure Swift world, but as mentioned earlier: this may not be possible yet. There is little point in providing a security/crypto library that can’t be trusted — and with cryptography, the requirement for trust extends far beyond “does it compile?, or even “do all the tests pass?”. We don’t want another heartbleed, or a predictable PRNG (https://github.com/g0tmi1k/debian-ssh <https://github.com/g0tmi1k/debian-ssh>).

But, I don’t know. Maybe the solution isn’t corecrypto, but is LibreSSL/OpenSSL, or, something else. Maybe adding compiler support for Crypto tasks is already done (or easy enough to do) and my argument is moot. Thats why we’re having this discussion, right?

>> 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?)
> 
> The thing I need and which is a little awkward to get is async TLS, both client and server. I started working on an OpenSSL BIO and see whether I can get that running on top of GCD, looks like it should be possible.
> 
> For the hashes that I needed so far (just MD5 and SHA1) I use CryptoSwift.

These seem like excellent use cases to consider, thank you for bringing them up! Reading through https://swift.org/server-apis/ <https://swift.org/server-apis/>, the section on "Security and Encryption”, definitely indicates that this is the right place to talk about these needs.

-z

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