Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

[Rafael Misoczki <[e-mail]>]

Re: creating a kty for PQC algorithms (or any other way of grouping these
algorithms to indicate they are PQ-secure), two things to consider:

- These algorithms are *currently* classified as post-quantum secure, and
the truth is that we can't guarantee this property in the long-term. As an
example of how these things may change quickly, we just saw a *3rd-Round
Finalist* candidate (Rainbow <https://www.pqcrainbow.org/>) being subject
to a devastating *classical* attack <https://eprint.iacr.org/2022/214.pdf>.

- Only very carefully selected parameters lead to instances of these
algorithms which can be (currently) called post-quantum secure. If
the community/NIST ends up standardizing parameters with overestimated
security, this may lead to quantum vulnerable instances of these algorithms
in this group of PQ-secure algorithms while they are not PQ-secure.

Just some food for thought for the situation where these algorithms are
grouped with some indication they are "PQ-secure" but later on we found
they are not. There might be some benefits for not officially labeling them
as "PQ-secure" in any way, and instead only indicate what is the underlying
class of problems (e.g. lattices, or hash, or isogney, etc).

On Fri, Mar 11, 2022 at 11:34 AM Anders Rundgren <
[e-mail]> wrote:

> Hi Ilari,
>
> I fully understand what you are saying and how OKP was supposed to work.
> That everything in crypto-land isn't great is also true.
>
> However, overloading established identifiers is seldom a good idea because
> it obviously requires changes in well-functioning code.
>
> I also believe that from a marketing point of view post-quantum algorithms
> may be entitled their own "kty" :) If it is sufficient with one is beyond
> my insight in the matter...
>
> In the draft I also found additional optional fields which doesn't have an
> OKP counterpart.
>
> Cheers,
> Anders
>
>
> On 2022-03-11 17:11, Ilari Liusvaara wrote:
> > On Fri, Mar 11, 2022 at 05:23:48AM +0100, Anders Rundgren wrote:
> >> Before deciding to overload "OKP" for a new crypto system, I would
> discuss the matter with maintainers of cryptographic libraries and APIs.
> >>
> >> In the Java platform overloading the native counterparts to OKP keys
> >> [1,2] won't happen because that would break a lot.  I guess the same
> >> is valid for OpenSSL.
> >
> > The way it is supposed to work is to use the raw key parts as key
> > material in underlying cryptographic implementation. Implementations
> > where that is not possible are just broken.
> >
> >> It seems to me that reusing OKP would rather create an artificial
> >> "semantic gap" which doesn't exist today where "kty" indeed is
> >> synonymous with key type/family (RSA, EC, Ed etc):
> >> https://datatracker.ietf.org/doc/html/rfc7517#section-4.1
> >
> > There are already two "subtypes" of OKP keys that are not
> > interchangeable:
> >
> > - Key agreement keys.
> > - Signature keys.
> >
> > NISTPQC signatures would fit into signature keys "subtype", but NISTPQC
> > KEMs will not fit into the key agreement keys "subtype", so that would
> > be a third "subtype" (all NISTPQC algorithms have OKP-style key format,
> > as this was required by NIST).
> >
> >
> > This is very different from RSA and EC2, where there are no subtypes,
> > and all keys are interchangeable.
> >
> >
> > Another place similar multi-subtype non-interchangeable keys are seen
> > is symmetric algorithms, as there are at least two "subtypes":
> >
> > - AE(AD) Encryption keys.
> > - MAC keys.
> >
> >
> >
> > -Ilari
> >
> > _______________________________________________
> > COSE mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>