<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="">Hi all, what about the crypto library <a href="https://github.com/krzyzanowskim/CryptoSwift" class="">https://github.com/krzyzanowskim/CryptoSwift</a>, It’s pure swift<br class=""><div><blockquote type="cite" class=""><div class="">在 2016年11月9日，02:00，<a href="mailto:swift-server-dev-request@swift.org" class="">swift-server-dev-request@swift.org</a> 写道：</div><br class="Apple-interchange-newline"><div class=""><div class="">Send swift-server-dev mailing list submissions to<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a><br class=""><br class="">To subscribe or unsubscribe via the World Wide Web, visit<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://lists.swift.org/mailman/listinfo/swift-server-dev<br class="">or, via email, send a message with subject or body 'help' to<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>swift-server-dev-request@swift.org<br class=""><br class="">You can reach the person managing the list at<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>swift-server-dev-owner@swift.org<br class=""><br class="">When replying, please edit your Subject line so it is more specific<br class="">than "Re: Contents of swift-server-dev digest..."<br class=""><br class=""><br class="">Today's Topics:<br class=""><br class=""> 1. Re: Crypto Library (Zach Drayer)<br class=""> 2. Re: Crypto Library (Zach Drayer)<br class=""> 3. Re: Crypto Library (Bill Abt)<br class=""> 4. Re: Crypto Library (Brent Royal-Gordon)<br class=""> 5. Re: HTTP Parser (Thiago Holanda)<br class=""> 6. Re: Crypto Library (Chris Bailey)<br class=""> 7. Re: Crypto Library (Joannis Orlandos)<br class=""><br class=""><br class="">----------------------------------------------------------------------<br class=""><br class="">Message: 1<br class="">Date: Mon, 7 Nov 2016 12:48:58 +0000<br class="">From: Zach Drayer <zachary.drayer@gmail.com><br class="">To: Helge Heß <me@helgehess.eu>, swift-server-dev@swift.org<br class="">Subject: Re: [swift-server-dev] Crypto Library<br class="">Message-ID: <D043B4C9-66B6-4D30-B735-018AFD036838@gmail.com><br class="">Content-Type: text/plain; charset="utf-8"<br class=""><br class=""><forking "HTTP Parser", thanks for reading and/or sorry in advance for any for threading issues that crop up><br class=""><br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev <swift-server-dev@swift.org> wrote:<br class=""><br 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=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""></blockquote><br class="">Assuming we want a pure-Swift crypto framework _right now_:<br class=""><br class="">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). <br class=""><br class="">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.<br class=""><br class="">So, I don't think we really want a pure Swift crypto library yet.<br class=""><br class="">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).<br class=""><br 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="">- 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)<br class="">- 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.<br class="">- ??? other exciting things to consider here<br class=""><br class="">-z<br class="">-------------- next part --------------<br class="">An HTML attachment was scrubbed...<br class="">URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161107/8a3aab09/attachment-0001.html><br class=""><br class="">------------------------------<br class=""><br class="">Message: 2<br class="">Date: Mon, 7 Nov 2016 15:31:10 +0000<br class="">From: Zach Drayer <zachary.drayer@gmail.com><br class="">To: Helge Heß <me@helgehess.eu><br class="">Cc: Swift Server Dev <swift-server-dev@swift.org><br class="">Subject: Re: [swift-server-dev] Crypto Library<br class="">Message-ID: <B2FB0028-4AE2-48B7-9EE2-24342C2FB013@gmail.com><br class="">Content-Type: text/plain; charset="utf-8"<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 2:45 PM, Helge Heß via swift-server-dev <swift-server-dev@swift.org> wrote:<br class=""><br class="">On 07 Nov 2016, at 13:48, Zach Drayer <zachary.drayer@gmail.com> wrote:<br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev <swift-server-dev@swift.org> 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=""></blockquote><br 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.<br class=""><br 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 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).<br class=""><br class=""><blockquote type="cite" 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=""></blockquote><br class="">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>).<br class=""><br 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?<br class=""><br class=""><blockquote type="cite" 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=""></blockquote><br class="">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.<br class=""><br class="">-z<br class=""><br class="">-------------- next part --------------<br class="">An HTML attachment was scrubbed...<br class="">URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161107/54a3ef77/attachment-0001.html><br class=""><br class="">------------------------------<br class=""><br class="">Message: 3<br class="">Date: Mon, 07 Nov 2016 13:48:22 -0500<br class="">From: Bill Abt <babt@me.com><br class="">To: Swift Server Dev <swift-server-dev@swift.org><br class="">Subject: Re: [swift-server-dev] Crypto Library<br class="">Message-ID: <9BAD41B0-4E48-4DB3-AD87-FA421D467A42@me.com><br class="">Content-Type: text/plain; charset="utf-8"<br class=""><br class="">We experimented with various different approaches when doing the lower levels of Kitura. Ultimately, we chose to use CommonCrypto on macOS and libcrypto (from OpenSSL) on Linux for the crypto portion. You can see the implementation (which works on both macOS and Linux) at https://github.com/IBM-Swift/BlueCryptor <https://github.com/IBM-Swift/BlueCryptor>. As far as the securing sockets, we chose to go with Apple Secure Transport on macOS and OpenSSL on Linux. This implementation can be found at https://github.com/IBM-Swift/BlueSSLService <https://github.com/IBM-Swift/BlueSSLService>. The BlueCryptor package can be used by virtually Swift application. The BlueSSLService, however, is an add-on to and dependent on BlueSocket, the underlying network layer for Kitura.<br class=""><br 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. The underlying codebase is massive and there are bits and pieces that are missing and would have to be re-implemented. Another factor that led us to not use the Security framework was relatively sparse documentation. 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. 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=""><br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 10:31 AM, Zach Drayer via swift-server-dev <swift-server-dev@swift.org> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 2:45 PM, Helge Heß via swift-server-dev <swift-server-dev@swift.org <mailto:swift-server-dev@swift.org>> wrote:<br class=""><br class="">On 07 Nov 2016, at 13:48, Zach Drayer <zachary.drayer@gmail.com <mailto:zachary.drayer@gmail.com>> wrote:<br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev <swift-server-dev@swift.org <mailto:swift-server-dev@swift.org>> 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=""></blockquote><br 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.<br class=""><br 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 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).<br class=""><br class=""><blockquote type="cite" 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=""></blockquote><br class="">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>).<br class=""><br 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?<br class=""><br class=""><blockquote type="cite" 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=""></blockquote><br class="">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.<br class=""><br class="">-z<br class=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""></blockquote><br class="">-------------- next part --------------<br class="">An HTML attachment was scrubbed...<br class="">URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161107/6c3ead79/attachment-0001.html><br class=""><br class="">------------------------------<br class=""><br class="">Message: 4<br class="">Date: Mon, 7 Nov 2016 11:54:21 -0800<br class="">From: Brent Royal-Gordon <brent@architechies.com><br class="">To: Matt DeFoor <mattdefoor@gmail.com><br class="">Cc: swift-server-dev@swift.org<br class="">Subject: Re: [swift-server-dev] Crypto Library<br class="">Message-ID: <AD308EF0-7DBA-469D-BDD3-6F1189F38EAC@architechies.com><br class="">Content-Type: text/plain; charset=utf-8<br class=""><br class=""><blockquote type="cite" class="">On Nov 7, 2016, at 7:49 AM, Matt DeFoor via swift-server-dev <swift-server-dev@swift.org> wrote:<br class=""><br class="">Ultimately, I think we'll want to stick with the known crypto libraries and frameworks that are compliant with FIPS 140-2 Level 1 until a decision can be made around the need/desire for a pure-Swift implementation and sponsor(s) for obtaining the validation. There are going to come cases where some software or perhaps embedded hardware that use Swift for crypto purposes will require FIPS 140-2 Level 1 validation.<br class=""><br class="">Then again, perhaps FIPS isn't a concern for people at all. If so, please disregard :)<br class=""></blockquote><br class="">I'm not familiar with the specifics of the FIPS requirements, but naïvely, this sounds like a good case for some abstraction. If we define general protocols for crypto modules and conform both Darwin security and LibreSSL APIs to them, you'll be able to switch between FIPS-compliant and open-source implementations without rewriting any code.<br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class=""><br class=""><br class="">------------------------------<br class=""><br class="">Message: 5<br class="">Date: Tue, 8 Nov 2016 10:01:02 -0200<br class="">From: Thiago Holanda <unnamedd@gmail.com><br class="">To: James Lei <proyb7@gmail.com><br class="">Cc: swift-server-dev@swift.org<br class="">Subject: Re: [swift-server-dev] HTTP Parser<br class="">Message-ID:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><CACDpt5VCsvbAe3i9sMqHa6AUW+gWfZ4khfL9vcS6LjRycQAA0w@mail.gmail.com><br class="">Content-Type: text/plain; charset="utf-8"<br class=""><br class="">Hi James, the early adopters form Swift Server APIs will be the<br class="">stakeholders team or who want to test what the steering team develop.<br class=""><br class=""><br class="">TH<br class=""><br class="">-------------- next part --------------<br class="">An HTML attachment was scrubbed...<br class="">URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161108/c59c1cf7/attachment-0001.html><br class=""><br class="">------------------------------<br class=""><br class="">Message: 6<br class="">Date: Tue, 8 Nov 2016 15:45:50 +0000<br class="">From: Chris Bailey <BAILEYC@uk.ibm.com><br class="">To: Bill Abt <babt@me.com><br class="">Cc: Swift Server Dev <swift-server-dev@swift.org><br class="">Subject: Re: [swift-server-dev] Crypto Library<br class="">Message-ID:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><OFDEE7346B.4FB7B287-ON80258065.00541210-80258065.005697A9@notes.na.collabserv.com><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class="">Content-Type: text/plain; charset="utf-8"<br class=""><br class="">Whilst there's legitimate debate on the use of C vs. Swift for HTTP <br class="">parsing, I think the situation for the security libraries in general is <br class="">more clear.<br class=""><br class="">We've effectively got four choices on how to do the underlying <br class="">implementation of the security APIs:<br class="">Use OpenSSL/LibreSSL everywhere<br class="">The challenge his is iOS devices, where there is no support for <br class="">OpenSSL/LibreSSL. There's likely also an argument that using <br class="">OpenSSL/LibreSSL will be a regressive move for macOS users vs. the Apple <br class="">libraries that have been optimized for the platform. Additionally there <br class="">may be a granularity issue - we'd the Apple libraries are deliberately <br class="">broken into three libraries and we'd need to reflect that from <br class="">OpenSSL/LibreSSL. I think that means we at least have to have a "hybrid" <br class="">model of using the Apple libraries on macOS/iOS, and OpenSSL/LibreSSL <br class="">elsewhere<br class="">Use the Apple security libraries everywhere<br class="">This three libraries are a significant body of work, and based on the <br class="">effort required to port libdispatch to Linux, I would estimate that a <br class="">considerable amount of porting work. There would then be secondary <br class="">challenges on how we respond to security vulnerabilities on the new <br class="">platforms, and the effort and cost of trying to get FIPS compliance for <br class="">the new libraries on each platforms<br class="">Use a hybrid of Apple security libraries on macOS/iOS and OpenSSL/LibreSSL <br class="">elsewhere<br class="">This leverages existing "defacto standard" libraries on each platform, <br class="">where things like FIPS compliance certification already exists, and teams <br class="">already have a track record of responding to security vulnerabilities. <br class="">There is a challenge though on how we isolate/abstract the user away from <br class="">the differences between the libraries - particularly for things like <br class="">certificate handling and configuration.<br class="">Create a pure-Swift implementation<br class="">The implementation of OpenSSL is ~350K lines of code, which is a sizeable <br class="">amount of function to implement, and most importantly, to get right and do <br class="">rigorous security vulnerability testing for. Once done, we will then have <br class="">to react rapidly to any reported vulnerabilities and do the full set of <br class="">work and cost to get FIPS compliance certification. <br class=""><br class="">For me, this points to option #3 as the most viable solution - and <br class="">therefore the first that we should investigate.<br class=""><br class=""><br class="">Chris<br class=""><br class=""><br class=""><br class=""><br class="">From: Bill Abt via swift-server-dev <swift-server-dev@swift.org><br class="">To: Swift Server Dev <swift-server-dev@swift.org><br class="">Date: 07/11/2016 18:48<br class="">Subject: Re: [swift-server-dev] Crypto Library<br class="">Sent by: swift-server-dev-bounces@swift.org<br class=""><br class=""><br class=""><br class="">We experimented with various different approaches when doing the lower <br class="">levels of Kitura. Ultimately, we chose to use CommonCrypto on macOS and <br class="">libcrypto (from OpenSSL) on Linux for the crypto portion. You can see the <br class="">implementation (which works on both macOS and Linux) at <br class="">https://github.com/IBM-Swift/BlueCryptor. As far as the securing sockets, <br class="">we chose to go with Apple Secure Transport on macOS and OpenSSL on Linux. <br class="">This implementation can be found at <br class="">https://github.com/IBM-Swift/BlueSSLService. The BlueCryptor package can <br class="">be used by virtually Swift application. The BlueSSLService, however, is <br class="">an add-on to and dependent on BlueSocket, the underlying network layer for <br class="">Kitura.<br class=""><br class="">In my opinion, using the Security framework on macOS is fine but to get <br class="">the “beast” running on Linux may be very, very problematic. The <br class="">underlying codebase is massive and there are bits and pieces that are <br class="">missing and would have to be re-implemented. Another factor that led us <br class="">to not use the Security framework was relatively sparse documentation. <br class="">CommonCrypto is a much smaller subset as is Secure Transport and the <br class="">mapping between them and librcrypto and OpenSSL is much cleaner and <br class="">straight forward. Plus, as others have pointed out, an implementation <br class="">taking this approach doesn’t have to worry so much about FIPS <br class="">certification since the underlying platform implementation are already <br class="">certified.<br class=""><br class="">On Nov 7, 2016, at 10:31 AM, Zach Drayer via swift-server-dev <<br class="">swift-server-dev@swift.org> wrote:<br class=""><br class=""><br class="">On Nov 7, 2016, at 2:45 PM, Helge Heß via swift-server-dev <<br class="">swift-server-dev@swift.org> wrote:<br class=""><br class="">On 07 Nov 2016, at 13:48, Zach Drayer <zachary.drayer@gmail.com> wrote:<br class="">On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev <<br class="">swift-server-dev@swift.org> wrote:<br class="">P.S.: As a sidenote, can’t someone (hm hm, who would come to mind?) <br class="">sponsor the CryptoSwift guy to do a java.security like Security standard <br class="">framework (which includes TLS)? That would be pretty cool :-)<br class=""><br class="">Instead: while in C, Security.framework, and CommonCrypto.framework from <br class=""> are both fully open source, and battle-hardened.<br class=""><br class="">Do they provide a clean Linux story too? (.framework in the name kinda <br class="">suggests they don’t :-)<br class=""><br class="">Do they work with non-blocking I/O? The API read/write/handshake API <br class="">suggests that they may not?<br class=""><br class="">Looks like the approach people currently use is either Security.framework <br class="">on Darwin and Open/LibreSSL on other platforms, or using OpenSSL on both. <br class="">Some even forking OpenSSL.<br class=""><br class="">Good question. My assumption was “yes, of course”, but, it looks like that <br class="">isn’t correct in the way I expected it to be.<br class=""><br class="">CommonCrypto looks like it makes some assumptions about Darwin (e.g. <br class="">importing TargetConditionals or Availability.h) but looking one level <br class="">deeper, we find `corecrypto` at the bottom of <br class="">https://developer.apple.com/security/ that is also open source, is what <br class="">underlies CommonCrypto + Security, and, has the necessary `#if`s to build <br class="">on Linux (even if it is lacking a Makefile at the moment).<br class=""><br class="">This is one of (rare) the cases where practicality and strongly deferring <br class="">to the thing that already exists seem to be the safe option (and not only <br class="">in opinion).<br class=""><br class="">This is all true, but then someone also thought it makes sense to have <br class="">Security.framework despite OpenSSL being available. Or java.security. Or <br class="">Windows SChannel/security. Just saying …<br class=""><br class="">The thing which makes a pure-Swift thing attractive is that it would be <br class="">cross platform and readily available. The C libs are really diverse <br class="">between the platforms and forking OpenSSL into an embedded module is not <br class="">exactly 1337 either.<br class=""><br class="">No disagreement that there are a number of benefits to living in a pure <br class="">Swift world, but as mentioned earlier: this may not be possible yet. There <br class="">is little point in providing a security/crypto library that can’t be <br class="">trusted — and with cryptography, the requirement for trust extends far <br class="">beyond “does it compile?, or even “do all the tests pass?”. We don’t want <br class="">another heartbleed, or a predictable PRNG (<br class="">https://github.com/g0tmi1k/debian-ssh).<br class=""><br class="">But, I don’t know. Maybe the solution isn’t corecrypto, but is <br class="">LibreSSL/OpenSSL, or, something else. Maybe adding compiler support for <br class="">Crypto tasks is already done (or easy enough to do) and my argument is <br class="">moot. Thats why we’re having this discussion, right?<br class=""><br class="">Anyway, (to me) the more interesting questions that we can talk about are <br class="">over API:<br class="">- what constructs are needed (bignum? secure random? hmac? checksumming? <br class="">key derivation? wrapping a socket in a big TLS hug?)<br class=""><br class="">The thing I need and which is a little awkward to get is async TLS, both <br class="">client and server. I started working on an OpenSSL BIO and see whether I <br class="">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=""><br class="">These seem like excellent use cases to consider, thank you for bringing <br class="">them up! Reading through https://swift.org/server-apis/, the section on <br class="">"Security and Encryption”, definitely indicates that this is the right <br class="">place to talk about these needs.<br class=""><br class="">-z<br class=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""><br class=""><br class=""><br class="">-------------- next part --------------<br class="">An HTML attachment was scrubbed...<br class="">URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161108/e4040bb6/attachment-0001.html><br class=""><br class="">------------------------------<br class=""><br class="">Message: 7<br class="">Date: Tue, 8 Nov 2016 17:55:15 +0100<br class="">From: Joannis Orlandos <joannis@orlandos.nl><br class="">To: Swift Server Dev <swift-server-dev@swift.org><br class="">Subject: Re: [swift-server-dev] Crypto Library<br class="">Message-ID: <D8F1F92A-039A-4404-8D2C-606D80DA651D@orlandos.nl><br class="">Content-Type: text/plain; charset="utf-8"<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 8 Nov 2016, at 17:54, Joannis Orlandos <joannis@orlandos.nl> wrote:<br class=""><br class="">I think option #3 is the most viable but you seem to partially overestimate the amount of work that you'd have to put into a Swift variant to OpenSSL. LibreSSL, which does not contain a lot of legacy code, is ~200K lines of code which is a lot less than your OpenSSL figures. And in Swift we can probably be a lot more expressive in our statements so I think 180K would be a feature complete SSL implementation.<br class=""><br class="">I think the FIPS compliance certification is going to be the toughest part. The API for the cryptography will have to be designed regardless of point 3 and 4 which I think would result in 150k lines of code that will have to be written specifically for point 4. It's not exactly unthinkable to write Swift Cryptography. The Vapor framework already counts 60k lines of code which is build by two people primarily but I think it's probably not worth the effort/maintenance at this scale to build a pure swift SSL implementation, at least initially.<br class=""><br class="">Joannis<br class=""><br class=""><blockquote type="cite" class="">On 8 Nov 2016, at 16:45, Chris Bailey via swift-server-dev <swift-server-dev@swift.org <mailto:swift-server-dev@swift.org>> wrote:<br class=""><br class="">Whilst there's legitimate debate on the use of C vs. Swift for HTTP parsing, I think the situation for the security libraries in general is more clear. <br class=""><br class="">We've effectively got four choices on how to do the underlying implementation of the security APIs:<br class="">Use OpenSSL/LibreSSL everywhere<br class="">The challenge his is iOS devices, where there is no support for OpenSSL/LibreSSL. There's likely also an argument that using OpenSSL/LibreSSL will be a regressive move for macOS users vs. the Apple libraries that have been optimized for the platform. Additionally there may be a granularity issue - we'd the Apple libraries are deliberately broken into three libraries and we'd need to reflect that from OpenSSL/LibreSSL. I think that means we at least have to have a "hybrid" model of using the Apple libraries on macOS/iOS, and OpenSSL/LibreSSL elsewhere<br class="">Use the Apple security libraries everywhere<br class="">This three libraries are a significant body of work, and based on the effort required to port libdispatch to Linux, I would estimate that a considerable amount of porting work. There would then be secondary challenges on how we respond to security vulnerabilities on the new platforms, and the effort and cost of trying to get FIPS compliance for the new libraries on each platforms<br class="">Use a hybrid of Apple security libraries on macOS/iOS and OpenSSL/LibreSSL elsewhere<br class="">This leverages existing "defacto standard" libraries on each platform, where things like FIPS compliance certification already exists, and teams already have a track record of responding to security vulnerabilities. There is a challenge though on how we isolate/abstract the user away from the differences between the libraries - particularly for things like certificate handling and configuration.<br class="">Create a pure-Swift implementation<br class="">The implementation of OpenSSL is ~350K lines of code, which is a sizeable amount of function to implement, and most importantly, to get right and do rigorous security vulnerability testing for. Once done, we will then have to react rapidly to any reported vulnerabilities and do the full set of work and cost to get FIPS compliance certification.<br class=""><br class="">For me, this points to option #3 as the most viable solution - and therefore the first that we should investigate. <br class=""><br class=""><br class="">Chris<br class=""><br class=""><br class=""><br class=""><br class="">From: Bill Abt via swift-server-dev <swift-server-dev@swift.org <mailto:swift-server-dev@swift.org>> <br class="">To: Swift Server Dev <swift-server-dev@swift.org <mailto:swift-server-dev@swift.org>> <br class="">Date: 07/11/2016 18:48 <br class="">Subject: Re: [swift-server-dev] Crypto Library <br class="">Sent by: swift-server-dev-bounces@swift.org <mailto:swift-server-dev-bounces@swift.org> <br class=""><br class=""><br class=""><br class="">We experimented with various different approaches when doing the lower levels of Kitura. Ultimately, we chose to use CommonCrypto on macOS and libcrypto (from OpenSSL) on Linux for the crypto portion. You can see the implementation (which works on both macOS and Linux) at https://github.com/IBM-Swift/BlueCryptor <https://github.com/IBM-Swift/BlueCryptor>. As far as the securing sockets, we chose to go with Apple Secure Transport on macOS and OpenSSL on Linux. This implementation can be found at https://github.com/IBM-Swift/BlueSSLService <https://github.com/IBM-Swift/BlueSSLService>. The BlueCryptor package can be used by virtually Swift application. The BlueSSLService, however, is an add-on to and dependent on BlueSocket, the underlying network layer for Kitura. <br class=""><br 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. The underlying codebase is massive and there are bits and pieces that are missing and would have to be re-implemented. Another factor that led us to not use the Security framework was relatively sparse documentation. 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. 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=""><br class="">On Nov 7, 2016, at 10:31 AM, Zach Drayer via swift-server-dev <swift-server-dev@swift.org <mailto:swift-server-dev@swift.org>> wrote: <br class=""><br class=""><br class="">On Nov 7, 2016, at 2:45 PM, Helge Heß via swift-server-dev <swift-server-dev@swift.org <mailto:swift-server-dev@swift.org>> wrote: <br class=""><br class="">On 07 Nov 2016, at 13:48, Zach Drayer <zachary.drayer@gmail.com <mailto:zachary.drayer@gmail.com>> wrote: <br class="">On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev <swift-server-dev@swift.org <mailto:swift-server-dev@swift.org>> wrote: <br 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=""><br class="">Instead: while in C, Security.framework, and CommonCrypto.framework from are both fully open source, and battle-hardened. <br class=""><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=""><br 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. <br class=""><br 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 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). <br class=""><br 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=""><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=""><br class="">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>). <br class=""><br 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? <br class=""><br 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=""><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=""><br class="">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. <br class=""><br class="">-z <br class=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org <mailto:swift-server-dev@swift.org><br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev> <br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org <mailto:swift-server-dev@swift.org><br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev><br class=""><br class=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org <mailto:swift-server-dev@swift.org><br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""></blockquote><br class=""></blockquote><br class="">-------------- next part --------------<br class="">An HTML attachment was scrubbed...<br class="">URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161108/cefd512d/attachment-0001.html><br class=""><br class="">------------------------------<br class=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""><br class=""><br class="">End of swift-server-dev Digest, Vol 2, Issue 8<br class="">**********************************************<br class=""></div></div></blockquote></div><br class=""></body></html>