4 ms·
There is a very good reason: efficiency. Do you want to have servers carry an extra megabyte of otherwise-useless key material for each incoming connection? Wha
by pclmulqdq 2y ago
There is a very good reason: efficiency. Do you want to have servers carry an extra megabyte of otherwise-useless key material for each incoming connection? What about the extra ~100-1000 microseconds of CPU time for each key exchange?
Now multiply that by 100,000 live connections and 10,000 per second, and you'll see that there's a big problem here.
A lot of cryptography arguments forget that people don't place unlimited value on cryptography (or even security in a general sense). These algorithms are costly, and if they do nothing, should not be used.
- adastra22 2y agoKyber768, which is what I see most people using for hybrid PQC deployments right now, has 1kB keys and is actually faster than elliptic curve cryptography.
- pclmulqdq 2y ago4 kB keys, you mean, right? You have to store your private key, too. It's pretty fast otherwise, yes.
- adastra22 2y agoYou have to store 1 private key. You store/transmit/interact with millions of other public keys, so the concern over size is somewhat asymmetrical.
- pclmulqdq 2y agoMany protocols use an ephemeral private key, and protocols like TLS that don't today are moving toward ephemeral private keys faster than they are toward PQC. The ephemeral key gets signed with your long-lived private key, but that's all your long-lived key is used for.