On Tue, Nov 09, 2021 at 01:33:48PM +0000, John Mattsson wrote:
> Hannes wrote:
>
> I do, however, agree that the cleaner way is to define a new
> parameter, as you suggested, and then re-use the HPKE registry.
> By doing this we also make sure that the two registries do not get
> out of sync. So, unless there is an objection I would go head and
> make the chance to the draft.
>
> - The current COSE key exchange algorithms comes in pairs such as
>
> ECDH-ES + A128KW (ECDH ES w/ Concat KDF and AES Key Wrap w/ 128-bit key)
> ECDH-ES + HKDF-256 (ECDH ES w/ HKDF - generate key directly)
>
> The approaches have different pros and cons. I think it would be
> good to follow the same architecture with HPKE in COSE (but
> continue using HPKE Seal() instead of AESKW). The difference between
> using a CEK and deriving a key directly could easily be signaled with
> the sign of the ‘hpke-alg' value.
>
> Using (say 'hpke-alg'; label 11) the two approaches could be signaled as
>
> {11 : 17} or {11 : -17}
>
>
> - I think the current draft and Göran’s ‘hpke-alg' suggestion both
> lack a definition of the HPKE AEAD used for the Seal operation.
> I do not think the HPKE AEAD follows from the HPKE KEM ID.
Yes, HPKE actually has three algorithm constants (KEM, KDF and cipher),
and to make things even more confusing, some KDF operations do not use
the KDF, but potentially different KDF dicated by the KEM used.
If one could require that the two KDFs are always the same, then this
would drop the number of distinct algorithms to two, and those two
would map neatly into key and message parts. However, if HPKE ever
gets a KEM that uses KDF it does not know about, then that could not
be used (no such thing exists currently; all current KEMs use
known KDFs). Additionally, I am not sure allowing the KDF to vary
is cryptographically kosher, fixing it in key would take care of
that.
Analyizing how HPKE uses types, most things SealBase/OpenBase deal
with are octet strings, except:
- The public key input for SealBase is abstract.
- The private key input for OpenBase is abstract.
- SealBase returns two octet strings, which go into different
outputs of OpenBase.
If using NIST curves, the first of the two octet strings returned by
SealBase is uncompressed elliptic curve point. It could be compressed,
but not made compact: The key derivation uses the sign of that point,
even if it does not depend on the sign of the final shared point. This
could be solved by defining HPKE KEMs that are duplicates of NIST curves
with compact encoding.
And the public key being abstract brings its own set of issues, as
different HPKE keys may have different key types:
- NIST curves are EC2.
- Compact NIST curves versions would be OKP?
- CFRG curves are OKP.
- Future PQC KEMs from NISTPQC will be OKP.
And one presumably can not assume that COSE curve will uniquely map to
HPKE KEM. So it looks like one would need to introduce HPKE key type
field.
And HPKE also has mode where it performs direct key generation (which
does not need specified cipher, only KEM and KDF, the latter of which
might be cryptographically unsound anyway). So there could be one
codepoint for HPKE with direct keygen. For key wrap, one would need to
specify the keywrap algorithm too.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
