1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
/*!
## Rationale for defaults
### Why is AES-GCM preferred over chacha20-poly1305?
Hardware support for accelerating AES-GCM is widespread, and hardware-accelerated AES-GCM
is quicker than un-accelerated chacha20-poly1305.
However, if you know your application will run on a platform without that, you should
_definitely_ change the default order to prefer chacha20-poly1305: both the performance and
the implementation security will be improved. We think this is an uncommon case.
### Why is x25519 preferred for key exchange over nistp256?
Both provide roughly the same classical security level, but x25519 has better performance and
it's _much_ more likely that both peers will have good quality implementations.
### About the post-quantum-secure key exchange `X25519MLKEM768`
[X25519MLKEM768] -- a hybrid[^1], post-quantum-secure[^2] key exchange
algorithm -- is available when using the aws-lc-rs provider, set as the highest-priority key
exchange algorithm by default.
[X25519MLKEM768] is pre-standardization, but is now widely deployed,
for example, by [Chrome] and [Cloudflare].
You may see unexpected connection failures (such as [tldr.fail])
-- [please report these to us][interop-bug].
The two components of this key exchange are well regarded:
X25519 alone is already used by default by rustls, and tends to have
higher quality implementations than other elliptic curves.
ML-KEM-768 was standardized by NIST in [FIPS203].
MLKEM768 is available separately, but is not currently enabled
by default out of conservatism.
[^1]: meaning: a construction that runs a classical and post-quantum
key exchange, and uses the output of both together. This is a hedge
against the post-quantum half being broken.
[^2]: a "post-quantum-secure" algorithm is one posited to be invulnerable
to attack using a cryptographically-relevant quantum computer. In contrast,
classical algorithms would be broken by such a computer. Note that such computers
do not currently exist, and may never exist, but current traffic could be captured
now and attacked later.
[X25519MLKEM768]: <https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/>
[FIPS203]: <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf>
[Chrome]: <https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html>
[Cloudflare]: <https://blog.cloudflare.com/pq-2024/#ml-kem-768-and-x25519>
[interop-bug]: <https://github.com/rustls/rustls/issues/new?assignees=&labels=&projects=&template=bug_report.md&title=>
[tldr.fail]: <https://web.archive.org/web/tldr.fail/>
*/