[swift-server-dev] Crypto Library

[Helge Heß]

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 :-)
> 
> 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).

OK.

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

OK.

> 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.


> 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.


> 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.

hh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161107/888a56f2/attachment.sig>