Re: [CFRG] Questions for the group from the HPKE presentation

Dan Harkins <> Fri, 06 August 2021 23:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA18E3A1F49 for <>; Fri, 6 Aug 2021 16:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EQdYAewICPmp for <>; Fri, 6 Aug 2021 16:56:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AE943A1F34 for <>; Fri, 6 Aug 2021 16:56:30 -0700 (PDT)
Received: from ( []) by (PMDF V6.8 #2433) with ESMTP id <> for; Fri, 06 Aug 2021 18:56:29 -0500 (CDT)
Received: from blockhead.local ([]) by (PMDF V6.7-x01 #2433) with ESMTPSA id <> for; Fri, 06 Aug 2021 16:54:25 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by ([]) (PreciseMail V3.3); Fri, 06 Aug 2021 16:54:25 -0700
Date: Fri, 06 Aug 2021 16:56:27 -0700
From: Dan Harkins <>
In-reply-to: <>
To: Richard Barnes <>, Nick Sullivan <>
Cc: CFRG <>
Message-id: <>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_QihcwHTONErP+9XNsQyTpg)"
Content-language: en-US
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
X-PMAS-SPF: SPF check skipped for authenticated session (, send-ip=
X-PMAS-External-Auth: [] (EHLO blockhead.local)
References: <> <>
X-PMAS-Software: PreciseMail V3.3 [210805] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <>
Subject: Re: [CFRG] Questions for the group from the HPKE presentation
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: Fri, 06 Aug 2021 23:56:37 -0000

On 8/6/21 3:49 PM, Richard Barnes wrote:
> 1. I don't think this question is well-formed.  HPKE isn't an API, it 
> is a construction.  In fact, the "API considerations" section of the 
> HPKE spec is there precisely because there might be different APIs to 
> an HPKE implementation.

   It may not be perfectly formed but its obvious what is being asked. 
My answer
to it is that once you find out that your contexts are out of sync it's 
too late.
I think it's more important to just be able to deal with out-of-order 
and lost

   Yes, it's "a construction"...that hides a datum from the user and 
makes the
construction fragile for some use cases. So I'd like to remove that 
fragility for
those use cases. The easiest and least intrusive, to the construction, 
way is
to just have Nn=0 for these new AEAD algorithms and not worry about the 

   One thing I failed to mention during my presentation is that even if the
user adds a counter/nonce as AAD or a plaintext tweak (to hide whether 
the same
thing is encrypted twice) and screws it up, the DAE security guarantees
remain. SIV is the original misuse-resistant mode.

   Instead "resetting the nonce counter" we could do somethinganalogous 
to what
IPsec does with a floating window that prevents replay but allows 
delivery modulo some limit (really late packets will just get dropped). 
But that
might require some changes to the API...err, the construction, so we'd 
be back
to a reformed question #1.

> Given all that, I would be in favor of no action here. There are 
> several existing ways for an HPKE-based protocol to deal with 
> out-of-order delivery.

   You mean like using deterministic authenticated encryption? If not 
that, then what
exactly are you referring to?

> 2. Personally, I don't have a use case for either of these.

   Well, will you admit that while these might not be your use cases 
that they are
legitimate nonetheless?

   Serialization should have never used SEC uncompressed format. There's 
no valid
reason to do that. I regret that I didn't bring this issue up until it was
officially "too late". But that can be rectified pretty easily and no 
one will force
you to use compact representation if you really don't want to.


> On Fri, Aug 6, 2021 at 12:31 PM Nick Sullivan 
> < 
> <>> wrote:
>     Dear CFRG participants,
>     At IETF 111, Dan Harkins made a presentation
>     <>
>     with two proposals:
>     - a proposal to define new codepoints for HPKE representing new
>     KEMs for compressed NIST points
>     - a proposal to define new codepoints to support deterministic
>     authenticated encryption schemes that don't use a nonce. This is
>     in service of the use case of out-of-order delivery of
>     ciphertexts. /In the discussion, it was noted thatHPKE uses a
>     nonce to ensure that it never leaks whether the same plaintext was
>     encrypted twice and that this proposal does not provide this
>     security property./
>     Also during the discussion, an alternative proposal was made to
>     solve the out-of-order use case: modify the API for HPKE to enable
>     the user to reset the nonce counter. This API would enable
>     out-of-order delivery of ciphertexts with existing HPKE AEADs.
>     The chairs would like to ask the group a few questions:
>     1) Does the research group support adding an API to HPKE for
>     resetting the nonce counter?
>     2) Is there interest in pursuing a work item to explore defining
>     either of the following:
>     - new codepoints for compressed curve points in HPKE?
>     - new codepoints for deterministic authenticated
>     encryption in HPKE (given the answer to (1) was no)?
>     Regards,
>     Nick (for the chairs)
>     _______________________________________________
>     CFRG mailing list
> <>
>     <>

"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