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.
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!
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."
I predict that you don't agree that this is relevant.
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.
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.
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 [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]
