Hi Nico,
On 7/17/26 07:35, Nico Williams wrote:
On Fri, Jul 17, 2026 at 12:52:05AM +0200, Jacob Appelbaum wrote:
On 7/16/26 21:57, Nico Williams wrote:
The objective answer is that the horse left the barn two
decades ago when the IETF decided to get out of fighting
about national cryptographic standards, therefore Deb's 37
years at the NSA are irrelevant in this case, and you're
fighting the wrong battle if you want to change that two-
decade-old decision.
That is not correct and the ISE could easily publish the
drafts under discussion without consensus as Rob suggested
more than a week ago.
Has that not been opposed too? / The relevant decision-makers
would be the authors and the Independent Submission Editor. I
have not seen a definitive objection from either, and I
understood Eliot to be open to considering the idea.
Would that not be opposed too? It could certainly be opposed.
What kind of opposition do you mean?
Rob's (it was Rob, right?) suggestion appears to be a viable
fallback. The Independent Stream does not require IETF rough
consensus, although it is not an automatic bypass: the authors and
ISE would have to pursue it, and the IESG would still conduct the
RFC 5742 conflict review [0][1]. I note that the authors have
largely not engaged in discussion.
I swear I've seen arguments that users of RFCs don't really
understand these subtle differences in track and editor queues,
that they take any RFC as a 'standard'.
Yes. Many readers treat any RFC number as a standard despite the
stream boilerplate. That is a real drawback, but it is also why
the distinction matters for _us_: Independent Stream publication
would not assert IETF consensus. In practice, I suspect very few
outside of the IETF would care about the distinction. It would
allow us to provide clarity when the matter is raised.
I still prefer resolving the issues in the working group. I am
not opposed to publication; I am trying to identify text that
makes publication responsible.
What you're really litigating is a social death penalty for
the NSA -- something we *could* do, but shouldn't. We
really, really shouldn't do that for at least several
reasons, such as:
You may be surprised but I very strongly agree with you. We
should not litigate a social death penalty. I do not advocate
for removing Deb from the IETF. No one should be harassing
her. No one should be making threats. No one should be giving
her a hard time. No one should be mocking her on social media.
No one should be sending threatening or slanderous or libelous
emails.
It's not just the invectives against Deb. It's also the
invectives against the I-D authors and those who have voiced
support for the I- D.
I extend that to everyone: Deb, the authors, supporters,
opponents, and other participants. We need more technical
communication, not threats, harassment, ostracism, or censorship.
I have received several reports of troubling off-list conduct.
That should be handled through the appropriate conduct process
rather than mixed into the technical disposition of the drafts. It
is unclear to me if those reports will by sent by those persons to
the IETF out of (expressed to me) fear of retaliation.
The incessant urging to not publish anything that might be
tainted by the NSA *is* very much akin to a social death penalty
for the NSA.
I do not oppose publication because NSA personnel were involved.
The immediate concern is a documented NIST design decision: FIPS
203 removed Kyber's `m <- H(m)` step, whose stated purpose was
protection against flawed randomness, because FIPS 203 requires
approved randomness generation [2][3]. The question is whether
IETF documents should repeat that assumption silently or not,
describe and explain the peer- recoverable value, and preserve a
cheap local safeguard for deployments that do not satisfy the full
FIPS model.
It is indisputable that NIST removed the hash over `m`, ignored
all pushback, ignored official comments on the matter, and
unrelated to much of the discussion they then also declared that
non FIPS-certified settings are expected to simply fail
catastrophically if the RNG has an issue. So you see, removing the
hash and qualatatively weakening the design of Kyber, they assert
is fine. That they accept this outcome and state that they are
correct was explictly stated by NIST on this very list. They
additionally also push this without a hybrid construction, also
over the express concerns of the authors of Kyber. Those two
things together and my ability to exploit ML-KEM in the
Dual_EC_DRBG setting correctly raise eyebrows.
NSA involvement is relevant historical context, but it is not a
social veto. NIST is not the final technical authority for the
IETF, any more than BSI, CSE, ETSI, ISO, IEEE, or a corporation
would be. Former NIST people dropping by to argue that the world
should adopt their public security posture is unreasonable. They
have a traditionally had the Suite A and Suite B security postures
and we're being offered the B option by another name, again. The
IETF should have a stronger security posture and wihtout being in
a FIPS-certified setting. The same scrutiny should apply to every
source: examine the design, assumptions, evidence, and
consequences for the end user.
The still-incomplete public record concerning NIST/NSA
coordination and the answers given in this discussion make careful
review more, not less, appropriate. I would also welcome explicit
clarification of the IPR position, although the current drafts do
not resolve it.
Comments that are not made by NIST have not brought clarity
because any such analysis carries no weight about NIST's actual
position. If NIST makes clear that we are free to hash `m` and
retain the IPR waiver, we would be able to resolve the issue of
excess authority preventing a stronger security posture, if it is
desired. Do you see that they are unwilling to bring this clarity?
If they were gagged as John Kelsey was, I would expect that
bringing this clarity would be out of bounds. NIST is free to say
otherwise and what they did say on the matter is contridicted by
the public record. It could be credibly explained but NIST did not
deem it worthy of their time.
The American cliché "good enough for government" is the phrase
that comes to mind here. Is that good enough for the IETF? No, it
is not.
People should *especially* not be punished for the worst thing
they are suspected of doing, and especially if they did not do
it.
Even if they are guilty, they deserve a chance at redemption.
Everyone deserves a fair shot at re-integration.
For those who say TL;DR, the summary is that: IMO the ML-KEM I-D
- and all I-Ds specifying KEMs- should normatively state which
DRBGs are acceptable, and they should include informative text
about the unfortunate risk of RNG-based kleptography when using
KEMs outside DH hybrids.
I broadly agree, with the qualification if 'acceptable' is stated
as a 'MUST' or a 'requirement imposed by NIST to achieve security'
and that a hybrid does not help if both components depend on the
same recovered RBG lineage.
Ok then, here's my take:
* Ideally we should have a practical, strong PQ Diffie-Hellman.
We do not. I agree in the strongest terms. Practical post-
quantum constructions with genuine Diffie-Hellman-like
contributory behavior remain an important research goal.
MIKE seems interesting but I have not analyzed it, evaluated it,
used an implementation in a deployment.
CTIDH is somewhat more familar to me and while there is literature
that is relevant for the security in the quantum setting, I find
it to be extremely promising.
CTIDH and related commutative group-action work are interesting in
that respect. I help maintain an implementation released by an
academic group, but I did not design CTIDH and make no claim that
it is ready to replace standardized KEMs. In my own experimental
use I combine it with X25519.
More generally, I would not deploy a comparatively young post-
quantum construction without an independently generated classical
component today. On balance I have decided that in at least two
protocol withs no other PQC option available, a hybrid X25519 and
CTIDH-512 or CTIDH-1024 were better than X25519 alone. This
protects against CTIDH failures today, and hedges against a future
with quantum computers.
* All KEMs are going to have this `m` problem in some fashion.
Is that a correct statement? That makes all of them suitable
for RNG- based kleptography. I do not think that all KEMs
necessarily have the same problem. We need a precise property:
can an adversarial recipient recover an unchanged, sufficiently
large, ordered sample of the sender's RBG output?
ML-KEM clearly exposes that shape in the most risky way possible
and it is unnecessary risk. To recap before we en-and-de-cap: `ML-
KEM.Encaps` samples a 32-byte `m`, and a decapsulating peer that
controls its implementation can retain the reconstructed `m'`.
Third-round Kyber instead hashed `m` before using it [2][3]. Other
KEMs and their uses have to be analyzed construction by
construction; a ciphertext carrying a recoverable secret is not
necessarily carrying raw generator bytes.
In addition to Kyber where everything is essentially equal except
the hash in our discussion, sntrup761 is a useful contrast. It
uses a structured fixed-weight ternary polynomial `r`, not a raw
32-byte `m`. In the reference sampler, many 32-bit random words
are masked, sorted, and mapped into the ternary polynomial before
`r` is used, and the shared key is derived by hashing its encoding
[4]. The recipient can recover `r`, but `r` is not an unchanged
contiguous generator block. The difference is extremely stark.
That does not prove immunity to every malicious or specially
shaped RBG. It means only that the direct ML-KEM argument does not
transfer unchanged. I made a preliminary attempt to recover a
Dual_EC_DRBG block through this sampler and did not succeed. I
would welcome a better analysis, especially from the sntrup761
authors: do you see a practical method for reconstructing a full
Dual_EC output block from the existing fixed-weight sampler? The
sntrup761 authors and implementations could also hash the RNG as
Kyber did to make the comparison even easier. Regardless, NIST and
a couple of other people may discuss the construction of `m` and
KEMs in a way that would lead a reasonable person to believe a KEM
always has this issue. However, it is simply not true. A KEM does
not imply an `m` must be composed of contiguous sample of the
system RNG without transformation, otherwise. It is misleading and
it is dangerous as I have shown with Dual_EC_DRBG as an example.
In TLS this can lead to decryption of the connection, and future
sessions. This is acceptable to NIST, and it should not be to the
IETF.
This difference is one reason I remain comfortable with
sntrup761x25519 as a conservative OpenSSH option. The ML-KEM SSH
exchange, like TLS, gives an unauthenticated client an opportunity
to supply the encapsulation key and recover the server-generated
`m` pre-auth; the actual risk still depends on the
implementation's RBG, state separation, and generation order. This
is a kind of landmine where it increases analysis work and where
implementations may get it wrong. It is not the conservative
choice that I would expect from the professionally prudent
securtiy minds that brought us OpenBSD and OpenSSH.
It however entirely makes sense if OpenSSH needs to provide ML-
KEM. I hope that they will ensure that `m` is hashed in practice
but if not, it only further underscores why the NIST's decision
process and their conclusion is unreasonable. OpenSSH is not only
used in a FIPS-certified setting, and I highly doubt that NIST
will promote the various DRBGs used by GNU/Linux, FreeBSD, NetBSD,
and OpenBSD as qualified designs. I would welcome it as long as
they did not impose unreasonable changes as they did with Kyber
for `m` since those designs are what the world uses.
For this reason I think we should have no RECOMMENDED=Y non-
hybrid KEMs. But I don't see why not have RECOMMENDED=N KEMs.
Interesting. I support hybrids as the conservative default, but
the hybrid label alone is not sufficient for this issue.
If the ML-KEM interaction permits recovery of an RBG state before
the same state lineage generates the X25519 scalar, both
components may be predictable. If the X25519 scalar was generated
first and the RBG resists backtracking, that component may remain
independent. Reseeding, per-connection state, buffering, and call
order all matter.
A compact version of my current classification is therefore:
scheme recoverable value raw RBG block? ML-
KEM 32-byte `m` yes Kyber r3
`H(m)` no sntrup761 fixed-weight ternary
`r` no
That table is deliberately narrow. I would not label every
randomized signature, OAEP seed, DH exponent, or structured KEM
secret as a "raw leak" merely because it depends on randomness;
the transformation and recoverability must be analyzed. I have
done most of that analysis on other IETF primitives but that is
for a different email.
* TLS 1.3 has insanely large nonces ('random'), and that's
enough for RNG-based kleptography.
Agreed. TLS `Random` fields already create a broader public-
output problem, and I regret not addressing it while TLS 1.3 was
being written. I am preparing separate work on public and peer-
recoverable RBG outputs across TLS, QUIC, MLS, SSH, IKE, and other
protocols. That broader work should not prevent fixing an
additional clean oracle now.
therefore ML-KEM adds nothing much new *except* that when using
a FIPS-140-3 validated module then ML-KEM can sneak a Dual_EC-
style DRBG in through the back door even when the TLS 1.3
implementation would not otherwise use such a DRBG.
The word "except" is doing substantial work in your sentence. ML-
KEM can expose an additional sample of the randomness used for
secret generation even when an implementation separates or
conditions other TLS-visible fields.
A successful sabotage mechanism should be reliable, economical,
and plausibly deniable. The protocol should not make that job
easier when a wire-compatible hash removes the direct structured
sample.
* We can insist that the choice of DRBG to use MUST be one of a
set we approve of, and, impliedly, none of the ones we don't
approve of. Agreed in principle. We should state the actual
requirement rather than invent combined algorithm names. FIPS
203 requires fresh randomness from an approved RBG, with the
required security strength, under the SP 800-90 framework [2].
Hash_DRBG, HMAC_DRBG, and CTR_DRBG are the SP 800-90A
mechanisms, but the requirement also includes the entropy source
and construction requirements in SP 800-90B and SP 800-90C.
I would then state the separate `m` issue. The approved-RBG
requirement is the primary layer; hashing `m` is a local layer
that prevents this consumer from returning algebraically
structured output to a peer when the primary assumption fails.
NIST and some of the IETF, such as myself, appear to have
different risk tolerances on that point. NIST has publicly
acknowledged the limited claim: hashing protected the KEM, while a
broken RBG could still compromise the wider system. That is not an
argument that the KEM-level protection has zero value but NIST
agreeing that it has value, and that it is not valuable to _them_.
Okay! I am glad that they did not present an attack as their
original motivation to remove the hash. It is not a security issue
to have the hash. It is good that we do not disagree on that
point. The performance was also not a relevant concern. Their
expressed concern is how they logically separate things in a
FIPS- certified setting, and outside of that setting, they
qualatiatively weakened the design and accept the consequences.
This tells us their security posture, and it is less than the IETF
should accept. These kinds of "logical" separations are how we had
IPsec failures with Dual_EC_DRBG on the internet that allowed for
full passive decryption through nonce leakage. This was reportedly
exploited by the NSA and it is not in dispute. Juniper engineers
probably deeply regret being tricked by that kind of mistaken
protocol and implementation design.
The public record concerning NIST/NSA coordination is, and
remains, incomplete. Materials produced through litigation appear
relevant to statements made during this discussion. My
understanding is that the litagion is ongoing and that production
of documented related to NIST/ NSA collaboration remains
unfinished. I do not need to resolve that institutional history in
this email. I do think NIST should answer concrete questions and
publish enough of the record for independent evaluation. We could
also wait for the lawsuit to finish but that is likely to take a
long time, so NIST could really help speed things up by either
stating their intention to 1) immediately and proactively produce
the documents in question and/or 2) directly engage here with the
understanding that if the documents later contridict them, they
will be on the hook. Both of those seem incredibly unlikely and
that is why an independent court has been involved to _force_ NIST
to produce the facts.
Does it not concern you that the facts _already_ produced in that
lawsuit do not match the claims made by NIST on this very list?
If not, what would be the line for you? I ask so that when the
lawsuit is finished, we may do a proper retrospective analysis.
The AES counter DRBG is plenty good enough. Which
implementation?
CTR_DRBG can be a sound construction, but naming it does not
guarantee a side-channel-resistant implementation. Cohney et al.
demonstrated cache- based recovery against vulnerable table-based
AES CTR_DRBG code in SGX, including state recovery, loss of
forward security, and an end-to-end TLS compromise [5]. This was
an implementation attack, not a universal break of CTR_DRBG. These
kinds of failures are possible because NIST's standards are below
the security and the quality of the IETF's standards. There are
examples worth considering such as the constraints described in
NIST SP 800-90a.
The distinction matters. FIPS 197 specifies AES, but does not by
itself require a constant-time implementation or test for secret-
indexed table lookups. SP 800-90A specifies the DRBG construction,
but cannot make a leaky AES implementation safe. Hardware
instructions can reduce this particular risk, while introducing
their own hardware and microcode assumptions. Would you believe
that one of the findings in [5] as presented in 2020 ( https://
rwc.iacr.org/2020/slides/Cohney.pdf ) included an OpenSSL FIPS
module, the NetBSD kernel systemwide PRG (!), mbedTLS _inside_
SGX, and also the nist_rng library. That includes a FIPS-certified
setting. Perhaps the FIPS-certified setting is not as strong as
the NIST advertising would have us believe?
NIST has not updated the corresponding standards in response to
the publication [5] as far as I am aware. I am happy to be
corrected on this point but if even NIST is able to get it right,
maybe we should consider this as a factor in their security
posture?
I want to note as a matter of honesty that here, hashing `m` does
not save a system after the attacker has extracted the CTR_DRBG
key; the attacker can reproduce the hash. It does, however,
address a different failure class: algebraic structure in output
that is otherwise handed directly to the peer. Therefore the
correct guidance is not "CTR_DRBG is broken" or "the hash fixes
everything." It is:
* exclude Dual_EC_DRBG and analogous structured generators; *
require a securely implemented, prediction-resistant RBG; *
require side-channel-resistant primitives and sound reseeding/
state management; * retain the local hash to avoid exporting raw
structure; * even NIST's standards and certified FIPS modules get
this wrong; * NIST updated their threat model in 2019; * NIST did
not update the actual standards to require safe defaults!
The longer document should review Hash_DRBG, HMAC_DRBG, and
CTR_DRBG, including side channels, fault attacks, entropy failure,
reseeding, and state compromise, rather than treating an approved
algorithm name as an implementation proof. The authors of [5] note
that CTR_DRBG is not provably secure, they note that Woodage and
Shumow found problems with HMAC_DRBG, and they encourage the use
of Hash_DRBG.
Note that the authors in addition to the "Dual_EC Backdoor" they
raise the "Juniper Dual_EC Incident" they also raise the DUHK
Attack on ANSI X9.31.
So - lets recap that into some conclusions: - No: Dual_EC_DRBG
(withdrawn (!)) - No: CTR_DRBG (FIPS certifiable (!!) does not
mean not exploitable) - No: HMAC_DRBG (see Woodage and Shumow's
related work, and others)
Meanwhile, NIST says they are working on an updated SP 800-90A
where they announced a comment period ( https://csrc.nist.gov/
pubs/ sp/800/90/ a/r2/iprd ) which closed in late 2025:
Date Published: September 4, 2025 Comments Due: November 4, 2025
(public comment period is CLOSED)
Aside from the absurdly short comment period, NIST says that
public comments will be posted after the closing date. Nearly a
year later, that statement remains true as someday they may be
posted. As of today, the public comments have not been posted as
far as I am aware.
Do you want to make a prediction about Hash_DRBG?
This, however, may run into a problem where FIPS-140-3 validated
cryptographic modules might not be configurable as to DRBG
choice. However, it is enough to state this requirement. We do
not have a Protocol Police function.
Agreed. Accurately summarizing the NIST requirement and adding
the right cross-references is sufficient for that part of the
issue.
* As long as there is one acceptable DRBG that can be selected,
we can state a normative requirement and give useful advice
regarding the dangers of RNG-based kleptography.
Agreed. I would list the approved constructions as examples,
state the required properties, and explain the kleptographic
failure mode.
* I do suspect that all KEMs enable Dual_EC-style kleptography.
And yet ML-KEM should be published. Not because that's a good
thing, but because -once more- the horse left the barn when the
nonces (`Random`) were made more than large enough and when the
codepoint registries were made Specification Required. I do not
think the general conclusion about all KEMs follows, but I also
do not think this is a reason to withhold ML-KEM indefinitely.
My request concerns an avoidable, wire-compatible footgun and
accurate Security Considerations, not ML-KEM's lattice hardness
assumptions.
But also I'd have to see how recovering *one* `m` value would
allow a kleptographer to steal *many* other clients' `m` values.
For Dual_EC_DRBG, the result depends on truncation and state
management. With an untruncated 32-byte output, one `m` may be
enough for the trapdoor holder to recover the next state. With the
standardized P-256 truncation, the attacker normally enumerates
the missing bits and uses another output or other state
information to identify the correct candidate [8]. Once a long-
lived shared state is recovered, later outputs may be predicted
until reseeding or separation defeats synchronization.
Or put simply: you draw 32 bytes from the sabotaged RNG, you
transmit it, you then draw 32 more bytes.
An adversary with the Dual_EC_DRBG trapdoor/secretkey(s) that
receives your first 32 bytes is able to predict the 32 bytes of
the second draw, even if you do not send them.
Would you like me to send you an implementation of this where you
control the trapdoor/secretkey(s)?
* The large size of `Random` is still problematic.
Agreed. I call these public or peer-recoverable wire oracles. TLS
1.1, 1.2, and 1.3 all expose large `Random` fields, and other
protocols can inherit related risks through TLS or their own
public randomness.
My broader survey remains preliminary because implementation
choices, state sharing, sequencing, and authentication phase
change the answer. If this attack class is deployed, however, the
strategic value for mass collection and real-time decryption could
be substantial.
[Heavy trimming follows.]
Thank you for tolerating my verbosity. I will try to return the
favor.
* If the NSA wants to get burned again by playing the
Dual_EC game again, let them!
This is frankly, reckless. We should not be used unwittingly
or be party to such folly.
My personal advice: sometimes that is the smart play -- if you
never engage in tactical retreats thus badly losing some
battles, you'll exhaust yourself and lose the war.
I take the advice. My claim here is bounded: we should learn from
Dual_EC_DRBG and treat it as the canonical public example of
strategic cryptographic sabotage. The tactical compromise I can
support is to publish after adding accurate RBG requirements and
the `m` guidance, while moving the larger analysis to separate
work.
I am exhausted, but that is another reason to turn the dispute
into specific text rather than continue repeating it.
* The NSA is not likely the monolith a social death penalty
for it would have to presume.
I do not understand this point but I agree that the NSA is not
a monolith. Part of asking the questions that I asked is that
there are NSA people I have directly spoken to who answered
almost all of those questions without a problem. I am not only
talking about whistleblowers but people whose job never
involved cryptographic sabotage.
But you and/or others in these threads are treating all involved
with NSA in regards to ML-KEM as monolithically motivated by the
same interest in kleptography. That amounts to treating the NSA
as a monolith. "It's supported by NSA pEoPlE!!" is basically
the backup singers' line.
Thank you for clarifying. I do not infer a common motive from NSA
affiliation, nor do I want an institutional blacklist. I would
apply the same skepticism to Edward Snowden, Bill Binney, Thomas
Drake, an NSA engineer, a NIST employee, a defense contractor, or
an independent academic: examine what they propose, what
assumptions they bring, how they answer questions, and what
outcomes their position produces. Most of all, I would want to
examine their security posture.
Institutional background can still be relevant without making the
institution a monolith. People with access to classified systems
may know constraints or attacks that they cannot describe
publicly. That can create blind spots even without malicious
intent. Suite A is the obvious example: public reviewers cannot
reason from secret knowledge they do not possess, and a person who
possesses it may be unable to explain why or even _that_ a public
design is unsafe.
Furthermore, they may feel that even if they _could_ do so, they
do not agree with thwarting large-scale adversaries if it would
thwart their favorite, civil-liberties respecting, honest, law-
abiding, large-scale adversary... who they consider more as a
friend in any case.
The solution is not personal exclusion. It is transparent threat
models, conflict disclosure where applicable, independent review,
explicit assumptions, and technical mitigations that do not depend
on trusting a person's institutional role. It is also important to
look at the results. NIST's modified Kyber grants a cryptographic
oracle in over a dozen protocols where the protocols are layered.
Example: your Signal client uses ML-KEM in TLS, and again in the
Signal e2ee ratchet. Neither are required to be FIPS-certified, to
put it mildly.
My own principle is simple: I will not support cryptographic
sabotage or an accommodation designed to preserve it or that
allows for it as an acceptable consequence of an imposed change
against the express wishes of the cryptographic primitive's
designer(s). I will support technically sound protections even
when they protect people or institutions hostile to me. RFC 7258
says pervasive monitoring is an attack; the relevant IETF value is
to reduce harm to the end user [12].
* There is no technical content regarding ML-KEM to back
this up.
I could easily believe that you were aware of these issues
before the discussions on this list. Were you?
Some of them.
Agreed. As exhausting as it has been, the discussion has produced
a clearer technical record and some real convergence.
For example, were you aware that you could do this kind of
thing, including recovering `m`?
I believe my earlier response (and the above) should make it
clear that I am. Above is a fuller treatment of this issue.
Yes, now it is clearer. I was asking about before the discussion
because the point is subtle and was absent from the drafts'
Security Considerations and from several early responses. That
suggests a gap in our protocol-analysis process worth fixing.
Do you think that the removal of a hash function to enable it
is not "technical content" when that single design choice was
made exactly to counter this kind of thing?
Not sufficient to stop publication. Instead it is sufficient to
argue that the choice of DRBG must be limited.
Then we agree that it is technical content. I am not asking for
nonpublication as an end in itself. If the DRBG restriction
includes the reason for it, the recoverability of `m`, and the
Appendix C.1 tradeoff, we are close to agreement.
Are you really buying the argument from NIST where they made
it worse and accept that as a fact, over what, ~300-1500
cycles?
With a non-kleptographic DRBG it seems fine.
Does that still hold with the cited research showing that the
current (not even including Dual_EC_DRBG!) NIST DRBG have non-
trivial security failures?
Does it concern you at all that a practical full state recovery
over the network against TLS was shown for CTR_DRBG in a FIPS-
certified setting and NIST has so far only updated their _threat
model_? If the authors did not catch that two month call for
comments _five years later_, will NIST even address these issues?
Regardless, as of now, it does not seem fine to me. Updating the
threat model is absolutely hilarious, I am sure that is very
reassuring to impacted parties.
I agree that the risk of inserting a kleptographic DRBG is real,
but not publishing is not really a good answer.
We agree that the kleptographic-RBG risk is real, and I agree
that nonpublication is not the only answer.
I still would not call the unhashed design equally safe. It is
qualitatively weaker than the same construction with one
additional hash because it relies entirely on the RBG and its
implementation. The hash was present specifically to tolerate one
class of upstream failure.
CTR_DRBG illustrates the distinction between an algorithm and a
deployed system. The Cohney et al. work used cache leakage in a
vulnerable AES implementation to recover DRBG state and compromise
TLS [5]. That does not show that CTR_DRBG is kleptographic, but it
does show that "use an approved DRBG" is incomplete implementation
guidance. Similar questions exist for Hash_DRBG and HMAC_DRBG.
What the relevant research literature says about side channels,
fault injection, entropy failure, reseeding, (RNG) state
compromise, and malicious implementation all deserve systematic
analysis.
We should define the attack classes carefully. Young and Yung's
SETUP model is a natural starting point for deliberate
kleptography, while side-channel and fault attacks may belong in
adjacent categories. The engineering response can still be
systematic:
* write down each attack strategy and the required capabilities; *
distinguish design, implementation, supply-chain, and compulsion
failures; * test whether each construction and implementation
resists it; * record mitigations and residual risk; and * set a
minimum profile for protocol use.
Hardware acceleration is not a magic boundary. AES instructions,
RDRAND, and SHA extensions reduce some software-side channels but
add assumptions about hardware, microcode, firmware signing, and
update channels. Those assumptions can fail through ordinary bugs
or sophisticated compromise.
The point is not that every extreme scenario is occurring; it is
that protocol guidance should not confuse a standardized algorithm
with an immutable, side-channel-free implementation. Also, IETF
should not push a standard that requires FIPS-certified setting as
a general matter when the general case was made weaker and imposed
a new dependency to acheive security: the FIPS-certified setting!
I have preliminary experiments in which an ML-KEM interaction
supplies a useful observation point against a deliberately
vulnerable table-based CTR_DRBG implementation. I do not present
that as a general break or a finished result. The research from
2019/2020 still generally applies.
The immediate conclusion remains modest: require a defensible
RBG, require secure implementation and state management, and hash
`m` so this particular peer interface does not export raw
structure. The longer-term work can determine what additional
requirements are needed for each SP 800-90 construction.
Also just to restate the obvious: we are really discussing some
text in a text file that is _advice_ to implemnters who are not
building in a NIST-certified setting. Those implementers better
understand the situation and are required to diligently follow
NIST's standards. Yes, that still leads to certified
implementations being broken in some cases and that is _also_
NIST's problem, not the core concern that we face.
There is only the 1DES key weakening and the Dual_EC
adventure,
This is not a fair or accurate accounting of the history. Even
if you skip the Clipper Chip, export cryptography and all
related attacks in SSL/TLS, and many other related matters,
the issue of Dual_EC_DRBG amazingly *still* ships today in one
of the most popular Java libraries in the world. It also ships
ML-KEM. We agree about 1DES, of course.
Clipper was an overt attack on the public. There are at least
two distinct issues.
Clipper was an overt policy attack, but policy opposition was not
the whole story.
From memory, Prof. Dr. Matt Blaze had to find a novel technical
failure in the Escrowed Encryption Standard: the 16-bit LEAF
authentication check could be searched so that a device retained
strong Skipjack encryption while bypassing the escrow mechanism
[9]. This was not a cryptanalytic break of Skipjack itself; it was
a break of the key-escrow protocol surrounding it. That
distinction strengthens, rather than weakens, the lesson that
expert technical review can defeat a government-mandated access
design. Skipjack itself followed the 1DES pattern with the 80-bit
key and 64 bit block choices by the way.
The 512-bit modular DH group precomputation thing was not a
covert attack on the standards process.
It is not only about 512-bit DH, of course.
I understand the perspective that export controls and weak 512-
bit groups were not, by themselves, covert manipulation of the
standards process.
Noteworthy however is that "covert" depends on a lot of
assumptions about people's understanding of what certain technical
framing means in a given context. The GSM cryptographic weaknesses
may well have been understood by some telecom technician but most
non-technical users of the phones most certainly did not always
understand.
They were nevertheless policy-created weaknesses whose practical
consequences were not understood by most users of products
marketed as secure. We should classify the history precisely
without minimizing the harm.
Perhaps only Dual_EC was a covert attack on the standards
process.
I do not think Dual_EC_DRBG exhausts the documented history of
SIGINT enabling or weakened communications standards.
GSM is one example. TETRA is another important case: the secret
TEA1 algorithm, used in critical-communications systems, reduced
an advertised 80- bit key to 32 effective bits and was only
publicly understood after reverse engineering [10]. The
researchers did not establish who inserted the weakening or
whether it was exploited, but the result is directly relevant to
how we evaluate secret or nationally constrained cryptographic
designs. TETRA is highly relevant to European security.
ML-KEM might be a covert attack, but not on the standards
process because the codepoints were always going to be assigned,
and of course we're discussing the possibility that ML-KEM is
kleptography so much that everyone who needs to know that it
could be, does.
The public, undeniable fact is that FIPS 203 removed the hash
that Kyber said protected against flawed randomness [2][3]. I am
not claiming that ML-KEM is itself a covert attack. I am saying
that the change opens a direct hidden-structure failure mode and
that an approved algorithm name does not eliminate implementation
or side-channel risk and that is when we are speaking about the
FIPS- certified setting. Outside of that NIST's change makes our
lives harder which is not something that we are required to accept
and to pass on to others. The NetBSD kernel wide DRBG CTR_DRBG
example from [5] was impressive.
Clipper being an overt attack, and ML-KEM maybe a covert attack,
you can see that Clipper would be easier to defeat -- the whole
public could see it.
Agreed: the removal is not covert. Appendix C.1 records it. The
technical effect is also public: relative to third-round Kyber,
ML- KEM no longer has that local safeguard against flawed
randomness. Experts therefore have a responsibility to explain the
tradeoff and the assumption that replaced it.
And again, if your fears turn out to be true, then you win a
big prize: more egg on the NSA's face.
This does not follow. It took over a decade for John Kelsey to
come out with his public apology tour. It only happened
because one person blew the whistle and essentially killed
himself for us to know about it.
But the egg landed on their face much earlier. Apologies and
non- apologies are merely the acknowledgement
Agreed that the reputational damage began earlier but it was also
paid in disrespect to people who raised the findings as a
concern. That pattern repeats here as a variation on the theme but
this time, the attack may be a fact to some but now instead of
being in doubt, it is dismissed as old news or as irrelevent or
unexploitable, and so on.
The important point is not whether an institution eventually
apologizes; it is how long users remain exposed before the
technical problem is acknowledged and fixed. Shumow and Ferguson's
2007 rump- session observation, and Blaze's Clipper work, are
reminders that early warnings deserve serious technical treatment.
Thus I don't think there is anything we can do regarding `m`
other than give advice for non-FIPS implementations --
perhaps we should do that much,
That sounds like the discussions have moved you!
Then you might like the above. Except you might not because it
doesn't move the needle as much as you seem to want.
I will take the movement and thank you for several intense but
useful days of discussion.
but that seems like something TLS and IETF should say much
more generally in a BCP rather than in each Internet
protocol RFC that somehow needs RNGs.
Or maybe, not? I guess I also agree with you that we need a
draft about the overall issue. Would you be interested in co-
authoring such a draft?
I cannot easily co-author I-Ds [for reasons], not with
celerity. I can comment and suggest text.
Thank you. Comments and suggested text would be genuinely useful;
I could take responsibility for an updated draft but I think the
draft authors should resolve the outstanding technical issues that
they see as valid. That tells us about the security posture that
they wish to advance in the IETF. That applies _equally_ to the
hybrid and the pure ML-KEM drafts.
* You and others are destroying your credibility and good
will towards yourselves and towards the IETF by really
reaching in your arguments against ML-KEM.
That is a fair point. [...]
That sounds like the discussions have moved you as well :)
Yes. The discussion has moved me toward a narrower, more
actionable position where now I see that NIST's current DRBG
offerings are _exceeding dangerous_ in the TLS context. Simply
presenting them without qualification seriously misrepresents the
risks as a general solution. I remain concerned that credibility
and tone sometimes displace technical disposition, but I should
also make my own arguments easier to assess and harder to dismiss.
I observed an intense desire for conformity and harmonization
in the form of a popularity contest. There are a few people in
the discussion who broke through that wall. Quite a few people
demonstrated that when it came down to a factual point that
they have a duty to the truth. I personally respect that a lot
more than the parasocial shaming behavior and the foot
dragging.
Last October I was on DJB's side. His pounding the table got me
to abandon that side -- there were no real arguments other than
"they've done it before" and "of course they'd do it again". Now
there's the `m` matter, and regarding that see the above.
The cases for and against pure PQC and hybrids are broader than
those two slogans. I also understand why perceptions of repetitive
or abrasive presentation can cause readers to disengage. This is
in part a big structural failing of the NIST process and it is a
problem in the IETF as well.
At the same time, process cannot substitute reaction to style for
a technical disposition. NIST's participation raised factual
questions about the history and rationale of the change, and the
answers did not resolve all of them. My earlier comments also
waited years for a partial response. That history helps explain
the frustration, although it does not excuse unnecessary heat from
any participant.
I will focus this reply on the concrete convergence: define the
RBG requirements, explain `m`, record the Kyber/FIPS change, and
state the mitigation.
I really want to emphasize that DJB's manner of argument is a
tremendous turn-off.
I hear you. It should not determine whether a reproducible
technical claim is true. The working group needs both professional
communication and a process that tracks substantive objections to
a clear disposition.
We should still try to do good things for the betterment of
all people, even if they're unappreciative.
Some people, when faced with a difficult war, choose a hill to
die on, then die on it. Others fight until it's time to retreat
to live to fight another day. Martyrs don't win wars.
I understand. The useful response is not martyrdom but converting
the issue into durable text and reproducible work. While it
remains in our power, we should endeavor to create that centered
around the End User's security. The End User that is not in the
FIPS-certified setting especially as NIST has the FIPS-certified
setting covered. It does not exactly inspire confidence that in
the FIPS-certified setting the certified CTR_DRBG could be
exploited to remotely extract the CTR_DRBG AES keys over a network
through TLS. They have it covered alright! That security posture
is their choice.
This mistake by NIST should be undone in so much as we should
not go along with something when the research data shows that
it is dangerous.
Look at it from NIST's point of view: that hash merely extends
the DRBG, and via FIPS they mandate DRBGs, so if the hash is
important then it should be included in the DRBG or the DRBG
should be designed so it's not needed because the DRBG is not
necessary.
I understand that position. But a protocol-level hash is not
merely "more DRBG." It enforces a property at a separate boundary:
the peer receives `H(x)` rather than the DRBG output `x`. That
matters precisely when the upstream RBG assumption fails, and not
every TLS deployment is inside the FIPS validation model.
Thus my [new] position is that we should limit the set of
acceptable DRBGs.
We may agree on limiting acceptable RBGs if phrased as NIST's
requirements that must be imposed to acheive their notion of
security. Because approved construction names do not by themselves
guarantee a safe implementation, I would add implementation
guidance here and develop the broader requirements in a separate
document. I was shocked when I realized that the literature piles
up but the FIPS standards do not keep pace, rather the _threat
model_ is updated! TLS should become stronger and stronger as we
learn new things, and the threat model should become _stronger_ as
adversary capabilities improve. The purpose of TLS is to provide
_security_ not a false sense of security, after all.
Yes, I understand the criticism that this appears to be
contrived because you do not use /dev/hwrng or similar
interfaces but I wonder what would change your mind?
The `m` issue did change my mind, as you noted. Just not to the
point of opposing publication. Rather, I propose normatively
limiting the choice of DRBGs to ones we believe are not
kleptographic.
I do not oppose publication once the immediate issues are written
down or referenced accurately.
For example, the Cavium SIGINT enabling - Cavium has a kernel
driver for their hwrng and it presents as /dev/hwrng which
does not transform the output. This kind of CPU is used in
"security" devices.
Please consider that NSA claims it as a SIGINT Enabling
Success.
If you have a TLA-in-the-box attack, you have bigger problems.
And by you I mean we, naturally.
My question is whether "if" is the right prior and what evidence
would change it.
The Cavium reporting shows a knowledge-and-choice problem: users
may rely on hardware and firmware they cannot meaningfully audit,
and hardware RNG interfaces can feed operating-system entropy
pools or be consumed directly. A compromised source is a system-
wide problem, but that is not a reason to remove cheap local
barriers at protocol boundaries. The reason for the removal is not
required for security and it re-introduces an entire class of
security failures. Some large- scale deployments could easily
remove that hash and no one will know, so in my view those kinds
of deployments should not impose their extreme privilege on the
rest of us. Most people, unlike the large defense contractors who
mentioned hashing was going to impact their bottom line or the
environment, do not have thousands of engineers working from the
top to the bottom on their systems. Most people do not have
absolute confidence in their full computing systems, they must
make assumptions about trust which will change in a big way with
this PQC transition.
Would you believe that someone does the wrong thing with that
kind of stack and does so in a way that harms security?
Certainly possible, even likely.
I am glad we agree.
* We know they will go to IEEE if we don't publish. IETF is
much more open, so if we abdicate our remit to more closed
SDOs, what will you have achieved with this social death
penalty?
I do not understand this part - the draft can go to the ISE if
consensus can't be reached. Deb should not be pushed out of
the IETF, and no one should be ostracizing her. This holds for
anyone in these discussions, even convicted felons.
See above (at the very top).
Understood.
That said - if the authors of the draft want to take it
elsewhere and publish it, especially because the WG won't
rubberstamp something and want to add some basic security
considerations, I would say that is their right. I note that
they are welcome to integrate the text and then I think most
objections would be handled. Most of us can't edit the draft
by merging a pull request. I have the sneaking suspicion that
that if I open the pull request that it would not be merged.
If I am wrong, I would do the work.
Would you settle for publishing with a normative requirement
that the DRBG used to generate `m` be one we approve of?
Almost. I would settle on publication with a normative RBG
requirement plus text that explains why `m` matters and recommends
restoring the hash. The RBG restriction and the hash address
different layers. The same is true of CTR_DRBG: choosing the
construction does not excuse a leaky table-based AES
implementation. That leaky table-based AES situation is
catastrophic and that is for a current NIST DRBG. At the very
least we should also normatively cite the (ever weaker?) NIST
threat model!
Really, pick your fights carefully!
I take your point(s) and I respectfully submit that I observe
what appear to be some oversight in a few of your priors. I
appreciate many of your points though.
Have I covered all points now?
Probably, yes. Remaining is some discussion above as well as the
task to produce the exact text.
We all have a duty to resist and none of us have a duty to
obey. We
I agree with this.
Good to know, I am glad.
have no requirement to simply go along with such things,
especially if we think will lead to harm to the End User. With
deep respect to the actual Indigenous people of the world: we
the Indigenous Cryptographers of the Internet SHOULD help the
End User to resist targeted and mass surveillance and indeed,
we MUST treat pervasive monitoring as an attack [0].
To paraphrase Bill Hicks: there is a war on your privacy and
each time that you protect your privacy with strong
encryption, you're winning it.
On so many fronts. The whole age verification stuff is clearly
aimed at ending anonymous and pseudonymous posting so as to
force self- censorship on people.
Agreed. The claimed benefit of broad age-verification mandates
does not justify the resulting surveillance, identity linkage, and
chilling of anonymous or pseudonymous expression.
[0] A term the NSA has given *us* and we should claim it, and
wear it with pride to stand in solidarity with other
Indigenous peoples of the world. Note: "the fact that NSA/CSS
makes cryptographic modifications to commercial or indigenous
cryptographic information security devices or systems in order
to make them exploitable" is "Top Secret" - https://
www.spiegel.de/ international/ germany/inside-the-nsa-s-war-
on- internet-security- a-1010361.html
But also public. And something we basically knew to expect.
Yes. The history is public enough that surprise is no longer a
reasonable response. The standards question is which concrete
engineering lessons we apply now.
Kind regards, Jacob Appelbaum
[0] https://datatracker.ietf.org/doc/html/rfc8730
[1] https://datatracker.ietf.org/doc/html/rfc5742
[2] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
[3] https://pq-crystals.org/kyber/data/kyber-specification-
round3-20210804.pdf
[4] https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf
[5] https://eprint.iacr.org/2019/996
[6] https://datatracker.ietf.org/doc/html/rfc4086
[7] https://datatracker.ietf.org/doc/html/rfc8937
[8] https://hovav.net/ucsd/dist/juniper.pdf
[9] https://www.mattblaze.org/papers/eesproto.pdf
[10] https://www.midnightblue.nl/research/tetraburst
[11] https://cr.yp.to/antiforgery/cachetiming-20050414.pdf
[12] https://datatracker.ietf.org/doc/html/rfc7258
_______________________________________________ TLS mailing list
-- [email protected] To unsubscribe send an email to [email protected]
