Subject: [CFRG] misuse-resistant AEAD and HPKE

From: Dan Harkins <[email-masked]>
Date: Mon, 02 Nov 2020 12:49:12 -0800

Hello,

   For some use cases it would be good to avoid the stateful requirements
of the the Seal() and Open() constructs in HPKE. This would seem especially
important if (skX, pkX) are derived deterministically which could result
in reuse of a particular nonce-secret for distinct invocations of Seal()
or Open().

   Rogaway and Shrimpton formalized the notion of a misuse-resistant AEAD
scheme in [1]. The mode they defined, AES-SIV, has the following properties:

    - the nonce can be arbitrary;
    - the nonce can repeat without loss of authenticity of the message,
      with privacy lost to the extent that one could know that the same
      message was sent (if, in fact, it was);
    - the nonce is not even required-- truly deterministic AEAD.

While that last property is pretty cool, it would probably be too
hard to pry into HPKE at this point. But the other properties could
be supported quite straightforwardly I think.

   AES-SIV has been defined in RFC 5297. I would be happy to provide
some suggested text to add support for AES-SIV if there is consensus
that it's a good idea.

   regards,

   Dan.

[1] "Deterministic Authenticated Encryption, A Provable-Security Treatment
     of the Key-Wrap Problem"-- EUROCRYPT '06, St. Petersburg, Russia, 2006.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Richard Barnes <[email-masked]>
Date: Mon, 2 Nov 2020 18:13:24 -0500

Hi Dan,

I'm not sure what sort of support you have in mind here.  If the idea is
just to define some ciphersuites for SIV or whatnot, feel free to email
IANA once the registry exists.

I would not be OK with specializing HPKE so that it *only* supports
misuse-resistant AEADs.  Even having different behavior for
misuse-resistant vs. not seems like more trouble than it's worth -- more
code paths and more management overhead (is this one misuse-resistant or
not?) in exchange for saving ~2 hash invocations.

--Richard

On Mon, Nov 2, 2020 at 3:49 PM Dan Harkins <[email-masked]> wrote:

> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Dan Harkins <[email-masked]>
Date: Mon, 02 Nov 2020 16:43:00 -0800

Hi Richard,

On 11/2/20 3:13 PM, Richard Barnes wrote:
> Hi Dan,
>
> I'm not sure what sort of support you have in mind here. If the idea 
> is just to define some ciphersuites for SIV or whatnot, feel free to 
> email IANA once the registry exists.

   The text surrounding the APIs requires the maintenance of state unless
you're doing a single-shot version. Just firing off an email to IANA once
the registry exists would be a little too late I think.

   So what I have in mind is some text in section 5.2 explaining that if 
(let's
imagine how this *might* look) the "MRAE" column in table 5 indicates "yes"
then the encryption/decryption need not be stateful. The existing ciphers in
table 5 would all have "no" in the "MRAE" column. That's one way of 
doing it.
Since there is a separate section for "single shot APIs" using the 
stateful API
from section 5.2 there could also be a new one for "MRAE APIs" that 
similarly
uses the stateful API from section 5.2. That's another way of doing 
this. There
may be others.

> misuse-resistant vs. not seems like more trouble than it's worth -- 
> more code paths and more management overhead (is this one 
> misuse-resistant or not?) in exchange for saving ~2 hash invocations.

   I'm not suggesting it *only* support misuse-resistant AEAD; not 
suggesting
the removal of anything. Since AES-SIV takes a double-wide key I'm 
suggesting
the addition of AES-SIV-256 and AES-SIV-512 and text describing what they
bring to the table.

   The issue is not the savings of ~2 hash invocations, it's the 
introduction of
misuse-resistance.

   Dan.

>
> --Richard
>
>
> On Mon, Nov 2, 2020 at 3:49 PM Dan Harkins <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>       Hello,
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 3 Nov 2020 01:00:49 +0000

Would you consider some kind of merge with AES-GCM-SIV? To avoid the need for double-wide key (which, IMHO, is a nuisance)?

On Nov 2, 2020, at 19:43, Dan Harkins <[email-masked]<mailto:[email-masked]>> wrote:

  Hi Richard,

I'm not sure what sort of support you have in mind here.  If the idea is just to define some ciphersuites for SIV or whatnot, feel free to email IANA once the registry exists.

  So what I have in mind is some text in section 5.2 explaining that if (let's
imagine how this *might* look) the "MRAE" column in table 5 indicates "yes"
then the encryption/decryption need not be stateful. The existing ciphers in
table 5 would all have "no" in the "MRAE" column. That's one way of doing it.
Since there is a separate section for "single shot APIs" using the stateful API
from section 5.2 there could also be a new one for "MRAE APIs" that similarly
uses the stateful API from section 5.2. That's another way of doing this. There
may be others.

I would not be OK with specializing HPKE so that it *only* supports misuse-resistant AEADs.  Even having different behavior for misuse-resistant vs. not seems like more trouble than it's worth -- more code paths and more management overhead (is this one misuse-resistant or not?) in exchange for saving ~2 hash invocations.

  I'm not suggesting it *only* support misuse-resistant AEAD; not suggesting
the removal of anything. Since AES-SIV takes a double-wide key I'm suggesting
the addition of AES-SIV-256 and AES-SIV-512 and text describing what they
bring to the table.

  The issue is not the savings of ~2 hash invocations, it's the introduction of
misuse-resistance.

  Dan.

--Richard

On Mon, Nov 2, 2020 at 3:49 PM Dan Harkins <[email-masked]<mailto:[email-masked]>> wrote:

  Hello,

  regards,

  Dan.

_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Dan Harkins <[email-masked]>
Date: Mon, 02 Nov 2020 23:33:46 -0800

Hi Uri,

On 11/2/20 5:00 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> Would you consider some kind of merge with AES-GCM-SIV? To avoid the 
> need for double-wide key (which, IMHO, is a nuisance)?

   Ultimately it's the will of the group. If there's consensus for 
AES-GCM-SIV
then of course. Also if there's consensus for "don't bother with MRAE" then
it's all moot.

   I prefer AES-SIV over AES-GCM-SIV but for reasons that might not apply
to HPKE. Given that the Expand() can generate any length output, including
double-wide keys, I don't see the nuisance: just set Nk accordingly, there's
actually an existing column for that in table 5 so it's not like this is 
onerous.

   regards,

   Dan.