Ilari, Daisuke,
You guys talk a lot about how to use PQC algorithms in HPKE for use with COSE
but where are those actually described?
Ciao
Hannes
From: AJITOMI Daisuke <ajit...@gmail.com>
Sent: Tuesday, November 1, 2022 12:00 PM
To: Hannes Tschofenig <hannes.tschofe...@arm.com>
Cc: Ilari Liusvaara <ilariliusva...@welho.com>; cose@ietf.org
Subject: Re: [COSE] COSE HPKE
Hi Ilari and Hannes,
Sorry, I finally checked all of Ilari's comments and proposals today.
- Instead of registering hpke_sender to Common Header Parameters,
register encapsulated_key:
Why is it necessary to define the encapsulated key (enc) independent of HPKE in
this COSE-HPKE spec?
In the context of HPKE, enc should be bstr and nothing more. We should focus on
the bstr encapsulated key in the context of HPKE.
In the Kyber case, we can consider only the Kyber mapped onto the HPKE
framework, in which case enc would still be bstr (or the alternative might be
to not use the enc field, assuming that enc is included in the ciphertext
though).
For algorithm HPKE, encapsulated key MUST be present in unprotected
bucket and its value SHALL be of type COSE_HPKE_Sender.
Hmm..., it seems a bit odd to put the COSE_HPKE_Sender information into a
generic encapsulated key attribute, given the fact that the encapsulated key
itself is just one of the attributes of COSE_HPKE_Sender.
Anyway, I believe that if you want to define generic encapsulated key
information (for PQC? and so on), that you should make a separate I-D.
- COSE_HPKE_Sender could be simplified to:
COSE_HPKE_Sender = [
kdf: uint,
aead: uint,
enc: bstr,
? kem: uint
];
I think this approach using the array type is also good, but I was going to
suggest the following additions to the HPKE sender information as the next step
of draft-03. Specifically, I was thinking of the need to specify the HPKE
version information and support other HPKE modes other than Base mode in the
long run.
There are 3 optional attributes in this structure and I think it is not
suitable to be represented as an array.
```
COSE_HPKE_Sender = {
? 0 => uint, ; HPKE version (default: 1) *
? 1 => uint, ; kem id
2 => uint, ; kdf id
3 => uint, ; aead id
4 => bstr, ; enc
? 5 => bstr, ; sender public key (for Auth mode or AuthPSK mode) **
}
* Need to confirm the HPKE version can be expressed in uint.
** Need to discuss whether bstr or COSE_Key.
```
Best regards,
Daisuke
2022年10月31日(月) 20:30 Hannes Tschofenig
<hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>>:
Hi Ilari,
I updated the PR based on your feedback.
I still have a few question regarding the processing rules. I wonder whether
this procedure introduces fragility just for a very small byte saving (namely
saving the kem id value).
It also makes the implementations more difficult since multiple cases have to
be considered.
~snip~
> * you introduce rules for processing that are dependent upon the
> presence/absence of the kem field. You are asking the developer to
> determine whether "the KEM is consistent with the private key".
>
> I fear that this rule is too loose to understand. We will have to
> specify what "consistent" means i.e. what checks a developer is
> supposed to make. This also changes the text that is currently in the
> draft, which says that the kem is optional one the value of this field
> is inferred already by the key identifier.
This processing is already needed, it is just left unspecified. And my wording
was apparently very poor.
The question is, what does your implementation do if it receives:
a) A message with no KEM, but there are multiple KEMs that all can
be used with the private key and have Nenc = |enc|.
I think it is reasonable to fail to decrypt.
b) A message with no KEM, there are multiple KEMs that all can be
used with the private key, but only one has Nenc = |enc|.
I think it is reasonable to attempt decryption with the one
KEM.
(checking for Nenc = |enc| is needed in case both compact and
uncompressed curves are supported with the same private key.)
c) A message with KEM that can not be used with the private key.
I think it is reasonable to fail to decrypt.
(If the KEM can be used with private key, but Nenc != |enc|,
then HPKE will fail anyway.)
Ciao
Hannes
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
COSE@ietf.org<mailto:COSE@ietf.org>
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
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
