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

Reply via email to