On Mon, Mar 24, 2025 at 5:17 PM Martin Thomson <m...@lowentropy.net> wrote:
> On Tue, Mar 25, 2025, at 02:37, Eric Rescorla wrote: > > 1. Getting PQ resistance for free even with non-PQ PAKEs. > > 2. Reducing the combinatoric explosion of "groups" > > I don't know that you are really getting PQ resistance if your PAKE > remains vulnerable. You might maintain confidentiality for that single > connection, but if there is a possibility of impersonation (are you relying > on the PAKE for authentication of the server?) then you lose. > This is what we are doing right now by rolling out PQ for key establishment but not for authentication: we provide security against harvest now decrypt later attacks, but not against impersonation if there is a CRQC. Avoiding the combinatoric problem seems like a pretty high complexity tax. > Sure, we are already in the position where we have N (number of ECC groups) > x M (number of PQ groups) groups. Adding a PAKE makes that N x M x P > (number of PAKEs). However, these are all small numbers. Building a > parallel extension is relatively straightforward if you model it like key > exchange and use the obvious combiner. But then, why did we not do that > with PQ as well? > I agree it's a judgement call, but IMO PQ key establishment via KEMs is more like DH key establishment than PAKEs are. For instance, neither needs to connect with some password database. For this reason and others,it's not clear to me that in fact it will be simpler to have combined PAKE + ECC + PQ groups than to have the PAKE be separate. -Ekr
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
