4 ms·

I think quantum may be practically mitigated with aggressive key rotation in some cases. I've been prototyping an oauth machine-to-machine integration with a ba

by bob1029 6mo ago

I think quantum may be practically mitigated with aggressive key rotation in some cases. I've been prototyping an oauth machine-to-machine integration with a banking vendor that has our ecdsa keys rotate every 5 minutes. The keys are scheduled for deletion after 10 minutes. I see no reason I couldn't reduce this to something like 30s/60s. Our counterparty frequently scans our JWKS endpoint for revocation, so in practice an attacker with a quantum computer would need to be very fast if they wanted to break this particular wire agreement the scary way.

glitchc 6mo ago
You're clearly not using these keys in certificates, which would need to be signed by a root or interim CA on every update.
- bob1029 6mo ago
  Correct. The keys are only used for signing JWTs. Trust was established with the vendor out of band from this wire protocol (the URL they scan for public keys).
  - SahAssar 6mo ago
    I'm not sure I understand, but haven't you just moved the problem to the out of band layer? And is that layer not secured using the same normal (somewhat) long-lived TLS as most sites? I don't think I understand the threat model you are using here?
    - bob1029 6mo ago
      Think of the out of band layer as two human executives exchanging URLs and GUIDs in person. You still need a secure transport, but in this model the thing that is being secured on the wire expires within 15 minutes. The only way to break the model is to defeat a transport or protocol key and only before rotation, revocation and expiration can catch up each time.
      - SahAssar 6mo ago
        So, that'd be the same for a private CA with short lifetime certs used with TLS, right?
cortesoft 6mo ago
This wouldn’t help symmetric key encryption, which is what this is talking about. The keys you are rotating are asymmetric keys, which are only used to exchange symmetric keys for the actual encryption. In good setups, those symmetric keys are changed every session anyway. If an attacker can break the symmetric encryption in a reasonable amount of time, they can capture the output and break it later. In addition, how are you doing the key rotation? You have to have some way of authenticating with the rotation service, and what is to stop them from breaking THAT key, and getting their own new certificate? Or breaking the trusted root authority and giving themselves a key?
- bob1029 6mo ago
  > This wouldn’t help symmetric key encryption, which is what this is talking about. I agree. The point I am trying to make is that even for asymmetric encryption (which is far more vulnerable), there are still plausible ways to make a quantum break more difficult. The only thing that could compromise this scheme, aside from breaking the signing keys, would be to have TLS broken to the extent that viewing real-time traffic is possible. Any TLS break delayed by more than 15 minutes would be worthless.
  - knorker 6mo ago
    > Any TLS break delayed by more than 15 minutes would be worthless. What makes you say that? This is the store now decrypt later attack, and it's anything but worthless. Oh, worthless for your oauth? Uh… but how do you bootstrap the trust? Sounds to me like you need post quantum to carry the whole thing anyway. Or you mean one key signs the next? Ok, so your bet is that within the time window an RSA key, RSA can't be cracked? Why in the world would anyone want to depend on that? Surely you will also pair it with PQ?
  - minitech 6mo ago
    > Any TLS break delayed by more than 15 minutes would be worthless. It sounds like you’re talking about breaking TLS’s key exchange? Why would this not have the usual issue of being able to decrypt recorded traffic at any time in the future? Edit: If it’s because the plaintext isn’t useful, as knorker got at in a sibling comment… I sure hope we aren’t still using classical TLS by the time requiring it to be broken in 1 minute instead of 15 is considered a mitigation. Post-quantum TLS already exists and is being deployed…
bawolff 6mo ago
Going from breaking a key in a month to breaking a key in 1 second seems trivial compared to the effort of going from where we are now to being able to break a key in a month. I dont know what the quantum future holds, but if quantum actually happens then i have low faith in your plan.
cedws 6mo ago
Sounds like overkill. Quantum is a premature concern, but if there’s really that much paranoia why not use PQC like ML-KEM instead of rolling this strange thing?
- avadodin 6mo ago
  I'm not sure what you mean by "this strange thing" as the article promotes AES128 for symmetric encryption and explains why it is dumb to move to "post-quantum" for that use case. I think there are too many unknowns to bet it all on one horse. So, if we have to change all of our infrastructure due to a supposed quantum computing threat, I'd go with HybridPQ for asymmetric encryption.
FiloSottile 6mo ago
This will probably not help enough for asymmetric keys, and is unnecessary for symmetric keys. https://arxiv.org/abs/2603.28846 https://arxiv.org/abs/2603.28846 claims an attack runtime of a few minutes. There are enough order-of-magnitude breakthroughs between today and scalable quantum error correction, that it makes no sense to try to to guess exactly the order of magnitude of the attacks that will be feasible. Either you believe they won't happen, in which case you can keep using long-term ECDSA keys, or you believe they will happen, in which case they are likely to overshoot your rotation period.
rollulus 6mo ago
Wouldn’t using opaque tokens have avoided the problem altogether?

by bob1029 6mo ago

glitchc 6mo ago

You're clearly not using these keys in certificates, which would need to be signed by a root or interim CA on every update.

bob1029 6mo ago
Correct. The keys are only used for signing JWTs. Trust was established with the vendor out of band from this wire protocol (the URL they scan for public keys).
- SahAssar 6mo ago
  I'm not sure I understand, but haven't you just moved the problem to the out of band layer? And is that layer not secured using the same normal (somewhat) long-lived TLS as most sites? I don't think I understand the threat model you are using here?
  - bob1029 6mo ago
    Think of the out of band layer as two human executives exchanging URLs and GUIDs in person. You still need a secure transport, but in this model the thing that is being secured on the wire expires within 15 minutes. The only way to break the model is to defeat a transport or protocol key and only before rotation, revocation and expiration can catch up each time.
    - SahAssar 6mo ago
      So, that'd be the same for a private CA with short lifetime certs used with TLS, right?

cortesoft 6mo ago

This wouldn’t help symmetric key encryption, which is what this is talking about. The keys you are rotating are asymmetric keys, which are only used to exchange symmetric keys for the actual encryption. In good setups, those symmetric keys are changed every session anyway. If an attacker can break the symmetric encryption in a reasonable amount of time, they can capture the output and break it later. In addition, how are you doing the key rotation? You have to have some way of authenticating with the rotation service, and what is to stop them from breaking THAT key, and getting their own new certificate? Or breaking the trusted root authority and giving themselves a key?

bob1029 6mo ago
> This wouldn’t help symmetric key encryption, which is what this is talking about. I agree. The point I am trying to make is that even for asymmetric encryption (which is far more vulnerable), there are still plausible ways to make a quantum break more difficult. The only thing that could compromise this scheme, aside from breaking the signing keys, would be to have TLS broken to the extent that viewing real-time traffic is possible. Any TLS break delayed by more than 15 minutes would be worthless.
- knorker 6mo ago
  > Any TLS break delayed by more than 15 minutes would be worthless. What makes you say that? This is the store now decrypt later attack, and it's anything but worthless. Oh, worthless for your oauth? Uh… but how do you bootstrap the trust? Sounds to me like you need post quantum to carry the whole thing anyway. Or you mean one key signs the next? Ok, so your bet is that within the time window an RSA key, RSA can't be cracked? Why in the world would anyone want to depend on that? Surely you will also pair it with PQ?
- minitech 6mo ago
  > Any TLS break delayed by more than 15 minutes would be worthless. It sounds like you’re talking about breaking TLS’s key exchange? Why would this not have the usual issue of being able to decrypt recorded traffic at any time in the future? Edit: If it’s because the plaintext isn’t useful, as knorker got at in a sibling comment… I sure hope we aren’t still using classical TLS by the time requiring it to be broken in 1 minute instead of 15 is considered a mitigation. Post-quantum TLS already exists and is being deployed…

bawolff 6mo ago

Going from breaking a key in a month to breaking a key in 1 second seems trivial compared to the effort of going from where we are now to being able to break a key in a month. I dont know what the quantum future holds, but if quantum actually happens then i have low faith in your plan.

cedws 6mo ago

Sounds like overkill. Quantum is a premature concern, but if there’s really that much paranoia why not use PQC like ML-KEM instead of rolling this strange thing?

avadodin 6mo ago
I'm not sure what you mean by "this strange thing" as the article promotes AES128 for symmetric encryption and explains why it is dumb to move to "post-quantum" for that use case. I think there are too many unknowns to bet it all on one horse. So, if we have to change all of our infrastructure due to a supposed quantum computing threat, I'd go with HybridPQ for asymmetric encryption.

FiloSottile 6mo ago

This will probably not help enough for asymmetric keys, and is unnecessary for symmetric keys. https://arxiv.org/abs/2603.28846 https://arxiv.org/abs/2603.28846 claims an attack runtime of a few minutes. There are enough order-of-magnitude breakthroughs between today and scalable quantum error correction, that it makes no sense to try to to guess exactly the order of magnitude of the attacks that will be feasible. Either you believe they won't happen, in which case you can keep using long-term ECDSA keys, or you believe they will happen, in which case they are likely to overshoot your rotation period.

rollulus 6mo ago

Wouldn’t using opaque tokens have avoided the problem altogether?