Do not agree several points about the value of hybrid and its complexity.
> And for short term protection there is no point in dual signatures, if a CRQC
> is available the classic part is irrelevant. And until a CRQC is available
> the QR part is redundant.
The point is: Customers (and also professionals, like experts here) do not
exactly know when CRQC will be available. So, there is a long period up to
years for such uncertainty. For example, if this uncertain period is 2030-2035,
what customers should do in 2030 or 2031?
- Choice A: Just keep traditional cryptography for the services and systems,
but do nothing on PQ migration. Then, they may lost their business soon due to
either their competitors supporting PQ or losing their business in reality for
CRQC appearance.
- Choice B: Migrate to pure PQ solution from now. Yes, good. However, the
majority of professionals (at least in IETF and cryptography community) do
think that PQ algorithms are not yet as mature as traditional ones. So just bet
on the security of one single PQ algorithm may be risky. I would like to assign
a probability of 10^{-2} for such a risk, if a number is good for illustration,
while a mature traditional algorithm may just have the risk probability like
10^{-3} or even 10^{-4}.
- Choice C: Hybrid (including dual or composite signatures etc), which is a
conservative and balanced approach, but also an improving one. (PQUIP has
several good documents on this line). The simplest reason for this hybrid is
that it can improve practical security level, i.e., reduce risk probability.
For a right hybrid solution, once the above traditional algorithm and PQ
algorithm are used via hybrid, the resulting services or systems will only have
only risk probability as low as 10^{-5} or even 10^{-6}. Namely, risk only
happens if both algorithms fails. This is actually a huge security improvement,
compared with the risk probability of 10^{-2} for pure PQC solution, in this
simulated setting. After a number years of time testing, such systems can
update to pure PQ algorithm or even PQ+PQ hybrid solution when a CRQC arrives
ore nearly arrives. In particular, businesses demanding high security will
benefit from hybrid.
(I would like to call this as a little new "theory" about PQ migration. I will
be happy to explain more later.)
The blog at https://blog.cr.yp.to/20251004-weakened.html gives much more
reasons and cases with details, on a similar topic: "It's normal for
post-quantum cryptography to be rolled out as an extra layer of security on top
of traditional pre-quantum cryptography, rather than as a replacement."
Yes, just like you, many may say Choice C (Hybrid) will increase migration
complexity.
> I think this will just add complexity with no value, complexity means more
> bugs and more ways to screw up, and must always be justified.
Yes, complexity or performance overhead will be introduced. But, it may be not
that much. As I remember, both AWS and Cloudflare did some experiments a few
years ago, which showed that network performance for employing PQ (or hybrid)
normally drops something like 10%. By considering the continuous hardware
updates, this is not a big issue. In real application, migration complexity is
tightly related to soft engineering, it would be hard to analyze in a simple
way. However, at the protocol level (the target of IETF), I do think it is not
too much complex, compared with pure PQ solution. Three examples.
1) TLS takes concatenation way to do hybrid key exchange (KE), so this mainly
means to add a new KE algorithm ID for a hybrid algorithm combination (say
ECDH+ML-KEM). It do not introduce essential change for either the TLS protocol
or implementation/crypto library.
2) IKEv2 does this differently as the first IKE_SA_INIT exchanges can not be
fragmented. So, PQ KEMs will be run after ECDH has been run first. Though this
introduces more interactions between two peers, IPSECME WG reached its
consensus on this approach and published RFC 9370, in May 2023.
3) The last one, Composite ML-DSA for use in X.509 Public Key Infrastructure
(draft-ietf-lamps-pq-composite-sigs-12). It is well known in IETF that this is
a tough work for the author team and also for the group. However, IMO, here are
the two main reasons: a) ML-DSA defined two private key formats and several
variants for this "one" particular PQ signature algorithm. b) It is the first
try for defining PKI with composite or hybrid signatures. For future ones, a
lot of experience learned will be helpful and save our energy.
> - If a CRQC is expected soon all this work is net overhead for basically no
> gain as classic signatures will be obsolete quickly, and going though
> composite signatures will cause dual migrations classic -> composite ->
> pureQR, which is operationally expensive and doubles the pain.
"If a CRQC is expected soon ... ": This just one case, with very small
probability. So, more is about the case if a CRQC will come 10 or 15 years
later. We and customers should concern much more for this case, as it is
expected to happen with big (if not overwhelming) probability. As explained the
above, "soon all this work is net overhead for basically no gain .." may not
really true, as hybrid improves system security level, and also boosts the
research and standardization of generic hybrid approaches, including PQ+PQ
solutions.
First of all, " dual migrations" and "composite" may be treated in the same
category, as both are concrete ways of realizing hybrid. "will cause dual
migrations classic -> composite -> pureQR, which is operationally expensive and
doubles the pain." Not really, if my explanation the above sounds right. From
now, it may be more practical to expect that all those approaches will be
supported simultaneously in most applications. So, essentially one surgery for
all pain. For those with strong confidence in a single PQ algorithm, no
problem, just go ahead, if they have no concern on the issues like the
difference between risk probability of 10^{-2} and 10^{-5}.
> - If a CRQC is not expected soon, then rushing into composites is also not
> useful, it is better to stay on a classic signature until the time pureQR are
> trustworthy enough to do the migration once.
The above explained already. The PQ migration has a long period of uncertainty.
A lot of customers may like to brace the benefits of both traditional
cryptography and PQ algorithms, especially in this long uncertain period.
> Because I do not see a cryptographic relevant justification I am somewhat
> against adding composite signatures to JOSE (can't speak about COSE because I
> am not as familiar with its application space).
Read the above blog and several documents in PQUIP should help, I think. On the
other hand, this document does not give much justification why PQ or why hybrid
approach, as it supposes that the background more or less like explained the
above.
Guilin
-----Original Message-----
From: Simo Sorce <[email protected]>
Sent: Saturday, 18 October 2025 3:42 am
To: Lucas Prabel <[email protected]>; Orie
<[email protected]>; John Mattsson <[email protected]>
Cc: [email protected]; [email protected]; cose <[email protected]>
Subject: [jose] Re: Call for Adoption request:
draft-prabel-jose-pq-composite-sigs-04
Lucas,
while LAMPS may have different needs, I do not understand what composites bring
to JOSE or COSE, the JWT and JWS tokens are generally short-lived entities,
therefore there is no need for long term protection against CRQC.
And for short term protection there is no point in dual signatures, if a CRQC
is available the classic part is irrelevant. And until a CRQC is available the
QR part is redundant.
I think this will just add complexity with no value, complexity means more bugs
and more ways to screw up, and must always be justified.
Additionally, in terms of timing:
- If a CRQC is expected soon all this work is net overhead for basically no
gain as classic signatures will be obsolete quickly, and going though composite
signatures will cause dual migrations classic -> composite -> pureQR, which is
operationally expensive and doubles the pain.
- If a CRQC is not expected soon, then rushing into composites is also not
useful, it is better to stay on a classic signature until the time pureQR are
trustworthy enough to do the migration once.
Note that for a PKI infrastructure that provides CA certificates that have a
long life the considerations may be quite different, so LAMPS has more reasons
to entertain composite signatures at least for CA certificates.
Because I do not see a cryptographic relevant justification I am somewhat
against adding composite signatures to JOSE (can't speak about COSE because I
am not as familiar with its application space).
Simo.
On Fri, 2025-10-17 at 15:35 +0000, Lucas Prabel wrote:
>
>
> Hi Orie, thanks for your feedback.
>
> I think the point about the specific use cases is not specific to hybrid
> composite signatures, but could also be raised for pure PQ signatures, which
> didn’t prevent the COSE ML-DSA draft to be adopted by the COSE WG.
>
> The LAMPS composite draft has already been adopted and is in WGLC. Given the
> 2030 migration timelines announced by several security agencies and
> organizations, I also believe waiting too long to standardize such mechanisms
> could make it difficult for some systems to achieve compliance in time.
>
> Best,
>
> Lucas
>
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
