[hpke] Re: purpose and practice for aad and info parameters

[Laurence Lundblade <[e-mail]>]

> On Mar 10, 2026, at 1:13 PM, Ilari Liusvaara <[e-mail]> wrote:
> 
> On Tue, Mar 10, 2026 at 11:26:27AM -0700, Laurence Lundblade wrote:
>> Is this correct?
>> 
>> aad: Useful for authenticating data (but note that in mode_base, this
>> authentication is not strong, not equivalent to signing).
>> 
>> info: Useful for authenticating data (same as aad) AND influencing
>> the key schedule and context set up.
>> 
>> There’s not really any difference of substance between aad and info
>> for authenticating additional data except info sometimes has some
>> size limitations that aad does not. Data to be authenticated is not
>> difficult to understand and isn’t required for security reasons like
>> info might be.
>> 
>> 
>> The question, then, is when info is actually needed for security
>> reasons?
> 
> - For protocol separation.
> - For mode separation (if AAD does not do it reliably).
> - Authenticating session (as opposed to message) data.

Right, but wouldn’t the aad parameter to HPKE Seal/Open work just as well for these?

By protocol, you mean the application protocol using HPKE, right?

By mode, you mean HPKE modes (base, psk,…)

Or, maybe you want these in info so they are part of domain separation? Maybe domain separation is the main way to characterize the difference between info and aad?


> - For SuppPrivInfo (using aad for this is insecure!).
> 
> The first two are the most common ones. For those, 64 bytes should be
> plenty.
> 
> 
>> [Section 5.2 of RFC 9053] defines a fairly complex mechanism for this
>> and refers to [SP800-56A] for guidance on how and when. HPKE does not
>> include an equivalent discussion.
> 
> Most of those fields are either meaningless or implicit in HPKE.
> 
> 
>> This is a bit above my pay grade, but my understanding is that HPKE,
>> as designed and used with the registered algorithms, should remain
>> secure even if the info parameter is empty. Can someone confirm that?
>> It seems like an important point.
>> 
>> That said, it seems possible to use the HPKE framework with poor
>> algorithms or a weak random number generator where input via the info
>> is necessary for the reasons discussed in [SP800-56A]. In other words,
>> not every conceivable use of HPKE is guaranteed to be secure enough
>> that info can be empty.
> 
> Including SuppPrivInfo might help with a bad KEM, but it will not help
> with a bad AEAD. Bad KDF is mostly not a thing.

I note that compensating for a bad RNG is an explicit non-goal of HPKE. That seems like a really good choice to me.

Still, adding some pre-shared secret can increase security. Maybe the security issue is how the secret parts of the KEM are protected or managed has a little weakness and there’s a pre-shared secret that is stored or managed differently.

Thanks for your response.

LL