Hi Daniel! Sorry to see you exit the thread, because the actual question is still sitting there unanswered. Jacob was responding to your message to me and Simon, and his points concern my stated plan to ship a hashed-m Kyber variant, so I'll respond to them inline myself.
> 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. Whether or not you agree with Jacob's take, the situation does line up with it: the license only covers implementations that follow the NIST specs, and NIST won't say if hashing m is covered or not. That's exactly why I brought this up in the first place. Nobody needs to assume bad intent here, the uncertainty is real either way. > 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. This is the real issue and so far nobody has disputed it. You suggested the PQC forum as the better place to ask, but people already asked there. NIST could end this whole thread with one sentence. The fact that they haven't is why it keeps going. > I predict that you don't agree that this is relevant. I have to say I don't read this as interpreting your opinions for you, and I disagree with any characterization of Jacob's message as a personal attack. Predicting that a colleague will dispute the relevance of a source is just a forecast about an argument. We all do it constantly. And you are free to prove the prediction wrong! I would honestly like to hear your take on whether the DES history bears on how we treat unexplained design changes today. > 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 is simply correct threat modeling, and it is the entire security rationale for hashing m. The lattice math can be perfect and it won't save you if the input to the KEM was already adversarial. And to be clear about where I stand: Katzenpost is not a business entity. We are not titans of industry. We are a free libre open source software project and our mixnet operates in many countries around the world. We have no interest in approval from NIST or from the IETF, and I will ship the hashed-m variant regardless. Best regards, David Stainton Founder and core developer, Katzenpost post quantum mix network On Mon, Jul 13, 2026 at 2:00 AM Daniel Apon <[email protected]> wrote: > > Hi Jacob, > > Interpreting my intentions and opinions before I have a chance to speak for > myself is highly offensive, and I'm done with this conversation with you. > > 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. >> >> 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]
