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]
