Re: [CFRG] Fixing the multi-shot API of HPKE

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Strictly speaking, AES-GCM-SIV does *not* need a nonce, given that the bounds (how many messages of what size are secured with the same key) are observed.

I found that a very useful property. Not everybody needs that, and not always - but it's like "you don't need it, until you *really* need it".
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare
 

On 2/13/21, 07:29, "CFRG on behalf of Dan Harkins" <[e-mail] on behalf of [e-mail]> wrote:


       Hi Karthik,

    On 2/13/21 3:10 AM, Karthikeyan Bhargavan wrote:
    > Hi Dan,
    >
    > I don’t fully understand the problem you are alluding to.
    >
    >>     "It is up to the application to ensure that encryptions and
    >>      decryptions are done in the proper sequence, so that encryption
    >>      and decryption nonces align.”
    > The HPKE stateful API guarantees that nonces cannot be misused, even if you use AES-GCM or Chacha-Poly. (Of course, you could also add a SIV ciphersuite.)
    > Furthermore, it guarantees that the stream of plaintext messages received by the decryptor is a prefix of the stream of plaintext messages sent by the encryptor.

       It's not an issue of misuse, it's an issue of the sender and
    receiver contexts getting out of sync through entirely normal
    network behavior and becoming unusable.

    > In the current design, if two ciphertexts are decrypted out-of-order, both decryptions will fail.
    > So the problem alluded to in the text above is one of functionality; the application has to ensure (using some meta-data) that it is calling decrypt in the right order.
    > The application usually has to do something like this anyway to put the plaintext stream together.
    >
    > I do not see how using AES-GCM-SIV is going to solve the above issue; yes, it would allow you to decrypt the plaintext in any order, but  the HPKE receiver would not be able to authenticate the correct order.
    > Am I missing something?

       AES-GCM-SIV requires a nonce (although reuse is not tragic in the
    way it is for GCM) so there still needs to be some guarantee that the
    nonce plugged into the receiver is the same as the one plugged into
    the sender when the ciphertext was created. This is a proposal for
    AES-SIV (defined by Rogaway and Shrimpton) which can do deterministic
    AEAD (it can also be passed a nonce to be more like a traditional AEAD
    mode, albeit slower, but that's not what I'm proposing here). No nonce
    so nothing to worry about getting out of order.

       Regarding the correct order, for a streaming application yes that's
    true. The correct order would still be needed and whatever technique
    you use to ensure that decrypted packets get ordered correctly could
    probably be used to ensure that packets are decrypted in order. But
    there are other interesting applications of HPKE that are not streaming
    and each message can be thought of as self-contained. Imagine a sensor
    obtaining some environmental data and then sending it off to a server
    for correlation and processing every <time slice>. It would be quite
    easy for such a sensor and server to get their HPKE contexts out of
    sync and that would be a real PITA.

       regards,

       Dan.

    > -Karthik
    >
    >
    >
    >> On 13 Feb 2021, at 00:29, Dan Harkins <[e-mail]> wrote:
    >>
    >>
    >>    Hello again,
    >>
    >>    The HPKE spec defines a single shot API for doing things like key-wrapping.
    >> You pass in the recipient's public key and some plaintext and get back a
    >> ciphertext. And that's it. One and done.
    >>
    >>    There is also (what I'll call for lack of a better word) a multi-shot API.
    >> The idea here is that there's a single asymmetric crypto operation involving
    >> the recipient's pubic key to derive some state that resides in an opaque HPKE
    >> context and then multiple calls to encrypt distinct plaintexts. The state
    >> created includes a base nonce and a sequence number (initialized to zero).
    >> Each call to another encryption (decryption) increments the sequence number
    >> which is xor'd with the base nonce and passed to the AEAD algorithm. The HPKE
    >> APIs take a plaintext, and AAD, and produce a ciphertext, and vice versa.
    >>
    >>    This multi-shot API is fine if your world is Guaranteed In Order Delivery
    >> of Packets but that's not the world we all live in. As such, it'll only
    >> be a matter of time before the sender and receiver are out of sync. The
    >> HPKE draft alludes to this problem this way:
    >>
    >>
    >>
    >> Well that's a pain! One of the nice things about HPKE is that one doesn't
    >> need to worry about the nitty gritty of crypto state management anymore,
    >> it's all hidden. The API is nice and clean-- pass in a plaintext and get a
    >> ciphertext, pass in a ciphertext and get a plaintext.
    >>
    >>    If there was an AEAD mode that did not require a nonce it could be used
    >> in HPKE's multi-shot API without need for the application to manage state
    >> and guarantee the parties stay in sync. Thankfully there is such an AEAD
    >> mode: AES-SIV (RFC 5297).
    >>
    >>    When I brought this up earlier (and also on github) in the context of
    >> misuse resistance the response was, there's an export-only API that will
    >> give you a secret and you can go do any AEAD mode you feel like, including
    >> AES-SIV, issue closed.
    >>
    >>    While that is technically true, it applies equally to the AEAD functions
    >> that HPKE already defines-- you can export a secret and do AES-GCM-256
    >> outside of HPKE while managing the necessary state yourself. Yet HPKE
    >> defines AEAD functions whose state resides in an opaque context so there
    >> is obviously value in having that functionality. I just want to get that
    >> value-- a clean, multi-shot API where I don't need to worry about managing
    >> state or guaranteeing people remain in sync-- for people who don't live
    >> in the world of Guaranteed In Order Delivery of Packets.
    >>
    >>    So I'd like to ask the group whether they see value in having a nonce-less
    >> AEAD mode in HPKE. If so I'll be happy to resurrect the text changes I
    >> proposed and will be happy to contribute test vectors from my HPKE
    >> implementation which already does AES-SIV.
    >>
    >>    One issue is that there are different security properties for a
    >> deterministic authenticated encryption scheme than for a probabilistic
    >> scheme. This is discussed in [1] and the security considerations would
    >> have to mention this. But I don't see that as a formidable problem.
    >>
    >>    regards,
    >>
    >>    Dan.
    >>
    >> [1] Rogaway and Shrimpton, "Deterministic Authenticated Encryption",
    >>      EUROCRYPT, 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]
    >> 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
    [e-mail]
    https://www.irtf.org/mailman/listinfo/cfrg