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

Karthikeyan Bhargavan <> Sat, 13 February 2021 11:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F7AB3A0EEE for <>; Sat, 13 Feb 2021 03:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d-nfi6vhaO-T for <>; Sat, 13 Feb 2021 03:10:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DF333A0EED for <>; Sat, 13 Feb 2021 03:10:41 -0800 (PST)
Received: by with SMTP id b3so2589215wrj.5 for <>; Sat, 13 Feb 2021 03:10:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lpJ09GULdUwa4iClD88cjthXtOA03Nja7Ho0/66ZG4M=; b=j0jwQN8HHE7xaOl4lsNDUcOtxs+6YZ4I2ZtQkf+zFdFY5+DASXxUgSww5ZSC8u9ReR aWDd4xAjEmWbvu5DFjibGiNm+oVR/pZLRvRrc1vQdXNO0Bg2Ar9pI3eNBnAn2RRsS/76 Dez3LXD0UUuZ+Qth6/Zi0ep+vNPCgerttCoTcfyCfwx/dU0yH6vtS4olUlt1up/hd9kl B+YZ4NRMDe4Nhj8t+pIhY2J7HmkHIbmKWgCIgo8q7YYwtUePlLFCdkzYWoFkgPlOX8Jz YapyBc1Skpjljn00xkjRjtQzo28wXqbreEc0pACkc5/tMinIs2KEGOunGYJQc7D1sFiH +ubA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lpJ09GULdUwa4iClD88cjthXtOA03Nja7Ho0/66ZG4M=; b=I8C2JOZjG7gC1YesVjRajmX4UknRM1NPp9hThqOJM8636oystL28ZnSc+BYx5tpLDS /wBzyOKaMbrddXAAYotpXgtuphxVeJjucHrygMCa3mCsntgW+AsKddni2dIqH7r2EJgn HtJO71oLlrMSFmvJhbDXvh3EyEf1K/FPYj/Q2EiWZEacyKYmfCbJyzRJEYHpWlOc0svW UZmowErRzAkFiMyNRZN2wZg+57b8V7EF9bBEySlMu57r9vDUiv5uSkclmGfrdtOhwINv LJ2xBrgEHx32l8rAQqw9zBWoydFPTpEwXJvO7Bf9JdL4YonsritaDYG1A1ux54WYS9Qz GMmQ==
X-Gm-Message-State: AOAM5323jS1lIpvFQdr1f4EO+IyaPBdVsLmz3sS39HSlaDXlet1eLr5A 3NbOCi7qk6ezJh490HY4Xtw=
X-Google-Smtp-Source: ABdhPJxrvC/C5yg8lDog8Yb5rQ2NB7VUKRgxjVXmU8jtRwvcTvTBkvqO04BWcYkE38lrw7pRb0r+IA==
X-Received: by 2002:a5d:698b:: with SMTP id g11mr8288782wru.211.1613214639803; Sat, 13 Feb 2021 03:10:39 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id q19sm19449134wmj.23.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Feb 2021 03:10:39 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Karthikeyan Bhargavan <>
In-Reply-To: <>
Date: Sat, 13 Feb 2021 12:10:38 +0100
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Dan Harkins <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [CFRG] Fixing the multi-shot API of HPKE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Feb 2021 11:10:44 -0000

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.

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?


> On 13 Feb 2021, at 00:29, Dan Harkins <> 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