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?
1. https://github.com/libressl-portable/portable/issues/114 2. https://github.com/libressl-portable/openbsd/issues/58
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
> (X25519 is also the default between Chrome and
> web servers: https://www.chromestatus.com/feature/5682529109540864 )
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
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
X25519 would appear under "Key exchange" and ChaCha20-poly1305 under "Cipher Suite"
With Chromium I just get ECDHE_RSA and AES_128_GCM, anyway.
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: [email protected]
Edited: tls_load_file instead of tls_read