Hi Ilari,
You combined the KEM and KDF into one value (such as COSE_CRV_HPKE_P256_SHA256).
The issue I am raising is that in the example messages (not the example keys*)
this value is not communicated.
While the curve can be inferred from the included public key, the KDF is
actually not shown in the message structure itself.
Imagine I receive a COSE structure, like the one below -- an example COSE-HPKE
two-layer structure, how do I find out what KDF to use?
---
96_0([
/ protected header /
<< {
/ alg set to AES-GCM-128 /
1: 1
}
>>,
/ unprotected header /
{
/ nonce value /
5: h'938b528516193cc7123ff037809f4c2a'
},
/ detached ciphertext /
null,
/ recipient structure /
[
/ algorithm id TBD4 for COSE_ALG_HPKE_AES_128_GCM /
<< {1: TBD4} >>,
/ unprotected header /
{
/ ephemeral public key structure /
-1: << {
/ kty set to EC2 /
1: 2,
/ crv set to P-256 /
-1: 1,
/ x-coordinate /
-2: h'985E2FDE3E67E1F7146AB305AA98FE89
B1CFE545965B6CFB066C0BB19DE7E489',
/ y-coordinate /
-3: h'4AC5E777A7C96CB5D70B8A40E2951562
F20C21DB021AAD12E54A8DBE7EF9DF10'
} >>,
4: 'kid-2'
},
/ encrypted CEK /
h'9aba6fa44e9b2cef9d646614dcda670dbdb31a3b9d37c7a
65b099a8152533062',
],
])
---
Ciao
Hannes
*: In your examples, what are the public keys representing? Are those the long
term public keys of the recipients in a kind of key set style?
-----Original Message-----
From: COSE <[email protected]> On Behalf Of Ilari Liusvaara
Sent: Sunday, July 10, 2022 2:26 PM
To: [email protected]
Subject: Re: [COSE] HPKE: Ephemeral public key encoding
On Sun, Jul 10, 2022 at 11:09:45AM +0000, Hannes Tschofenig wrote:
> Hi Ilari,
>
> Thanks for the examples. Those reflect my view as well.
>
> Only one minor question:
>
> In the " P256/Chacha encrypted message" examples you set the "EC
> identifier (crv)" to "1" (P-256) for key type 2 "EC2".
> This is inline with what I did in
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-01.
> However, in light of your mail regarding new algorithms registry in
> your email
> https://mailarchive.ietf.org/arch/msg/cose/Hllzp2Pznnqcr1XcL2zYWOHjyT0
> / I was wondering whether the value shouldn't be
> COSE_CRV_HPKE_P256_SHA256 instead. Your examples use the newly
> proposed COSE_HPKE_* algorithms but none of the COSE_CRV_HPKE_*
> elliptic_curve values.
In my code, the ephremeral key compression is entierely separate function. The
keys are not cross-checked against long-term keys or against anything else in
the message. That is, the code will happily proceed to decompress key on the
wrong curve and then feed it to HPKE (which then will barf on bad key).
And COSE_CRV_HPKE_* constants do appear in the example public keys.
This also reflects the fact that it is much more complicated to add
(de)compression support for a curve than it is to support a new KEM supported
by the underlying HPKE library. The latter is literially one- liner containing
the information that is absolutely required for function (COSE codepoint
number, HPKE KEM, HPKE KDF and name for keygen).
> X25519 public key:
>
> {
> 1: 1, / kty => OKP /
> 2: h'623FCA05CED1C293', / Some random kid /
> -1: -65540, / crv => -65540 (HPKE X25519 with SHA256) /
> / Raw public key data, 32 bytes /
> -2:
> h'56D7B1DEBC69B56EE457E518DB604EF60CF528A91E08B6326C112D9E886BC135'
> }
>
>
> P256 public key:
>
> {
> 1: 1, / kty => OKP /
> 2: h'1F677209D1C5174C', / Some random kid /
> -1: -65537, / crv => -65537 (HPKE P256 with SHA256) /
> / Raw public key data, 65 bytes /
> -2:
> h'040E271193AE34E989C5BDD36A8AF81391B62A2501A49203EA7511B5CC4E44A5753FAB35EA9E5FDEAF037E2B24CB1FF21C4C4AF1ED8AF3A91C4FECF69187DA4369'
> }
>
>
> X25519/Chacha encrypted message (test\n):
>
> [
> / { alg => -65539 (HPKE Chacha20Poly1305) } /
> h'A1013A00010002',
> {
> 4: h'623FCA05CED1C293', / kid copied from the key /
> / Uncompressed ephremeral key /
> -1: {
> 1: 4, / kty => symmetric /
> / Uncompressed raw key, 32 bytes /
> -1:
> h'580C05EF2AADBB07DE02BD44A2654CABF575689CAF067BA61BF3ACF74DF76138'
> }
> },
> / 5+16 = 21 bytes ciphertext. /
> h'B9A8708F3E956001A273511B013371A518503E9D6A'
> ]
>
>
> P256/Chacha encrypted message (test\n):
>
> [
> / { alg => -65539 (HPKE Chacha20Poly1305) } /
> h'A1013A00010002',
> {
> 4: h'1F677209D1C5174C', / kid copied from the key /
> / Compressed ephremeral key. Note that this could be /
> / Replaced by the 65 byte decompressed key marked as /
> / symmetric-type and the message would still decrypt. /
> -1: {
> 1: 2, / kty => EC2 /
> -1: 1, / crv => P-256 /
> / x-coordinate of point, 32 bytes /
> -2:
> h'96E997A98294937ED395D4B29673BB163C87313F9ECBF887B9CA15D7A5C5E675',
> -3: true / y coordinate is odd /
> }
> },
> / 5+16 = 21 bytes ciphertext. /
> h'6F7E60C1DCCCDD5F4C8CD02942B92A9AAA6492ED1D'
> ]
>
>
>
> Regarding defining a new key type, the key type could then be defined
> to carry explicit HPKE KEM/KDF algorithm identifiers in long-term
> keys, removing any need to track those in COSE. Any new KEMs/KDFs
> defined by HPKE would instantly become usable in COSE.
-Ilari
_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
