Re: [MLS] Proposal: Change AES-GCM to AES-SIV

[Dennis Jackson <[e-mail]>]

Hi Richard, 

The use of implicit nonces is complementary to SIV, but certainly
doesn't replace it. To be precise, implicit nonces ensures all
implementations use the same scheme for nonce generation. It does not
ensure that nonce generation scheme is correct.

One possible source of error is an edge case in which the
implementation unintentionally deviates from the standard. This is hard
to catch in practice. With AES-GCM, an attacker able to detect (or
force) this edge case would be able to derive the authentication key
and attack the protocol. With AES-SIV, the attacker would gain very
limited information about the message sent and the protocol would abort
normally. 

A second, more serious source of error is when the nonce generation
scheme is not correctly designed. This was the case in the KRACK attack
on WPA2. Despite the comparative simplicity of a 4-message 2-party
handshake and WPA2's wide deployment, every single implementation had
at least one nonce reuse attack. Although WPA2 does use explicit nonces
(since it is over a lossy medium), implicit nonces would not have
caught the KRACK attack, as both parties reset their nonce
counter in accordance with the specification. 

Given we are implementing a novel multi party asynchronous group key
exchange from scratch, I don't think we should shrug this away. Not
when the code level difference for implementors is only whether to pick
EVP_CIPH_GCM_MODE or EVP_CIPH_SIV_MODE. 

All the best,
Dennis 

On Wed, 26 Sep 2018 23:53:24 +0200
Richard Barnes <[e-mail]> wrote:

> Hi Dennis,
> 
> Thanks for writing this up.  One brief note: The Böck et al. paper
> you cite is about TLS 1.2 and earlier, which use explicit nonces.  In
> fact, that paper cites the implicit nonce approach in TLS 1.3 as one
> of their two recommended approaches.  That seems to support the idea
> that generating nonces in the TLS 1.3 style is a reasonable solution
> here.
> 
> That, together with the persistent lack of implementation of
> AES-GCM-SIV, makes me inclined to stick with normal AES-GCM, while
> assuring adequate safeguards.
> 
> --Richard
> 
> 
> On Wed, Sep 26, 2018 at 11:31 PM Dennis Jackson
> <[e-mail]> wrote:
> 
> > Proposal: Change AES-GCM to AES-SIV
> >
> > Rationale:
> >
> > AES-GCM requires a unique nonce for every message, otherwise it
> > fails catastrophically by directly leaking the authentication key
> > and consequently provides no resistance to active attacks on
> > confidentiality.
> >
> > AES-SIV is a drop in replacement for AES-GCM which significantly
> > mitigates the impact of repeated nonces. For a message pair with
> > repeated nonces the attacker only learns if the two plaintexts were
> > equal. There is no other loss of confidentiality or authenticity.
> > This is provably the minimum leakage possible in the event of a
> > repeated nonce.
> >
> > Handling nonces is a tricky part of any implementation and easy to
> > get wrong in the presence of state loss or concurrency. Failures
> > in nonce generation are both catastrophic and subtle. Richard Barnes
> > has already improved the specification by moving from explicit to
> > implicit nonces which can aid the discovery of faulty
> > implementations. However, implicit nonces are not a silver bullet
> > and recent papers have uncovered serious nonce reuse issues in both
> > TLS [1] and WPA [2].
> >
> > + AES-SIV significantly mitigates the impact of nonce reuse
> > + AES-SIV is a drop in replacement with the same interface as
> > AES-GCM
> > + AES-SIV makes use of the same hardware support as AES-GCM
> > + AES-SIV has a proof of security [3] and is described in RFC 5297
> > [4]
> > * AES-SIV has reasonable (but not extensive) library support
> > (including OpenSSL, BoringSSL, Intel IPP)
> > * Despite being over 10 years old, AES-SIV has not seen widespread
> >   deployment
> > * AES-SIV Encryption is ~70% of the speed of AES-GCM Encryption
> >   (Decryption is the same speed as AES-GCM)
> >
> > References:
> >
> > [1]
> > https://www.usenix.org/system/files/conference/woot16/woot16-paper-bock.pdf
> >
> > [2] https://www.krackattacks.com/
> >
> > [3] http://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf
> >
> > [4] https://datatracker.ietf.org/doc/rfc5297/
> >
> > _______________________________________________
> > MLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mls
> >  



-- 
PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC