<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="">We experimented with various different approaches when doing the lower levels of Kitura. &nbsp;Ultimately, we chose to use CommonCrypto on macOS and libcrypto (from OpenSSL) on Linux for the crypto portion. &nbsp;You can see the implementation (which works on both macOS and Linux) at&nbsp;<a href="https://github.com/IBM-Swift/BlueCryptor" class="">https://github.com/IBM-Swift/BlueCryptor</a>. &nbsp;As far as the securing sockets, we chose to go with Apple Secure Transport on macOS and OpenSSL on Linux. &nbsp;This implementation can be found at&nbsp;<a href="https://github.com/IBM-Swift/BlueSSLService" class="">https://github.com/IBM-Swift/BlueSSLService</a>. &nbsp;The BlueCryptor package can be used by virtually Swift application. &nbsp;The BlueSSLService, however, is an add-on to and dependent on BlueSocket, the underlying network layer for Kitura.<div class=""><br class=""></div><div class="">In my opinion, using the Security framework on macOS is fine but to get the “beast” running on Linux may be very, very problematic. &nbsp;The underlying codebase is massive and there are bits and pieces that are missing and would have to be re-implemented. &nbsp;Another factor that led us to not use the Security framework was relatively sparse documentation. &nbsp;CommonCrypto is a much smaller subset as is Secure Transport and the mapping between them and librcrypto and OpenSSL is much cleaner and straight forward. &nbsp;Plus, as others have pointed out, an implementation taking this approach doesn’t have to worry so much about FIPS certification since the underlying platform implementation are already certified.<br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Nov 7, 2016, at 10:31 AM, Zach Drayer via swift-server-dev &lt;<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 7, 2016, at 2:45 PM, Helge Heß via swift-server-dev &lt;<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 07 Nov 2016, at 13:48, Zach Drayer &lt;<a href="mailto:zachary.drayer@gmail.com" class="">zachary.drayer@gmail.com</a>&gt; wrote:<br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev &lt;<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>&gt; 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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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&nbsp;<a href="https://developer.apple.com/security/" class="">https://developer.apple.com/security/</a>&nbsp;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 class=""><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 class=""><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 class=""><br class=""></div><div class="">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 class=""><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 class="">These seem like excellent use cases to consider, thank you for bringing them up! Reading through&nbsp;<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 class=""><br class=""></div><div class="">-z</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-server-dev mailing list<br class=""><a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""></div></blockquote></div><br class=""></body></html>