Hello Uri,
On 4/22/26 21:52, Blumenthal, Uri - 0553 - MITLL wrote:
There can be arguments about the life expectancy of hybrids - from
zero to CRQC appearance - but can be no objection to the point that
once CRQC is here, only pure PQ will make sense.
With respect, I suspect that there there will be measurements rather
than mere speculative arguments.
The life expectancy will depend greatly on such a machine existing, who
has such a machine, who is willing to reveal that they have such a
machine, how efficient and/or useful it is for practical attacks, and
most importantly if the PQ cryptography actually survives contact with
that reality. The latter point seems particularly challenging as a
discussion point.
Something that I haven't seen raised in this discussion is a possible
middle ground where we see something like the proposed
TWINKLE[0]/TWIRL[1] machines where breaking a single key may be feasible
but cost prohibitive at scale. Those proposed systems did not force RSA
into retirement. Meanwhile, LOGJAM[2] resulted in RFC8270 rather than
RSA's end.
There are several kinds of PQ failures that we have seen, additional
failures that we expect to see, and a few that many of us hope won't
happen at all. SIKE remains a humbling example that is seemingly avoided
in many of these discussions.
Thus, arguing against pure PQ makes no sense in my opinion: you may
be able to delay long enough to avoid hybrids, but there’s no way
you’d avoid pure PQ. — Regards, Uri
As of today, there isn't a quantum computer that is public and breaking
ECC. We are fairly confident that ECC is secure today modulo various
kinds of NOBUS and other kinds of cryptographic sabotage. We are also
fairly confident that ECC will fall eventually if there is a quantum
computer. Most people are confident that there will be a relevant
quantum computer and that we should prepare. It seems odd to prepare by
increasing the risk of attacks by computers that already exist today.
A non-exhaustive list of ways that one might avoid pure PQ:
- if the PQ crypto fails as SIKE failed
- if some or all of Peter Gutmann's criticisms about CRQCs are correct
- if the PQ crypto fails in a novel way that CRQCs enable
- if the it is impractical to break both ECC and the PQ during the
window in which it matters
- if the PQ crypto deployment gives adversaries an opportunity to
sabotage previously functional cryptography and thus break security
- recommendations and/or regulations that impose a hybrid requirement
Hybrid compositions make sense for encryption and for signatures.
Attacks with a quantum computer to break the cryptographic encryption or
signature system(s) may be roughly the same but I am not convinced that
the consequences are equal. It is remarkable that signature forgery
isn't considered more of a concern than HNDL.
Arguing for a belt rather than suspenders and a belt is often a
reasonable fashion choice but is it an equally secure and resilient system?
Kind regards,
Jacob Appelbaum
[0] https://en.wikipedia.org/wiki/TWINKLE
[1] https://en.wikipedia.org/wiki/TWIRL
[2] https://en.wikipedia.org/wiki/Logjam_(computer_security)
On Apr 22, 2026, at 13:25, Nicola Tuveri <[email protected]>
wrote:
Hi Rich, thanks for your clarification, indeed my phrasing was
not ideal. I’ll take your comment as a chance to clarify my
stance. Code point assignment and deployment support are distinct
considerations. In practice, non-experimental production
ZjQcmQRYFpfptBannerStart This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
Hi Rich,
thanks for your clarification, indeed my phrasing was not ideal.
I’ll take your comment as a chance to clarify my stance.
Code point assignment and deployment support are distinct
considerations. In practice, non-experimental production
deployments generally rely on both assigned code points and a
published standard.
Concerns about the proliferation of standards introducing support
for additional code points are not uncommon on this list. I note a
similar concern here in support of delaying this draft.
At present, the process risks creating the impression of a “first-
to-standard” outcome, where publication effectively determines the
direction of deployment before the trade-offs have been fully
examined, possibly even stalling the progress of other drafts. In
particular, the argument that introducing additional options
increases complexity has been raised repeatedly on this list, but
it does not seem sufficient on its own to guide decisions in a
security area WG. It would be preferable to more explicitly
evaluate the security properties of hybrid and non-hybrid
approaches and reach a position that can inform what should-and
should not-be advanced to standard.
Best regards,
Nicola Tuveri
On Wed, Apr 22, 2026 at 19.30 Salz, Rich <[email protected]
<mailto:[email protected]>> wrote:
* I have read the draft, but I do not support its publication at
the moment.
* My rationale is that this draft adds complexity by adding extra
code points for pure mldsa.
Code points are assigned when a stable reference is available, as
you might recall from the long threads on the pure ML-KEM draft.
So I don’t think your stated rationale makes sense.
_______________________________________________ TLS mailing list
-- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list --
[email protected] To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
