Add AES-GCM-SIV Nonce-Misuse-Resistant AEAD

[briansmith]

The draft spec is at https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv. One version of the paper describing one version of the construct (which might not be what's in the draft) is at https://eprint.iacr.org/2015/102.pdf. Note that the draft is almost definitely going to be updated in a significant way as foretold in https://www.ietf.org/mail-archive/web/cfrg/current/msg08853.html.

BoringSSL and Shay Gueron appear to be working on a highly-optimized implementation. Hopefully we can just take the BoringSSL asm code as-is, so we'd just have to write the upper layer in Rust. With this in mind, we should land changes prototyped in #369 first.

This would be the first purportedly-nonce-misuse-resistant AEAD in ring. We may also need to do additional work, e.g. defining a trait for nonce-misuse-resistant AEADs that is implemented by AES_128_GCM_SIV and AES_256_GCM_SIV but not by other AEADs. In order for that to work, we may also need to add an AEAD algorithm trait and hide the struct that's currently ring::aead::Algorithm.

We should do a literature review of papers analyzing the AES-GCM-SIV construct, including in particular whatever new paper Shay will probably write to describe the final version.

[briansmith]

See also RIV for Robust Authenticated Encryption.

[briansmith]

See also Stronger Security Variants of GCM-SIV.

[briansmith]

See these threads:

• https://mailarchive.ietf.org/arch/msg/cfrg/k2mpWgod4mbdOxsvN6EtXHb0BAg
• https://www.ietf.org/mail-archive/web/cfrg/current/msg08894.html

Also, I'm curious if the idea from https://eprint.iacr.org/2016/564.pdf can be used in some way here, and/or if there are ways of strengthening the nonce construction.

[briansmith]

See https://boringssl.googlesource.com/boringssl/+/41c10e2b5f37edce8b9f292f7f3bacb7e30e25c4

[misnomer1]

Hey,
I am interested in taking up adding AES-GCM-SIV to ring. I have a question though.

AES-GCM-SIV uses nonce in its key calculation and the current SealingKey/OpeningKey creates the key in its init function where as in AES-GCM-SIV the key has to be created when you call seal/open. What is a good way to write AES-GCM-SIV impl with being backwards compatible (or) do you suggest writing a new API here like create NonceMisuseResistantAlgorithm and AES-GCM-SIV-128 AES-GCM-SIV-256 being its implementations

[briansmith]

AES-GCM-SIV uses nonce in its key calculation and the current SealingKey/OpeningKey creates the key in its init function where as in AES-GCM-SIV the key has to be created when you call seal/open.

Actually, it is quite similar to ChaCha20-Poly1305, right? In ChaCha20-Poly1305 we derive a new Poly1305 key for each seal/open operation (from chacha20_poly1305.rs):

    let mut ctx = {
        let key = derive_poly1305_key(chacha20_key, counter.increment());
        poly1305::Context::from_key(key)
    };

So, I suggest structuring this more like the chacha20-poly1305 code.

What is a good way to write AES-GCM-SIV impl with being backwards compatible (or) do you suggest writing a new API here like create NonceMisuseResistantAlgorithm and AES-GCM-SIV-128 AES-GCM-SIV-256 being its implementations

If you want to start implementing AES-GCM-SIV as a part of the ring::aead API, that is fine by me and probably simpler. Eventually we'll want to be able to create a new API for AES-GCM-SIV and XChaCha20-Poly1305 that allow nonces that aren't 96 bits to be used, but we can do that as a separate step. Or, if you want to design that new API first and then implement it, I suggest proposing the API design.

[misnomer1]

Thank you for the pointers and I will implement it similar to chaha20-poly1305. I will implement it and send a PR soon

[misnomer1]

Hi Brian,
I created a PR for ASM version. I see my build is failing here (#816) where as building on my local mac seems fine with Aad parameter recognized. What do you think I am missing here?

[briansmith]

Are the initial users of this going to use it with random nonces? If not, how is the nonce going to be formed? It would be good to learn more about the applications as we consider the implementation.

[misnomer1]

Yes, the users will use random nonces. In our use case we send the nonce during initial handshakes