Re: [COSE] Updating the COSE alg registry for HPKE

[Ilari Liusvaara <[e-mail]>]

On Wed, Jul 05, 2023 at 04:31:37PM -0500, Orie Steele wrote:
> Inline:
> 
> On Wed, Jul 5, 2023 at 12:59 PM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > On Wed, Jul 05, 2023 at 05:03:28PM +0000, lgl island-resort.com wrote:
> >
> > There would currently be 2. Little idea about what happens in the
> > future. I would imagine there will be at least:
> >
> > - X25519+MLWE-KEM-768
> > - P-384+MLWE-KEM-1024
> > - X448+MLWE-KEM-1024
> > - MLWE-KEM-1024 (CNSA2)
> >
> >
> https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids
> 
> So far I only see X25519Kyber768Draft00 ...
> https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/02/

Well, yeah. MLWE-KEM (or whatever) is due 2024, as standardized version
of Kyber.

 
> I have no idea how to represent keys for this using JWK or COSE Key, but
> the current draft seems compatible with either "alg" or "sender info / hkc"
> approach.

{
   "kty":"HPKE",
   "kem":48,
   "pub":"some_base64url_gunk"
}

(Add priv for private keys, translate to COSE in the usual way.)


> > And while inferring KEM from key is regarded as too complex, I think it
> > is technically possible.
> >
> >
> It's especially possible in the case that you meant "key serialization" as
> in "JWK" or "COSE Key".
> 
> It remains better to be explicit, in case some variant of P-256 DHKem
> emerges in the future...
>
> which could happen, as soon as the HPKE registry takes an update (notice
> that the draft for x25519 + kyber hybrid scheme has already been added to
> the registry).

There is already HPKE extensions draft, which adds a second KEM
compatible with P-256/P-384/P-521. That can be detected from length of
encapsulated key (32/48/66 vs. 65/97/133).

A really nasty one would be another KEM with the same EK length but
different internal KDF (e.g. based on SHA-3 instead of SHA-2). That
could cause some major pain without having full KEM identifiers.

 
> There have been critical security bugs related to not validating key to
> algorithm bindings.
> I'm not asserting this kind of thing applies to DHKems, or composit /
> hybrid kems....
> I don't know if it does, or if feeding different encapsulated keys that
> don't match the kem id does anything useful, other than error...
> (regardless of twisting or hybrid stuff used).
> 
> https://crypto.stackexchange.com/questions/43132/is-elliptic-curve-diffie-hellman-ecdh-still-secure-if-i-use-the-public-key-mor

It is actually possible to have nasty cases, even with ECDH.

It is possible to come up with (pathological) ECDHKem BAD such that:

- If used with legimately generated keys, BAD is roughly as secure as
  x25519.
- BAD keys and ciphertexts have the same length as x25519 keys and
  ciphertexts.
- If one tries to encrypt using BAD with x25519 key, there is about
  50% chance that the result is easily breakable.

Now, such KEM would look somewhat suspicious, but one could design
less suspicious KEM that interacts badly with something else. Esp.
compact version of P-384.

As for non-ECDH KEMs, those could react badly to algorithm mixup just
by accident.


> > > There’s a lot of flexibility if this doesn’t suit your use case.
> > > The COSE IANA alg registry ranges from the private use (less than
> > > -65536) that has no requirements to a full IETF standard. Note
> > > that the recent Chinese algorithm registration was content with
> > > specification required.
> >
> > I much rather have these _not_ have a specification, as that would
> > make it possible for there to be a special snowflakes, which would
> > cause a lot of pain for anyone implementing those.
> >
>
> I don't follow... Can you restate what you mean here?

For example, anything that sticks the encapsulated key into different
place compared to the rest. For whatever reason.
 

> > > I would expect final agreed-upon HPKE PQ algorithms would come in
> > > as informational RFCs since HPKE and RFC 9053 are informational.
> > > For something as important as this, I would think the informational
> > > RFC process is about the right level. There should be a good public
> > > discussion and agreement.
> >
> > There is already Kyber I-D, that is intended to serve as precursor to
> > MLWE-KEM (or whatever it is). For asymmetric encryption, it essentially
> > says "Use HPKE". Intended status is informational RFC.
> >
> > It forms the basis of current post-quantum algorithm in HPKE.
> 
> Where are you getting the term "MLWE-KEM" from?

I vaguely remember some discussions about what the eventual standardized
version of Kyber (and Dilithium) will be called. 

MLWE stands for Module Learning With Errors.




-Ilari