Re: [jose] [COSE] HPKE PartyU / PartyV

["lgl island-resort.com" <[e-mail]>]

Here’s API documentation for what I did for t_cose after the San Francisco IETF.

TLDR — PartyU / PartyV are unnecessary; if you are worried about something for your use case, add a random salt to the KDF context.

This was for COSE -29 and -25. COSE-HPKE has even less reason to use these IMO.

LL



t_cose_recipient_enc_esdh_party_info()

Like the documentation for t_cose_recipient_enc_esdh_supp_info() this gives an opinion and recommendation: PartyU and PartyV should be left unset and unused. Don't call this method.

The point of PartyU and PartyV is to bind the content encryption key to the sender and receiver context. These are in COSE because they are in NIST SP800-56A and JOSE. They are justified by academic papers on attacks on key agreement protocols found in Appendix B of NIST SP800-56A. Probably these attacks don't apply because you probably are using a good RNG and because the ephemeral key is generated anew for every encryption. Good RNGs are much more common now (2023) than when these papers were authored.

These data items are described in RFC 9053 section 5.2. This API only allows setting Party*.identity. It doesn't allow setting Party*.nonce or Party*.other. It always sets them to \c NULL. Speaking with opinion, 'nonce' and 'other' seem very unnecessary and complex. Hopefully, no implementation ever uses them. Everything needed can be done with the 'PartyInfo*.identity' data items.

 See t_cose_recipient_enc_esdh_supp_info() where it is recommended to set one of the KDF context inputs and additionally t_cose_recipient_enc_esdh_salt().

 The opinions here were formed from discussions with long-time workers on COSE, CMS, LAMPS, reading of NIST SP800-56A and trying to formulate attacks that these data items defend against.

<https://github.com/laurencelundblade/t_cose/blob/dev/inc/t_cose/t_cose_recipient_enc_esdh.h>
[bd5ad74c-9697-4c62-aec5-84c27ee4494e.png]
t_cose/inc/t_cose/t_cose_recipient_enc_esdh.h at dev · laurencelundblade/t_cose<https://github.com/laurencelundblade/t_cose/blob/dev/inc/t_cose/t_cose_recipient_enc_esdh.h>
github.com<https://github.com/laurencelundblade/t_cose/blob/dev/inc/t_cose/t_cose_recipient_enc_esdh.h>




On Feb 27, 2024, at 1:02 PM, Orie Steele <[e-mail]> wrote:

Hello OSE-Enthusiasts,

As we align JOSE and COSE drafts for adding support for HPKE, we've encountered our old friends:

PartyU and PartyV...

JOSE has this to say: https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.1.2

"""
   The "apv" (agreement PartyVInfo) value for key agreement algorithms
   using it (such as "ECDH-ES"), represented as a base64url encoded
   string.  When used, the PartyVInfo value contains information about
   the recipient.  Use of this Header Parameter is OPTIONAL.  This
   Header Parameter MUST be understood and processed by implementations
   when these algorithms are used.
"""

COSE has this to say: https://datatracker.ietf.org/doc/html/rfc9053#name-context-information-structu

(TLDR... No MUST).

We have an opportunity to maintain parity here, and essentially repeat the support for behavior we have in JOSE and COSE for "ECDH-ES+A128KW", when PartyU and PartyV are present.

HPKE has support for enabling this consistently, and JOSE and COSE have the structures we need to use, already defined.

My question is not if we can do this, it is SHOULD we do this....

I've always found this part of encryption in JOSE troublesome, why is it necessary for HPKE to support this?

Are we passing up an opportunity to simplify things and remove an unused/underutilized feature from being required in a new, and currently not used encryption scheme (HPKE).

Is it time for apu and apv to be ignored when present and not understood?

Regards,

OS

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries
[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
_______________________________________________
COSE mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cose