Re: [CFRG] misuse-resistant AEAD and HPKE

[Dan Harkins <[e-mail]>]

   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 <[e-mail] 
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     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