Re: [MLS] Substitute AES-128-GCM with AES-256-GCM for TreeKEM

If QC becomes practical, all the DH stuff is out the window anyway :)

On Thu, Sep 20, 2018 at 8:36 AM Dennis Jackson <dennis.jackson@cs.ox.ac.uk>
wrote:

> One area in which the symmetric cipher keysize does matter is if you
> believe quantum computers will become viable in the next 5~10 years.
> Considering the efforts standards bodies and corporations are putting
> into developing post-quantum handshakes, this doesn't seem unreasonable.
>
> If QC becomes practical (even assuming no other cryptanalytic
> breakthroughs) AES-256 degrades to 128-bit security and AES-128
> degrades to only 64-bit security (no better than DES). However, none of
> the draft handshakes are post-quantum secure, which is arguably a bigger
> problem.
>
> Some options:
>
> a) do nothing
> b) specify a post quantum handshake alongside AES-256
> c) specify AES-256 in general and allow a PSK in addition to the usual
> handshake
>
> Wireguard uses c) to achieve "cheap" PQ-security without the
> burden of implementing a PQ handshake.
>
> I'm not advocating for any of these options, just noting where
> symmetric keysize is a consideration.
>
> On Thu, 20 Sep 2018 14:27:09 +0200
> Joel Alwen <jalwen@wickr.com> wrote:
>
> > On 20/09/2018 14:02, Richard Barnes wrote:
> >
> > > As I understand it:
> > >
> > > The parts of a ciphersuite work together, so the idea is roughly
> > > that there's no point in adding one super strong link to the chain
> > > if the others are weak.
> > >
> > > Following the TreeKEM / ECIES example below, if you generate a key
> > > for AES-256 off of a P-256 ECDH operation, then the whole thing can
> > > still be broken with 2^128 effort, by attacking the ECDH instead of
> > > the AES.
> >
> > - I agree with this point of view. To me it seems the con of the
> > switch to AES-256 is some (small) additional cost in bandwidth,
> > storage and computation but there is no pro in terms of added
> > security since keys are negotiated on a 128-bit secure curve. So it
> > doesn't make that much sense to me... Nor do I think, at least for
> > short and medium term security, that there is a problem with 128-bit
> > security.
> >
> > - Having said that, I think 256-bit security does have legitimate use
> > cases in practice. (Say, long-term forward secrecy and/or hedging
> > against future improvements in cryptanalyis.) Therefor I'm quite in
> > favor of including in MLS a recommended fully 256-bit secure
> > instantiation. E.g. SHA-512, Ed448-Goldilocks, AES-256-GCM. (My
> > preference for Ed448 over P521 stems from P521 being less efficient,
> > less easy to implement in side-channel resistant way and Ed448 soon
> > being included in TLS hopefully leading to solid implementations
> > becoming widely available.)
> >
> > - I think that mandating an explicit nonce reuse resistant mechanism
> > (whether via SIV or something else) makes a lot of sense and is
> > something MLS should do.
> >
>
>
>
> --
> PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>