sgtm On Wed, Dec 13, 2023 at 4:36 PM Russ Housley <hous...@vigilsec.com> wrote:
> Bas: > > Thanks. I've adjusted the proposed text to address your comments: > > Implementations must use a ciphersuite that includes a symmetric > encryption algorithm with sufficiently large keys. For protection > against the future invention of a CRQC, the symmetric key needs to be > at least 128 bits. While Grover’s algorithm (described in > Section 7.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum > computer to perform a brute force key search using quadratically > fewer steps than would be required with classical computers, there > are a number of mitigating factors suggesting that Grover’s algorithm > will not speed up brute force symmetric key search as dramatically as > one might suspect. First, quantum computing hardware will likely be > more expensive to build and use than classical hardware. Second, to > obtain the full quadratic speedup, all the steps of Grover’s > algorithm must be performed in series. However, attacks on > cryptography use massively parallel processing, the advantage of > Grover’s algorithm will be smaller. > > Implementations must use sufficiently large external PSKs. For > protection against the future invention of a CRQC, the external PSK > needs to be at least 128 bits. > > Russ > > > On Dec 13, 2023, at 8:18 AM, Bas Westerbaan <b...@cloudflare.com> wrote: > > I think there is a companion point to be made. I suggest: >> >> Implementations must use a ciphersuite that includes a symmetric >> encryption algorithm with sufficiently large keys. For protection >> against the future invention of a CRQC, the symmetric key needs to be >> at least 256 bits. >> > > Not true.128 bit symmetric keys are fine for PQ. > > Right, I think that means that ECH as-is can be used, but in the face >> of a CRQC, ECH as-is won't protect against the leakage about which >> John was concerned. > > > Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's > deployable, and whether its performance is acceptable, is something we > should figure out.) > > Best, > > Bas > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
