November 29th, 2018

sswg-meeting-notes
(Tanner) #1

[SSWG] November 29th, 2018

Attendance:

  • Logan Wright
  • Tanner Nelson
  • Johannes Weiss
  • Tomer Doron

Adding new members:

  • @tomerd will make a PR amending SSWG guidelines with rules for accepting new members
  • New member rules should take into consideration minimum attendance / contributions, vote requirements to accept / remove, etc
  • Ideally, new members will contribute to the “big picture” of Swift on the server

Docker updates:

  • Repo is undergoing re-licensing.
  • Waiting on the repo to be moved.
  • @IanPartridge are there any other updates here?

Logging:

  • Johannes tried increasing performance of logger when current level is silenced
  • Deciding on value vs. reference type is proving difficult
  • @tomerd will share a proof of concept implementation

Crypto:

  • SwiftNIO will likely be including private copy of BoringSSL in version 2.0
  • Frameworks relying on SwiftNIO’s COpenSSL library will need to vend their own OpenSSL implementation
  • Server-side Swift needs a good, shared Crypto implementation that everyone can rely on
    • Reach out to CryptoSwift @tanner0101
    • Pure Swift implementations have some caveats; side-channeling; debug build slowness

HTTP Client:

  • Focus on low-level client implementation that is general enough for everyone to use
  • Implementation should be capable of powering URLSession, Vapor’s HTTP client, etc
  • Higher level features can be added by frameworks
  • There are many existing implementations, we should make look carefully at these and try to take the best pieces from all of them
(Johannes Weiss) #2

they can't really vend OpenSSL (because symbol clashes) but vend BoringSSL in the same way as NIO will do or more likely use the system's OpenSSL

s/side-channeling/side-channel resistance/g

(Jeffrey Macko) #3

Have you considered libsodium as a crypto library ?

(Tanner) #4

@mackoj no, I hadn't heard of that before. Looks especially promising as the README says it even supports iOS. I would be very interested to see a proof of concept Swift package based on this. Even if it's not something NIO ends up using, this could be a nice alternative to something like vapor/crypto that relies on libssl installation.

(Cory Benfield) #5

libsodium is great. However, it is worth bearing in mind that it has a reduced feature set that mean that for a number of users it is unable to support their needs.

In general, if users are building a system that requires custom cryptographic infrastructure, my strong recommendation is to just pick up libsodium and use whatever it provides for that purpose. However, as a general-purpose cryptographic library it is just too restricted.

For example, libsodium provides the following symmetric cipher constructions:

  • AES256-GCM
  • ChaCha20 (including XChaCha and IETF variants, both separately and combined with Poly1305 as an AEAD construction)
  • Salsa20 (including XSalsa, not available as an AEAD construction)

That's it. No AES128, no AES modes other than GCM. For signatures, it provides Ed25519. For cryptographic hashing it provides BLAKE2b, SHA256, and SHA512: that's it.

In general, if you don't have a specific scheme you have to interop with, libsodium provides great constructions. Sadly it just can't be a solution to a lot of problems.