[swift-server-dev] Crypto Library

[Matt DeFoor]

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.

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.

For those curious about OpenSSL and FIPS, see the following:

https://www.openssl.org/docs/fipsnotes.html

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.

Then again, perhaps FIPS isn't a concern for people at all. If so, please
disregard :)

Sorry if this was already addressed in the Security meeting.

Cheers,
Matt

On Mon, Nov 7, 2016 at 9:45 AM, Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:

> 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
>
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161107/2c772dcc/attachment.html>