3 ms·

Even with lattice stuff, the parameters keep having to be changed to ensure security. It may not be explosive breaks, but the cryptanalysis is advancing at stun

Even with lattice stuff, the parameters keep having to be changed to ensure security. It may not be explosive breaks, but the cryptanalysis is advancing at stunning speeds. This stuff is no where near prime time ready.

tptacek 2y ago
I think we are agreeing, directionally. I don't have a strong opinion in either direction and wouldn't be qualified to express one. I'm a vulnerability researcher with a little bit of cryptography to me, so I tend always to err on the side of utterly skeeved out. I assume, regardless of what national standards bodies recommend, this stuff will all be run hybrid for the foreseeable future, but who knows? I don't think anybody can easily shut down the argument that it's too early for lattice PQC to simply replace ECDLP cryptography.
- adastra22 2y ago
  There is not any reason to NOT run hybrid cryptography schemes right now, when the use case allows for it. I do worry though that early standardization might lock us into a bad standard, and current PQC systems are too inflexible to allow for many use cases. The latter point means that if you want PQC, you might have to give up some features. E.g. multikey signature schemes, zero knowledge proofs, etc.
  - CiPHPerCoder 2y ago
    > There is not any reason to NOT run hybrid cryptography schemes right now, when the use case allows for it. This is reasonable, but runs contrary to the stance taken by CNSA 2.0.
    - adastra22 2y ago
      Gee, I wonder why.
  - 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 ago
      Kyber768, 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 ago
        4 kB keys, you mean, right? You have to store your private key, too. It's pretty fast otherwise, yes.
        adastra22 2y ago
        You 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 ago
        Many 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.

tptacek 2y ago

I think we are agreeing, directionally. I don't have a strong opinion in either direction and wouldn't be qualified to express one. I'm a vulnerability researcher with a little bit of cryptography to me, so I tend always to err on the side of utterly skeeved out. I assume, regardless of what national standards bodies recommend, this stuff will all be run hybrid for the foreseeable future, but who knows? I don't think anybody can easily shut down the argument that it's too early for lattice PQC to simply replace ECDLP cryptography.

adastra22 2y ago
There is not any reason to NOT run hybrid cryptography schemes right now, when the use case allows for it. I do worry though that early standardization might lock us into a bad standard, and current PQC systems are too inflexible to allow for many use cases. The latter point means that if you want PQC, you might have to give up some features. E.g. multikey signature schemes, zero knowledge proofs, etc.
- CiPHPerCoder 2y ago
  > There is not any reason to NOT run hybrid cryptography schemes right now, when the use case allows for it. This is reasonable, but runs contrary to the stance taken by CNSA 2.0.
  - adastra22 2y ago
    Gee, I wonder why.
- 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 ago
    Kyber768, 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 ago
      4 kB keys, you mean, right? You have to store your private key, too. It's pretty fast otherwise, yes.
      - adastra22 2y ago
        You 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 ago
        Many 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.