On Tue, Jan 18, 2022 at 11:20:34AM +0000, Hannes Tschofenig wrote:
> Hi Ilari,
>
> [Hannes] I think you are suggesting to do this:
>
> 96(
> [
> // protected field with alg=AES-GCM-128
> h'A10101',
> { // unprotected field with iv
> 5: h'26682306D4FB28CA01B43B80'
> },
> // null because of detached ciphertext
> null,
> [ // COSE_recipient_outer
>
> / protected / h'a1013818' / {
> \ hpke-alg \ 1:16 \ HPKE/P-256+HKDF-256 \
> hpke-aead-id: 1 // AES-128-GCM
> } / ,
> / unprotected / {
> // HPKE encapsulated key
> / ephemeral / -1:{
> / kty / 1:2,
> / crv / -1:1,
> / x / -2:h'98f50a4ff6c05861c8...90bbf91d6280',
> / y / -3:true
> },
> // kid for recipient static ECDH public key
> / kid / 4:'[email protected]'
> },
> // Encrypted CEK
> h'FA55A50CF110908DA6443149F2C2062011A7D8333A72721A',
> ]
> ]
> ]
> )
Yeah, thereabouts.
I am not sure what is the best precise variation to use.
- I would like there being generic support for all HPKE algorithms.
The most compact way of doing this is:
* Have new alg=hpke. Which has the AEAD id as parameter.
* Have new kty=hpke. Which has the KEM and KDF ids as parameters,
as well as raw public/encapsulated key.
However, this runs into size issues with P-x curves.
HPKE encapsulated key for KEM=33, KDF=2, would be roughly:
-1:{
1:<id-kty-hpke>,
-1:33,
-2:2,
-3:h'...'
}
This would be 11 bytes of overhead, assuming typical PQC sizes.
- Solving the P-x size issues, option a):
* With EC2, do not include explicit KEM and KDF ids.
* The public keys are unpacked into public/encapsulated keys.
Roughly corresponds to the above, but with no hpke-alg.
- Solving the P-x size issues, option b):
* Use the HPKE kty, with negative KEM id.
* Pack the P-x keys using the same compression as in C509.
AFAICT, this is one byte more compact than a) with P-x keys.
The ephemeral key would roughly be:
-1:{
1:<id-kty-hpke>,
-1:-1
-3:h'0398f50a4ff6c05861c8...90bbf91d6280'
}
For X25519 and X448, the both options above save 3 bytes.
And looks like I underestimated the space savings from cose_encrypt0
if one only has one recipient. The savings are more like 50 bytes or
so (more for 192-bit and 256-bit levels).
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
