search

cose-wg / HPKE

3 stars 3 forks source link

Introduce the encapsulated_key header parameter instread of HPKE_Sender_info #27

Closed dajiaji closed 1 year ago

dajiaji commented 1 year ago

Following the consensus call result, it is necessary to switch from the a-la-carte approach to the ciphersuite approach.

In the ciphersuite approach, which includes all information in the "alg" value, the HPKE_Sender_Info structure is not needed. Simply specifying the binary string of the encapsulated key in the header is sufficient.

We need to introduce the encapsulated_key header parameter instread of the HPKE_Sender_Info.

selfissued commented 1 year ago

This this be a new header parameter or simply the Content Encryption Key (CEK)?

ilaril commented 1 year ago

A new header parameter, in order to transport the enc bstr from SealBase() to OpenBase(). In unprotected bucket, because protected bucket would cause circular dependency.

There is no existing suitable parameter. Either because of completely different purpose, or unsuitable value type.

CEK will be the plaintext if COSE-HPKE is placed as a recipient of AEAD cipher (RFC 9052, section 5.3).

dajiaji commented 1 year ago

This this be a new header parameter or simply the Content Encryption Key (CEK)?

An encapsulated key is basically a serialized public key, and it is used to derive a keying material, not for encryption/decription purposes. In addition, the existing ”epk” (ephemeral public key) header parameter cannot be used because, for example, an encapsulated key for a hybrid KEM for PQC is a byte string consisting of two public keys concatenated together.

It would be better to define a new header parameter for the encapsulated key.