Re: [CFRG] misuse-resistant AEAD and HPKE

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 <dharkins@lounge.org<mailto:dharkins@lounge.org>> wrote:

  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.

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 <dharkins@lounge.org<mailto:dharkins@lounge.org>> wrote:

  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

_______________________________________________
CFRG mailing list
CFRG@irtf.org<mailto:CFRG@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg

--
"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

_______________________________________________
CFRG mailing list
CFRG@irtf.org<mailto:CFRG@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg