Hi Daisuke,
Let us provide a bit of background about the multiple recipient setup.
Imagine a sender wants to encrypt plaintext and wants to share it with multiple
recipients.
(The goal here is that all recipients receive the same plaintext. If you want
to send different plaintext to different recipients then we are back to
one-layer structure (Section 3.1.1 in the draft)).
The sender encrypts a CEK (Content Encryption Key) using HPKE and places the
result in the recipient structure. Multiple recipients implies multiple
recipient structures. Each encrypted CEK looks different but the CEK is the
same.
In a second step, the CEK is used to encrypt the plaintext (such as a firmware
image).
(With AES-KW, used in the SUIT firmware encryption draft, there is another
option. I am not describing it here.)
Daisuke, you are proposing to put no information as shown below (snippet from
Github PR). IMHO information has to be provided on how the plaintext is
encrypted with the CEK. In the example below this information is absent.
96_0([
h'', // **This is the mandatory point to be fixed.**
{},
h'',
[
[
h'a10120',
{
4: h'3031',
-4: {
1: 16,
5: 1,
2: 1,
3: h'040..90',
},
},
h'5f..a9',
],
],
Ciao
Hannes
From: COSE <[email protected]> On Behalf Of AJITOMI Daisuke
Sent: Wednesday, November 16, 2022 11:25 PM
To: Laurence Lundblade <[email protected]>
Cc: Ilari Liusvaara <[email protected]>; cose <[email protected]>
Subject: Re: [COSE] AEAD algorithm ID for HPKE
Ilari has said most of what I want to say but let me add one point.
> From reading the PR#9 more carefully I see that you put HPKE as the algorithm
> ID in both the body header and recipient headers.
As I mentioned in the following comment, I think that the alg value for the
first layer should not be "HPKE" in the Layer Two example and I asked Hannes to
fix it.
https://github.com/cose-wg/HPKE/pull/9#issuecomment-1288984512
Best,
Daisuke
2022年11月17日(木) 4:48 Laurence Lundblade
<[email protected]<mailto:[email protected]>>:
On Nov 16, 2022, at 9:00 AM, Ilari Liusvaara
<[email protected]<mailto:[email protected]>> wrote:
On Wed, Nov 16, 2022 at 08:21:21AM -0800, Laurence Lundblade wrote:
It’s taking some time for me to understand HPKE well. Patience
appreciated. Let me ask a couple questions that seem important and
clarifying and have you confirm my understanding.
Is the bulk AEAD operation (JUST the bulk operation) on the pt that
produce the ct the same for HPKE as for the methods in COSE section
6? They both can use AES 128 GCM, but it looks to me like they aren’t
the same because HPKE has a stateful encryption context (HPKE section
5.2) and COSE doesn’t. You might be able to use the same AES 128 GCM
library for both, but the surrounding inputs don’t seem compatible.
Yes, all the surrounding stuff is different, the two only unify in
the raw AES 128 GCM implementation.
In my implementation, the common part is just the methods
- EncryptionKey::encrypt_buffer_to_buffer()
- DecryptionKey::decrypt_buffer_to_buffer()
Which implement raw AES-GCM/Chacha20-Poly1305 (EncryptionKey/
DecryptionKey also contains the algorithm used)
Makes sense.
In this case the body parameter algorithm ID is clearly NOT one of the COSE
content encryption algorithms registered today from section 4 of RFC
9053<https://www.rfc-editor.org/rfc/rfc9053.html#name-content-encryption-algorith>.
Definitely not A128GCM (1)…, definitely not AES-CCM-16-64-128 (10).
Are we considering whether and how reuse of the HPKE encryption
context fits into COSE? It is probably not useful in COSE (but
can see it is critical in TLS).
I don't think there has ever been a proposal for COSE-HPKE to reuse
the context.
OK. Just checking because I haven’t read all the back history here. Makes
sense. Possibly the COSE-HPKE draft should mention that.
How will multiple recipients be handled with COSE-HPKE? In one case
one HPKE recipient may use Edwards curves and another HPKE recipient
NIST curves. There’s also the possibility that one recipient uses HPKE
and another something that is not HPKE like AES key wrap from RFC 9053
section 6.2.
It kind of seems like HPKE was not designed for multiple recipients
because it was designed in the TLS context. You mentioned two-layered
HPKE in a previous message. What is that?
Use COSE to encrypt with freshly generated random key, then use HPKE to
encrypt that random key N times, and stick the N HPKE encryptions as
recipients of the message.
Makes sense. It parallels section 6.4 of RFC
9052<https://www.rfc-editor.org/rfc/rfc9053.html#name-key-agreement-with-key-wrap>,
right? It’s two layers of encryption (content and key wrap) plus key
agreement, right?
In this case the body parameter algorithm ID IS clearly one of the COSE content
encryption algorithms registered today from section 4 of RFC
9053<https://www.rfc-editor.org/rfc/rfc9053.html#name-content-encryption-algorith>.
One of A128GCM (1)…, AES-CCM-16-64-128 (10, ...). The algorithm ID in the
COSE_Recipient is HPKE.
I believe the COSE-HPKE draft should address this to be complete. Seems like
some details to work out to be sure it is right.
My first thought for multiple recipients in COSE-HPKE is to use the
facilities COSE has, but I’m not sure how to line that up with the
way AEAD is integrated into the HPKE encryption context. It does
seem necessary to address this now.
That's the way it is done.
The first layer (bulk encryption) in case of multiple recipients can
not use HPKE because it is symmetric-only operation, where HPKE always
involves asymmetric step (it is possible to do asymmetric-only, via
exporters but not vice versa).
Glad we’re getting some alignment here. :-)
LL
So focusing on the COSE body header parameter algorithm ID, it seems
that it should be a COSE algorithm ID if it is doing what COSE says
to do even if the recipient structure is HPKE, but if it is not
compatible with COSE’s use of AEAD, then it should be something else
(which must be in the COSE registry). Not saying which way to go here.
Just building up some facts.
Yes, if doing two-layer (required for multi-recipient):
- The main message algorithm is old COSE algorithm id (e.g., 24 for
Chacha20-Poly1305)
- The recipient algorithm is HPKE (whatever the numeric value will be).
Then there are subtle differences between one- and two-layer even for
single recipient: My implementation only ever attempts one bulk
decryption. In case there are multiple applicable keys, in case of one-
layer, it gives up if the first key is wrong, in case of two-layer, it
will proceed to try the remaining keys. This limitation comes from the
way the code handles very large messages (it is not bound by system RAM
size).
-Ilari
_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
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
