<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 7, 2016, at 2:45 PM, Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 07 Nov 2016, at 13:48, Zach Drayer <<a href="mailto:zachary.drayer@gmail.com" class="">zachary.drayer@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">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 :-)<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class="">Instead: while in C, Security.framework, and CommonCrypto.framework from are both fully open source, and battle-hardened.<br class=""></blockquote><br class="">Do they provide a clean Linux story too? (.framework in the name kinda suggests they don’t :-)<br class=""><br class="">Do they work with non-blocking I/O? The API read/write/handshake API suggests that they may not?<br class=""><br class="">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.<br class=""></div></div></blockquote><div><br class=""></div><div>Good question. My assumption was “yes, of course”, but, it looks like that isn’t correct in the way I expected it to be.</div><div><br class=""></div><div>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 <a href="https://developer.apple.com/security/" class="">https://developer.apple.com/security/</a> 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).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">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).<br class=""></blockquote><br class="">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 …<br class=""><br class="">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.<br class=""></div></div></blockquote><div><br class=""></div>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 (<a href="https://github.com/g0tmi1k/debian-ssh" class="">https://github.com/g0tmi1k/debian-ssh</a>).</div><div><br class=""></div><div>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?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">Anyway, (to me) the more interesting questions that we can talk about are over API:<br class="">- what constructs are needed (bignum? secure random? hmac? checksumming? key derivation? wrapping a socket in a big TLS hug?)<br class=""></blockquote><br class="">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.<br class=""><br class="">For the hashes that I needed so far (just MD5 and SHA1) I use CryptoSwift.<br class=""></div></div></blockquote><br class=""></div><div>These seem like excellent use cases to consider, thank you for bringing them up! Reading through <a href="https://swift.org/server-apis/" class="">https://swift.org/server-apis/</a>, the section on "Security and Encryption”, definitely indicates that this is the right place to talk about these needs.</div><div><br class=""></div><div class="">-z</div><div class=""><br class=""></div></body></html>