Sign in

Filippo Valsorda

@filippo.abyssdomain.expert
59K followers 541 following 2.6K posts

@geomys.org founder / RC F'13, F2'17 Cryptogopher / Go cryptography maintainer filippo.io / github.com/FiloSottile mkcert.dev / age-encryption.org sunlight.dev / filippo.io/newsletter

PostsRepliesMedia
Pinned
Filippo Valsorda @filippo.abyssdomain.expert · 06/09/2026
I am going write-only on social media for a bit. I'm ok! It's just not doing me or the world much good to scroll right now, and I have a mountain of really cool stuff to do. Anyway, if you see my posts with interactions restricted, this is why. You can reach me via email, Slack, or Signal.
leaflet.pub
A social media hiatus
I am taking a hiatus from consuming social media. Not sure for how long. Maybe a month (so until early October 2026)? We'll see how it goes. I will keep pos…
11251
Filippo Valsorda @filippo.abyssdomain.expert · 28/09/2026
🏍️🦋
0341
Reposted by Filippo Valsorda
bryan newbold @bnewbold.net · 28/09/2026
Hello World from the PLC organization (plcred.org)! The org was soft-announced back in March at AtmosphereConf. We've been working through logistics step by step and now have a public web presence we can point to.
blog.plcred.org
First steps of the PLC organization
1425165
Filippo Valsorda @filippo.abyssdomain.expert · 28/09/2026
I'm excited to announce that the PLC Organization now has a statute! And a bank account! And a @standard.site publication! All the important stuff. The PLC Org is an independent Swiss Association meant to operate the PLC directory, which collects and distributes signed updates to atproto accounts.
blog.plcred.org
First steps of the PLC organization - Public Ledger of Credentials Organization
One year ago, Bluesky Social PBC announced their intention to facilitate the creation of an independent organization to operate the Public Ledger of Credenti…
425157
Filippo Valsorda @filippo.abyssdomain.expert · 28/09/2026
The thing that worries me most lately is that many people who know that “fascism is bad, actually” have also convinced themselves that AI tools must be eschewed as fake or impure. In a self-reinforcing loop, there is relatively little AI tooling and infra by “fascism is bad” folks.
825734
Filippo Valsorda @filippo.abyssdomain.expert · 24/09/2026
filippo.io/mldsa@v1.0.0 is now updated to the Go 1.27 implementation and API. It's also now a transparent wrapper on Go 1.27+ using type aliases, so the same program can use it alongside crypto/mldsa without issues. Essentially, it's a drop-in compatibility replacement for crypto/mldsa.
0282
Filippo Valsorda @filippo.abyssdomain.expert · 17/09/2026
We got paged the other night, so now I know a lot more about ZFS internals than I ever thought I would. groups.google.com/a/chromium.o...
groups.google.com
Tuscolo2026h2 write-path degradation on August 9th
1260
Filippo Valsorda @filippo.abyssdomain.expert · 13/09/2026
Triaged a large batch of issues found by a zkao.io scan. Some good bugs, but no vulnerabilities. (LLMs are especially bad at telling those apart.) LLMs found zero (0) vulnerabilities above SEV:LOW in Go crypto so far 💁‍♂️ 💅
a long list of freshly filed issues:
#81502 crypto/x509: clarify VerifyOptions.CertificatePolicies semantics
#81501 crypto/tls: document custom RSA decrypter requirements for key exchange
#81500 crypto/x509: document duplicate handling in CertPool.AddCertWithConstraint
#81499 crypto/x509: reject unsupported bounds in critical name constraints
#81498 crypto/rsa: VerifyPSS accepts salts longer than the hash in FIPS-only mode
#81497 crypto/tls: repeated ech_outer_extensions placeholders bypass reference ordering checks
#81496 crypto/tls: RSA key exchange accepts ciphertexts shorter than the modulus
#81495 crypto/tls: decodeInnerClientHello discards trailing ech_outer_extensions data
#81494 crypto/tls: final ServerHello can accept ECH after HelloRetryRequest rejected it
#81493 crypto/tls: parseECHExt accepts trailing data in outer ECH extensions
#81492 math/rand: NewZipf accepts non-finite parameters that prevent Uint64 from returning
#81491 math/big: ProbablyPrime skips Miller–Rabin rounds when n is MaxInt
#81490 math/big: Int.GobDecode accepts negative zero that can panic in arithmetic
#81489 math: Jn and Yn mishandle extreme orders
#81488 math/rand/v2: ChaCha8.UnmarshalBinary panics on an overlong read buffer
#81487 math/big: ProbablyPrime panics when the Lucas parameter search exceeds its bound
2623
Filippo Valsorda @filippo.abyssdomain.expert · 11/09/2026
Oh damn I had not seen the details of the MicroTik RCE: the client can send a public RSA key with correct N and e = 1 and the server will use it. Two primitives/protocol things that would have prevented it: if RSA was defined with a fixed e, and if SSH clients sent a key hash instead.
github.com
CVE-2026-67276 - GitHub Advisory Database
RouterOS does not compare the complete RSA public key...
26016
Filippo Valsorda @filippo.abyssdomain.expert · 10/09/2026
What's the point if GitHub has unsandboxed RCEs, Hugging Face has unsandboxed RCEs, Forgejo has unsandboxed RCEs... Anyway, we gotta stop shelling out to git in security contexts.
Forgejo v16.0.4
Release notes
Security bug fixes
PR: Critical: fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the .git folder, performs variable template expansion on files listed in .forgejo/template, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.
1646
Filippo Valsorda @filippo.abyssdomain.expert · 09/09/2026
19% of all WebPKI certificates issued yesterday included an SCT from the Geomys Tuscolo Certificate Transparency log 🤯
sctdata.geomys.org
CT Log Usage Dashboard
Measured by counting embedded SCTs in trusted leaf certificates, using Censys data.
1282
Filippo Valsorda @filippo.abyssdomain.expert · 06/09/2026
Oh hey, actually, before I log off, real quick: do you have an artist you like to recommend for a logo of a project? Ideally someone in the atproto community. Self-recommendations welcome!
106310
Filippo Valsorda @filippo.abyssdomain.expert · 05/09/2026
Again and again, demanding work from dozens or hundreds or thousands of unaffected dependents instead of fixing vulnerability scanners does not scale, and is an open source sustainability issue. github.com/FiloSottile/... (do NOT dogpile on the reporter, call your vuln scanner vendor instead)
"I wake up" cat cycle meme, the cat is an open source maintainer, the pattern is

"I get asked to update a dep
to fix a vuln I'm not affected by
because someone's vuln scanner sucks"
620815
Reposted by Filippo Valsorda
Sophie Schmieg @sophieschmieg.infosec.exchange.ap.brid.gy · 03/09/2026
Given the multiple cryptanalysis papers that came out in the last few weeks, I have updated my very unscientific guide to the security of various PQC algorithms to account for them. keymaterial.net/2025/12/13/a-very-u…
keymaterial.net
A very unscientific guide to the security of various PQC algorithms
After publishing my series on UOV, one feedback I got was that my blog posts made people feel more confident in the security of the scheme, because “at least someone is looking into these things”. I don’t necessarily know if that is the takeaway I would make from my posts, but it gave me the idea to write my extremely subjective, and very much biased guesstimates for how secure I consider various approaches and problem families within PQC. Since unfortunately I do not possess infinite wisdom or the gift of time travel, these are at best informed guesses, and I take no responsibility for being wrong on any of them. **Update (2026-09-03):** There have been several cryptanalysis papers that have come out since I wrote this article, which have changed some of my priors, I have added updated sections to reflect these changes. ## Generalities There is a somewhat popular saying in cryptography “attacks only get better”. It’s a vacuously true statement, since obviously an attacker will always use the most powerful technique currently known, but I think it is also at least slightly misleading, implying that progress on attacks is not only inevitable, but also somewhat continuous. Instead, what we are seeing is usually something like this: Initially, when a certain technique is first seriously discussed, attacks come in quickly and parameters have to be adjusted to account for them. With time, as our understanding of the space grows, we tend to refine those attacks, but it is a process of diminishing returns. It is possible that some novel mathematical technique starts a new spurt in advances in attacks, but importantly, there is usually no continuous improvement in attacks. As an example, if we look at RSA, we first have the naive factoring algorithms such as trial division and Fermat’s method, which predate cryptographic use. Then, in the seventies, they get joined by the first major improvement in the space, Pollard’s rho. In the 80s, we get the quadratic sieve, as the first subexponential algorithm, joined by various lattice methods. Finally in the 90s, more than 30 years ago, we get the current best factoring algorithm, the general number field sieve, a refinement of the quadratic sieve, as well as further improvements on lattice techniques. Quantum algorithms also first enter the scene, with Shor’s algorithm. After that, successes die down substantially, mostly confined to relatively minor improvements to the general number field sieve. This is not because we stopped working on factoring algorithms, but most of the effort shifted to other targets such as The Montes’ algorithm for factoring polynomials over discrete valuation rings. If we look at elliptic curves, the story of attacks is even less exciting. There is, to this date, no known generic classical attack against elliptic curves that is better than a space-time traded off version of a brute force search. This is again not because the topic isn’t studied, elliptic curves are one of the most fundamental building blocks of algebraic geometry, and we know them in great depth. In fact, we know them well enough that we can even start to explain this lack of attacks: They are the most generic form of Diffie-Hellman out there. All in all, this makes our job predicting the future of which algorithm is likely to break and which ones are likely to last, very, very hard. We are not looking at nice, predictable trends, but instead are mostly looking at a process that jumps in huge steps every few decades. A different view to look at the same trends is to say that a scheme gets more trustworthy every time it survives an attack. From that point of view, attacks that fail teach us something about the scheme itself, adjusting our priors, making it more trustworthy. This is particularly true for attacks that tell us something fundamental about the underlying problem; the more general the attack, the more it can teach us why a scheme is resiliant. But, now, without further ado, my personal list about how safe I think various approaches to PQC are, together with how familiar I am personally with the space and how much I think it has been studied. ## 1st Place: Hash-based Signatures There isn’t much to say about hash-based signatures. They have a security reduction to the properties of the hash function used. Any signature scheme, and pretty much any public key encryption scheme requires a hash function somewhere in its construction, be it to compress the message, act as a random oracle, a key derivation function, or as a one-way function. If we cannot construct a secure hash function, we cannot do cryptography. In fact, if we consistently failed in creating secure hash functions, we would most likely live in a universe where P equals NP. Hash-based signature schemes have reduction proofs that reduce their security to that of their underlying hash function. As such, hash-based signature schemes are at least as secure as any other asymmetric (or symmetric) cryptographic primitive. They have plenty of drawbacks, but lack of security is not one of them. While I haven’t studied them to great depth, there is also just not much to say about their security. They are secure. Note that one of the drawbacks that some hash-based signature schemes have is the necessity to keep state (LMS/XMSS). While these schemes are as secure as their hash function if used correctly, the same is not true if the state is not managed correctly, i.e. if one-time-signatures are used more than once. While I have extremely high confidence in the mathematics of hash-based signatures, I also have extremely low confidence in our collective ability to not corrupt state once in a while. ## 2nd Place: Lattices It is hard to overstate my confidence in lattices. General lattices, such as used in FrodoKEM, being broken is pretty much all but equivalent to proving P = NP, at which point all cryptography vanishes (since symmetric cryptography reduces to boolean satisfiability very easily), and it is time to find another career. Lattices feature heavily in arithmetic number theory, as they arise very naturally when studying number fields. As such, lattice algorithms are actually far more central to mathematics than factoring algorithms. The number of problems an efficient lattice reduction algorithm solves is far higher than that of an efficient factoring algorithm. The main reason for that is that lattice problems are the simplest form of Diophantine equation problem, the linear Diophantine equation. You can see an example of this in one of my previous blog posts. This makes lattice reduction one of the most useful algorithm to calculate pretty much about anything in discrete mathematics. Far from being constrained to just algebraic number theory, they also show up in algebraic geometry, in the description of Abelian varieties over the complex numbers. Or, as it turns out, p-adic numbers, as studied in my PhD thesis. Given how central they are to mathematics, I would be extremely surprised if someone, somehow, found a way to improve on generic lattice reduction. Even when it comes to quantum algorithms, lattice reduction is probably one of the most studied one, and so far, no generic improvement has been found, and several fundamental looking obstructions have been identified. Lattices, as a mathematical object, have been studied pretty much for the same time as elliptic curves have been, since both arise from the same underlying questions about the circumference of an ellipsis. In this study, certain integrals arise naturally, defining a function that has two periods in the complex plane. In other words, functions that can be seen as defined on the complex numbers modulo a lattice. And the simplest of these functions , obeys a differential equation . In other words, and its derivative define a elliptic curve. In cryptography, lattices also have been studied about as long as elliptic curve have. First as an attack, due to their mentioned ability to solve Diophantine equations, and soon after as cryptosystem themselves, by increasing the lattice rank to the point that the reduction becomes impossible to compute. The main reason you might not have heard of them before is their generally larger overhead compared to elliptic curves and RSA, making them unappealing in a world where elliptic curves and RSA are unbroken. But we are not using generic lattices, we are specifically using module lattices. Those are the lattices coming from number field orders. A number field is a field extension of (such as adding the imaginary unit _i_ to the rational numbers), and an order in such a number field is a generalization of the integers (such as adding the imaginary unit _i_ to the integers, to obtain the number field order called the Gaussian integers). These number field orders are canonically lattices themselves, and any finitely generated module (I.e. vector space, but for rings) over them is again a lattice in a canonical way. If there is a break of ML-KEM or ML-DSA, my money would be on exploiting this additional structure. However, even when it comes to this additional structure, it is very well understood and studied. Looking at MLWE and NTRU specifically, both problems are deeply related to the p-adic rational reconstruction problem. In the case of MLWE, we need to switch to RLWE, but a number field order can be seen as a module over an order of some subfield, so this doesn’t really change the picture all that much. So what is the rational reconstruction problem? Recall that, in order to attack LWE, we needed to find such that , which mainly boils down to describing the kernel, the solutions to . For RLWE (or indeed, for NTRU), we need to switch to a number field order, which we mainly do by replacing the capital with a lower case . We can, of course, without much consequence, switch the sign of the error term, and write , for the lattice we need to reduce. With a slight reordering, this is equivalent to . Since and are small in some metric, this means that what we are asking is given a fraction with bounded numerator and denominator, which is only known modulo some ideal (or more generally a number of finite places), find the numerator and denominator. We all know this problem when we replace the finite places with infinite places, especially over , albeit usually less dressed up in formal mathematics lingo: This is the question of which fraction fits best with some given limited precision decimal expansion, such as the question of whether an output of 1.666 came from an actual result that was 5/3, or 1666/1000. This problem (over finite places, i.e. modulo a prime) arises relatively naturally when studying number fields, and the only way we know for solving it is lattice reduction. This is a very common pattern in arithmetic number theory, you usually take problems that arise there and reformulate them until you can express them as a lattice problem, and then proceed to reduce the lattice when the number field is small enough. The opposite, where you can use the number theoretic properties of the number field to say something about a lattice without reducing it on the other hand is very rare. That being said, we are not using a random number field when it comes to lattice cryptography, but a fairly small set of very specific ones, which have properties that are not usually encountered in many number fields, such as having a class number of 1, and an easy to calculate group of units (up to some finite cofactor easy to calculate, that is, but still this is usually a hard lattice problem for a random number field, but is easy for the cyclotomic fields heavily ramified over 2 that we want for our cryptographic purposes). That being said, even with these blemishes, when it comes to module lattice cryptography, we are talking about a very well understood and explored part of mathematics, that should be very safe to use for cryptographic purposes. **Update (2026-09-03):** Since writing this article, two advancements have been made in lattice cryptanalysis. First HAWK has been broken by a classical attack, making it so that an attacker has to only reduce a lattice that is much smaller than the one assumed. This makes the scheme no longer attractive, as the necessary increase in parameter choices pushes it beyond ML-DSA in terms of signature and public key sizes. You might have noticed that I did not even mention HAWK in this overview to begin with, and there is a good reason for that: While NTRU and MLWE rely on the mentioned step of going from local information at a finite place to global information (the thing that we only really know how to do with lattice reduction). HAWK’s public key already used global information, so my argument as to why even number field based lattices should be secure did not apply to it. All in all, the fact that HAWK was broken should not be considered as all that relevant information when it comes to the security of other lattice schemes. Second Daniel Simon, of Simon’s algorithm fame released a quantum algorithm that claimed to solve the dihedral coset problem in polynomial time. This rather unassuming title would be a bombshell for lattice cryptography and beyond, as it would imply that a lot of instances of LWE and general lattices are solvable on a quantum computer. The paper received a lot of attention and led to another set of quantum algorithm people writing another paper that points out some fundamental problems with the given algorithm. That paper gives an information theoretical argument that generalizes further, and has led Kuperberg, another famous quantum algorithm person, to conjecture that it might be possible to prove that at least certain common approaches to solving lattice reduction with a quantum algorithm might _never_ have more than a polynomial advantage over classical algorithms here. All in all, this is a great showcase of the dynamic I mentioned in the beginning of this blog post: The failed attack led to us learning more about the nature of lattice reduction, to the point that it has substantially increased our confidence in the security of lattices. ## Update (2026-09-03): 2.5th Place: Have you considered Kerberos First suggested by Adam Langely, mostly as a semi-serious thought experiment, Kerberos, as a protocol, is already quantum safe. This is due to it using only symmetric cryptography, which is unaffected by quantum computers. With the recent results on Classic McEliece (which I will go into in the next section), “just use Kerberos” should now be mentioned as more desirable from a security point of view than any of the algorithm families discussed below. This is a moderately uncomfortable situation, because basically, if lattices fail, we do not have any other conservative choice to fall back to, but at the same time, given our very high confidence in lattice schemes, maybe is actually the right fallback to think about. Of course relying on symmetric cryptography to secure the internet would require a substantial amount of rearchitecturing, and have rather uncomfortable consequences for what privacy means in a future like that, but it is important to keep in mind that even without asymmetric key agreements, we would still have at least some ideas on how to proceed. ## 3rd Place: Codes I know a lot less about codes than I do about lattices, I’ve always considered them as the smaller sibling of lattices. Both schemes fundamentally work via underdetermined linear systems, where the solution has certain special properties. Being small in the case of lattices, and having lots of zeroes (i.e. being small in the Hamming metric) in the case of codes. Their construction has many similarities, to the point that code based cryptography can be attacked with the same lattice reduction techniques that lattice cryptography has to deal with. Compared to lattices, codes are far less central to mathematics, but whether that is a good or a bad thing is hard to say. But really, I haven’t studied codes to any necessary detail to have much of an opinion on them, other than that they are fine, probably, at least as long as lattices are fine. They are also less efficient than lattices in pretty much all of their instantiations, and at least I do not know how to think of them as a more general mathematical problem (akin to the p-adic rational reconstruction problem that governs MLWE/NTRU). **Update (2026-09-03):** At the same time that the other two mentioned papers came out and grabbed all the spotlight, a third paper was published on Classic McEliece. Initially, this paper only claimed a distinguisher attack, i.e. an attack that would allow an adversary to decide whether a given public key was created using Classic McEliece’s key generation algorithm (and have a private key), or randomly chosen in a way that just makes the format match. Distinguisher attacks are usually not by themselves a problem. We only rarely care about being able to hide our public keys in random data, after all. But they are also quite often a harbinger of things to come. Being able to distinguish a correctly formatted, but random instance of a problem from the instance that was created via key generation means that the actual problem used to safeguard the algorithm is not what we originally thought it was. This gives insight in what the actual problem underlying a cryptographic algorithm is, and if that actual problem turns out to be substantially easier than what we thought the problem was, we can potentially figure out a key recovery attack. And indeed, the authors of the paper managed to tweak their quasi polynomial distinguisher into a quasi polynomial key recovery attack. While the attack is quasi-polynomial, it is still quite expensive to run, and so while quite a few people currently believe that Classic McEliece’s standardized parameters are all easier to break than AES 128, as far as I am aware, nobody has been able to actually run the algorithm itself. This is somewhat similar to what the situation is with RSA 1024 at the moment, believed to be breakable, but nobody has the spare compute lying around to actually demonstrate the break. While BIKE and HQC, the other two code based KEM schemes that were in the NIST competition (with HQC being the one selected by NIST) are not affected by this attack, it certainly does not give me great confidence when the what is widely seen as conservative candidate of an algorithm family suffers a break like this. ## 4th Place: Isogenies Now to a bit of a controversial placement: Isogenies. What, even though SIKE was broken? Yeah, well obviously I don’t place SIKE at 4th place, it’s somewhat lower, right above Vigenère ciphers, and only because the attack is more interesting. SQISign on the other hand is a different story. The main reason to place it ever so slightly above multivariate cryptography in my opinion is that we much better understand the underlying hard problem and how it relates to the scheme itself. I am not ashamed to admit that I have a bias towards pretty mathematics, and SQISign does some of the most beautiful mathematics I know of. That being said, the scheme is for now too slow to actually be used in practice, and while it can be reduced to the endomorphism problem, we cannot currently rule out that the endomorphism problem ends up being easy, especially given that it is far less central to mathematics than lattices are. It has been studied somewhat extensively, though, but I am somewhat worried that the best experts on the endomorphism problem in algebraic geometry are just now slowly even learning about the existence of isogeny based cryptography. After all, the SIKE attack is based on a theorem discovered in 1997, and yet wasn’t discovered until 2022, showing a huge gap between academic algebraic/arithmetic geometry and cryptographers working on isogeny based crypto. ## 5th Place: Multivariate Cryptography I’ve written a whole series on Unbalanced Oil and Vinegar, probably the most basic of the multivariate schemes. Since then, a new attack has come out, leveraging wedge products. While the attack is far from catastrophic, it also feels very arbitrary, similar to the Kipnis–Shamir attack on Balanced Oil and Vinegar, it seems to me that we are missing something to really have a full understanding of the space. Humorously enough, even before the paper, I had tried unsuccessfully to attack UOV using wedge products, more precisely I tried to figure out if there is a structure in the cotangent space that can be exploited, so the fact that wedge products were a meaningful attack vector is not surprising per se, but still, if we want to trust UOV, we need to, in my opinion, have a better understanding of what the hard problem here actually is. It is easy to point to Gröbner bases here, but in my opinion the gap from generic Gröbner basis computation to the specific UOV problem is quite large. While all NP-complete problems necessarily reduce to each other, reducing to a Gröbner basis computation is one of the easier reductions, just like you can reduce a computer program to a boolean circuits satisfiability problem by literally translating the instructions, you can reduce a problem about polynomials to a Gröbner basis computation. One thing that particularly stands out to me about Multivariate Cryptography is that variations that have tried to reduce the size of the public key ended up broken quite often. To me, there is something missing about fully understanding what makes this problem hard to fully trust it, but my progress in understanding the problem space better has at least given me a glimpse of why basic UOV should be secure. That being said, realistically, I should place them above isogenies, mostly because we have had more survived attacks in this space, but this my list, and if it doesn’t contain at least one upsetting placement, it wouldn’t be very subjective now, would it? ## Bonus: Why RSA and Elliptic Curves both fall together One question that I got asked recently was why RSA and elliptic curves, while looking so different as cryptosystems, are both susceptible to Shor’s attack, when all these other schemes barely spend a word talking about why Shor’s does not apply to them. While it is true that at first glance, RSA and elliptic curves do look very different, they are actually far more related than one might think, some of it is even already visible in classical attacks. As I described in my post on why elliptic curves are really the only option for discrete logarithm problems, elliptic curves contain the multiplicative discrete logarithm as a subcase (at least if you allow for stable models). And for multiplicative discrete logarithm problems, we already have the same attacks working on RSA and DLOG. From that perspective it might be less surprising that an attack that is polynomial on RSA also solves ECC. More concretely, the thing that Shor’s algorithm actually solves is the Abelian Hidden Subgroup problem: Given a group , a function is said to hide the subgroup of if is constant on each coset, but different for different cosets. In particular, if is a normal subgroup, this means that is defined and injective on . The hidden subgroup problem is Abelian if the group in question is Abelian. This is a bit of a mouthful, so let’s look at a trivial example first, using as our group and try to hide as a subgroup. A function would hide this subgroup if it has a different value on the cosets, for example, if the function was just the value of the integer modulo 3. For a slightly more interesting function, which actually meaningfully hides something, we can look at the world of variant Sudoko, where we often see the concept of a modular line or modular mirror or similar, which requires certain digits to have the same residue mod 3 (For example this one or that one). Solving these puzzles is usually done by coloring the corresponding digits in one of three colors, indicating the residue class mod 3. Importantly, it is (at least initially), not known which color corresponds to which residue class, which starts to show why the function is considered hiding this subgroup. Of course, even if you just mapped integers to colors, the hidden subgroup would still be pretty easy to find by anyone who can count to three (and importantly, solving the Sudoko has nothing to do with solving the hidden subgroup problem), but you can imagine that for a larger modulus, this becomes an actually hard problem. While not necessary, it is very useful to know the classification problem for Abelian groups when looking at this question for Abelian groups in particular. All finitely generated Abelian groups can be written as the product , where . Knowing this means we know very well how, at least in theory, any subgroup of an Abelian group looks like, which is going to make the next bits a bit easier to grasp in their generalities. Knowing that Shor’s algorithms can solve the Abelian Hidden Subgroup problem, and now knowing what the Abelian Hidden Subgroup problem is, all that is left to do is to show where the subgroup is hiding, for both RSA and elliptic curves. As discussed, elliptic curves are more or less the most generic of all DLOG groups, so we don’t really need to concern ourselves with the intrinsics of how elliptic curves work, and can instead just take a generic group G (and as a bonus, this allows me to use multiplicative notation without feeling dirty). In fact, let’s start with DLOG. So given two elements , we are looking for such that . Instead of working with G as domain, we use two copies of , and define our function as . Since , this is equal to , i.e. it’s a linear transform on followed by a discrete exponentiation. But the discrete exponentiation is a group isomorphism, so we can basically ignore it for the purposes of hidden groups, since the hidden group definition does not really care about the range of the function to begin with. As a linear function, it is easy to see where maps to the unit, namely exactly for vectors generated by . Since is a group homomorphism, we can use the group isomorphism theorem to know that is constant on each of the cosets and injective on the quotient, i.e. hides an Abelian subgroup. Applying Shor’s algorithm, and obtaining a generator of this subgroup, we can recover k, since all elements of this subgroup have the form . Reformulating RSA into an Abelian Hidden Subgroup problem is even easier: The security of RSA is build on the attacker not knowing the order of the group, since the order of is , from which we can recover n’s factors p and q easily. So how is order finding an Abelian Hidden Subgroup Problem? Just take a random element and define as . This function has the same result exactly for all the multiples of the order of a, in other words it hides as a subgroup of . And the order of an element is always a divisor of the order of a group, so we can use this to find factors of n. Hidden Subgroup Problems are more general than just this, and are mostly just a framework to restate problems to. In fact, we can restate lattice reduction as a hidden dihedral subgroup problem. But importantly, quantum computers are really good at operating on Abelian groups, but have, at least so far, have not shown any success whatsoever on non-Abelian groups. This does make sense, given their construction, and gives us some data on why lattices have withstood quantum cryptanalytic attacks so far. ### Share this: * Share on X (Opens in new window) X * Share on Facebook (Opens in new window) Facebook * Like Loading…
24217
Reposted by Filippo Valsorda
The Verge @theverge.com · 02/09/2026
In an internal Slack message obtained by The Verge, 1Password’s Karimov downplayed the overtly racist comments from DHH, telling staff the following: www.theverge.com/tech/988536/...
Verge quoted text:

As I said, people have different personal opinions. You believe in your heart that DHH is evil, that you have the moral high ground, and that nothing will change your mind.

However, not everyone believes that. It is not fair to claim a monopoly and ostracize team members who might disagree with you.

There are people who are afraid to speak up simply because they will be personally attacked.
4150282
Filippo Valsorda @filippo.abyssdomain.expert · 31/08/2026
I love absolutely everything about vulnbrocards.com by @yossarian.net. I actually hope these become widely recognized references. blog.yossarian.net/2026/04/11/B...
blog.yossarian.net
Brocards for vulnerability triage
4339
Filippo Valsorda @filippo.abyssdomain.expert · 30/08/2026
TIL that under memory pressure Linux will evict .text, and then thrash for a couple minutes or more, reading it back thousands of times, before hitting the OOM killer. For 60MB of executable out of 8GB of memory (0.75%). That's objectively silly.
8551
Reposted by Filippo Valsorda
Filippo Valsorda @filippo.abyssdomain.expert · 29/08/2026
Someone should definitely make an anonymous cgit renderer that's up to 2010s qps standards, though, agreed. It's actually a very LLM friendly job, because you can even target HTML byte-equivalence on—ironically—a large example dataset.
4181
Filippo Valsorda @filippo.abyssdomain.expert · 29/08/2026
I know it's unpopular to say because the scrapers are evil and stupid (and most of them are!) but I can't get over how small the numbers are in all of these posts. 18M/day is 200 qps, and there isn't even a bandwidth cost argument. Those are Raspberry Pi numbers. people.kernel.org/monsieuricon...
911810
Filippo Valsorda @filippo.abyssdomain.expert · 29/08/2026
I used to be very good at playing the negotiation game, on behalf of myself and others. Times have changed, and I've probably lost the pulse, but a big part is understanding what game the other side is playing. This is a good post to read for early- and mid-career folks: lobste.rs/s/mroowi/bei...
2344
Filippo Valsorda @filippo.abyssdomain.expert · 26/08/2026
Ok, I think the ML-DSA performance side quest might be complete 🏎️ Very proud of how safe and clear the final incremental changes are, too.
A table of improvements in ML-DSA benchmarks showing progressively better delta all the way to -40% overall
2472
Reposted by Filippo Valsorda
Russ Cox @swtch.com · 25/08/2026
Frontier LLMs are much better and dramatically faster than I am at finding and fixing bugs. If you are not asking them to debug your code and review your bugs, you are doing it wrong. A thread of Claude wins. (No longer at Google, btw.)
819120
Filippo Valsorda @filippo.abyssdomain.expert · 25/08/2026
I am so happy we can now divinate precise diagrams in minutes to help reason through complicated code. (This is the "butterfly" of the Number Theoretic Transform of ML-DSA. It's faster not to reduce non-overflowing intermediates, but I had to convince myself that they do not, in fact, overflow.)
A wire diagram with rows and cells and a zoomed out detail that shows how to get to outputs from inputs and the relationships of the bounds.
3282
Reposted by Filippo Valsorda
Anton Zhiyanov @antonz.org · 25/08/2026
The new JSON package is finally production-ready in Go 1.27, so I've updated my JSON v2 guide. It explains all the main differences between the json and json/v2 packages, with interactive examples for each one. Check it out! antonz.org/go-json-v2
antonz.org
JSON evolution in Go: from v1 to v2
Reviewing the key changes in json/v2.
2427
Filippo Valsorda @filippo.abyssdomain.expert · 21/08/2026
ML-KEM and ML-DSA fill matrices/vectors with output from SHAKE, each element derived from slightly different inputs. This is perfect for SIMD instructions, so now we have func ReadMulti(s []*SHAKE, out [][]byte) backed by AVX2 on amd64, and by the existing two-lane asm on arm64. go.dev/cl/818720


benchmark \ host    linux-amd64_c2s16  linux-arm64_c4as16
                              vs base             vs base

RoundTrip/Alice               -10.86%              -5.23%
RoundTrip/Bob                 -14.10%              -5.53%

Sign/ML-DSA-44                 -4.39%              -0.69%
Sign/ML-DSA-65                 -3.15%              -0.49%
Sign/ML-DSA-87                 -3.78%              -0.62%
Verify/ML-DSA-44              -18.07%              -6.05%
Verify/ML-DSA-65              -21.12%              -7.15%
Verify/ML-DSA-87              -25.42%              -8.20%
Keygen/ML-DSA-44              -12.85%              -4.68%
Keygen/ML-DSA-65              -14.66%              -5.49%
Keygen/ML-DSA-87              -20.41%              -6.79%
1414
Filippo Valsorda @filippo.abyssdomain.expert · 19/08/2026
We got a lot of traces, thank you! The main category we are missing (unsurprisingly) is Windows. We got one (1) pure-Windows session 😅 Please... idk, ask a friend? help-test-crypto-passkey.exe.xyz Also, I worked around an interop issue in KeePassXC and ChiPass. If you use those please try again!
## Windows platform (webauthn.dll serializer)

- [x] Edge or Chrome on Windows 11 + Windows Hello (PIN, face, fingerprint)
      — one Edge session: ES256, UP+UV, no BE, counter increments
- [ ] Firefox on Windows + Windows Hello
- [ ] Windows + security key, in Chrome and in Firefox
      — Windows mediates every key, including PIN entry
- [ ] Windows + phone via hybrid protocol
- [ ] Windows + iCloud Passwords app or 1Password as a Windows passkey
      provider (the plugin API, not the extension)
- [ ] Windows 10 vs Windows 11 (older webauthn.dll)
- [ ] Chrome on Windows + Google Password Manager
103413
Filippo Valsorda @filippo.abyssdomain.expert · 18/08/2026
Oh, I just realized quantum computers (and the massive size of ML-DSA signatures) will probably kill asymmetrycally-signed JWTs as bearer tokens. This is good. 90% of the time, asymmetric signatures are unnecessary complexity, and a session ID or HMAC would do just as well.
64115
Reposted by Filippo Valsorda
Recurse Center @recurse.com · 18/08/2026
🍂📝 Applications are OPEN for the Fall 2 Batch, which begins on September 21! Spend 6 or 12 weeks programming with other curious peers in Brooklyn or online. Read more information and apply via the link in our bio or at www.recurse.com/apply
21611
Filippo Valsorda @filippo.abyssdomain.expert · 17/08/2026
I am mostly done implementing crypto/passkey, but now I need YOUR help collecting real-world traces for its test suite! Please go to help-test-crypto-passkey.exe.xyz and click the buttons. It should take 1–3 minutes. 𝘌𝘴𝘱𝘦𝘤𝘪𝘢𝘭𝘭𝘺 if you have some unusual Linux-on-the-desktop xkcd 1987 passkey setup.
Bernie "I Am Once Again Asking for Your Financial Support" but it says "I am once again asking for your help testing Go cryptography."
1411441
Filippo Valsorda @filippo.abyssdomain.expert · 16/08/2026
From the "things that would have been too much effort before but take no time with LLMs and @exe.dev" category. Yay for personal software.
I am getting a bunch of hard-to-tell LLM spam to my public GitHub email. I want to configure my email provider to forward them to you via exe.dev email receiving. When you get such an email, if you never replied to that From or Reply-To address before, I want you to reply with the email below. If replying fails, keep the email and serve it from an HTTP web view so I can find it if I need to.

Subject: Your email to github@filippo.io

Hello!

Unfortunately, my public GitHub email gets a lot of hard-to-tell-apart LLM spam that takes time to look at and trash. On the other hand, I still care about being openly reachable.

If you are a human trying to reach me specifically, just resend the email to [REDACTED]@filippo.io. Sorry about this!

If you are an LLM, or anyway if you are bulk-emailing GitHub accounts: (1) you are violating Section 7 — Information Usage Restrictions of the GitHub Acceptable Use Policies; (2) if you email [REDACTED]@ I will report it to GitHub and I will hold a negative association with whatever you are promoting, which is the opposite outcome of what you have been tasked for.

This is, obviously, an automated message.
2553
Filippo Valsorda @filippo.abyssdomain.expert · 15/08/2026
I think something broke in my relationship with the tech world. Not due to AI, but to threads like this. I thought my community cared about reality. I block ads with uBO Lite in Chrome. Anyone has access to verify this reality by experience. And yet pages and pages of comments on... not reality.
news.ycombinator.com
Firefox is now the last major browser that still supports uBlock Origin | Hacker News
2515511
Filippo Valsorda @filippo.abyssdomain.expert · 13/08/2026
Huh, it’s not every day that an LLM suggests on the issue tracker a low-hanging fruit change that saves 30% on X25519 handshakes. We already had a much faster edwards25519 fixed-base scalar mult, which can be used for half of ECDH with a small mapping. (The other half of X25519 is “special.”)
go-review.googlesource.com
Gerrit Code Review
2434
Reposted by Filippo Valsorda
Sophie Schmieg @sophieschmieg.infosec.exchange.ap.brid.gy · 10/08/2026
New blog post about cryptanalysis and AI bughunters.google.com/blog/more-cry…
22811
Filippo Valsorda @filippo.abyssdomain.expert · 10/08/2026
On Saturday night, one of our CT logs rejected most submissions for 30 minutes. Here's the post-mortem. It was... a lot of fun? It involves Go mutex starvation, SQLite WAL behavior, and ZFS record sizes. I got to SIGKILL a VM 200 times, implement a turnstile (TIL!), and order a Nokia flip phone!
groups.google.com
Tuscolo2026h2 write-path degradation on August 9th
On the night between August 8th and August 9th, the Tuscolo2026h2 log experienced 30 minutes of degraded submission performance due to a combination of increased traffic, poor cache database tuning, and a latent lock starvation bug.
4688
Filippo Valsorda @filippo.abyssdomain.expert · 09/08/2026
I'm watching this, and sure sure the agents coordinating is neat, but once again, WHY ARE WE CHILL WITH Artifactory HAVING SEVERAL RCEs, SSRFs, and unauthorized writes. Why are we chill with Hugging Face having RCEs. Why are we chill with GitHub having RCEs (unrelated, from April).
817417
Filippo Valsorda @filippo.abyssdomain.expert · 07/08/2026
It’s very clear by now that if LLMs are not improving your software quality it’s either a revealed preference (yours or your org’s) for more volume vs more quality, or a skill issue. The level of testing and review they are enabling in the Go cryptography standard library is amazing.
935835
Reposted by Filippo Valsorda
Russ Cox @swtch.com · 05/08/2026
Experimental new tool from me. pkg.go.dev/rsc.io/cmd/m... is useful for cross-operating-system or cross-architecture Go development work. If your test machine is on the internet (or just your local network), you can use it as a 'go test' and 'go run' target and keep developing in your usual setup.
pkg.go.dev
mote command - rsc.io/cmd/mote - Go Packages
3537
Reposted by Filippo Valsorda
fig (aka:[phil]) @bad-example.com · 01/08/2026
a neat thing about hubble is that you can get a point-in-time* snapshot of the whole network. vs doing your own backfill crawl, which will give you samples spread over a >24h period any researchers who want this, feel free to reach out
1625
Filippo Valsorda @filippo.abyssdomain.expert · 01/08/2026
Paging @masnick.com to the Streisand effect courtesy phone. An “engine problem“ is a complete non-issue and it was corrected in 24h! But Go2Sky sued @avherald.com! Now I’m reading about their 2016 incident they wanted to hide, and I’d never, ever fly an airline with this approach to transparency.
1177
Filippo Valsorda @filippo.abyssdomain.expert · 31/07/2026
After a year and a quarter of operating the Tuscolo Certificate Transparency log (with a total of 8 minutes of planned downtime)… I'm happy to announce the second Geomys CT log: Trastevere! It's basically the same, except it's a Dell PowerEdge R6515 racked in Seeweb's Frosinone, Italy datacenter.
groups.google.com
The Trastevere Static CT log
Certificate Transparency Policy
3371
Reposted by Filippo Valsorda
Chris Peikert @chrispeikert.bsky.social · 29/07/2026
Also: HAWK’s entire foundation was very new—just 4-5 years old, an infant by cryptographic measures! Most brand-new cryptography gets broken or severely weakened before long. This is normal and good. Now AI will help speed up that process more systematically.
0226
Filippo Valsorda @filippo.abyssdomain.expert · 29/07/2026
I'm seeing folks draw the wrong conclusion (in good faith or not) from the HAWK attack. HAWK is a scheme that 1. cryptographers were suspicious of and 2. was still in the assessment process. A break is GOOD. It means the process is useful, and it INCREASES confidence in the selected algorithms.
111620
Filippo Valsorda @filippo.abyssdomain.expert · 29/07/2026
I know it’s not most folks‘ primary concern, but LLMs or not, I’m unimpressed by how soft these infrastructure services are. What do you mean HF had a Jinja2 template injection. And I’m still not over GitHub’s unsandboxed RCE. Geomys might need to self-host code/CI to avoid a weak link.
1020119
Filippo Valsorda @filippo.abyssdomain.expert · 26/07/2026
I rigged up frood (my Alpine initramfs NAS running on an Ampere Altra, which continues to work great) to have a direct 2.5 Gbps Ethernet link to the secondary 5 Gbps fiber uplink router, so it can do downloads faster and without saturating the primary. I don't know why I didn't do it sooner!
github.com
frood: add direct usage of the secondary upstream · FiloSottile/mostly-harmless@e5f289c
2261
Filippo Valsorda @filippo.abyssdomain.expert · 26/07/2026
I keep finding new obvious LLM use cases. I have this old tool, md-ld, which collects orphan Markdown link references, so you can just type prose and then find links later, while preparing to publish. *Of course* Claude Code with just WebSearch and WebFetch can fill them out for me from context.
github.com
md-ld: add -llm flag · FiloSottile/mostly-harmless@9957940
4330
Filippo Valsorda @filippo.abyssdomain.expert · 26/07/2026
It's not my usual beat, but I wrote a pure-Python ML-DSA verifier. pip install mldsa It's 350 lines, CC0/0BSD, single-file, no dependencies, and thoroughly tested. Signature verification handles no secrets, so it doesn't need to be constant-time.
words.filippo.io
Production ML-DSA Verification in 350 Lines of Python
I am publishing a production, pure-Python ML-DSA verifier. It's just 350 lines, and pretty readable and robust.
17211
Filippo Valsorda @filippo.abyssdomain.expert · 25/07/2026
Get your own totally official Geomys FIPS 140-3 Entropy Source! 🎰 Only at @gophercon.com in Seattle, next month. Compatibility with any Go version is not guaranteed 👀
A clear plastic box with 5x4 small dice in it, and a label saying Geomys FIPS 140-3 Entropy Source. It leans against a crocheted gopher.
2574
Filippo Valsorda @filippo.abyssdomain.expert · 24/07/2026
JFrog Xray is defective, flagging unaffected binaries as vulnerable, and the cost is borne by maintainers who have to field requests to work around it. This is a real open source sustainability issue. (The problem here is JFrog, not the person who politely opened the issue.)
github.com
v1.3.1 release binaries embed Go toolchain vulnerable to CVE-2025-68121 (crypto/tls session resumption) · Issue #730 · FiloSottile/age
Summary The published v1.3.1 release binaries appear to be built with a Go toolchain that predates the fix for CVE-2025-68121 (Go issue golang/go#77217), a crypto/tls session-resumption vulnerabili...
4326
Reposted by Filippo Valsorda
Python Package Index @pypi.org · 22/07/2026
The Python Package Index now rejects new files published to releases older than 14 days. This mitigation prevents long-stable releases from being poisoned in case publishing tokens or workflows of PyPI projects are compromised. blog.pypi.org/posts/2026-0... #python #security #supplychain #pypi
blog.pypi.org
Releases now reject new files after 14 days - The Python Package Index Blog
PyPI no longer allows publishing new files to releases older than 14 days.
04517
Reposted by Filippo Valsorda
Fucking Every Word @everyword.bsky.social · 20/07/2026
fucking cryptographers
111130