1 | /*! |
2 | |
3 | ## Rationale for defaults |
4 | |
5 | ### Why is AES-256 preferred over AES-128? |
6 | |
7 | This is a trade-off between: |
8 | |
9 | 1. classical security level: searching a 2^128 key space is as implausible as 2^256. |
10 | 2. post-quantum security level: the difference is more meaningful, and AES-256 seems like the conservative choice. |
11 | 3. performance: AES-256 is around 40% slower than AES-128, though hardware acceleration typically narrows this gap. |
12 | |
13 | The choice is frankly quite marginal. |
14 | |
15 | ### Why is AES-GCM preferred over chacha20-poly1305? |
16 | |
17 | Hardware support for accelerating AES-GCM is widespread, and hardware-accelerated AES-GCM |
18 | is quicker than un-accelerated chacha20-poly1305. |
19 | |
20 | However, if you know your application will run on a platform without that, you should |
21 | _definitely_ change the default order to prefer chacha20-poly1305: both the performance and |
22 | the implementation security will be improved. We think this is an uncommon case. |
23 | |
24 | ### Why is x25519 preferred for key exchange over nistp256? |
25 | |
26 | Both provide roughly the same classical security level, but x25519 has better performance and |
27 | it's _much_ more likely that both peers will have good quality implementations. |
28 | |
29 | */ |
30 | |