[montyedwards]

I'm currently evaluating LibreSSL for use in data protection software I licensed to a large company.

The optional libtls API bundled with LibreSSL is a really simple wrapper API that is secure by default. And it was a breeze to build on Windows because they use cmake (just need to download released bundle rather than from git to avoid problems.) A couple of the optional libtls functions don't work on Windows (tls_load_file), but 100% of OpenSSL-1.0.1+ api functions I tried so far worked fine.

For me, the biggest downside is LibreSSL doesn't support X25519 yet, while BoringSSL and OpenSSL both support it. And BoringSSL is starting to get easier to use with other software like nginx without messy patches.

Hopefully, X25519 will be added as a beta feature during LibreSSL 2.5.x and released as stable in 2.6.

If you have time, take a look at https://github.com/libressl-portable/openbsd

And email patches to: [e-mail]

Edited: tls_load_file instead of tls_read

[jamiesonbecker]

> LibreSSL doesn't support X25519 yet

ouch, that's pretty core. (We use it for storage crypto in the Userify on-prem server [ssh key/sudo management] management servers, although the managed nodes themselves just use 'regular' TLS/https for communication.) That means we can't switch to Alpine pretty soon, which I was contemplating for our AWS Marketplace instances in order to move to a distro with a smaller footprint. (X25519 is also the default between Chrome and web servers: https://www.chromestatus.com/feature/5682529109540864 )

Any idea on when X25519 will be added?

[xoa]

I too would definitely be interested if there's any sort of milestone planned for X25519. There are a couple of open enhancement requests on it in both openbsd and portable [1,2] dating to before ratification of RFC 7748 (or Chrome 50), but no assignees yet. I also don't see any discussion on the libressl public mailing list archives at marc.info, though I'm not sure if that's complete. It seems like it may become an ever bigger breaking issue for a lot of folks as support becomes more widespread following standardization, inclusion in OpenSSL 1.1.0, and increasing major browser/OS support.

1. https://github.com/libressl-portable/portable/issues/114 2. https://github.com/libressl-portable/openbsd/issues/58

[montyedwards]

No idea when LibreSSL will add X25519 or X448, as defined in RFC 7748 - Elliptic Curves for Security.

Here's RFC 7748 https://tools.ietf.org/html/rfc7748

Here's the errata for RFC 7748 https://www.rfc-editor.org/errata_search.php?rfc=7748

[stock_toaster]

  > (X25519 is also the default between Chrome and
  > web servers: https://www.chromestatus.com/feature/5682529109540864 )

I thought chacha20/poly was the default. That's what I get when I connect to https://www.google.com with chrome (chrome-53) at any rate.

[wolf550e]

TLS cipher suites have five parts:

  1. key exchange:
    PSK - for embedded only
    RSA - obsolete because it doesn't provide PFS
    DHE - secure only if 2048 bits and up
    ECDHE - usually using P-256, secure
    ECDHE with Curve25519, called "X25519" - secure
    CECPQ1 - Google experiment in post quantum crypto
  2. authentication:
    PSK - for embedded only
    RSA encryption/decryption - obsolete because it doesn't provide PFS
    RSA signing and verification - secure if keys are 2048 bits and up
    ECDSA signing and verification - usually over P-256, secure
    EdDSA signing and verification - draft standard, uses Curve25519 and Curve448, secure
  3. cipher (for confidentiality):
    RC4 - disallowed
    3DES - obsolete because of sweet32
    AES-128 - good, requires AES hardware to be both fast and secure
    AES-256 - same as AES-128 but is required for post-quantum and against parallel attacks on many keys
    CHACHA20 - good, is fast on generic hardware
  4. MAC (to protect against tampering which usually breaks confidentiality):
    HMAC-MD5 - obsolete
    HMAC-SHA1 - ok
    HMAC-SHA256 and HMAC-SHA384 - no more secure than SHA1 for this use case
    GCM - faster than HMAC, requires CLMUL CPU instruction to be fast
    POLY-1305 - fast and secure on generic hardware
  5. KDF used to generate symmetric keys:
    MD5+SHA1 - obsolete, probably ok
    HMAC-SHA1 - ok
    HMAC-SHA256 and HMAC-SHA384 - no more secure than SHA1 for this use case

Originally 5 was the same as 4 and was not specified separately. Also, many details omitted.

But anyway, chacha20-poly1305 is actually one of these [1]:

   TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
   TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
   TLS_PSK_WITH_CHACHA20_POLY1305_SHA256
   TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
   TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
   TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256

and you use only the first two from the list. The "ECDHE" part can be regular ECDHE with P-256 or X25519.

1 - https://tools.ietf.org/html/rfc7905#section-2

[djsumdog]

This is a really good list. Those long cryptic string constants make a lot more sense now.

[tveita]

ChaCha20-Poly1305 is a symmetric cipher, used for encrypting your traffic. X25519 is an key exchange protocol using asymmetric cryptography, and is used in during connection setup to establish keys for the symmetric cipher.

X25519 would appear under "Key exchange" and ChaCha20-poly1305 under "Cipher Suite"

With Chromium I just get ECDHE_RSA and AES_128_GCM, anyway.