[hpke] Re: Clarification on some corner cases of HPKE

[Stephen Farrell <[e-mail]>]

Hiya,

I disagree with David. That usually means I'm wrong:-)

Disclaimer: I contributed the OpenSSL HPKE stuff so am probably
quite blameworthy, but I've no recollection at all of either of
these issues being a topic of discussion.

On 17/06/2026 20:56, David Benjamin wrote:
> The byte string of length zero is a perfectly valid byte string. I don't
> see any reason for zero-length plaintext to be an error. 

ISTM that incrementing the sequence number after an initial
empty plaintext is more likely to confuse so disallowing
those doesn't seem unreasonable.

> I similarly don't
> see any reason to limit psk_id to NUL-terminated strings. 

I don't recall identifiers that can contain a NUL in the middle
as being anything other than a source of bugs/vulns, so also
disagree there. (A little more than for the empty plaintext
thing.)

That said, I don't disagree strongly in either case and if
there were some real use-case that required either I'd be
ok with making an OpenSSL PR for a fix. (Absent a real use-case
I'd probably not spend time on it now.)

Cheers,
S.


> In general, I
> think having holes in your input space like this just results in
> unnecessarily problems for the layers above. (Accidental truncation at
> NULs, extra error condition to worry about, etc.)
> 
> (Our implementation is perfectly happy with zero-length plaintexts. We
> don't currently implement the PSK modes but, if we did, I think we'd have
> allowed psk_id to just be a general byte string.)
> 
> On Wed, Jun 17, 2026 at 3:34 PM Samuel Lee (ENS/Crypto) <Samuel.Lee=
> [e-mail]> wrote:
> 
>> Hey folks,
>>
>> I've been working on a new implementation of HPKE recently and when I
>> performed some interop testing with OpenSSL I found a couple of interesting
>> corners.
>>
>>
>> *Sealing an empty plaintext*
>> The HPKE spec seems to not make any restrictions on the minimum plaintext
>> length, and my implementation of HPKE allows a plaintext length for
>> Seal/Open to be zero-length.
>>
>> This naturally reduces to a MAC over the AAD for AEADs.
>> While the use case is probably niche, one could imagine that it might make
>> sense to want to just integrity protect some data between Sender and
>> Recipient for a specific message.
>>
>> OpenSSL appears to treat zero-length plaintext as an error.
>>
>>
>> *psk_id as a NUL terminated string vs. a byte array*
>> The HPKE spec seems to not make any restrictions on the form of PSK ID
>> beyond maximum lengths, and my implementation of HPKE takes psk_id as an
>> arbitrary byte buffer.
>>
>> OpenSSL takes psk_id as a NUL terminated string, so ids must not contain
>> NUL bytes.
>>
>>
>> For both of these issues, is there any opinion on whether these should be
>> treated as implementation defined vs. one way is "correct"?
>> Are there other interop gotchas that folks have run into that I should be
>> aware of, or HPKE implementations anyone would suggest looking at for
>> further interop testing?
>>
>> Best,
>> Sam
>> _______________________________________________
>> hpke mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> 
> 
> _______________________________________________
> hpke mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]