<div dir="ltr">Keep in mind that some consumers of a crypto library need compliance with FIPS 140-2 Level 1. Writing a crypto library and obtaining the necessary FIPS validation certificate can be an expensive and time-consuming process. A pure-Swift library would be no different in this regard if there is a need for compliance with FIPS 140-2 Level 1.<div><br></div><div>Since Security.framework and CommonCrypto.framework are already FIPS 140-2 Level 1 certified, it would seem that those would be reasonable targets for wrapping on Darwin. However, other platforms (with the exception of Windows which has it's own FIPS certified crypto library) would likely need to be based on Open/LibreSSL. Some commercially available Linux distros provide a certified OpenSSL FIPS object module. In addition, for those that can get by with a private label validation, compiling your own FIPS object module is an alternative. Keep in mind that LibreSSL completely removed it's support for the FIPS object module.</div><div><br></div><div>For those curious about OpenSSL and FIPS, see the following:</div><div><br></div><div><a href="https://www.openssl.org/docs/fipsnotes.html" target="_blank">https://www.openssl.org/docs/<wbr>fipsnotes.html</a><br></div><div><br></div><div>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.</div><div><br></div><div>Then again, perhaps FIPS isn't a concern for people at all. If so, please disregard :)<br></div><div><br></div><div>Sorry if this was already addressed in the Security meeting.</div><div><br></div><div>Cheers,</div><div>Matt</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 7, 2016 at 9:45 AM, Helge Heß via swift-server-dev <span dir="ltr"><<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 07 Nov 2016, at 13:48, Zach Drayer <<a href="mailto:zachary.drayer@gmail.com" target="_blank">zachary.drayer@gmail.com</a>> wrote:<br>
> On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:<br>
>> 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>
><br>
> Assuming we want a pure-Swift crypto framework _right now_:<br>
><br>
> 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>
<br>
OK.<br>
<br>
> So, I don't think we really want a pure Swift crypto library yet.<br>
<br>
OK.<br>
<br>
> Instead: while in C, Security.framework, and CommonCrypto.framework from are both fully open source, and battle-hardened.<br>
<br>
Do they provide a clean Linux story too? (.framework in the name kinda suggests they don’t :-)<br>
<br>
Do they work with non-blocking I/O? The API read/write/handshake API suggests that they may not?<br>
<br>
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>
<br>
<br>
> 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>
<br>
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>
<br>
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>
<br>
<br>
> Anyway, (to me) the more interesting questions that we can talk about are over API:<br>
> - what constructs are needed (bignum? secure random? hmac? checksumming? key derivation? wrapping a socket in a big TLS hug?)<br>
<br>
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>
<br>
For the hashes that I needed so far (just MD5 and SHA1) I use CryptoSwift.<br>
<span class="gmail-m_6393401827337963027HOEnZb"><font color="#888888"><br>
hh<br>
<br>
</font></span><br>______________________________<wbr>_________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-server-dev</a><br>
<br></blockquote></div><br></div></div>