Subject: [Cfrg] The new submission "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption"

From: Shay Gueron <[email-masked]>
Date: Sun, 6 Mar 2016 05:50:18 +0200

Hello CFRG,

We would like to draw your attention to our new submission draft entitled
“AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption”. Posted on
https://www.ietf.org/internet-drafts/draft-gueron-gcmsiv-00.txt

The submission specifies two authenticated encryption algorithms that are
nonce misuse-resistant. Their performance is expected to be roughly on par
with AES-GCM, when run on modern processors that have AES instructions.

Security and performance analysis can be found in S. Gueron and Y. Lindell.
GCM-SIV: Full Nonce Misuse-Resistant Authenticated Encryption at Under One
Cycle per Byte. In 22nd ACM CCS, pages 109-119, 2015.

We hope that the CFRG will take this up as a working-group item.

Thank you,

Shay Gueron, Adam Langley, Yehuda Lindell

---

From: Björn Edström <[email-masked]>
Date: Mon, 7 Mar 2016 23:40:33 +0100

" We note that POLYVAL(H, X_1, X_2, ...) is equal to

   ByteSwap(GHASH(x*H, ByteSwap(X_1), ByteSwap(X_2), ...)), where
   ByteSwap is a function that converts a field element to a 128-bit
   string, reverses the order of the bytes, and interprets the result as
   a field element again."

Well done! That's a nice property to help adaption.

Any similar submissions in the CAESAR competition that are worth
considering by the CFRG?

Cheers
Björn

On Sun, Mar 6, 2016 at 4:50 AM, Shay Gueron <[email-masked]> wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Shay Gueron <[email-masked]>
Date: Tue, 8 Mar 2016 06:28:10 +0200

Hello Björn,

Here are a few comments.

In the reference [GCM-SIV], we have compared GCM-SIV to other nonce-misuse
resistant CAESAR submissions.

We did not submit the proposal to CAESAR, only due to the timeline. There
are, of course, other worthy CAESAR submissions.

There were some CAESAR submission which also use GF(2^128) computations,
but I am not sure which ones remained (at least one (Julius) was
eliminated).

One advantage of GCM SIV is that it can be viewed simply as "AES-GCM in a
reversed order". So , it inherits the proofs of AES-GCM (with 96-bit IV),
relies on the assumptions on AES, and enjoys the same hardware
acceleration. This is why we pointed out the equivalence between POLYVAL
and GHASH.

We chose to use POLYVAL so that 128-bit blocks can be viewed as field
elements and as AES ciphertexts in a consistent way (with respect to the
order of the bits inside each byte). This is not the case with AES-GCM.

Thank you, Shay

---

From: Taylor R Campbell <[email-masked]>
Date: Thu, 31 Mar 2016 14:54:39 +0000

The performance claims in the paper are impressive, but I would like
to see replication by disinterested parties.  Unfortunately, SUPERCOP
does not appear to be set up to measure AEAD.  Has anyone set up
anything similar for that?

Where is the optimized implementation I could use to replicate your
performance results?  Where is the reference implementation I could
use for validation?  I checked the internet-draft and paper and didn't
see anything there.

So I'm particularly interested in seeing

- the expected performance in software on CPUs that do not support
  AES-NI or PCLMULQDQ, and

- the cost of making variability in software performance independent
  of secrets.

It is all well and good for your test computer to support AES-NI and
PCLMULQDQ, but not all of my computers do, and when I write a stack of
general-purpose software for the internet, I can't assume that.  Even
on machines that have them or equivalents, assuring myself that they
will actually get used, through all the layers of abstractions and
build systems and toolchains, takes nontrivial engineering effort.

Rich companies like Google and Apple can afford to just buy new
hardware or specialize their software stacks to one platform, but not
everyone can do that.

I would suggest it is irresponsible to endorse general-purpose crypto
on the internet for which it is difficult to write fast, constant-time
software implementations.  The primitives that AES-GCM-SIV is built
out of -- AES and GF(2^n) arithmetic -- do not inspire confidence in
that regard.