On Sun, Mar 26, 2023 at 07:33:10AM +0900, Orie Steele wrote:
> Should post quantum keys use "the old way" or "the new way" or
> "both / it depends" ?
It depends.
This may sound very anticlimatic, but key types need to be designed
around needs of algorithms, such as:
a) How are the keys used in COSE / JOSE? Are there multiple uses unified
by some larger family, or only a single use?
b) Is there only a single alg that makes sense with each individual key,
or are there multiple?
c) Are there no parameters, a small set of possible parameter sets, or
more complex parametrization? Is there already registry for possible
parameters?
d) What are the components of private/secret/public key and what are the
types of those components?
e) What hints would be useful (extra info to improve interop, but not
absolutely required for things to work)?
Designing key types without knowing how the keys are actually used in
COSE / JOSE is fraught with danger. It is very easy to make a subtle
mistake that ruins the design, but isn't discovered until it is too
late.
Let's analyze a number of different things around those axis:
1) RSA:
a) There are multiple different uses, unified around RSA.
b) Multiple.
c) There are no parameters.
d) There are 2 or 7 positive integer components in private key
(depending on if CRT speedup is used or not) and 2 positive integer
components in public key. All the components are potentially large
numbers.
e) There are no hints.
The RSA key type in COSE / JOSE is designed along these lines.
2) Short-Weierstrass ECC:
a) There are multiple different uses, unified around ECC.
b) Multiple.
c) There is more compicated parametrization, but only a small set
of parameters in common use. No existing registry.
d) There is one positive integer component in private key, and 2
nonnegative integer components in public key.
e) There are no hints.
The EC/EC2 key type in COSE / JOSE is designed along these lines.
3) HSS-LMS:
a) There is single use, as signature.
b) Single.
c) There is small set of possible parameters. There is already a
registry.
d) Private keys are not representable. Public keys are one byte string
component.
e) There are no hints.
The HSS-LMS key type in COSE is designed along these lines.
4) X25519/X448:
a) There is single use, as DH function.
b) Multiple.
c) There are no parameters,
d) Private and public keys are both one byte string component.
e) There are no hints.
The OKP kty in COSE / JOSE is designed for this type of thing
(b through e)
5) EdDSA:
a) There is single use, as signature.
b) Single.
c) There is small set of parameters. There is no existing registry.
d) Private and public keys are both one byte string component.
e) There are no hints.
COSE / JOSE also throw these to OKP, but the design could have been
very different.
6) Kyber:
a) There is single use, as KEM.
b) Multiple.
c) There is small set of parameters. There is no existing registry.
d) Private and public keys are both one byte string component.
e) There are no hints.
This is still a great match to what OKP was designed for. However, in
COSE this is likely unnecressary, as PQ HPKE should appear soon. In
JOSE, likely needed, because combining JOSE and HPKE turns out to be
Hard (while the Kyber in JOSE seems straightforward extension of
ECDH-ES).
7) Dilithium, Falcon and Sphincs+:
a) There is single use, as signature.
b) Single.
c) There is small set of parameters. There is no existing registry.
d) Private and public keys are both one byte string component.
e) There are no hints.
The answers to questions are identical to EdDSA! The very different
design mentioned in EdDSA is actually what is employed by the COSE /
JOSE PQ signature drafts (split to three ktys with horrible naming).
8) HPKE:
a) There is single use, as asymmetric encryption.
b) Single in COSE, the JOSE case seems Too Hard.
c) More complex parametrization: A single integer, picked from existing
registry. In some cases, reprurposing other keys is possible.
d) Private and public keys are both one byte string component.
e) Supported KDF and AEAD. In case of converted keys, supported KEM.
In case of converted keys, this adds common key parameters for the
hints. In case of dedicated keys, this would argue for design like:
kty: HPKE
kem: uint
priv: bstr (private keys only)
pub: bstr
Plus common key parameters for KDF / AEAD hints.
As for the HPKE JOSE case being too hard, I have come to conclusion that
I don't have any idea on how to integrate HPKE into JOSE in any sort of
even remotely clean manner. Thus, I have given up working on it, at
least until somebody comes up with a breakthrough.
Commenting on the keys from various drafts:
- PQ signatures work:
The kty naming is horrible, but otherwise looks good. There is a
decision on if to have one or three kty's.
- Kyber:
OKP can't be used that way. However, if "lat" was replaced by "crv"
(looks odd, but works as intended), it would look good.
- HPKE:
The JOSE case is fraught with danger because it is not clear how HPKE
would be used in JOSE, and if that would need to be reflected in the
key format.
The COSE case is clear. The current draft has issue where it
mishandles KEM in both dedicated and converted key cases:
* In dedicated key case, KEM is key subtype, and should not be grouped
together with hints (KDF/AEAD).
* In converted key case, KEM is also a hint, like KDF and AEAD. It can
have mulitple values.
-Ilari
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
