Hi Daniel,
On 7/13/26 02:00, Daniel Apon wrote:
Hi Jacob,
Interpreting my intentions and opinions before I have a chance to
speak
I did not interpret your intentions before you had a chance to speak. I
responded point by point to what you wrote, explained the basis for my
reading, and made a prediction about our disagreement based on your
public comments.
That prediction was not a personal attack. It was an invitation to
confirm or deny the disagreement.
for myself is highly offensive,
It was not my intention to offend you. I apologize for doing so.
At the same time, I need to be clear: citing NIST/NSA history, quoting
public documents, and predicting disagreement about their relevance is
not a personal attack.
The relevant context includes your own participation in the 2023
pqc-forum thread. You wrote [0]:
"Would you be okay with a single step that read something
like "sample M <- UniformDist(Support)," perhaps with commentary
about the onus is on the implementer to do so properly?"
That was a fair contribution to the discussion. My point is simply that
this formulation did not address the hidden-structure problem. It moved
responsibility to the implementer, but it did not explain why removing
Kyber's hash was safe against a Dual_EC_DRBG-shaped channel.
Saying this now is not a personal attack on you, either, but upon
revisiting, I am able to see how one may identify with NIST's output as
one's own work. Perhaps that is what happened here.
I assume good faith, and I am sorry that I offended you regardless of my
intentions. We appear to disagree about the issue of hidden structure as
a relevant security concern. I trust that you are as committed as I am
to not making this personal, and to working toward our common IETF goal
of protecting the end user.
and I'm done with this conversation with you.
I accept your withdrawal and do not expect a reply even though I would
prefer clarification. I have removed you from the To: field.
I reserve the right to respond to what I think is not a fair
characterization of what I wrote, especially where it top-quotes my
prediction while omitting the historical and technical context for it.
The rest of my email is for clarifying the record, primarily for third
party readers.
I note that you have not accepted or rejected my technical analysis, nor
have you accepted or rejected the prediction that you do not view the
history as relevant. That is your right. It does not make the prediction
a personal attack.
See below for clarification on my intentions and the facts that informed
my prediction.
Kind regards, --Daniel
On Sun, Jul 12, 2026 at 6:54 PM Jacob Appelbaum
<[email protected]> wrote:
Hi Daniel,
On 7/12/26 21:42, Daniel Apon wrote:
Hi David, Simon, all--
In a very general context, there have been well-founded
warnings before about taking legal advice from a public mailing
list, e.g. whether a license permits this or that, etc.
Speaking for myself, to address the weird crux of the current
technical issue (and again: I am not a lawyer.):
The licensing effort by NIST was intended to provide patent-
free commercial access to NIST standards. It seems odd, to me,
to see this turned around some years later, to question the
intentions of the NIST licenses about whether one can hash this
way or that and be compliant with the license that NIST has
granted, for free, gratis, to the world. Anyway, perhaps this is
a question better asked on the NIST PQC Forum than the (very
specific) TLS WG mailing list.
It isn't weird as much as it tracks with using the patent to
achieve a specific singular (sizes aside) implementation outcome
rather than encouraging a variety.
The interpretation of the patent concern as "odd" may be consistent with
not evaluating the FIPS and IPR concerns being raised. Requesting
clarity from NIST is fair. It is not a personal attack.
NIST won't provide clarity on the list when directly asked and yet
it is such a simple question. Many people asked NIST over the
years including on pqc-forum and in the official comments. Still
NIST has continued to not address the issue. It makes NIST look
like they can't address the issue because they don't want
developers to make a choice that for example, deviates from FIPS
203.
Sounds familiar... oh yes as Ken sent in an email earlier today!
Ken made a fair point about NIST repeating historical patterns. NIST is
on this list and has engaged selectively. NIST could clarify whether
restoring Kyber's original hash over `m` is acceptable from an IPR and
conformance perspective. It has not done so.
That institutional silence is the point. Expressing frustration with
NIST, a government agency writing on this list, is not a personal attack
on you.
From Thomas R. Johnson's declassified NSA history:
"(FOUO) Once that decision had been made, the debate turned to the
issue of minimizing the damage. Narrowing the encryption problem
to a single, influential algorithm might drive out competitors,
and that would reduce the field that NSA had to be concerned
about. Could a public encryption standard be made secure enough to
protect against everything but a massive brute force attack, but
weak enough to still permit an attack of some nature using very
sophisticated (and expensive) techniques? NSA worked closely with
IBM to strengthen the algorithm against all except brute force
attacks and to strengthen substitution tables, called S-boxes.
Conversely, NSA tried to convince IBM to reduce the length of the
key from 64 to 48 bits. Ultimately, they compromised on a 56-bit
key."
This is the historical context. It starts with DES, but it does not end
there. Dual_EC_DRBG is the more recent example, and the NIST-hosted Don
Johnson / John Kelsey email says that Q was "the public key for some
random private key", that NSA "kyboshed" an alternate generation idea,
and that Johnson "was not allowed to publicly discuss it" [1].
That is not an attack on John Kelsey. It is evidence that NIST people
were put in a bad position by NSA, and that the public record supports
taking this class of concern seriously. John Kelsey seems pretty alright
to me, and I think he appears to have done the best he could in the
situation.
The IETF is one of the few places where this can still be discussed
openly. We need strong encryption without backdoors or sabotage, and we
need standards discussions that take that history seriously.
I predict that you don't agree that this is relevant.
This is the prediction that offended. It was based on reading your
comments and perceiving a difference in how we weigh this history. That
is not a personal attack.
The prediction remains unanswered.
If I am wrong, the answer is simple: say that you do agree this history
is relevant to evaluating NIST's removal of the hash over `m`. If I am
right, then we have identified an actual disagreement. Either way, the
prediction was an invitation to clarify, not an insult.
As we discussed previously: we don't need to discuss the lattice
hardness assumptions if the Adversary has an advantage that
satisfies their attack before the lattice issues are the hardness
assumption(s) needing to be solved.
This was about scope. The lattice hardness assumptions are not the only
relevant security question if an adversary can exploit another layer
first.
The point here is that NIST removed a defense-in-depth hash from Kyber,
and that change can matter before lattice hardness is the limiting
assumption. NIST could reverse that decision, and it could clarify that
restoring the hash is safe from an IPR perspective.
Here is a fun idea: someone should call their State Senator or
Congressperson to request an answer from NIST. It would be much
more problematic if they refused to answer in that case.
This is not a personal attack. NIST is a public agency. If ordinary
participants cannot get clear answers through the standards process such
as with filing official comments, it is legitimate to ask whether
democratic oversight is the right route.
That is not a threat. It is an invitation to test the concern through
public institutions.
Hopefully someone from Oregon on this list calls Senator Ron Wyden's
office. He has historically had both the clearances required to know
what is happening behind the scenes, and the protection of the Speech
and Debate clause to tell the public.
Kind regards,
Jacob Appelbaum
[0] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/
m/0ZrlR5HNAwAJ
[1] https://csrc.nist.gov/CSRC/media/Projects/Crypto-Standards-
Development-Process/documents/
Email_Oct%2027%202004%20Don%20Johnson%20to%20John%20Kelsey.pdf
Kind regards, Jacob Appelbaum
--Daniel
On Sun, Jul 12, 2026 at 3:11 PM David Stainton
<[email protected]> wrote:
The NIST Kyber patent license only grants you a license to
use ML-KEM when implemented according to NIST
specifications.
If you deviate, such as by taking the defense-in-depth
approach to hash m to improve robustness against a
compromised PRNG, the NIST patent license does not cover
your usage.
Hi Simon!
I appreciate the warning and I am well aware. Maybe you
providing this information is helpful for others on the list
but it is simply not relevant to Katzenpost since we have no
commercial pursuit, we are not titans of the industry, and
furthermore we do not force users to use any particular KEM.
Any KEM can be used via specifying it in configuration files.
Novel KEMs can also be created via our KEM combiner. In light
of all of this, I am merely stating that pretty soon when I
get around to it, I will make a modified Kyber that hashes m.
And this will be made OPTIONALLY available for use in
Katzenpost if users choose to use it; and in this context
"users" means mixnet operators.
Best regards, David
People in the IETF used to prefer patent un-encumbered
technology, but things are different today.
https://csrc.nist.gov/csrc/media/Projects/post-quantum-
cryptography/documents/selected-algos-2022/nist-pqc-license-
summary-and-excerpts.pdf
/Simon
_______________________________________________ TLS mailing
list -- [email protected] To unsubscribe send an email to tls-
[email protected]
_______________________________________________ TLS mailing list
-- [email protected] To unsubscribe send an email to tls-
[email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
