From cryptskii at proton.me Mon Jun 1 06:21:58 2026 From: cryptskii at proton.me (cryptskii at proton.me) Date: Mon, 01 Jun 2026 10:21:58 +0000 Subject: [Cryptography] DSM: deterministic state machine (edge, post-quantum, no public ledger/consensus) In-Reply-To: References: Message-ID: Hi all, I?m sharing an article I posted yesterday that highlights what I think is one of the strongest aspects of DSM?s design: resistance to smart collusion and no saleable authority surface in the ordinary validity path. Article: https://irrefutablelabs.org/articles/DSMSecurityComparison.html The article is grounded in this recent paper: Breaking Omert?: On Threshold Cryptography, Smart Collusion, and Whistleblowing https://eprint.iacr.org/2025/1582.pdf The core point is simple. Many systems try to mitigate collusion by making authority harder to corrupt. DSM takes a different approach by removing the intermediary authority that collusion would normally target. The article also touches on MEV and valid but non neutral ordering. I think this matters when looking at the long term economic and fairness effects on a protocol. Even when behavior remains technically valid, repeated preferential ordering or timing advantages can still create meaningful extraction over time. In that sense, MEV and related ordering games can become the long game version of collusion: not an obvious break, but a slow structural drain through priority, timing, and access. That framing is not how these problems are usually discussed in Web3. My view is that the language around MEV often makes the issue sound smaller than it is, partly because many architectures can only mitigate it rather than remove the authority surface that creates it. Feel free to read when you get a chance. Feedback is more than welcome. Thanks, everyone. Brandon From cryptography at mdpi.com Wed Jun 3 22:18:21 2026 From: cryptography at mdpi.com (Cryptography Editorial Office) Date: Thu, 4 Jun 2026 10:18:21 +0800 Subject: [Cryptography] (ESCI & Scopus indexed) New CiteScore of 6.4 In-Reply-To: References: <1b8aba93-8ffb-5395-075f-bdf4f66eb76c@mdpi.com> <2dfffa04-f8fe-dbd7-b5a7-0022fa8ecf86@mdpi.com> <7b4b011a-473c-45f2-aa35-1d325d2091ed@mdpi.com> <60fa0ef2-008f-1bba-9108-6c19a3980563@mdpi.com> <0b15e2da-b4bd-321e-c601-642fb7c207dc@mdpi.com> <7b64deeb-6a2b-33d0-0281-978e39a75a67@mdpi.com> <7f95109a-ad6f-08dd-070e-991b2e79bcc3@mdpi.com> Message-ID: I am pleased to share that Cryptography (ISSN: 2410-387X) has received a heightened CiteScore of 6.4. It ranks as follows: Q1 (66 out of 680) in "Applied Mathematics". Q1 (37 out of 203) in "Computational Theory and Mathematics". Q1 (142 out of 568) in "Computer Networks and Communications". For full details of the current CiteScore release, please refer to the journal?s source profile (https://www.scopus.com/sourceid/21101039441). Cryptography (ISSN 2410-387X, https://www.mdpi.com/journal/Cryptography) is a scientific peer-reviewed open access journal of cryptography published quarterly online by MDPI. It is covered by Scopus (Elsevier), Emerging Sources Citation Index (ESCI-Web of Science), etc. The journal scope is shown here: https://www.mdpi.com/journal/cryptography/about. Editorial Board: https://www.mdpi.com/journal/cryptography/editors. More Topics: https://www.mdpi.com/journal/cryptography/special_issues. We warmly welcome high-quality reviews and regular research papers in all areas of theory and practice of modern cryptography. Any questions about the journal Cryptography, please contact cryptography at mdpi.com. Best regards, Xue Cheng Managing Editor -- MDPI Branch Office, Wuhan Cryptography Editorial Office https://www.mdpi.com/journal/cryptography MDPI, Grosspeteranlage 5, 4052 Basel, Switzerland Twitter: @Cryptogr_MDPI https://twitter.com/Cryptogr_MDPI LinkedIn: Cryptography-MDPI From crypto at senderek.ie Sat Jun 6 09:00:08 2026 From: crypto at senderek.ie (Ralf Senderek) Date: Sat, 6 Jun 2026 15:00:08 +0200 (CEST) Subject: [Cryptography] The TLS-LTS draft expires in August 2026 Message-ID: <1d9d3c1e-32ac-85a8-95bf-9495d58ff34a@senderek.com> The draft for TLS-LTS will expire on 14 August 2026. For those who don't know already why it [1] matters to keep it alive, it "specifies an update of TLS 1.2 for long-term support (LTS) on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed." The TLS-LTS proposal "specifies a few simple restrictions on the huge range of TLS suites, options and parameters to limit the protocol to a known-good subset, as well as making minor corrections to prevent or at least limit various attacks." With the expiration deadline in sight, would any of the more important people on this list please exercise their influence, to make sure TLS-LTS can be endorsed in the IETF? Ralf. [1] https://www.ietf.org/archive/id/draft-gutmann-tls-lts-17.txt From leichter at lrw.com Sat Jun 6 14:52:04 2026 From: leichter at lrw.com (Jerry Leichter) Date: Sat, 6 Jun 2026 14:52:04 -0400 Subject: [Cryptography] =?utf-8?q?=22The_U=2ES=2E_Military_Quietly_Turned?= =?utf-8?q?_GPS_Into_a_Global_=E2=80=98Numbers_Station=2C=E2=80=99_Evidenc?= =?utf-8?q?e_Suggests=22?= Message-ID: The headline, of course, doesn't quite match the actual article This summary does: "A random sequence in an innocuous GPS message field is likely encrypted traffic from the U.S. military's system for remotely updating cryptographic keys around the world." https://www.404media.co/the-u-s-military-quietly-turned-gps-into-a-global-numbers-station-evidence-suggests/?ref=weekly-roundup-newsletter -- Jerry From hyc at symas.com Sun Jun 7 09:48:16 2026 From: hyc at symas.com (Howard Chu) Date: Sun, 7 Jun 2026 14:48:16 +0100 Subject: [Cryptography] =?utf-8?q?=22The_U=2ES=2E_Military_Quietly_Turned?= =?utf-8?q?_GPS_Into_a_Global_=E2=80=98Numbers_Station=2C=E2=80=99_Evidenc?= =?utf-8?q?e_Suggests=22?= In-Reply-To: References: Message-ID: Jerry Leichter wrote: > The headline, of course, doesn't quite match the actual article This summary does: "A random sequence in an innocuous GPS message field is likely encrypted traffic from the U.S. military's system for remotely updating cryptographic keys around the world." > > https://www.404media.co/the-u-s-military-quietly-turned-gps-into-a-global-numbers-station-evidence-suggests/?ref=weekly-roundup-newsletter Interesting, considering how easily GPS is jammed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rsalz at akamai.com Sun Jun 7 09:51:44 2026 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 7 Jun 2026 13:51:44 +0000 Subject: [Cryptography] The TLS-LTS draft expires in August 2026 In-Reply-To: <1d9d3c1e-32ac-85a8-95bf-9495d58ff34a@senderek.com> References: <1d9d3c1e-32ac-85a8-95bf-9495d58ff34a@senderek.com> Message-ID: * With the expiration deadline in sight, would any of the more important * people on this list please exercise their influence, to make sure TLS-LTS * can be endorsed in the IETF? I do not qualify as important, but I have other qualifications: I?ve been involved with the IETF for a long time, I am one of the maintainers (?designated experts?) of the TLS registry, and I spent some time with Peter trying to move his document forward. Because there is a (slight) incompatibility with the version on which it is based, no standards-track work is possible. The only way to move this forward within the IETF is to publish it as an individual RFC. I believe the editor of that series is willing to do so. I don?t know Peter?s views on this, and I would not blame him for just not caring about IETF publication any more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leichter at lrw.com Sun Jun 7 11:36:24 2026 From: leichter at lrw.com (Jerry Leichter) Date: Sun, 7 Jun 2026 11:36:24 -0400 Subject: [Cryptography] =?utf-8?q?=22The_U=2ES=2E_Military_Quietly_Turned?= =?utf-8?q?_GPS_Into_a_Global_=E2=80=98Numbers_Station=2C=E2=80=99_Evidenc?= =?utf-8?q?e_Suggests=22?= In-Reply-To: References: Message-ID: <028BE1F0-930B-4115-A4E6-8EE158F3142B@lrw.com> >> The headline, of course, doesn't quite match the actual article This summary does: "A random sequence in an innocuous GPS message field is likely encrypted traffic from the U.S. military's system for remotely updating cryptographic keys around the world." >> >> https://www.404media.co/the-u-s-military-quietly-turned-gps-into-a-global-numbers-station-evidence-suggests/?ref=weekly-roundup-newsletter > > Interesting, considering how easily GPS is jammed. I'm not sure how important that is in this application. The re-keying material is presumably repeated many times to ensure, even when no jamming is present, that the message gets through - many things block GPS signals, and any particular piece of equipment may simply be turned off. And the signals are likely to make it through the jamming here and there. The thing I wonder about is different. The message field is only 176 bits long. Not much room for effective authentication! Getting your enemy to re-key to an invalid key would be a great attack. -- Jerry From crypto at senderek.ie Sun Jun 7 12:48:17 2026 From: crypto at senderek.ie (Ralf Senderek) Date: Sun, 7 Jun 2026 18:48:17 +0200 (CEST) Subject: [Cryptography] The TLS-LTS draft expires in August 2026 In-Reply-To: References: <1d9d3c1e-32ac-85a8-95bf-9495d58ff34a@senderek.com> Message-ID: <5db1dbae-3ff2-0050-2ff0-655b379bcd0a@senderek.com> On Sun, 7 Jun 2026, Salz, Rich wrote: > I?ve been involved with the IETF for a long > time, I am one of the maintainers (?designated experts?) of the TLS registry, > and I spent some time with Peter trying to move his document forward. > Because there is a (slight) incompatibility with the version on which it is > based, no standards-track work is possible. Thank you Rich for your comments. For those who are not that familiar with the inner workings of the IETF can you say what incompatibility is blocking the progress? This draft is full of very good ideas and an excellent proposal to reduce the complexity that haunts TLS. In my opinion the approach in this draft shows the way, how complexity can effectively been tackled. And even though the draft focuses on systems that cannot easily been updated, Long Term Support for TLS should also be as valuable for server software we are using every day. Actually, TLS-LTS provides an extension that signals the client's request for a limitation of TLS cipher suites to a known-good subset during the initial handshake (Client Hello). And because IANA has already assigned the extension type 0x1A for this extension, a server software willing to comply just needs to reply with 0x1A in its Server Hello and stick to the draft's requirements. So TLS-LTS does not add complexity, but on the contrary it allows the server to reduce the attack surface considerably, making TLS connections more reliable and secure. > The only way to move this forward within the IETF is to publish it as an individual RFC. > I believe the editor of that series is willing to do so. I think, it would be worth trying, to ensure that this work is no longer locked in an endless time loop. Ralf From phma at bezitopo.org Sun Jun 7 18:53:49 2026 From: phma at bezitopo.org (Pierre Abbat) Date: Sun, 07 Jun 2026 18:53:49 -0400 Subject: [Cryptography] mathematical constants Message-ID: <37105983.lfNtQ83HCr@puma> Is there a place where we can collect mathematical constants for use as nothing-up-my-sleeve numbers? Pi has been used in MD2 and Blowfish, SHA-1 uses square roots of primes, Twistree (hash function I invented) uses two representations of exp(4), and many cryptographic algorithms use ?. I thought of computing the 2-adic sum of all factorials, and found that the alternating sum of all factorials (which converges in all p-adic systems) is equal to the Gompertz constant (in the same way that you can add all positive integers and get -1/12). Pierre -- loi mintu se ckaji danlu cu jmaji From pgut001 at cs.auckland.ac.nz Sun Jun 7 20:57:53 2026 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon, 8 Jun 2026 00:57:53 +0000 Subject: [Cryptography] mathematical constants In-Reply-To: <37105983.lfNtQ83HCr@puma> References: <37105983.lfNtQ83HCr@puma> Message-ID: Pierre Abbat writes: >Is there a place where we can collect mathematical constants for use as >nothing-up-my-sleeve numbers? The problem is that with any kind of famous irrational number you're mostly relying on people believing that the hex string you're using somehow corresponds to an encoding of Noodleheinz's Constant or whatever [0]. I'd go with either some well-known piece of text ("Friends, Romans, countrymen...") if low entropy is OK or the same thing run through HKDF if you need high entropy, that's pretty easy for anyone to verify. Peter. [0] Has anyone ever verified things like the SHA-2 constants? How are the fractional parts of square/cube roots encoded to get the hex values? From phma at bezitopo.org Mon Jun 8 02:13:23 2026 From: phma at bezitopo.org (Pierre Abbat) Date: Mon, 08 Jun 2026 02:13:23 -0400 Subject: [Cryptography] mathematical constants In-Reply-To: References: <37105983.lfNtQ83HCr@puma> Message-ID: <1821710.Wv0x8mG9nZ@puma> On Sunday, June 7, 2026 8:57:53 PM EDT Peter Gutmann via cryptography wrote: > The problem is that with any kind of famous irrational number you're mostly > relying on people believing that the hex string you're using somehow > corresponds to an encoding of Noodleheinz's Constant or whatever [0]. I'd > go with either some well-known piece of text ("Friends, Romans, > countrymen...") if low entropy is OK or the same thing run through HKDF if > you need high entropy, that's pretty easy for anyone to verify. The actual entropy in the byte sequence of an irrational constant is zero, except for Chaitin's constant. A very long sequence of bytes of the constant can be computed by a small program. In the source code of Twistree, I put instructions in Haskell and Julia for computing exp(4) as a 2-adic number, using packages written by someone else. Each entry in the collection of constants could link to a program that computes the constant. > [0] Has anyone ever verified things like the SHA-2 constants? How are the > fractional parts of square/cube roots encoded to get the hex values? To verify the hex value of a square root, square it. Verifying 0x9e3779b9: julia> 0x09e3779b9^2 0x61c88645e35e67b1 julia> 0x11e3779b9^2 0x3ffffffee35e67b1 julia> UInt128(0x11e3779b9)^2 0x00000000000000013ffffffee35e67b1 Pierre -- The Black Garden on the Mountain is not on the Black Mountain. From huitema at huitema.net Mon Jun 8 02:50:03 2026 From: huitema at huitema.net (Christian Huitema) Date: Sun, 7 Jun 2026 23:50:03 -0700 Subject: [Cryptography] mathematical constants In-Reply-To: References: <37105983.lfNtQ83HCr@puma> Message-ID: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> On 6/7/2026 5:57 PM, Peter Gutmann via cryptography wrote: > Pierre Abbat writes: > >> Is there a place where we can collect mathematical constants for use as >> nothing-up-my-sleeve numbers? > The problem is that with any kind of famous irrational number you're mostly > relying on people believing that the hex string you're using somehow > corresponds to an encoding of Noodleheinz's Constant or whatever [0]. I'd go > with either some well-known piece of text ("Friends, Romans, countrymen...") > if low entropy is OK or the same thing run through HKDF if you need high > entropy, that's pretty easy for anyone to verify. If the goal is "nothing up my sleeve", one of the problem is the number of possible inputs. For example, assume a hidden attack that is blocked if the standard constants are derived from the digits of Pi, but enabled if they are derived from the HKDF of "a well known piece of text". Imaging an attacker willing to try finding one of the multiple thousands "well known pieces of text" until finding one that meets the desired goal... -- Christian Huitema From rcs at xmission.com Mon Jun 8 02:40:20 2026 From: rcs at xmission.com (rcs at xmission.com) Date: Mon, 08 Jun 2026 00:40:20 -0600 Subject: [Cryptography] mathematical constants In-Reply-To: References: <37105983.lfNtQ83HCr@puma> Message-ID: <20260608004020.Horde.nJR4QAQdC_-3Z96BN-cyCg2@webmail.xmission.com> Quoting Peter Gutmann via cryptography : > Pierre Abbat writes: > >> Is there a place where we can collect mathematical constants for use as >> nothing-up-my-sleeve numbers? > > The problem is that with any kind of famous irrational number you're mostly > relying on people believing that the hex string you're using somehow > corresponds to an encoding of Noodleheinz's Constant or whatever [0]. I'd go > with either some well-known piece of text ("Friends, Romans, countrymen...") > if low entropy is OK or the same thing run through HKDF if you need high > entropy, that's pretty easy for anyone to verify. > > Peter. > > [0] Has anyone ever verified things like the SHA-2 constants? How are the > fractional parts of square/cube roots encoded to get the hex values? I implemented Blowfish from the description, which (IIRC) needed 4x32x256 (=32768) bits of pi-3. My routine used one of the simple infinite series for pi, using bignum integers, with every term scaled by 2^(32768+100), and the answer printed in hex. To convert an ordinary fraction to hex, just multiply it by 2^64 and print the integer part in hex. You can even do it a digit at a time: multiply the fraction by 16, and use the integer part as one digit. Then repeat--- multiply the leftover fraction by 16, record the integer part as a hex digit, over and over ... You can do a crude eyeball check on the cube-root-of-prime stuff by computing the table of first differences. Suppose the primes begin after 343. Then 347, 349, 353, 359, 367, 373, 379, ... has deltas 2, 4, 6, 8, 6, 6, ... The deltas of the cube roots will be multiples of the sequence 1, 2, 3, 4, 3, 3, slightly diminished (since the graph of cbrt(N) is concave downward). The formula for cbrt(343+N) begins with 7 + N/147 - (N^2)/151263 + ..., which is close to linear for small N. Knuth volume 2, appendix B, has 40 digits of pi, e^gamma, zeta(3), etc. Abramowitz & Stegun, table 1.1, has 40 digits of cube roots. etc., and table 26.11 has 2500 5-digit random numbers. (This is the old printed version, which is online, free.) Rich From 9bf3a7ef93bb at ewoof.net Mon Jun 8 06:13:44 2026 From: 9bf3a7ef93bb at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Mon, 8 Jun 2026 10:13:44 +0000 Subject: [Cryptography] mathematical constants In-Reply-To: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> References: <37105983.lfNtQ83HCr@puma> <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> Message-ID: <614fb08f-3419-414d-86f8-c8a1332171a1@home.arpa> On 7 Jun 2026 23:50 -0700, from huitema at huitema.net (Christian Huitema): > If the goal is "nothing up my sleeve", one of the problem is the number of > possible inputs. For example, assume a hidden attack that is blocked if the > standard constants are derived from the digits of Pi, but enabled if they > are derived from the HKDF of "a well known piece of text". Imaging an > attacker willing to try finding one of the multiple thousands "well known > pieces of text" until finding one that meets the desired goal... Doing so wouldn't even be particularly difficult, if one is aware of what pattern to the constant enables a particular attack. Download all of Project Gutenberg or some similar resource. Write a program which takes the first m..n words or sentences from each work or maybe the first m..n sentences of each paragraph; and runs those through x number of possible one-way functions, then checks whether the output satisfies the criteria. Depending on those criteria, the combinatorics might well not be unreasonable. Then the selection of the "nothing up my sleeve" value can be specified as something like "the first $number sentences from $work by $author as published in $year, encoded in US-ASCII, run through Argon2d with parameters such-and-such". Easy to verify, nothing obviously malicious going on especially if in this example the hashing isn't all that unusual, and at a glance the inputs to the selection and generation of the "nothing up my sleeve" value are all relatively low entropy; and if an attack is discovered by an external party, offers a large degree of plausible deniability. -- Michael Kj?rling ??https://michael.kjorling.se From leichter at lrw.com Mon Jun 8 08:39:05 2026 From: leichter at lrw.com (Jerry Leichter) Date: Mon, 8 Jun 2026 08:39:05 -0400 Subject: [Cryptography] mathematical constants In-Reply-To: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> References: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> Message-ID: <4D4C50D5-41D8-4BCF-833B-BBADA6B8F13C@lrw.com> > If the goal is "nothing up my sleeve", one of the problem is the number of possible inputs. For example, assume a hidden attack that is blocked if the standard constants are derived from the digits of Pi, but enabled if they are derived from the HKDF of "a well known piece of text". Imaging an attacker willing to try finding one of the multiple thousands "well known pieces of text" until finding one that meets the desired goal... Indeed, while the very first uses of the ?nothing up my sleeve? claim relied on a very small base of values, since everyone wants to use their own values (Why? Why not use the same set of values for everything, if the actual values don?t matter?) the claim that the values ?couldn?t have been influenced? becomes harder to support. What would work would be pre-commitment to values. For example, we could have a clearinghouse to which the proposer of a new algorithm would publicly apply for some number of bits. The clearinghouse would choose that number of bits from the next digits in the RAND book of random numbers. This is subject to a theoretical attack: Someone could look ahead in the book, find a ?good? sequence, then wait for it to be ?next.? Unlikely, but if you really want to eliminate that possibility, there?s the idea (due I think to Rabin) of a random beacon: A source that continuously broadcasts random bits to, nominally, the entire world. It could be a natural source - radio emissions from the Sun; it could be artificial. An algorithm proposer would publish the algorithm with unspecified constants to be filled in at a specified future time from the beacon. -- Jerry From rsalz at akamai.com Mon Jun 8 11:04:52 2026 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 8 Jun 2026 15:04:52 +0000 Subject: [Cryptography] The TLS-LTS draft expires in August 2026 In-Reply-To: <5db1dbae-3ff2-0050-2ff0-655b379bcd0a@senderek.com> References: <1d9d3c1e-32ac-85a8-95bf-9495d58ff34a@senderek.com> <5db1dbae-3ff2-0050-2ff0-655b379bcd0a@senderek.com> Message-ID: On 6/7/26, 5:52?PM, "cryptography" wrote: * Thank you Rich for your comments. For those who are not that familiar with * the inner workings of the IETF can you say what incompatibility is blocking the * progress? I don?t recall the details; some of it was because of the forthcoming RFC that says TLS 1.2 is frozen except for security fixes[1]. (Ironically, I am the co-author of that.) The second was something about the use of ECDH [2]. You can (sic) troll through the whole archives easily[3]. [1] https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-08.html [2] https://mailarchive.ietf.org/arch/msg/tls/aYsIi0HjV3ZagCFB9n_eRpFsBZ4/ [3] https://mailarchive.ietf.org/arch/browse/tls/?q="tls-lts" -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgut001 at cs.auckland.ac.nz Mon Jun 8 11:32:22 2026 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon, 8 Jun 2026 15:32:22 +0000 Subject: [Cryptography] mathematical constants In-Reply-To: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> References: <37105983.lfNtQ83HCr@puma> <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> Message-ID: Christian Huitema writes: >Imaging an attacker willing to try finding one of the multiple thousands >"well known pieces of text" until finding one that meets the desired goal... Good point, the "is father dead or deceased" problem [0]. But then again since irrational numbers are infinite series you can just walk down as large a cataloge of those as you have available until you find the pattern you need. Having said that, at some point you're just chasing down phantoms. If you want to backdoor something you do all the stuff Snowden showed us the NSA did, which gets you all the plaintext all the time, and then don't have to bother with trying to introduce some infinitesimal bias into something, hoping it gets adopted, and recovering a few bits of plaintext through it once a blue moon. Peter. [0] https://www.nsa.gov/portals/75/documents/news-features/declassified-documents/friedman-documents/publications/FOLDER_245/41748799078803.pdf, bottom of p.217. From crypto at senderek.ie Mon Jun 8 13:37:08 2026 From: crypto at senderek.ie (Ralf Senderek) Date: Mon, 8 Jun 2026 19:37:08 +0200 (CEST) Subject: [Cryptography] The TLS-LTS draft expires in August 2026 Message-ID: <17ecc44c-21ee-d392-8168-4ccbf42c0b91@senderek.com> On Mon, 8 Jun 2026, Salz, Rich wrote: > [1] https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-08.html > [2] https://mailarchive.ietf.org/arch/msg/tls/aYsIi0HjV3ZagCFB9n_eRpFsBZ4/ > [3] https://mailarchive.ietf.org/arch/browse/tls/?q="tls-lts" Thank you very much for the pointers, they are an insightful read. [1] which makes the point that "This document specifies that outside of urgent security fixes (as determine by TLS WG consensus), and the exceptions listed in Section 4, no changes will be approved for TLS 1.2." But TLS-LTS does in no way require such changes to TLS 1.2. What TLS-LTS actually requires is that - if the tls_lts extension, (which is already approved) is present in the Client Hello - then a hash of all messages leading up to the calculation of the master secret will be used to generate the master secret in order to protect against the use of manipulated handshake parameters. That is a prudent way to reduce the attack surface not a change to TLS 1.2, but to the way it is being implemented. And all the other requirements in -LTS have similar justifications. [2] makes an interesting reference to RFC 9325 in which the preferred cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 which every client should request first. TLS-LTS limits the cipher suites (without PSK) to either TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (with mandatory EtM) So it seems, GCM is seen as superior to CBC mode, and many websites have already chosen to use only GCM mode for AES with TLS-1.2. This is ignoring the fact that GCM can fail in a catastrophic way if nonces are reused, which is not the case with CBC mode. RFC 9325 states: "While this problem has been fixed in TLS 1.3, which enforces a deterministic method to generate nonces from record sequence numbers and shared secrets for all its AEAD cipher suites (including AES-GCM), TLS 1.2 implementations could still choose their own (potentially insecure) nonce generation methods. Which is just another reason to request a proven way to generate GCM nonces that solves the problem in TLS 1.2 too, which is exactly what TLS-LTS is doing already. Ralf From pgut001 at cs.auckland.ac.nz Mon Jun 8 13:49:45 2026 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon, 8 Jun 2026 17:49:45 +0000 Subject: [Cryptography] mathematical constants In-Reply-To: <4D4C50D5-41D8-4BCF-833B-BBADA6B8F13C@lrw.com> References: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> <4D4C50D5-41D8-4BCF-833B-BBADA6B8F13C@lrw.com> Message-ID: Jerry Leichter writes: >What would work would be pre-commitment to values. How many attacks have there been due to published booby-trapped values in crypto algorithms? (EC-DRBG doens't count because the private-key values were never made public, I mean published definitely non-NUMS values). Now, how many attacks have there been due to buffer overflows, XSS, SQLI, stack-smashing, ... ? On the way back from a recent security meeting a friend of mine made the comment that worrying about side-channel attacks (which had come up there) was like frantically phoning around plumbers to fix a loose tap in a house that's on fire. Peter. From iang at iang.org Mon Jun 8 17:09:21 2026 From: iang at iang.org (iang) Date: Mon, 08 Jun 2026 21:09:21 +0000 Subject: [Cryptography] mathematical constants In-Reply-To: References: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> <4D4C50D5-41D8-4BCF-833B-BBADA6B8F13C@lrw.com> Message-ID: <7091c8cd-b3e2-49c5-99b1-8706e01a2a5f@iang.org> On 08/06/2026 21:49, Peter Gutmann via cryptography wrote: > Jerry Leichter writes: > >> What would work would be pre-commitment to values. > How many attacks have there been due to published booby-trapped values in > crypto algorithms? (EC-DRBG doens't count because the private-key values were > never made public, I mean published definitely non-NUMS values). > > Now, how many attacks have there been due to buffer overflows, XSS, SQLI, > stack-smashing, ... ? Not to mention, how many attacks have there been using phishing, social engineering, identity-sales fraud, lost bitcoins, phone porting (a US specialty), $5 wrench plumbing (a top-ten hit in France), the move to panopticon phone tracking (UK leads, but US states have their own game going on), the statal desire to unbank just bc (everywhere...), ... It was estimated that 30% of all bitcoin was stolen or lost. If you get hacked at your bank, what are your chances of getting a conversation? Let alone getting your money back... Meanwhile, security professionals & cryptographers are obsessed with attacks that simply do not rate in the real world. No 'history' no risk. No statistics, no loss. It's all theory - yeah this amazing exotic attack could happen if all the planets were in alignment! > On the way back from a recent security meeting a friend of mine made the > comment that worrying about side-channel attacks (which had come up there) was > like frantically phoning around plumbers to fix a loose tap in a house that's > on fire. It's way worse - we spend time on complimenting society's fashion statement of lovely cryptographic algorithms while they're walking around with flame throwers on their back, smoking & juggling with firing brands... This is why I don't spend a lot of time on this group - everyone's obsessed about theoretical weaknesses that never happen. And we all totally ignore the security shitstorm that actual ordinary human people have to navigate .. because it's not elegant coding or cryptography, it's not important. Everyone believes we're Major Tom when we're really just shovelling Ashes to Ashes. iang From iang at iang.org Mon Jun 8 17:22:06 2026 From: iang at iang.org (iang) Date: Mon, 08 Jun 2026 21:22:06 +0000 Subject: [Cryptography] mathematical constants In-Reply-To: <4D4C50D5-41D8-4BCF-833B-BBADA6B8F13C@lrw.com> References: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> <4D4C50D5-41D8-4BCF-833B-BBADA6B8F13C@lrw.com> Message-ID: <617aa1c9-9e9f-45f8-b6a4-a783bf905b04@iang.org> On 08/06/2026 16:39, Jerry Leichter wrote: >> If the goal is "nothing up my sleeve", one of the problem is the number of possible inputs. For example, assume a hidden attack that is blocked if the standard constants are derived from the digits of Pi, but enabled if they are derived from the HKDF of "a well known piece of text". Imaging an attacker willing to try finding one of the multiple thousands "well known pieces of text" until finding one that meets the desired goal... > Indeed, while the very first uses of the ?nothing up my sleeve? claim relied on a very small base of values, since everyone wants to use their own values (Why? Why not use the same set of values for everything, if the actual values don?t matter?) the claim that the values ?couldn?t have been influenced? becomes harder to support. An alternative to the simple claim of "nothing up my sleeve" is to run a ceremony. We discussed this many years back. In short, several people get together who are keen on the security result, and perhaps adversarial. They all provide inputs into a simply program -- short enough to be typed in -- and watch that everyone's input is included & hashed. Theoretically, only one person has to be honest for this construct to work. We did it at CAcert for a new root cert. I think they did a variant to create the zCash primary keys. In terms of post-auditability, if everyone turns up and posts their process and their inputs to the world, it is secure and auditable if one person is honest. fwiw in the CAcert process I used Jon Callas' method of driving my laptop camera with dark covering into quantum noise, and took photos to be hashed into the overall system. Another guy used John Denker's sound card method. iang From jon at callas.org Mon Jun 8 18:59:53 2026 From: jon at callas.org (Jon Callas) Date: Mon, 8 Jun 2026 15:59:53 -0700 Subject: [Cryptography] mathematical constants In-Reply-To: <37105983.lfNtQ83HCr@puma> References: <37105983.lfNtQ83HCr@puma> Message-ID: <0E177E70-FD2C-46C3-A9EC-00E2FA3228BB@callas.org> > On Jun 7, 2026, at 15:53, Pierre Abbat wrote: > > Is there a place where we can collect mathematical constants for use as > nothing-up-my-sleeve numbers? Pi has been used in MD2 and Blowfish, SHA-1 uses > square roots of primes, Twistree (hash function I invented) uses two > representations of exp(4), and many cryptographic algorithms use ?. I thought > of computing the 2-adic sum of all factorials, and found that the alternating > sum of all factorials (which converges in all p-adic systems) is equal to the > Gompertz constant (in the same way that you can add all positive integers and > get -1/12). What's the goal here? (By the way, at least one of the things you mention -- Blowfish -- are not really using them as NUMS constants at all. In Blowfish, there's a buffer that's initialized with them because otherwise it would be zero. Pi is a convenient thing to fill it with. It's a similar thing with SHA-1, but that leads to the comments below.) I think there are two things that are in tension here. One is the idea behind NUMS, which is an argument that algorithm parameters are not weak. Whatever "weak" means. The other is that we want the most secure algorithm possible. Whatever "most" and "secure" mean. If there are any options in the NUMS selection, then there's always a chance there could be some sort of backdoor. (Even in the case of only one selection there's a chance, but let's put that aside for now.) Assume Alice wants an advantage on attacking the algorithm; it seems likely that whatever the set of NUMS options are, Alice will pick the most favorable one. There's also positive and negative versions of this. Alice might pick the parameters that are secretly weak, or avoid parameters that are secretly strong. If there are no options on the selection, then we're declaring that we don't want a more secure parameter than the agreement. In effect, we are saying that the risk of a backdoor is greater than the risk of weak parameters; moreover we're saying that we accept the weaknesses of the agreement and reject improvements declaring them essentially a stalking horse for backdoors. These are in tension -- you can't have both laudable goals at the same time. You can't have both the most secure algorithm and only one parameter choice. (I go further and assert that we can't ever know that there are no hidden flaws in the single NUMS selection. On top of that, an enterprising jester could start a whispering campaign that the single NUMS was created with some secret cabal that reserved the flaw for themselves. I'm not sure there's a way out of that hall of mirrors once there are people who wander in.) There's a real-world case where both of these are true, even. That's Lucifer/DES. We know that Lucifer was a 64-bit block cipher with weak S-boxes and that it was transformed into a 56-bit block cipher with strong S-boxes and that the resultant cipher, DES, is overall more secure than Lucifer. (There's also a lot I glossed over here, starting with the word "secure" when we try to compare the effect of a shorter key against improved cryptanalysis.) When I was working on Threefish, we selected our rotation constants (which in an ARX SP-network are the analogues of S-boxes) with an evolutionary algorithm that used random values taken from a PRNG that was simply initialized. We flat out said in the papers that we are giving transparency in the process and showing all the work, but we can't ever prove that there was nothing up our sleeve. (Though not in those words, of course.) I think that NUMS is a really great concept that's easy to say and easy to agree is a great concept. However, the more that we examine what it means, the more we wander into a hall of mirrors. It's good to know there's nothing up the designer's sleeve, and we also want to know there's nothing in the designer's shoe, or palmed in their left hand, or casually hooked to the lining of their jacket, or what. We also don't know that the adversary isn't advocating for NUMS because that's the weakest parameter set. In the real world there are a lot of things that have unknown provenance. We don't know what the selection was for any of the NIST elliptic curves. We don't know why the primes picked in SHA-1 were picked. Heck, we don't know why Blowfish uses digits of pi and not digits of e or phi, or what. (I also think that picking pi is pretty close to NUMS because the properties we want that bitstring to have are provably met by pi, and it's pretty much the number on the top of just about anyone's head.) I think it's indeed interesting to have a catalogue of useable arbitrary constants that are useful. A survey of cryptographically interesting constants would be a fun book to read and fun to write. Yet I'm not sure what it gains us. What am I missing? Jon From paul at nohats.ca Mon Jun 8 22:00:21 2026 From: paul at nohats.ca (Paul Wouters) Date: Mon, 8 Jun 2026 22:00:21 -0400 (EDT) Subject: [Cryptography] The TLS-LTS draft expires in August 2026 In-Reply-To: <17ecc44c-21ee-d392-8168-4ccbf42c0b91@senderek.com> References: <17ecc44c-21ee-d392-8168-4ccbf42c0b91@senderek.com> Message-ID: <3b73671a-63de-1af3-6ea6-c0bfee73bcd6@nohats.ca> On Mon, 8 Jun 2026, Ralf Senderek wrote: > On Mon, 8 Jun 2026, Salz, Rich wrote: > > > [1] https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-08.html > > [2] https://mailarchive.ietf.org/arch/msg/tls/aYsIi0HjV3ZagCFB9n_eRpFsBZ4/ > > [3] https://mailarchive.ietf.org/arch/browse/tls/?q="tls-lts" > > Thank you very much for the pointers, they are an insightful > read. > > [1] which makes the point that > > "This document specifies that outside of urgent security fixes > (as determine by TLS WG consensus), > and the exceptions listed in Section 4, no changes will be approved for TLS 1.2." > > But TLS-LTS does in no way require such changes to TLS 1.2. I was the Area Director for TLS at the time. My memory is that doing an "LTS version" would mean there could still be future changes to the TLS 1.2 protocol, but the TLS WG decided to freeze all work on 1.2. This is the typical way how IETF encourages moving to the next major version of a protocol. Also, since TLS 1.2 has no PQC support, it is kinda contradicting to work on a "stable long term TLS 1.2", as most people (I know Peter is not among them) want protection capability against PQ in their "long term" TLS implementations. > So it seems, GCM is seen as superior to CBC mode, and many websites have already > chosen to use only GCM mode for AES with TLS-1.2. Yes, not only due to security reasons but also because of its superior speed (and less CPU usage) due to GCM hardware offload. > This is ignoring the fact that GCM can fail in a catastrophic way if > nonces are reused, which is not the case with CBC mode. My understanding is that the way this is integrated in TLS and IKEv2, is that it would be really hard to re-use the same nonces, even for a machine that powercycles and has weak random at boot, due to the nonce being part random and part counter, and each session starting with a new random key following a (EC)DH (or KEM) exchange. > RFC 9325 states: > > "While this problem has been fixed in TLS 1.3, which enforces a deterministic method > to generate nonces from record sequence numbers and shared secrets for all its AEAD > cipher suites (including AES-GCM), TLS 1.2 implementations could still choose their > own (potentially insecure) nonce generation methods. > > Which is just another reason to request a proven way to generate GCM nonces that solves > the problem in TLS 1.2 too, which is exactly what TLS-LTS is doing already. But at what point do you stop backporting TLS 1.3 fixes into TLS 1.2, instead of just switching to TLS 1.3? Paul From paul at nohats.ca Mon Jun 8 22:04:52 2026 From: paul at nohats.ca (Paul Wouters) Date: Mon, 8 Jun 2026 22:04:52 -0400 (EDT) Subject: [Cryptography] mathematical constants In-Reply-To: References: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> <4D4C50D5-41D8-4BCF-833B-BBADA6B8F13C@lrw.com> Message-ID: On Mon, 8 Jun 2026, Peter Gutmann via cryptography wrote: > How many attacks have there been due to published booby-trapped values in > crypto algorithms? (EC-DRBG doens't count because the private-key values were > never made public, I mean published definitely non-NUMS values). There was also the RFC 5114 MODP values, but I guess it doesn't count either because we don't have trapdoor values, even if we are fairly sure they exist :P > On the way back from a recent security meeting a friend of mine made the > comment that worrying about side-channel attacks (which had come up there) was > like frantically phoning around plumbers to fix a loose tap in a house that's > on fire. Which is why I disable the spectr/meltdown workarounds on my laptop. If something on my laptop can do side channel attacks, I've already lost. Paul From crypto at senderek.ie Tue Jun 9 02:36:23 2026 From: crypto at senderek.ie (Ralf Senderek) Date: Tue, 9 Jun 2026 08:36:23 +0200 (CEST) Subject: [Cryptography] The TLS-LTS draft expires in August 2026 Message-ID: On Mon, 8 Jun 2026, Paul Wouters wrote: > I was the Area Director for TLS at the time. My memory is that doing an > "LTS version" would mean there could still be future changes to the TLS > 1.2 protocol, but the TLS WG decided to freeze all work on 1.2. This decision doesn't need to be undone, because TLS-LTS is about a safe implementation not about changes. > But at what point do you stop backporting TLS 1.3 fixes into TLS 1.2, > instead of just switching to TLS 1.3? TLS-LTS never intended to backport anything from 1.3. Ralf From pgut001 at cs.auckland.ac.nz Tue Jun 9 02:55:02 2026 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 9 Jun 2026 06:55:02 +0000 Subject: [Cryptography] mathematical constants In-Reply-To: References: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> <4D4C50D5-41D8-4BCF-833B-BBADA6B8F13C@lrw.com> Message-ID: Paul Wouters writes: >There was also the RFC 5114 MODP values, but I guess it doesn't count either >because we don't have trapdoor values, even if we are fairly sure they exist >:P Well... we strongly suspect them but no-one's ever come forward with any evidence, but then you'd still have to have rocks in your head to use them: For people not familiar with the numbers, first there were the Oakley groups, RFC 2409, updated with more modern ones in RFC 3526, both with known, published, and independently verified generation techniques. Then RFC 5114, with MODP groups equivalent to a smaller subset of the existing widely-used RFC 3526 ones appeared but with no explanation for where the magic values came from (to quote a paper on password complexity rules, "they appear to have been pulled out of thin air, or perhaps less well-lit regions"). Like a number of other RFCs, there is literally no reason for RFC 5114 to exist, and in fact given that far more comprehensive sets of MODP groups with public, verified derivation values exist the RFC with its unknown-source values may as well have been published with a giant "Never use this" banner across the top. Finally, the TLS folks had a go at inventing their own values in RFC 7919 [0], again doing the same thing as RFC 3526 but with usage requirements so... well, I can't think of an appropriate euphemism for "braindamaged" so let's call it that, that by more or less universal unspoken consensus among implementers everyone ignored it until TLS 1.3 came along and said you had to use the 7919 groups instead of the universal-standard RFC 3526 values as a means of finally getting these orphaned groups adopted... but then everyone ignored that as well. Peter. [0] You can't be a real country unless you have a beer and an airline. It helps if you have some kind of a football team, or some nuclear weapons, but at the very least you need a beer. And some MODP groups -- Frank Zappa. From pgut001 at cs.auckland.ac.nz Tue Jun 9 02:57:00 2026 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 9 Jun 2026 06:57:00 +0000 Subject: [Cryptography] mathematical constants In-Reply-To: <0E177E70-FD2C-46C3-A9EC-00E2FA3228BB@callas.org> References: <37105983.lfNtQ83HCr@puma> <0E177E70-FD2C-46C3-A9EC-00E2FA3228BB@callas.org> Message-ID: Jon Callas writes: >What's the goal here? I think it's to provide a mental fidget toy for cryptographers while security engineers got on with fixing real-world problems. Peter. From webmaster at pro-wrestling.biz Tue Jun 9 04:04:57 2026 From: webmaster at pro-wrestling.biz (Roland Ionas Bialke) Date: Tue, 9 Jun 2026 10:04:57 +0200 (CEST) Subject: [Cryptography] How carny boxing is working vs. Intelligence messeging hidden in plain sight In-Reply-To: References: <44500d9a-745e-4756-96db-5862cfd39c62@huitema.net> <4D4C50D5-41D8-4BCF-833B-BBADA6B8F13C@lrw.com> Message-ID: <20260609080457.9CFEEA00104F@dd46936.kasserver.com> An HTML attachment was scrubbed... URL: From pgut001 at cs.auckland.ac.nz Thu Jun 11 10:35:44 2026 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 11 Jun 2026 14:35:44 +0000 Subject: [Cryptography] The TLS-LTS draft expires in August 2026 In-Reply-To: References: <1d9d3c1e-32ac-85a8-95bf-9495d58ff34a@senderek.com> Message-ID: Salz, Rich via cryptography writes: >The only way to move this forward within the IETF is to publish it as an >individual RFC. I believe the editor of that series is willing to do so. I >don?t know Peter?s views on this, and I would not blame him for just not >caring about IETF publication any more. There's a bit of a backstory to this one (I'm the author of the draft), I've been travelling for work so this response is a bit delayed: - I first posted it in 2016, and was asked to delay publication as an RFC until TLS 1.3 was finished, so as not to interfere with the 1.3 process. - After waiting some years for TLS 1.3 as requested, I proposed it again, and it was shut down with the excuse "we've got TLS 1.3 now, we can't have -lts". An IETF person then suggested I submit it to the independent submissions stream, which I also did as requested. - The very same person then blocked it when I submitted it there based on a series of made-up-on-the-spot hurdles which, if applied to other RFCs, would probably have prevented about half the existing TLS RFCs from ever being published had they been applied to them. So "the editor of the series was willing to do so", then blocked it once I submitted it. The next step will be to appeal this, now getting on for ten years, but a more effective technique that I used to get RFC 8894, SCEP, passed after 20 years when another IETF person kept raising pointless objections preventing publication was to note that their term was up in under a year, wait a year, and then continue the process with the next person in the role, whereupon it passed without comment. Peter. From tennantcharlie at mail.com Sat Jun 13 02:38:13 2026 From: tennantcharlie at mail.com (tennantcharlie at mail.com) Date: Sat, 13 Jun 2026 06:38:13 +0000 Subject: [Cryptography] Something to think about. Message-ID: https://github.com/luckyduckcode/bitcoin-fan-fiction Sent using the mail.com mail app