4 ms·

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

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 https://github.com/libressl-portable/openbsd And email patches to: tech@openbsd.org Edited: tls_load_file instead of tls_read

jamiesonbecker 10y ago
> 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 https://www.chromestatus.com/feature/5682529109540864 ) Any idea on when X25519 will be added?
- montyedwards 10y ago
  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 https://tools.ietf.org/html/rfc7748 Here's the errata for RFC 7748 https://www.rfc-editor.org/errata_search.php?rfc=7748 https://www.rfc-editor.org/errata_search.php?rfc=7748
- stock_toaster 10y ago
  > (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 https://www.google.com with chrome (chrome-53) at any rate.
  - wolf550e 10y ago
    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 https://tools.ietf.org/html/rfc7905#section-2
    - 10y ago
- xoa 10y ago
  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 https://github.com/libressl-portable/portable/issues/114 2. https://github.com/libressl-portable/openbsd/issues/58 https://github.com/libressl-portable/openbsd/issues/58

jamiesonbecker 10y ago

> 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 https://www.chromestatus.com/feature/5682529109540864 ) Any idea on when X25519 will be added?

montyedwards 10y ago
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 https://tools.ietf.org/html/rfc7748 Here's the errata for RFC 7748 https://www.rfc-editor.org/errata_search.php?rfc=7748 https://www.rfc-editor.org/errata_search.php?rfc=7748
stock_toaster 10y ago
> (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 https://www.google.com with chrome (chrome-53) at any rate.
- wolf550e 10y ago
  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 https://tools.ietf.org/html/rfc7905#section-2
  - 10y ago
xoa 10y ago
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 https://github.com/libressl-portable/portable/issues/114 2. https://github.com/libressl-portable/openbsd/issues/58 https://github.com/libressl-portable/openbsd/issues/58