Security Cryptography Whatever

AI Lattice Proofs With Chris Peikert

Wed, 26 Aug 2026 00:00:00 +0000

The robots are at it again, and this time they’re solving, and breaking(?), math and cryptography! Things have been happening in the lattice corner including new leapfrogging complexity results in the closest vector problem (CVP), AND a possible poly-time quantum attack against the dihedral coset problem (DCP) that made everyone freak out for about a week (UPDATE: looks like it’s busted: https://eprint.iacr.org/2026/1693). ALSO, there was an important distinguisher attack against Classic McEliece, which on its face doesn’t sound like a big deal, unless you’re familiar with the track record of efficient distinguishers in the history of code-based cryptography… 😱

To help us make sense of all this we are joined again by OG friend of the pod Chris Peikert! We had trouble with his audio but tried our best to fix it, apologies.

Links:

https://openai.com/index/ten-advances-in-mathematics/
https://cdn.openai.com/pdf/ten-proofs-oai.pdf
https://x.com/ChrisPeikert/status/2083534770403750025
https://bsky.app/profile/chrispeikert.bsky.social/post/3msp3boueis2z
https://en.wikipedia.org/wiki/Boolean_satisfiability_problem
https://knowyourmeme.com/memes/wordcel-shape-rotator-mathcel
Chen 2024: https://eprint.iacr.org/2024/555
https://eprint.iacr.org/2026/1630
https://eprint.iacr.org/2026/1693
CVP within n^(1/2-ɛ) - : https://eprint.iacr.org/2026/1655

Deirdre: Hello, welcome to Security Cryptography Whatever. I’m Deirdre.

David: I’m David.

Thomas: I’m Thomas and I’m going to be lucky if I have one good minute in this podcast.

Deirdre: That’s Thomas. We have a returning special guest today, Professor Chris Peikert. How are you, Chris?

Chris: I am great. Great to be with you again tonight.

Deirdre: Yeah, I think you were with us in our first year, and now we’re very happy to have you come back. And now we have you on camera for the first time. There’s been a lot of news in lattices. And so we had to reach out to, I think it’s fair to say, our fattest favorite lattice cryptographer to ask him questions, especially about new proofs about closest vector problem, new proofs about shortest vector problem, something called dihedral coset problem and how it affects lattices. And also Classic McEliece, because why not? So to intro, OpenAI unleashed their, I think it’s still closed model. And I forget the name of it, Astra.

David: Astral.

Deirdre: They all have a cute, whimsical, powerful name or whatever. And they targeted it at a bunch of just pure math problems, it appeared to be. And they put out this paper that was like, OpenAI’s 10 math proofs. and one of the 10 was like a new result for hardness of the closest vector problem. And when I saw this, I was like, “Oh, that’s interesting, and maybe I will actually go look at the proof.” But I think you read it first, and you’re like, “Actually, this is kind of nice.” Can you tell us your take?

Chris: Yeah, so I think the first character of my skeet tweet thread on this was the exploding head emoji, like, wow. And it’s held up. Like, the result itself is this new proof. So it’s about the closest vector problem on lattices and actually approximating the closest vector problem on lattices, right? So the closest vector problem is I give you a lattice and I give you a target point somewhere out in space. And the goal is follow a lattice point that’s as close as possible to that target point. And that’s the exact, like you have to follow exactly the closest lattice vector to the target. And then there’s this approximate version which says, oh, you don’t have to give me exactly the closest. You can give me a point which is within some factor of the closest. Okay. So that’s like the approximation factor. And for a long time, we’ve known that the closest vector problem is NP-hard in that exact version.

Chris: Like that goes back to the 80s. That’s classic stuff. And then in the 90s, people showed that increasing the approximation factor, which can make the problem easier, right? Like you have more possible answers. It’s an easier problem. But even then, if you increase the approximation factor to like any constant, 100, a billion, a Google, whatever, it’s still NP-hard, right, to even get approximately close to the factor. And then even if you go to factors like n to the 1 over log log n, right, so not quite a polynomial. n is the dimension here, by the way, dimension. So not quite polynomial, but merely i-ish, polynomial, close-ish is still NP-hard. Okay, so that was like the last word that we had on the NP hardness. And it was from around 1998. I think maybe there’s a follow up journal version in 2003. So more than 20 years. And then this hadn’t budged, like nobody had improved upon that. And that result used like this heavy PCP machinery, probabilistically checkable proofs and all this stuff. Technical, doesn’t matter. And then OpenAI shows up on August 1st and is like, hey, we show that actually polynomial approximation, CVP, is NP-hard. And their polynomial is n to the 1 over 400.

Deirdre: I was wondering what that term really was.

Chris: And so, yeah.

Deirdre: That’s good.

Chris: And so that’s a fixed polynomial, right? N to the 1 over 400. That’s the first term in the title of the paper. CVP is NPR. But what’s exciting is that it’s some fixed polynomials end to a constant. And then I quickly noticed not making any intelligent observation whatsoever, but it’s like, why end of the one over 400? Like, is there something intrinsic there? Is there something important? And so you run to your model, you run to your favorite cloud or your chat or whoever. You say, can you improve this? And it says, oh, yeah, actually, I can get you like end of the one over 28 without doing anything but like improving the bookkeeping here. Like I didn’t change anything about the proof. I just used better numbers. Right. So I found it really interesting that like Astra didn’t try to even.

Deirdre: Well, we’re not even really sure how they queried it or what they asked it, but it does.

Chris: This polynomial. Yeah.

Deirdre: Seem that you can come up with a impressive attacks with very simple queries with not a lot of detail about what you’re asking the model to do. So driving down that factor from one or driving.

Chris: Exactly.

Deirdre: Up that factor from one of one over 400 to one over 128 or whatever. So how so that is bringing the closer and closer to the actual closest vector problem as opposed to like this approximation. bound, right?

Chris: No well it’s making it’s taking you farther away from the exact version.

Deirdre: The other way around. Okay, yeah, yeah.

Chris: Farther away yep yeah because like we know yeah.

Deirdre: Cool. And that’s attractive because you can do more efficient cryptography if you have more space, kind of?

Chris: Well, for the CVP, actually, crypto is not in this regime at all. So this is like purely a complexity, computational complexity result. So, yeah, I just want to put that out there. But there is this one half or n to the one half barrier, like square root of n barrier that’s known, where we know that the square root n approximate CVP is in the class called co-NP, the complement of NP problems.

Deirdre: Yeah.

Chris: And because of that, it’s highly unlikely. Okay, so this would cause some major collapse in the polynomial time hierarchy, dogs and cats living together, like chaos everywhere, right? So we do not have any reason to make, we very much do not expect square root n to be NP hard. But now we have like, oh, n to the 1 over 400 is, n to the one over 28 is, n to the one over eight is with like other people kind of pushing and prodding on the models to like improve this thing. And as of just a few days after that, somebody who goes by the name of Mira on Twitter, I don’t even know who it is, poked the models long enough to get them to prove, oh yeah, I can get any n to the half minus any tiny constant. So like arbitrarily close to square root n basically is still NP hard. So now we have this like total phase change, you know, up to square root n, but not quite is NP at square root n and beyond. You have, you know, very good reason to think it’s not NP-hard. And so we went from like this huge unknown gap to like completely closed gap in a matter of a few days with just miles poking on things. I mean, that’s insane.

David: So I want to go back to that a little bit to make sure like I’m kind of understanding that like what changed. So, like, in general, even if it’s not, like, directly related to the things that we ultimately ended up making cryptography on, like, we like the idea of the problem remaining complexity theory hard for worse and worse approximations, as opposed to over time to keep it hard, having to make the approximation slowly approach the real problem. because if the approximation remains hard at arbitrarily large sized things, then we can feel better about how hard everything is overall.

Chris: Yeah, you got it. I mean, it’s kind of a vibes thing. It’s not like a formal result, but like, let’s take away CVP precisely. Let’s drop that problem and just take a kind of other lattice problems like shortest vector problems and things. We can do cryptography from those problems with approximation factors that are like n or n to the 1.5 you know things like that or n squared right so like very small polynomials approximation factors give us crypto from certain lattice problems and now we’re saying oh well n to that nearly one half for cp at least is np hard so it it seems like not a big jump from this np hard regime and we you know that should kind of gives us a little more confidence you know if you feel like I mean by contrast the—

Deirdre: Yeah.

Chris: Best algorithms we have to attack these problems in like efficiently in polynomial time they only get like exponentially bad approximation factors like nearly two to the n so you got to go all the way out to like these huge factors in order to solve these problems efficiently and so this kind of gives us a belief that okay these small polynomial factor problems are probably hard like that that that’s a good good warm and fuzzy feeling yeah.

David: Yeah, because like, previously, like, 1 over log log n, like, at extremely large n is basically just like, n to the 0, right, n.

Chris: Yeah kind of yeah.

David: But to get out there with one over the end of 400, you need to be able to end of the E to the E to the 400.

Chris: Yeah right right if something like that yeah yeah.

David: Or something like that for it to cross over. So it’s like, all these numbers are fake.

Chris: Yeah. Yeah. And I think, I think the other thing that’s cool about this, I don’t think anybody expected it or would have bet on it. Like if you had asked me last Friday is small, you know, tiny polynomial approximate or hard NP hard, like probably not. I don’t, I don’t think that’s, that’s going to be even true, much less do I expect it. And then, so it just completely changed our understanding of these problems.

Deirdre: One other thing that you mentioned when you were skeeting, posting about this on Blue Sky, was that the proof is actually quite elegant and uses novel techniques, which is like wonderful to see because even humans sometimes have a hard time giving a grokkable, nice proof of some either, you know, something that they’re trying to establish or that, you know, a lemma is correct or something like that. Can you explain that a little bit?

Chris: A couple of things about this. So the, you know, the prior best result that goes back to the late 90s, using this like really heavy machinery, this PCP machinery, and all this like self-composition, really complicated. It’s pretty hard to follow. It’s a great result, but it’s like pretty quiet run. Why can’t be there. And then this result, it just like shoots straight at the target. I mean, it gives this direct reduction. I know you all remember from undergrad, like to prove a problem and be hard, you give a reduction from 3SAT to your problem.

Deirdre: Yeah yeah sure we all remember from undergrad.

Chris: So you guys do these in your sleep still. So that’s what this did. It just went straight from 3SAT to a CVP problem, this approximate CVP problem. And it did so with really just elegant, beautiful, algebraic encoding of the 3SAT formula. You have to take a 3SAT formula and translate it to a CVP, a lattice and a target point, right? And satisfying certain properties. And it just did it straight. It took like, oh yeah, we’re going to encode these whole formulas as a Reed Solomon code, a Reed Solomon code word. And we’re going to take each clause and encode it in a slightly different way as a Reed Solomon code word and put constraints. And these constraints give you a CVP instance. Actually, it gives you this, the side effect is it gives you this nearest code word problem instance, actually. So it goes by two steps. First, it goes to the nearest code word problem. And then there’s a very simple prior known reduction from nearest code word problem to CVP. So the interesting novelty is in that step to nearest code word, which is quite cool. And it’s just unlike anything I’ve ever seen. I asked some people around, and they hadn’t seen it either. I asked the people who would like work in the coding complexity and like all these polynomial code coding problems. And they’re like, yeah, I mean, I’ve seen some stuff with shadows and whatever, but nothing nearly quite like this. So really original, really elegant,

Deirdre: Yeah.

Chris: Very beautiful.

David: And to just like confirm I know we all know this from undergrad but to confirm um what we definitely learned in ECS 376, like when you’re doing the reduction there, the goal is to say, look, 3SAT, we all agree, you know, is NP hard. So if you can take another problem, or you can take a 3SAT instance, convert it into another problem, solve that problem, and then convert it back, we must know that that other problem is at least as hard as 3SAT. So in this case, we took an arbitrary 3SAT instance, and we turned it into, I don’t want to solve that problem, instead I’ll solve CVP directly and then therefore had we done that it must be at least as hard now which way does the—

Chris: Exactly a plus yeah yeah yeah yeah.

David: Inequality get rid see this was the thing that always confused me I would always get backwards I never remembered which direction of the reduction was which is that three sat less than or three sat greater than CVP.

Chris: It’s 3SAT less than or equal to cvp because uh we’re saying like the difficulty of the three set problem is no more than the difficulty of of the cvp problem but you know the inequality aside, you have it exactly right. And the interesting thing, like we’re trying to prove that not CVP is NP-hard, but like approx. CVP, right? So what you have to do is actually design a reduction that maps this formula to a CVP instance, but you need to kind of like polarize it in some way. So if the formula is satisfiable, you need to generate a CVP instance that is a yes instance, like the target point is pretty close to the lattice. But if the formula was not satisfiable, target point has to be like much farther away from the lattice by this n to the 1 over 400 factor or whatever the factor is. So you need to kind of generate these like two very different situations from merely the fact that this formula is either satisfiable or not. And you don’t know whether it is your reduction just transfers its satisfiability to these two conditions. So that’s why it’s super intricate and tricky to some approximation proofs.

Deirdre: Yeah. This kind of jumped out at me when we were analyzing this because we’ve seen other proofs, other algorithms from models. We especially care about how they’re applicable to cryptography. And this is sort of a hop, skip and a jump away from how hard are some of the lattice problems that we build our cryptography on. But sometimes, like we’ve seen some papers come out that are basically driven by some of these large language models, such as ones that of Anthropic, that are sort of like, okay, you obviously kept it up to date with the latest literature in the field. And you saw all the pieces, you were able to keep it all in your context, and you were able to put the pieces together and then kind of draw the rest of the owl. And like the result is a result and it’s meaningful and it’s useful, but it’s also not very clever. I don’t think the words elegant or, you know, interesting or, you know, any of the things that you used to describe this proof would be used for that. But now this is apparently fully powered by yet another model with a different way it was grown or a different way that it was targeted or something like that. and it’s it’s very interesting to see and we we might be reaching the point because I’ve been sort of trying to keep my ear out for do we get an Alpha Go moment when it comes to mathematics or cryptography or anything like that where the models start doing something that to the human experts seems different or notable or I would never think of that or alien because sometimes these you know Go grandmasters would describe the moves that AlphaGo would take and they’d be like, it’s like someone came down to Earth and was playing some crazy alien version of Go with moves that I would never even think of. And this smells something in that ballpark. So yeah, I don’t know.

Chris: Yeah I I I kind of agree with everything you just said I mean I don’t want to minimize anything from the previous results they’re super impressive but like you say like the for the most part people say like okay yeah you took like very uh expertly put together a lot of different pieces and put them in in in different ways but like the dominoes were kind of all there lined up we didn’t quite see how to knock over you know the first one or whatever and then you know the model found it and then everything falls falls and and it comes out great and like that’s super useful uh super interesting but I think this is the first one you know where I can you know from my own knowledge and experience confidently say like oh this is really original like this is it’s not alien math because it’s all known stuff it’s like these read solomon things or whatever right but they were the whole path that it took was like extremely different from anything you know I’m aware of and anyone I’ve talked to is aware of so that is that’s why I think you know the Mythos Hawk break and everything I was like oh that’s really cool this one I was like wow like whoa this is really.

Deirdre: Yeah. All right. Anyone have anything else before we we pivot? No. Cool. Awesome. You mentioned that there were some you mentioned before we started recording that there were some other results that had come out recently. not the closest vector problem, but the shortest vector problem that jumped out to you that we had completely missed. Do you want to share with that with the class?

Chris: Sure. Yeah. I mean, it was over a span of maybe three days. We had three different papers posted to ePrint, which is like the cryptography preprint server, all getting more or less the same result, which the result is the following. The shortest vector problem, so that is you’re just given a lattice, there’s no target point, and you want to follow the exact shortest non-zero vector in the lattice.

Deirdre: Mm-hmm.

Chris: So zero is always in there, that’s shortest, obviously, but you want the shortest non-zero vector in the lattice. So the state-of-the-art for the exact SVP is from 2015, And it’s basically a two to the. So exponential time with a nice clean n in the exponent, right? And with a little extra, let’s worry about that. So basically two to the n, and then these new papers, you can get something like two to the point seven, two something something times. So they improve the constant in the exponent from like just one times n to 0.7 something times n. And they all came out like within a couple days of each other. And they all use the same basic technique. And some of the papers admit that like AI came up with this and other ones, we kind of got a little help from AI. And some of them don’t comment at all on other AI games. But in any case, it’s pretty clear that AI was the force multiplier. And so, you know, that’s the result that hadn’t been improved in 11 years. It uses the same core component behind the prior test results, but does some extra in a more efficient way. It doesn’t seem to have any effect on the security of Datis crypto, as far as anyone can tell, because it’s attacking this exact worst SVP. So if the algorithm has to provably work, and it’s already has a nice shape to it and everything. And so kind of heuristically, we know how to do much better than the 2^{0.7 whatever n}. So it doesn’t really change as far as we can tell any of the security estimates, but it is like, again, like as a pure complexity result, it’s a big step forward.

Deirdre: I wonder, I’m the fact that we had like three that came out very close to each other. And they were very similar. I’m very curious how they were querying or what they were querying. And like, I’m just I’m, I’m very curious, because I have a feeling they all kind of went in the same path. And they finessed it into, you know, something that they, you know, they put out themselves. Well, yeah, this is,

Chris: And this is one where like all the techniques used are kind of well established and it was put together in a way,

Deirdre: All right.

Chris: But it wasn’t like, Oh my gosh, this is some brand new alien math or anything like that.

Deirdre: Yeah, okay.

David: I was going to say, I seem to recall there being a proof for one of the lattice-related problems that the average case complexity and the worst case complexity were the same. And so does that not apply here? Like you were saying, oh, it’s not relevant because it’s worst case only. But I thought that we had proved for just about everything with lattices that worst case and average case have the same complexity. So what am I misunderstanding?

Chris: Yeah, so we have these worst case to average case reductions, which is like what crypto frequently relies on, because you got to use random instances for your crypto, but you want to make sure that you’re using secure random instances that are actually hard to break. And the worst case hardness of those kind of tells you, well, you can’t break the crypto unless you’re also capable of breaking these problems in the worst case. So the reason it doesn’t kind of move the needle on that, which is a great question, is that these worst case to average case reductions usually have a blow up in the dimension to some amount. Right. So it’s like, oh, it starts in dimension N and it goes to maybe dimension 10 N or something like that. Right. And so, oh, if I can break, well, I can break the worst case in 2^0.7n, whatever n, or I can break the average case in 2^0.7n, whatever, 0.2, something times 10n, like these aren’t really comparable. So that’s the, maybe the short answer to that question.

Deirdre: Okay we’re gonna oh of course yeah yeah yeah and there’s yeah and there’s always like especially.

Chris: There’s also approximation factors in there too. This is for exact SVP. So there’s another reason.

Deirdre: If you’re trying to like, you know, the learning with errors problem reduces the shortest vector, and there’s, there’s already gaps in there as well. So like, we’ve got gaps in here. And then we’ve got gaps between the problem that we build our constructions with and all of them add up into what you can how expensive it is to try and actually estimate any of this stuff and break it.

Chris: Break it. Yeah, exactly. Yeah. So the gaps always make things a little easier and yeah. So.

Deirdre: Okay, and more lattices for our favorite lattice cryptographer. There is a is a is a is a quantum attack paper, a preliminary draft on the ePrint, and they’re trying to attack the dihedral coset problem in what they say is polynomial time. And this has been a bit of a kerfuffle because one, it’s a quantum algorithm and you can’t just code up your quantum algorithm against toy parameters and just run it and see if it works. Because we don’t have those computers yet, unfortunately. And everyone is trying to see if this paper were correct and how closely it would apply from the dihedral coset problem to things like LWE, if it were true. And we don’t know. It doesn’t sound like anyone knows. Do you have an opinion?

David: Also, can you explain what the dihedral coset problem is? Because that’s something we all also definitely know.

Chris: I have opinions. Yeah, yeah, we should start with that. Indeed, indeed. Yeah. So before we go to dihedral, we should go to cyclic, because that’s where the story begins, really, like 30 some years ago.

Deirdre: That too, because I didn’t know that one before I started reading this.

Chris: So, you know, we kind of all know Shor’s quantum algorithm, which like breaks factoring and discrete log.

Deirdre: Yes.

Chris: Right. And the way it does that is by solving this what’s called a hidden shift problem on the cyclic group, basically. So there’s cyclic groups in the discrete log problem and there’s cyclic groups hiding in the factoring problem. And quantum algorithms, computers, Shor, is really good at solving these hidden hidden hidden shift problems on the cyclic groups. Okay, huge cyclic groups. So the closest thing to being a cyclic group without cyclic is the dihedral group. Okay, so the dihedral group is basically cyclic, but also with like flips. So if you think of like an N-gon, a regular N-gon, a triangle, a square, a pentagon, et cetera, with N sides, and then you can obviously rotate it to itself, right? And then it’ll overlap with itself with all the variations. But you can also flip it, right, if it’s got an even number of sides. Flip is giving you now the dihedral group. So this is, the dihedral group is basically the symmetry of an N-gon, right? And for all we know, quantum breaks and solves this hidden shift problem on the cyclic group, huge cyclic groups, but it’s totally unable to do it on the adding this one flip element kind of destroys, seems to destroy quantum’s power to solve it. So that’s kind of a strange and bizarre situation. But there we have it. And then, so people for a long time have been trying to solve this dihedral hidden coset or dihedral coset problem quantumly. So that’s what the claimed result is basically to have done this. So you can take a lattice problem, transform it into this hidden shift on a huge dihedral group. And then if you can solve that, that gives you a solution to your original lattice problem. So that’s what we’re dealing with here. And there’s a bunch of overheads involved in these reductions, but they’re all polynomial. So the claim here is polynomial time algorithm for a dihedral coset problem, and therefore for all these lattice problems that underlie cryptography. So pretty serious. The good news or bad news or news is that people don’t seem to buy the proof. They don’t. They’re identified errors in the proof that are pretty substantial and they don’t seem to be easily fixable. And it’s in more than one place, it appears to be. So the status of this claim is still kind of up in the air. And people are trying to figure out, you know, what’s actually going on here? Are these serious issues? Are they fixable? Or is there something fundamentally, you know, insufficient with this approach? So that’s where we are as of August, whatever day we’re recording.

Deirdre: It’s just 13.

Chris: This and by the time you print we may have some resolution. I know people have found some interesting things about this so stay tuned.

Deirdre: If this did hold, how far away from LWE does it, is it, and which instances of LWE would be shaking in their boots versus others?

Chris: Yeah.

Deirdre: Because this reminds, some of us are getting flashbacks to Chen’s paper in 2024, which was a different quantum attack. And it was basically going to endanger a whole bunch of lattice constructions, but especially more complex instances like the things you need for FHE or the things you need for, there’s more space in the parameters. I think it’s between the dimension and the modulus size, things like that. And those are things that you usually use for more complicated instances, either using ring LWE for weird blind signatures or, you know, odder things than say ML-KEM and ML-DSA, which the gap between those parameters is smaller. So do you think there’s anything like that at play here if it were to hold.

Chris: Yeah I mean all these all the papers the previous paper all these questions come down to like what actual gap factor or approximation factor does this thing attack right and I think if I remember correctly with the with the chen paper it was like claiming to attack a factor that was a little bit bigger than maybe what basic encryption needs but sufficient to break you know what like fhe needs or what like more fancy crypto.

Deirdre: Yeah, yeah.

Chris: Needs but the specific factor I think didn’t really matter like if that paradigm had worked out if that algorithm had actually been correct and correct analysis we’re quibbling over the approximation factor you know is it n to the one over 400 or is it n to the one over 28 or is it n to the you know whatever like it’s the same kind of story broke it for n^3 and probably push on it a little bit you’re going to get it for n squared and for n to the one half n to the one and whatever. So yeah, like, and you’re talking about the sun, like, do you really care what the—

Deirdre: It’s sort of like asking how hot is the fire when everything’s on fire.

Chris: Temperature is? It’s freaking hot, like everything’s gonna burn. So it doesn’t matter too much. So my best understanding is the current paper, at least claims to reach factors that would, you know, break all the crypto, or, you know, more or less all of it. And, you know, so I don’t really get too wrapped up in the exact factor that’s involved, because, like, either it works as a new paradigm, or it doesn’t. And if it works, fundamentally, then, like, we need to abandon all this stuff, even though, oh, well, you’re an end quarter off from the factor that I use that now, forget about it just like go away so um that’s how I I see this.

Deirdre: Okay, yeah. I think it’s very hard to say. It’s hard to just completely say, yeah, no, there’s a bug over here. And there’s a bug over there. So just like chuck it in the bin, as tempting as it is, just like, no, no, no, it’s no, everything’s fine. Just chuck it in the bin. So I think we have to say stay tuned to the consensus on a—

Chris: Yeah, saying that the proof is flawed is like an insufficient conclusion to things.

Deirdre: Yeah.

Chris: But there will be more decisive conclusions in the near future. I’m very confident that will kind of fully resolve the unknowns right now.

Deirdre: Okay. I hope you’re right, because that’ll help me sleep better at night with all of our post-quandum options. Okay. To stop talking about lattices for a second, there was another paper on classic McEliece. I are you no we’re never going to stop talking about lattices or—

Chris: How much time you got?

Deirdre: I mean I’ve been told that secretly elliptic curves are a lattice or something like that or can be represented as a lattice problem um another another paper uh that does not seem to have any AI involved but like whatever maybe it does maybe it doesn’t who cares at this point A much more efficient distinguisher and a not very efficient decryption attack on the code-based cryptosystem Classic McEliece. but when you’re telling me about a public key encryption system and it says, oh, we can distinguish your public key from a random key. And I’m just like, okay, like, all right, like, so? But apparently, this is like a big deal in code based cryptography, where code is not we’ve implemented computer code, but we were using codes like the Reed Solomon codes. Yeah, the error.

Chris: Error correction codes.

Deirdre: Goppa, in this case, I think it’s binary Goppa codes that are underneath Classic McEliece. Goppa codes that are underneath Classic McEliece. Can you tell us why we care about a much improved distinguisher attack and why we worry when we get a good distinguisher attack for code-based - Nice photography.

Chris: Yeah, there’s a bunch of things to unpack here. So the headline paper title result is like a quasi polynomial time analysis of of McEliece for the Classic McEliece kind of parameters or the asymptotic parameter Classic McEliece uses. So quasi polynomial time means, well, not quite polynomial, but pretty close. So it’s not like n to a constant. It’s not n cubed or n to the hundred, but it’s like n to the log n. Right. That’s that’s what they’re going after. And there’s a specific reason why the log n is there, but we won’t get into it. So this is like asymptotically good because the previous thing we had was a paper from Eurocrypt 25. I think it was 25, yes. That was a slightly sub exponential, like n to, sorry, two to the like n, and then some logs that happen to log factors that end up being less than one. Okay, something like that. So just barely slightly better than two to the n and not like actually practical, like this only kicked in for very large n’s. So that was sort of the first bang or the first shot heard around the world. And then this result is like, oh no, it’s not two to the nearly n, it’s like n to the log n. So vastly, vastly better in terms of complexity. And they actually gave concrete estimates for the specific McEliece parameters, showing that the runtimes are something like 2¹¹⁵, or is it 2¹¹⁴, 2¹, something like in the 2 to the low 100s, right? That was for distinguishing. Okay, so distinguishing is like, oh, you give me a key that is McEliece key, or it’s just totally random junk. And they can tell which is which, right? They can tell which one it is. That’s what the algorithm does. And they have a proof, like a rigorous proof that it works within this running time. Okay, so like, why do we care? Who cares about distinguishing the key? It’s because of the techniques that actually allow you to do it. It’s like the ideas, the algebra, the new approach that they brought to this problem That’s very unlike anything else. And they were able to extend the technique, also do decoding, basically, or like recover the message from a ciphertext, right? Given the ciphertext, recover the message. And the way it works is like very similar to the distinguisher. They basically glue the ciphertext onto the public key, like as if it was just a slight key, and they do some fiddling with it, and they run the distinguisher. And if their distinguisher says looks good, that means you have a zero in this position of your ciphertext.

Deirdre: Oh, no.

Chris: And if it says looks random to me, that means you have a one as the error in that position.

Deirdre: Oh, no.

Chris: So you can very easily recover all the bits of the error vector in the ciphertext by just kind of running the distinguisher a bunch of times with slightly bigger parameters.

Deirdre: Oh.

Chris: So that’s the natural thing. And I should say, the fact that you can use a distinguisher to follow the error and actually do the decoding is not a big shock, let’s say. I mean, it’s very clever. It’s a cool idea. But in codes and lattices and everything, we have all these kinds of different search decision reductions that are called. It just says, like, oh, if you have a distinguisher, you can kind of leverage it to solve and follow the error and solve LWE and whatever. So search to decision reductions are like very common in this general milieu and this version of such a reduction. So they have a way to decrypt a ciphertext in like a comparable amount of time. I’m not saying exactly. There’s overhead to it for sure. But in quasi polynomial time and there are some heuristics that they need. They can’t prove it completely that it works, but in all their evidence, you know, suggests that, yeah, this actually does work. And then the natural thing that they say in the paper is like, oh, by the way, we have this distinguisher. Obviously, a really important thing would be can you recover the secret key from a public key? Right. And they say, like, conceptually, our ideas ought to be applicable to that question, too. like let’s get the secret key from the public key, but we’ll leave that for later. Okay, so stay tuned. It’s basically what they’re telling us.

David: Um and they weren’t like they were trying to do pir they’re like private information retrieval right like this was not a group of people that this didn’t just come out of the like uh crypt analysis community this came out of like privacy and they were trying to build something on there.

Chris: Yeah.

David: Like oh well our scheme doesn’t work because of this result oh wait doesn’t that apply to this other thing like is that um uh like that seems bad for what like mcgleese generally like do you think there’s something about mcgleese that it was like perhaps understudied relative to other things Or like, why do you think that this kind of popped out of a somewhat unrelated field rather than from the cryptanalysis itself? Is there any takeaway from that, or is it just the way the world goes?

Chris: I mean, I can spec. Yeah, I can speculate. I mean, I think a lot of things we’re learning from these AI papers is that like big results can come from using very different kinds of math than an error. Right, the CVP result, it was just pulled from fields and error correcting codes. Certain ideas from error correcting codes, of course, were used in complex lab problems, like I don’t know, but the specific sophisticated tools that the. Not the ones that, you know, you’re difficult to use.

Chris: So the AI’s were able to bring like very different math to these problems than most of the experts, you know, working on work. for the CVP result. They brought all this function field math and error correcting codes and things like that. And, you know, this, we did simple error in the problem before, but nothing like the tools that were brought by Astra to this problem. And so maybe what happened here was something similar where, you know, the cryptanalysis had been a pretty narrow for a long time, right? like it had basically come down to information set decoding problem and people were just saying like how quickly can I decode uh and follow errors and decrypt it um and so pushing on that same direction for many years you know didn’t yield anything really substantially new but then when people were able to bring very different kinds of mathematical algebraic geometry from 2005 uh you know all of a sudden new things become possible when you start doing these clever algebraic high degrees varieties and all kinds of stuff like that so very new tools open up some some right and new exciting results this group was trying to build what’s called doubly efficient peer so very specific kind of pir that um we basically have only one construction of it’s from LWE or Ring LWE actually.

Deirdre: Yeah.

Chris: Years ago, I think. And naturally people have been trying to build doubly efficient beer from many other assumptions. So far, I don’t think anything has really come up. They ran into this barrier to follow their narrative in the paper. They ran into this barrier and realized, oh, we can’t get it from this technique because mumble, mumble, mumble. and then, oh, wait, that break Classic McEliece in quasi-poly time. So it’s super cool how different ideas can just cross-pollinate like this and have on a— One thing that I saw repeatedly remarked after this paper started getting attention was that I heard from more than one person, yeah, but we were always a little suspicious about Classic McEliece. And like, I am younger than Classic McEliece by at least a decade. So I don’t have any of that context. I’ve just heard that it is a thing that exists. is like one of a handful of instances of code-based, you know, public key cryptography. And I’ve heard that it’s like old and trusted and it’s still standing. So like, it sounds fine to me. Like, you know, I, now that you look at like a, you can do distinguisher attacks like this on it and, you know, it smells a little something. Why do we believe these codes are strong or like, you know, strong one way and, you know, have a trap door the other day, other way, you know, all that sort of stuff. And like, I just don’t look at the deep literature there to convince myself, because I’ve never really needed to. But like, why? Like, do you have a sense of like, why there’s sort of a vibe in the field of just sort of like, yeah, but we were always like a little bit suspect. I was a little suspect of Mikalese.

Chris: Yeah. Oh, I think Matt Green publicly said it, right? It was always sketchy. But probably a lot of people think that as well. And unfortunately, I’m not younger than McEliece cryptosystem. I mean, I can tell you the things that I have heard and the things that I believe myself. One is that a lot of variants of McEliece have been proposed over the over the years to try and make it more efficient. Let’s make the key smaller. Let’s use some different codes. Let’s not use binary GAPA codes. Let’s use some other family of codes. Virtually all of these got broken. And for some reason, the original, you know, McEliece didn’t. I don’t have a sense that the community ever really understood at some deep level why All these like proposed and they just self-destruct, right? everything else around it is, is just a disaster. So that’s kind of uncomfortable. Everything else around it is, is just a disaster. So that’s kind of uncomfortable. And then I think, I mean, another aspect of it is like, people just don’t understand what it is that makes it, you know, kind of okay, where all these variants aren’t.

Deirdre: Mm-hmm.

Chris: And the level of diversity of breadth of ideas that had brought to attack it were not that wide. They kind of all came down to this variations of information set decoding. Let’s just treat the public code and then try to decode the random code.

Deirdre: Mm-hmm.

Chris: We’ll attack on the public keys themselves. But obviously, it was just like a permutation and a linear transform of this code. so it just has this it just has this kind of feeling why if this is okay exactly makes it okay when all these other things okay I at least never found a you know a good solution for these things so that’s you know probably why you know when I was in school I would talk to you know I remember talking to some professors about it and they’re like yeah we don’t know what the hell is this thing like we just don’t know what to think of it right and like scientifically you want to understand you know you want to have a reasonable explanation for why this thing is plausibly secure and I never heard one at least you know um yeah.

Deirdre: Hmm. This unfortunately is reminding me of the oil and vinegar and variants that are being tried out, especially for post-quantum signatures. And there have been, I think it’s wedge attacks against a lot of these more complicated, smaller, faster versions that oil and vinegar is a specific flavor of multivariate public key cryptography. And it just seems like all of these other ones, except OG oil and vinegar, and I think mayo, which has like a slight tweak on oil and vinegar, just keep, they keep falling down. And a lot of this sounds very similar to the story you told of codes that are code-based crypto.

Chris: Yeah, there are a lot of similarities, like you say, like people propose things to try to improve the efficiency, you know, just get broken totally. So understand is, you know, good in combination or what causes them to work or not work.

Deirdre: Thank you very much for taking on a tour on various sections of post-quantum cryptography.

David: One last important question, though.

Chris: David? Yes.

David: How are you feeling about Michigan football this season?

Chris: This season. Well, can we talk about like what’s happened since the last time I was on?

David: Oh, yeah.

Chris: We got a national championship in football. We got a national championship in basketball.

David: I mean, champions. Oh, yeah.

Chris: Who’s got it better than us, man?

David: Mm-hmm. Nobody, although. we don’t need to talk about what happened.

Chris: So.

David: Kind of in between some of those things but like right now you know we asked grandma for Kenny Dillingham and she said what Kyle Whittingham and there we are that’s gonna be great.

David: Yeah, and I’m excited to see you at the Rose Bowl in a few months. Congrats, Michigan football. Go blue. Cool. All right. Where’s my thing? Oh, gosh. I do this every time. I have a spiel that I have to give.

Chris: Sponsor read.

Deirdre: Yes. Well,

David: No, we did our one sponsor read of the year.

Deirdre: We do one a year.

David: And we thank them very much.

Chris: Hmm.

David: But we did the one.

Deirdre: Um where is it okay Security Cryptography Whatever is a side project from Deirdre Connolly, Thomas Ptacek, and David Adrian. You can find the podcast online @scwpod, and the hosts online @durumcrustulum, @tqbf and @davidadrian. You can buy merch online at security at merch that securitycryptographywhatever dot com and if you like the pod give us a five-star review. Go blue!

An Odyssey of Lattice Cryptography withh Mark Schultz-Wu

Mon, 27 Jul 2026 00:00:00 +0000

We invited Mark Schultz-Wu on the podcast to talk about the history of lattice cryptography. When lattices are explained in plain english, they are actually quite simple! I don’t think any of us have ever seen Deirdre so happy. If you’re watching the video version, there’s a section that’s 6.1 minutes long with no cuts and consists just of Deirdre vigorously agreeing with what Mark is saying while smiling. What a time to be alive.

We are hosting another happy hour in Vegas between Black Hat and DEF CON! It’s sponsored by Teleport! Thank you to Teleport, and dear readers, you should go check them out.

Links:

Mark’s IETF Post
NTRU
The original lattices are hard paper
The original LWE for cryptography paper
Entropic LWE
Dilithium round 3 submission
Recent attacks on Classic McEliece
Lectures on post-quantum cryptography from Alfred Menezes (an originator of elliptic curve cryptography)
Falcon
Regev
Tightness in Proofs

Deirdre: Okay, uh, Teleport. Teleport ad read. Uh, SCWPod is sponsored by Teleport.

David: You should probably introduce us first still.

Deirdre: Wait, oh, oh, we’re doing the ad read during the podcast?

Mark: Yes, it’s going right in.

David: We’re just gonna start the podcast and then we’re gonna talk about Teleport, who’s sponsoring our live event. Well, our, our happy hour ad. I’m just gonna talk about it now. We’re doing a happy hour again at at Vegas in the liminal space between Black Hat and DEF CON, like we have done every year for the past 3 years. And it is once again, like last year, sponsored by Teleport. And if you don’t know what Teleport is, you probably don’t have SSH. But we’re very happy that they’re sponsoring and we can attest that Thomas is a Teleport user.

Thomas: We use Teleport everywhere at Fly. We love Teleport very much. It is a very, very— if you’re a SOC 2, it is a very, very good way to get a lot of business processes Um, kind of all tucked under kind of a recorded SSH dealy. Um, Teleport is great. Use Teleport for everything.

David: And on that note, I’d like to say this is Security Cryptography Whatever, and my name is David.

Deirdre: I’m Deirdre.

David: Thomas.

Mark: And today we’re talking about lattice cryptography.

David: We’re talking about lattice cryptography. On this very professional podcast with our special guest, Mark Schultz.

Mark: Mark, how are you?

Thomas: Hi.

Mark: Yeah, I’m Mark.

Deirdre: Thanks for being here. Um, yeah, this is like Lattices Redux because one of our very first episodes we talked to Chris Piker about lattices, which was great. He also, uh, tried to show us a bunch of slides. And so we ended up talking through, uh, what our audio-only listeners we’re supposed to be seeing with like a depiction of dots on a field with vectors like that. This is another chance to lattices and try to understand all the stuff that is the area of lattices and post-quantum cryptography, especially using lattices. And you were posting on the internet recently some very, very useful history of, history of where we started with lattice cryptography, the where we started, what got broken, and how we got to things like Kyber, Dilithium, and some other fancier things you’ve done research on. So we would just have you basically talk through what you began posting elsewhere, which is like the history of over 30, maybe 40 years of lattice cryptography.

Mark: So it’s worth clarifying upfront, I am a lattice cryptographer. I, uh, what was this? I think I graduated 2024. I worked with Daniele Miciancio. I was working on fully homomorphic, although my— so I do have some background in lattice-based chemistries, but my publications, with the exception of like one which was talking about those lattice-based, uh, uh, it’s called public key encryption at least, um, was, uh, more on the fully homomorphic encryption side.

Deirdre: Yeah. Uh, and that’s the— that’s some of the fancier stuff that especially if you’re trying to do a post-quantum solution to anything that’s like slightly fancier than public key encryption or signatures, uh, sometimes you may be tempted to reach for the fully homomorphic solution because it seems to solve your problems, but it might do it, uh, computationally costly or largely.

Mark: Um, well, computation and, uh, bandwidth.

Deirdre: Yep.

Mark: So in general, the, uh, the fancier the lattice things get, the bigger you have to increase one of the parameters, the kind of the modulus, and then you also you also have to increase the dimension as well. So kind of, you can think about like 2 parameters that like counteract with each other and keep getting bigger and bigger, and then everything gets big. And then that’s how you can get like, you get FHE papers that talk about 20 gigabyte keys and it’s like, yeah, it’s like fine. It’s not the biggest keys, it’s not the smallest keys. You know, if you’re optimizing for size, maybe you get down to 3 gigs or whatever, but it’s very far from the public key thing.

Deirdre: Gosh. And I want to get back to that when we kind of reach— we kind of start at the simple beginnings, then we get over there, because then we can talk about like why some of these instances of lattice problems, like they feel a little bit more riskier in terms of we think these things when we apply them to these spaces are okay. But then occasionally a paper will show up and be like, oh, anything with parameters that are slightly this far apart, which is bigger than what they are for, for dilithium and kyber basically, or anything more complicated than that that are FHE-like, get scary. Anyway, so Thomas, I mean, I have a specific thing here, right?

Thomas: Which is like, as always, I’m just trying to reinforce things I say on Hacker News, but like a claim I make kind of regularly, which I shouldn’t be making, is that I don’t know what I’m talking about. Is that kind of lattice cryptography and elliptic curve cryptography are of, they’re not literally, I think, I think they’re not literally comparable vintage, but like they were both live ideas in the 1990s, right? I like to say, I like to say that there’s an alternate universe where lattices win over curves.

Mark: So it depends on for what particular applications. The Andrew cryptosystems, both of them, um, were introduced in the mid-‘90s, right? And the Andrew cryptosystems that we see in, in, you know, these days, they’re very similar to what was around in the ’90s. Like, I don’t want to say exactly the same, but at least for entropy, I should say entropy encryption, it’s— there’s a lot of similarities there. Entropy signatures from the ’90s got completely broken. Lattice-based signatures had a very rough going until, like, the first secure lattice-based signature was in 2008, which is rather late. The way I like to describe how late it is is that fully homomorphic encryption was in 2009. So we didn’t get signatures after fully homomorphic encryption, but it was remarkably close, which is kind of wild to think about. You know, you would think FHE is a much harder problem. Lattice-based signatures, they’re very, they’re very well understood at this point, but it took a lot longer to get there because of some additional complexities that show up with lattices for signatures in particular.

Thomas: So like, because of post-quantum cryptography, there’s like, there’s an attitude that lattice cryptography is like, you know, moon math, like whiz-bang stuff, right? And like, one of my things is just kind of pushing back on that notion that like we don’t have a good understanding of what lattice cryptography is. Another thing I like to point out is the gap in time between like in True and LWE or in True and like the, like New Hope or something like that.

David: Right.

Thomas: And like, and like the P-curves in Curve25519, right? Like everyone’s familiar.

Mark: Yeah. New Hope is a great example here. New Hope was in Chrome a decade ago. It was in experimental releases of Chrome. You had to opt in. This was a decade ago. The scheme has had no substantial cryptanalysis in the last decade, no substantial improvements to cryptanalysis in the last decade. When I say that, it’s like a decade, it’s rounding up a little bit. I think the most recent substantial improvement to lattice-based attacks, which was in 2018, when I say substantial improvement here, it’s worth mentioning lattice-based attacks usually separate into 2 components. There’s one which is phrasing the problem as a lattice, and then there’s the other which is solving the lattice problem. When I say this substantial improvements thing here, I mean the second part, the solving lattice problem. There have been some iterations on the improving the phrasing things as a lattice problem. If you’re familiar with the MatSol attack, this is kind of in this first category. One difficult thing with lattice-based cryptography, which I was actually struggling with a bit today, I was asking some people and getting not that great of responses, is that it’s really kind of a socially defined field in a certain sense. What do you mean? You might— yeah, so you might say, okay, lattice-based cryptography, what does that mean? Well, a very easy answer would be, it’s cryptography based on lattices. Unfortunately, this isn’t true at all.

Deirdre: Yeah.

Mark: Um, so as an example, the NTRU paper, the first NTRU, uh, preprint, uh, the term lattice appears in it never. Any cryptographer these days would call NTRU a lattice-based scheme. If you publish a paper on NTRU, it would get put in the lattices track, and it was described as a ring-based cryptosystem.

Deirdre: Oh, I mean, okay, I get that, I get that.

Mark: Yeah.

Thomas: So it like reduces to lattices or like can be—

Mark: it does reduce to lattices, but this is also not a satisfying way to define what lattice-based schemes are. I mean, one reason for that is like elliptic curve-based schemes don’t reduce to elliptic curves, they reduce to Pollard-Rho on a generic group, right? So maybe you call them group-based crypto, or you call them like Pollard-Rho crypto. I don’t know, like it’s— we don’t tend to define problems based on what they reduce to. Um, I mean, for factoring you like sort of do, but also like You can break RSA without breaking factoring by breaking modular, what’s called modular polynomial roots.

Deirdre: Yeah.

Mark: Like that does not actually, you do not need to break factoring to break RSA. Right. So it’s like a, the naming is kind of all over the place.

Deirdre: Yeah.

Mark: In general, lattice-based schemes do get broken by lattice-based attacks.

David: Cool.

Mark: And that’s, I’m pretty sure that’s how the naming for NTRU kind of got decided.

Deirdre: I see.

Mark: It was first ring-based and then there was a lattice attack on it and now it’s lattice-based. Um, but if we’re going based off of schemes that are based by, uh, broken by lattice-based attack, the first one was actually in 1978 with the, there was knapsack-based cryptosystems that Shamir famously broke. Um, and so maybe these knapsack cryptosystems are lattice-based. I would personally argue they are. Uh, my advisor had some papers in the early 2000s on knapsack-based cryptosystems. He’s a lattice-based cryptographer. So there’s a sense in which like lattice-based cryptography is the cryptography that lattice-based cryptographers do. And often involves in kind of reducing problems to solving computational problems on lattices, but—

Thomas: Like other than Intru, check me on this, right? Other than Intru, the schemes that we’re talking about when we think about lattice cryptography are like remarkably similar, right? Like they’re all based on the same, based on the LWE problem.

Mark: Well, yes and no. So the popular ones these days are, I’d say that there’s 2 big counterexamples to this, or maybe 3. So as an example, one thing that you might say is lattices are the only way we can get FHE. This is like sort of true if you define lattices in the right way. In particular, there’s this problem called the approximate greatest common divisor problem that was popular in the early 2010s. It kind of looks more like a number theoretic problem, like something closer to RSA, but it also kind of looks like a lattice problem if you do lattices a lot, and we can get fully homomorphic encryption from this. And Anton Zhu also has this cryptosystem he called the Mersenne prime cryptosystem. I think it was somewhere around 2015. And that also kind of looks like a lattice-based cryptosystem. And also it doesn’t, you know, it’s, it’s not LWE, it’s not NTRU, it’s its own thing. There’s also more recently, there’s these lattice isometry problem type cryptosystems, which it has lattice in the name. So maybe it’s lattice-based, but also the first part of any paper on these is always, here’s how we rewrite our things in terms of quadratic forms. And now we’re gonna do everything in terms of quadratic forms, which mathematically quadratic forms and lattices are kind of equivalent, you know, so it’s, it’s still kind of lattice-based, but kind of computationally quadratic forms end up being nicer for most crypto systems. That all being said, the predominant lattice assumptions are almost always the learning with errors problem, or an algebraically structured variant of it, or a variant with rounding, so like learning with rounding, this type of thing, or the entry problem. There are even more esoteric things than what I’ve just mentioned. In fact, like, uh, when we’re talking about, you know, kind of lattice-based cryptography, these are kind of the boring assumptions.

Deirdre: Yes.

Mark: Uh, one of my favorite things is that there’s this line of lattice-based papers which say we want to do insane stuff, we want to be crazy, and we want to be fast to make a lattice-based PRF.

Deirdre: Oh yeah.

Mark: And I think they’re within a constant factor of AES when you have AES-NI hardware assumptions.

Deirdre: Really?

Mark: Using only AVX-2. Yeah, I can’t remember the precise constant factor. It might be something big like 5 or whatever, but like you can get very fast PRFs based off of very weird lattice assumptions. These are the Spring and Leap PRFs. Okay. I don’t think anyone uses them for anything, but like they use assumptions that are much farther from kind of the boring standard lattice assumptions.

Deirdre: To cover that for our listeners, so We touched on a little bit of NTRU originating in the ’90s. So that’s the end. So let us, let us describe specifically the NTRU assumptions that those things that are consistent with what was introduced in the ’90s reduced to in terms of the security definition construction reduction and not the social construction of like, well, if I can break it using a lattice attack, then why?

Mark: Yeah, but like the NTRU, the problem underlying NTRU, I’ve heard people call it as the small decisional a polynomial ratio problem. Okay. Essentially, you have 2 polynomials, both are drawn from some small distribution, say some, like, you know, centered, some Gaussian-type distribution, discrete Gaussian, who knows. One of them you need to make sure is invertible, usually invertible mod some other prime than the prime you’re normally working with, but it’s invertible. And then you take the numerator one, the non-invertible one, and then the invertible one, invert the invertible one, multiply them together, and it looks uniformly random. That’s roughly the assumption underlying NTRU. And there’s some parameters to tweak, you know, which distributions you use. I mentioned that one might be invertible mod a different prime, what different prime you choose, but that’s kind of NTRU. And what I mentioned here doesn’t really involve lattices at all. You can reduce it to a lattice problem and attack it that way. But the kind of the standard NTRU problem, it’s about inverting polynomials and multiplying them together. Okay.

Deirdre: And then around 2005, Regev introduced, I think, did he literally call it just LWE, like the cryptosystem, or—

Mark: Learning with Errors. So, so it’s the learning with errors problem. And it actually is a very interesting history itself as well, which is like there’s this question you might ask, which is that LWE, it’s our kind of leading candidate for a post-quantum assumption. You might wonder why is that the case? And the best answer is unfortunately the most boring answer. People, very smart people have tried to break it and, you know, have failed. But LWE in particular has a very funny story in that the first person to introduce it was one of the very smart people who tried to break it and failed. So LWE originates, and Regev, he has this 2009 survey, I think, that includes this on the LWE problem that I think includes this point. But Regev was a quantum algorithms person and he was trying to create quantum algorithms for certain worst-case lattice problems. So, like the shortest vector problem.

Deirdre: I didn’t even realize that. That’s neat. That’s very cool. Yeah.

Mark: Well, so some of his— he’s kind of more recently switched over into computational biology. But some of his more recent cryptographic work was actually a faster, I think he, it was a faster factoring algorithm. So some optimizations to Shor’s stuff. Yeah. So he’s been a quantum algorithms guy for 20 years, right? Probably longer than 20 years. But so he was initially looking at these worst-case problems on lattices saying, I wanna try to find quantum algorithms for them. And he was almost able to get it to work if he knew how to solve this one problem quantumly. So if he could solve this one particular problem quantumly, he could, fully solved, you know, these quantum— sorry, these worst-case lattice problems, which were of independent interest at the time. The one problem he couldn’t solve was LWE. So he said, okay, well, instead of saying I get this algorithm for SVP, also I get a reduction from solving this very particular problem that I don’t know how to solve quantumly to— sorry, I get a reduction from SVP quantumly to solving LWE. And that’s what the paper ended up being. But LWE really came from a quantum algorithms guy not being able to solve a different problem. And that was like the isolated subset he didn’t know how to do.

Deirdre: Cool.

Mark: And it’s stood up since then. So like, I guess it’s a decent way to find a problem.

David: Yeah.

Deirdre: And now we have like a whole lineage of problems and like kind of, you know, narrow definitions of problems that all kind of nest down and reduce to different forms or slightly different variations on LWE. And like, yeah. And, um, and I think some of that, I mean, like, you have, like, a learning with errors, like, problem or game or whatever, um, that reduced to SVP, which is the shortest vector problem. Or, you know, you’ve got gap SVP, like, you’ve got, like, you know.

Mark: Yeah, well, so it’s always gap SVP. This is something that’s important to get right, um, because so SVP is an NP-hard problem, right?

David: Yeah.

Mark: So if I said that SVP reduced, uh, LWE— sorry, if I said that SVP reduces to solving LWE in the average case, that could imply that LWE is NP-hard to solve. This is not true, and it’s actually not thought to be true. Yeah. So when you mentioned gap SVP, roughly— so how it works is SVP is this problem. You have this high-dimensional kind of point cloud. It’s this structured point cloud. It’s a lattice. And you’re wondering which part of the structured point cloud is the closest part to 0. In low dimensions, it’s easy. You just do it by, like, I don’t know, looking at the thing. In high dimensions, well, high dimensions, things, you know, from recursive dimensionality, you might expect it to be much harder, and it is. So do we have any intuition as to why that’s hard?

David: Like, I get that, like, you sit down and like it turns out no one’s come up with a good answer for it, but like it just seems like—

Mark: so for SVP, right, like SVP itself, no gap, it’s just NP-hard. So it’s, you know, what’s the intuition for why it’s hard? It’s an NP-hard problem. You know, why is any NP-hard problem hard? I don’t know, they all could be easy, but if any one of them was easy, all of them would be, and we think at least some of them are hard. Right? So there is a more satisfying reason for that, for these lattice problems in particular. So these lattice problems, or lattices in general, they actually show up kind of in useful scenarios somewhere. So in particular, so coding theory wants to look at kind of high-density kind of arrangements of points that are noise tolerant, right? For standard coding theory, this is often noise tolerant in what people call the Hamming metric or pseudometric, where, you know, you get kind of bit flip errors, this type of things, you know, kind of a particular coordinate is either totally fine or totally corrupted. Another error model you could imagine, kind of instead of this digital error model, you could imagine an analog one where you might have a little bit of noise in each coordinate. This is more accurate for kind of radio communications, this type of stuff. So in this analog noise model, you might say I still want to be able to code things to get this dense point cloud so I can get efficient, say, radio communications, but I want to be able to efficiently decode things too. So in this way, kind of problems like SVP, more properly the closest vector problem, kind of have this kind of direct application. And this was actually one of the reasons that at least some of the initial computational study of lattices was occurring, was to kind of, for these kind of radio communications purposes.

Deirdre: Yeah, I could see that.

Mark: Especially since random lattices, for a suitable definition of random, are known to have very good coding theoretic properties. It’s kind of like how random linear codes, they’re kind of near optimal. Random lattices, for many definitions of lattices, are near optimal for these coding-theoretic properties. So if you could efficiently decode a random lattice, then you could get a very efficient analog communication system. This is, for fairly certain parameters, this is roughly what the LWE problem is, is kind of efficiently decoding a certain random lattice, which likely has near optimal parameters for these coding-theoretic purposes. So none of this is a satisfying reason to say why it’s hard. You know, it’s sort of close to a problem that’s NP-hard, but it’s in a kind of this parameter regime where that problem is no longer NP-hard. The problem’s in Arthur Merlin, I think. So if it was NP-hard, you would get some polynomial hierarchy collapse, one of those things that people make it— yeah, kind of, you know, cryptography still isn’t from NP-hard problems in this setting. But then also you have this other community where if they could solve these computational problems on lattices on this average case setting, or, you know, in the worst-case setting, so, uh, then they could get these better constructions, and they haven’t been able to either.

Deirdre: So, um, and we— one of the things that I sometimes hear referenced, and then, uh, if I talk to like a lattice cryptographer, they give me like a, eh, is that we have a, uh, we have like a reduction to worst-case hardness of like gap-SBP for a lot of these LWE systems. Which is like not necessarily a complexity result that we have for some of our other cryptographic constructions that we deploy in the real world.

Mark: So the answer I have to this is, which is that— so famously, we do have this reduction. This was what Regge’s 2005 paper for. It was initially a quantum reduction. It was de-quantum. It was made classical, I think, in 2009.

David: Okay.

Mark: And maybe in more generality, like since then, kind of in the more efficient settings that we tend to use lattices, there have been more and more of these reductions. The issue with these reductions is they’re what are generally called non— there’s 2 big issues with them, actually. So one is that if I wanted to use one of these reductions to build a crypto system, I would need to do 2 things. One is I would need to say, okay, now my hard problem is no longer LWE, it’s GAP-SVP in the worst case. So that’s interesting, but I would now need to figure out what worst-case instances of GAP-SVP look like.

Deirdre: Okay.

Mark: I don’t think that’s really known. So you might be able to do something. You could say like, hey, to figure out how hard gap SVP is in the worst case, I’ll sample a bunch of stuff on average and see how it is in the average case. Like, that’s a fine strategy, but then you’re not using the worst case part of it.

Deirdre: Yeah. Okay.

Mark: All right. The other bigger issue is that the reduction is highly non-tight. Oh, okay. All right. So I don’t know if people have worked out the parameters or I’ve seen a number of papers of people trying to work out the parameters, but there was a lot of debate over which papers did it right. There might have been some errors or whatever. I’ve seen estimates, I think, as high as maybe 30,000 or 60,000 lattice dimension to get appreciable security. So it’s like a—

Deirdre: and we’re nowhere, we’re nowhere using that for, for things like Kyber or Dilithium or— No.

Mark: So Kyber and Dilithium are dimension— so Kyber’s dimension’s like 512 to 1024.

Deirdre: Yeah.

Mark: The, the 60,000 dimension does actually show up sometimes in fully homomorphic encryption, but that’s more Uh, people, even then, they try to get away from that if they can. It’s more like if you can’t optimize certain parameters, you kind of have to have things that big. Yeah.

Deirdre: Okay.

Mark: Um, but the trend there is trying to get them smaller as well.

David: Okay.

Deirdre: So basically we have a thing that could be a nice, like, security, like, lower bound, except we don’t know how to use it to actually give us real-world security parameters that are actually useful, that are of any relation to that mathematical lower bound.

Mark: It’s these 2 things. It’s one, it’s this non-tightness that you’re mentioning. But then the other is that it’s not at all clear to me, or I think to other people, that it’s easier to worst-case cryptanalyze GAP-SVP than it is to average-case cryptanalyze LWE. Because at some point you need somebody to say, I have a computer, you know, I have these algorithms, I tried running them, it took a while, and this is my estimate how much longer it would take for bigger parameters, right? This kind of explicit work trying to extract concrete parameters from these kind of abstract algorithms.

David: Okay.

Mark: And if someone could write down, this is what the worst-case gap SVP instance looks like, and this is how long it takes to solve, then we would have something very interesting. But— and then also if everything was tight, I should say. But that work is also like a— I don’t know if anybody’s looked into it. It seems unclear how to characterize the worst-case gap SVP instances that you’d be reducing from.

David: Got it.

Deirdre: Okay. So in the ’90s, we had our— well, we’ve had our very early, uh, you know, social, uh, instances of lattice cryptography, uh, before the ’90s. We’ve got NTRU, which is still kind of floating around in some form since the ’90s. We get the introduction of LWE, uh, in the mid-aughts, uh, and since then we’ve gotten these other flavors of LWE. Uh, including ring LWE, module LWE, and we’ve seen these unstructured lattices. Uh, one of the crypto systems that uses that is FrodoChem.

Mark: Um, that’s just plain LWE. So that’s the initial version.

Deirdre: Okay. All right. I, for, for some reason I didn’t, I didn’t clock that. I don’t know. Uh, I’ve—

Mark: yeah. So there, there are, so, so yeah. So essentially what happens is any LWE instance can roughly be phrased as the following. You have this integer matrix, you have a secret, and you multiply them together and you add some error.

Thomas: Yes.

Mark: Uh, it’s worth mentioning this error should also be kept secret, so you might think of it as kind of a, kind of a static secret and an ephemeral secret.

Deirdre: Yeah.

Mark: But that’s like the rough shape of it. All the algebraic structure is saying is that this integer matrix— well, matrices take n squared parameters, and that can be a big number. So can we shrink that somehow?

David: Yes.

Mark: You could say, hey, instead of being this n squared matrix thing, I want this to be a matrix that is determined by one of its rows, and then maybe kind of some kind of simple transformation you apply to that row. I might want it to be some sort of topless matrix, some cyclic matrix, these types of things. The algebraic structure, it’s all a way of saying that this matrix, instead of being this fully dense one, it’s going to be this one with some interior structure. As an example for RLWE, RLWE is usually done over a negacyclic— sorry, a cyclotomic ring of power 2. This matrix ends up being what’s called negacyclic. So you have one diagonal and, sorry, you have the vector in a column, and then each time you move it over, you kind of cyclically permute it.

David: Yeah.

Mark: Except when you go off one end, you introduce a minus sign.

Deirdre: Yep.

Mark: So there is this very concrete way to describe it. The downside is that the very concrete way to describe it kind of can hide some security concerns.

David: Yes.

Mark: I said you introduce a minus sign. That sounds like extra work. Why do that? Why just avoid introducing a minus sign? Everything breaks. So that might sound like a very small reason, like, like issue you can make that would make everything break. In kind of the fancier math thing, it ends up making a lot more sense. Roughly, you have a polynomial, and if you don’t introduce this minus sign, the polynomial has this degree 1 factor, and you can kind of stunt everything down to this degree 1 factor to get a 1-dimensional instance that’s very easy to break. So the minus sign—

David: yeah.

Thomas: For people who like aren’t in their happy place when they hear the term cyclotomic field, we’re starting with like original Coke Zero LWE with what’s now called FrodoChem, right?

Deirdre: Yeah.

Thomas: And then we’re going to structured lattices where like instead of what, like a uniform random lattice or whatever, we have, you know, structure inside of the— that, that matrix, right? Why did we do cyclotomics there?

Mark: So why we do cyclotomics there, um, so it’s a, it’s a good question. You could do other forms of structure. In fact, there was this NIST submission, maybe it was called Titanium, that roughly, like, there’s this thing that was called middle product LWE. It’s its own thing. It’s like, there’s more esoteric assumptions, but it essentially said that, like, we get hardness if any of these very large set of structures is fine. So in some senses, maybe it was more conservative, but it’s also, I don’t remember all the downsides of titanium. It’s at least a lot— the middle product stuff’s a lot harder to work with. But why do we use cyclotomics there? Roughly speaking, the initial thing that was introduced was these cyclic lattices. It’s kind of the most obvious thing to do. They had antecedents and— sorry, they had precedence in coding theory. My advisor actually, I think in 2001, he— not for LWE, but for a different problem, the short integer solution problem— he said we can kind of have this cyclic structure, we can get benefits from it. But then there were these papers that said essentially that the cyclic structure means that when you view things in terms of polynomials, you get this degree 1 factor and everything can break. So you have to split off that degree 1 factor and then you get these cyclotomics. Like, it kind of— what cyclotomics are is you take the polynomial x to the n minus 1, which, uh, and then you kind of factor it and you keep the highest degree piece, very roughly. So this x to the n minus 1, very roughly, is kind of the generator of this cyclic transformation. So you start with kind of the easiest thing possible, and then you kind of keep the biggest component of it that’s secure.

Deirdre: And the primary motivation is to take a secure crypto system but make the things that you’re shuttling around on the wire smaller while keeping— while reducing to the same problem.

Mark: Well, so it’s not exactly reducing the same problem. So the idea is that now you only have to pass around one row or column of this matrix. So you get a big size win. But now it is going to be like you’re working over this structured family of instances. Yeah. So there are these concerns. Is this structure useful for attackers? Yeah. It’s plausibly true.

David: Yeah.

Mark: Um, and so RLWE, um, so R-CIS, so it’s, uh, kind of the short integer, uh, solution, uh, version of this was introduced in 2001. RLWE, I think, was roughly 2011. The structure has finally helped attackers this February, maybe. Oh, I think they got a times 4 speedup, and it seems kind of limited to that. So it is— there now finally appears to be a very small gain from the structure, but it has taken a while to materialize. It is worth mentioning, for kind of adjacent lattice problems, the structure can help. So I mentioned you have this matrix and you have a single column and you kind of apply this transformation. You can think about like having this one structured block in it. Kyber does something different. Roughly, it has smaller structured blocks, say 256 by 256 structured blocks, and then it builds the block matrix out of that.

Deirdre: Right.

Mark: This is module LWE.

David: Yep.

Mark: The reason why we often prefer module LWE versus ring LWE, and I say often because this is only true in public key cryptography, in fully homomorphic encryption, everyone uses RLWE. But the reason for public key cryptography, why we do that, is that in 2016, there were some improved quantum attacks against kind of these single block instances, not of ring learning with errors. So the attacks, I think to this day, don’t really say anything for the deployed schemes.

Thomas: Wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait.

Deirdre: Yeah.

Thomas: Modular LWE is just LWE with block matrices?

Mark: Roughly.

Thomas: Yeah.

Mark: So it’s module here. Module.

Thomas: Module. Module.

David: Module.

Mark: Sorry.

Thomas: Yeah, yeah, yeah.

David: Yes.

Mark: Yeah. But it’s roughly just you have block matrices and they all share the same structure.

Thomas: So this is this thing where you look up, you look up like modules in Wikipedia and you get—

Mark: Yeah, no, it’s impossible.

Deirdre: Right.

Thomas: Like the actual thing that’s going on here is it’s just block matrices.

Mark: It’s block matrices. Yeah. So it’s block matrices and then it’s instead of fully materializing that, you only ever materialize like the single rows you need. And then you need to have an efficient way to multiply these block matrices by a vector. And that’s where like NTT stuff can show up.

Deirdre: Yeah.

Mark: You know, so it’s a lot of it can be easier in terms of polymath, but it’s block matrices.

Thomas: This was, this was my understanding, which is now like devastated by the last 15 minutes that you two have been talking, right? My understanding before, because I’m an idiot, was that all of the complexity in these systems, all the structure that was being introduced was about something like NTT, was just about like speeding up the multiplication.

Mark: Well, so that also shows up. So it’s not independent because if I just have this dense matrix and I have a vector and I want to multiply them, that’s N squared time, right?

Thomas: Yeah.

Mark: But if I have a structured matrix here and then I will have— if it’s structured in the right way, say it’s an NTT matrix, and then I have a vector here, now I can do something N log N. Yeah. Right?

Thomas: Yeah.

Mark: So roughly speaking, It kind of does both in that we get the compactness because you only need the single row or column. And then also we get this kind of NTT-friendly form.

Thomas: Yeah.

Mark: So we can also get some computation speedups.

Deirdre: Yeah.

Thomas: Okay. So like module LWE has become, for reasons, very salient in like discussions about risk in lattice systems. But yeah, I interrupted you to say, you know, for fuck’s sake about modules and block matrices, right as you were going to say, we now prefer block matrices, or we now prefer modular LWE. I would like to hear more about the thing you were originally going to say.

David: Yeah, yeah.

Mark: So, so what happened is in 2016 there were quantum attacks, I think, against ideal SVP. Yeah, so I mentioned before that SVP is what reduces— worst-case SVP reduces to LWE. So you might think, oh, these quantum attacks against SVP, that’s concerning for LWE. Well, not really, because the reduction goes the wrong way. So if you want to solve LWE, you have to reduce to actually what’s called a rank 2 instance, kind of a block structure with like a 4 squares instead of 1, right? You have to reduce to a rank 2 instance of ideal SVP. And the quantum attacks don’t help in that setting. So in 2016, these quantum attacks in a very, in a relevant but adjacent context showed up. People were like, hey, it’s not that much worse to just use this block structure. And then we’re kind of farther away from the issue. And things have been fine since then, but also for, RLWE-based schemes, things have been fine as well. So as I mentioned, fully homomorphic encryption still uses RLWE everywhere, uses RLWE with insanely more speculative parameter sets. Like there, when I mentioned there was this times 4 speedup from the algebraic structure that appeared recently, I think you get much bigger ones in FHE.

David: Yeah.

Mark: I think that there was maybe a 15-bit speedup. I don’t remember, I’d have to check again, but that’s because FHE people do much, much more speculative things, uh, kind of, uh, to try to get things to be, uh, more efficient.

Deirdre: Yeah. And this, this kind of leads into, this is like the, there’s the boring, the boring crypto stuff, which is literally like the primitives that are basically public key encryption that you, you know, twiddle with an FO transform and turn into, uh, something that looks like key exchange, but it’s not, it’s a KEM. Uh, and then your regular schmegular, you know, signatures to give you like unforgeability or whatever you want to do. Um, but things that get more complicated than that, um, have to go into these settings that have, uh, a little bit, uh, more exotic assumptions if you want to do—

Mark: well, yeah, so I would actually say lattice-based signatures do tend to be a little bit harder than fully homomorphic encryption to get right. Oh, which again is a very funny sentence.

Deirdre: Tell me why, because I would never even have like that, that notion wouldn’t have even entered my head.

Mark: So there’s roughly 2 families of lattice-based signatures. One of them I’m more familiar with. Roughly what they do is they say, okay, so lattices looks a little bit like Diffie-Hellman. If you think of it as AS plus E, if you just ignore the error AS, it’s like, I don’t know, it’s like a one-sided group action. It’s like Diffie-Hellman, right? So you can do Diffie-Hellman type things. In fact, Kyber and things like this, they can be thought of as a Diffie-Hellman type thing that adjusts for this noise being here. Yeah. So if you’re doing Diffie-Hellman type things for encryption, you could say, hey, for signatures, I also wanna do not Diffie-Hellman type things, but I wanna do standard things. So maybe I’ll do Schnorr signatures or something like that. And a lot of people try to do this and all of them break because this noise here ends up being much more devastating. In particular, I mentioned before that the noise, you can think of it as an ephemeral part of the secret. So the noise is security sensitive. A lot of space signatures, until they started to be done properly, would often leak this noise. There would be attacks that would allow attacker to recover part of the noise. If you recover part of the noise, you can almost always break the scheme pretty easily.

Thomas: Can I just ask real quick what that attack looks like? Because this is like one of the rare instances where I have like a bit of an intuition for what that would be.

Mark: Yeah.

Thomas: But like, okay, so like I can see immediately why leaking any of the error bits in an LWE computation, like the whole reason why the system isn’t just Gaussian elimination is the error, right? So like obviously bad to leak it. But like, what does that attack look like?

Mark: So I’m pretty sure they ended up being machine learning-ish type attacks where the idea is that, uh, if done improperly, you get part— so lattices, they’re these, I mentioned they’re these point clouds. And you might imagine for these points, um, there’s kind of this initial block and then everything is a translate of that, right? So the kind of the inside of this initial block, you might call the fundamental parallel pipe, or at least lattice-based cryptographers do. So, um, so the attacks roughly would say that we can identify leakage somewhere within this fundamental parallel pipette, and then maybe it was some sort of like gradient descent-ish type attack on top of this with enough signatures to recover the actual secret, and then from there you win. It’s something along these lines. Um, there’s been—

Thomas: it’s, it’s much more interesting, interesting than the hidden number problem then, right? It’s not like we have a bit of bias and then I can literally just do like a, you know, a BKZ or something like that.

Mark: I think that there is this kind of averaging step you have to do. I don’t think you just create a lattice and I think you do need many signature samples.

Deirdre: Okay. Oh, so you do, you do need like one key and then are we doing—

Mark: I don’t know if there are attacks with a single signature. It’s not a huge amount you need. I think there are papers I’ve seen that have been like on the order of 500, but it’s, it’s something that like a, You know, it’s devastating attacks. You need to get this part right with lattice-based signatures. But that’s why if you look at stuff like Dilithium, Dilithium describes itself as kind of a Fiat-Shamir with aborts scheme.

Deirdre: Yes.

Mark: The Fiat-Shamir is as part of creating the Schnorr signature. The aborts is to say that, hey, if we would leak part of this error, we try again until we don’t leak it.

Deirdre: Oh, that’s, that’s fascinating. That’s where that comes from.

Thomas: This is still, this is getting more. So what is, What, what, what’s happening when we’re doing the Fiat-Shamir in the Schnorr signature that’s causing us to leak the error? This is like, ‘cause I don’t do signature stuff.

Mark: Well, I’m pretty sure it’s that the errors get too large. The rejection conditions in Dilithium are bounding the size of the error. I think there’s 2 rejection conditions actually, but I think that there was this paper a couple years ago that said that you only really need one of them, but that one is load-bearing. Although this wasn’t for Dilithium specifically, it was for Fiat-Shamir with the Borch type schemes.

Deirdre: Neat.

Thomas: Neat. That’s my contribution.

Deirdre: Okay, so for more exotic settings like FHE, why do you have to get more exotic and why are your parameters slightly different than the things that we might see in kyber and dilithium? And why are your assumptions more exotic as well?

Mark: So there’s a number of reasons for this. So the first thing is, I said FHE always uses ring learning with errors, not module. The reason for this is because of something people often call, like, I don’t know, seed compression, where an RLWE ciphertext has 2 components, A and B, and the A part is uniformly random. So you can just store a small seed there and you can use like an XOF or something like that to expand it. For MLWE, you kind of pick up more of these components in the front. So you would need kind of more of them. You could all generate them from a single seed. So in this setting where you can expand things from seeds, it doesn’t really matter. The issue is this expanding from seeds thing does not survive any homomorphic operations.

Deirdre: Wow. Okay.

Mark: So even something as simple as adding together 2 ciphertexts, well, now you have that, you know, an XOF of seed 1 plus XOF of seed 2. You can’t find a seed that really expands to that target. So, you now have to store the full 2 polynomials here, and in the MLWE setting, you have to store even more, right? So that’s kind of the— for FHE, you end up taking this big size hit, or sorry, this big bandwidth size hit, if you end up using MLWE versus RLWE. Okay. But there’s other more exotic things people use— do as well. And it’s worth mentioning, when I say for FHE, there’s 2 broad classes of FHE schemes. There’s what’s often called few or TFHE-based schemes, And then there is generally CKKS, BGV, BFE, they’re all kind of tensor product multiplication schemes. Okay. So for this first class, you get a lot more flexibility. You can do things much closer to public key type crypto. But the second class is the one that I’m describing that has less flexibility. In particular, for the second class, you get these weird assumptions about the error. So for, in public key cryptography, The error vector, you can kind of choose to be from any distribution you like, as long as it’s not too concentrated. If it’s too concentrated, there are these attacks from 2011, the reward-gate attacks, that start being applicable and concerning. But even things like, often people do Gaussian-type noise with standard deviation 3, that’s not too small, right? Gaussians are a little bit hard to generate, especially if you need to have a masked implementation of the generator. So instead you can actually just sum up a bunch of bits. It’s a binomial random variable. If you center it, it looks kind of Gaussian and it’s good enough for encryption. So the issue with this is that there’s this one component of FHE that’s very key where kind of a certain parameter scales with the sum of all these, the sum of the absolute values of all these coefficients. So instead FHE likes to have this noise be kind of sparse ternary noise. They want to make this as small as possible, which is a much more aggressive assumption for a particular reason. In particular, the error distribution and the secret distribution for LWE, they tend to be fine with anything. We have these proofs that like, as long as they have enough entropy, you can get— so there’s this thing called entropic LWE, where, well, there’s 2 relevant things to say, I should say. The secret distribution and error distribution, they can be the same. And then as long as the error distribution has enough entropy, things are mostly fine. But the worst-case to average-case reductions aren’t true in this setting. So even though we don’t use them for any choice of parameters, moving to settings where the worst-case to average-case reductions are no longer true is still often seen as something that’s very concerning. Okay. Just because, Uh, because you’re never quite sure how your, your parameters may be—

Deirdre: may break down, and then like at least— well, it’s more kind of deal.

Mark: It’s not like that. It’s more that in— if you’re in a regime where the worst-case to average-case reductions hold, then you kind of have this understanding that it’s hard for there to be atypical structure there that wouldn’t also help in the gap SVP world. Okay, it might help with much smaller gap SVP instances But an algorithm here is concretely an algorithm for gap-SVP, right? With the caveat of this tightness being bad. But if you start falling outside of this worst-case to average-case setting, then there could start being non-trivial attacks that wouldn’t also imply an attack for gap-SVP.

Deirdre: Okay.

Mark: So, so yeah, so in FHE, the secret distribution can often end up getting much weirder with much more aggressive assumptions. I’ve seen papers that suggest Hamming weight 32 and Hamming weight 64 secret keys, which are very small numbers, although I don’t think there have been attacks on these schemes. So, but there’s also the ciphertext modulus can get very large in FHE. Roughly, for Kyber, ciphertext modulus is 14 bits. It’s relatively small. In FHE, each, for at least these tensor product-based schemes that I was mentioning I was focusing on, Each time you do a multiplication, you kind of have to shave off 50 bits from your ciphertext modulus, very roughly. So if you have this complicated circuit you need to compute, say a bootstrapping circuit, then you might need to support 800-bit, 1,500-bit modular, things that are much larger than the 14 bits that Kyber uses.

Deirdre: Yeah, yeah. I would need some like big limb arithmetic and all of this has to be prime.

Mark: So you can usually— no, it doesn’t have to be prime. That’s one of the benefits of all of these LWE-based schemes is that the number theoretic structure of the moduli does not really matter at all.

Deirdre: Oh, good.

Mark: So as an example, Kyber is— I think Kyber is prime, but it doesn’t have to be. I mean, Sabre was another NIST finalist and it’s 2^32, right? So it doesn’t really matter. For FHE, they take a bunch of word-sized primes and they multiply them together. So they do CRT-based things, but you could do plenty of other things. It doesn’t really matter. Cool. Wow.

Deirdre: Okay. So we’ve basically done a whole tour of the history of lattice-based cryptography, including some of the whiz-bang stuff that, depending on your field, you may see some FHE stuff or things that use FHE constructions under the hood, such as like BLIND.

Mark: They are being deployed practically, generally not full FHE schemes.

Deirdre: Yeah.

Mark: But I think Apple’s Caller ID uses Uh, it uses homomorphisms of lattices. So it’s like a—

Deirdre: I wouldn’t be surprised.

Mark: It uses very weak, uh, homomorphic, uh, lattice-based stuff.

Thomas: Yeah.

Mark: And I think Google might have something as well, but I forgot.

Deirdre: Yeah, those are, those are the areas that I expect more things to kind of trickle out because like things that we might have used, uh, blinded commitments, uh, or other, other things using elliptic curves basically a write-out if you’re trying to deploy anything that might be quantum resilient into the future. And then you start reaching for lattice things that generally might have something FHE-ish under the hood. You’re just not doing a full, you know, like fully homomorphic computation with a bunch of other fancy stuff. But under the hood, that’s, you know, if you’re trying to do anything with homomorphic commitments and doing anything with that, like that’s secretly fully, you know, Uh, homomorphic reductions underneath, underneath it, and I expect more of those to show up.

Mark: Um, yeah, it’s also worth mentioning it’s not purely a quantum, pre-quantum thing, right? So a lot of FHE applications actually don’t particularly care about the quantum security aspect of things. It’s like, even in these kind of relatively simple settings, lattice-based things tend to be very fast.

Deirdre: Oh yeah, that too. Yeah, yeah, yeah.

Mark: I mean, they’re the only real cryptography we have that I’ve seen some people describe this, you know, quasi-linear time where, you know, the, the, the compute kind of almost scales linearly with just the size of the things you’re operating on. Yeah, it’s not common.

Deirdre: And like, you could make an argument that in terms of trying to find quantum-resistant, you know, replacements for the stuff that’s like the boring crypto that’s deployed a lot all over the place, like key agreement or the equivalent of key agreement and signatures, that’s kind of why they win is because they’re very fast and they’re quantum-resistant. Um, and they generally are small enough, uh, to fit in a lot of places. And a lot of the other, uh, problem— other cryptographic problem lineages just don’t seem to fit for one reason or another. Um, but yeah, there’s other problems that like there just isn’t— it isn’t even equivalent, like the fully homomorphic stuff.

Thomas: Like when you, when you, when you put quantum into that mix there, it’s kind of obvious why it’s so attractive right now. But like there’s There’s a— I don’t know the answer to this question, but there’s a reason that we ended up using curves and not nTrue back in the ’90s, right? Like, and part of it is that we didn’t care about quantum then, but like, I mean, so if it’s in the ’90s, so you’ve got like an almost 10-year head start.

Mark: Yeah, so nTrue was mid-‘90s, so it was a little bit later. It had some patent encumbrances. I think, what’s it called, elliptic curves did as well, but the entropy ones would have been earlier. Sorry, not earlier. There would have been— the patents would expire later in the future, I should say. I think, how to say, it probably also didn’t help that the entropy-based signatures were broken pretty quickly.

Deirdre: Yeah.

Mark: So I think they were broken before 2000, so that would make And true encryption looked a lot more suspect these days. It seems mostly fine, but there have been non-trivial attacks against NTRU that are not possible against RLWE. So there are some concerns to have against NTRU, but it hasn’t impacted the public protocol feed parameter chain.

David: Sure.

Thomas: Like, also, the vibe I have is that, like, just LWE has, like, a clear kind of theoretical basis for it. Like, LWE is a cleaner abstraction.

Deirdre: Right?

Thomas: I’m more— I think I’m more just like, there’s, there’s sure, like, we had reasons to trust curves more than we had, you know, and true or whatever, like, that now happened to be considered lattice. But like, there’s practical reasons, I assume, right? Like, nobody was thinking this, like, no one was thinking this carefully. I was there in 1998. Yeah.

Mark: So the main things that I would say for practical reasons, or at least why lattices are more appealing now, Lattices, there are a bunch of, you know, this matrix-vector arithmetic, or rephrasing in terms of polynomials. So they, with vectorized multipliers and vectorized adders, they kind of take advantage of that vectorization very well. That probably wasn’t as relevant in the ’90s. Lattices are bigger, so that’s, you know, a clear downside. And yeah, like those are the big downsides that I know have— sorry, that I know. Like I don’t know how fast lattices are compared to elliptic curves if you remove AVX instructions.

Deirdre: Oh, they’re faster. They’re, at least the, the, the Kyber LWE stuff, you don’t even need speedup. Like maybe, maybe you would speed up your hash function, but that’s independent of the, of the lattice.

Mark: Is this on, is this on architectures? Like, look, lattices auto-vectorize relatively straightforwardly. In many settings as well. So this is ensuring no AVX instructions.

Deirdre: Yeah, like even, yeah, even naive implementations with no vectorization, um, are very fast. Um, and you might have to do some tricks, uh, maybe in like 128 versus 512, uh, for, sorry, for like if you do Kyber 512 versus, uh, say P256 or something like that, or x25519. The x25519 might go faster than you, um, but you’ve had, uh, some good, uh, optimization tricks, uh, added on to that for a while. Um, it’s not— it’s not difficult to do a very fast naive non-vectorized assembly or intrinsics, uh, uh, LWE Kyber.

David: Sure.

Thomas: And we’re also— we’re fully Curve committed before Curve type— before 25519 happens. We’re already like, the P-Curve’s won, like Yeah. One other relevant point though.

Mark: I don’t remember the initial parameter sizes from NTRU, but so there’s— NTRU wasn’t initially phrased as a lattice-based cryptosystem, but quickly it was determined you could reduce it to a lattice problem and then attack the lattice problem. Algorithms for attacking lattice problems did have substantial advances between 2000 and maybe 2015, 2018, somewhere around there. So The security story for NTRU, like, probably didn’t look that great as those advances were happening. I don’t know. Again, I don’t know what parameters they initially chose, but if they chose parameters aggressively enough, they probably would have been broken, even if current parameters are probably fine.

Deirdre: I mean, yeah, I’m seeing some sample params. Yeah, go ahead.

David: Timing just doesn’t work out. The NIST curves were being standardized in like ‘98, ‘99, and you have NTRU coming out in like ‘96, right? That’s just not going to fucking happen. Like on that timeline, no matter how good it was, to say nothing of the fact that we couldn’t do signatures with it. Like, and a little bit because we tried signatures and they broke at the time too.

Thomas: So which again, I could do a full hour just on attacks on naive Schnorr LW signatures or lattice signatures because those attacks are really neat. So I’m going to short circuit this a little bit and just say Simplified and true prime. So SN True P versus original and true, where are we?

Mark: So I, so how to say this, I’m SN True P, I would describe the following way, but I, I haven’t looked at the original and true scheme as much. So SN True P is roughly the following. And what I’m saying here, this story also was replicated in the, like, the LWE land. Like, roughly there are 3 ways to build lattice-based KEMs. You kind of start with your pseudorandom component. It could be the NTRU assumption, it could be LWE assumption. That pseudorandom component kind of has this secret part. It’s not good for anything public key. The initial thing people did, at least in LWEs, you would take this randomized subset sum of it, and then the random coefficients from the subset sum, you would have that be another secret, and then this kind of is roughly the 2 secrets, sort of. So this you might call leftover hash lemma-based construction, because for its security you need to appeal to something called the leftover hash lemma. The other thing that you can do, at least in LW land, I don’t know if this works for Andrew, is instead of doing this randomized subset sum that needs these leftover hash lemma type constructions, which the downside for them they obtain this stronger form of security. They obtain kind of a statistical indistinguishability of— they don’t obtain that form of security, I should say. But applying this step to kind of make this randomized sum look uniform again, that this requires— this single part of the reduction is statistically secure. So the parameters chosen for it are maybe a little bit larger than you might want without impacting positively your total end security that you get. So instead of doing that, you can actually do this other second application of the LWE assumption to get something that uses slightly smaller parameters. Both of these, they create this kind of random pad that’s agreed to up to these low-order errors, and you can add messages to it, do a one-time pad type thing. The final thing you could do is you could just say, hey, I just wanna build a KEM. I don’t actually care about messages. So you could have this random pad and you could just apply some shared function to it that will agree on a key. So this type of third thing, this is closest to what sNTRU-P does. Although from NTRU, you can also build directly public key encryption, so you could do these other constructions as well, at least the variant of the leftover hash lemma thing, I think. So there initially were these LWE-based things that looked closer to sNTRU-P that didn’t have this explicit message and followed this paradigm. But they ended up not being as popular in the NIST scheme, as I’m sorry, in the NIST competition. I think New Hope initially was of this form, but they changed it. And I don’t think any finalists ended up being of this form. For LWE in particular, it’s hard to make the resulting KEM CCA secure. For NTRU, it ends up being easier to do. So you can get SNTRU-P CCA secure based off of kind of taking this NTRU assumption and then What’s it called? I think, I’m assuming they don’t do this leftover hash format type thing, but you don’t include this message, you apply this decoding stuff to get the shared quantity and then to get CCA security because it’s, there isn’t any, it has a straighter, more straightforward path to CCA security.

Thomas: So like the subtext of that is kind of like, obviously if you’re a nerd, right, is that like in the IETF and in NIST and all that, there is basically a drama between module-LWEE and Kyber and sNTP, right? Like sNTP was implemented in SSH originally, uh, you know, New Hope, which is RLWEE, I guess, was, uh, you know, browsers before that. But there’s like, there’s key implementations of all these things. And then like module-LWEE is like the standard now, right? And s-entropy is like, I don’t know, I don’t know what you would call it, like, but it’s the, it’s the other system that people think about or advocate for. And so like, like the big debate, especially among people who, you know, don’t do this professionally, is like, is, are we taking a huge risk flyer on using module LWE as opposed to using something like simplified NTRU prime?

Mark: I’m biased being a fully homomorphic encryption person. NTRU is not secure in fully homomorphic encryption anymore. It is for these TFHE few-type schemes, but in 2017 there was a non-trivial attack that applies only to NTRU that breaks it in every parameter regime I care about. So maybe it’s more conservative, but that’s only from a certain definition of the word conservative. In applications that I care about, I can no longer use NTRU even though it has appealing computational properties, ‘cause it’s explicitly insecure.

Deirdre: So, but, uh, but non-FHE for, for just regular public encryption?

Mark: Like, well, the thing is, non-FHE, this attack did not get down further, right?

Thomas: Okay.

Mark: But it’s like, it’s this type of thing where it’s like, let’s say McEliece. People like McEliece. I mean, people like McEliece. Some people advocate for McEliece, right? And one of the justifications people give is that it showed up, you know, in 1978 and it’s been secure ever since. But in the last few years, it’s not been true. There’ve been this series of papers that have said, hey, there’s maybe this additional structure in McEliece that can be exploited. And it’s, uh, I’m not sure the current status of the papers, but at least the abstracts are getting pretty concerning, right? So whenever there’s this like additional structure showing up, it’s something that gets a little bit concerning. Arguably this happened for NTRU in 2017 with these additional attacks on FHE. It also arguably did happen for RLWE with these attacks, these quantum attacks on the sig figs.

Deirdre: Scheme, right?

Mark: Or on this adjacent assumption on kind of ideal SVP, but not the rank 2 version that you would need to break RLWE.

David: Right.

Mark: So there are like these things where it’s like, whenever I see one of these kind of non-trivial attacks on something adjacent, it’s like, well, can it move over? You know, is it something to be worried about? So I would be a little bit worried about RLWE and a little bit worried about NTRU for both of those reasons.

Thomas: So I mean, that’s also like, that’s literally, that’s literally the logic of safe curves, right? It’s like, here are adjacent attacks on specific curve structures that only matter in specific regimes, ergo never use these curves, right? And it’s like, it seems like that’s essentially the same argument here.

Deirdre: It’s like, yeah, so it’s, I mean, it is in this, in the year of our Lord 2026, but are, Mark, are you trying to like hint towards Yeah, I don’t know if I want to use those assumptions anymore because what if they keep moving? What if those attacks keep getting better?

Mark: It’s mostly that. Well, it’s in my day-to-day job, I just explicitly can’t use NTRU. Right.

Deirdre: Okay.

Mark: Right. And it’s that if I— a lot of this is kind of vibes-based in the sense that if you look at the threshold—

Deirdre: A lot of cryptography is vibes-based, honestly.

David: Yeah.

Mark: But if you look at the threshold for where we currently think it’s safe to use NTRU versus not NTRU, I think it’s if you have this ciphertext modulus q, I think of its q being roughly less than 1 over 100 n to the 3.2 something, or maybe it’s some arbitrary number. And arbitrary numbers appear plenty of places. The best lattice attacks have arbitrary numbers in the exponent. So it’s not like arbitrary numbers should totally disqualify a scheme from being used. But then also it’s like, I would feel more confident if there was some clean number and being like, oh, the attacks can’t go below that. Yeah, it’s this clean number.

Deirdre: So, okay.

David: I want to just compare and contrast a little bit back with elliptic curves, just in terms of like timelines and analysis. Like you have Kobletz and Miller being like, let’s do elliptic curve Diffie-Hellman in ‘87.

Deirdre: 1985. I always thought it was ‘85.

David: ‘85 when they wrote the paper, ‘87 when it was published.

Mark: Right.

David: And then NIST standardizes that in ‘99, 2000, meaning there was some sort of lead-up to that. Now, we’re much, much better nowadays at writing cryptographic standards than we were then, despite the best efforts of NIAF. And, but like, if you go back and you look at like, what were all the problems with like cryptography in the 2000s and 2010s, they were by and large not with the primitives of that era. They were like, these standards all are written poorly and like some of these protocols were dumb or like the way in which we chained AES together was a bad way to chain AES. But like primitives more or less held and you like look at, you know, P-256 like we’re still using today. It’s not quantum secure, but, you know, that takes 10 to 15 years to get standardized and then another 10 years for adoption. You look at, you know, lattice-based cryptography starting in the ’90s, 10 years later, looking at RingLWE, and 20 fucking years after that is where we’re at now. Right? Like, I don’t, I’m not a primitives person. I’m not picking parameters for these things. My job in the last basically decade plus has been to listen to people who do work on primitives, then figure out how to use them in the real world. And if they’re being used correctly. And the answer is people have been like looking at this stuff for longer than elliptic curves, like at the time that they were deployed. These are, these are a safer thing to move to. Um, and like if you are, um, you know, familiar with like Diffie-Hellman and, and, and, um, cyclic group based like cryptography, like I encourage you to go to like your preferred AI chatbot and say, I understand Diffie-Hellman, explain to me enough like algebra to understand Kyber, it will do it very good.

Mark: I did it earlier today.

Thomas: Literally, this is literally what David did before this episode.

David: I did it like earlier today because like, again, actually understanding like all the details of the crypto systems is like not relevant for day-to-day use a lot of the time.

Thomas: Yeah, I’m just waiting for the IETF post where they say David Adrian, who just learned how Kyber worked 5 minutes before shooting this episode, because it turns out that like part of this is like evaluating, you know, experts on various serious things than making decisions.

David: And like, that, that’s the way it goes. And I think we’re actually at like a very conservative point of using lattice cryptography. Like post-quantum cryptography.

Mark: Yeah, I think something, I think something that’s not appreciated often by people who are concerned about lattices, like I’ve seen a lot of arguments that I have a hard time following. Like people have mentioned Dual EC was bad, so we should be concerned about LMLKEM.

Deirdre: Everyone knew Dual EC was bad. But when they first suggested it—

Mark: but so this is true, you know, if, uh, the potential for backdoor was known. And then also, not only that, like, if default parameters weren’t published, I don’t know if DualCEC had any issues. I think the issue was both the potential for backdoor and default parameters being published that were the backdoor parameters. But even ignoring that, if for Lattices, very early on in the— I think it was in Lattice Cryptography: The Internet, there’s this section that says, hey, backdoors are bad. This particular component of the scheme could be a backdoor. We’re gonna throw away some efficiency to make sure that it can’t be leveraged. And every scheme since has always done this. Like, it’s, you know, lattice-based cryptographers also want to build secure systems and it shows up in the constructions. But not only that, like, there’s this, like, the concerns over the NSA and potentially backdooring or, you know, subverting cryptography with lattices, are a little bit confusing just because it seems like everyone else is moving over to Lattices too. So Europe, for the most part, has also chosen lattice-based schemes, not always the same schemes. The BSI, so the German InfoSec government group, have chosen FrodoKEM, I think. The Chinese are not, they have not yet announced what schemes they’re gonna be moving over to. They’re rather early in their process. I think a couple of weeks ago they had the final submission period for their schemes closed down. But the comments that you can see from certain Chinese cryptographers make it seem like they’re gonna be going for lattice-based schemes. They’re gonna be lattice-based schemes with Chinese characteristics, which for Chinese lattice-based schemes, there’s, there was a NIST submission, LAC, which is maybe good to look at. It was doing something roughly Kyber-like, except it chose a very small modulus, 8 bits instead of 14 bits. And it tried to argue that by doing some error correction argument, you could get things to work. It got broken. So the issue for why it got broken is somewhat technical, but roughly the Chinese response to it appears to be that we’re not going to do LAC again, it got broken. Instead, we’re going to switch to an unstructured lattice-based thing, maybe because they’re worried about the algebraic structure, but also because the algebraic structure is specifically what made this error correction component of LAC break. So another way to fix that is just use a larger modulus like Kyber does. So It’s, it might be that either one, it’s hard to tell.

Thomas: But like in the BSI case, and I guess in the Chinese case, if they do unstructured lattices, right?

Mark: Like if you’re using ProtoChem, there really is an argument there that they wouldn’t use ProtoChem exactly. I think they’ve—

Thomas: right, what is it?

Mark: I think it’s S-Cloud Plus. It’s really like, it’s more like a ProtoChem version of this black scheme, which had some roughly— how to just describe it. So in lattice-based schemes, you have this error, And when you decrypt, you get the message plus the error back and you have to remove the error. Almost every scheme, you just round off the low-order bits. That’s where the error was, you’re fine. You could say, hey, handling errors, that’s like what error correcting codes do, or that’s what these types of things do. I can do something fancier to be able to tolerate more error and then choose smaller parameters. This is roughly what LAC did and it is roughly what SCLAW+ does versus FERDECAIN. Okay, so it’s a little bit different.

Thomas: But like, if you collapse it down to just like the German case, right? Like the, the, the, like the Fortikam decision there really is more conservative than the Kyber thing.

Mark: So it depends on what you mean by conservative, ‘cause it’s like, if, if I wanted to make AES more conservative, would I design a new block cipher or would I say AES with 1,000 rounds?

David: Right.

Mark: Well, the new block cipher, I mean, it, it might be good, but AES with 1,000 rounds, you know, AES would have to be really weak before 1,000 rounds is broken. Right. So conservative usually in cryptography means within a certain efficiency budget, right? So for FrodoKEM, is it more conservative or is doing Kyber but doing Kyber with modular rank 15 more conservative? I mean, it’s hard for me to say, you know, you, if you’re saying downside for FrodoKEM is the large ciphertext and I have this large ciphertext budget for conservative, being conservative, is it better to use an LWU-based scheme versus MLW?

Deirdre: I just don’t know. Yeah.

Thomas: Oh, that’s good. That’s a really good way of framing it. That makes sense.

David: Yeah.

Deirdre: Yeah.

David: And I will say, if you are a country and you are trying to get me to care about your cryptographic standard, you need to have at least twice the GDP of California for me to start reading your standard. We’re just going to set that as the bar. Looking at you, Germany.

Deirdre: Also, I wanted to— I wanted to also shout out South Korea that also did a PQ competition and they also selected lattice-based. Uh, KEMs and signatures, I think. I think there was Smaug and, um, another one. Um, but they’re slightly different. They have slightly other assumptions, but it was kind of like looking at what, uh, came out of the NIST competition and we’re like, oh, we can make some tweaks to some of these things and learn some stuff. Uh, we’ll, we’ll see. We’ll see if they get implemented and deployed in anywhere.

Mark: Yeah, it’s There are many different choices that you can make with lattices. I mean, even in this competition, like the final 3 lattice schemes, you really could have chosen most of them and gotten something mildly different and probably fine. But it does seem like essentially every country I’ve seen that runs a standardization, or at least every appreciably large country that runs a standardization, is kind of converging on lattice-based things. And this, I’m sure this has some downsides. If lattices end up being weak, you know, that’s bad for everyone. But it also like for this kind of argument that the NSA is trying to standardize weak Cryptography, it’s like, okay, well, why is China going along with it? You know, why is it’s it makes it a little bit more confusing of an argument.

Thomas: Right? Although the the freaky argument online, or the the freak argument online, is just that like lattices are fine, modules are the problem.

Mark: Yeah, but in that case, if if the NSA is saying, hey, China is doing unstructured lattices and we’re going to do modules, it seems like they’re intentionally doing bad things in like that. Geopolitical fight, you know.

Deirdre: Um, I’d be remiss to not forget about, uh, Falcon, uh, the future FN-DSA, which we’re totally gonna get a draft standard for any day now out of the Department of Commerce. Um, do you have anything to comment on these, uh, floating point-based lattice schemes?

Mark: I, I, I’m uncomfortable with it. I don’t know, like, it’s, it’s really small signatures.

David: That’s great.

Mark: I’m sure some people will do it right. I, it feels like something that’s very easy to get wrong, uh, but maybe I’m pessimistic.

Deirdre: Um, you’re not, you’re not the only one that’s, uh, just feeling a little about, uh, implementing Falcon securely.

David: Um, floating point numbers aren’t real. They can’t hurt you.

Deirdre: I mean, they can hurt me and secure implementations of my cryptographic software, so Wait, how do you even handle constant-time Falcon with subnormal?

David: So it was just DOA. There is maybe one person in the world that understands how to handle constant-time floating points, and it’s not clear if anyone else understands what they’re saying or will be able to duplicate that.

Deirdre: Yep, uh, yep, exactly that. You literally clone like One person. Stick them in your mouth.

Thomas: Okay, so what have we learned today? I’ve learned that Oded Regev, who is the godfather of all lattice cryptography, is now a computational biologist. Yeah, he saw this coming and exited the field.

Mark: Yeah, I have no clue why he switched over. And it’s not purely computational biology. He actually writes mathematical lattices papers as well. That like he had a paper that got into the Annals of Mathematics recently. So it’s like, you know, one of the best math journals in the world. So he still writes lattice papers and he still does quantum papers and computational biology and it’s a ton of stuff.

David: He’s just excluded us, the terrible group of people. Like, I don’t want to be at these NIST things.

Thomas: Yeah, my son is a grad student and an aspiring computational biologist.

David: So this is—

Thomas: I don’t know, it gives me— it gives me a thing to talk about with my son. So you, you’ve healed my family.

Mark: It’s fun to hear.

Deirdre: I’ve learned that you really, really need to get a quantum algorithmist to build your cryptography because that’s gonna stand the test of at least 20 years where other people fail. Um, and you just have to catch them before they turn into a computational biologist.

David: I’ve had a couple hours ago.

Thomas: So I learned you should definitely ask chat.

David: Cyberworks. So, you know, we’re all learning something today.

Thomas: I also, I think everybody should go on ChatGPT and just ask it to spell out how an attack on a naive LWE Schnorr signature works. Oh yeah, it’s a neat attack. It’s a neat, like just the blueprint or the schematic of that attack is pretty neat.

Deirdre: Well, we want to talk a little bit more about that in a second. I want to give a shout out to Alfred Menezes. Who is, you know, one of the OGs of elliptic curve cryptography, has been cranking out a whole series of lectures free on YouTube on his YouTube channel. We’ll put the link in the, in the notes on post-quantum cryptography, on a whole bunch of cryptography, free and available. It’s amazing and it’s pretty cool. So if you’d want to learn how Kyber works and how a lot of these crypto, last crypto schemes work, Um, that’s a good place to learn if you don’t want to turn to your local large language model to do it. Um, cool. Anything else?

Mark: It’s also worth mentioning, uh, so Menzies, uh, Armen Menzies, his, uh, the paper showing that regabs reduction, um, is not highly non-tight.

Deirdre: Yeah.

Mark: So could never really be possibly useful for setting parameters. It was one of his papers.

Deirdre: I didn’t know that. Oh my gosh.

Mark: It was one of his Another Look papers.

Deirdre: Oh my goodness, I have to read that one now. All right, um, is there anything else, Mark, that you wanted to, to bring up before, before we wrap?

Mark: I don’t think so. It’s— yeah, like lattices, like, uh, people seem very concerned that they might break in surprising ways, and I can’t unfortunately guarantee anything about the future in any context. But if you want to see a lot of examples of lattices breaking in surprising ways you can look 20 or 30 years ago because there were many very funny ones.

Deirdre: Yeah. So yeah, that’s a good place to do it.

David: Okay. It is a little funny that when we were an audio-only podcast, we did a very visual discussion of lattices. And now that we are a video podcast, we did an entirely audio discussion of lattices where some visuals probably would have helped a lot.

Deirdre: Yeah.

Mark: Sorry about that.

David: That’s not your fault.

Deirdre: You know, you were, you were, you were doing a great job with the, with the linear algebra, actually. And I mean, I understand. Yes.

Thomas: The rotations.

Deirdre: Exactly.

Thomas: This is the most fun that Deirdre has had on one of these episodes where we weren’t just talking about isogenies.

Deirdre: Yeah, well, oh, and that’s another one where you’re like, oh, you— lattices are not— don’t just show up in lattice-based cryptography, they show up in a bunch of cryptography, such as isogeny-based cryptography like ski sign.

David: We all know it worked out great.

Deirdre: It’s totally great. It’s fine. Nothing— don’t worry.

Mark: I mean, even like, this is something Trying to define what lattice-based cryptography is was something I was thinking about today because it’s like, well, cryptography like based on lattices, any elliptic curve over the complex numbers is a lattice. Yes. Or rank 2 lattice. So it’s like, is elliptic curve cryptography lattice-based cryptography? No, that’s very stupid, but it’s complicated terminology.

Thomas: This is why you can’t look anything up on Wikipedia because everything on Wikipedia is written that generally.

Deirdre: Yeah.

Thomas: You’re the problem.

Deirdre: All right.

Mark: I think— for the record, I, I would, if anybody has a good definition of lattice-based cryptography, I’d be very interested in hearing it because I’ve been trying to think through it and I keep running into these weird cases where it’s like, oh, you know, if Schnorr’s factoring algorithm worked out, would RSA be lattice-based because the best attacks are lattice attacks? You know, are elliptic curves lattice-based because elliptic curves are lattices? So it’s, there’s gotta be some definition somewhere, but I haven’t found something. That makes sense to me. Yeah.

Deirdre: Besides it being like this socially defined research area, you might need to write that blog post.

Mark: Cool.

Deirdre: Thank you. Thank you, Mark. Security Cryptography Whatever is a side project from Deirdre Connolly, Thomas Ptacek, and David Adrian. You can find the podcast online at SCWPod and the hosts online at DurhamCrestlum, @TQBF, and @DAdrian. He’s got the new handle. You can buy merch online at merch.securitycryptographywhatever.com. If you like the pod, give us a 5-star review wherever you rate your favorite podcasts. Thanks again to Teleport, who is sponsoring our event in Las Vegas between Black Hat and DEF CON. There are links on our website about trying to find us in the liminal space between Black Hat and DEFCON in Vegas this year in a couple of weeks. Thank you for listening. All right, let’s hit the button.

Thomas: That was awesome. Deirdre: Okay. Teleport. Teleport ad read. SCW Pod is sponsored by Teleport.

David: You should probably introduce us first.

Deirdre: Wait — oh, we’re doing the ad read during the podcast?

David: Yes.

Deirdre: Got it. Okay.

David: And then we’re going to talk about Teleport, who’s sponsoring our live event — well, our happy hour. I’m just going to talk about it now. We’re doing a happy hour again in Vegas, in the liminal space between Black Hat and DEF CON, like we have done every year for the past three years, and it is once again, like last year, sponsored by Teleport. If you don’t know what Teleport is, you probably don’t have SSH. We’re very happy that they’re sponsoring, and we can attest that Thomas is a Teleport user.

Thomas: We use Teleport everywhere at Fly. We love Teleport very much. If you’re SOC 2, it is a very, very good way to get a lot of business processes all tucked under a recorded SSH dealy. Teleport is great. Use Teleport for everything.

Deirdre: Awesome.

David: I’d like to say this is Security Cryptography Whatever, and my name is David.

Deirdre: I’m Deirdre.

David: And today we’re talking about lattice cryptography on this very professional podcast, with our special guest, Mark Schultz-Wu. Mark, how are you?

Mark: Hi. Yeah, I’m Mark. Thanks for having me.

Deirdre: Thanks for being here. This is lattices redux, because on one of our very first episodes we talked to Chris Peikert about lattices, which was great. He also tried to show us a bunch of slides, so we ended up talking through what our audio-only listeners were supposed to be seeing — a depiction of dots on a field with vectors, that kind of thing. So this is another chance to get into lattices and try to understand the area of lattices and post-quantum cryptography.

And you were posting on the internet recently some very, very useful history of where we started with lattice cryptography, what got broken, and how we got to things like Kyber, Dilithium, and some of the fancier things you’ve done research on. So we’d basically just like to have you talk through what you began posting elsewhere — the history of over 30, maybe 40 years of lattice cryptography.

Mark: It’s worth clarifying up front: I am a lattice cryptographer. I graduated in 2024, I think, and I worked with Daniele Micciancio. I was working on fully homomorphic encryption. I do have some background in lattice-based KEMs, but my publications — with the exception of one, on lattice-based public key encryption — were more on the fully homomorphic encryption side.

Deirdre: Got it. And that’s some of the fancier stuff. Especially if you’re trying to do a post-quantum solution to anything slightly fancier than public key encryption or signatures, sometimes you may be tempted to reach for the fully homomorphic solution, because it seems to solve your problems — but it might do it in a way that’s computationally costly, or large.

Mark: Computation and bandwidth. In general, the fancier the lattice things get, the bigger you have to make one of the parameters, the modulus, and then you also have to increase the dimension as well. So you can think about two parameters that counteract each other and keep getting bigger and bigger, and then everything gets big. And that’s how you get FHE papers that talk about twenty-gigabyte keys. It’s not the biggest keys, it’s not the smallest keys — if you’re optimizing for size, maybe you get down to three gigs or whatever — but it’s very far from the public key thing.

Deirdre: Gosh. And I want to get back to that. Let’s start at the simple beginnings and then get over there, because then we can talk about why some of these instances of lattice problems feel a little bit riskier. Occasionally a paper will show up and say, oh, anything with parameters that are slightly this far apart — which is bigger than what they are for Dilithium and Kyber, basically, or anything more complicated than that, that’s FHE-like — gets scary. Anyway. Thomas.

Thomas: I mean, I have a specific thing here, right? Which is that, as always, I’m just trying to reinforce things I say on Hacker News. A claim I make kind of regularly — which I shouldn’t be making, because I don’t know what I’m talking about — is that lattice cryptography and elliptic curve cryptography are of… they’re not literally comparable vintage, I think, but they were both live ideas in the 1990s, right? I like to say that there’s an alternate universe where lattices win over curves.

Mark: It depends on the particular application. The NTRU cryptosystems, both of them, were introduced in the mid-‘90s, and the NTRU cryptosystems that we see these days are very similar to what was around in the ’90s. I don’t want to say exactly the same, but at least for NTRU encryption there are a lot of similarities.

NTRU signatures from the ’90s got completely broken. Lattice-based signatures had a very rough going until — the first secure lattice-based signature was in 2008, which is rather late. The way I like to describe how late it is: fully homomorphic encryption was in 2009. So we didn’t get signatures before fully homomorphic encryption, but it was remarkably close, which is kind of wild to think about. You would think FHE is a much harder problem. Lattice-based signatures are very well understood at this point, but it took a lot longer to get there because of some additional complexities that show up with lattices for signatures in particular.

Thomas: So, because of post-quantum cryptography, there’s an attitude that lattice cryptography is moon math, whiz-bang stuff, right? And one of my things is just pushing back on that notion — that we don’t have a good understanding of what lattice cryptography is. Another thing I like to point out is the gap in time between NTRU and LWE, or NTRU and NewHope or something like that, versus the P curves and Curve25519, right?

Mark: NewHope is a great example here. NewHope was in Chrome a decade ago. It was in experimental releases of Chrome — you had to opt in. This was a decade ago. The scheme has had no substantial cryptanalysis in the last decade, no substantial improvements to cryptanalysis in the last decade. When I say a decade, I’m rounding up a little bit.

I think the most recent substantial improvement to lattice-based attacks was in 2018. When I say substantial improvement here, it’s worth mentioning that lattice-based attacks usually separate into two components. There’s one which is phrasing the problem as a lattice, and the other is solving the lattice problem. When I say the substantial improvements thing here, I mean the second part, solving the lattice problem. There have been some iterations on improving the phrasing thing as a lattice problem — if you’re familiar with the MATZOV attack, this is kind of in that first bucket.

One difficult thing with lattice-based cryptography, which I was actually struggling with a bit today — I was asking some people and getting not that great of responses — is that it’s really kind of a socially defined field, in a certain sense.

Deirdre: What do you mean?

Mark: You might say, “Okay, lattice-based cryptography, what does that mean?” A very easy answer would be, well, it’s cryptography based on lattices. Unfortunately, this isn’t true at all. As an example, in the NTRU paper — the first NTRU preprint — the term “lattice” appears never. Any cryptographer these days would call NTRU a lattice-based scheme. If you published a paper on NTRU, it would get put in the lattices track. And it was described as a ring-based cryptosystem initially.

Deirdre: I mean, okay, I get that.

Thomas: It reduces to lattices, or it can be rewritten as a lattice.

Mark: But this is also not a satisfying way to define what lattice-based schemes are. One reason for that is that elliptic curve-based schemes don’t reduce to elliptic curves. They reduce to Pollard rho on a generic group, right? So maybe you call them group-based crypto, or you call them Pollard rho crypto. I don’t know. We don’t tend to define problems based on what they reduce to. I mean, factoring, you sort of do — but also, you can break RSA without breaking factoring, by breaking modular pth polynomial roots. You do not need to break factoring to break RSA. So naming’s kind of all over the place.

In general, lattice-based schemes do get broken by lattice-based attacks, and I’m pretty sure that’s how the naming for NTRU got decided. It was ring-based, and then there was a lattice attack on it, and now it’s lattice-based.

But if we’re going based off of schemes that are broken by lattice-based attacks, the first one was actually in 1978, with the knapsack-based cryptosystems that Shamir famously broke. So maybe these knapsack cryptosystems are lattice-based. I would personally argue they are. My advisor had some papers in the early 2000s on knapsack-based cryptosystems, and he’s a lattice-based cryptographer. So there’s a sense in which lattice-based cryptography is the cryptography that lattice-based cryptographers do, and often involves reducing problems to solving computational problems on lattices.

Thomas: Other than NTRU — check me on this — the schemes that we’re talking about when we think about lattice cryptography are remarkably similar, right? They’re all based on basically the same LWE problem.

Mark: Yes and no. The popular ones these days, I’d say there are two big counterexamples to this, or maybe three.

As an example, one thing that you might say is that lattices are the only way we can get FHE. That’s sort of true if you define lattices in the right way. In particular, there’s this problem called the approximate greatest common divisor problem that was popular in the early 2010s. It kind of looks more like a number theoretic problem, something closer to RSA, but it also kind of looks like a lattice problem if you do lattices a lot, and we can get fully homomorphic encryption from it.

Antoine Joux also has this cryptosystem he called the Mersenne prime cryptosystem — I think it was somewhere around 2015 — that also kind of looks like a lattice-based cryptosystem, and also doesn’t. It’s not LWE, it’s not NTRU, it’s its own thing.

More recently, there are these lattice isometry problem type cryptosystems. It has “lattice” in the name, so maybe it’s lattice-based, but also the first part of any paper on these is always, “Here’s how we rewrite everything in terms of quadratic forms, and now we’re going to do everything in terms of quadratic forms.” Mathematically, quadratic forms and lattices are kind of equivalent, so it’s still kind of lattice-based, but computationally quadratic forms end up being nicer for most cryptosystems.

That all being said, the predominant lattice assumptions are almost always the learning with errors problem, or an algebraically structured variant of it, or a variant with rounding — learning with rounding, that type of thing — or the NTRU problem.

There are even more esoteric things than what I’ve just mentioned. In fact, when we’re talking about lattice-based cryptography, these are kind of the boring ones. One of my favorite things is that there’s this line of lattice-based papers which say, “We want to do insane stuff, we want to be crazy, and we want to be fast — let’s make a lattice-based PRF.”

Deirdre: Oh yeah.

Mark: I think they’re within a constant factor of AES when you have AES-NI hardware —

Deirdre: Really?

Mark: — or AVX2. Yeah. I can’t remember the precise constant factor. It might be something big, like five or whatever. But you can get very fast PRFs based off of very weird lattice assumptions. These are SPRING and LEAP. I don’t think anyone uses them for anything, but they use assumptions that are much farther from the boring standard lattice assumptions.

Deirdre: To cover that for our listeners: we touched on a little bit of NTRU originating in the ’90s. So let us describe specifically the NTRU assumptions — the things that are consistent with what was introduced in the ’90s — what they reduce to, in terms of the security definition and the construction reduction. And not the social construction of, well, if I can break it using a lattice attack, then…

Mark: The problem underlying NTRU — I’ve heard people call it the small decisional polynomial ratio problem. Essentially, you have two polynomials. Both are drawn from some small distribution, say some Gaussian type distribution, a discrete Gaussian, who knows. One of them you need to make sure is invertible — usually invertible mod some other prime than the prime you’re normally working with, but it’s invertible. Then you take the numerator one, the non-invertible one, and the invertible one, invert the invertible one, multiply them together, and it looks uniformly random.

That’s roughly the assumption underlying NTRU. There are some parameters to tweak — which distributions you use, and I mentioned that one of them might be invertible mod a different prime, and what different prime you choose. But that’s kind of NTRU. And what I mentioned here doesn’t really involve lattices at all. You can reduce it to a lattice problem and attack it that way, but the standard NTRU problem is about inverting polynomials and multiplying them together.

Deirdre: Okay. And then around 2005, Regev introduced — did he literally call it just LWE, like the cryptosystem, or…?

Mark: Learning with errors. So it’s the learning with errors problem, and it has a very interesting history itself. There’s this question you might ask: LWE is our leading candidate for a post-quantum assumption. You might wonder why that’s the case. And the best answer is unfortunately the most boring answer — very smart people have tried to break it and have failed.

But LWE in particular has a very funny story, in that the first person to introduce it was one of the very smart people who tried to break it and failed. LWE originates — Regev has this 2009 survey, I think, on the LWE problem that includes this point. Regev was a quantum algorithms person, and he was trying to create quantum algorithms for certain worst-case lattice problems, like the shortest vector problem.

Deirdre: Oh no, I didn’t even realize that. That’s neat. That’s very cool.

Mark: Yeah. More recently he’s kind of switched over into computational biology, but some of his more recent cryptographic work was actually a faster factoring algorithm — some optimizations to Shor. So he’s been a quantum guy for probably longer than twenty years.

He was initially looking at these worst-case problems on lattices, saying, “I want to try to find quantum algorithms for them.” And he was almost able to get it to work, if he knew how to solve one particular problem quantumly. If he could solve that one problem quantumly, he could fully solve these worst-case lattice problems, which were of independent interest at the time. The one problem he couldn’t solve was LWE.

So he said, “Okay, well, instead of saying I get this algorithm for SVP, I get a reduction from solving SVP quantumly to solving LWE.” And that’s what the paper ended up being. But LWE really came from a quantum algorithms guy not being able to solve a different problem, and that was the isolated subset he didn’t know how to do. And it’s stood up since then, so I guess it’s a decent way to find a problem.

Deirdre: Yeah. And now we have a whole lineage of problems, and narrow definitions of problems, that all nest down and reduce to different forms or slightly different variations on LWE. You have a learning with errors problem or game or whatever that reduces to SVP, the shortest vector problem — or, you know, you’ve got gap SVP, you’ve got —

Mark: Yeah. Well, it’s always gap SVP. This is something that’s important to get right, because SVP is an NP-hard problem, right? If I said that SVP reduces to solving LWE in the average case, that could imply that LWE is NP-hard, which is not true, and it’s actually not thought to be true.

So, gap SVP. Roughly, how it works: SVP is this problem where you have this high-dimensional point cloud. It’s a structured point cloud — it’s a lattice — and you’re wondering which part of this structured point cloud is the closest part to you. In low dimensions, it’s easy. You just do it by, I don’t know, looking at the thing. In high dimensions, from the curse of dimensionality, you might expect it to be much harder, and it is.

David: Do we have any intuition as to why that’s hard? I get that you sit down and it turns out no one’s come up with a good answer for it. But it just seems like it shouldn’t be hard, right?

Mark: For SVP itself, no gap, it’s just NP-hard. So what’s the intuition for why it’s hard? It’s an NP-hard problem. Why is any NP-hard problem hard? I don’t know. They all could be easy. But if any one of them was easy, all of them would be, and we think at least some of them are hard, right?

So there is a more satisfying reason for these lattice problems in particular. These lattice problems, or lattices in general, actually show up in useful scenarios. Coding theory wants to look at high-density arrangements of points that are noise tolerant, right? For standard coding theory, this is often noise tolerant in what people call the Hamming metric or pseudo-metric, where you get bit flip errors — a particular coordinate is either totally fine or totally corrupted.

Another error model you could imagine, instead of this digital error model, is an analog one, where you might have a little bit of noise in each coordinate. This is more accurate for radio communications, this type of stuff. So in this analog noise model, you might say, I still want to be able to code things to get this dense point cloud so I can get efficient radio communications, but I want to be able to efficiently decode things too. In this way, problems like SVP — more properly, the closest vector problem — have this direct application. And this was actually one of the reasons that at least some of the initial computational study of lattices was occurring: for these radio communications.

Deirdre: Yeah, I could see that.

Mark: Especially since random lattices, for a suitable definition of random, are known to have very good coding theoretic properties. It’s kind of like how random linear codes are near optimal. Random lattices, for many definitions of lattices, are near optimal for these coding theoretic properties. So if you could efficiently decode a random lattice, then you could get a very efficient analog communication system. For certain parameters, this is roughly what the LWE problem is — efficiently decoding a certain random lattice which likely has near optimal parameters for these coding theoretic purposes.

None of this is a satisfying reason to say why it’s hard. It’s sort of close to a problem that’s NP-hard, but it’s in a parameter regime where that problem is no longer NP-hard. The problem’s in Arthur-Merlin, I think. So if it was NP-hard, you would get some polynomial hierarchy collapse. Cryptography still isn’t from NP-hard problems in this setting. But then also you have this other community where, if they could solve these computational problems on lattices in this average-case setting, or in the worst-case setting, they could get these better constructions — and they haven’t been able to either.

Deirdre: One of the things that I sometimes hear referenced — and then if I talk to a lattice cryptographer, they give me a sort of “ehh” — is that we have a reduction to worst-case hardness of gap SVP for a lot of these LWE systems, which is not necessarily a complexity result that we have for some of our other cryptographic constructions that we deploy in the real world.

Mark: The answer I have to this is “ehh,” which is: famously, we do have this reduction. This is what Regev’s 2005 paper was for. It wasn’t initially a quantum reduction — it was made classical, I think, in 2009, and maybe in more generality since then. In the more efficient settings where we tend to use lattices, there have been more and more of these reductions.

The issue with these reductions — there are two big issues with them, actually. One is that if I wanted to use one of these reductions to build a cryptosystem, I would need to do two things. One, I would need to say, “Okay, now my hard problem is no longer LWE, it’s gap SVP, in the worst case.” That’s interesting, but I would now need to figure out what worst-case instances of gap SVP look like. I don’t think that’s really known.

So you might be able to do something. You could say, “Hey, to figure out how hard gap SVP is in the worst case, I’ll sample a bunch of stuff on average and see how it is in the average case.” That’s a strategy, but then you’re not using a worst-case anything.

The other, bigger issue is that the reduction is highly non-tight. I don’t know if people have worked out the parameters — I’ve seen a number of papers of people trying to work out the parameters, but there was a lot of debate over which papers did it right. There might have been some errors or whatever. I’ve seen estimates, I think, as high as maybe thirty or sixty thousand lattice dimension to get appreciable security.

Deirdre: And we’re nowhere near using that for things like Kyber or Dilithium.

Mark: No. Kyber’s dimension is like 512 to 1024. The sixty thousand dimension does actually show up sometimes in the fully homomorphic setting, but even then they try to get away from that if they can. It’s more like, if you can’t optimize certain parameters, you kind of have to have things that big. The trend there is trying to get them smaller.

Deirdre: Okay. So basically we have a thing that could be a nice security lower bound, except we don’t know how to use it to actually give us real-world security parameters that are of any relation to that mathematical lower bound.

Mark: It’s these two things. One, it’s this non-tightness that you’re mentioning. But the other is that it’s not at all clear to me, or I think to other people, that it’s easier to worst-case cryptanalyze gap SVP than it is to average-case cryptanalyze LWE. Because at some point you need somebody to say, “I have a computer, I have these algorithms, I tried running them, it took a while, and this is my estimate for how much longer it would take for bigger parameters.” This kind of explicit work trying to extract concrete parameters from these abstract algorithms.

If someone could write down, this is what the worst-case gap SVP instance looks like, and this is how long it takes to solve, then we would have something very interesting. And also if everything was tight, I should say. But that work is also — I don’t know if anybody’s looked into it. It seems unclear how to characterize the worst-case gap SVP instances that you’d be reducing from.

Deirdre: Got it. Okay. So in the ’90s we had our very early social instances of lattice cryptography. In the ’90s we’ve got NTRU, which is still kind of floating around in some form. Since the ’90s we get the introduction of LWE, in the mid-aughts. And since then we’ve gotten these other flavors of LWE, including Ring LWE and Module LWE, and we’ve seen these unstructured lattices. One of the cryptosystems that uses that is FrodoKEM.

Mark: That’s just plain LWE.

Deirdre: Okay. All right. For some reason I didn’t clock that. I forgot.

Mark: So, essentially what happens is, an LWE instance can roughly be phrased as the following. You have this integer matrix, you have a secret, you multiply them together, and you add some error. It’s worth mentioning this error should also be kept secret, so you might think of it as a static secret and an ephemeral secret. But that’s the rough shape of it.

All the algebraic structure is saying is that this integer matrix — well, matrices take N squared parameters, and that can be a big number. So can we shrink that somehow? You could say, hey, instead of being this N squared matrix thing, I want this to be a matrix that is determined by one of its rows, and then maybe some simple transformation you apply to that row. I might want it to be some sort of Toeplitz matrix, these sorts of things. The algebraic structure is all a way of saying that this matrix, instead of being fully dense, is going to be one with some interior structure.

As an example, RLWE is usually done over a cyclotomic ring of power of two. This matrix ends up being what’s called negacyclic. You have the vector in a column, and then each time you move it over you cyclically permute it, except when you go off one end you introduce a minus sign. So there is this very concrete way to describe it.

The downside is that the very concrete way to describe it can hide some security concerns. I said you introduce a minus sign. That sounds like extra work. Why do that? Why not just avoid introducing a minus sign? Everything breaks. So that might sound like a very small issue you could make that would make everything break. In the fancier math thing, it ends up making a lot more sense. Roughly, you have a polynomial, and if you don’t introduce this minus sign, the polynomial has this degree-one factor, and you can hunt everything down to this degree-one factor to get a one-dimensional instance that’s very easy to break.

Thomas: So for people who aren’t in their happy place when they hear the term “cyclotomic field”: we’re starting with Coke Zero LWE, with what’s now called FrodoKEM, right?

Deirdre: Correct, yeah.

Thomas: And we’re going to structured lattices, where instead of a uniform random lattice or whatever, we have structure inside of that matrix, right? Why did we do cyclotomics there?

Mark: It’s a good question. You could do other forms of structure. In fact, there was this NIST submission, maybe it was called Titanium, that roughly did what’s called middle product LWE. It’s its own thing. There are more esoteric assumptions, but it essentially said that we get hardness if any of these very large set of structures is fine. So in some senses maybe it was more conservative, but also — remember all the downsides of Titanium. The middle product stuff’s a lot harder to work with.

But why do we use cyclotomics there? Roughly speaking, the initial thing that was introduced was these cyclic lattices. It’s the most obvious thing to do. They had precedents in coding theory. My advisor actually, I think in 2001 — not for LWE, but for a different problem, the short integer solution problem — said we can have this cyclic structure, we can get benefits from it. But then there were these papers that said, essentially, that the cyclic structure means that when you view things in terms of polynomials, you get this degree-one factor, and everything can break. So you have to split off that degree-one factor, and then you get these cyclotomics.

What cyclotomics are is: you take the polynomial X to the N minus one, and then you factor it, and you keep the highest degree piece, very roughly. This X to the N minus one, very roughly, is the generator of this cyclic transformation. So you start with the easiest thing possible, and then you keep the biggest component of it that’s secure.

Deirdre: And the primary motivation is to take a secure cryptosystem but make the things that you’re shuttling around on the wire smaller, while reducing to the same problem?

Mark: Well, it’s not exactly reducing to the same problem. The idea is that now you only have to pass around one row or column, so you get a big size win. But now you’re working over this structured family of instances. So there are these concerns: is this structure useful for attackers? Plausibly.

RLWE — so the Ring-SIS, the short integer solution version of this, was introduced in 2001. RLWE, I think, was roughly 2011. The structure has finally helped attackers, this February maybe. I think they got a times-four speedup, and it seems kind of limited to that. So there now finally appears to be a very small gain from the structure, but it has taken a while to materialize.

It is worth mentioning that for adjacent lattice problems, the structure can help. So I mentioned you have this matrix, and you have a single column, and you apply this transformation. You can think about having this one structured block in it. Kyber does something different. Roughly, it has smaller structured blocks — say, 256 by 256 structured blocks — and then it builds the block matrix out of that, and this is module LWE.

The reason why we often prefer module LWE versus ring LWE — and I say “often” because this is mostly for public key cryptography; in fully homomorphic encryption everyone uses RLWE — the reason for public key cryptography is that in 2016 there were some improved quantum attacks against these single block instances, not of ring learning with errors. So the attacks, I think to this day, don’t really say anything for the deployed schemes. But —

Thomas: Wait, wait, wait, wait, wait, wait, wait, wait, wait. Module LWE is just LWE with block matrices?

Mark: Roughly, yeah.

Thomas: Okay.

Mark: If you hear “module” —

Thomas: Module. Module. Yeah.

Mark: But it’s roughly just that you have block matrices, and they all share the same structure.

Thomas: It’s that thing where you look up “modules” on Wikipedia and get —

Mark: No, it’s impossible. Yeah.

Thomas: Right, but the actual thing that’s going on here is it’s just block matrices.

Mark: It’s block matrices, yeah. So it’s block matrices, and then instead of fully materializing that, you only ever materialize the single rows you need, and then you need an efficient way to multiply these block matrices by a vector, and that’s where NTT stuff can show up.

Thomas: This is my thing. This was my understanding — which is now devastated by the last fifteen minutes that you two have been talking. My understanding before, because I’m an idiot, was that all of the complexity in these systems, all of the structure that was being introduced, was about something like NTT. Was just about speeding up the multiplication.

Mark: Well, that also shows up. It’s not independent. Because if I just have this dense matrix and I have a vector and I want to multiply them, that’s N squared time, right? But if I have a structured matrix, and if it’s structured in the right way — say it’s an NTT matrix — and then I have a vector here, now I can do something N log N, right? So roughly speaking, it does both: we get the compactness, because you only need the single row or column, and we also get this NTT-friendly form, so we can get some computation speedups too.

Thomas: So module LWE has become, for reasons, very salient in discussions about risk in lattice systems. But I interrupted you to say, you know, “for fuck’s sake” about modules and block matrices, right as you were going to say, “We now prefer block matrices,” or, “We now prefer module LWE.” So I would like to hear more about the thing you were originally going to say.

Mark: Yeah. So what happened is, in 2016 there were quantum attacks, I think, against ideal SVP.

Deirdre: Yeah, that rings a bell.

Mark: I mentioned before that worst-case SVP reduces to LWE. So you might think, oh, these quantum attacks against SVP, that’s concerning for LWE. Well, not really, because the reduction goes in the wrong way. To solve LWE, you have to reduce to what’s called a rank-two instance — kind of a block structure with four squares instead of one, right? You have to reduce to a rank-two instance of ideal SVP, and the quantum attacks don’t help in that setting.

So in 2016, these quantum attacks showed up in a relevant but adjacent context. People were like, “Hey, it’s not that much worse to just use this block structure, and then we’re kind of farther away from the issue.” And things have been fine since then — but also for RLWE-based schemes, things have been fine as well. As I mentioned, fully homomorphic encryption still uses RLWE everywhere. It uses RLWE with insanely more speculative parameter sets. When I mentioned there was this times-four speedup from the algebraic structure that appeared, you get much bigger ones in the FHE setting. I think there was maybe a fifteen-bit speedup — I don’t remember, I’d have to check again. But that’s because FHE people do much, much more speculative things to try to get things to be more efficient.

Deirdre: And this leads into — there’s the boring crypto stuff, which is literally the primitives that are basically public key encryption that you twiddle with an FO transform and turn into something that looks like key exchange, but it’s not, it’s a KEM. And then your regular schmegular signatures, to give you unforgeability or whatever you want to do. But things that get more complicated than that have to go into settings that have a little bit more exotic assumptions.

Mark: I would actually say lattice-based signatures do tend to be a little bit harder than fully homomorphic encryption to get right.

Deirdre: Oh, okay.

Mark: It’s a very funny sentence, but —

Deirdre: Tell me why, because that notion wouldn’t have even entered my head.

Mark: There are roughly two families of lattice-based signatures. One of them I’m more familiar with. Roughly what they do is they say, okay, lattices look a little bit like Diffie-Hellman. If you think of it as A times S plus E, and you just ignore the error — A times S, it’s like a one-sided group, like Diffie-Hellman, right? So you can do Diffie-Hellman type things. In fact, Kyber and things like this can be thought of as a Diffie-Hellman type thing that adjusts for this noise being here.

If you’re doing Diffie-Hellman type things for encryption, you could say, hey, for signatures I also want to do standard things. So maybe I’ll do Schnorr signatures or something like that.

Deirdre: Oh.

Mark: A lot of people try to do this, and all of them break, because this noise ends up being much more devastating. In particular, I mentioned before that the noise you can think of as an ephemeral part of the secret. The noise is security sensitive. So lattice-based signatures, until they started to be done properly, would often leak this — attacks that would allow an attacker to recover part of the noise. And if you recover part of the noise, you can almost always break the scheme pretty easily.

Thomas: Can I just ask real quick what that attack looks like? Because this is one of the rare instances where I have a bit of an intuition for what that would be. I can see immediately why leaking any of the error bits in an LWE computation is bad — the whole reason why this system isn’t just Gaussian elimination is the error, right? So, obviously bad to leak it. But what does that attack look like?

Mark: I’m pretty sure they ended up being machine learning-ish type attacks, where the idea is that if done improperly, you get part of it. Lattices, as I mentioned, are these point clouds, and you might imagine for these points this initial block, and then everything is a translate of that, right? The inside of that initial block you might call the fundamental parallelepiped — or at least lattice-based cryptographers do. So the attacks roughly would say that we can identify leakage somewhere within this fundamental parallelepiped, and then maybe some sort of gradient descent-ish type attack on top of this, with enough signatures to recover the actual secret, and then from there you win. It’s something along these lines.

Thomas: But it’s much more interesting than the hidden number problem, then, right? It’s not like we have a bit of bias and then I can literally just do a BKZ or something like that.

Mark: I think there is this kind of averaging step you have to do. I don’t think you just create a lattice, and I think you do need many signature samples.

Deirdre: Oh, so you do need one key and then —

Mark: I don’t know if there are attacks with a single signature. It’s not a huge amount you need. I think there are papers I’ve seen that have been on the order of five hundred. But these are devastating attacks — you need to get this part right.

That’s why, if you look at stuff like Dilithium, Dilithium describes itself as Fiat-Shamir with aborts. Fiat-Shamir is part of creating the Schnorr signature. The aborts is to say that, hey, if we would leak part of this error, we try again until we don’t leak it.

Deirdre: Oh, that’s fascinating, that that’s where that comes from.

Thomas: Hold on, this is getting more — so what’s happening when we’re doing the Fiat-Shamir in the Schnorr signature that’s causing us to leak the error? Because I don’t do signature stuff.

Mark: I’m pretty sure it’s that the errors get too large. The rejection conditions in Dilithium are bounding the size of the error. I think there are two rejection conditions, actually, but there was this paper a couple years ago that said you only really need one of them, but that one is load-bearing. Although this wasn’t for Dilithium specifically, it was for Fiat-Shamir with aborts type schemes.

Thomas: Nyet. Nyet. That’s my contribution.

Deirdre: Okay. So in more exotic settings like FHE, why do you have to get more exotic, why are your parameters slightly different than the things that we might see in Kyber and Dilithium, and why are your assumptions more exotic as well?

Mark: There are a number of reasons. The first thing is, I said FHE always uses ring learning with errors, not module. The reason for this is because of something people often call seed compression, where an RLWE ciphertext has two components, A and B, and the A part is uniformly random. So you can just store a small seed there, and you can use an XOF to expand it. For module LWE, you pick up more of these components in the front, so you would need more of them — you could generate them all from a single seed. So in this setting where you can expand things from seeds, it doesn’t really matter.

The issue is that this expanding-from-seeds thing does not survive any homomorphic operations. Even something as simple as adding together two ciphertexts — well, now you have an XOF of seed one plus an XOF of seed two. You can’t find a seed that really expands to that target. So you now have to store the full two polynomials here, and in the module LWE setting you have to store even more. So for FHE, you end up taking this big bandwidth size hit if you end up using module LWE versus RLWE.

There are other more exotic things people do as well. And it’s worth mentioning, when I say “for FHE,” there are two broad classes of FHE schemes. There’s what’s often called the TFHE-based schemes, and then generally CKKS, BGV, BFV — they’re all tensor product multiplication schemes. For this first class, you get a lot more flexibility. You can do things much closer to public key type crypto. But the second class is the one that I’m describing, that has less flexibility.

In particular, for the second class, you get these weird assumptions about the error. In public key cryptography, the error vector you can choose to be from any distribution you like, as long as it’s not too concentrated. If it’s too concentrated, there are these attacks from 2011, the Arora-Ge attacks, that start being applicable and concerning. But even things like — often people do Gaussian type noise with standard deviation three. That’s not too small, right? Gaussians are a little bit hard to generate, especially if you need to have a masked implementation of the generator. So instead you can just sum up a bunch of bits. It’s a binomial random variable. If you center it, it looks kind of Gaussian, and it’s good enough for encryption.

The issue with this is that there’s this one component of FHE that’s very key, where a certain parameter scales with the sum of the absolute values of all these coefficients. So instead, FHE likes to have this noise be sparse ternary noise. They want to make it as small as possible, which is a much more aggressive assumption.

In particular, the error distribution and the secret distribution for LWE, they tend to be fine with anything. We have these proofs that as long as they have enough entropy — there’s this thing called entropic LWE. The secret distribution and error distribution can be the same, and then as long as the error distribution has enough entropy, things are mostly fine. But the worst-case to average-case reductions aren’t true in this setting. So even though we don’t use them for any choice of parameters, moving to settings where the worst-case to average-case reductions are no longer true is still often seen as something that’s very concerning.

Deirdre: Because you’re never quite sure how your parameters may break down, and at least you have that as a backstop kind of deal?

Mark: It’s not like that. It’s more that if you’re in a regime where the worst-case to average-case reductions hold, then you have this understanding that it’s hard for there to be atypical structure there that wouldn’t also help in gap SVP. It might help with much smaller gap SVP instances, but an algorithm here is concretely an algorithm there — with the caveat of this tightness being bad. But if you start falling outside of this worst-case to average-case setting, then there could start being non-trivial attacks that wouldn’t also imply an attack for gap SVP.

So in FHE, the secret distribution can often end up getting much weirder, with much more aggressive assumptions. I’ve seen papers that suggest Hamming weight 32 and Hamming weight 64 secret keys, which are very small numbers. Although I don’t think there have been attacks on these schemes.

There’s also the ciphertext modulus, which can get very large in FHE. For Kyber, the ciphertext modulus is fourteen bits. It’s relatively small. In FHE — at least for these tensor product-based schemes I was focusing on — each time you do a multiplication, you have to shave off fifty bits from your ciphertext modulus, very roughly. So if you have this complicated circuit you need to compute, say a bootstrapping circuit, then you might need to support eight-hundred-bit or fifteen-hundred-bit moduli. Things that are much larger than the fourteen bits that Kyber uses.

Deirdre: Yeah. And we need some big limb arithmetic, and all of this has to be prime?

Mark: No, it doesn’t have to be prime. One of the things about all of these LWE-based schemes is that the number theoretic structure of the moduli does not really matter at all.

Deirdre: Oh, good.

Mark: As an example, I think Kyber is prime, but it doesn’t have to be. Saber was another NIST finalist and it’s two to the thirty-two, right? So it doesn’t really matter. For FHE, they take a bunch of word-sized primes and multiply them together — so they do CRT-based things — but you could do plenty of other things. It doesn’t really matter.

Deirdre: Cool. Wow. Okay. So we’ve basically done a whole tour of the history of lattice-based cryptography, including some of the whiz-bang stuff that, depending on your field, you may see — FHE stuff, or things that use FHE constructions under the hood, such as blind —

Mark: The things that are being deployed practically are generally not full FHE. I think Apple’s caller ID uses homomorphisms of lattices. So it’s a very weak homomorphic lattice-based thing. And I think Google might have something as well, but I forget.

Deirdre: I wouldn’t be surprised. Those are the areas where I expect more things to trickle out, because things that we might have used blinded commitments for, or other things using elliptic curves, are basically right out if you’re trying to deploy anything that might be quantum resilient into the future. And then you start reaching for lattice things that generally might have something FHE-ish under the hood.

You’re just not doing a full, fully homomorphic computation with a bunch of other fancy stuff. But under the hood, if you’re trying to do anything with homomorphic commitments, that’s secretly homomorphic reductions underneath it, and I expect more of those to show up.

Mark: It’s also worth mentioning it’s not purely a quantum, pre-quantum thing. A lot of FHE applications actually don’t particularly care about the quantum security aspect of things. Even in these relatively simple settings, a lot of these things tend to be very fast. It’s the only real cryptography we have that I’ve seen some people describe as quasi-linear time, where the compute almost scales linearly with just the size of the things you’re operating on.

Deirdre: Yeah. And you could make an argument that, in terms of trying to find quantum-resistant replacements for the boring crypto that’s deployed all over the place — key agreement, or the equivalent of key agreement, and signatures — that’s kind of why they win. Because they’re very fast, and they’re quantum-resistant, and they generally are small enough to fit in a lot of places. And a lot of the other cryptographic problem lineages just don’t seem to fit for one reason or another. But there are other problems where there just isn’t an equivalent, like the fully homomorphic stuff.

Thomas: When you put quantum into that mix, it’s kind of obvious why it’s so attractive right now. But there’s a reason that we ended up using curves and not NTRU in the ’90s, right? I don’t know the answer to this question. Part of it is that we didn’t care about quantum then, but —

David: I mean, Koblitz and Miller was like late ’80s. Curves got almost a ten-year head start.

Mark: NTRU was mid-‘90s, so it was a little bit later. It had some patent encumbrances. Elliptic curves did as well, but the NTRU ones would have expired later in the future, I should say.

It probably also didn’t help that the NTRU-based signatures were broken pretty quickly. I think they were broken before 2000, so that would make NTRU encryption look a lot more suspect. It seems mostly fine, but there have been non-trivial attacks against NTRU that are not possible against RLWE. So there are some concerns to have about NTRU.

Thomas: Sure. Also, the vibe I have is that LWE has a clearer theoretical basis for it. LWE is a cleaner abstraction, right? We had reasons to trust curves more than we had for NTRU or whatever now happens to be considered lattice. But there are practical reasons, I assume, right? Because nobody was thinking this carefully. I was there in 1998.

Mark: Yeah, so the main things that I would say for practical reasons — or at least why lattices are more appealing now — lattices are a bunch of matrix-vector arithmetic, or rephrasing in terms of polynomials. So with vectorized multipliers and vectorized adders, they take advantage of vectorization very well. That probably wasn’t as relevant in the ’90s. Lattices are bigger, so that’s a clear downside. Those are the big downsides that I know of. I don’t know how fast lattices are compared to elliptic curves if you remove AVX instructions.

Deirdre: They’re faster. At least the Kyber LWE stuff — you don’t even need the speedup. Maybe you would speed up your hash function, but that’s independent of the lattice math.

Mark: On what architectures? Lattices auto-vectorize relatively straightforwardly in many settings as well. So this is assuming no AVX.

Deirdre: Yeah, even naive implementations with no vectorization are very fast. You might have to do some tricks. If you do Kyber-512 versus, say, P-256 or X25519 — the X25519 might go faster, but that’s had some good optimization tricks added onto it for a while. It’s not difficult to do a very fast, naive, non-vectorized, no-assembly, no-intrinsics LWE Kyber.

Thomas: Sure. And we were also fully curve-committed before Curve25519 happens. We’re already on the P curves.

Mark: I don’t remember the initial parameter sizes for NTRU. NTRU wasn’t initially phrased as a lattice-based cryptosystem, but quickly it was determined you could reduce it to a lattice problem and then attack the lattice problem. Algorithms for attacking lattice problems did have substantial advances between 2000 and maybe 2018, somewhere around there. So the security story for NTRU probably didn’t look that great as those advances were happening. I don’t know what parameters they initially chose, but if they chose parameters aggressively enough, they probably would have been broken, even if current parameters are probably fine.

Deirdre: I’m seeing some sample params. Yeah, go ahead.

David: The timing just doesn’t work out. When the NIST curves were being standardized in like ‘98, ‘99, and you have NTRU coming out in like ‘96 — that’s just not going to fucking happen on that timeline, no matter how good it was. To say nothing of the fact that we couldn’t do signatures with it. And elliptic curves were like the hottest thing in the world because of Wiles at the time, too.

Thomas: Which — again, I could do a full hour just on attacks on naive Schnorr lattice signatures, because those attacks are really neat. I’m going to short-circuit this a little bit and just say Streamlined NTRU Prime. So sNTRUp versus original NTRU. Where are we?

Mark: How to say this? I would describe sNTRUp the following way, but I haven’t looked at the original NTRU scheme as much. And what I’m saying here, this story also was replicated in LWE land.

Roughly, there are three ways to build lattice-based KEMs. You start with your pseudorandom component. It could be the NTRU assumption, it could be the LWE assumption. That pseudorandom component has this secret part. It’s not good for anything public key. The initial thing people did, at least in LWE, is you would take a randomized subset sum of it, and then the random coefficients from the subset sum, you would have that be another secret. And then this is roughly the two-secrets sort of thing. This you might call a leftover hash lemma-based construction, because for its security you need to appeal to something called the leftover hash lemma.

The other thing you can do — at least in LWE land, I don’t know if this works for NTRU — is, instead of doing this randomized subset sum that needs these leftover hash lemma type constructions, whose downside is that they don’t obtain this stronger form of security, statistical indistinguishability… but applying this step makes this randomized sum look uniform again. This single part of the reduction is statistically secure, so the parameters chosen for it are maybe a little bit larger than you might want, without positively impacting the total end security that you get. So instead of doing that, you can do this other second application of the LWE assumption, to get something that uses slightly smaller parameters.

Both of these create a random pad that’s agreed to, up to these lower-order errors, and you can add messages to it, do a one-time pad type thing. The final thing you could do is just say, “Hey, I just want to build a KEM. I don’t actually care about messages.” So you could have this random pad, and just apply some shared function to it that will agree on a key. This third thing is closest to what sNTRUp does.

Although from NTRU you can also build public key encryption directly, so you could do these other constructions as well — at least the variant of the leftover hash lemma thing, I think. There initially were these LWE-based things that looked closer to sNTRUp, that didn’t have this explicit message and followed this paradigm, but they ended up not being as popular in the NIST competition. I think NewHope initially was of this form, but they changed it, and I don’t think any finalists ended up being of this form. For LWE in particular, it’s hard to make the resulting KEM CCA secure. For NTRU, it ends up being easier to do. So you can get sNTRUp CCA secure based off of taking this NTRU assumption — I think they don’t do this leftover hash lemma type thing, and you don’t include this message. You apply this decoding stuff to get a shared quantity, and it has a more straightforward path to CCA security.

Thomas: So the subtext of that, obviously, if you’re a nerd, is that in the IETF and in NIST and all that, there’s basically a drama between module LWE and Kyber, and sNTRUp, right? sNTRUp was implemented in SSH originally; NewHope, which is RLWE I guess, was in browsers before that. There are key implementations of all these things, and then module LWE is the standard now, right? And sNTRUp is — I don’t know what you would call it, but it’s the other system that people think about or advocate for. And so the big debate, especially among people who don’t do this professionally, is: are we taking a huge risk flyer on using module LWE as opposed to using something like Streamlined NTRU Prime?

Mark: I’m biased, being a fully homomorphic encryption person. NTRU is not used in fully homomorphic encryption anymore. It is for these TFHE type schemes, but in 2017 there was a non-trivial attack that applies only to NTRU that breaks it in every parameter regime I care about. So maybe it’s more conservative, but that’s only from a certain definition of the word “conservative.” In applications I care about, I can no longer use NTRU, even though it has appealing computational properties. It’s explicitly insecure.

Deirdre: But non-FHE, for just regular public key encryption?

Mark: Well, the thing is, non-FHE, this attack did not get down further, right? But it’s this type of thing where — let’s say McEliece. People like McEliece. Some people advocate for McEliece, right? And one of the justifications people give is that it showed up in 1978 and it’s been secure ever since. But in the last few years, that’s not been true. There have been these series of papers that have said, “Hey, there’s maybe this structure in McEliece that can be exploited.” I’m not sure of the current status of the papers, but at least the abstracts are getting pretty concerning, right?

So whenever there’s additional structure showing up, it’s something that gets a little bit concerning. Arguably, this happened for NTRU in 2017 with these additional attacks on FHE. It also arguably did happen for RLWE with these quantum attacks on this adjacent assumption — ideal SVP, but not the rank-two version that you would need to break RLWE. So there are these things where, whenever I see one of these attacks on something adjacent, it’s like, well, can it move over? Is it something to be worried about? So I would be a little bit worried about RLWE and a little bit worried about NTRU, for both of those reasons.

Thomas: That’s literally the logic of SafeCurves, right? It’s like, here are adjacent attacks on specific curve structures that only matter in specific regimes, ergo never use these curves. It seems like that’s essentially the same argument here.

Deirdre: I mean, it is, in this the year of our Lord 2026. But Mark, are you trying to hint towards, “Yeah, I don’t know if I want to use those assumptions anymore, because what if they keep moving? What if those attacks keep getting better?”

Mark: Mostly that. Well, in my day-to-day job I just explicitly can’t use NTRU. And a lot of this is kind of vibes-based, in the sense that if you look at —

Deirdre: A lot of cryptography is vibes-based, honestly.

David: That’s why Claude’s so good at it.

Mark: — where we currently think it’s safe to use NTRU versus not NTRU: I think it’s if you have this ciphertext modulus Q, and it’s Q being roughly less than one over a hundred times N to the three point two something. Or maybe — it’s some number, and arbitrary numbers appear plenty of places. The best lattice attacks have arbitrary numbers in the exponent. So it’s not like arbitrary numbers should totally disqualify a scheme from being used. But then also, I would feel more confident if there was some clean number, and being like, “Oh, an attack can’t go below this clean number.”

David: I want to just compare and contrast a little bit back with elliptic curves, in terms of timelines. You have Koblitz and Miller being like, “Let’s do elliptic curve Diffie-Hellman,” in ‘87.

Deirdre: 1985. I always thought it was ‘85, but —

David: — when they wrote the paper, and ‘87 when it was published, right? And then NIST standardizes in ‘99, 2000, meaning there was some sort of lead-up to that.

Now, we’re much, much better nowadays at writing cryptographic standards than we were then, despite the best efforts of the NSA. But if you go back and look at what were all the problems with cryptography in the 2000s and 2010s, they were by and large not with the primitives of that era. They were: these standards are all written poorly, and some of these protocols were dumb, or the way in which we chained AES together was a bad way to chain AES. But the primitives more or less held. You look at P-256, which we’re still using today — it’s not quantum secure, but that takes ten to fifteen years to get standardized, and then another ten years for adoption. Then look at lattice-based cryptography starting in the ’90s, ten years later looking at Ring LWE, and twenty fucking years after that is where we’re at now, right?

I’m not a primitives person. I’m not picking parameters for these things. My job in the last basically decade plus has been to listen to people who work on primitives, then figure out how to use them in the real world and whether they’re being used correctly. And the answer is, people have been looking at this stuff for longer than they had been looking at elliptic curves at the time that elliptic curves were deployed. These are a safer thing to move to.

And if you are familiar with Diffie-Hellman and cyclic group-based cryptography, I encourage you to go to your preferred AI chatbot and say, “I understand Diffie-Hellman. Explain to me enough algebra to understand Kyber.” It will do it very well. I did it earlier today.

Thomas: Before this?

David: I did it earlier today, because, again, actually understanding all of the details of the cryptosystems is not relevant for day-to-day use a lot of the time.

Thomas: I’m just waiting for the IETF post where they say, “David Adrian, who just learned how this works five minutes before shooting this —”

David: Yes. Because it turns out that part of this is evaluating experts on various things and making decisions, and that’s the way it goes. And I think we’re actually at a very conservative point of using post-quantum cryptography. Post-quantum cryptography is a type of math. Lattice cryptography is a type of math.

Mark: Something that’s not appreciated often by people who are concerned about lattices — I’ve seen a lot of arguments that I have a hard time following. People have mentioned Dual EC was bad, so we should be concerned about ML-KEM.

Deirdre: We knew Dual EC was bad, though. When they first suggested it —

Mark: This is true. The potential for a backdoor was known, and then also, if default parameters weren’t published, I don’t know if Dual EC had any issues. I think the issue was both the potential for a backdoor and default parameters being published that were the backdoor parameters.

But even ignoring that: for lattices, very early on — I think it was in Lattice Cryptography for the Internet — there’s this section that says, “Hey, backdoors are bad. This particular component of the scheme could be a backdoor. We’re going to throw away some efficiency to make sure that it can’t be leveraged.” And every scheme since has always done this. Lattice-based cryptographers also want to build secure systems, and it shows up in the constructions.

And not only that, the concerns over the NSA potentially backdooring or subverting cryptography with lattices are a little bit confusing, just because it seems like everyone else is moving over to lattices too. Europe for the most part has also chosen lattice-based schemes. Not always the same schemes — the BSI, the German InfoSec government group, have chosen FrodoKEM, I think.

The Chinese have not yet announced what schemes they’re going to be moving over to. They’re rather early in their process. I think a couple of weeks ago they had the final submission period for their schemes close down. But the comments that you can see from certain Chinese cryptographers make it seem like they’re going to be going for lattice-based schemes. They’re going to be lattice-based schemes with Chinese characteristics.

For Chinese lattice-based schemes, there was a NIST submission, LAC, which is maybe good to look at. It was doing something roughly Kyber-like, except it chose a very small modulus — eight bits instead of fourteen bits — and it tried to argue that by doing some error correction argument, you could get things to work. It got broken. The reason why it got broken is somewhat technical, but roughly the Chinese response to it appears to be: we’re not going to do LAC again, it got broken; instead we’re going to switch to an unstructured lattice-based thing. Maybe because they’re worried about the algebraic structure, but also because the algebraic structure is specifically what made this error correction component of LAC break. Another way to fix that is just to use a larger modulus like Kyber does. So it might be either one — it’s hard to tell.

Thomas: But in the BSI case, and I guess in the Chinese case if they do unstructured lattices — if you’re using FrodoKEM, there really is an argument there that that’s more conservative.

Mark: FrodoKEM exactly, they have — what is it? I think it’s SCloud+. It’s really more like a FrodoKEM version of the LAC scheme. How would you describe this? In lattice-based schemes you have this error, and when you decrypt you get the message plus the error back, and you have to remove the error. In almost every scheme, you just round off the low-order bits. That’s where the error was. You’re fine. But you could say, “Hey, handling errors, that’s what error-correcting codes do. I can do something fancier to be able to tolerate more error, and then choose smaller parameters.” This is roughly what LAC did, and it is roughly what SCloud+ does, over FrodoKEM.

Thomas: Okay. But if you collapse it down to just the German case — the FrodoKEM decision there really is more conservative than the Kyber thing.

Mark: It depends on what you mean by conservative. If I wanted to make AES more conservative, would I design a new block cipher, or would I say AES with a thousand rounds, right? Well, the new block cipher might be good, but AES with a thousand rounds — AES would have to be really weak before a thousand rounds is broken, right? So “conservative” usually in cryptography means within a certain efficiency budget, right? So for FrodoKEM: is it more conservative, or is doing Kyber with module rank 15 more conservative? It’s not for me to say. If you’re saying the downside for FrodoKEM is the large ciphertext, and I have this large ciphertext budget for being conservative, is it better to use an LWE-based scheme versus module LWE? I just don’t know.

Thomas: Oh, that’s good. That’s a really good way of framing it. That makes sense.

David: And I will say: if you are a country and you are trying to get me to care about your cryptographic standard, you need to have at least twice the GDP of California for me to start reading your standard. We’re just going to set that as the bar. Looking at you, Germany.

Deirdre: I wanted to also shout out South Korea, which also did a post-quantum crypto competition, and they also selected lattice-based KEMs and signatures, I think. I think there was SMAUG and another one. They’re slightly different — they have slightly other assumptions — but it was kind of like looking at what came out of the NIST competition and saying, “Ooh, we can make some tweaks to some of these things and learn some stuff.” We’ll see if they get implemented and deployed anywhere.

Mark: There are many different choices that you can make with lattices. Even in this competition, of the final three lattice schemes, you really could have chosen most of them and gotten something mildly different and probably fine. But it does seem like essentially every country I’ve seen that runs a standardization — or at least every appreciably large country that runs a standardization — is converging on lattice-based things.

And I’m sure this has some downsides. If lattices end up being weak, that’s bad for everyone. But also, for this argument that the NSA is trying to standardize weak cryptography: okay, well, why is China going along with it? It makes it a little bit more confusing of an argument.

Thomas: Although the freak argument online is just that lattices are fine, modules are the problem.

Mark: Yeah, but in that case, if the NSA is saying, “Hey, China is doing unstructured lattices and we’re going to do modules,” it seems like they’re intentionally doing badly in that geopolitical fight, you know?

Deirdre: I’d be remiss not to bring up Falcon — the future FN-DSA — which we’re totally going to get a draft standard for any day now out of the Department of Commerce. Do you have anything to comment on these floating point-based schemes?

Mark: I’m uncomfortable with it. I don’t know. It’s really small signatures, that’s great. I’m sure some people will do it right. It feels like something that’s very easy to get wrong. But maybe I’m pessimistic.

Deirdre: You’re not the only one that’s feeling a little something about implementing Falcon securely.

David: Floating point numbers aren’t real. They can’t hurt you.

Deirdre: I mean, they can hurt me, in secure implementations of my cryptographic software.

Mark: Wait, how do you even handle constant-time Falcon with subnormals?

Deirdre: That’s a good question.

David: You don’t. It was just DOA. There is maybe one person in the world that understands how to handle constant-time floating point, and it’s not — nobody else understands what they’re saying, or will be able to duplicate it.

Deirdre: Yep. Exactly that. You literally clone one person and stick ‘em in your lab.

Thomas: So what have we learned today? I’ve learned that Oded Regev, who is the godfather of all lattice cryptography, is now a computational biologist. He saw this coming and exited the field.

Mark: I have no clue why he switched over. And it’s not purely computational biology. He actually writes mathematical lattices papers as well — he had a paper that got into the Annals of Mathematics recently, one of the best math journals in the world. So he still writes lattices papers, and he still does quantum papers, and computational biology.

David: That makes a lot of sense. He’s just excluded us, the terrible group of people. Like, I don’t want to be at these NIST things.

Thomas: My son is a grad student and an aspiring computational biologist, so this gives me a thing to talk about with my son. You’ve healed my family.

Deirdre: I’ve learned that you really, really need to get a quantum algorithmicist to build your cryptography, because that’s going to stand the test of at least twenty years where other people fail. And you just have to catch them before they turn into a computational biologist.

David: And a couple hours ago I learned how Kyber works. So, you know, we all learned something today.

Deirdre: Yay!

Thomas: I also think everybody should go on ChatGPT and just ask it to spell out an attack on a naive LWE Schnorr signature. Just the blueprint, or the schematic, of that attack is pretty neat.

Deirdre: Well, we want to talk a little bit more about that in a second. I want to give a shout-out to Alfred Menezes, who is one of the OGs of elliptic curve cryptography, and has been cranking out a whole series of lectures free on YouTube on his YouTube channel — we’ll put the link in the notes — on post-quantum cryptography, on a whole bunch of cryptography, free and available. It’s amazing, and it’s pretty cool. So if you want to learn how Kyber works and how a lot of these lattice crypto schemes work, that’s a good place to learn, if you don’t want to turn to your local large language model to do it. Cool. Anything else?

Mark: Also worth mentioning: Alfred Menezes — the paper showing that Regev’s reduction is highly non-tight, so it could never really possibly be useful for setting parameters, was one of his, with Koblitz.

Deirdre: I didn’t know that! Oh my gosh. I’m learning so many things. Oh my goodness. I have to read that one now. All right. Is there anything else, Mark, that you wanted to bring up before we wrap?

Mark: I don’t think so. People seem very concerned that lattices might break in surprising ways, and I can’t unfortunately guarantee anything about the future in any context. But if you want to see a lot of examples of lattices breaking in surprising ways, you can look twenty or thirty years ago, because there were many very funny ones.

Deirdre: Yeah. That’s a good place to do it. Okay.

David: It’s a little funny that when we were an audio-only podcast, we did a very visual discussion of lattices, and now that we are a video podcast, we did an entirely audio discussion of lattices, where some visuals probably would’ve helped a lot.

Deirdre: No, you were doing a great job with the linear algebra, actually.

Thomas: This is the most fun that Deirdre has had on one of these episodes where we weren’t just talking about isogenies.

Deirdre: Yeah. Well — and that’s another one, where you’re like, “Oh, lattices don’t just show up in lattice-based cryptography. They show up in a bunch of cryptography, such as isogeny-based cryptography, like SQIsign.”

Mark: This is something like trying to define what lattice-based cryptography is. It was something I was thinking about today, because it’s like, well, is cryptography based on lattices? Any elliptic curve over the complex numbers is a lattice — a rank-two lattice. Is elliptic curve cryptography lattice-based cryptography? No, that’s very stupid.

Thomas: This is why you can’t look anything up on Wikipedia, because everything on Wikipedia is written that generally. You’re the problem.

Mark: For the record, if anybody has a good definition of lattice-based cryptography, I’d be very interested in hearing it. I’ve been trying to think through it, and I keep running into these weird cases where it’s like: oh, if Schnorr’s factoring algorithm worked out, would RSA be lattice-based, because the best attacks are lattice attacks? Are elliptic curves lattice-based, because elliptic curves are lattices? There’s got to be some definition somewhere, but I haven’t found something that makes sense to me yet, besides it being this socially defined research area.

Deirdre: You might need to write that blog post. Cool. Thank you. Thank you, Mark.

Security Cryptography Whatever is a side project from Deirdre Connolly, Thomas Ptacek, and David Adrian. You can find the podcast online at scwpod, and the hosts online at @durumcrustulum, @tqbf, and @dadrian. He’s got the new handle.

You can buy merch online at https://merch.securitycryptographywhatever.com. If you like the pod, give us a five-star review wherever you rate your favorite podcast. Thanks again to Teleport, who is sponsoring our event in Las Vegas between Black Hat and DEF CON. There are links on our website about trying to find us in the liminal space between Black Hat and DEF CON in Vegas this year, in a couple of weeks.

Thank you for listening. All right, let’s hit the button.

Thomas: Awesome.

Trump’s Golden Post-Quantum EO(s)

Thu, 02 Jul 2026 00:00:00 +0000

The dear leader has actually bleated out some not-dumb executive orders (EOs) to accelerate adoption of post-quantum crypto for the US government! This looks to be in response to a flurry of advancements in quantum computing and quantum attack algorithms a few months ago. We cram legalize into our eyeballs— plus, ECDSA.fail!

Links:

The EO https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/
CNSA2 https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0FAQ.PDF
https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
https://www.ecdsa.fail/
https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/
https://blog.cloudflare.com/post-quantum-roadmap/
https://blog.google/innovation-and-ai/technology/research/neutral-atom-quantum-computers/
https://en.wikipedia.org/wiki/FedRAMP
https://www.whitehouse.gov/presidential-actions/2026/06/ushering-in-the-next-frontier-of-quantum-innovation/
https://blog.trailofbits.com/2026/04/17/we-beat-googles-zero-knowledge-proof-of-quantum-cryptanalysis/
https://scottaaronson.blog/?p=9861

David: Recording earlier because like, I don’t want to do cold opens anymore. I just want to have something from before we actually start talking to edit it because I hate copy pasting things in.

Deirdre: Okay.

David: For example, this.

Deirdre: Hello, welcome to Security Cryptography Whatever. I’m Deirdre.

David: I’m David. Thomas is on a plane or something like that. He’s either buying a bandsaw or on a plane or both. He has a bandsaw on a plane. It’s a whole thing. What do you say?

Deirdre: And I hope he doesn’t get arrested. Um, we have a special emergency pod where we’re hopping on to take advantage of the news that there is a new executive order about post-quantum cryptography specifically. It’s not just buried in like 100 pages of a Kyber EO, um, and the, the top line headline is the U.S. government is moving up its post-quantum migration from approximately 2035 to 2030 and 2031. Uh, so it is ordered, so it shall be done. Because Golden— because Trump signed it with the big pen. Um, and so this is our excuse to finally catch up on a bunch of news about quantum attacks and post-quantum cryptography and a whole bunch of other little thingies that have happened in basically the last 3 months that we just never really hopped on the pod and talked about, even though they happened. Um, David, what do you think?

David: Which had the EO on it because I hit this fun bug where if you set your window height at the exact right spot, the, the dropdown on the Trump White House site would just bounce up and down and up and down and up and down like a Jack Russell Terrier. Um, but as soon as I started streaming, it adjusted the window size and now you can’t see the funny bug. Anyway, great, great technology, bleeding edge cryptography here. Okay, so I figured let’s just go through the EO.

Deirdre: Sure. Um, the context for this EO, this executive order from our dear leader, President Trump. Also, we did not— we do not have a crystal ball. We have produced multiple episodes, and by we I mean David produced multiple episodes featuring, um, some, you know, fictional presidents. Yes, the AI Gamer presidents, who, including, including our dear leader, a fake version of our— of President Trump, talking about post-quantum cryptography and quantum cryptography and things like that. And we do— do not ask us for KALSHI bets. Do not ask us what the spreads should be for anything else. We, we were doing satire and unfortunately it became real. That seems to be a current risk of doing satire.

David: However, the official stance of this podcast is that insider trading makes markets more efficient.

Deirdre: Sure, sure, why not? Sure. Anyway, so the context is in, in March, um, there were some results for both improving quantum attacks against especially elliptic curve Diffie-Hellman, or elliptic curve, sorry, the elliptic curve discrete logarithm problem, um, and there were improvements, uh, in, uh, in different ways of producing a quantum computer, specifically about building quantum computers using neutral atoms. And basically, um, we’ve— we had multiple results that were kind of percolating amongst, you know, the, the Whisper network, uh, and then got published by Google, uh, predominantly. They put— I think they published both things, the, the neutral atom stuff and this, uh, this improved attack efficient, more efficient attack against, uh, the elliptic curve discrete logarithm problem. And they specifically were trying to be like, this is, uh, we think this will make attacking P-256, um, especially EC, the ECDSA signature scheme over P-256, uh, much easier. And then you put those things together, you— it’s much more efficient, uh, to get a, a cryptographically relevant quantum computer, and you get a much more efficient attack algorithm. And basically the projection of where you get a scary quantum computer that can run a scary, very fast for what we’ve had before, quantum attack algorithm, especially against elliptic curves, brought that reality, projected reality, a lot closer. And in response to that, Google and Cloudflare announced that they were gonna be moving their targeted, their target dates to be quantum fully migrated to quantum-resistant cryptography. Up to the end of 2029. And then I think a lot of people in the industry like really stood up and started paying attention because that’s moving up target dates that people have been working against up by at least 5 years. It was more 5 or 6 years.

David: Start of 2029 actually is what Google—.

Deirdre: Oh, did they say that? Oh gosh. Um, so, but that happened in March-ish, and we’ll have links to those in the, in the show notes. We— some people have been saying there might be a, another Kyber EO, executive order, or a cryptography EO or something like that. But like, you know, you never know what the fuck’s going on, uh, in, uh, our dear leader’s, uh, house. Uh, so this just showed up yesterday, and there’s some lovely video of, of Trump just talking, learning the phrase quantum cryptography for the very first time and uttering it. The result is Um, but it’s a lot of fun.

David: And pointing out that no one cares when, when Einstein— what year Einstein published some paper about quantum something or other, apparently.

Deirdre: So here it is. This is, uh, Securing the Nation Against Advanced Cryptographic Attacks. And yeah, there’s a— there’s several things in here actually, because I thought it was just about cryptography, and it’s not just about the, the cryptography, uh, of the, uh, the U.S. government.

David: Um, so for the sake of the like 8 readers that, um, take audio only, what we’ll do is we’ll read through, I think, most of this.

Deirdre: Okay.

David: And then pause and talk through it instead of relying on everybody to simply read the screen. Um, so section 1, the advent of large-scale quantum computers, particularly in the hands of adversaries, will pose a significant threat to widely used cryptographic security systems. Ongoing Kyber activity against our nation also presents the risk of adversaries collecting United States information now and decrypting it once the large-scale quantum computers are operational.

Deirdre: I agree.

David: So right off the bat, we have a reference to the store now, decrypt later threat, which we have talked on and on and on about. I mean, it’s still not clear, like, who this risk acts like in the grand scheme of risks. Where does this apply to you? But this is sort of the main risk of quantum computers now.

Deirdre: It is the live threat, if that is within your threat model.

David: Um, in light of these threats, the United States must take steps to strengthen cryptographic protection, protections for the nation’s sensitive data, critical infrastructure, and digital economy. Uh, it is the policy of the United States to safeguard national security and maintain technological leadership by responsibly and effectively executing the transition of federal information systems to the NIST-approved Federal Information Processing Standards, FIPS, for post-quantum cryptography, PQC, and to assist critical infrastructure owners and operators with their transitions. Um, so, um, unfortunately, unlike AI Gamer Obama, who said that he would become a Republican if Doge got rid FIPS. Um, well, we still have FIPS. Section 2 is just a bunch of definitions, so we’ll skip all of that.

Deirdre: Although the one thing that I will not skip is the term high-value asset, or HVA, um, which has a specific definition and an OMB memo, blah blah blah blah blah. And this is— and the, uh, another definition that follows, the term national security systems, or NSS. So Up until about recently, until this memo actually, the U.S. government has been targeting, um, FIPS standards that includes post-quantum cryptography, uh, to be rolled out and in use by any of these applied systems. So this is like any system that the U.S. government is using. This includes like the Department of Education to, you know, this freaking website that we’re looking at. I’m pretty sure this has to be served with NIST curves or something like that at the moment. Um, that’s all U.S. federal government, uh, from very boring stuff to less boring stuff. For national security systems like Department of Defense stuff or NSA stuff or top secret SCI, no foreign system stuff like that, they have their own suite of more constrained algorithms that are basically a subset of the FIS FIPS stuff, and they are using PQ only, no hybrid, except for, you know, if you’re doing IPsec or something like that, you’re doing some VPN stuff, they trust elliptic curves a little bit. Um, they just have a much more constrained set, and they have all of the parameter sets pegged to the most tippy-top parameter set possible. Um, those were all trying to get migrated by the end of 2035, although I think there were different targets for different systems for CNSA 2.0. They were trying to get some stuff migrated earlier.

David: For CNSA 2.0, it’s really vague, but it was kind of already closer to 2031 for most things. And there’s a statement that’s very vague about like new systems, new, new procurements should be like CNSA 2.0 compliant in starting in 2027, which like is just on one hand, just like not gonna happen at all. On the other hand, like, um, talking with the people that wrote that, what it really means is you better not be charging us an extra update for it.

Deirdre: Right.

David: Uh, okay.

Deirdre: Yeah.

David: So, um, they should be doing as much CNSA 2 things as are reasonable.

Deirdre: Yeah.

David: So for example, like you’re not gonna have, uh, um, an HTTPS certificate that’s CNSA 2 compliant for like a number of years.

Deirdre: Yeah. Bye. That’s publicly trusted. Yes.

David: That’s publicly trusted.

Deirdre: Yeah.

David: For private PKIs, you can do whatever you want. Starting—.

Deirdre: You can basically do it now, depending—.

David: In Chrome 150, which releases on June 30th. So 7 days from now.

Deirdre: That’s nice.

David: You’ll be—.

Deirdre: Breaking news. Breaking news on the podcast.

David: I don’t know that it’s breaking. It’s like on a public site describing Chrome releases.

Deirdre: This is a scoops. We’re doing scoops. Scoops. Who cares where the information came from? It’s an exclusive.

David: It’s been discussed on IETF threads by other implementers. Uh-huh. Breaking news.

Deirdre: One of the only other definitions in the section is the Cryptographic Module Validation Program, the CMVP program, which is part of getting FIPS certified. So if anyone has ever mentioned anything about being FIPS certified, This is the program that basically does it. It started with hardware and firmware implementations and then they just said also we’ll, we’ll certify software implementations of FIPS stuff in a module, in a module boundary. And it’s, you know, it’s a whole thing. And unfortunately it leads to kind of, you know, reading the tea leaves to try and predict what will be FIPS certifiable or not in the program, the lab that does the program. And a lot of that is wrong. But that’s what that is. And we’ll talk about that later.

David: There’s, there’s two types of FIPS certification actually. There’s the, well, there’s a bunch of types, but relevant to this, there’s, there’s the CMVP, the Cryptographic Module Validation Program, which is the really annoying one to get.

Deirdre: Yeah.

David: That a lot of things require. And then there is Cryptographic Algorithm Validation, CAVP.

Deirdre: True.

David: Yes. Which is more straightforward to get. ‘Cause CAVP is like, did you implement this algorithm correctly based on like some test vectors. Mm-hmm.

Deirdre: And CMVP is like, do you meet all of these arbitrary other like, um, requirements that make it very difficult to test in like, like how do you, like, everything has to be within a module boundary and it has to be started up a certain way.

David: And this is why it needs to be able to do a self-test with fixed random. So you have to build in like a backdoor to your system to prove that it operates correctly. Basically it’s a pain in the ass.

Deirdre: Yeah.

David: Um, and then you have to certify it on every, uh, uh, well, depending you, in theory, it, the certification only applies to specific environments. So for example, like Arch Linux 4.0 on a Chromebook.

Deirdre: Yeah.

David: Or like Debian in Google Cloud.

Deirdre: Yeah.

David: Um, and in practice what you do is you get some bullshit certified for some platform and then you convince your auditor that that’s what everything is.

Deirdre: Yep. But you still have to like juggle all of those like certs in case you, your compliance auditor is like, is your cert for this module on this platform is still up to date? And you have to keep it alive. And that’s a lot of juggling and, you know, bookkeeping for questionable amounts of additional security.

David: So, and then NIST will take like 6 to 18 months to actually issue your certificate once you pass the testing.

Deirdre: That too. Okay. Section 3, Coordinating the PQC Transition. The Director of OMB and the National Kyber Director, in consultation with the Assistant to the President of National Security Affairs and the Administrator of the Office of Electronic Government— I didn’t know that that was a thing— OMB shall lead the strategic coordination oversight of the national PQC migration policy and strategy set forth in this order, ensuring its alignment with broader cybersecurity goals. B, the Secretary of Commerce, Blutnick, through the Director of NIST and in consultation with the Director of National Security Agency, NSA, and the Secretary of Homeland Security. Is that still known? Do we have an acting secretary?

David: We— I don’t remember who it is, but it’s not known anymore.

Deirdre: I think we need—.

David: I think it’s an acting secretary at the moment, but they have to be approved. Yeah.

Deirdre: Oh gosh. Uh, through the Director of the Cybersecurity Infrastructure Security Agency, CISA, and the Department of Redundancy Department. Shall provide agencies on ongoing basis with comprehensive technical guidance on PQC implementation, including best practices, implementation, and risk management strategies.

David: Cool. Just what we needed, more guidance from CISA.

Deirdre: Section 4, Accelerating the PQC Transition. Within 30 days of the date of this order, which is yesterday, uh, June 22nd, each agency head shall identify its PQC migration lead and provide the name and contact details of the PQC migration lead to the Director of OMB and the National Kyber Director within 90 days. Yes.

David: Yeah. So this is like fairly standard stuff for like how a government, like the executive branch, tells agencies to do things. There’s like a similar, um, guidance around like doing inventory a while ago that’s like, yes, define a point person, and then that person has to submit a report to these other people that contains these things. Blah, blah, blah, blah, blah. And then you need to do this other thing by this other time. And then that all goes through the point person back to whoever, as deemed by the authority stated at the top, which in this case is like NSA plus Secretary of Commerce.

Deirdre: Yep. And we explored a lot of that when we talked about the, the big Kyber EO that came down just before the end of the Biden administration. And it’s like a lot of similar stuff.

David: Um, I think the big takeaway in this section is that like, we’ve included the HVAs, the high impact systems and national security systems. And given this like, timeline for both key establishment at the end of 2030 and then digital signatures by the end of 2031, which, you know, very nice that these have actually been split out because it’s much, much, much, much easier to do key establishment that it is to do signatures in most cases. And you can actually just like, doing key establishment is basically just update your OpenSSL. Mm-hmm. At this point.

Deirdre: And, or, you know, your Go, you like, you can upgrade Go, you can upgrade, uh, I think it’s in Java 25 or JDK 25, um, that you get it as well. Like a lot of the places where you just update, uh, and you are serving TLS, for example, Um, you will get your post-quantum FIPS interoperable, uh, key agreement and it just works. Uh, it’s not that easy if you’re using, uh, signatures and you need to share, uh, a public key or rotate keys or certs or have any sorts of roots of trust or anything like that.

David: Yeah. Fundamentally, like independent of any of the like struggles with size that we’ve discussed with PQC in the past, um, like you are going to have a new trust hier— like a PKI hierarchy for PQCE.

Deirdre: Yeah.

David: Which means that like, in some way you’re going to have to get a certificate from like something vaguely new. And like, even if that certificate is done in such a way that it looks like this looks like the old stuff to old things, like at some point your ACME client’s gonna have to either be pointed at a new endpoint or have that endpoint just like do some sort of, uh, you know, Indiana Jonesing to a new hierarchy when you’re not looking., um, uh, and actually have like certificates issued.

Deirdre: Yeah.

David: Which is just fundamentally like more work, hopefully marginally more work, and hopefully mostly handled, um, automatically still, but like not as straightforward as, oh, I’ve just updated my, my SSL/TLS implementation and now there’s a new cipher suite available and you just use that with new things.

Deirdre: And now—.

David: Because it involves a long-lived credential instead of just an ephemeral credential.

Deirdre: Yep. And not even like long-lived, but just like someone needs to trust it in some way. It needs to be sort of like, have some sort of like, where does this come from? Did like, is this real? Is this like not expired and things like that? Um, and we, and we haven’t even gotten an update to, uh, SSH or OpenSSH for, uh, keys, the actual keys that do the signing for you. We have gotten an update, uh, for the key agreement of your SSH session in OpenSSH. So that’s cool. But we still aren’t sure what SSH, uh, pub keys, PQ pub keys are gonna look like yet. Um, there’s still discussion going on about that. Um, yay. Um, but one, one of the huge things is like, okay, 2030 for key agreement, like that’s kind of on par, but the fact that they’re moving up signatures to be done by the end of 2031 is pretty big because we, that is a short runway for things that don’t have solved solutions ready to go yet. And it’s like aggressive. So that, that was a big thing that caught my eye.

David: Yeah. I mean, Chrome’s expecting to be able to accept, um, post-quantum, uh, Merkle tree certificate CAs in 2027. Um, cool. Uh, but the first round of those will not have key strengths suitable for CNSA 2. Oh, you’re right. Um, but it will be, yeah, they’ll get there eventually, but they’ll at least be PQC. And this actually doesn’t say anything about key strength.

Deirdre: Correct. I think it’s just, it needs to be FIPS, which means if it supports ML-DSA 44, you’re good. And I think a lot of people will be perfectly well suited to use ML-DSA 44.

David: Um, Yeah, it’s really complicated to decide what’s, um, like a national security system. If you talk to most people from like NSA, they’ll be like, oh, you know, that’s like the DOD servers running in like a DOD data center or whatever, like on a private DOD network. And it’s like, yes, that’s definitely true. Um, but like what, like more and more of the government uses like public clouds and SaaS. And then you have the question of like, is your cloud console considered a national security system?

Deirdre: Yeah.

David: You are deploying using that cloud console to deploy, uh, you know, a national security system on some cloud.

Deirdre: Yeah.

David: Um, and then like now you have like a whole host of basically publicly accessible websites that become in scope for rules that were written to be for like, uh, basically a DoD network. Which is where all of this gets complicated.

Deirdre: It’s like, do I really need— does like AWS have to serve me, uh, an mldsA87 cert and everything in that chain and an MLKEM1024, uh, key exchange just to like, you know, load up the console? Like, I don’t— maybe, I don’t know, I don’t work for them.

David: MLKEM1024 is like not that bad in the grand scheme of things compared to— whereas like mldsA87 is It’s just like, you really gonna send me 35 kilobytes of certs? Like, come on.

Deirdre: Yeah. Like, when you’re sort of thinking about like, well, yes, if you are like doing X-keystore crap, like the stuff that Snowden leaked, you know, sure. I give me the fat, you know, NIST Level 5 certs and like, sure, gimme ML-KEM 1024. But when you’re just like, well, you know, if you’re trying to twiddle something in the like, defense cloud that is being served by, you know, AWS, like, do you need it there too? And like, it, the answer might be yes. And then you’re just like, oh, goddammit. Like, to just serve me a website, a regular website, um, you need to support this stuff is like, oh boy. Okay.

David: The struggle is if you can’t split your domain, like split your users by domain, because it’s easy to make one domain that only uses the high strength stuff and another domain that uses like the normal strength stuff. To be clear, the normal strength stuff is like strong enough to survive like a Dyson sphere built around the sun being used to like brute force it. But, um, like if you say you’re on a search engine, if that somehow becomes in scope for a national security system, like you probably don’t actually want to pay, um, the cost of the cryptography for, you know, a few billion users.

Deirdre: Yeah. Um, all right. Well, the last rest of the section, advancing to Section 6.

David: Procurement, um, because I think everything else is more just like reporting details on timing and reporting. Yeah, Section 6 procurement is where it gets exciting.

Deirdre: Hold on, hold on, at the end of Section 5, uh, uh, um, Homeland Security shall release public guidance regarding cryptographic bill of materials and they should enable the automated assessment of assets utilized by hardware software element. I’m like Great, we’re just gonna keep doing that. We’re gonna keep doing C-bombs. Okay, sure, we’re moving the timelines up super aggressively, but first we gotta get that bill of materials. Oh, okay, sure, maybe you gotta do that.

David: I don’t remember this for sure, but I feel like some of the like S-bomb stuff got revoked by an earlier Trump EO, but maybe—.

Deirdre: Oh, that— yeah, that might have been in the Kyber EO, and he wrote like a few months after he came into office, he basically had a short one that was like, revoke all that except for this, this, this, and this. It might— that might have been it. But, uh, uh, 6.

David: So moving on to Section 6, procurement, Section B: Within 180 days of the date of this order, the Secretary of Commerce, through the Director of NIST, shall, to the extent appropriate and consistent with applicable law, revise the processes used by the Cryptographic Module Validation Program to accelerate validations of cryptographic modules. Um, now what does it mean to revise these processes? I don’t know. Um, I also, like, I’m gonna be pessimistic about this cuz I don’t really know how you fix these things. I think you just get rid of, like, in my opinion, we shouldn’t have CMVP at all. We should just have CAVP, if that. Really, we should just have the FIPS list of algorithms and say like, these are the ones that you have to use. And like, you don’t, you know, we, we expect that like software works correctly and like that’s part of, you know, the purchasing agreement is that like software works correctly. Right. Mm-hmm. If it doesn’t, it gets fixed. This is kind of how all software works, but somehow it becomes like just the cryptographic algorithm part and not the network part. It’s like, oh, well we have to do all this additional testing. It’s like, yeah, you should, you know, make sure that you’re procuring software that works for your use case and works well. But like, do we really need this like additional testing versus saying, you know, Yes, this, this software complies with the guidelines in the sense of it uses the algorithms that the NSA wants to use for the national security systems. It like meets the product requirements that are required to do the government thing. So I don’t know. I suspect that we will not get rid of CMVP. And as a result, I don’t really know like how to improve CMVP very well. Yeah. I haven’t specifically taken something through CMVP. I’ve, you know, worked with teams that I’ve had to make changes so that it can go through CMVP, but I’ve not been the point person to like, take something to a lab, get it tested, submit that to NIST, and so on.

Deirdre: I bet, I bet we know some people who do have opinions, but I am quite— the way this, this is written, I’m a little bit worried now because it’s like within 180 days, the revise the processes, like you have 6 months to revise the processes, not come up with a plan, give to go up the chain about how you’re going to revise the processes. Like, no, you’re going to change them.

David: So I’m, I mean, I think 6 months is more than enough time to change the processes, but like, you know, government, government, it’s, it’s also tough to do because like in practice, like at least for, for, uh, like CNSA too, a bunch of this also goes through NIAP where then like NIAP has a protection profile that is like in theory above and beyond just the CMVP. That’s like, oh, you know, you have this broader set of requirements and NIAP is supposed to check that all of that complies with those requirements. But in practice, like, NIAP just writes requirements that are impossible to comply with and, like, make no sense, and, like, combine requirements for clients and servers and then say that you have to follow all of them, but in ways that just don’t make sense. And so getting any, like, NIAP protection profile for a product, which again is also done through, like, a third party, so you, like, take it to a tester, like, Booze Allen Hamilton, and then they like, well, that’s a thing, and send it to NIAP. Um, and then just like, nope, nobody, like the testers don’t understand the product. NIAP doesn’t understand TLS. And then everybody’s just trying to get it through. But also like you’re, it’s just a bunch of people like bullshitting and lying each other to each other until eventually you get the stamp. And then what is used in practice is not at all what was tested because the requirements were like literally impossible to comply with. Even though like the requirements from CNSA 2 are actually very straightforward.

Deirdre: Oh gosh. I keep forgetting about NIAM and yeah, I don’t, I’ve looked at it once and I’m just sort of like, okay, sure.

David: Yeah. Like the NIAM protection profiles don’t like correctly discern between like must offer something and must negotiate something when a client or a server, so it’ll be like, you TLS client, like you must offer You must use Extended Master Secret with TLS 1.2. And it’s like, well, if you’re like a web browser, like, you know, what, what happens if like the server, like we offer it in Chrome, but like not every server speaks that. I think most do, but like, are we just supposed to reject it? And then they’re like, oh, well you must use, you know, AES-256, cuz that’s what’s in CNSA2. It’s like, well, here’s the incantation you can put in to make it so you get AES-256 with Google. But like, if we just turn off AES-256 in like Chrome, for example, then you just can’t load most The internet.

Deirdre: Yep.

David: Because it’s all using AES-128.

Deirdre: Yep. Which is fine, by the way. Uh, I don’t know. There was a, a lovely blog post that went around recently because people were like, oh, so to be post-quantum, we need to go to AES-256. And it’s like, no, actually you don’t. And I guess people don’t, don’t know this. Basically Grover’s is not efficient against, uh, against thing, especially things like AES, but even hash functions. AES-128 is, is fine. You do not need to upgrade. The only reason you need to upgrade is if you need to be compliant with CNSA 2.0, and that’s just because they, they put all the parameter sets to 11, not because they actually are protecting against Grover’s attack. Anyway, sidebar.

David: Anyway, so my feedback is to just simply get rid of CMVP entirely.

Deirdre: Who knows? Like, we’ve already had Doge come, come through our government. You— who knows? Maybe that will actually happen. It’d be very, very interesting. Uh, anything else? Oh, uh, contractor vulnerability disclosure programs. Cool. That VDPs incorporate reports of cryptographic vulnerabilities including testing for lack of encryption, the use of non-FIPS approved algorithms. Cool, that’s neat. What’s FAR?

David: It was probably the Federal Acquisition Regulatory Council.

Deirdre: Oh, okay.

David: Uh, I think this is probably going to be a net negative. Um, well, I don’t know, like, what do they mean by, I guess it’s probably in the definitions up above, but like contractor, if contractor means like labs, like, I hope they don’t, aren’t like having the labs check for vulnerabilities. If they’re just saying like people that we’re buying cryptography from should have a vulnerability disclosure program, then like, sure.

Deirdre: Yeah, I guess that sounds good.

David: Everyone should have a vulnerability disclosure policy. Most people should not have a bug bounty. Yeah, that is my stance. Uh, and, uh, I think, and then Section 7 is the none of this is illegal section.

Deirdre: Hopefully the costs for the public issue of the source shall be borne by the Department of Commerce. Of course, poor, poor them. Poor Litnik. Cool. Yeah, so that’s, uh, that’s it. That’s, uh, that’s the EO. It’s very exciting.

David: Yeah. So I think takeaways for most people should just be to update your TLS server software or, um, which if you’re like using a VM, you can just like do now and you should be getting TLS Quantum Key Exchange out of the box, probably hybrid, um, 25519 with MLKEM768. That’s enabled by default in, yep. I believe like OpenSSL 3.5 and newer and boringSSL and all the other SSLs.

Deirdre: Yep.

David: If you’re using a, like, TLS load balancer from a cloud, it probably supports all of those now as well. And if not, it will very soon. And like, again, the step there will just be to like, roll your config to the new version, enable it, or just let it update itself depending on, you know, how you’re configured. And all of that should be pretty straightforward. And then for publicly accessible websites, like, you’re just gonna need to wait until the certificates are available.

Deirdre: Yeah.

David: And then you have just a certificate management problem, you know?

Deirdre: Yep. Uh, and you know, Modulo Chrome trusting, Modulo Chrome having a, a trust store beyond Merkle tree certs. Um, I’m pretty sure that a lot of publicly trusted CAs, um, either already have ML-DSA support, um, like operational, they just don’t have an ML-DSA root, uh, in other root stores, trust stores out in the world. It’s kind of a little bit of a chicken and an egg issue with them. Um, and this is regular schmegular ML-DSA certificates, not the fancy new, new gen Merkle tree certs.

David: Um, no, those are like not gonna end up being an option for publicly trusted sites. Like at this point, like all but like a lot of the browsers have signaled in various forums, not to speak on behalf of any of them. Um, yeah. That like the, because of the need for transparency for public PKIs, meaning like the full set of certificates is publicly disclosed.

Deirdre: Yeah.

David: Um, uh, the, if there was a, a non-Merkle tree certificate, which we haven’t really defined, but we’ve been talking around, but if there was an old style ButML DSA, like root store, that would require old style certificate transparency and that system would fall over, um, in a post-quantum world for a number of reasons.

Deirdre: And so in a post-quantum world, or you could just do something, a terrible bridge where you have your ML-DSA cert, but you have, uh, ECDSA, uh, transparency statements.

David: That would still fall over publicly in a sense, because like the full certificate contents are logged. And so if you like drastically increase the size of the certificate, the set of people that are currently basically running CT logs out of the goodness of their heart,, would probably not be super happy about, you know, um, these things that are just like basically a net negative to run suddenly, like doubling, quadrupling, 10x-ing in storage costs.

Deirdre: Yeah. I, I was thinking of literally all the SIGs and, and key public keys that you’re downloading. Yeah. Those would be smaller if you did a little bit of mix and match and relied on and just kind of, you know, crossed your fingers that the transparency benefits, uh, be given by ECDSA would give you a little bit longer. But you’re right, for the log operators, there still gets They’ll still get fucked.

David: Yeah, but there are definitely a number of companies that offer like private PKI ML-DSA products right now. Yeah, I think I’ve done it for a while. There are many HSMs that support it, although none of them have a CMVP yet, um, because NIST is just behind on, uh, on approving them. Yes, they have CAVPs but not CMVPs.

Deirdre: Was it the first, uh, validated implementation of ML-DSA was only like this year, 2026 or something like that, that finally got through. And it was in the pipeline for like 18 months or something like that.

David: It took so long. The final standard was released in like July of 2024.

Deirdre: Yeah, I think that’s correct. Yeah, or August, I forget.

David: Yeah, July or August.

Deirdre: Yeah, and it took that long. They, they had it ready to go and they, they shoved it in there and it took that long to get validated or whatever.

David: Yeah, it was an extremely minor change in the final standard from the last draft standard.

Deirdre: And so yeah, Yep. It just takes so long. So yeah, we’ll see if, uh, they literally just chuck CMVP out the window. That’s a way to update procedures or what they do, because this may be possibly the best opportunity to overhaul that program since it’s come into existence, I think. But, uh, we’ll see. We’ll see how that goes.

David: Earlier in the year, um, I saw this talk. And it was, it was kind of like the scene in The Big Short where Steve Carell’s character comes and meets the guy in Vegas who’s like on the other side of the trade, like selling stuff.

Deirdre: And they’re eating sushi.

David: Yeah. And they’re eating sushi. And Steve Carell’s getting angrier and angrier at this guy who’s basically just like taking money off the top of the trade and like fucking over his customers. But you’re just like, oh, like this person like actually exists. And for me earlier this year, I was at this talk and there was someone who was like, just giving this talk about how important it is that when you’re in a sys— system where like you need FIPS cryptography, you make sure that you’re like, actually using all of the FIPS stuff everywhere, because otherwise who knows what kind of cryptography you’re getting. And like, it’s not just enough to like get OpenSSL that lists FIPS, like other stuff might be used. And the only way to know that you have like high assurance cryptography is to like make sure you have the thing that actually got like FIPS verified. And I was like, oh shit, man. Like, I got bad news for you about like most products you’ve ever used, right? Like, not, not that like everyone’s out here doing fraud, but just like in practice, it’s not possible to get these validations, um, at a rate or reflective of every environment in the way that like all of this stuff is actually used. And that’s, that’s why I think like CAVP makes much more sense because it’s just like, let’s make sure we’re using the right algorithms. But like the chance of you actually being able to verify to the letter of the law of how you’re supposed to verify a cryptographic module is basically zero when it comes to actually distributing software.

Deirdre: And the argument of like, and even if you are able to do it, like the value to security, uh, is very debatable, um, about that procedure for actually like validation, um, is debatable.

David: And there’s a they’re supposed to have like a self-test of them as well, which requires like a hash of itself in it, basically. Yeah. Yeah. Yeah. Um, which then gets submitted in the cert. And so like your, your, your validation only applies to like the specific, like hash of your thing, technically. Um, but that is a problem of like, well, if it takes 18 fucking months to like get one of these things verified, like you’re gonna make changes underneath.

Deirdre: Yeah. Um, and so it’s also, uh, you can’t, you can’t change like a doc comment. You can’t like, there’s, well, depending on how you, in theory.

David: Yeah.

Deirdre: Well, that, that’s not technically basically, you know, FIPS approved.

David: Now, most of the downstream requirements that like you don’t need specifically to have that FIPS thing. So like FedRAMP, for example, now lets you update, like be like, as long as you are regularly getting your cryptographic module validated whenever you make a large change, then it’s fine for you to update it in between because like, you know, bug fixes are good and new features or whatever are good. But like at some point, like, like what are we doing here?

Deirdre: Yeah, I got, I totally forgot about FedRAMP. So this, this is going to impact FedRAMP, but it’s not specifically named in here.

David: So like, I guess there’s nothing specific, but yeah, well, that’s just going to be downstream of like FedRAMP says you need things that are like FIPS 140-3 validated. And then that now involves covering these other things. So I don’t think FedRAMP itself really needs to change.

Deirdre: Yeah.

David: Like, I don’t know, maybe they make a, post-quantum secure statement at some point, but it’ll kind of fall out of the FIPS validation. Oh, personally, I like it better when there aren’t a bunch of executive orders around, like my non-government job.

Deirdre: Yeah.

David: Yeah. I don’t know about your experience.

Deirdre: Yeah. I don’t, I, part of me is like, this could be good. And part of me is just like, what, what are we doing? I mean, I— yeah, I don’t know. We’ll see. Especially because it’s like high-impact systems, which, for example, those might be things like the IRS’s computers and the State Department systems that let it issue passports and things like that, and like help maintain consular security, stuff like that. Um, so important stuff, but definitely there’s going to be whole— a whole bunch of parts of the federal government that may not be PQ, um, even if everything in this EO is like, um, fulfilled all the way down to the, down to the letter. Um, we’ll see, we’ll see how it goes. I don’t hate it. I’m kind of amazed it does not say quantum cryptography in there.

David: Also, I heard someone, I heard someone references the quantum key distribution or anything like that, quantum randomness.

Deirdre: Thank God, like The Little Mercies, because there’s been chatter, more chatter about that, I think because there’s funding coming out of like the EU or something for EU-based businesses. And it’s just like, no, no, no, we don’t want none of that. I was having to— you—.

David: Is a great place to take vacation.

Deirdre: There’s nothing about—.

David: This is a great place to host a World Cup, apparently.

Deirdre: Um, Boston is a great place to host any Scotland matches. Um, I am sad that I was not spending as much time in Boston while, you know, every Scots person, Scottish person, um, that could ambulate made it to my hometown for a week. But, uh, I want them to come back. Now the English are over there and everyone’s like, boo, we want the Scottish back.

David: English historically haven’t had a great time in Boston.

Deirdre: No, it was— yeah. Um, I swear someone said that there was a mention of investment in quantum computing, but it’s definitely not in this EO. Did I miss another one? Or maybe, maybe Trump was saying the wrong things out of his mouth again.

David: So, um, there is about that as well.

Deirdre: Hold on, I’m pasting it in here. Yes, there was another one, another presidential action. Um, gosh, ushering in— I’m sharing— ushering in the next frontier of quantum innovation.

David: How long?

Deirdre: It’s not this one. This is on— it’s not that long either.

David: No, so there’s a second EO.

Deirdre: Yeah.

David: Um, oh God, two EOs in one show. I think that, that might be a bit much.

Deirdre: I’m scanning, scanning, scanning. Updating quantum strategy. Harnessing quantum computing for science. Secretary of War and a bunch of other secretaries shall ensure that capabilities, manufacturing infrastructure, and expertise are made available to support this QC effort.

David: Exploration.

Deirdre: Coordinate with the NASA administrator, the director of NSA.

David: Uh, to attempt to like keep track of the relative capabilities of different quantum computing systems in order to accurately assess the performance. That’s interesting because it’s really hard to assess relative capabilities of them cuz they all work different ways and basically none of them do anything useful until one day. One of them will do many things useful.

Deirdre: All of a sudden they do a whole bunch of— a whole bunch of useful, uh, Secretary of Energy shall, uh, basically price out and scope out delivery for one QC. Cool. Um, develop a plan to encourage contributions to the effort from commercial quantum computing companies. Secretary of War, national security applications of quantum computing, establish a center for such a purpose.

David: Thought, thought, thought. I previously heard of NSA saying that they like to be approximately 7 years ahead in terms of the, like, general public in terms of cryptanalysis, which I know some people have taken to, well, that means they clearly have a quantum computer now. I think that’s a load of crap. There’s like no way. Yeah, that anyone has a quantum computer now. Um, like, we would— there would be downstream effects of that.

Deirdre: Yes, it’s, it’s sort of like when, um, all the nuclear scientists just stopped publishing for a while when, like, most of them were either working at the— at Los Alamos, uh, or, you know, some of them were working in Germany. Um, it’s just like the absence, uh, is a signal, and we we don’t have anything close to that, or, or the inverse of sort of like, um, we would see evidence, uh, even, even if it’s not direct evidence.

David: We would also need like technological advances that would probably see like effects of an industry that like don’t seem to have happened, like, you know, improvements in superconducting and things like that.

Deirdre: Yep.

David: Um, but speaking of building quantum computers, do you want— should we talk about ECDSA.fail?

Deirdre: Oh my goodness.

David: I love a good.fail domain.

Deirdre: Yeah. Um, yeah, that’s good before, uh, we, yeah, you get the gist of the rest of the CEO. They’re actually kind of like trying to tell people to do stuff regarding quantum computing, which is pretty cool. Um, we’ll see where that goes. Um, so we, we discussed how, um, there were published, uh, improvements, uh, to attacking Elliptic curve discrete logarithm problem, uh, with quantum attack algorithms, which are basically like iterations around Shor’s algorithm or improving parts of some of these like broad class attack algorithms. And specifically, the Google, uh, Google folks published a paper that claimed they had a quantum attack circuit for one of the, uh, slowest parts of, uh, running Shor’s algorithm to attack, uh, this discrete— elliptic curve discrete logarithm problem, which I think it was literally like the elliptic curve point operations itself, which is like funny because that’s the classical part. And it turns out running it on the quantum computer is actually kind of like the slow bottleneck of using Shor’s algorithm to attack the thing, to find that like the periodicity of your, you know, elliptic curve group or whatever it may be. Um, so they claim— they published a paper that claimed that they were able to do this in, you know, n million Toffoli— I think it was like a million and change Toffoli, um, gates, which is like a way to measure the circuit depth of the, uh, quantum circuit that you’re actually going to use. It’s kind of like measuring the number of multiplies or divides or whatever you might have in a certain attack algorithm or another, another algorithm on a classical computer. It’s just a way to kind of like measure. And then, um, I think they claimed that they needed like, you know, a 1024, some, some small number of logical qubits or whatever. Not— they didn’t, they didn’t require like 10 million or a million logical qubits to run this. It was some, some small number or something like that. Um, but they did not publish the circuit. They published a zero-knowledge proof of the circuit statement and they published the proof and they published their claims about the size and the speed that this should take to attack, you know, elliptic curve, uh, sorry, uh, elliptic curve DSA, uh, algorithm, uh, based on P-256 curve. Yeah. Um, yeah.

David: The Google publication was 2.1 million gates and 1,425 qubits.

Deirdre: Nice. I was pretty close.

David: In March, late March.

Deirdre: 2024.

David: Um, excuse me, 2026.

Deirdre: And this, this was kind of interesting because two people have been following quantum attack algorithms and, and sort of like, this is part of a, um, lineage of like, here’s our improvement and here’s like our tweak on how, how many resources, how fast can we get some of these attack algorithms to be. Even though we don’t have a quantum computer yet to really, you know, test them. Like, this is— I’m going to write it up or whatever. But this was new in that the authors claimed that their results were too dangerous to publish. So that is why they published a zero-knowledge proof of them, and they directly compared it to, um, uh, to— I think it was literally like the Manhattan Project or whatever. Like, they didn’t want to, like, publish the ingredient, like, the specific ingredients of how to make an atomic bomb or something like that. And it’s just like, uh, like, I don’t know, like, we can’t run it yet, can we? Like, it’s gonna be several years until we can— until we can run it. So like, all right, whatever. But that’s not the funny part. That, that was an interesting kind of— it, it caused a little bit of a debate of like, oh my goodness, if we make any more improvements of attack algorithms, do we have to— is this the way we disclose them now? Is this a new form of responsible disclosure? Like, blah, blah, blah, blah. That didn’t matter. People saw this result and they’re like, ooh, you’re trying to attack the, the signing algorithm of Bitcoin. Hmm, let’s try if we can like really run this down. And someone set up ECDSA.fail, and they were basically— they basically started crowdsourcing, um, attempts to improve this, uh, theoretical construction, uh, you know, this construction published by Google, but without publishing the actual circuit, and tried to beat their claimed, um, uh, costs and speed and resource requirements. And people were using ChatGPT and Claude and Opus and all this stuff to try and incrementally try to improve and improve and improve and improve and submit it. And the zero-knowledge proof turned out to be a great way to like cross-test your results or something like that. I think that’s what it was. One, there was also a bug in it. The Trail of Bits people were able to find that, like, you, they were able to get it to validate things that it was not supposed to validate. Was that it? And that, that’s what they were using to, to validate other things. I don’t remember.

David: Um, no, they’re, they’re using the, just the same, like, sim circuit simulators that, um, were in the Google paper, but then like Uh, the Google paper didn’t include like the actual circuit that just had like a proof about the circuit. Yeah. But like the circuit simulator is basically just code. And so you can have a coding agent, you know?

Deirdre: Yeah. Okay. That was, that was it.

David: Optimize this circuit, make no mistakes.

Deirdre: Yep. And it took 3 days. Let me see if I can find, if I can cross-reference. I think this was the 30th and the first result that beat it was June 2nd. So I think it was 3-ish days before the entire point of this thing is too dangerous to publish, so we’re just going to publish a zero-knowledge proof on it, which is completely blown out of the water by people crowdsourcing competing results on the internet. And they’re still going, and they’ve been able to drive it down. It’s like not quite twice as fast or twice as efficient in terms of gates as the Google, uh, results. But it’s very— it— people have been able to get a very good, um, much better, like 45% less gates and like, yeah, uh, 25% less—.

David: Or excuse me, 25% or 30% less gates and like 45% less qubits. Yeah.

Deirdre: And, uh, uh, it’s, it’s a lot of fun. It, it’s a, it’s a lot of fun.

David: So, um, power of telling people, it’s, it’s telling people that like something can be done and then trying to figure it out. Like, uh, when, when DROWN happened, like the way we got involved at Michigan was we heard there was a rumor that like there was something wrong with SSLv2. And so because we heard that, myself and my advisor like opened up the OpenSSL source code and just looked at the SSLv2 handshake for a while, like on a projector screen. And then we were like, ah, that pointer’s wrong after a while. And that was like our contribution. That turned out a bunch of people much smarter than us had come up with like a cryptographic vulnerability. And we were just like, no, that pointer’s wrong. And those two combined are what like led to the fan— the fanciest version of Ground. But like the only reason that we thought to look there was someone said, well, someone said, the rumor was there was something there. Same with this. Once you know something can be beaten, well, let’s go, let’s go try it.

Deirdre: Yeah.

David: Or just the same as like, uh, Nicholas Carlini, you know, saying the vulnerability is probably in this function. Yeah. Go, go find it. No, it’s in this function. Like, once you know the vulnerability is in the function, then you can find it. But yeah, otherwise you’d never find it.

Deirdre: Gosh, I love it. Um, I’m amused. I kind of hope that, like, this is, this is a great way to get improvements. Like, their attack algorithms, like, okay, but like, that’s how, that’s how defenses get better because the attacks get better and then we get better at defending. So that means you migrate off of ECDSA.

David: Spoiler alert, but, um, or, you know, a little culture clash between the physicists and the software security people.

Deirdre: Yes. Um, that, that was a thing that may not be obvious from just looking at the papers and the blog posts was that those results for that attack algorithm actually came out of like a different part of Google than say cryptography and security. And only the cryptography and security people found out about this thing that was coming, like very last minute, as far as I know. And like, they’re just like, what? Like, wait, what? Like, what do you— and then it was a whole negotiation of trying to get it out of Google. There’s no NSA or US government meddling, being like, no, no, you can’t publish this, it’s too dangerous. Like, none of that, as far as— that’s everything I’ve learned. It’s just like people, these physicists spooked themselves And instead of working with security people and cryptography people who are used to publishing, you know, things that affect security postures out in the world, they just spooked themselves. They said, I don’t know if we should publish this. Oh, let’s go get a zero-knowledge proof to slap on it. That, that’ll let us get it out the door.

David: So, um, yeah, I mean, Scott Aaronson even had a blog post kind of about this where he was like, you know, maybe like we shouldn’t publish some of this stuff cuz we’re close. And then he was like, Nadia Henninger talked me out of it on Facebook. And I thought that was interesting. Because I didn’t realize Nadia was still on Facebook.

Deirdre: Oh my goodness. I, I didn’t—.

David: But you know, thank you to Nadia for keeping your Facebook so that you can like tell Scott Aaronson when he’s wrong. Yes.

Deirdre: Uh, thank you very much because I’m not going on Facebook. And what I wonder— oh, I wonder, I think his blog posts are, or the, the comment section are, are cross-synchronized, uh, with, with Facebook. That might be why. I don’t know.

David: I don’t know.

Deirdre: Well, I haven’t logged into Facebook in many years.

David: Thank you to Nadia Henninger for discussing this with Scott Aaronson.

Deirdre: Yeah. But yeah, easy to say it’s fun. Uh, go, go fork the, the circuit simulator and see if you can do better with your favorite, uh, on your own or with your favorite, uh, large language model or something, because apparently they’re good at it. Seems fun. Cool. Did we miss anything?

David: I think that’s enough, uh, executive orders for 10 PM on a Tuesday.

Deirdre: Yeah, I don’t want to discover any new, uh, Trump EOs that involve quantum or cryptography or security. Um, cool. Yay, emergency pod done. Security Cryptography Whatever is a side project from Deirdre Connolly, Thomas Ptacek, and David Adrian. Our editor is Nettie Smith. You can’t— oh my God, I need—

David: Fuck, is our editor Nettie Smith? Like, we keep editing ours.

Deirdre: Uh, yeah, I need the fucking—.

David: I need to find this online. Yes, @tqbf, um, @durumcrustulum or @dadrian. Yes, that’s right, I ponied up the money to change my handle.

Deirdre: Oh, it’s not David C. Adrian no more.

David: All right, don’t forget to like us, rate us, smash that like and subscribe, follow us on whatever preferred format you get your podcasts or video podcasts.

Deirdre: Yes.

David: And thank you for listening.

Deirdre: And also you can get merch at merch.securitycryptographywhatever.com. Thank you for listening.

Facing the Vulnpocalypse With lcamtuf

Sun, 14 Jun 2026 00:00:00 +0000

We talk to Michał Zalewski (lcamtuf) about the vulnpocalypse and if we even need fuzzers anymore. This episode may be export controlled at a future date.

This episode was recorded on May 28, 2026.

Links:

lcamtuf: Either the most interesting time in the history of InfoSec or the second most interesting after the arrival of the web.

Deirdre: Hello, welcome to Security Cryptography Whatever. I’m Deirdre.

David: I’m David.

Thomas: I’m Thomas.

Deirdre: And we have—

lcamtuf: And I’m Michael.

Deirdre: Yes.

lcamtuf: Oh, sorry.

Deirdre: I— That’s okay.

lcamtuf: I missed it all.

Deirdre: This is the first time I think that’s actually happened in almost 3 years. Nice. We have a very special guest today. You may know him from the internet as, oh my God, I say lcamtuf, but.

Thomas: Yes, lcamtuf.

Deirdre: But you have like a real world human name, Michael Zielowski.

Thomas: Oh my God.

Deirdre: I’m sorry, I know Irish and the name.

Thomas: We were all hung up on the first name.

lcamtuf: Yeah.

Thomas: I can’t believe you hung up on the second bit.

lcamtuf: That was absolutely terrible.

Deirdre: Yes. I’m sorry.

lcamtuf: Yes. No, that’s fine. Yeah, the Polish pronunciation is Michal Zalewski, but I usually just go by Michael and yeah.

Thomas: Oh my God. I pronounced the W wrong.

lcamtuf: See, we’re— Yeah.

Thomas: You’re justified. I’m just as wrong as you are.

lcamtuf: This is the most disappointing podcast I have, you know, ever done in my life.

Deirdre: It’s bad.

Thomas: It will get so much worse.

lcamtuf: No, it’s gonna get worse.

David: It’s gonna get worse.

Thomas: So worse. Right. So we thought right now was a good time to talk because of all of the AI vulnerability discovery stuff that’s going on. And I feel as if we would have a very easy time finding people to talk to that were all lit up about AI vulnerabili— like agent-based vulnerability discovery. I’m one of those people. But it’s trickier to find somebody who is both skeptical— might be the wrong word, but like not on the exact same page as everybody else and who also has your track record in the space, particularly. And I said this a little bit earlier, like 90% of what I talk about here is just me exorcising demons from Hacker News. And like one of my, like one of my continual irritants on Hacker News is that any time a story from one of the Frontier Labs comes up, like 3 people always say fuzzers did all this stuff already. And like, the problem is that Google isn’t running fuzzers or Apple isn’t running fuzzers or whatever. And yeah, so you’re the author of American Fuzzy Lab, AFL, which is like the de facto standard tool in that space. So I kind of wanted to get like your perspective, not right away on the AI stuff, but just basically on the trajectory of how we’ve been doing automated vulnerability assessment, let’s call it?

lcamtuf: So that is a very open-ended question, I think. Yeah. You know, like most of vulnerability research is being done automatically and it’s been like that for a long time, right? If you look at the browser space, I would wager that 80 or 90% of what’s actually found and fixed is a product of automated tools. At the same time, you know, even though it is automated, you can have dramatic sort of, you know, step improvements or sort of, you know, like revolutionary shifts in the tooling that we are using. And I think LLMs do represent such a shift. So I’m not gonna take the, you know, the contrarian position of, oh, all of this sucks and it’s the same as fuzzing and, time is a flat circle. But at the same time, I do have fairly complex thoughts about the impact of the AI angle specifically. And I can sort of get into that now or we can get there more gradually. But yeah, sort of to directly answer your question, I think this is a very interesting time to be in. I think we are seeing Very fundamental shift. The technology is real, real. It’s amazing. And you should be using it as a part of your workflow. I think that’s the bottom line.

Thomas: Yeah. So I think the first thing I want to like, I have like my own personal experience using like, you know, kind of fuzzer arrangements of various kinds to do projects, but I’ve never done the like the at-scale work that like, you know, Google did in like the 2010s, you know, so like large farms full of things doing, you know, profile-guided, you know, AFL coverage and all that, right? So I have a mental model of like fuzzers as tools of like, they’re like literally things that I would build as like shop tools to get like, you know, individual projects done. But like one of these, like one of the worries I always have when people say like fuzzers did all this stuff is like my, like my advanced fuzzer knowledge is not all that up to date. I understand exactly what the tools are doing, but like the difference between that and actually finding vulnerabilities with them, like actually having the field experience with them and seeing where like the, you know, the sharp edges are or where they were, they’re really, really effective or whatever. I feel like I have less real-world experience. So if I said that, like, I think the way I want to get into this is just to like make a, make a claim that it’s probably going to be wrong, but I’ll make it anyways just so that you can tell me I’m wrong. Right. My experience of this is that fuzzers are a really good way of getting a pile of, you know, variably quantified or variably qualified crashes in programs, right? And that, like, people that run large-scale fuzzing, you know, quickly get adept at, you know, building mountains and mountains of crashes. And in those crashes, I think there’s like a general understanding that there are vulnerabilities,, but the work is going from that pile of crashes to actual vulnerabilities. And if you’re not doing that work, you’re not actually solving the problem.

lcamtuf: Yeah, I think, you know, a large portion of running fuzzers at this scale and actually getting vulnerabilities fixed is the automation around the actual sort of, you know, permutation engine, right? Like it’s how you get projects on board in the first place. That’s, you know, a major bottleneck for open source. And I think, you know, quite often you have to do it yourself, and then it’s gated on the available capacity of software engineers to actually instrument code, plug it in the right place, make sure that the right functionality is being exercised. And then the really difficult part is, you know, crashes are often good enough. Like, I think open-source developers don’t necessarily need an exploit. They don’t need a very detailed write-up, but they want a repeatable crash and You need to bring it to them using the workflow that they prefer, you know, in a fashion that works for them. Some of them have their own, you know, pet peeves and sort of, you know, complex ideologies that you have to work with to actually make sure that things get fixed. So I think it was always a bottleneck for fuzzing. Not all of this goes away with agents. I think, interactions with open source developers continue to be a very challenging touchpoint that you can’t really automate with an LLM and expect good results, right? Right. But yeah, I think, like, again, I think the way I’ve been describing this, and that goes way beyond vulnerability research, is that, you know, most of security problems really boil down to text comprehension at a scale. With emphasis on scale, right? Like we never have enough resources to actually look at every event generated by an enterprise, you know, detection pipeline or to sort of, you know, look at every line of code that’s being written. And I think LLMs really profoundly changed the game on a number of fronts, right?

Thomas: So. Let me like, let me try really quickly just like I mean, two things, right? First of all, cards on the table, my interest in all of this stuff is like almost purely on the capability side, right? Like what vulnerabilities are we finding is a much more interesting question to me than how, how this works as an engineering process, right? Like how we solve the open source metabolizing these things, all that stuff. Those are really important and valid problems that I have passing interest in, right? But like, I’m, I’m really focused on like the raw capability side of it. Right. And then like with respect to how fuzzers kind of have traditionally worked, I had like a radicalizing moment a couple of years ago, like maybe a year and a half ago where like, um, an engineer on our team, Salim, um, who, uh, is amazing. Um, like once a week he was finding game over vulnerabilities in our platform and like, you know, resolving them. And one of them was, This wasn’t a game over vulnerability, but it was a really good concern that we hadn’t thought about. We run farms of virtual machines for our customers, multi-tenant on the same hardware. And in some corner of our system, we were doing file system maintenance for VMs on the host side. So like we’d do like file system repair before backup or something like that. It was like whatever the current equivalent of fdisk is or whatever, but we’d run that on the host side, he’s like, well, you know, the filesystem obviously is controlled on the guest side. So now you’re exposed to the entire kernel surface for whatever this filesystem is. That’s a really good find. We solved that pretty quickly. But like, we’re trying to figure out how big of a deal it was. And it’s like, I’m just gonna go to syscaller and find crashers and run them through it. And like, there were crashers for it. Like he was immediately able to repro, you know, I don’t, you know, you can’t call it a memory corruption vulnerability just because it panics or whatever, but like, things where if we had found them ourselves, we would’ve gone and investigated them. And I have now this perception that there is just a mountain of Syscaller things that are just sitting there and like somebody should triage them, I guess. But like, are they vulnerabilities or are they not vulnerabilities? I don’t know. We’re in a state of uncertainty about that, right?

lcamtuf: No, so I think that’s like a fundamental change, right? And again, it doesn’t matter as much as, people sometimes claim, but I think it does matter, especially if you have like, you know, Heisenbugs that you don’t really, you know, you can’t immediately decide what’s causing this. It doesn’t reproduce consistently. It happens in a weird place that may be, you know, miles away from the original fault. So look, like again, in terms of technical capability and how it changes the game for InfoSec, I’m not actually a contrarian at all, right? My contrarian position lies somewhere else and it has more to do with how we as an industry think about the vulnerability research in the first place, right?

Thomas: Yeah. I should say, like, I’m saying that my interest is in XYZ, but like, I don’t speak for David, you, or Deirdre. I think I’m a, I’m a weirdo in this, in this one thing, right? Like, I find vulnerability research really very motivating, um, as a reason to learn pretty much everything I’ve learned about technology and math. Um, but that’s just me, right? Like, I think you’re right to like call out the, the— you, you just said something interesting that I’ve heard you say before, which is just like, um, how the industry kind of looks at vulnerability research. And you’ve said in other places Like, I get the impression that you generally feel like we way overvalue vulnerability research as an intrinsic good.

lcamtuf: Yeah, so, you know, maybe let me answer that in the form of a rant. And I’m gonna get to, like, a very precise AI-related point down the line. But yeah, I generally have come to, you know, detest infosec punditry on some level because I think we consistently get fixated on things that are, not really representative of what actually matters day to day. And you mentioned Hacker News and I actually checked Hacker News today and there was someone talking about how InfoSec, information security has already ceased to exist as a field, as a consequence of AI vulnerability discovery. And I think we have—

Thomas: That was not me for the record.

David: Let me call my boss real quick and let her know the field doesn’t exist anymore.

lcamtuf: So, you know, and it’s not just that, I think, you know, like, when you think about what arguably changed enterprise security the most in the past 15 years, it’s not the stuff that people present at Black Hat or that we, you know, sell at RSA. It was the one thing that we all love here, I think, Bitcoin, right? It used to be that ransomware was this niche thing that basically was constrained by how much money you could move through Western Union. Which was not a lot, right? And now it’s this like global economic powerhouse that funds hostile regimes and really is the one thing that keeps most CISOs up at night. And, you know, post-quantum cryptography doesn’t. I’m sorry to say that, right?

Deirdre: I know.

lcamtuf: Yeah. And so in my mind, you know, the discourse around AI vulnerability discovery kind of fits that mold, although not, again, not in the way that many people claim. You know, many folks think that the technology itself is hype or, And it isn’t, right? Like, again, it’s real, it’s impressive, and you should be using it. But, and again, as I mentioned, right, I think most of security is text comprehension at a scale. And now we have a, and we were really severely constrained by scale, and now we have a tool that largely removes that constraint. And that’s amazing, that’s transformative, and it’s absolutely gonna change the practice of InfoSec. But to get to my actual point, I think, you know, our industry has long overstated the practical importance of vulnerability research. And I think it’s partially because it’s sort of, you know, our origin story. And then it’s a part of our collective identity. It’s how we can, you know, it’s what we can bring up to show how clever we are and why we need to be paid more than everyone else. And it has cool ties to spycraft and all the other things. But But fundamentally, you know, like, zero days were generally not how enterprises get popped, and having 5 times as many zero days or 50% less doesn’t really change the nature of the game. And part of it is, you know, sort of physical constraints too, right? Like, the technology is not magic. It doesn’t give you an endless supply of, you know, zero days in OpenSSL, for example. It gives you some respectable numbers of new findings in software that was OpenSSH is already kind of busted and had exploitable bugs every year. And, you know, and that you probably have somewhere in your enterprise in a version that’s 5 years behind, right? So we were always kind of operating in that reality and we have far more basic problems that we can’t quite solve or couldn’t, you know, inventory patching, human behavior that are adding up to a much larger and less tractable attack surface that actually keeps biting us in the back over and over again. And this is actually where LLMs are absolutely amazing and are going to change the, because like all of a sudden you can actually reason about every single thing that’s happening within your enterprise quite possibly, right? And you can take action on that. And on the offense side, it’s kind of, you know, the same thing that like the attackers can now afford to pull on every single door handle within your enterprise and they can do that more quickly and they don’t have to care. Like, you know, if you’re using an agent, you have to worry about it deleting your production database. Ways. They don’t, right? Like, if it messes up, well, that’s a shame, but that was your data, not theirs, right? So, like, again, I think there’s a lot of interesting wake-up calls for security, and things we need to reckon with, and things we need to start building. But, like, you know, the vulnerability research side is amazing, and it’s, you know, on some level, it is, depressing to me that, you know, this is the one thing that I always enjoyed. And, you know, same as Thomas, right? Like, it really motivated me to learn. And now, you know, there’s a computer that can do it better, the same or better, and, you know, for a lot less. But yeah, so that’s sort of, you know, the genesis of my skepticism here, right? I think the AI apocalypse In the industry or the day of reckoning is coming, but it’s probably not the, you know, vuln-pocalypse, right? Angle specifically.

David: Yeah.

lcamtuf: Yeah.

Thomas: I want to— David, you go. Sorry.

David: I mostly agree with you. The way that I would put it is that it seems like zero-day exploitation is currently, or let’s say, pre-AI was not supply constrained at all. It was demand constrained because like for the most part, society works in the sense that it is like not a good career option for anyone on this call to decide to like go into exploitation. And if they do, but like actual like computer exploitation, not like vulnerability research. And if they do, like you said, they’re probably just gonna go after unpatched things anyway. It’s not clear that increasing the number of available zero days results in more, like, actual operationalized exploits. Yeah, well, to me— And it seems like it won’t.

lcamtuf: I think, you know, there are quantitative differences, right? Like, I think it lowers the bar, right? And sort of, you know, there’s gonna be like, I think, you know, it’s gonna alter the market dynamics, right? Like if you wanna buy a zero-day, maybe you’re gonna be able to buy it for less. But that’s kind of, you know—

David: You may have the Jevons paradox.

lcamtuf: Yeah, it’s kind of like, you know, qualitative versus quantitative, I think is the distinction I see, right?

David: Yeah. So I think there will be, there is like a risk that like the people in like, let’s say Southeast Asia, not to rag on them, that are currently running like tech support scams,, may find that it is now economical to run subset of like AI-driven exploitation things on some subset of users. Um, but I suspect that that would look different kind of in the same way that like pirating music got replaced with like listening to Spotify versus like everyone just started paying $0.99 a song.

Thomas: I like, so I think I’m like the resident vulnerability research and AI maximalist in this conversation, right? And I do think that the, like, the emphasis on, you know, the, the first tier targets like Chrome and iOS and all that, right? I do feel like that’s mostly a competitive thing, if that’s the right way to put it. It’s mostly kind of like a, it’s, it’s tournament logic, right? It doesn’t have that much to do with making things more secure. I feel like when we talked to, uh, Mark Dowd about like the markets and vulnerability research, I didn’t come away from that with the sense that like they were lacking for possible vulnerability avenues to chase down. Um, and like, there’s a, like, there’s a persistent logic that, you know, state-level actors or whatever are stockpiling vulnerabilities, which turns out not to be true. Like, it’s a software product like every other software product, and they’re literally more concerned about paying maintenance costs for vulnerabilities and exploit kits than they are with like, you know, having 15 different backup vulnerabilities. So I think you could look at the situation and say, okay, the fact that it’s going to get cheaper to find Chrome vulnerabilities, like a Chrome drive-by or whatever, um, that won’t change that much because everybody that you cared about having Chrome drive-bys already had them.

Deirdre: Exactly. Or at least had—

Thomas: there’s already a market that makes that work.

Deirdre: Already had the ones they really needed and no more.

lcamtuf: Yeah.

David: And I think there’s— an early Uber investor a few weeks ago was saying, oh, I don’t know why we didn’t give Mythos, like, to the US government and then use it to hack China, like, before announcing it. And it’s like, well, that’s because that’s not how any of this fucking works. Like, we’re not short— the reason that, like, the US military can or cannot get into something in China has nothing to do with, like, a shortage of exploits.

lcamtuf: The other reason why I’m kind of skeptical about the vulnerability situation specifically is that I think there’s, like, inherent symmetry to it, right? Like, any tool that the bad bad guy can use, the good guys can use exactly the same way, right? So if Chrome or, you know, Microsoft or whoever, Apple want to sort of, you know, match the increase in the availability of zero days, you know, they have a simple lever to pull and they can sort of, you know, get where they want to be to restore the previous equilibrium., right? Or even go beyond. I think there are many other areas in security where that symmetry doesn’t hold, right? Like the example I mentioned, like, you know, the defense versus offense on the enterprise side has this asymmetry baked in. It’s a lot easier to crank out hyper-targeted spear phishing emails to execs than to detect and stop them reliably, right? Even with AI. And so I think that’s where the AI gives the bad guys a lot more advantage that is more difficult to counter, right? Versus just, you know, we were fuzzing Chrome before, now we’re also gonna, you know, throw some LLMs at it, right? And that’s kind of, you know, the eternal struggle. Between good and evil, right? Right.

David: It changes things operationally a lot for all the reasons that like Thomas doesn’t care about, um, which are, I think, the ones that are interesting to me. And so like, you, you have a question even like right now, I’ve had people come to me at Chrome who like work on other parts of Chrome and are basically like, aren’t we just drastically overinvesting in basically like anti-exploitation things. And if you look at it like by the numbers, right, there’s like not that many people whose crumbs get popped every year. So in some sense, we are. On the other hand, like what we’re really doing is like we’re winning, sort of, for some definition of winning. And like if we stopped doing all of this, it will go back and it would look like the early 2000s or the late ’90s again.. And so we just kind of have to do all this work to run in place, sort of. And then like what, um, like AI bug finding has done has, I think in many ways, like just validated things that a bunch of security people already knew, like for, for platforms basically. Like let’s ignore the open source projects, which is like not interesting. I agree. I agree with everyone else that—

Deirdre: Not including Chromium.

David: How about, uh, about like small open source projects? And instead, like, let’s just talk about like things that previously were targets for exploitation, which is like client-side platforms, like browsers.

lcamtuf: Yeah, let’s not talk about stuff like XZ, right? Like, who cares about that?

David: Um, I mean, in practice, um, in practice, like, uh, I, I would just, I would quote Hermione, um, and, and say, you know, when it turns out when that happens, we’re pretty good at catching it. Um, uh, but like, the deluge of AI bugs has created, like, has magnified all of the things that were already stupid about bug bounties, which was that, like, a bug bounty is, like, the worst possible way to prioritize security work because it’s entirely interrupt-driven. And so instead what you have is you have just deluge of bugs that were basically validating everything that security people said, which was like, your code’s full of memory safety vulnerabilities and these are the areas that are the worst. And then people are like, oh, you know, I don’t know. Like, and security people are bad at their jobs at getting people to change anyway. And so all these bugs show up and then you have this operational question of like, how do we deal with that? And you have to deal with it, even though the like impact of increased exploitation might not be that bad, because eventually, like, if we just chose to not deal with it, we’d be back in the 2000s again and we don’t want that. So you have to figure out how to deal with it. And like, yeah, you get the AI tools to help you deal with the problems that the AI solved. But again, I think it is a little bit harder for defenders because like, if you’re an engineering team, you need to like make sure this stuff is repeatable and can either run on every commit or you have like a consistent way of using a harness to find bugs and patch them and prevent them from coming back. Whereas if you’re like selling exploits, even if you’re operationalizing it, What you need is a fuzzer you can run for a few months that pops out a big enough backlog. And then a couple months later, you need to be able to do that again. I’m kind of, I haven’t actually worked for an offensive firm, so I don’t know that for sure. But there’s a difference between finding a lot of bugs once and then like actually solving a problem. And again, the people working on the platforms actually have to solve the problems again. And that just always sucks because you’re, you know, doing—

lcamtuf: Yeah, but I think, you know, like With browsers in particular, I think the implicit assumption is that given the developer velocity, the choice of languages and the features that are sort of being shipped every year, we are accepting, implicitly accepting a certain baseline of security failures, right? So like we are not aiming for a state of having zero vulnerabilities because that would be insane. And also, yeah. And so, yeah, you wanna lower the base rate, you know, you wanna run the same tools that the bad guys are running at the same or larger scale to make their lives harder. But ultimately, more hinges not on the inability to find another bug in, you know, WebGL or whatever, but on actually on mitigations, right? Like holding up and making it really difficult to reliably exploit And sort of, you know, bringing the cost up, right? Like most of the mitigations you can eventually bypass if you get lucky, if you chain together, you know, 5 or 10 bugs, but a large portion of why zero days have gotten so expensive is because you need to do all that legwork that wasn’t necessarily essential before, right?

David: And I think that— I disagree with that a little bit in the sense that like, As enough mitigations, like, do actually have an impact on attackers, but unless you can like affirmatively say like a given bug that comes into your queue, like, doesn’t matter. Like at this line of code, ideally by like inspecting the line of code, being like, oh, this uses a span. So I know it’s not an out-of-bounds read unless the span is constructed wrong or it uses raw_ptr, miracle pointer in Chrome. So we know the use-after-free doesn’t matter.

lcamtuf: Oh no, no.

David: I, I— Like if you have something where like, oh, maybe it’s just a write and not a read. You still have to treat it like it’s bad. No, no, no.

lcamtuf: Yeah, I was, I was talking about—

David: And then it comes through your whole process as an engineer.

lcamtuf: Yeah, I was talking about the offense side, right? Like I think on the defense side—

David: Yeah, but you can’t discern. The problem is the defender can’t discern which ones were useful and which ones were not. And so you have to treat them all the same. And so if you just apply mitigations, even if you are actively hurting the ability to actually exploit Chrome, like you’re not solving your problem of you have this massive interrupt queue of security issues, which eventually you’re just going to stop looking at.

Deirdre: Yeah.

lcamtuf: Yeah. We’re basically doing two things that are not solving the problem, but which is trying to enumerate all the bugs, but yeah.

Thomas: So there’s like an implicit assumption here in this conversation that the vulnerabilities that agents might find, and we can get into more of why we think agents might or might not find different kinds of vulnerabilities, but the vulnerabilities they’re going to find are going to be of the same kind of, they’re going to rhyme with all the vulnerabilities that we’ve seen so far. And like we’re accepting a certain amount annually or every month or whatever of memory corruption vulnerabilities in client-side software or whatever it is, right? And so like, I think we feel like we have a decent bead on where things are going. And like, I do feel like we’ve kind of like organizationally and as kind of an industry, we’ve metabolized a certain level of, you know, dealing with vulnerabilities, right? Like the sky doesn’t fall every time a new vulnerability comes out. You’re much more likely to get popped with phishing or by a dumb misconfiguration in an S3 bucket something like that. Like fully agree on that, right? And like LLMs apply to that stuff the same way they apply to everything else, which is super interesting. But I wanna push back on the idea that like what agents are gonna do is, you know, get us to peak oil on memory corruption vulnerabilities or something like that, right? Like there were moments in the past when we as practitioners, like we were practicing when SQL injection, you know, broke out, right? And there’s, there’s like a before or after moment that was probably the span of like just a couple months where like before there were a bunch of things that were hard to break into and after, like for a while, everything was trivial. The first commercial pen test I ever did was like, it was an application where I logged in with quote, unquote, quote equals quote, which is literally the first SQL injection I ever attempted and it worked, which totally ruined me for vulnerability research ever after that. ‘Cause I’d always think that would work and it almost like, you never get blatant SQL injection vulnerabilities like that. But I did in that one instance and thought they were that common. But like, so like, When we discovered SQL, when we first published StackOverflows, right? There’s a clear before and after to enablement for StackOverflow vulnerabilities. Before, lots of software was, you know, resilient enough. And then after, the entire internet was vulnerable. And in those moments, it’s really material, the vulnerabilities that you’re finding, right? In those moments, it actually really matters a lot that there are all these new vuln— it becomes the dominant vector that things get popped with until you kind of figure that out. And I’m not as certain as I think the implicit assumptions in this conversation are that we’re not we’re not going to see more things like that. So, you know, side-channel attacks are a good example of where there’s like lots of kind of intellectually understood vulnerabilities that we don’t viscerally feel and we don’t deal with because there isn’t enough elite attention to develop them into real vulnerabilities. How certain are the three of you that like all Go memory race vulnerabilities are not going to really be practically exploitable?

lcamtuf: So I think you’re sort of, you know, Entering toward this sort of, you know, AGI question here maybe, right?

Thomas: Is that AGI? It’s like—

Deirdre: It’s not even AGI.

Thomas: Is a memory race exploitable an indication of AGI?

David: Exploiting a Go race condition, AGI confirmed.

lcamtuf: Right, yeah, no, I think, you know, to some extent, you know, all that I have seen so far is that LLMs are very good at scaling the methods that we’ve been using in the past and finding the problems that we’ve been finding in the past. Now I think there’s also less numerous data points from other fields that they are actually so good at combining and synthesizing information from the sort of training corpus that they arrive at completely new conclusions, completely new findings, like fundamentally new math, right? And so on. I think you’re asking about unknown unknowns, right? There is a future where we, it actually turns out that there’s a nearly inexhaustible supply of zero days in OpenSSL in places we were not even thinking about. But I have no way to prove or disprove that.

Thomas: And I don’t think— Hold on. Hold on. In fairness, I want to say, I actually don’t think we’re going to get like a bottomless supply of OpenSSH vulnerabilities. I have like a, despite it being an old school C code base, I have a very high opinion of the OpenSSH code base, right? I’m actually thinking of things where it’s like, I have a nagging suspicion that there are already things there. And to me it’s not as much about advancing LLM, like frontier model capabilities, although that’s a factor. It’s not as much that as it is the new abundance we have of elite attention. OpenSSH, right? Where like, it doesn’t take that much time for me to set up the conditions to like, do, you know, a side-channel testing harness across the internet or something like that. Where like, I, I’d have to do a whole lot of studying and research and like trial and error to get that, like those harnesses set up for myself to do that kind of testing. And now I can just dispatch it and have it done. Um, like it’s, so I feel like the really high-end vulnerability research has been for the past 20 years done by like a reasonably large number of people, but it’s still an elite in the industry. And I don’t like that. Right? Like I think that’s always been kind of bullshit. And like one of my big things is just, I don’t think that the people doing this work on the high end are really in any fundamental sense more gifted or capable than any other engineer. They just, they, they’ve been inducted into the field and they get to do that work. Yeah. Right. And like, I think the bottom has fallen out of that. Right. And so now if you imagine 10, 100 times more people being able to do that work because it’s no longer as time-consuming, I think a lot more things get kind of proved out.

Deirdre: Not even time-consuming, but like, no, like, where do you even get the knowledge to start the thing that requires— like, that also requires time, but it requires some sort of like entry point of like, how do I even get started on this path? And now you don’t even have to know anything. You just like go look for vulns in place. Like, here’s your guide, start here, enter here, and it will find something more, more likely than not. If it’s a, if there is a vuln there, it won’t, you know, maybe it’ll hallucinate something that’s not really there, but then you can write a test that’ll actually, it’ll ask it to write a test to be like, confirm that this is broken. So there’s, it’s, it’s not even just the time amplifier, but like, there’s a lot of stuff that you used to be, have to be able to know what to ask or know where to start or know how to approach a thing. That you basically have a very powerful shortcut on.

lcamtuf: I would say this. I think that a lot of money and compute has been thrown at this problem by the frontier labs over the past couple of weeks or months. And we’re going to start seeing a trickle or a flood. I mean, we have already started seeing some of the sort of public results from that. My understanding of, you know, what I’ve seen so far and what I can talk about is that they are not fundamentally different from, again, you know, the kind of vulnerabilities, the kinds of targets, the kinds of attack surfaces that we’ve been seeing before. So I think, you know, that doesn’t disprove your theory, but I think the, it would hinge, I think, We would depend on some additional breakthroughs before we get to this point where you can point GPT-5.5 or Mythos or whatever at Chrome and come up with completely new classes of vulnerabilities or, you know, the, like, again, race conditions of the kind that we thought are not exploitable in past. Like, I think it’s possible, like it happened before.

Thomas: But that’s not what I, that’s not what I think, right? Like, so there’s the big thing with Mythos has always been Nicholas Carlini being able to aim those frontier models at a piece of software and just say, give me a zero-day exploit, right? And those words put together and getting real output from that was like a, a huge thing. I, I, I, that’s, it’s, that’s a real thing, right? But like, I’m not coming from a place of, you know, pointing, you know, a frontier model at a code base and saying, come up with an entirely new bug class. Like, it’s just gonna figure that out. I’m more coming from like, like, do you really not have nagging suspicions about— so first of all, this might just be me, right? It might just be because I learned all the computer science I learned by reading exploits. But like, it’s like, it’s like all I think about is like what, like what the new bug classes are gonna be like Spectre. Like, that was amazing for me, right? Like, things like that. Like, that’s the punctuation for this whole kind of career that I have, right?

lcamtuf: But it’s kind of like—

Thomas: I’m always thinking about like what the other, like, what weird thing this could turn out to be. Entire bug classes. Do you not have anything like that? Do you not think that way? Are you not a vulnerability researcher?

lcamtuf: I have a lot of things, like, you know, there’s a lot of places, there’s a lot of rocks that I think we have not peeked under. And I think LLMs are gonna, like, you know, in the embedded world, which is, you know, something I’m spending a lot of time with as a hobby. There’s a lot of absolutely terrible things that are absolutely everywhere right now. And I’m not talking, you know, like a crappy HTTP stack on a more fundamental level, right? Like, you know, the radios and everything.

Thomas: Yeah, RF.

lcamtuf: Yeah. And I think this is, but at the same time, you know, so yeah, I think, you know, we’re going to unlock a lot of interesting things. Does that Is that like a fundamentally qualitative change versus, you know, some researchers deciding, oh, actually I’m going to throw a fuzzer at this hardware as it happened many times in the past. And, you know, what is the actual, like, you know, Spectre, again, like a fascinating class of bugs.

Thomas: I know, I know what you’re going to say.

lcamtuf: Does it like, you know, so what? Like, I absolutely loved it, every bit of it. And, you know, the insane amount of resources. We spent—

Deirdre: but we agree, we probably agree. The foundation of the trusted compute base. It’s a lot of, it’s a, it’s a lot of things that are kind of, we worry about in cryptography is like, this is highly difficult to exploit in a lot of cases, but it’s the foundation of trust in almost everything that we build on top of it.

Thomas: I know, I know. Fundamentally, fundamentally, the impact of Spectre was simply to make all of our computers slower. I understand this, right?

Deirdre: But that’s interesting. It could have been a lot worse. It could have been a lot worse.

Thomas: But you, you can’t say that about SQL injection. Fundamentally, the popularization of SQL injection materially changed the susceptibility of networks to attack, right? Spectre didn’t do that. SQL injection did do that. SSH, more recent example, right?

lcamtuf: Yeah, but again, like, you know, you also have tools to eradicate it more quickly now. So I think there is symmetry, right? We get, like, you know, we’ve been through those cycles before, many times before, and both on the sort of, you know, like the, uptake or the sort of, you know, uphill portion of it when, you know, someone discovers XSS and it turns out that you can do absolutely terrible things with it, including, you know, running code on your device because we moved everything to the web, right? Including control over endpoints. And then sort of, you know, we’ve seen people actually make progress, making those classes of issues go away, right? Like, you know, like, If you want to find an XSS on google.com, you’re going to have a hard time, right? Because of the investments that the company has made into getting rid of entire class of engineering.

David: Into safe coding specifically. Like again, not mitigations, like safe coding, stop the bug at the source.

lcamtuf: So I think, you know, like if you’re asking me if security is going to be interesting for the next couple of years, absolutely. And vulnerability research is gonna be interesting and a lot of other, you know, attack and defense related aspects of it are gonna be fun as well. But again, like, you know, and I guess, you know, it’s a question of where we draw the line between apocalypse and business as usual, right? And maybe we are just defining it a bit differently.

Thomas: I didn’t come up with bugpocalypse or whatever it is. I don’t think there’s any pocalypses coming, right? We’ll figure it out. I think the RF thing is like such a good example just because of so many times I had the experience of being on projects where there was an RF target and like we’d go in and like everyone wanted to like get good at GNU Radio or whatever people were using, like SDRs and all that. Right. And like by your second project, you just knew going into that, like, no, you’re not gonna do anything with an SDR for this RF target. You have no idea how complicated it is to actually get a protocol up and running like that. Right. Inevitably you’re just going to do the hardware hacking to find like the serial bus that you can like turn this thing into a modem for its own protocol. That might not be true anymore though, right? Like now, like that’s, that seems like a reasonable task to stick an LLM on. ‘Cause it’s got like in the training set, there is all the RF knowledge. It’s just like none of us are electrical engineers. So we were never trained to do that stuff. But like the model’s an electrical engineer, it’s every kind of engineer. I, I just think that’s, I know, I get what you’re saying. Like even like widespread RF attacks probably wouldn’t, I don’t know, maybe it’d be more destabilizing than Spectre, but like, No, like, you know, you could probably build some cool worm, right?

lcamtuf: And like, I’m, but again, you know, we’ve done that. We’ve been there.

Thomas: It’s a worm. We’ve seen worms.

David: The apocalypse isn’t going to be on users. It’s the, like, let’s classify projects into like 3 shapes. There’s like some stuff like OpenSSH and BoringSSL that pretty much doesn’t have bugs. Um, what did you say? OpenBSD?

Deirdre: Insha’Allah. BoringSSL.

David: BoringSSL, which has had the AIs pointed at it and they have not found any high severity memory issues, whereas they have found many in other SSLs. Um, and like OpenSSL, like there’s like 3 people in the world that can write like safe C code, like, uh, the WireGuard, uh, Jason is one of them, but, um, So there’s some projects that like we’ve actually managed to make safe. There’s another set of projects that just like don’t actually matter that much. And then there’s the like set of projects that are like actually juicy exploit targets. And I think we’re all loosely in agreement that those will not, that like we’re not really expecting a ton more exploitation. Like maybe it’s a risk, like we’ll see what happens with the market dynamics. Um, but the, the, the apocalypse there is on the engineering teams of those products. Because you have more and more bugs than ever and there’s, there’s not a good way to prioritize, like, how you handle this.

lcamtuf: Yes.

David: You need to be taking the set of bugs and turning it into like a queue of actually preventative actions and not just mitigations because you need preventative actions to like save the time of an— I’m— of the actual engineering teams. And if you just choose to say, you know, well, exploitation was already like demand-bound, not supply-bound. So it doesn’t matter. Like, doing nothing will result in the Jevons paradox and like bad things happening. So you have to do something. And so the apocalypse is just like, you have this massive queue of interrupt work that is saying like, you got 20 million lines of C++ in Chrome. Well, not all of them are going to be winners, right? Yeah. And if it’s one bug per like 1,000 lines, that’s, you know, like 20,000 high severity bugs, and if an AI finds 10 a day, well, I’ll see you in like 3 to 10 years.

Deirdre: Yeah. Yeah. And that’s not even including like, you know, up the past couple of months, couple of years, like there’s been sloppy reports to bug bounty programs and, and bug trackers and stuff like that. And like, you can get rid of a lot of the, the crap reports. It’s laborious, but you can do it. Now the reports are just very, very good and a lot of them are not slop and that is like when they’re all very good and they’re all high, like you have to deal with that too.

Thomas: Yeah. Can I take a minute? Can I just take a minute here? Another Hacker News thing just blew up in my brain. I’m sorry, I’m having a message board stroke.

lcamtuf: Okay. Oh my God.

Thomas: But can we talk, can we talk for a second?

Deirdre: You mean like Hacker News statins or something?

David: What’s going on? What are we doing?

Thomas: Can we talk for a second here about the idea that curl is the benchmark for how effective a vulnerability tool is.

Deirdre: Fuck, why?

Thomas: This is—

Deirdre: No.

Thomas: This is entirely— Am I— I’m waiting for any of the three of you to tell me that I’m wrong and that curl is deceptively difficult software to build. And that you wouldn’t expect it to work properly. ‘Cause all I hear is like Mythos didn’t find awesome things. Like they did a Mythos scan on curl and it didn’t find any new curl zero days. It’s like you could do a Mythos scan on cat and I wouldn’t think that cat would have zero day vulnerabilities either.

Deirdre: It’s a little bit more complicated than cat, You know, it’s not OpenBSD, so I wouldn’t expect it to be that juicy.

Thomas: Well, you shut your mouth.

lcamtuf: I also, you know, like we, like, I think there’s also the risk of like, you know, I had the opposite of this conversation with many folks many years ago before AI that, you know, like in the context of some of the mitigations we’ve and sort of, you know, defenses and so, and practices we’ve been developing at Google. That all of this is cool, but it works for like, you know, this one company in the world that is sort of, you know, has a codebase of a sufficient complexity and a sufficient amount of funding and so on. And everyone is sort of, you know, struggling with more basic problems, right? So I think curl is actually representative of a lot of what’s out there, right? Like it’s actually a pretty good baseline for a codebase that isn’t terrible. It’s not like, you know, some of the— It’s not FFmpeg, right? Like you can’t throw a parser at it and have like, you know, 50 bugs in an hour. But it’s also not like, you know, some like very simple trivial library that is not gonna have bugs.

Thomas: So I think it’s a good— I think curl matters a lot. I think curl matters. I just don’t think it’s a complexity benchmark.

lcamtuf: Yeah, I think, you know, there are people making arguments both ways that this is like, basically if someone tells you that whatever outcome with curl, good or bad, is proof of anything, then they are probably full of it.

Thomas: But I feel bad. I feel bad putting this to you because I feel like fundamentally the subtext of what you’re saying is like, we’re way over-indexed on vulnerability discovery and response in general, right? And like, we can go different angles on that. We can talk about backup software, we can talk about the oddball stuff that I’m worried about getting, you know, popped right now that like isn’t Chrome or whatever, right? But like, more generally, I wonder Like one big problem that we have is, um, it’s, it’s really easy to imagine, you know, next week, like Mythos 2 is gonna find a reliable KVM exploit, right? Um, like something that broadly impacts everybody and like, I’m gonna have to reboot every single, you know, server in our fleet. And that’s a lot of hardware to reboot. It would take us all, it would take us some, we’ve, we’ve tabletopped this. It’s, it’s doable, but like, it’s, it’s rough.

Deirdre: Like the vuln wouldn’t be anything. I think we’re speculating the vuln wouldn’t be anything like completely alien that no one’s ever seen before. It’s just threading pieces together in a way that because it holds all this context in its quote head, it’s able to thread them together and find an exploit.

Thomas: Well, hold on, forget LLMs finding this. Imagine, you know, just Travis Ormandy publishes this next week. Of course. Which he has done to us before.

Deirdre: He took a shower and then, you know.

Thomas: Yeah, I’ve like gotten lunch and come back and like Zenbleed is happening, right? Oh boy. Whatever. Put aside how the— I admire him. He’s amazing. I’m not dunking on him. That did happen. That did happen to me. My thing here now is on the, on the defender side, right? Like another thing that agents potentially do for me is put me in a situation where I don’t necessarily have to reboot to do that. Right? Like it’s much more plausible now that I could do a dynamic kernel patch than before.

lcamtuf: Yeah, but that’s kind of one of the places where you do have that asymmetry, right? Like, to find vulnerabilities, you’re perfectly happy with a, you know, 50% accuracy rate. Like if 50% of the findings or 90% of the findings, that would be just like absolutely wonderful. You will not accept 90% accuracy for binary patching in production, right? So I think the solution is a lot more challenging than the—

Thomas: I’m like, You’re like, you’re two steps past where I’m at, right? Just assume we’re at the, assume we’re in a, in a situation where like we’ve identified the vulnerability, there is an official source level fix for it. That’s the right fix and all that. And I, I have the simple logistical problem of how the hell do I actually apply this patch given I’m gonna have to reboot, you know, tens of thousands of, you know, physical machines or whatever.

Deirdre: How do you deploy the fix?

Thomas: Not, right. Okay. Like I’m thinking more just in line of like, we have a known good fix for it. And like, I can, I can imagine that in most cases, even I’d, in many cases, I’d be able to dynamically, given a known good patch, dynamically apply that in the business operation sense, not in the like software library.

Deirdre: Like I just have to release a security fix version and blast it out to all official channels, et cetera.

David: No, no. By apply, you mean hot patch your live running.

Thomas: Yeah, exactly.

David: Right. Without rebooting.

lcamtuf: Yeah. But you have confidence that the solution is right and you just need like a monkey with a wrench to log in.

Thomas: Well, yeah, but I mean, I think a lot of things don’t get fixed just because it’s very difficult to schedule resets and take the outage.

Deirdre: Yes. Or in this case, take the risk of an outage. You might have a lot of confidence that you can live patch this, but that’s still risky.

lcamtuf: If you can get to that point, yeah. And then, you know, like you still have the problem that, you know, if the agent goes to Reddit and decides to ransomware you instead, you, But like, you know, that can be mitigated, right? Like with sandboxing and it’s all probabilistic, but I think we have to get used to the notion that, I mean, you know, it was always probabilistic, but like humans are probabilistic too, although in a different way and maybe a bit more predictable. And we need to build better models of how to deal with the unpredictability of agents every now and then. But yeah, no, like, yes, I— I don’t think you’re crazy.

Deirdre: So a nice thing though with software is that you can do all this other stuff outside that the model isn’t touching, and you can try to get something that’s a lot more deterministic to try to like confirm so that it’ll spit something out and you can have pretty good confidence in what it will do behaviorally because you did all this other work to like test it up the wazoo yourself and try to basically mitigate the probabilistic trust that you have.

lcamtuf: Yeah, sorry, I didn’t mean to interrupt. No, sorry. Yeah. I know, I have this theory that if we’re thinking about using agents in like mission-critical settings, like enterprises and so on, the principle, the way to build those architectures is not to put agents with human-like autonomy and human-like access and hope for them to always make the right decisions. It’s to give them tools that are secure by default, provide them with more constrained permissions and more constrained access that is tailored to the differences between those. They are fundamentally different. You can’t put them in prison, right? If they delete your data, they can write you an apology letter, but that’s kind of as far as it goes. So there’s like, you know, the usual social contract you have with your employees is gone and all the negative consequences that come with that. So I think, you know, there are architectures that are conductive to building secure agentic platforms today, and we should be leaning into that more in the future. But I don’t think this is the direction that the frontier labs are moving in, which is basically human-like agents that are, you know, your coworkers, your assistants, and basically have access, unconstrained access to everything that you have and that act with full human-like autonomy, right? And I think that is, I may be wrong about this, but I just don’t, Until we solve prompt injection and all the other problems that we don’t seem to be making as much progress on as on capabilities themselves. I, yeah, I don’t know.

Thomas: I do get, yeah, I do get squicked out. Like I see a lot of places where LLMs are super applicable to defense, but I do get squicked out every time I see somebody using an LLM as a reference monitor, right? Like this is the actual defense we have is that an LLM will make smart decisions about things. Like I’m sure there are a lot of places where like, good smart decision-making as like a good triage step or whatever, but like literally as an access control mechanism, kind of like doesn’t seem right to me.

lcamtuf: Well, the problem they are trying to solve, I think in many cases is that you now have agents on the attack side, right? So, and they can move very, very quickly, like, you know, compromise to persistence to lateral movement in, you know, what, 30 seconds, right? And they can do it at any time. And so you kind of need human-like reasoning about what’s happening in the enterprise and autonomous decision-making on timescales that are just fundamentally incompatible with human workflows, unless you fundamentally rethink how companies are structured and built and you, you know, compartmentalize everything a lot better than we are compartmentalizing today. So I think on some level, LLM-type reasoning is unavoidable on the defense side if you want that real-time clever sort of countermeasures, but it’s incredibly difficult to get this right and not shoot yourself in the foot.

Thomas: So yeah. It wouldn’t be my first move as a defender. That wouldn’t be like the first place I would go.

lcamtuf: Oh yeah, yeah, yeah. I think, you know, like, like you need a lot of piping before you even get there, right? Like, you know, it needs to have the right sources of information to begin with. And, you know, most enterprises don’t even have that, right?

Thomas: Let me ask you a weird question. So you’ve got the book and I’m going to ask you about the book and the new book in a second, right? But like, like how, how, like, how like security are you going to be going forward? Are you going to veer off into circuit land?

lcamtuf: No. So, you know, so yeah, electronics has been my passion ever since. And I think, you know, it’s kind of like I ended up doing computer security kind of by accident. You know, computers, like I was either going to become an electrical engineer or a chemical engineer. And that was sort of, you know, my childhood thing. And then computers showed up and ruined my life, right? And it was sort of the right time, the right place, right, to be getting into InfoSec.

Deirdre: I feel like that could be said of all of us, and then computers showed up and ruined my life.

lcamtuf: Right, yeah, yeah. So I think, you know, so obviously, you know, no real regrets about that. But yeah, I keep going back to that. And here’s the thing, like, I’m still very passionate about security. And I think, again, like, this is, incredibly interesting, right? Like this is either the most interesting time in the history of InfoSec or the second most interesting after the arrival of the web, right?

David: Yeah, absolutely.

lcamtuf: I was not nearly as excited about the field for a good while, right? So I wanna be a part of it. At the same time, I think, you know, the things that make you visible in the field, like basically punditry, you know, I guess having a TikTok now, right? Or a podcast. Or like, you know, doing vulnerability research work. I think, you know, I’ve done this long enough that it feels kind of, when you look back at it, it feels kind of futile, right? Like I did two security books. They are basically completely obsolete at this point. All the, you know, hundreds of advisories and whatever that I published, you know, a decade, two decades ago, No one really remembers or cares about any of that. And it’s not that, you know, I’m sort of, you know, I, like, I’m not seeking eternal fame, but I think it’s kind of weird about InfoSec compared to almost anything. Like, you know, if you publish a book about electronics, yeah, it’s going to be slightly outdated in 10 years and maybe badly outdated in 20, but it’s sort of, you know, it’s, it’s not as rapid, it’s not as dramatic, right? If you build a, if you’re a woodworker and you build a stool for yourself, you know, it’s still gonna be fine. Like you’re gonna still gonna be able to look at it and maybe pass it onto your children.

Thomas: No, like if you wrote like a comprehensive catalog of shop jigs in a woodworking book in like 1965, I would probably still be interested in reading that.

lcamtuf: Right, so I think, you know, I’m trying to balance, like basically I looked at my, you know, infosec legacy and thought to myself, oh my God, this is all like, you know, this is worthless. Right? Like there’s, you know, AFL is going to get forgotten before long as well. And I’m trying to, you know, like find ways to make a more durable difference before, you know, before my time is up.

Thomas: Right. So the book, I’m looking at a cover with a woman holding a solder, a hot solder iron way too close to her face. Yes. Tell us more about the book.

lcamtuf: Right.

Deirdre: What is the name of the book?

lcamtuf: The Secret Life of Circuits.

Deirdre: Awesome.

lcamtuf: Yeah.

Thomas: Let me ask my first question is, will this book teach me how to solder? Because I am terrible at soldering.

lcamtuf: It actually contains some, you know, like pretty useful tips, which is basically spend more money on a good soldering iron, like a pencil shape. Like, you know, versus the one that you hold like a toothbrush and is about as fine of a tool. And that really, really makes a difference. But yeah, so like, there’s plenty of books about electronics, but I think we have this weird two-track approach to teaching that discipline, right? Like there’s the hobby track, which is where you basically tell people that circuits are like water pipes, And I guess a diode is like a check valve and the transistor is God knows what, right? Like some sort of a plumbing abomination that you probably don’t want in your home. And all of this is very seductive, but it’s also kind of terribly wrong because there are interactions between electrons and charges that are happening at microscopic distances. Like, you have two wires and there’s current flowing in one and a voltage appears in another one. And like, you know, you can’t really explain that with like, you know, plumbing analogies, right? So you, so all that stuff that they teach you basically has zero predictive power and you struggle to build your own circuits down the line. It’s kind of like watching, you know, 3 Blue One Brown videos on YouTube and you are really impressed by how clearly it’s all explained. And then you realize that you don’t actually know how to apply any of that knowledge to any practical problems. And then there’s the second track, which is sort of the college degree approach, right? Where you have a textbook that is more anatomically correct, but the way we teach electronics to students is we really front-load the calculus. You’re basically only learning truly punishing math for the first year and a change before you get to an LED or like whatever, right? And you use that as a foundation to streamline all the electronic theory down the line. But this means that, you know, like college textbooks are basically completely inaccessible to hobbyists because no one is going to take a semester or two of calculus.

Thomas: What’s the level of, like, what’s the level of math I need for the— I know that you’re doing a different track here, which is super, super interesting, right? You’re trying to be like at least practically theoretically rigorous about things without forcing me to solve partial differential equations. But what’s the level of math rigor you think you’d need to bring into the college track normally? How far do you have to get in that sequence?

lcamtuf: So are you asking about the way people normally teach it?

Thomas: The way people normally teach it.

lcamtuf: I think it goes pretty far. It’s like Laplace transforms and complex number calculus and stuff like that, right? So it’s not just like the basics of of here’s the rate of change or here’s the sum over time, right? It’s like far more punishing. And the thing that I, like, you know, I don’t have an EE degree, but I actually tried to follow that path. And the thing that is really frustrating by the end of the day is that none of the calculus is really explained from first principles, right? Like you’re given formulas for, this is how you calculate the rate of change of this particular function. But it’s like, it’s just a rapid fire of formulas that you’re gonna forget if you’re not applying it day to day, within like 6 months of— And so, yeah, the approach I’ve been trying to take in the book is, and so, The problem, like the further problem with that is that all the electrical engineers are taught the theory in a specific way and they kind of assume that the complexity is essential to the explanation, right? So if you go to Wikipedia or you go to Stock Exchange and you just want to understand why the formula for the reactance of a capacitor or the frequency response of a filter looks this way, the answer is you know, kid, like, learn some calculus and come back, right? And I don’t think you actually have to do that, right? Like, for sine waves, you can do all of, like, you can derive all of this from basic trigonometry, and it’s going to take you a bit longer. And, you know, there’s going to be more triangles and circles that you have to draw. But you kind of just need, like, you know, middle school, early high school foundations. To explain electronics. So I think, you know, there’s a distinction between essential complexity and the complexity that makes sense and is expedient in a college setting, but doesn’t really make sense for hobbyists. And so I’m trying to aim for that middle ground. And it’s been a wild ride and a lot of triangles and like almost 300 hand-drawn illustrations and diagrams and yeah.

Thomas: I haven’t asked you specifically before, but I get the sense that you have most of the math already. So I was like, is the work here going from like, I can metabolize this stuff because I have, you know, like complex calculus and all that, right? To like translating it down or like, is this literally you trying to figure this out as you go?

lcamtuf: No, no, no. So I think, you know, you know the answer, right? And you sort of, you know, start from that point, but it’s actually— Sometimes when you force yourself to explain something simply, you realize, actually, you know, do I really understand this? Like, you know, why is it the way it is? And how do you convey that in a way that makes sense to a person who, you know, hasn’t read the same books, right? And hasn’t gone down the same rabbit holes. So it is a bit of both, I think, you know, like, trying to explain is when you realize that you don’t know certain things.

Thomas: And Yeah. Yeah. For sure. How far are you into the book now? I saw like 420 pages. Have you written 420 pages?

lcamtuf: Yeah. Yeah. It’s all done. It’s like, you know, with the printer right now. So yeah, you can preorder and get a free PDF today and it’s going to be like the entire book. And then it’s going to ship in September, like physical copies. It’s going to be full color and hardcover. So like really, really fancy.

Deirdre: Will there be copies at the NoStarch booth at DEF CON or Black Hat or whatever?

lcamtuf: I would expect so. Cool. But, you know, like, I’m not in charge of their marketing, but they usually bring all the new stuff.

Thomas: It would be a funny role for you to take.

lcamtuf: Yeah. They actually always try to rope me in. They ask, you know, are you going to DEF CON or Black Hat or whatever? And my answer is always no, thank you. I went there like, you know, 20 years ago on the Good enough.

David: Will it teach you how to calculate the equivalent resistance between two resistor nodes that are a knight’s move away in an infinite grid of ideal 1-ohm resistors?

lcamtuf: So that’s the thing, you know, there’s a lot of things that we teach to people just to torture them, I think, right?

David: Or in some cases to be hit by a bus in an XKCD comic.

lcamtuf: Yeah, and I think, you know, there’s also a lot of things that we teach in a particular way for historical reasons, right? Like if you buy an electronics book, there’s probably going to be a chapter about things like tunnel diodes that, you know, no one has made commercially since the ’70s. And you can, you know, buy some Russian surplus on eBay, right? Like if you really want to, or how to wind your own transformer or stuff like that. And no, and And the book is not going to be spent, or like, you know, like, you usually start with NPN or BJT, like, you know, bipolar junction transistors, which are kind of not exactly obsolete, but they are more complex than the more common and more modern field effect transistors, which is what you actually use everywhere, right? In digital circuits and power switching and so on. So I’ve been trying to step away from that as well and like really focus on modern problem solving. And that means that, you know, if you want to build an oscillator, you’re probably not going to be putting together individual transistors. You’re going to get a microcontroller that costs like, you know, 50 cents and program it to output whatever waveform you want, right? And if you want to change the frequency or whatever, you can just upload new code. So I think there’s a lot of stuff like that. In the book, just trying to keep it practical and not torture people with math or theory just for the sake of it. It’s just the things you really need, or, you know, the things you need to know to make sense of Wikipedia articles or college textbooks down the line if you really need to investigate a specific thing.

David: Well, that’s very cool. Thank you. Thank you for coming on. Thank you for telling us about the book. Thank you for letting us interrupt you while you talked about AI bug finding for like an hour before talking about your book.

Thomas: Okay, cool.

David: We appreciate it.

Thomas: Okay, cool. Thank you. I mean, so much for this is, this is, this has been, um, a very fun conversation. Yes. Even though I think that vulnerability research is gonna matter more than you think it will. Uh, I am super psyched for the book, although I’m a late in life math student, so I’m actually psyched about the math parts of it. But still I’m unbelievably terrible with electronics and I did not realize I could, I did not realize I could download the whole book right now, which is awesome. So that is The Secret Life of Circuits. That is Mikhail Zelensky’s, Zelensky’s, get it at some point, new book. Everything else he’s written, we used to give copies of The Tangled Web, which was your second book.

lcamtuf: Yes.

Deirdre: Which I have right here on screen. To every candidate that applied at Montserrat.

Thomas: Exceptionally good writer, very fun to read. So yeah, look, thank you so much for doing this. We really enjoyed talking to you.

lcamtuf: Thank you. And you know, after the Volnpocalypse, I’m happy to come back onto the show and you can tell me how wrong I was.

Thomas: You’re a prepper. That was your third book is about like preparing for the— it was about preparing for the Volnpocalypse. So I’m sure you’ll be ready. We’ll come to your place because you’ll have water stockpiled for us.

lcamtuf: Yeah, I have an excavator. So, you know, You don’t actually have an excavator, do you? I have an excavator. I have a tractor. I, you know, I’m all set.

Thomas: You’re buying all the equipment that 2-year-olds were really fascinated by. You have the means now to buy the real-size Tonka trucks.

lcamtuf: Yeah. The trick is you publish a book to make it look legit and then you can buy whatever.

Deirdre: Okay. Well, when the Volmpocalypse comes, we’re running to your compound. You already invited us. You can’t take it back. Security Cryptography Whatever is a side project from Deirdre Connolly, Thomas Daczek, and David Adrian. Our editor is Nettie Smith. You can find the podcast online at SCWPod and the hosts online at @durumcrustulum, @tqbf, and @dadrian. You can buy merchandise at merch.securitycryptographywhatever.com. If you like what you’re hearing or seeing, give us a 5-star review wherever you rate your favorite podcasts or videos. Thank you for listening.

Thomas: I can’t believe he has an excavator. I can’t believe he has an excavator.

AI Finds Vulns You Can’t With Nicholas Carlini

Wed, 25 Mar 2026 00:00:00 +0000

Returning champion Nicholas Carlini comes back to talk about using Claude for vulnerability research, and the current vulnpocalypse. It’s all very high-brow stuff, and the gang learns some bitter lessons.

This episode was recorded on March 19, 2026.

Links:

David: Sounds like a really bitter lesson to learn.

Thomas: Yeah, I was going to say it’s terrible. It actually is terrible, right?

Nicholas: Yes.

Thomas: All of the fun problems are gone.

Deirdre: Hello and welcome to Security Cryptography Whatever. I’m Deirdre.

David: I’m David.

Thomas: Thomas.

Deirdre: And we have a set special guest today. Our returning champion for vulnerability research, I think, Nicholas Carlini. Hi, Nicholas.

Nicholas: Hello.

Deirdre: Hi. We had to have you back because you, I think you wrote a blog post that Thomas was giddy over and basically saying how vulnerability researchers who once were able to find a bug class and then point their guns at software, crank the handle, and get lots and lots of vulns out of it by trying to find instances of that bug class are now gonna have to work a lot harder to crank that handle. Can you tell us a bit about what you wrote?

Nicholas: Or less, or less so.

David: Yeah, go ahead.

Thomas: But like, just before we jump in, right? So, I don’t know, like 2 weeks ago, 3 weeks ago, there was like a security nerd conference about AI and security called Unprompted. Um, I was like on the program committee for part of it, but I did no work. My name should not be on there at all. It was, I had life stuff going on, but, uh, Nicholas presented, um, some of the same stuff from like this, from this, like there was this Anthropic Red blog post from February, I think, um, which got like a lot of coverage because it claimed to have generated 500 zero-day vulnerabilities, which is a, um, you know, kind of a grabby stat. And then Nicholas kind of presented some of the same work at Unprompted, um, and it kind of really lit people up. So I’m really psyched to kind of have a conversation about that whole space of stuff, Nicholas, that you’ve been working on. And, um, we, me and Deirdre have not done a great job of introducing it.

Nicholas: Yeah, I’m sorry.

Thomas: So, so I’ll let you, I’ll let you take it from the top, just kind of what, what you’re, what you’re kind of working on, and then I’ll drill into it.

Nicholas: Yeah. Okay. So the basic setup that we’ve been trying to understand is how bad is it going to get when you have these language models that are getting increasingly capable and they are now able to be used to try and find vulnerabilities and potentially exploit them. And so the reason why I’m curious about this, yeah, I don’t know, many years ago I used to do pen testing stuff and this was like the thing that got me into security in large part. And, uh, for a long time when I was doing security in machine learning, the only thing you could do was you could attack the machine learning models because like they were too dumb. Um, but like, I don’t know, within the last like year or so, 6 months, the models have gotten good enough that you can do security, meaning use the models to help you with security. And so the thing we’ve been trying to understand is, yeah, what, what can you do? And it’s been growing from basically very, very little to, yeah, as of last month, a couple months ago, like you can actually use them to find real bugs that people care about in the world. And so we’ve been trying to understand both where things are right now, but maybe more importantly to me, you know, where things are going in the near future because the models have been getting a lot better and this, like, I see no immediate end in sight in like, let’s say the next 6 to 12 months. And so I’m like trying to understand like what are the bugs we’re able to find now? And then can we like try and roughly extrapolate what we’ll be able to find in 6 months or 12 months?

Thomas: Like a couple of different places I kind of wanna go with this. The first thing though is like you’re saying like there’s been improvements to the models lately such that they’re now able to find vulnerabilities. But like for people that were, you know, kind of building pen test type tooling before and were also using like the responses API or any other API for any LLM, like it’s been possible to use an LLM to find vulnera— to find real vulnerabilities for quite a while, right? Like, um, if you have like a harness set up for it, like if you have the right set of prompts for it and like whether or not it like, it one-shots a vulnerability for you, it will give you essentially, it’s been like for probably more than a year, um, like LLMs have been a reasonable way to get enough information to get like a really strong hypothesis about a vulnerability somewhere, right? What’s, what’s the difference between that, like the status quo ante and where we are now with the stuff that you’re talking about?

Nicholas: Yeah. Okay. So yeah, so even like, um, you know, Google DeepMind has had a project looking at doing this for a long time. Uh, OpenAI had announced something like 7, 8 months ago looking at this. Yeah, this is definitely a thing that if you tried hard, you can definitely get the models to find bugs for you. The thing that we’ve been finding most recently is you don’t really have to try very hard. We have, I don’t know, let’s say, 10-line Bash script plus Docker container. I just sort of point it at the thing and be like, I’ve compiled this program with ASan. Please run against it, read the source code, and try to find a bug. That makes ASAN trigger. And depending on which program you’re looking at, sometimes more often than not, it comes back to you with an input that makes ASAN trigger. And this is not always a problem. Sometimes it’s just some stupid, it’s now gonna read from null or something. But every once in a while it gives you a much worse version of this. And if you ask it nicely and say, please disregard all of your null pointer dereferences, then it’s even more likely to find something that’s important for you. You don’t really have to put in a huge amount of work, which is both good and bad. It’s nice because it makes it easier to find a lot of bugs. But in a world where the only people who could find these bugs were the people who put a bunch of work in, there was some barrier to entry and it’s not the case that just any random person could ask it to find a bunch of bugs for them. There still is a lot of work that you as a human have to do. But again, rate of progress. Previously had to like fancy scaffolding and now you could just like open up, you know, Claude code or Codex or whatever and just like point it at something and say, find me a crash and it more or less will succeed. And this is getting, um, you know, only easier.

Thomas: Okay. So like the, the headline from like the blog post and presumably the talk is like this 500 vulnerability, this 500 zero-day vulnerability thing, right? So there’s like, I’m kind of inferring from that, that there’s like a discrete project inside of Anthropic to like find a bunch of vulnerabilities. So like, I guess one thing I’m really curious about is what that project looked like, who that project was, who was working on it. How’d you guys pick targets? Like what, what was the project internally?

Nicholas: Yeah. So there are a number of things that we’ve been doing. That was the result of a somewhat old project where we took OSS fuzz and instead of running fuzzers, on the, you know, the harness endpoints. We like ran a language model and said, you are a fuzzer, you know, your job is to find an input that triggers ASan, you know, where like now, like you’re instrumenting right into the middle of whatever the thing is at the ASan point, sorry, at like the fuzzer point and like trying to trigger some crash, which is useful, but like, It has some problems. Lots of times you find things that can never be triggered from the real code. There are some harnesses for OSS fuzz that have bugs in them. And so you find occasionally the model will find a bug in the harness. It will just constantly return to you. In the JavaScript ones in particular, there are some that you can basically escape your way out of the JavaScript string. And when you’re being called into V8, we got a bunch of fake-style JavaScript bugs where it was actually just escaping the harness and then just crashing the outside program. But okay, yeah, so there’s various program reasons why this is not perfect, but this is the first thing that we started with because it’s about the simplest thing that you could look for. And even in this, we found a huge number of crashes that are like, yeah, heap buffer overflow writes, various things that are very harmful. And the other reason why we picked this is we were looking for something that people could say, or they couldn’t say this is random code that was untested. We wanted code that OSS fuzz has tested this for a very long time. We have found crashes in this code that is different than what the fuzzers found. And it’s not the case that we’re the first person to have ever looked at this. This is why what we found is at least marginally interesting. Now the models have gotten a lot better since then. And so now we could just Recently we’ve just pointed them at the Linux kernel and be like, find crashes for me and it succeeds. And so this has gotten a lot better, but the initial thing that we started with the 500 bugs was mostly from OSS-Fuzz.

Deirdre: And you’re pretty sure that it’s the model is doing whatever it thinks emulating a fuzzer is rather than calling out to a fuzzer or whatever.

Nicholas: Yeah. Okay. Yeah. So we don’t actually literally say you’re a fuzzer. We actually say you’re playing in a CTF. The goal is to trigger ASAN, but we do this in part so that the model doesn’t refuse. But, okay. So why are we pretty sure it’s not just calling out to a fuzzer? Because presumably this is part of OSS-Fuzz. If calling out to the fuzzer was all you had to do, then we would’ve been found before. And so this is the main thing that we’re relatively sure there. But also we just have been reading a bunch of the bugs and you could just look at the traces and it’s just very, very clear. That the things that it’s finding are not the like, you know, fuzz sort of found findings. Cool.

Thomas: You guys, you guys do not have a special model where you don’t have to pretend that you’re in a CTF for.

Nicholas: We, we’ve just been using the production model that everyone else in the world has access to. Yeah, I mean, we get the model a little before everyone because, you know, we’re training it. But the model that we were using has been deployed.

Thomas: How, how focused are you on memory corruption in this work?

Nicholas: Yeah. Okay. So initially we were very focused on it because it gives a very, very nice oracle, right? Like, if I sort of have a copy of the program running in a separate VM with the compiled with ASan, and then the first model gives to me a binary and I give it to the other one and I run it on there. And if the other one crashes with the binary on with an ASan crash, then I’m like, okay, great, this is a bug. And so we did this. We, for example, we ran this on Firefox with Opus 4.6 and we sent Mozilla 122 crashing inputs and like they confirmed all of these are bugs. Like 100% of the things we crashed them, perfect true positive rate, all bugs. Because we have a perfect crash oracle and they’re sort of competent security people who understand that if you have an input that’s crashing ASAN, like you should, actually treat this as something that’s worth looking at. And so like they, they sort of treated them all as bugs. Now some of them were not, you know, high severity sort of potential escape vulnerabilities. And so they triaged, I don’t remember exactly how many, I think it was 22 total of them got CVEs that because they thought they were like bad enough. And so the rest were, you know, crashing inputs that were, are bad, but, um, are not like immediately, it’s not immediately clear how you would exploit this. And so they didn’t triage these as, high severity vulnerabilities that need CVEs. But like, this is why we started with memory corruption as the thing, because you can get this very, very nice oracle. We’ve since additionally tried to do other things that don’t have such a nice oracle. So somewhat recently I pointed it at a bunch of content management systems and have been finding— such as? Okay, so the best one that we have is an example. There’s this project called Ghost. Which has, I don’t know, it’s like 50,000 stars on GitHub or something.

David: Oh, so like, yeah, it’s like WordPress but in Node.

Deirdre: Got it. Okay.

Nicholas: Yeah.

Deirdre: So literally like CMSs, but yeah. Okay.

Nicholas: Sure.

David: Yeah.

Nicholas: It was like standard web apps.

Thomas: And Ghost is an important target. Like there’s a lot of people running Ghost. Yeah.

Nicholas: Yeah.

David: I used to run Ghost and I was paranoid about running it and I put its login behind an additional OAuth2 proxy because I was very worried about it.

Nicholas: Yeah. Yeah. So Ghost was actually pretty good. So Ghost in the history of the project on their, like, you know, security tracker has never had, like, a critical severity bug before. Before. Before. Yeah. And then Opus 4.6 found one. And so it found a SQL injection that goes, nice, an unauthenticated user who has literally no perms, who can compromise the admin database, mint themself a new admin account, and then log themself in and yeah, complete complete account takeover. And it was like, so not only did it find the vulnerability, it also wrote the exploit, which was like a non-trivial blind SQL injection where you only control some parameter after a WHERE clause. And so you can’t actually do things. You can either parse or not parse invalidly a JSON object. And so then you have to see whether you got a 500 or a 403, and then you sort of do some binary search to read out the keys, it wrote the whole thing for me. And yeah, it was quite a bad bug. But yeah, this one we didn’t have a grader, so it was a little bit harder to do. But the models have gotten good enough that most of the time you can just have them write a report and then you have them read the report and you ask, here’s a report that I received from someone. Is this real? Can you go and replicate this on the thing or not? To separate instance of the model. Then it will go off and say, here’s the following flaws that I found. I don’t think it’s quite as real. We run this critiquer over all of them. Then after that’s done, then we look at the highest severity ones ranked by this critique agent. Then we filed a couple of these ones that were the highest severity. This isn’t as perfect and clean as an oracle. We’ve been doing this only more recently once the models have gotten good enough that we can trust them for this. But I think it’s highly likely that the world is going to move more and more in this direction where you can just trust that for the most part, most of the time, the models are good. But again, these ones we are very, very careful to manually review all of them. I have walked through the trace of myself. I spun up the thing because I’m still very paranoid the model is just going to lie to me. I don’t want to be the person generating AI slop. This will be very bad.

Thomas: Like we can, yeah, we can let you off the hook for having to hedge about this for the rest of this whole time, right? Like we assume that you’re like, you know, you’re verifying things before you send them upstream and all that. I wanna lock in on like the methodology here. So, so with the, with the ASAN builds, with the memory corruption oracle, it’s kind of easy to see how you would kind of build that out. Like intuitively it’s like you also have like giant fuzzer farms that produce crashes and like the, the li— like the limiting reagent there is how much time people have to go verify all those dump crashes. And you have kind of infinite ability to verify crashes and that wall. And that’s not, I get the impression that’s not actually what you’re doing. Like really, like OSS fuzz is just kind of like a, it’s itself a harness to give the LLM access to, you know, the code and the environment and all that. But like, I assume it’s predicting vulnerabilities from code as well as from behavior, right? But you have like a, you have a really good, you have both a really good oracle for knowing when you found a vulnerability, but also like, um, it knows how to find the memory corruption vulnerability, like the space of different, like C and C++ vulnerabilities. Like they’re interesting vulnerabilities and they’re very corner casey. There’s lots of bank shots you have to take to get them to work and all that. But the core idea of the vulnerability is simple. There aren’t that many of them, right? Which is not the case for a CMS. So my question is, when you’re doing something like finding a SQL injection in Ghost, right? How much prompting are you giving it about what a SQL injection is?

Nicholas: Zero. Yeah, again, so like we sort of, I wrote a single prompt, which was the same for all of the content management systems, which is, I would like you to audit the security of this codebase. This is a CMS. You have complete access to this Docker container. It is running. Please find a bug. And then I might give a hint. “Please look at this file.” And I’ll give different files each time I invoke it in order to inject some randomness, right? Because the model is gonna do roughly the same time each time you run it. And so if I want to have it be really thorough, instead of just running 100 times on the same project, I’ll run it 100 times, but each time say, “Oh, look at this login file, look at this other thing.” And just enumerate every file in the project basically. I’ll filter out the files that are header files or okay, it’s whatever in Node. So it’s not header files, but I’ll filter out the files that have obviously nothing interesting going on in them and then just give it the files that have plausibly security-relevant code. And again, I use a language model for this. I run it over all the files. I say, rate on a scale of 1 to 5, how likely is this file to have something interesting in it? And then it just like discard the ones that are 1s and 2s and then I keep the 3, 4, 5 and then I just run it on this and say, please find me a bug. And yeah, sometimes it gives me SQL injection, sometimes it gives me, you know, login bypasses, sometimes it gives me XSS, sometimes it gives me CSRF. Yeah, just like, it knows what all the bugs are.

Thomas: Okay. And you’re literally automating Claude here, like the CLI Claude, you’re not driving the API.

Nicholas: No, I run Claude code, you know, you can run Claude code in a mode, dangerously skip permissions, which means just like, don’t ask me for anything. You can do whatever you want. I give it a prompt. The prompt is, yeah, I don’t know. It’s like maybe in practice 30 lines or something. I don’t know what the prompt says. I didn’t even write the prompt. I asked Claude to write the agent that finds the bugs and just like, you know, I just told it what to do. And then it goes off and runs until it finds something and then it writes a report. And then I run these critique agents on all the reports. And then at the end of the critique agent, I ask it to write a CVSS score, which are fake, but it’s good enough that I can just grep for CVSS 9876 and then just find stuff and then go through them. Okay.

Thomas: So when you, in this kind of contraption that you’ve set up here, right? Like, are you, it sounds like you’re doing multiple runs against Ghost, say, like, and like those runs, like most of them don’t pay off. Like you just keep doing it until you get— Yeah, right.

Nicholas: I mean, like, yeah, I, I run it for almost literally every file in the program and the project set that has something interesting. I then try to have each one write a report and I tell the model, maybe there’s nothing here. If there’s nothing here, just write no findings. Then I run the critique agent over all of them. A good model most of the time will tell you no findings and then it will find a bunch of some things. Sometimes it turns out that it’s like the most common failure mode is early on in the session, the model adds some code to some debug thing that gives it a bypass so that it can log in without permissions. And then later on, after it’s compacted the summary multiple times, context window is cleared 5 times, it finds a bug which it added a while ago and is entirely fake. And then it’s like, oh, I found something. And then you have the triage agent run and the triage agent runs it on the clean image and it’s like, what do you mean? This is clearly not a bug and it will remove it. And you end up with a bunch of these kinds of things.

Thomas: But there was, I’m asking this because there was last year, I think in the middle of last year, somebody wrote a blog post about how they had found, I think it was Linux I think it’s called WiFi or something. They found a kernel vulnerability using, I, I forget which model it was, right? But like for, for me, like the nut graph of that piece, like the core of that piece was like they were running it thousands of times, right?

Nicholas: Oh, right.

Deirdre: Yeah.

Thomas: They’re burning like a zillion. I don’t, by the way, I don’t care about how many tokens you’re spending. The whole token economy thing seems very silly to me, but like they’re running it, they’re running it a thousand times and like one of those runs pays off with something actually interesting, right? Is that, is it a similar situation for you or are you just iterating over the files and that’s the only iteration that you do?

Nicholas: Yeah, so I’m just iterating over the files. It’s definitely not 1 in 1,000. I don’t know what the exact rate is, but you know, okay. Like of course there’s a spectrum of—

Thomas: Each time you, each time you, each time you give it a new file to look at, right? You’re really just giving it a new entry point into the code, right?

Nicholas: Exactly. I don’t even force it to like read that file. There’s no constraint. Like there’s like literally a line that’s like, you know, please look at, and then I, you know, bracket, you know, file name, end bracket. And then in Python I just like, you know, format this and like plop in whatever file name I want. And like this gives it an entry point to like, you know, launch off looking from there. And sometimes it finds a different bug somewhere else. But yeah, I, I don’t do any like fancy stuff here.

Thomas: I’m stuck on like, so first of all, I said there is like, there were some screenshots of the presentation that you gave it unprompted and like one of them, that, um, that got posted and people were like, liked it or whatever. It’s just that you believe that Claude is a better vulnerability researcher than you are. And I worked with you in the past and I already knew that Claude was a better vulnerability researcher than you were. But, um, but there was also like, there, there was like, there was the— Nicholas wrote all of the good parts of MicroCorruption. Um, Nicholas is much better than I am. I, I’m saying I’m really, really bad, but like, um, there was another slide which I actually found dispiriting, which was just like your, your, like the slide where you’re kind of talking about the methodology is just you showing Claude dangerously skip permissions, find me a zero-day vulnerability, right? So like that by itself is surprising to me. And like as a nerd who wants to like look at this thing like an analog synth with lots of different things to plug in together and lots of cool toys to do, I’m a little bit disappointed that there isn’t more room for little, you know, making little toys and I’ll get back to that. But also like this whole idea of, so each, each iteration that you’re doing over the files, which is just like, giving it a little hint, maybe start this like here this time and maybe start there next time, right? So essentially you’re just kind of randomizing, like what you’re really doing is just like doing like a randomized like start-freeze thing. Why do you ever stop?

Nicholas: Uh, as there are more things in the world to attack. Okay. But like, yeah.

Thomas: When, when you’re done with that loop, do you feel very confident about the security of say Ghost?

Nicholas: No. Yeah, so if we run this over the loop once, we, so okay, so when we found the 500 bugs in a bunch of OSS things, OSS fuzz things, I think we ran over every project, sorry, over every entry point maybe 20 times or something just to be even more thorough. And there are some entry points that we only found bugs 2 outta 20 times. And when I run over, so eventually I ran over the Linux kernel. When I did the Linux kernel, I ran over every file in the kernel that I thought was interesting and reachable from user space and whatever bunch of stuff, maybe like 5 or 10 times. And there are like sometimes where like it finds a bug and sometimes where it doesn’t. And so like, I don’t have like a very nice like scientific plot yet on like, you know, extrapolating where this is going to plateau. But the main reason why we stop is because there’s enough software in the world where after we’ve run it a couple times, we’re like, okay, we’ve sort of gotten a bunch of bugs here. Let’s move on and try and not spend all of our time on exactly one piece of software and distribute it amongst all of them. There’s enough code in the world that you could do only one pass over each project and be running for a very long time.

Deirdre: Do you have your own homegrown spidey sense of being a vulnerability researcher about which files you’re like, all right, you’ve given it a pass or two, but like, I really want you to do like 5 or 10 passes before I feel comfortable moving on. Or I feel like you’re not going anywhere.

Nicholas: Yeah. I, I probably could, like if I went and looked at the files individually, I could probably do this better than the model still a little bit. But like, I don’t, um, like I just like pointed at the project and just be like, find me things. The reason why is just the scale is enormous. It’s like on the slide of, I said the models are better vulnerability researchers than me. It’s not the case that if you gave the model a very small piece of code that was self-contained and 300 lines long and I could reason and it could reason the same amount of time on that piece of code, I would win. I’m still more intelligent than the model, but what I can’t do is analyze literally every program or every C file in the entire Linux kernel and try to find bugs. I will spend most of my time having a really good intuition about where to look, but the model doesn’t need the intuition. It could just look everywhere. It’s something so much faster and cheaper that half of its work will be completely wasted ‘cause it’s looking in drivers that aren’t even loaded. And fine, that’s fine. We waste that. I will just go look at the points where there is actually something to be found. Eventually, and then it will come back with interesting bugs that have been dormant for decades.

Deirdre: Even for the short ones, I feel like you both can achieve the same result, but I feel like the model might be able to do it faster than you.

Nicholas: Well, certainly they’re enormously fast. Yeah, especially like Thomas, you were saying, the model, there are only so many classes of bugs. I don’t know, security people like to think of themselves as brilliant sort of whatever people, but I don’t know, honestly, it’s just like there’s some amount of just like, you need to know what the classes of bugs are that people have found. And like 90% of doing vulnerability research is like, okay, let’s like pattern match this on the thing that we’ve seen before. And like there’s differences every single time. But like you can imagine that like if you had read all of the code on all of GitHub or something, then like you would be very, very good at pattern matching against whatever the use-after-free pattern that this one in particular needed.

Deirdre: Yeah.

David: So, like, I wanna get back to whether or not, like, oh, you switched to a new thing because there’s like so many things to look at. Um, but also we’re in like, we’ll just like find something to pattern match on and we could in theory just like keep pattern matching until it’s gone. So like, I kind of remember when like fuzzing, it wasn’t, wasn’t new, but like OSS fuzz was new.

Deirdre: Yeah.

David: And like, uh, uh, like some people like popped out like, you know, let’s say like 10 CVEs in every single codec for like a year in like 2015.

Nicholas: 2016 or something.

Thomas: I don’t know.

David: Um, and then everyone was like, wow, this is amazing. We’re just going to fuzz all these things. And like fuzzing found like 10 bugs in every single library. And then like people kept running fuzzers for years and those like OSS fuzz, like, like you said, it like doesn’t find a whole lot of new bugs. Like there’s definitely like people working at offensive firms that like figure out a new way to jury-rig up a cluster, uh, a cluster of ones to fuzz like some in slightly new way. It pops out 10 bugs. And it doesn’t find anymore. Um, or like people who build careers doing that to submit to bug bounties. ‘Cause it’s just like, it, it turns out it’s like, it’s not actually enumerating the bug space. And it’s also far, far easier to like jury-rig some fuzzer for like a month than it is to like run it consistently over time. So like, in terms of cost-benefit analysis for defenders, it’s, it’s like helpful, but it’s, it’s not exhausting the space.

Nicholas: Mm-hmm.

David: But also we don’t necessarily see like a ton, a ton, a ton of like fuzzing bugs, like 10x, you know, every month. So when it comes to like bugs found by, uh, like agents again, or, or tools like Claude Code, like you can throw it at like some files and say like, find me bugs. And then there’s a round of that. And then people can jury-rig it up a little better to find more bugs. But like, do you think that we could exhaustively like actually make a piece of software more secure in the sense of like, we removed a bunch of the bugs and like, if we all run these agents for the next 2 months, like we’ll have found all of the bugs that agents are going to find aside from the margins, and it will go back to like, there are 10 people in their basement submitting the bug bounties and what are the tools they have as agents? Or is there an infinite plethora of bugs? Like, there’s something to be said about the population of bugs and then like how these agents are finding them. And like, are we approaching zero or yeah.

Nicholas: Okay. I think it’s a very good question. High-level answer, I don’t know. I think, yeah, I wish I knew the answer. This would be great to know, but yeah, not yet. Okay. Yeah, me too. Jesus Christ, that’d help a lot of work. Yeah. Okay. Yeah. So first answer is that even if it was the case that you could exhaust all of the bugs with one specific language model, it’s still the case that these models are getting a lot better over time. And so you can imagine a world where we exhaust all of the bugs that can be found with, you know, Opus 4.6. And OpenAI comes out and releases GPT-5.4, which they did, I don’t know, whatever, 2 weeks ago. And then like maybe this one finds a bunch of new bugs. And then Google comes around and releases Gemini. Let’s see, they’re on 3.1. So they released 3.2 and this one like finds a bunch of new bugs. Like, so you could imagine a world where even if you could exhaust all the bugs with one model, like we’re still in this increasing exponential capabilities. And like it seems likely to me that we will be stay there for a little while longer. So there’s this aspect of it. And then the other aspect is, I like to think of this as like, okay, so fuzzers find a restricted class of bugs that are fairly easy to enumerate. And so it’s fairly small, the attack surface is fairly low. And this means that once you’ve probed it a bunch, you can sort of have hardened that shell. As you get better and the models are able to find, attack a larger attack surface, you have to do more work to exhaustively find all of the bugs that can be scanned in that surface. And each time the models get better, the space of attacks grows again. So now that we can have pretty good bug finding without Oracle that gives you ASAN crashes, this gives you another attack surface that you can start to measure against. And I think that each time you do this, you have to do more work to make sure that you’ve done like, pigeonhole principle, whatever, like you need to have done a huge amount of work in order to make sure you’ve found all of the bugs, even if they were finite. And each time that you increase the surface, it gets even harder. And so this is maybe my other concern is it may be the case that it’s finite, but you could imagine that, yeah, the more powerful models might have a bigger surface to hit between.

David: Really? And so getting back into that, like, for the Firefox example, then, like, do you have like an estimate in terms of even if it’s finite, like not getting there, do you have an estimate to how much time it took Firefox engineers to patch all, what was it like 50 bugs or whatever it is? Relative to how long like Claude ran, um, to find, and then even for, for say you to validate, um, let, let’s include the time that you or anyone else at Anthropic spent validating the bugs. Mm-hmm. Um, relative to how long it took Firefox to, to patch them. And then not to like knock on like, not like if Firefox shelves some of them, like let’s not count that time. Just like actual time spent by engineers trying to patch these things.

Nicholas: Yeah. So I don’t know exactly how much time Firefox spent. Um, the bugs that we found there were found by one person, Iftikhar, who, yeah, was working for, I don’t know, not more than a month on some harnessing, probably a couple weeks. Probably most of this was reusable work because like, I don’t know.

Deirdre: Okay.

Nicholas: Some people—

David: Yeah, it takes a while to rig a browser, but once you’ve done it once, it’s copy and rig.

Nicholas: Yes. But some, like, he sort of did it properly and like hooked it up into the Anthropic infrastructure in the right way. I sort of do some things just like, I don’t know, I just turn on a bunch of Docker containers on the same machine. I go grab a machine with 100 cores and just call it a day and just run it over a weekend. Other people do actual engineering and make it properly distributed. He did it that way. So it’s like a reusable infrastructure that if he wanted to spin on something else, he could do that. And so, I don’t know how much of the work was on this, but it was not more than a couple weeks of work. To like harness the whole thing up. And then yeah, we like let the models go and churn for a while and then we sent off the bugs. So yeah, I think we sort of got most of the bugs that we could find with, with Opus 4.6. But like, I don’t know, my guess is if we were to run it for the same amount of time, we’d come up with a couple of more. I don’t know how many, we should probably have some numbers here at some point. I’m hoping to try and run some like science-y experiments, like measuring these curves over time. But like, we don’t have that quite yet. It’s like still, yeah, very early.

Thomas: Mm-hmm.

David: But so we can probably then like at least estimate on the short end, you spent, let’s say 2 weeks and then let’s say each bug took an engineer day for Firefox to patch of, of those 30. And so that’s at least like roughly 2x the engineering time to fix the bugs than it was to find the bugs. And that’s including like reusable engineering time.

Nicholas: Yeah. Also then like the, it’s like just legitimately harder to patch than it is to find these.

Thomas: Yes.

Nicholas: Because like you can’t make functionality, like you can’t just like, like the, the model Oracles are great because finding crashing inputs gives you the most perfect oracle. But if someone wants to fix it, you have to understand first how it happened. Actually, as a sort of aside, language models are actually very nice because while they don’t always give you a perfect explanation of what went wrong, it’s so much easier than, “Here is a fuzz crash.” Just like, “Here’s some binary.” The bugs that we have come with Python programs that generated them. And so like, even if you, like, it sort of misunderstands why, like you can at least like, okay, so, so it’s a little, they, they, the Firefox people found it a little bit easier to actually fix these than like normal fuzz crashes. But yeah, like they did have to spend quite a lot of work on like, you know, making sure that what they’re going to submit is not gonna like break some user functionality. And so I think this is one of the asymmetries here.

David: And you were kind enough to give them effectively 100% valid bugs. Uh, ‘cause another approach could be to just use the bug bounty as an additional oracle, um, uh, to help with, with, with the—

Nicholas: and some people in the past have, have tried this and have gotten many people mad at them. And yes, we are trying very hard to not have—

Deirdre: also the latency on that oracle is pretty, pretty large.

David: Like from, from Chrome side, like relative to February 2024, David eating his feelings here. 2025 had 5 times the submissions. Um, and then March of 2026, today’s the 19th, already has, um, over twice as many submissions as the entirety of February did. Um, and you know, some of that is our own like damn fault for, um, uh, basically being particularly like lenient and nice for years. Um, because that was like You know, what we, uh, um, there’s just the way that the Chrome VRP has been known for, like, being very easy access to get to engineers. And so, um, but, uh, yeah.

Nicholas: Firefox saw the same thing. Mozilla had a plot, um, where they, like, showed the number of bugs that were found, um, over time. And yeah, so, like, we found, I think it was, like, 20-something, which is, I don’t remember what the exact number was, like, 25% of all bugs that were found in last year, we found like in one, like in one batch of reports. But what you like, many people didn’t notice is like this, this chart had like two bars stacked on top of each other. There’s the ones that we found and the ones everyone else found. And it, the bar was like a lot bigger because we found many more. But if you remove all of the bugs that we found, last month was also the biggest month that they had seen in like the last two years.

Deirdre: Oh, right.

Nicholas: And so like, I, I can’t, I mean, I have no inside information on, on, on Firefox. But it’s like, I can’t sort of tell you that this is causally related, but I don’t know. It’s, it seems plausibly related.

David: It’s happening at every bug bounty, right? Yeah.

Nicholas: And, and, and this was like, to be clear, like the, like these are the real bugs they got CVEs for. And so, you know, like the, the numbers on submissions I’m sure are going up, but like the number of outputs is also going up.

Thomas: Yeah. I think like bug bounty incentives were always kind of weird to begin with. And these programs are all kind of like, they’re all in a, and I guess maybe except for Google, they’re all kind of ad hoc. I don’t worry that much. About like the long-term impacts on bug bounty programs that people just iterate and come up with better bug bounty terms and stuff.

David: There’s some of that, but also like, I, I don’t worry too much about bug bounties. I worry about the people at bug bounties on like large platforms and browsers, like in the, the sort of near term. Um, but I, I think like it was actually Jeff Belknap who used to work for you, Thomas, I think, um, when he was CISO of LinkedIn, like over 10 years ago, I think he was, he gave this talk that was like, bug bounties are stupid and you should stop running them. Like the only people that run, that should be running bug bounties are basically platforms. Are you an operating system or a web browser or like a phone vendor? Sure, run a bug bounty. Otherwise, or like, are you running other people’s code? Maybe run a bug bounty, but otherwise, like, get over yourself. You’re, you’re just like wasting time. And I feel like everyone’s just gonna come to that, that, that realization, like curl did it. Is a notable example, but like everybody that’s not huge is gonna shut their bug bounty down. And then the big bug bounties are all gonna be much, much more strict about what they’ll accept.

Thomas: Yeah.

Deirdre: Just because of overload?

David: Yeah, because it’s very easy to generate a, a reasonable looking bug report now. And that might be wrong. Like previously, like how well you format, did you follow the format? Did you submit the requested thing? Was it fully filled out? Was like a good proxy for are you reasonable? And now it’s not.

Deirdre: Whether, whether some human should invest their time actually validating it and testing it and trying to reproduce it and coming up with a patch. Yeah.

David: You’re also gonna see more of like, yeah, you’re not allowed to give us a bug that isn’t basically like coming with a POC unless you’ve previously given us bugs that came with a POC and then we’ll be willing to listen to you because you have a reputation. But like otherwise, good luck.

Thomas: I wanna talk more about the science of finding bugs. I wanna talk more about like what the, what the fuck is going on here, right? So yeah.

Nicholas: All right.

Thomas: All right. So hold on a second, Nicholas, when we’re, when you’re looking at what’s happening right now with 4.6 maybe, and just like going straight into there, like, is it that like, is it that the models are like, have superhuman attention spans and they’re basically doing what you and I would do um, looking at code, but they can hold up attention over huge amounts of code and keep lots of context in their heads and find more stuff. And it’s just a fact, it’s just a function of thoroughness. Or is it also the case that the models are maybe for some of the same reasons, really good at finding intricate corner cases that even if you and I stared at things like we can’t hold enough stuff in our heads to find all the weird bank shot conditions that would make these things work. Is it Either or, or both, or how much?

Nicholas: So far, all of the bugs that the models have spit out, once it produces the, like, report, I can understand. Like, I can, like, it’s, like, pretty clear to me what’s going on. Like, if it’s not yet producing reports where I read them and I’m like, what is this?

Deirdre: Like, it’s like, you haven’t seen a model do, like, the equivalent of AlphaGo, which is like, it does moves that no human would ever see or think of. It’s not doing that yet.

Nicholas: I don’t know how it got there, but like, you know, the final report, like, when I file the bug report. Like I am able to like, you know, concisely explain in, you know, a page or two of text, like, you know, what has happened. Sometimes these bug reports are, well, yeah, so the Linux one, for example, this was like some, so the bug we have was, we have several of them. One of them is in, I think this is in NFS daemon. It’s, the bug was 22 years old. Um, the bug, so in Linux, you, um, what the, the way the commit format works is they like you to say like, you know, fixes colon, you give a git commit hash of the, the, the commit that you’re fixing.

Deirdre: Yeah.

Nicholas: Um, uh, I couldn’t do that. So like I had to give a change set.

Deirdre: A fresh fix has to go back 22 years and be like, this commit is the one that introduced this bug.

Nicholas: I couldn’t give a commit because the bug predates Git.

Deirdre: Oh my God.

Nicholas: And so I was like finding the change set from 2.6 that introduced, and so like, okay, so, um, Yeah, okay, this is so like, you know, like this clearly has something interesting going on because like, you know, many eyes have seen this, but like when I tell you what the bug is, you know, like you can understand it. Like, so it turned out that like there was something where, you know, if two clients are cooperating and they take a lock on the same file and one of them has a really big name and the other one like gets a lock denied error, they’re like, or big person’s name gets echoed to the other person and overflows some buffer on the heap. Like, this is like not, you know, some obscenely complicated, like, magic that’s happening here. It’s just like, it’s a bug that, like, you can see why this, like, might have been hard to discover because it’s like, it requires multiple clients that are, like, interleaving packets in the right way. And, but like, it, it’s understandable once I tell it to you what’s going on. You know, all bugs are shallow in some sense. Uh, at least, you know, for the moment they still are.

Deirdre: That, that one reminds me of how, like, concurrency and async always tend to be just gnarly and like part of the reason that, you know, Chrome, not Chrome, Rust is not like completely free of concurrency and async bugs. But it does make the severity because of the memory safety and type safety and all the things that come out of that a lot easier to do and a lot less severity if you, you shoot yourself in the foot, it’s logic bugs. But that sort of bug definitely feels like of a piece of like humans are really bad at looking at a piece of code. And transposing that to the network topology and state machine of asynchronous clients doing a state machine transition together.

Nicholas: Yep. I don’t know.

Thomas: I don’t know.

Nicholas: I wouldn’t have thought that the, a model could also reason through that in its brain. I don’t know. I’m gonna clear it like, you know, like through its context, like, you know, it has, it has in some sense like understood this at some deep level in order to come up with, with this bug. Like this is a non-trivial sort of piece of reasoning you had to do in order to like like, you know, construct multiple clients querying in the right order. Right. Like, you know, yeah. It’s just like, there’s like some of these things that like are quite interesting and like, so those are one class of bugs, um, that it finds that are interesting. The other class is like just things that fuzzers can’t find that like are just boring.

Thomas: Yeah.

Nicholas: But just like, you know, I have so many bugs in protocols that have checksums, like just like, you know, AFL has a very hard time generating valid CRC32s. Um, and so like, it’s just like not a thing that you can fuzz once you have to include this in your protocol. Um, but like language model can just like find the bug and then write the, write the input and then check, write a Python program, compute the like checksum, add it to the packet and then send it off and then it crashes. And so you’ll even have other classes of bugs.

Thomas: Yeah. That, that, that makes sense. ‘Cause like a fuzzer is a brute force search, right?

Nicholas: Exactly.

Thomas: And it’s like, right. And like, yeah. Okay.

David: So.

Thomas: Okay. I thought I had more to say about that, but I had a fuzzer is a brute force search and that’s where my insight capped off there. Keep going. I’m sorry for interrupting you.

Nicholas: Oh, that’s fine. No, no, no. I mean like, yeah, this is exactly why, right? Like even if you like start doing some kind of branch coverage kind of thing, right? Like it’s just like, it’s very hard for AFL to like discover the right sequence of bytes that like, you know, happens to give a checksum that’s valid. And so it will just like very, very fast.

Thomas: And so yeah, it doesn’t have a, it doesn’t have a theory. It doesn’t have a theory of the code and whatever the fuck is happening inside the model, the model has a theory of the code. Code that it’s chasing?

Nicholas: Well, the model can just like ignore the— it knows that there’s this line that says, you know, it’s gonna do like this compute CRC32. It will reason about the rest of it. And then when it gets to the point where it needs a CRC32 to match, it can just go run some Python code to generate the correct CRC32 hash, add that into the, into whatever the object you need, and then it will, it’ll pass. And so like, this is like a, a sort of the, the, the power that the model has that like, you know, the fuzzer, which is just looking locally at like this individual branch is like unable to to do. And so you can find a bunch of bugs that are entirely trivial things. There’s like another bug that we, that we just, was just patched in FFmpeg 8.1, which again, 20-something years old. It’s a bug in H.264 introduced in the original commit that added H.264 to FFmpeg. And it’s a bug because there’s like some overflow where if you have some number of frames, that’s exactly, you know, 65535 frames, then you can overflow something. And like no fuzzer in the world is going to like, you know, run through the loop 65,000 times and then eventually have a crash, right? It’s like a very, very boring bug, but like a fuzzer’s not gonna find it for this reason.

Thomas: Knowing what the code is that’s broken there, if you looked at that code, would you have spotted it?

Nicholas: Maybe. I think if I gave you a one-sentence description, I think you would find it. But like empirically, you know, the code is 20 years old. It’s in FFmpeg, it’s in H.264. It’s not like some obscure codec. And like it’s still present. So I mean, like, you know, knowing that there was something to look for is like a very, very big hint, especially if I tell you like, you know, what kind of thing you’re looking for.

Thomas: There was like, um, earlier this year or earlier last year, whatever it was, right? There was the DARPA Cyber Challenge thing, right? Mm-hmm. Where a bunch of different teams put together kind of complicated systems for finding vulnerabilities, right? Mm-hmm. So if we, if we think about the work that you guys were doing with FORSIX, And if you kind of divide the universe of, you know, finding vulnerabilities with AI into like the quality of the model, the quality of the harness and the tooling that you build around the model and the quality of the prompting that you do, right? Like the domain-specific knowledge you bring about the target, about the vulnerabilities to that, that thing, right? It sounds like for the, for the FORSIX work that you guys were doing for like the Anthropic Red 500, you know, zero-day thing, heavily, heavily biased towards just the model. Right? Like there wasn’t basically almost no, you know, work done at all there. Right. And like I would’ve said before we talked just now, let’s like this, or before I saw the slides for the, the talk and all that, right. That like the state of the art is coming up with better and better harnesses. Right. Like, do you see, like, do you see the result that you guys got and the success that you got as like an indication that you have the right allocation there? Or is it really just a function of like, you guys have time to do this amount of stuff and also your incentive is to make the model as good as it can possibly be at doing this stuff. And like other people’s job can be to figure out what the best harness thing is.

Nicholas: Yeah, definitely some of all of these, right? Like, okay, so like part of the reason why we are looking for these bugs is, okay, so I am looking at these bugs ‘cause I like finding bugs.

David: Yes.

Nicholas: And the reason why Anthropic is willing to pay me to find bugs is because like they in part just like want to understand the capabilities of their model. They have this model, they want to know what can this thing do, they want to ensure that it’s not going to go and cause a bunch of harm. Part of what they care about is just tell me how good this thing that I have is in front of me.

Deirdre: And what it can do, not even how good it is, what it’s capable of in general.

Nicholas: Yeah, exactly. Part of the incentive structure here is just we are in some sense incentivized to just to try get some base understanding of what’s capable. And then I could almost certainly scaffold this better and probably find some more bugs. But in the time I would have spent doing that, there will be another model. And then I could just find more things. And oftentimes you find this. Okay, so the thing that happens is you write a harness that’s really, really, really good for a particular model. And then the next model comes out and it’s better in ways that your harness is no longer helpful. It’s now restrictive. Yes. So there’s a couple of nice examples. So I did this once. So last year I wrote a paper where I had some language models try and break some machine learning stuff. And at the time when I did this, I started writing the harness in November of 2024. The paper came out in January of 2025. In order to get the models to do anything sensible, I had to say you could edit the following 6 files. You can run exactly these 3 Python commands and do nothing else because if I give you some agency, you will brick the machine. I couldn’t do anything. But then today, the last couple of days, I’ve been running this harness again. And if you run that with today’s models, they’re trying to launch jobs in the background so that they can then read code while something else is running to save time. And it’s a good idea. Harness needs to let you do this. There have been some benchmarks that even other people have found There was this science-adjacent benchmark by some folks out of Princeton where with Opus 4.5, they initially found that Opus 4.5 was scoring like 40%. I trashed their entire harness. I just gave Claude code the harness, the thing, and I said like solve it. And it was like 92% or something. It was just like, you know, it’s like this is like a common thread where like, you know, you spend a bunch of time building something fancy and the next model just like doesn’t need that fanciness, which is not to say that this is like a useless endeavor. But like, you know, it’s just like, you know, at the, when, when things are increasing at the rate that they are, like, it’s kind of like kind of hard. The time that it takes you to write the fancy harness, the next model comes out and like, it’s good enough that like you didn’t need to have written that harness.

Thomas: There’s kind of like a thing, there’s a thing with like coding agents where if you watch carefully what’s happening there, they really kind of collapse down to just the ability to run Bash, right? Like they only need the one tool. They only need the one tool, but they get Python through Bash, right? Yes. Like all they, all they need is Bash and then they can find their way into the rest of everything else there. Right. And so like, and Awk and stuff. But like you’re giving, you’re giving the LLM, you’re, you’re giving 4Six access to an environment that has fuzzers and debuggers in it. Like to what extent is it using tools versus to what extent is it like looking at code and then making inferences about what’s in the code?

Nicholas: Yeah. So it usually is just looking at code to like an annoying degree where like, I’m, I’m sure that someone could come up with like a better prompting thing that like would like have it use the tools more, you know? Okay. A thing that it has a really hard time with is running GDB interactively. Huh. The harness is just not set up, the Cloud Code Harness, the Codex Harness, because it has to launch the program and send keys to it, which is just not exactly how the harness is set up. And so what you’ll find when it does is instead it runs GDB and just reruns the program from init, passing the sequence of commands that it wants, and then it runs and hits the breakpoint and stops. And then it reruns the whole command again and just adds on the next step. Which is like a terribly inefficient way of doing the thing.

David: Quadratic GDP.

Nicholas: Yeah, exactly. But like, you know, like it’s like sometimes like they’re just like not very good and like they do these dumb stuff. Sometimes it would be generally better if they did more of this. But like, yeah, again, we could do more to improve the harnesses.

Thomas: They are smart enough to go through the Git logs and see if there were previous vulnerabilities and then generalize from the vulnerabilities. Yes.

Nicholas: Yes. They do, they do this too. Yes.

Deirdre: They’re also dumb enough when I’m like in a fresh context to be like, revert the thing you just did. They’re like, okay, I will go to a previous Git commit. I’m like, there is no previous Git commit.

David: Commit.

Deirdre: Shut up, robot.

Nicholas: Yeah.

Thomas: What’s, so like while you’re on the topic of like 4.5 and harnesses and all that, like what changed 4.5 to 4.6? Like, is there like, was it like a step function there for you or like?

Nicholas: I think 4.5 was the big step function for me where 4.5 really gave some intelligence in the model. I don’t know what you want to call it. I hate using the word, but just soul, spirit, humanity, essence. The model just started to get a lot better. That was really the big one. 4.6 again just made it even better. OpenAI saw the same thing with 5.2 was just like a big step increase. And 5.4, again, people have found is quite a bit better. And I don’t actually understand a lot of why the models get better. I don’t know, I have enough things to be doing, sort of playing with them. But someone just says, here is a new model checkpoint, please play with it. And I’m like, okay. And then I go do my things. Scaling works, which is like a, unfortunate thing that I didn’t want to believe, but empirically has turned out to be true. And for the foreseeable future, it appears like it’s going to remain true.

Thomas: It’s terrible, right?

David: It’s a really bitter lesson to learn.

Thomas: Yeah, I was going to say, it’s terrible. It actually is terrible, right? Because all of the fun problems are gone. You just have to sit there and wait for them to come up with a new model. I hate it.

Nicholas: I mean, this is a real sort of question. Yeah.

David: The fun problems are not. Gone. ‘Cause like, well, now we have two different problems. The two obvious like follow-ups for like, okay, the models are really good at finding bugs now, are the models really good at exploiting bugs? Have you had Claude write exploits or is that like too woke for Anthropic? And then step two is like, could you maybe try patching some of them?

Nicholas: Yeah.

Thomas: Okay.

Nicholas: Yeah. So, okay. So let me talk about each of them in turn. So exploits, it’s getting better. It’s like not yet excellent at exploits. In the Firefox case, we had a separate blog post on the Anthropic blog where one out of, I think maybe two out of 500 times, it was able to produce a JavaScript exploit that was able to— So the bug was some heap thing. What the model was able to do was it was not a heap spray, but it allocated some other object on some other memory, overwrote the function pointer to point to some other thing, and then called and it was like, I don’t know, some 10-chain deep thing that eventually got at some point that I could then call out and go write some stuff. It was able to do this some of the time. I think a human could definitely do that much better, much faster today. But 4.6 was the first model we saw any sign of life on the exploitation. So yes, I would like to measure this. It’s not clear to me I want to make the model better at this, but I would like to measure this to keep track of it because The trend has been first you don’t do it at all.

Thomas: If you don’t do it, our overseas enemies will with their open weights models.

Nicholas: I mean, yes, there are many reasons why I want to keep track of what the current capabilities are. But yeah, I definitely do think that you can’t bury your head in the sand. The capability frontier is advancing. The best that I can do is to like measure what is true and then just like talk very loudly and say like, please be aware of the following fact about the world now. You know, like it was nice when, you know, we didn’t know about Spectre. Like that was just like a nice world to live in, you know, like, but like too bad, like it turns out a true fact about the world is you can do side channels and you can have these CPUs and like, you know, like now everything is worse, but like that’s just like the world we live in. Same thing with like, you know, ROP. Like, wouldn’t it be nice if write or execute was like, you know, just the perfect solution? But like, it’s like not, like, it’s just like, here is a true fact about the world. Like, you can do this thing. Now we have like this other thing that is true in the world. We have these language models that can find these bugs and potentially soon exploit them. And maybe we wish that like we didn’t have these things, but like, you know, they exist and we should like measure the capabilities that they have so that like we’re not just blind to what happens.

Thomas: I know that you’re like, I know that you’re, I know that you’re not like, you don’t speak for Anthropic, let alone for OpenAI, but like my understanding of the OpenAI situation is that if you want to use Codex to find vulnerabilities, that there’s some program you sign up for to do that, right? If I wanted to replicate the kind of things that you are doing right now with just my Claude subscription, can I just do that and it’ll work?

Nicholas: Yeah, we use the production model API and run the things that we have been doing. So like, you know, I have like the exact set of weights that, I am using or the set of weights that you have access to run. I think there are, okay, there’s a question of scale. At some point in the last couple months I’ve spent lots of money on doing some of this. So some of that is how much you’re willing to pay.

Thomas: There was like, there used to, I don’t know, you’re young, but you may remember there used to be a thing called Folding@home where people had like, right. So people had computers that were sitting there doing nothing and you could harness them to do stuff. And now people have these gym subscriptions to cloud where I have the Claude 20x Max or whatever, but I’m really only using a tiny amount of my tokens. So like if I built the thing that just like took everybody’s spare quota for their tokens and then used it to like find vulnerabilities in open source code, you guys would be fine with that. And hold on, I said you guys, I didn’t mean to say you guys, I meant you, Nicholas Carlini, would be okay with that.

Deirdre: Pretty sure that would be a violation of terms of service and the spamming of the tokens and the account subscription. And it wouldn’t have anything to do with the use of the, use of the time.

Thomas: I can’t, I can’t get over the fact that like the input to this whole thing is just like you, you find a target like Ghost and you check it out in a Docker container and then like you write a bash loop around like all the files in that thing and like a dumb, no offense to the quality of your prompts.

Deirdre: Production Claude Opus 4.6.

Thomas: We should all, we have another one of these that we’re going to record relatively soon and the three of us should come back to that having done this and found a bunch of vulnerabilities. It seems like really easy to go try and do this and find vulnerabilities. It’s weird to me that I’m not finding, yeah, it’s weird to me that I’m not finding vulnerabilities right now. We should have opened the podcast by starting to like look for one.

Deirdre: Should we just click the button?

David: Well, I guess we’ll have to have fun staying poor because we’re not submitting to bug bounties with all of the bugs that Claude found. But like the flip side of that question is like, well, why aren’t these fucking projects running it themselves? Right? Like I say, as somebody who has to deal with bug bounties a lot.

Nicholas: Fault. Yeah. Right. Like, I feel bad, like, you know, blaming, like, you know, like the open source developers did nothing wrong. Right. Like, like they put something out there in the world that like is like trying to be good and nice for everyone. And I’m like, you know, along comes this like, you know, bug hunting machine and like, you know, like it’s like, I don’t know, I quite bad saying like, you know, it’s like their, their fault in some sense.

David: Yeah, absolutely.

Nicholas: But like, you know, I do think that like people should spend more time doing this. Maybe this brings us to the patching question that you which is that like, you know, we, we, yeah, we have been trying quite hard to do this. You know, Anthropic now has this tool called Claude Code Security, which is this like patched proposal thing. DeepMind has this CodeMender thing. OpenAI has Aardvark, I think they’re calling their thing. Like there’s like a lot of people who are trying to do this. And I think this is like very, very useful and very important too. It’s just the case that it’s harder to automatically patch than it is to automatically find bugs. And what you really don’t want to do is you don’t want to propose like, you know, hello, I am here to help. Here are, you know, 500 PRs that I promise fix bugs. Please review them all. Like you’re like, you’re, you’re not, you’re like, the developer’s gonna have to spend almost as much time reviewing the correctness of these PRs as they’re going to have to spend as if they had patched them themselves, more or less. They’re gonna reject a bunch of them because because the model put it in an entirely reasonable point, but it’s just not aesthetically where the developer wanted to put it in the first place. And they care about the quality of their code so that they understand where things are. And there are a bunch of difficulties here with patching that just are not present when I’m just throwing wrenches and finding bugs. It’s a much harder question to try and do this patching thing. I’m glad that all of the 3 companies are trying quite hard to have a product that will do this. And like are proposing tools that will, you know, find as, as do, do as good of a job as we can given the current capabilities of the models. It’s just like, it’s so much harder to do. Mm-hmm. Yeah.

David: So it seems like there’s like a kind of two ways that we can go from here is like we, we could be in like a local minimum where it is now, it’s like really easy to find bugs and then, but it’s not like super easy to patch them. But like once, you know, the next iteration of models comes out out, then they’ll be able to patch all the bugs. They’ll like, the model’s fine. And we just have to like suck it up in the meantime. Another one could just be like, well, no, now there’s just like more bugs everywhere. And like, I don’t know, maybe we get marginally, you know, better patching them, but the rate of bugs is coming faster. And then the variant of that one is like—

Deirdre: We can see them now. They were there. We can just see them now.

David: You can see more of them. And it’s like, I haven’t talked to a single person that thinks that we can like exhaustively enumerate all of the bugs.

Nicholas: Bugs.

Deirdre: Yeah.

David: That, that like, especially in, in a large codebase, like a browser, like at some point, like you, you just end up in this like metastable state where fixing the bugs introduces new bugs and you just kind of like, um, have jobs.

Nicholas: I’m actually pretty optimistic here about like not introducing so many new bugs because like you can imagine a world where like most code that gets committed gets reviewed by one of these bug hunting things and like, it’s not gonna be perfect, but like, I do think that we can reduce the number of bugs that are inserted into code. By like doing a code review on, on newly inserted patches. It’s not gonna be perfect, but I think, I don’t know, like we can, like, so, so a big part of the problem when you’re doing this bug hunting with models is like finding ways to efficiently like burn tokens.

Thomas: Yeah.

Nicholas: And having it like, one thing that you can very efficiently do that like there’s a lot of tokens you can burn is by reviewing commits. So you could like, yeah, burn tokens just by going over all of the commits that you possibly can. But a big problem is, you know, it’s just like, it’s, so there’s too many commits. It’s like very hard to actually go over all of them. But if you have only new commits, then you can at least conceivably try to just like make sure that we’re not inserting more new bugs than we’re fixing. And like, I don’t know if this is something that’s gonna actually be feasible, like over the, you know, if at scale, you know, Chrome probably gets lots of commits. But I do think that you could reasonably cut down a large fraction of simple bugs that people make because no one sort of checked the first time. I don’t know what the ratio would actually be. I wouldn’t be surprised if you could catch half of the bugs that are accidentally reinserted by having a model re-review the code.

Thomas: Presumably there’s some way to index the codebase, right? You have a context efficiency problem that you’re dealing with here, right? Which is like those commits come in, they’re nice small scope, right? Like you can fit ‘em in really easily and then like it has to do a search to get the rest of the context for the code, which is gonna kind of blow up the context. And you have all this interprocedural stuff and that’s, so you have to kind of reason through that. But you can also like, this is like, like, like kind of right now the standard trick that people have for handling context is just to write things out to files, right? Mm-hmm. And then have it read in like specific files strategically. This is more harness work, but like you can imagine projects that wanna get better at like, you know, using LLMs to screen for bugs, just like kind indexing their code in some way, like having like text files to read, like, here’s the context for this kind of vulnerability. Like here are the things to look at, like these functions need to be safe for these kinds of inputs kind of stuff.

Nicholas: Yeah, definitely. I mean, yeah. Well, but right again, you know, we have the advantage that like, I’m not paying for my tokens. Like I’m not incentivized to like write the like harness that will give me 90% of the efficiency at like, you know, 5% of the cost. Yeah. I think it was like, you know, I’m, the market will do efficient market things and people will sort of emerge with, with products that, that try and give you this. And I’m sort hopeful that those will emerge more quickly than, than they have been.

David: It, it seems like the other thing that like is potentially a risk is like, you know, right now you kind of think there’s like two broad groups of attackers. There’s like sophisticated attackers and like unsophisticated attackers. And unsophisticated attackers just like call your grandmother and say that they’re Microsoft and ask her to like install an RDP server. Um, uh, and props to my grandmother for recognizing it was a scam and unplugging her computer. Here. Um, but, um, like, that’s like one whole side of the world is just basically like abuse or like tricking people into installing malware and then like writing the malware. But the way it gets on your machine is you installed it with Minecraft by accident. And then there’s like the side of the sophisticated attackers that are like doing exploiting memory corruption bug. And then a lot of the effort that we spend in, in security is like on the sophisticated attacker side. That’s like basically like 70% plus of the bug patching. Is dealing with them, but they’re actually a very, very, very small amount of the actual exploitation. There’s not a lot of people doing them. You know, if you look at like the number of commits that are like known exploited in the wild or number of CVEs in a browser that are known exploited in the wild compared to like the number of CVEs they issue per year is very low. Do you think that we’re at risk of like, of that becoming like that this thing that was high-effort targeted becoming broadly adopted at scale in the same way just tricking people into installing malware or an Internet Explorer toolbar 20 years ago was.

Nicholas: Yeah. I don’t know what I’m more worried about here. I think you should be worried. Yeah. Okay. So let me answer a question you didn’t ask first and then I’ll come back to the question you did ask, which is, I don’t know. It’s very, very fun to find these memory corruption things, but In practice, most exploits are just someone forgot to patch their service and it’s running something that’s known vulnerable or they misconfigured something and now they left some port open or whatever. I’m very, very worried about the ability of models to find and exploit those class of bugs because there’s just very little that’s new there. It just needed someone to go looking for it. The big problem that I have is I can’t measure this because I just can’t go scanning random internet services and try and like find stuff. But like, I am very worried that like random people will pretty easily be able to do this. So I think this is like one form of thing that like people will be able to do, even if they don’t know anything about memory corruption, just like, you know, find open services and like, you know, find things that like are just running servers that haven’t been updated since whatever, 10 years ago. And then look at like, you just like own it. I’m also worried, yes, about random people being able to find novel zero days. It’s unclear to me which of these things I should be more worried about. I would like someone to try and figure out how to measure this in some way. I don’t feel like I have a good answer which one is the most concerning, but I do think that we are fundamentally entering a new world on the order of having recently discovered that you can now smash the stack. Every once in a while you get these things, the world is different and like, you know, you’ll end up with like, you know, 2002 to 2004, the like, you know, the wave of worms and everything hitting was like immense. And like, I’m like kind of worried that like we’ll have that world again where people develop software in a world that was not, that did not like think about security as like a first-class object. And then it turns out we widely distributed the understanding of how to go and exploit these things. And then you end up with, you know, whatever, every other 5 days some worm that takes down half the internet.

Thomas: It is kind of an inversion of the standard concern that AI skeptics have about this whole situation is that everyone’s writing code with LLMs and that code is all going to be riven with vulnerabilities because the LLMs are stupid. But the reality is is like LLMs are pretty reasonably good at knocking down kind of standard vulnerability classes, much better than we are, right? I think that’s probably not much in doubt, right? It’s like the first cut an LLM has.

Nicholas: Yeah. These are not contradicting statements though. I think like it can both be true that the model can write dumb code and it could be true that, and like, it’s like I sort of talk to some people who say this and they’re like, I agree with you. Like it would be really like, I trust currently people to write code more than I trust the models. But also it can be true the models are bad there and they could be good at other certain classes of things. For example, finding vulnerabilities. I get very frustrated when people try to deny the reality that the models are actually good at certain things and they may not be good everywhere. There’s many places where I wish that people didn’t use them, but we should at least be acknowledging the things that they can do. Sorry for the small rant.

Thomas: No, that’s okay. But you have to disclose which thing in security which people weren’t doing with LLMs.

Nicholas: It’s not necessarily insecurity. I just mean other things that, you know, like I have gotten a number of emails from people who I know that just have too many dashes and the word genuinely. And I’m just like, I care to hear what you— Yes. It’s just like, yeah, I care what you have to say, not what the model has to say on your behalf.

Deirdre: Do me a solid and write me an email from you, the human being.

Nicholas: Thanks. Yes. Right.

Thomas: Yeah, I gotta say, like, I’ve been pretty bearish on kind of startups doing this stuff on like, you know, vulnerability hunting startups. ‘Cause I figure both OpenAI and Anthropic have just like multifactorial incentives to get really good at this. Like both for like the good of the world and also because it answers like the chief objection people have to building, you know, code with LLMs is it’s gonna introduce security vulnerabilities. There’s all these reasons why all of the frontier model companies are just naturally going to get good at this stuff. But I think you probably got 10 or 15 different startups funded just by saying that every time a new, a new model company introduces a new model, it finds new vulnerabilities, which means there’s now space for everyone just to say, yes, but we’re a multimodal, like, finding vulnerabilities startup.

Nicholas: No, I do think there’s good reason for companies to exist that are doing this. You know, the costs are one of them. I do think that, like, you know, the frontier labs are somewhat incentivized to reduce costs, but that are maybe less incentivized than a startup might be. I do think startups can be distributed across multiple labs. You could imagine that Model 1 proposes a bug and then Company 2 is better at auditing it and so you combine them in clever ways. Expo actually has a nice interesting blog post from a year ago where they Franken-modeled something where every other request that went switched between OpenAI and Anthropic and doing this in this way was better in some ways than either alone. I think there’s lots of interesting things that can be done. I think there is work to be done on scaffolding the models better. This exponential right now reminds me of the exponential from CPU speeds going up until let’s say 2000 or something where you had these game developers who would develop really impressive games on the current thing of hardware and they do it by writing like really detailed intricate x86 instruction sequences for like just exactly whatever this, like, you know, whatever 486 can do, knowing full well that in 2 years, you know, the pen team is gonna be able to do this much faster and they didn’t need to do it. But like you need to do it now because you wanna sell your game today and like, yeah, you can’t just like wait and like have everyone be able to do this. And so I do think that there definitely is value in squeezing out all of the last little juice that you can from the current model. Models. And the frontier model developers companies are just not quite the same way incentivized to do all of this. And so I think there’s plenty of room for people to try and build stuff with these models. And I would like to see more of it. What I just don’t want to see is people putting in work that is just entirely wasted and late enough that the next model is just better than what they would have done. And it was just not efficient in ways where If John Carmack had spent 5 years writing super efficient Doom things and had released Doom in 1997, right? It just could have run it just as efficiently on whatever unrolled C code compared to whatever optimized assembly thing he wrote for whatever stuff. So it’s like, right. I just think people need to be a little careful with how they’re doing it.

Thomas: I’m just going to say my company pays for my subscription, so if I come back Next time we record and I don’t have a vulnerability, you guys should all make fun of me.

Deirdre: Okay. We will.

David: Sounds like you’re respecting shareholder value.

Thomas: Indeed.

Deirdre: Um, this is fantastic. I’m a little bit scared, but also a little bit like excited.

Nicholas: So I think this is the right reaction. Like I, yeah, I’m also quite, quite worried. I think like, you know, I think if you have played with these things and you are not a little bit worried about what is about to happen in the world, I think like you are not thinking critically. I think it’s happening here first, but I think it’s going to happen in many other areas too. It’s not obvious to me. I’m not an expert in the other subjects of the world. I think we are seeing this first because these models happen to be very good at coding. But I do think we should think through this very carefully. Other people will encounter these problems next. I would like to just have the world start thinking about these things I do think things will look quite different in a small number of years and we should be just spending the time that we need to understand what’s true and not just sitting and hoping for the best.

Deirdre: Yeah. I mean, things have been looking very different in a matter of months.

Nicholas: Yes. Yeah, no, I have to hit my mind. I want to say in small numbers of years and I have to recalibrate to months. But yeah, things are going very fast and I think we need to just be willing to look at it.

Deirdre: At the very least update our models of the world.

Nicholas: Yes.

Deirdre: Yep. Pun not intended.

Thomas: Nicholas, this is amazing. Thank you so much for—

Deirdre: Thank you.

David: It’s great to talk to you guys.

Deirdre: Hell yeah. All right, I’m stopping.

Standardizing Pure PQC

Mon, 09 Mar 2026 00:00:00 +0000

Standardizing cryptography involves a lot of opinions. Luckily, the gamer presidents are on it. Come on, you all know the drill.

This is the last time I do this.

No transcript available.

Python Cryptography Breaks Up with OpenSSL with Paul Kehrer and Alex Gaynor

Sun, 01 Feb 2026 00:00:00 +0000

The Python cryptography module, pyca/cryptography, has mostly been a sane wrapper around a pile of C, so that users get performant cryptography on the many, many platforms Python targets. Therefore its maintainers, Alex Gaynor and Paul Kehrer, have become intimately familiar with OpenSSL. Recently, they declared that after many years of trying to make it work, they announced pyca/cryptography would be moving away from OpenSSL when supporting new functionality and exploring adding other backends instead. We invited them on to tell us about what has happened to OpenSSL, even after the investments and improvements following Heartbleed. No guests on this pod represent anyone besides themselves.

Watch on YouTube: https://www.youtube.com/watch?v=dEKBHI3rodY

Links:

Thomas: It’s 2026. It’s like the most scrutinized C code on the planet. All of like the low hanging fruit, memory corruption on OpenSSL is gone now, right? Like how likely there was one today.

David: Literally today!

Deirdre: Hello, welcome to Security Cryptography Whatever. I’m Deirdre.

David: I’m David.

Thomas: I am a national spokesperson for the Crystal Hot Sauce company.

Deirdre: Awesome. That’s Thomas. And we have two special guests today. We have returning champion Alex Gaynor. Hi, Alex.

Alex: Hello. Thanks for having me a second time.

Deirdre: Yes, thanks for coming back. We didn’t scare you off. And our other collaborator on the Python Cryptography library, Paul Kehrer. Hi, Paul.

Paul: Hi everybody. I’m just here on Alex’s shirt tails.

Deirdre: Yes, we invited Paul and Alex today, today because they wrote a little blog post about OpenSSL and they gave a talk about OpenSSL a couple of weeks ago on the same topics. And they have a lot of experience trying to operate around Open ssl. As maintainers of the, the Python Cryptography Library, we say the because it’s literally called cryptography. And so if you want to redo anything with cryptography in Python, theirs is usually the one that you go for. Alex, tell us what prompted you to write this statement, which is also the first statement from the Python cryptographic authority, aka YouTube.

Thomas: Before you do that, can I ask one or both of you to explain to, you know, the world why pika cryptography is, you know, like why you guys have standing to make these complaints, like, who do you guys think you are? Hi.

Paul: Sure, I’ll start with that. And Alex can jump it as he sees necessary. So the Python Cryptographic Authority is a self proclaimed authority. It’s important to note that inside the context of Python there used to be like a running gag where you would create an authority to define basically the GitHub namespace that you were going to use. So the Python Packaging Authority, which became a very official concept in Python, was originally actually the creation of a single person who wanted to go and do some work. Similarly, the Python Cryptographic Authority was founded in kind of an aspirational MANNER Back in 2013, like Alex and I were working for the same employer back then, and we looked around and discovered that there was not really a good solution for cryptography in Python. In Alex’s case, he was also interested in pypy support, a thing that he regrets to this day. But the outcome of that was ultimately that we, you know, we’ve embarked on a 13 year and counting adventure of taking over the world of cryptography in Python and largely We’ve been successful mostly because we have a.

I mean, I’m sure we’re going to get into this, but we have a somewhat maniacal focus on the way in which we deliver the software and the way in which we. The expectations we set for ourselves such that we can and do have higher expectations for the things that we depend on.

David: I can’t emphasize enough how in like, pre 13 years ago, so like 2011, if you tried to make an HTTPs connection from Python, it was effectively impossible. You at best, like, had to install PI open ssl, which didn’t have wheels, so it had to build OpenSSL from source every time. And so. And that. And of course OpenSSL would fail to compile because it was 2011. So it was just bad.

Deirdre: And for those who don’t ship a lot of Python libraries, wheels is a technical term of art. It’s not just, haha, wheels included, like batteries included. What are wheels?

Alex: Yeah, wheels are Python’s binary package artifacts. So you can have an sdist, which is source that you compile yourself, or a wheel that’s pre compiled by somebody else. So we, we build wheels of cryptography for many, many operating systems and CPU architectures.

Deirdre: This is a language called Python. Why isn’t it called like eggs? Or like.

Paul: They were called eggs.

Deirdre: Oh, God damn it. Okay, and now they’re called wheels because that makes sense. All right.

David: Alex is the first person to be asked the same question twice on this.

Alex: Podcast in two different episodes. Yeah, you get your wheels at the cheese shop, which. The Cheese shop was the original name of the Python package index.

Deirdre: What? Okay, all right.

Paul: It’s because Python was named after a Monty Python. After Monty Python and Cheese Shop is a famous sketch.

Deirdre: Now I’m remembering our whole episode that we did this whole rigmarole with like. No, we’ve been going strong for several years now. Forgive me for forgetting, but. Okay, so I was going to, I.

Thomas: Was going to say. Right, so like, the, the situation with like, like your biggest dependency is open ssl, right?

Paul: Correct.

Thomas: Yeah.

Paul: Right.

Thomas: And like, in the universe of things that use open ssl, like, that’s gotten a lot more complicated over the last 10 years as Chrome has shifted to BoringSSL and AWS now uses their own kind of formally verified SSL and OpenBFD, the Libra SSL. Like in the universe of OpenSSL consumers, where do you guys fit in? Like, what’s your rank?

Alex: I don’t know that there’s an official leaderboard of like, OpenSSL consumers, but I guess we have A lot of standing at the very least in the Python ecosystem. We’re consistently one of the most downloaded packages on the Python package index. Many millions of downloads. Like, if you use a Python thing, it’s like quite likely you rely on us. All of the major clouds command line interfaces include us. The cert let’s encrypt client includes us.

Thomas: Oh, hey, yeah, in the same sense as like if you’re writing a Go program and you use. Net HTTP, you’d be pulling in go’s TLS libraries. In Python world, if you’re doing the equivalent of, if you’re doing requests or whatever, you’re effectively to do TLS pulling you guys in.

Alex: No, so TLS is the one thing that is, I think in the usual cryptography toolkit that you probably would not pull in Cryptography for. We don’t have TLS APIs. You’re much more likely to either use the Python standard library SSL module or PyOpenSSL, which, which we also maintain, but is a separate library.

Deirdre: Oh, wow. And just for the record, why aren’t you just writing your Python cryptographic library in Python and shipping Python?

Paul: That would be very convenient. Unfortunately, it would have both security and performance implications that are effectively insoluble inside Python the language.

Alex: I will also say when we started cryptography, you know, 12 or 13 years ago, we made what amounts to like a very ironic deal, which is like I was persuaded that like I would help coordinate this library as long as the one thing we were doing was not implementing cryptography. We wanted to think hard about APIs. We wanted to think hard about what made a safe default and what shouldn’t have a default at all. We wanted to think hard about testing, but we were not trying to do something where we felt like the relevant expertise was like really outside of, you know, what a person might have if they didn’t have like a PhD in cryptography.

Deirdre: And you’re talking like low level primitives because like we can have a wonderful debate about what counts as implementing cryptography. But yes, I know what you mean.

Alex: Yeah, I would say about six months after we, you know, had this conversation where we’re not implementing cryptography. One of our maintainers at the time, I guess this would have been right after Heartbleed came up and said we should implement tls. And I said, what happened to our deal? And he said, TLS is a network protocol, it’s not cryptography. Sure. And I think that’s one of the. I think it’s like a very true statement that like really rides the line.

Paul: Yeah. And we’ve enclosed. We’ve definitely increasingly blurred it over time. I mean, I think one of the first times we kind of said, oh, this isn’t really cryptography was when we did like AES key wrap support back in the day when like OpenSSL’s implementations of it weren’t very good. And like, we still strive not to do it unless we have to. But there are scenarios where we choose to hoist it into ourselves because we believe we can do it better. I think the most recent example of that is actually something that we haven’t released yet, which is the HPKE support. OpenSSL does support HPKE, but we have chosen to implement it ourselves using OpenSSL’s primitives.

Deirdre: And why did you choose to do that?

Alex: So I think there were a couple motivations that come into it. One, it means you’re going to get a really consistent HPKE implementation no matter where you get your cryptography from. So like, the OpenSSL HPKE implementation is not supported on LibreSSL, BoringSSL, AWS LC, which I guess we’ll probably mention a lot in this conversation. So it’s called a forks. So like implementing it ourselves means you get a consistent experience because they’ll all have the underlying cryptography. It means we have a lot more control over kind of the compatibility surface. We’re not accidentally pulling in lax parsing behavior or other kind of unintended behavior from open ssl. And it gives us the kind of high level of confidence that we’re handling all the edge cases from both the security and correctness and just like not crashing perspective. Paul, I don’t know if there were more motivation for you.

Paul: Well, I would say that the one that’s kind of the elephant in the room that is the core component of. Part of our criticism that occurred in our statement is that the HPKE APIs are only accessible through the OSSL param APIs.

Deirdre: Oh, goodness.

Thomas: So, okay, I want to stop you guys there. Right, so we’re kind of beating around the bush and I think trying to let you guys introduce the talk that you guys did yourself, but I kind of don’t want to do that. Let’s just cat out of the bag, you guys. You’re not super happy with the current state of open ssl, but it’s like not for the normal reason that people usually bring up. Like, you know, that’s why there’s Libra ssl, because we don’t trust the code or whatever. Although we can get into that later too. But for other reasons. Right, so.

And your reasoning is mostly about or is entirely about the Design of Open SL3, that version of the library. So I have not paid close Enough attention to OpenSSL to know what the fuck OpenSSL 3 is. What’s roughly the timeline here, what happened? Like I knew OpenSSL back in the Heartbleed days and now there’s multiple OpenSSLs.

Paul: So, you know, Heartbleed happened in 2013. And at that time it became like a very well known fact that OpenSSL was kind of a project on life support that didn’t have the right resourcing and had various problems because of it. In the wake of that, OpenSSL got a surge of investment, both monetarily and also in human time. Like there were a bunch of folks from Google, like Amelie Casper and others who went over there and did a bunch of work. There were folks who later founded some of the forks that were involved heavily. And then there was just like a large organization formed that had a bunch of full time employees to do things. As a component of that, the business realized that part of the way in which you sustain in the cryptographic library is by catering to business interests around things like fips. The structure of FIPS is such that you want to isolate it off.

And that created a concept that they were, that was supposed to replace engines. Engines are a method of plugging things into OpenSSL. Providers became the new thing. Providers are intended to be a superset that can do all that stuff. And in the abstract it’s a fine concept. However, in practice, as they went down the path of this OpenSSL 3, which was a deliberate ABI breakage, they skipped two because they were worried about version numbering based on the fact that Libre had forked themselves and they called themselves two at the time they went to three. And the consequence like the actions of three were basically rewrite the entire internals without understanding the surface area of your own project. This led to an 18 month alpha beta phase before release and ultimately well over two years of delays from when they expected to be able to release it.

Thomas: So when did that land? Like when did OpenSSL 3 become. I assume that right now OpenSSL 3 is like the mainstream version everyone’s using.

Paul: That’s correct.

Alex: If you get your OpenSSL from like an Ubuntu or Debian or Red Hat, you’re going to get an OpenSSL 3 from a recent Linux distribution and then that landed in 2021.

Thomas: Okay, that makes sense to me. So now I know what you’re about to say, but let’s bring our audience up to speed on the suite of concerns that you guys have about the situation.

Alex: Yeah, so we’ve got a couple and I’m going to say them in the order that we wrote the post in as we’ll get into. I think we put them in the wrong order in the post. So the first concern, it’s the most easy to Quantify is performance. OpenSSL3 had some really, really significant performance regressions. Things like loading elliptic curve public key from like a subject public key info format, really simple format to parse. Got something like 8 times slower between OpenSSL 111 and OpenSSL 3.

Deirdre: Was it doing the on curve math? Was it checking that? It was like. No, it was just parsing.

Alex: Yeah, it’s like anything you can come up with that’s like the cryptography, the math that might make this time is not it. It was that the abstraction for how providers worked and like the interplay between it and the DIR parser and just like what the public API like all that back and forth had so many indirect calls, so much allocation, so much locking. OpenSSL had a whole like format auto detection thing that happened. It was like, you know, you find the issues in the OpenSL Bug Tracker where folks are like breaking down, like where is the time going? And it’s truly just that the, the parsing itself had become so convoluted that, that it was just, you know, time was spent in nonsense places. We’ll say since then OpenSL has made some improvements and now it is only 3 times slower than it used to be as of the last time I measured. So like that’s, that’s quite significant. Like I want to just give people like a data point for like how extreme this was. We have our own X509 like path validation code. Whoops.

People would call like X509 verification and doing our own public key parsing that is moving the public key parsing from OpenSSL to our own Rust code. No other changes. Was a 60% performance improvement on end to end x509 validation. Like that’s just like how extreme this overhead was to like what is empirically possible. So this was kind of the first and most easily quantifiable. The performance was insane. And I think, well, maybe we get into this more.

A lot of people think that this is like maybe our biggest complaint because it’s the easiest to quantify, but it’s not. We shouldn’t have put it first because our real complaint is the complexity that led to the performance regressions. The fact that the provider APIs were designed or evolved in such a way that the abstraction boundaries were unclear and you had really extreme performance regressions that came down to things like if you load a hash algorithm through a function like EVP SHA256, which is like get the SHA256 like hash object identifier. Like that is slower because what that API is doing is getting like an object that represents like a future promise that I will call the provider API later to like actually find the SHA256 API from your provider. And like that can change at any time in theory. Cause the provider APIs don’t say once your program’s initialized, you can’t change where the cryptography comes from. So there’s just tons of back and forth, lots of indirect calls, lots of allocations, lots of locking, lots of caches to try to compensate for that. The degree of complexity in the internals got really extreme, but it also got pretty extreme in the public APIs.

Paul: Yeah, I mean I won’t add a lot here other than to say the ultimate outcome of these attempted fixes for performance regressions based on this is that we have full on RCU code which has had bugs in OpenSSL since they landed it to just to try and resolve some of these issues. And like the nature of the DIR parsers are actually that it chains things together. Like it’ll progressively try different things. Which led to a bunch of bugs during the OpenSSL 3 betas where they were leaving errors on the error stack because they didn’t know they were doing these chained attempts to parse things.

Deirdre: What they were doing different, like different implementations of dirt parsing and they would like try one and then if it didn’t throw it would try another one.

Paul: So OpenSSL has like these auto keyloader APIs where it’s like give us some DIR and we’ll figure it out and give you back what you want. But that like necessarily means that it’s going to try a bunch of things rather than simply reading the OID out of it and then dispatching correctly. So you get a bunch of performance issues from that was that.

Thomas: I have two questions. Right? So first of all was the kind of the YOLO mode just try all the different formats key parsing thing, Was that an OpenSSL one thing or did they come up with that in OpenSSL?

Paul: OpenSSL one did have the same behavior on some limited APIs. Like it’s like D2i auto private key or something of that nature. So that behavior was there, but it was a much faster one in that it dispatched based on the OID at the time, as opposed to this one, which needs the providers and every provider doesn’t. There’s not a mechanism for providers to necessarily declare exactly what they support, so you have to just incrementally try them until one works.

Thomas: I’m a little familiar with the OpenSSL code or the OpenSSL code of old. Right? I don’t remember concurrency being a huge thing in that.

Deirdre: Yes.

Thomas: So you said there’s like a full on implementation of RC use now and open Silvery. Like what is that? You guys would know way better than we would. What is the concurrency situation? If this is a crypto library.

Alex: Yeah, it’s a crypto library. But like you have like various APIs for manipulating like global states, like adding a new provider to like the global context, for example. And so like if you haven’t done anything to preclude like that happening at arbitrary points in the runtime.

Thomas: Wait, wait, wait, wait, wait, wait, wait, wait. Why am I, why am I adding new providers to the runtime state of a running program?

Alex: I mean that’s roughly the question like Paul and I would ask. Like, you think that’s just like a design mistake, that you can support that, but like if you’ve chosen to support that and are now like going back to like, you know, you don’t, you’re not quite sure like what your API contract with users is like and now you have to deal with like concurrency bugs. People are reporting like Tsan issues or like performance issues. Like now like, yeah, like hold on.

Thomas: Hold on, hold on. RCUs are what you use when you’re locking so much and so many hot paths that you can’t actually do new taxes that you actually need an optimized concurrency primitive because you’re, I get like you need a lock because you can add a provider. Can you like add and remove providers in a hot path?

Alex: Nothing precludes you from doing that.

Paul: Yeah, there was not necessarily like, I want to be charitable here. So like maybe the answer may not be that they didn’t have a design ethos around it, but like for whatever reason as they went down the path of implementing this, the answer of support everything at all times became the correct answer. And like that led inexorably to these.

Thomas: Types of choices because engines in open ssl, that was there for like people doing like crypto card stuff, right? Yeah, at the time it was for like people with co processors, accelerators. Right. So the idea here is like you’re supporting a use case where somebody has like you know, a card or something like that they’re inserting and removing like several times per millisecond is why you would need RCUs.

Paul: I think the, I mean the RCU component is just the what comes out of the fact that they have to do locking in so many places just to check the actual reality is like they as best I can understand it again steel manning the concepts of the provider. There is a design goal in OpenSSL that it is an abstracted substrate upon which anyone can do anything including adding features that were never considered by the OpenSSL people. Like basically LinkedIn to any arbitrary program. Right. So like oh in the future, 10 years from now I can load arbitrary providers into some old piece of kit and get new stuff.

Alex: Yeah and like you do see examples this like before OpenSSL had post quantum crypto algorithms in it there were third party providers that would provide them. And so like you could get an ML chem inside Open SL before Open SL supported it. Like I think we would say like this is just like not the correct allocation of resources to like towards your problems.

Deirdre: But you know it makes me so nervous. Like I, you know I don’t have, I don’t maintain a project like this. Like I’ve maintained large rust projects but.

David: Like no, like Lib SDL works kind of like this. It’s designed to both be statically which it’s a, it’s a like cross platform graphics library that’s designed to be statically linked but also like sometimes it gets.

Alex: Swapped out and replaced with a different.

David: One because you know, maybe Valve like made it run on Linux but wants it to look like it’s Windows to trick some game from 10 years ago to run on Linux and you can kind of see how you end up there. I don’t quite understand what the like surrounding ecosystem is where you need to do this for cryptography as opposed to like games which are I was about to say notorious for being developed once and then left on for years but then I just realized I was describing HSMs.

Alex: Yeah, I mean I think what I would say is that like if you really sat down with a we want to make more things pluggable like I think there is probably a design you could get for providers where you put state in the right places. You have like the indirect function call in kind of the right place in the stack that balances the complexity and the performance and the maintainability of the system. I think there are useful points on the trade off curve that are not just everything is static. But I think the point OpenSSL ended up on, where the SHA256 or the result of EVV SHA256 is an abstract object which will call something on the provider later and that’s allowed to change at arbitrary points, is like not a particularly useful point on that trade off curve.

Deirdre: Yeah, no, God.

Thomas: I was, I was, I was set off on the whole RCU thing. So I was wondering, it kind of made sense to me that if they did a whole bunch of new concurrency stuff like that’s a way I could see you getting like a 6x performance regression. Right. Because. Okay, you’re just like, you know, you’re contending on locks or something like that.

Alex: I mean, and there certainly are a lot of locks, particularly in the earliest profiles.

Thomas: Okay, but it’s not your sense that. The vibe I get from you is that it’s literally just calling through bullshit indirection code. It’s not waiting on locks.

Alex: I don’t want to say there’s no locks anymore. The point of RCU is now you’re spending less time waiting on the locks. But like I said, it’s still 3x slower than what we think is a reasonable baseline for parsecs endure.

Paul: And I will note that I think we’ve fallen to the same trap because of the performance stuff is so easy to talk about. But again, the performance is not our critical concern here. It is the complexity that led to that issue.

Alex: Yeah. Which I think it’s worth building on. Kind of the complexity in the public APIs is like a really important other thing that is honestly maybe the most pressing thing for us.

Deirdre: Yeah. You mentioned OSSL param and like, you know, I’m poking around in there in OpenSSL for post quantum stuff and I’m seeing this all over the place. Where does OSL param come from and why is it there?

Alex: Yeah, so OSL param is another one of the kind of new APIs from OpenSSL 3 and it is effectively many public API functions. Instead of taking a list of arguments to a function, take an array of OS cellparams, which is basically an array of key value pairs. So instead of passing, I don’t know if you’re calling like Argon 2, like you’ve got a key derivation function. Like you’ve got your key material, you’ve got your salt and your salt, maybe a length because it’s C. So you got your pointer and your length. Fine. And your desired output and the rn and I can’t remember the third parameter’s name.

Deirdre: Sure.

Alex: Instead of. You pass each one of those to a function as arguments. The way this works in OpenSSL 3 is that you create an OS cell parameter and it’s got, you know, you know, string key, pointer to the key string, salt pointer to the path, salt len and like that is like how it works. You know, you’ve got types for each of the values because like you wouldn’t want to.

Thomas: Yeah, I was, I’m looking at that now. I’m looking at the CLAUDE summary on this now. And it’s like integer unsettled integer UTF string octest. Does it really have octet string?

Alex: It does. You want to pass like arbitrary bytes. You think your salt should be like UTF8.

David: I mean it sounds like they’ve created C JSON.

Deirdre: Oh goodness.

Alex: Yeah.

David: Or the C JSON TypeScript interface.

Alex: Yeah. And like, you know, again, to like try to steel man, this like our understanding of like, this is part of just like the make things very abstract theory of like, well, you could write a program that like, I don’t know, has a configuration file and like read some parameters from it. And that would mean that somebody could bring a new algorithm and new types of parameters and you’d never have to update your program because it all flows through this abstract OSL pram. In practice, our experience for the things we are trying to do is it means it’s very difficult to tell what arguments the function takes. It’s very difficult to tell you’re passing them correctly. You are losing a whole bunch of static type checking that you would normally get from a computer program. It makes things slow and it makes the OpenSL code like much more complex. Right.

Like you think like, oh, I have the name of a variable that’s not given to my function. Like that’s just like clearly much simpler than I’m going to go root around in the array. And in fact, many C Source files in OpenSSL source now have a custom Perl preprocessor to like make dealing with like these simpler.

Thomas: Oh no, wait, wait, wait, hold on, hold on, hold on. In the new OSSL_PARAM world in OpenSSL 3, yeah. None of the cryptography interfaces are type safe anymore. They all just take abstract arrays of parameters.

Alex: All the checking is none of the new ones. Like they’re still old APIs.

Thomas: It’s all runtime checking now. They’re just like, okay, correct.

Deirdre: Yeah, so we’re going backwards.

Thomas: Yeah.

Paul: Any new interface like EVP KDF and EVP aead, those are all interfaces that now require OSSL per ram, and almost any new feature added does require it. We’ve spent a lot of time and energy, like, trying to not use osslparam except where necessary. And I think we currently have two places we consume it, but we actually abstracted away by pushing it into rust. OpenSSL.

Thomas: Let me steel man this design. All right, what if the idea here is that no normal person is ever supposed to use this interface, which is the only way I can think, the only way I can think to describe a cryptography, a cryptography interface where, like, the IV isn’t type safe at compile time.

Deirdre: Instead you’re saying me and my collaborators are not normal because we did just that the other day.

Thomas: Hold on. I’m saying only two people in the world are ever supposed to consume osslperam, and it’s Alex and Paul. And what you guys are supposed to do is take that and then turn it into something reasonable.

Alex: So, I mean, I think what I would say is like, if you, you like, you’d come to the idea that like, your internal APIs needed to have this for whatever reason, right? You needed, you know, more flexibility in like the provider API, because, like, that ABI had to be the same for forever. Like, if you had like a theory of that, like this needed to be kind of your internals. I like, I think the. I like, I. I’m not sure I would ever reach that conclusion, but like, if I did, it seems like what I would want to do is like, have public APIs that are like, entirely like type safe and like, construct these things internally and it’s just like, not the case. Like if, for example, if the thing you would like to do is configure OpenSL to do elliptic curve signatures that use deterministic nonsense like specified in rfc. Like the way you do that.

Thomas: Yeah, hold up, hold on a second. You’re telling me that in the new system, if I want to do GCM or something and I’m passing a nonce in, it has to do a string compare to find the non key.

Paul: Correct.

Alex: I think in practice there’s old APIs that were type safe for things like doing a symmetric encryption.

Paul: But I would say, Alex, they’ve been significantly re implementing some of the old APIs using the new APIs so that underneath the hood they generate OSSL params, and then there’s definitely a string comparison.

Alex: So that’s better than making me know about them. Because literally, if you want to do an elliptic curve private key signature and you want to use a deterministic nonce RFC 6979 the way you do that is you create an OSSL params with two entries, one of which is a bool indicating true and the other is the marker for like. This is the end of the params and you pass that to evppkey setparams or whatever the function’s named. You can’t just pass bool to, you know, enable deterministic nonsense.

Thomas: Like you create an array, it’s like they’re implementing Ruby.

Alex: Yes, like, so like I used to be a programing languages person. Like I, like Paul mentioned, like, I got my start working on cryptography stuff because I was working on PyPi, the Python implementation. And like, yes, this is what it looks like if you’re like writing an interpreter and like, yeah, you know, a user can define arbitrary like functions. Like, so you have to have an array of parameters. Like, yeah, this is one interpreter. It looks like. But like, you don’t get to get.

David: Out of this discussion without noting you also worked on pyruby.

Alex: It was not called pyruvy, it was Topaz. But yes, yes, I created a Ruby interpreter.

Paul: I will say every time I end up doing OSSL_PARAM things. What it feels like to me is actually like Apple’s design aesthetic from Next Step era, like NS mutable dictionaries everywhere with all the same sort of challenges where like, maybe the, like, maybe the principal, like golden path has been tested, but God help you if you pass anything out of the ordinary. Who knows what’s going to happen. Which I think I should segue nicely to testing.

Thomas: I got to say, passing in as parameters to a function, a dictionary of random string keys and values does feel very Pythonic to me.

Deirdre: But it’s, but this is the part that’s in OpenSSL. It’s supposed to be a C library.

Alex: Yeah, they just renamed OSL param to Paramount.

David: Just rename OSL param to kwarg and suddenly you guys would be all over it.

Alex: I mean it’s not really our design aesthetic for Python. Like, you know, I think we have like Pretty strongly typed APIs within the Python world. But like, yeah, like that would be a recognizable like dynamic programming language aesthetic. That is like, definitely true. I just don’t see why you would bring that aesthetic to C. Like, that’s not C’s problem.

Deirdre: So all this dynamic stuff and lack of static validation and verification seems like it would make it hard to test or at least harder to test.

Paul: So we definitely, it’s definitely a difficult thing to Test. It is also the case that the OpenSSL project was founded in the 90s when aesthetics were different. However, over the course of the decades the OpenSSL project has been around and including the time now where they are a very well funded organization with more full time engineers than work on any of the forks to our knowledge.

Alex: They have a foundation and a corporation.

Paul: And a Corporation and 17 different interest groups at this point they they still struggle with testing. So like Alex and I consistently joke that like the Python Cryptographic Authority is a CI engineering project that incidentally produces a cryptography library. And part of the reason we make that joke is that like it reflects our real belief that like that type of investment in continuous integration and testing pays dividends in terms of like software engineering velocity and the quality of the product we deliver. We spend so much time on it that like it can almost make the other work. We do seem trivial. Unfortunately, the OpenSSL project, I mean we’ve worked with a lot of these folks, we like these people. But like it’s important to note where struggles continue. And one of those things is that despite all this time, the OpenSSL project does not prize testing in the way that we prize testing.

We have seen— there are many ways in which you can judge this, but one of the ways is fairly prominent is go and look at any bug fix or new feature set that lands on OpenSSL and look to see whether or not there are tests. Now, new features typically yes, bug fixes frequently no. And if you ask about them, they won’t say there shouldn’t be tests. But they may not happen. They’re not prioritized in the way that you would expect at a project like this. Similarly, you have a large CI matrix. Alex and I spend a lot of time and energy making sure our CI matrix is clean and fast because not otherwise is very painful. In fact, as A related note, OpenSSL shipped the bug fix release today, which meant we shipped the release because we statically link OpenSSL in our binary artifacts, the wheels, and because we’ve spent two weeks with Windows ARM64 builders failing, we removed Windows ARM64 support. That’s how serious we are about this sort of thing.

Alex: Failing not because we landed a regression, but due to a platform issue in GitHub’s Windows ARM 64 runners.

Deirdre: Yeah, it was because of the runners.

Alex: Correct?

Paul: The runners issued their platform. It’s not the first time we’ve had issues. This is not a conversation about how Microsoft owns GitHub, and yet somehow they don’t. Prioritize Windows ARM64 at all. But like, we’ve had enough issues and that, like, we gave them a lot of time, but we care very deeply about our CI working and being performant. And so we were willing to remove it even though it is painful.

Deirdre: That’s indefinitely until those things can work again.

Alex: Until they work and we have confidence they’ll say, working.

Paul: Yeah, okay, exactly. I need a track record behind it because fixing it is fine, but like, I need to see it working for an extended period of time and that like, they actually respond in a timely fashion to future issues.

Deirdre: Yeah, if failure is just flapping all the time, then it’s a noisy signal and it’s not a useful signal and then it’s just.

Alex: Yeah, flapping it all the time is like a useful segue into like. That is a big problem with OpenSSL’s CI. So, like really the apex of this was OpenSSL 3.0.4 had a buffer overflow in the RSA implementation for AVX512 capable CPUs. And in fact this failed in CI sometimes when the CI runner happened to be allocated on a machine with AVX512. But it didn’t always doing a different.

Deirdre: Architecture, like it was randomly GitHub Action.

Alex: Well, so GitHub Actions doesn’t guarantee like which CPU class you’ll get. And so like sometimes you built on a machine with AVX512, sometimes you didn’t. And so like when you were on AVX512, your tests probably failed. Like it’s a buffer overflow. So there’s always an element of luck. But it was not noticed because tests were kind of always flaky. And you know, I think this reflects two issues. One test being flaky all the time, which is a really persistent issue.

Like the day we wrote our slides for the original talk version of this, five of the ten recent commits had failing CI checks. And when we checked again the day before we get delivered our talk, every single commit had failing builds for cross compilation. Just like the first issue, just like lack of really prioritizing stability. The second issue is like lack of investment in the kind of infrastructure for like Open SL is a project with lots of like, per platform assembler, per platform assembly. And intel in fact offers a tool called Intel SDE which basically lets you dynamically toggle CPU features on and off. So you can, you know, simulate a CPU without AVX512, a CPU without SSE3, and so you can in fact test all of the combinations of assembly you have and There are forks that use this in their CI to verify all of their assembly. And you know, this is not present in OpenSSL CI. And like, we think that’s a real miss. Like, that’s just a missed opportunity.

Deirdre: Like, I’m, look, I’m, I was, I was stunned that you’re like, you can’t make sure that you get like an AVX backend runner in GitHub Actions. And like, the answer is, okay, maybe you can’t, but that means you put your AVX specific stuff behind a flag, you put online your own custom runner, you rack your own hardware, or you pay someone to rack the hardware and then you have the flag so that when you do allocate to your custom runner that always runs on avx, then you unflag your flag and then you test your AVX specific implementation. I know lots of projects that do this.

Alex: Yeah.

Thomas: And now a word from our sponsor, Fly IO, provider of AVA Scapable, and from the official hot sauce of security cryptography, whatever. Crystal Hot Sauce.

Alex: What a salt brand.

Thomas: It’s also. You’re thinking of a diamond. Diamond Crystal, maybe.

Deirdre: Yes, yes.

Paul: I’m going to be very disappointed if that doesn’t make it into the podcast. So, like, I mean, there’s, as you’ve noted, Deirdre, there’s a bunch of ways where you can slice this such that you get the type of testing coverage you want. It’s also the case that OpenSSL is at this point a big tent with a wide variety of supported things and they actually do have leverage in this ecosystem. So, like, if and when someone comes and says, I would like you to land like architecture specific assembly for my pet architecture, it would not be out of the bounds for them to say supporting that in our system looks like the following. And frankly, it would probably look similar to what Alex and I have said in the past around PowerPC 64, a little endian support, or Windows ARM 64, which is you will provide ephemeral runners that maintain no state and integrate into our CI such that we do not have the responsibility of managing them and they will work in the following fashion.

Deirdre: And if they do not, we drop you.

Alex: Yeah, I mean, give a real concrete example. There’s an open bug right now against OpenSSL for the assembly, for Spark for doing I don’t even know what. And it’s, it’s got some bug in an optimization it has. And you know, the OpenSSL folks have basically said, like, look, Spark assembly is not maintained by the Open SL core team. Like, this is community Maintained, like what I would encourage them to do is say like, this is a bug, therefore, like we’re disabling this optimization. If like the maintainer of the Spark platform wants to like contribute CI or contribute fixes, like, we will accept those. But like, we don’t want to ship this buggy thing and we don’t want to give users like the impression that like, you know, give them, like, we don’t want to carry all of this performance sensitive and buggy code. We would rather ship the slower thing that’s guaranteed to work and put really the onus on.

Like, if the SPARC owner wants that to be a fast OpenSL supported thing, like they should do the work. And so like, you know, if the OpenSSL project like pushed on things like that, we’d be very supportive.

Deirdre: We haven’t even touched on all the work that the Python Cryptography authority has done on moving towards doing a lot of the riskiest stuff in a memory safe language like Rust. But like you, just the two of you and your project did a ton of stuff on your own and we’re.

Thomas: Not, you know, it’s 20, it’s 2025 at this point.

Deirdre: It’s 2026.

Thomas: All of it’s 20. I’m sorry, it’s 26. 2026. It’s like the most scrutinized C code on the planet. All of the low hanging fruit memory corruption on OpenSSL is gone now, right? How likely there was one today.

Paul: Literally today.

Deirdre: The 27th.

Alex: Yeah, we were originally scheduled to record this podcast yesterday and if we had recorded this podcast yesterday, we would not have been able to discuss it. There were several pieces of memory corruption in Open SL that were disclosed today. And like, if we had recorded yesterday.

Thomas: I would have had you with that argument.

David: I’m kind of like with you, Thomas. Like adults understand how to write small bits of C code without like totally screwing it up. Part of that is having the judgment to not write large bits of C code parsers for like length, type, value and you know, deterministically bytes in, bytes out functions. Like we should be able to write in Rust or excuse me, in assembly in C without making huge mistakes. So the people that are working on OpenSSL don’t seem to be able to do this. Many people exist who are capable of doing this. Many of them have been guests on this podcast.

Alex: So I will agree partially with that. Like, folks who are familiar with my work know that like I talk a lot about memory safety as a language level concern and about how in the Long term we need to be looking at C and C replacements or to the extent the C and C standards committees have any openness to make their languages memory safe. But it is absolutely true that you can write small where small is like probably less than a few thousand lines of like C code for well defined tasks that don’t change very often and maintain memory safety. Like that’s, that’s like an observable fact that like BoringSSL is a code base like this that is like a very low rate of vulnerabilities because its maintainers are like very diligent maintainers. They take testing seriously, they just think hard about the changes they are making. But it is also just true that complexity and velocity are real world phenomena. And part of how boring SL is able to be that diligent is by having a very narrow scope that is like roughly the set of things Google exclusively cares about. And OpenSL does intend to, to cater to a larger audience.

It has more features, supports more functionality, and it’s like reasonable and very useful when we compare the set of features OpenSL has that BoringSSL does not. There are things missing that we would like. For example, so complexity and velocity are real world phenomena, Scope is a real world phenomena. And so you need approaches to security that are responsive to those real world constraints. And so we think you just have to have a design approach and like a memory safe programming language is by far the strongest one. To not have certain classes of vulnerabilities, like formal verification is another thing from that bucket for like how do you write certain types of programs very, very safely.

Thomas: I want to talk a little bit more about how you guys are SSL of thesising the open SL library with your own REST code. But before we do that, the thing today was if you give OpenCell a P7 file that is encrypted with an AAD cipher, is encrypted with GCM or whatever the EVP code, the high level OpenSL library, when it goes and tries to parse the P7 file and pull the nonce out of the it’s dir, right? Or it’s BR. Is it BER or DIR in P7?

Paul: It can be either.

Thomas: Wonderful. Okay, when it goes to pull out the non slot of the goofy, right? It spills that goo all over the stack, right? So like that. I guess the first question I have is we were talking about this earlier, but I’m still wondering if this does or does not hit you guys.

Alex: So this doesn’t hit us. While we do have some PK7 APIs that do still use OpenSSL for parsing for reasons we can talk about our PKCS decryption APIs use our own Rust DIR library and you know, totally memory safe parsing, not reachable.

Thomas: This is a little, this is a little off topic but like for somebody who’s asking what the attack surface is for P7 files, what does that look like?

Alex: So pkcs7 is like a pretty widely used container format. Like it pops up in all sorts of places. Like S mime is a pkcs. So like if you’re doing like encrypted email, like not, not like pgp but like, you know what, like what, what Microsoft Exchange will like encrypt your emails with like that’s a PKCS7 format. I think Microsoft’s like code signing format does it like it pops up in all sorts like places like this. Like if the thing you were shipping is like roughly a signature and encrypted blob and like some metadata and like, particularly if it’s like maybe a slightly older standard. Like I think modern, modern cryptographic esthetics or like container formats like this are not particularly useful but like in older things they were like super common.

Deirdre: Mm.

Paul: Yeah. It’s actually. I forget what the underlying weird name for the like standard is, but Apple Pay also actually uses PKCS7 signatures in the backend. But now with OpenSSL, one assumes.

Alex: Certainly there is actually a bunch of boring ssl.

Paul: Yeah, they own their own crypto, but they actually like the underlying APIs for a bunch of Apple’s stuff are actually BoringSSL underneath.

Thomas: I looked today and librassl didn’t have the bug. Librassl in the code where they pull the nonce out is doing an explicit length check. Does boringssll have the bug?

Alex: I don’t believe so, no. Okay, pretty so boring. SL actually published today a whole bunch of notes from past OpenSL vulnerabilities on whether they were infected. What customers of boringSL need to know. And I’m almost positive that this is one of the ones marked like this bug was introduced after we forked.

Thomas: Gotcha. Okay, so like you guys missed this bug. You missed out on all the fun because you rewrote this part of OpenSSL.

Deirdre: I wouldn’t say they’re missing it, Thomas.

Alex: Yeah, we missed this bug there. There were a handful of other bugs in today’s release that, that did impact us. I have to go back and like look, look at the full list to tell you which ones but how.

Thomas: How much of OpenSSL are you.

Paul: Guys going to rewrite and rust anything that’s not cryptography? Cryptography itself, the core crypto. Like we heard that one before we.

Alex: Opened with how that’s false. Yeah. So like we’re. The things I would say is like, we will do anything that is like parsing, that it’s, you know, serialization, deserialization that is like orchestrating cryptography. Like kind of the HPKE that we mentioned.

Deirdre: Canonical encodings.

Alex: Yeah, we’re pretty close to saturated on this stuff. Like almost all parsing at this point. Whether it’s, you know, public keys, private keys, whether it’s like X509 certificates and CRLs. All of that stuff is in Rust.

Paul: Yeah, I think the only path building. Yeah, the only exception at this point is actually what Alex alluded to earlier, which is that because PKCS7 does support BER in addition to dirty, we do have in one code path a fallback where if we can’t parse it using our DIR parser, we hand it to Open ssl because we have not implemented BUR and Rust.

Alex: Yeah.

David: And for those.

Alex: No, we probably won’t. Yeah. For those who are in this, like, Alphabet soup of like BUR and DER just is like causing their eyes to glaze over. The really short version is BER and DER are two different ways of serializing kind of the same ASN1 data. And DER is a subset of bur that like, basically takes away all of the flexibility that BER has. Like Burr will let you do kind of like very bizarre things that makes it like, much more complicated to parse. And like, we basically decided like, BER is a bad idea for all modern cryptographic standards. And like DER is just like, much more compact from a, like, surface perspective.

So, like, we restrict ourselves to DER and like, that’s the only thing you need to care about for things like X509 certificates kind of standards that are less well pended than x 509 is. Maybe I will say it like pkcs7 still have a lot of BER in their ecosystems and we refuse to support BER. And so we will use OpenSSL in the places we have a compatibility need to parse. Brr.

Thomas: How’s that gone for you guys? How’s that? I keep stepping on Deirdre and I’m sorry, but I want to hear the story about how it’s gone. Taking Python cryptography and making it a Rust project.

Alex: Yeah, I think it’s gone.

Paul: It’s like a whole podcast of its own.

Alex: But yeah, and we get it.

Thomas: It was complicated and dramatic and not a great experience is what I’m hearing.

Alex: No, no, I mean, so we, we gave a talk about this at Pycon a couple of years ago that really focuses on like the initial release and like what that migration looks like. But and to be clear, there were challenges and some drama early on where like we.

David: When is early on? Like, how many years ago is this?

Alex: 2022? I want to say that’s not that long ago. 2021.

Paul: No, it’s 2021, Alex.

Alex: I’m getting the exact date because it’s like February 2021. Yeah, yeah, February 2021. We do our initial release. So it’s like five years ago now and the initial release has, has some drama. Like we, we were pretty aggressive in like pushing rust into the ecosystem. Users who were getting. Not getting wheels that. To compile themselves like we’re.

And if they weren’t pinning their versions, like they woke up one morning and like, why is my ansible CI pipeline failing with like no rust C on my path? Like, what is this garbage? But like, we have, with lots of help from like other folks in the community, we have like pushed past that. Like we now we ship wheels for a great many platforms. Like that is no longer a problem. And so like, you know, I think your question is mostly about like, how is migrating our own code been? And like, I think it’s pretty much just been like an across the board win. We have much better performance on like all of our parsing APIs. As we kind of alluded to earlier. We have a much clearer compatibility surface. Like, because we own the parsing, we understand exactly what are the places we’re being lax because like, you know, the specification is like kind of in an HTML style, like diverged from like common practice.

And we know where we’re being strict. We have a much, there’s much clearer abstraction layers between things. I’ll give you a concrete example of. I think it’s just like, better. So we have a bunch of X509 certificate APIs. We used to implement those on top of OpenSSL’s X509 APIs. And so when you did something like sign an X509 certificate, you’re creating a new X509 certificate and you do a signature and you’d pass in a private key to do that signature. But actually that private key had to be an OpenSSL private key.

We nominally had these abstract APIs that you could implement for a private key. But if you didn’t pass an OpenSSL private key, we didn’t have a private key to Pass to the OpenSSL Signature API. So there’s this real abstraction failure and it’s not an uncommon one. You see this in a bunch of things that try to do abstraction layers like this. I believe The Java crypto APIs have a whole bunch of fast paths and slow paths depending on what kind of private key you’ve got. But now that we own x509 parsing top to bottom, what happens when you try to do a sign a new certificate is that we use the public sign API. And like any private key you’ve got, whether it’s one of the ones we provide or you have like a third party implementation of our private key APIs that use it, that I don’t know talks like AWS KMS for example or GCP or like any, any cloud providers key management. Now that just works.

So like we have a much cleaner compatibility surface, we have much more coherent story for things like third party keys. Like it’s just like I don’t have anything bad to say about the migration besides like the initial like stumbling with like the kind of pain of less people having it to adopt to Rust. Paul, I don’t know if you have like a different reflection on this.

Paul: Yeah, I mean I think I generally agree like past the initial teething, like one of the components of that entire project is Alex and I decided that like this was worth the breakage budget. We knew our position in the ecosystem was important. We knew that it was going to cause us pain as well as some user pain. But we wanted to both manage our long term pain as maintainers and also drive down the pain for the adopters as quickly as possible. So we were able to work across the ecosystem, basically blaze the trail such that future Rust Python projects have effectively the ability to deploy with no fear. Where we five years ago obviously had a lot of work to do. On the actual Rust development side, I would say that like the only piece of pain that we’ve really experienced, I’m not even msrv, although MSRV has its own like that’s minimum supported Rust version. For folks who are not deep in the Rust ecosystem, there was some work there we had to do.

But like the only real thing was that in our CI Rust compilation is slower than what we had before. And so we ended up spending a lot of time and energy looking at what it meant to cache intermediate artifacts and make sure that caches don’t do bad things. Because we had a few incidents where our caches were pretty bad, but once we got past that, we were in really good shape. And like, I mean, even right now, there’s, there’s a current feature Alex and I are working on where we were unhappy with the Python APIs that would allow us to express what we needed. And so we’re likely to rewrite this piece in Rust simply so we can have the visibility control that we want.

Deirdre: Yeah.

Alex: So like, I don’t know, if I had to register a complaint, like, my number one complaint might be like, the Rust coverage support is not quite as stable as like Python’s coverage py. This is like the level of like, complaint we have, you know, about five years of like maintaining this Rust code.

Deirdre: So you, you ate the pain of supporting Rust in your. Extremely widely supported. In terms of platforms, a diversity of platforms where it has used and it needs to be supported. Did you have to drop any platform that PI crypto was supported on in order to ship the Rust stuff?

Paul: We dropped no platforms we officially supported. Is a good way to say that one of the tricky bits of a migration like this, and I’m sorry, Alex, I’ll let you go.

Alex: Right, we’re going to say the same thing.

Paul: But yeah, one of the tricky bits about having a project that’s just C in Python is that C and like, Python is not a compiled language and C is a compiler that exists. Like there’s a compiler that exists for every platform under the sun, including things that are weird, like 31 bit architectures.

Deirdre: Yeah.

Paul: And so like, implicitly, when you ship software like this, you end up with consumers at some level who maybe they only want to compile it to prove they can, but there’s a set of folks who are like, we, like, I was able to compile this and therefore it should be supported.

Deirdre: Yeah.

Paul: And so one of the things that did come out of our Rust migration was a much more obvious, like a much more clear and obvious statement of like, we support architectures that have enough support that LLVM has been ported to it. Got it. And one of the, one of the, perhaps most prominent, and Alex and I might be overly patting ourselves on the back for it, but also it really feels like we might be responsible. Is that IBM recent? I guess now it’s about a year ago, but IBM ported Rust to aix and one of their headline messages on the blog post where they announced it was Python cryptography will work.

Deirdre: Oh, that’s pretty nice.

Alex: And like this, this is a very popular.

Deirdre: It’s not Nice, I know, but like the fact that they like, they are that good.

Alex: Positive sum interaction is the way I would say it. Like IBM gets better support for whatever customers AIX has. We can point users at aix. You like show up at our issue tracker and like IBM, like they maintain your stuff and like, I think this is like a good message to like, projects to like when you get requests for like weirdo, particularly commercial operating systems or architectures, like, push back and like try, try to make people go to like the company they have a support contract with and not like pawn it off on you. You know, if you, if you’re not interested in maintaining that.

David: Let’s, let’s talk about like that aspect a little more before we get back to like broader points about OpenSSL. Both you, Alex and Paul have been doing like open open source, I say in quotes, for, you know, like 13 years here. You have more than that. But this specific project, it’s very widely used, but. Well, I don’t know Paul as well, but Alex seems like a fairly emotionally stable person and like you see a lot of discourse around open source of like, oh, there’s all these like people freeloading off me. I don’t enough time now. I hate this project. But at the same time it kind of look over at you guys and you’ve been able to both kind of keep some amount of support for like a lot of, or keep a lot of support for a lot of platforms.

David: You’ve been able to get intel to do or excuse me, or whoever to do aix and like you’re, you’re still chugging along and to some extent like the Rust thing, like, you chose to do that in Rust in part because of your like, personal preferences around memory safety, which I agree with. But like, you could have also just been like, well, we’ll control our own parser by writing C code that doesn’t like, suck. So like you’re able to like kind of push your personal opinions into the project and, and kind of have fun without dying. Like, what’s your approach to this that like, lets you both kind of keep doing this, but also like, doesn’t necessarily result in either the drama or burnout that you hear a lot about in open source. And how do you feel about like, like are you being funded sufficiently for this? Or like, like how does money fit into this, if at all?

Alex: So very early on in the project’s history actually like, Paul and my employer, like gave us both time to work on it. That’s close to 10 years ago at this point for Me, maybe It’s more than 10 years ago. So it’s, it’s, you know, for the last 10 years at least, there’s been a, you know, labor of, you know, my personal time. As for, like, I guess how we think about it, I think, you know, I’m not sure we have like a documented philosophy of this or something, but like, we would like working on this project to be sustainable and enjoyable and a product that is like, you know, advances things we care about in the world. Right. Like, we think, you know, cryptography, the ability to build secure systems is important. Like, we’re, this is like a positive contribution. If we can make that easier in the Python ecosystem, we can advance memory safety.

That is a good thing for the world. And so part of what you hear when you hear us talking about the importance of really robust testing is that for a thing you work on in your spare time, it’s really, really valuable for the way things come to you to be predictable and not emergencies. For example, it is a thousand times more preferable to like, spend some time, you know, getting a PR to green because like, I control when I’m working on that than to have like a vulnerability reported to us. Like, you know, if you’re like a company, you talk about this in terms like shift left and like your developer productivity, but like for in your volunteer project, like, what I’m saying is like, it’s really good to like not have a vulnerability get reported. Like, when I’m busy with life, like, I can, you know, I can take a week or two off this project because it is stable and like, that’s, that’s really good.

Deirdre: And the stuff that you’re working on, the time is not like just trying to debug a flappy CI or like trying to like wasting time just trying to make something functional and workable as opposed to like, hey, here’s a new feature that people want, I need to go ship it, or a new primitive or making something better.

Alex: I mean, we put a lot of time to CI. Like, you know, I don’t know if it’s literally the majority of our time, but it’s really plausible that it’s the majority of our time. But it’s almost just overwhelmingly like proactive time.

Deirdre: Exactly.

Alex: Improving it so that like, when there’s a feature we’re excited about, like, we’re just working on that feature. Yeah, that’s the thing you can schedule and I mean, David, to like, question about like funding. I mean, the way I think I would say, like, particularly for the last 10 years is like, I think working on this project has been incredibly like positive some and I think it’s a concept that like doesn’t get. It’s due these days just in the sense of like we think we provided a thing that’s like valuable to many companies. And even though it is the case, like at least I have not been paid for to work on this in quite a while. Like I’m like very confident. I’ve gotten lots of opportunities, whether it’s to travel and give talks or meet people or just professional opportunities because like I work on this like that, that is for me like an exchange of like, you know, my time and like for like remuneration that like really seems fair and like very positive sums. So like, I don’t know, I don’t know. I don’t have any complaints. How are you feeling, Paul?

Paul: I mean I think I found that like over the course of 13 years, like again, yeah, I got time for my employer when we first started. I have not gotten time since I left that employer. So it has been 10 years roughly since I was quote paid to work on this project. We, I mean, I think a lot of the sustainability for this is that like Alex and I are a small team, right? It’s two primary contributors to this project. Which means that when we want to make major decisions, this is not like a large scale, long term effort. It is a conversation between two people who largely think very similarly. That means we can make big decisions, we can execute against them without a lot of bureaucratic time or a lot of politicking to determine what’s good or bad. Now that has its disadvantages too, but so far inside this project that they’ve been largely advantages.

It is also the case that we have built the project such that when people come and they ask for something unreasonable, we feel comfortable pushing back. We feel comfortable telling people they should not be, they shouldn’t behave certain ways in an issue tracker when they behave in ways that are inappropriate. And we built the system so that it’s enjoyable to use. One of the unofficial rules of thumb Alex and I have used for a long, long time now is anytime the CI exceeds 10 minutes, we spend time on it because it annoys us. And so like those types of things just make it continuously pleasurable to work on. It is also the case that it is a large bully pulpit, right? Like we have a lot of influence and we are cognizant and respectful of the fact that we can use that bully pulpit. But we do want to be able to Use it to like, pursue things we consider worthwhile in the ecosystem.

Alex: Yeah, maybe to really tie these two together. I think for Paul and I, a really big indicator.

Paul: What.

Alex: One of the things that, at least for me more than anything, led to us giving this talk and writing this statement about where OpenSL was, is that we found that working with these new cell APIs, looking at things like Argon 2 or MLChem, it was becoming really unpleasant. If you had a log of all of our chats, you would see the profanity really went up. We were experiencing a lot of frustration and that’s like a pretty marked difference from what came before. That was just kind of not the emotional valence we had about adding new features before. And that was a big signal to us, like, hey, something has gone wrong. We need to take stock of what’s happening here.

Deirdre: And so that basically leads you to. The two of you, you’re generally on the same page about everything and it’s not that difficult for you to finally declare and come to the conclusion that you basically have to move away from OpenSSL for at least some things. For Python cryptography.

Paul: Yeah. So the core thesis of the statement we issued is that OpenSSL as a project has slowly diverged from paths that we find aesthetically appealing, technically acceptable, etc. To the point where we are now actively seeking mechanisms by which we can end our dependence.

Alex: Wow.

Paul: Now that is a difficult thing to do. There are a variety of reasons why, like compliance reasons. We have downstream consumers that care deeply about the support of OpenSSL. We have feature gaps based on, like, what, what the different forks support. There’s a bunch of things that make this challenging, but like while OpenSSL continues on its current trajectory, and to be clear, it is possible for them to course correct, but it is a difficult thing based on the fact that we’ve spent years advocating for it. But if they fail to course correct, if they fail to provide material improvement on the axes that we’ve defined, then we will be trying to, at the very least remove OpenSSL as our default wheel configuration. And potentially based on what Alex and I consider sustainable for ourselves in the long term, OpenSSL entirely.

Deirdre: Do you have any other whale configurations besides OpenSSL?

Alex: Right now we support build against Libre, SSL, boringSL or AWS LC, but you have to bring your own. We don’t ship pre built wheels for.

Deirdre: Those, but it’s not difficult for y’ all to just sort of start experiment with just building those in because you already have the work to link, to hook them in.

Paul: So we’re perfectly capable of doing it right now. The challenge is that like, there’s no concept of like wheel variants that would say like, oh, I want cryptography, but with a different backend. And even if there was that concept, which there’s actually some PEPs that might make that possible, even if that concept did exist, I think that’s not a thing I can expect a consumer to understand the consequences of. Alex and I believe pretty deeply in having this library be the sort of like drop in and just work. And it has secure defaults. And so I think like what we want to do is get to a point where we would just swap the default. Right.

Thomas: So everyone is just like, to a first approximation, everyone’s just going to use the default. And if the default has feature gaps, then you’re randomly going to blow things up for people.

Paul: Exactly. Right, yeah. So like for example, the current state of, the state of the world is that we Support and ship Argon 2ID and script, both of which are APIs that live natively inside of OpenSSL. Not all the forks support either of those. And that meant if we, if we shipped a wheel with those, we would lose the support for those algorithms immediately.

Thomas: But like, it’s more likely that you’ll. Like, this is kind of a normal engineering problem. Right. Like a flag day problem kind of deal. Right. It’s more likely that you’ll resolve that problem than that open SL3 is going to get rid of OSSL param.

Paul: I won’t try and speculate, but I. You might be right.

Alex: Yeah. I’m not a betting person, but like, it seems plausible.

Deirdre: It seems plausible.

Alex: Yeah.

Thomas: It seems like one of us could just sign up for polymarket and set this up.

Deirdre: That sounds like a long, long bet.

David: I mean, it seems like all you have to do is violate your first rule, which you also opened by saying you’ve already repeatedly violated, which is just like write a little bit of your own cryptography.

Paul: Then I got to get involved in fips more heavily and that’s already too much of my life.

Alex: Yeah. Like you end up with things like if you actually like go inside the fips.

Paul: Not yet. Hopefully sometime soon.

Alex: If and when NIST finishes their starts. I lost track of the status of their key derivation function work. But like in theory, maybe someday. But like Another example, like ED448 is, I think, not supported by any of the forks. It is in.

Deirdre: Do you need it?

Alex: Do we need it?

Paul: Whether or not it was wise, we did expose it at one point.

Deirdre: Oh Lord.

Alex: Yeah, and like this is one of those things where like we could, we can make. We in fact have made the list of like what are the things that we ship that like we think are not stupid? Like there’s some stuff that like we expose that like we don’t care. Like I don’t know sec. Tea whatever. Like there’s weird elliptic curves that like if we drop them we don’t think many people would care.

David: Right.

Alex: We would be okay with it. But there’s things like ED 448 or like different KDFs or like I think various like AEAD modes. Like we’ve got a list somewhere that like any one of them like you might look at and you might say ah, how likely do we think it is people use this? We can make an assessment of like how much breakage would it cost to do this? You know, what’s the likelihood? Are there standards that implement this? Like you know, If I search GitHub does it like seem like there’s some projects that use that? But for any of the given forks we’re looking at like a decently sized list of these like I don’t know, 10 or so algorithms and that’s like I don’t know, 10 times the breakage budget of the you know, mean of them. So it’s, it’s potentially non trivial. So like we would like we want to spend our breakage budget. Well is I think the way I would say it, like we’re prepared to break things when we think like the ecosystem our users get like substantial benefits but we have a lot more ability to make changes like avoiding open SSL if we reduce the level of breakage that we incur in doing so.

Deirdre: That does sound like you’re incentivized to implement some of this stuff in Rust to paper over the migration away from OpenSSL to another default backend. That really does and that does sound like what you’re the.

Paul: It’s not impossible but there are there, there are challenges there too because depending upon what we need to re implement like we don’t want our downstream consumers to be silently surprised when, when the thing they thought was fips no longer can be. Similarly like there are there are various like dependency requirements in, in the Rust cinematic universe of of cryptography that are somewhat challenging for us in some scenarios. And so like one of the things we mentioned in our, in our statement was Graviola, a pure Rust cryptography library that is interesting to us in the abstract. It’s nowhere near where we would need it Right now it’s like we’ve spoken briefly with the author and that’s not currently their focus for its adoption, but it’s something that we’re watching with interest as maybe a long term solution as we go forward. And when I say long term, I mean on the 5, 10, 15 year time horizon. Alex and I are genuinely thinking in the long term here because it’s also why we spoke up when we did, because we gave it several years, but also knowing that it will take us many years to migrate off. We want people to be aware of the problems rather than springing this on people at the last second.

Alex: Yeah, yeah. I mean, just in that space of like, you know, compliance questions and libraries. I do. I am very hopeful that Filippo Valsor’s work on FIP support for GO is going to prove as a model that is very valuable. So, like I would say in the, at least in the open source cryptography world, OpenSSL has been one of. It is like the most default choice, like, maybe even more of a default choice than like open ssl. Just as like open source cryptography is in general, like they had, you know, done the work to like build the like back when it was called like the FIPS canister. And I think Filippo has really demonstrated that it is possible if you are a diligent and knowledgeable cryptography Mainer maintainer to like take on this project is not, you know, impossible.

It’s not all consuming. It doesn’t even require changing your library in that like, disturbing of ways. Like go’s cryptography modules are still kind of like a model of like clarity.

Deirdre: Yeah.

Alex: So like, I am hopeful that serves as like a model that like organizations that have felt like I only have one choice will look and be like, oh, it is actually possible. There are other directions.

Deirdre: Yeah, I really hope the way that he was able to get that working for Golang will be a model for like a future possible Rust, like alternative. Like Rust does not have a standard library the way that Golang has a standard library, including all the cryptography that comes, including tos that comes with go. But I could totally see a library project in Rust trying to be validated as a FIPS module the same way that the Golang one did. It just would be its own project as opposed to a piece of the standard library of a language or something like that.

David: So I’ve always said instead of rolling your own crypto, you should build it for someone else and then charge them for the FIP certificate.

Deirdre: Yeah.

Alex: Cool.

Deirdre: Good luck and Godspeed. You’ve come 10 years, what’s another 10 to actually get away from the fundamental underlying foundation of your project?

Paul: I’m sure Alex and I will be complaining about this in our retirement next to each other in the old folks home.

Alex: Looking forward to it.

Deirdre: Aw that’s sweet.

Thomas: Thank you guys very much for introducing me to OSSL program.

Alex: We’re glad to help and thank you guys for having us.

Deirdre: Absolutely. Paul, Alex, thank you so much.

The IACR Can't Decrypt with Matt Bernhard

Tue, 30 Dec 2025 00:00:00 +0000

The International Association of Cryptologic Research (IACR) held their regular election using secure voting software called Helios…and lost the keys to decrypt the results, leaving them with no choice but to throw out the vote and call a new election. Hilarity ensues. We welcome special guest Matt Bernhard who actually works on secure voting systems to explain which bits are homomorphically additive or not and more.

Watch on YouTube: https://www.youtube.com/watch?v=euw_yqAQFI8

Links:

David: No, no, no, no, no, no, no, no, no. No one has ever made anything easier by introducing threshold cryptography. You have at best made something possible. But you haven’t made anything easier.

Deirdre: Welcome to Security Cryptography. Whatever. I’m Deirdre.

David: I’m David.

Thomas: I’m pretty amused right now.

Deirdre: That’s Thomas. And today we have a special guest. Hi, Matt Bernhard.

Matt: Hi there. It’s great to be here.

Deirdre: Thanks. We invited Matt on today because there was a very funny thing that happened in the world of cryptography this past week.

David: You’re shooting too low. This was in the New York Times.

Deirdre: That’s true. Okay.

Thomas: Yes, I think they were in the New York Times because of my tweet. This all stems from my tweet.

Deirdre: Are you sure? I didn’t see your tweet.

Thomas: I decided to be confident about this fact.

David: I didn’t even know you tweeted Me.

Deirdre: Either, but I smashed my phone. So I’m all out of the loop on Twitter at least.

Thomas: So the International Association of Cryptographic Research, or Cryptologic Research, the logic. Yes. The IACR holds, what is it, annual or semiannual elections for roles within that organization. IACR runs a bunch of the major crypto conferences. So these are like the people that manage that whole enterprise. They have elections of all their members, you know, to elect directors of the organization and a president and a bunch of other things like that. They just held their election, which I found out because they emailed me to say that the election had failed due to the fact that one of the trustees of the election lost the cryptographic key that was required to decrypt the results. So they ran the entire election but are unable to decrypt it because somebody lost a USB key.

Thomas: That’s what happened.

Deirdre: Or the file that was on the USB key or something.

Thomas: I choose to believe that it is a USB key that holds the threshold key required to decrypt the IACR election. They use a system called Helios for this whole scheme. And I guess Helios has been used for other things besides this election.

Deirdre: Yes, they’ve been using Helios for a long, long time. And I’ve used Helios and other election thingies and other. Helios has been used and it’s been around for over 15 years. But this one was very funny because it’s the cryptographers can’t decrypt.

Thomas: So we’re going to get into the Helios details and online elections and all that. But I think like a better to start out with is Just what the IACR is. So I’d like to start with the fact that I’m pretty sure half the Internet now believes that every protocol ever presented at an IACR conference is now backdoored by the nsa.

Deirdre: They’re just papers.

Thomas: That was true of the post quantum cryptography competitions. You and all of that stuff is backdoored.

Deirdre: Oh, all of it.

Thomas: This is an actual. Yeah, this is an actual bogus election. This is like the January 6th of cryptography. Somebody didn’t.

David: The count was in fact stopped.

Thomas: Somebody didn’t like the way that count was going.

David: What are they hiding from us?

Thomas: So Deirdre, can you help me understand more? I happen to be a member of the iacr and the reason for that is I went to meet David and Deirdre at Real World Crypto, which is the best of all of the annual cryptography events. Right. Last year it was held. Was it last year? I think it was last year.

David: Two years ago.

Thomas: Two years ago.

David: A year and a half ago.

Thomas: Okay. It was held in Toronto, which is like driving distance from my place. So we drove up, I picked up David on the way and then we went to Real World Crypto to get into rwc. I was required to join the iacr. David disputes that this was a requirement, but I remember distinctly not wanting to be a member of the iacr or rather feeling that it would have no value to me to be a member of this organization. And yes, I am a member. And I know that because I was told A, to vote and B, the vote didn’t work. So you guys could read me a little bit more about what this organization actually does and really what the implications of the vote are.

Deirdre: So it’s just another academic body that runs conferences and lets you. So the flag, the tent poles for being a academic cryptographer is the Crypto conference, which is held in Santa Barbara every year. And it’s been going for 40 years now. I think Eurocrypt, which is in a different place in Europe or every year, and now Asia Crypt. And those are the big three. They’re considered some like the most prestigious academic, like not purely theoretical, but like straight up cryptography, cryptology and you know, a little bit of, you know, attack stuff in the world. There are other venues where you can do more applied stuff that’s more of like a security vent. But for straight up cryptographers who are doing straight up academic cryptography, those venues run and operated by the IACR is where it’s at.

And then they add, they added the Real World crypto symposium a couple like over 10 years ago now and that became very, very popular because it’s not a place where you submit papers and get published in peer review, but you submit presentations and they also get reviewed for, you know, quality and relevance. And it also appeals to people in industry who may not be publishing cryptography papers, but they’re very interested in like what how this stuff gets deployed and results that affect the real world.

Thomas: RWC is the good one because it’s where most of the good attack presentations get published or at least most of the good.

David: Real world crypto is just the worst MTV reality show.

Thomas: I remember it not being an especially good MTV reality show. Do the directors of the ICR pick the program committees for rw?

Deirdre: I think you have chair of the actual conference and the actual symposium you have several chairs and they help choose the program committee and they help us try to find them. Because for example for crypto Eurocrypt and Asia Crypt, you may need like 100 people to be on the program committee because there are just so many submissions to review. I think it’s smaller for real world crypto to review submissions because it’s not full on papers, its presentations. And then there’s a bunch of other smaller conferences for real World for icr. And then the other thing that IUCR does, they run the EPRINT cryptology archive. It’s basically archive where you published all sorts of pre print papers from all over science and academia. But ICR and the cryptographers basically have their own and we don’t know why they just aren’t on archive like everybody every other field but they do and that is a really good place to keep up to date on the latest developments in academic cryptography. Because basically everyone submits a paper there whether it’s just an idea or a very important result that they want to see, everyone to see.

Thomas: So I runs the three most important conferences in cryptography.

Deirdre: Yeah, conferences where papers are peer reviewed and published. And then they also run real world crypto which is very important for more applied industry stuff.

Thomas: So in the field they’re doing essentially the same thing that ACM does for computer science or Usenix or like Springer for the other sciences that are even worse at the stuff.

Deirdre: Spring is a publisher. But ACM and Usenix, correct? Yes, it’s just, it’s specific to, you know, robust quote academic cryptography.

David: For under peer review they’re arguably more competent because they run multiple good conferences. Whereas like Usenix runs well, USNIX runs a few in A different field, but they run one security one, and then ACM runs one security conference and then IEEE runs one security conference. It’s not in Oakland and everyone calls Oakland. But the ICR manages to run more than one top tier cryptography conference, which is actually kind of impressive for an organization to do.

Thomas: Okay, this makes sense. So, yeah, I still don’t know why the New York Times cares about the vote. I do get the. I do get the funny part.

Deirdre: Let’s see.

Thomas: Oh, it’s a fellow. It’s a person like an early career journalist that like got a break on the story. There’s a little blurb about it at the bottom. I’m sure they’re great. I’m just saying there’s a little blurb about this at the bottom. I too was wondering whether this was like a beat reporter at the New York Times that found this out. But no, apparently not.

David: The person who’s assigned to cryptography the whole time.

Thomas: Well, I mean, there’s people that are assigned to the Internet or computer security. Those are topics that actually get covered. I think the entire angle on this story is just that it’s really funny.

Deirdre: Literally. Cryptographers have a fancy way of doing their elections with fancy cryptography. And even the cryptographers can’t hold onto their keys to do their fancy decryption.

Thomas: I think that’s, that’s it among the four of us. Could anybody competently describe how the system roughly works?

Deirdre: So one thing that I did learn, like I’m, I’m threshold pilled because I worked on threshold signatures for several years when I was working when I was at dcash. Helios has, I’m pretty sure, El Gamal encrypted ballots. And that’s kind of funny because. Oh, wow, we are still doing Elgamal in 2025. Okay.

Thomas: This is the last place.

Matt: There are others.

Deirdre: There are others.

Matt: It’s not the only end to end voting library that uses ElGamal. In fact, there are two others that I know of that are used.

Deirdre: It kind of makes sense because of the pro, because literally elgamal is basically like public key encryption with. I’m assuming it’s elliptic curves. It’s not, you know, finite field or something like that. Maybe it’s.

Thomas: You’re assuming.

Deirdre: I looked at the paper and it just, it just said elgamal. And I was like, okay, I have to go dig into the code to actually figure out if it’s, you know, something not as fancy, but we can go see.

Thomas: We could find out on the voting site Right now. So the whole thing is done via a web app.

Deirdre: It is to be a web app.

Thomas: All of this cryptography is cosmetic.

Deirdre: Oh, shush. We have an old, old episode where we can refer to whether or not that you believe in that or not. But no, I do not think the Helios hosting is doing any of the fancy pinning and hashing and website web app transparency stuff that we all recommend for secure delivery of client based apps in the browser. We’re just going to leave that aside.

David: We all recommend.

Thomas: Nope.

David: It is.

Deirdre: Well, you know, if you want to really try to get application level security for a web app, a client side web app anywhere close to like what you can get for a mobile app or a desktop app with, you know, comparable security, you need some extra stuff on top because it’s. Otherwise it’s just tofu, whatever the server gives you. Right.

Thomas: It is. The code for the Helios version that is run for this election, which is hosted on heliosvoting.org is public. There’s a link to at the top of it. And it’s finite field elgamal.

Deirdre: Yes, it is finite.

David: I was going to say this is from 08. Definitely finite fields.

Deirdre: Yeah. Okay, so we have finite field elgamal and as far as I can understand it, it’s using elgamal to basically commit to this stuff and to voting values in these ballots. You have a ballot and you can tick more than one value or you can tick yes or no for a ballot position or whatever, a referendum, which is one of the things in this most recent election. The nice properties of algomal is it lets you add up stuff that is still encrypted. It lets you tally these things in a private way. Then at the very end, if you know the secret, you can decrypt these final values or you have to know enough of the secret or all of the secret. I thought that in this day and age, they were using a T of N threshold of key holders to decrypt because that’s a thing that we’ve known how to do for a very long time. They’re not doing that.

It just sounds like they just have. You have a third and you have a third and you have a third and you have to smush them all together to just get the decryption secret of the tally. The hormone warfare added up Elgamal ballots and then you can decrypt them at the very end.

Thomas: So hold on a second.

David: So to be fair, that’s still a threshold.

Thomas: I feel as if I might be learning. I feel like I might be learning something here. Right. So RSA is famously homomorphic with respect to multiplication. There’s like, there are attacks that work that way. Right. So El Gamal is additively homomorphic.

Deirdre: I think so.

Thomas: Mac Bernard is.

Matt: Well, it’s, it’s, yeah. Added homomorphic by multiplying ciphertext together.

Deirdre: So okay, yeah, yeah. So like you, you multiply the things together but underneath the value is like, you know, here’s, you know, one for Thomas, one for David and yeah, yeah.

Thomas: Matt started this whole thing by saying. Matt started this whole thing by saying that we’ve forgotten more cryptography than he had that he, he’d ever had. But like I didn’t, it’s still true.

Matt: This is the one small sliver of it that I, I know sort of.

Thomas: Well sometimes if it’s cryptography that no one would ever have to pen test, I know nothing at all about it. And Elgamal exists nowhere in industry other than apparently this.

Deirdre: And it’s tough because the papers, the documentation is from the paper from 2008 and we are looking at the updated maintained source code, but there’s not a lot of docs in between here and there that I can see. But yeah, this was a. There are other ways to do private balloting, private computation, private tallying that do involve a T of N sort of decryption scenario. And this is using a slightly different way of doing cryptography that makes it so that you may configure the system all system, not necessarily Halios Halo doesn’t support that yet to have say two out of three. If you have two out of three key shares, because three of the cryptographers that you have trusted to run the election and decrypt the results are available and one of them lost their share, you can still decrypt the tally underneath. And this uses fun stuff like Shamir secret sharing and things like that and lovely polynomials to make it happen. But that is not implemented here. If any one of them lost their share, or not even share, but piece of the key no one can decrypt, everything’s fucked.

Thomas: Why is this the one sliver of cryptography you actually have? What I was asking Matt why this is the one sliver of cryptography actually.

Matt: Has that I actually know about.

Thomas: Yes.

Matt: It’s because when I was an undergrad I had to implement a slightly newer variant of it for the Star Vote project, which so, you know, even before Helios came out, there’s been, you know, the stream of Internet voting and of enabling voters to vote on their phones for all variety of reasons.

Thomas: Right.

Matt: And Helios was a really big and kind of surprising, I think even to Ben himself, step forward in that realm. It was like accessible. He actually productionized it in a way that people like IACR could use it. But it did have some very obvious and serious drawbacks. And so a bunch of people in the academic community picked it up and ran with it pretty much immediately. Like, there are pretty sure forks of the Helios GitHub that have threshold fully implemented.

Thomas: Right.

Matt: There are like, and there have been, you know, maybe not dozens, but a dozen papers written about how to do certain things with Helios and they’re still being published today.

Thomas: Right.

Matt: Like there’s, there are new attacks on Helios all the time, but there are other, other systems that have come out since then. Star Vote was one that, you know, like Ron Rivest and a bunch of folks worked on. Election Guard is probably the biggest name right now in our industry, in the elections industry that came out of Microsoft. It was Josh Benilo who way back in the 80s wrote his PhD dissertation on how to do basically what Helios is. And then with Mixnets at the time, and then it’s come forward a lot.

Deirdre: That’s a thing that I didn’t realize was built into Helios. I thought Helios was just homomorphic stuff, like the niceness of the underlying, like, I, I didn’t think it was like some fancy schmancy, like fully homomorphic encryption going on, but I knew that there was, you know, leveraging the homomorphic properties of whatever the math was under the hood to tally the stuff up. But it does involve some sort of mixing as well to get, to give you more anonymity. Can you tell us a little bit about that?

Matt: Yeah, that I’m not super clear on. The like, you know, the kind of off the cuff read of it that I can give is, you know, when you’re tallying the mixnet typically, and I think Helios publishes a bulletin board of ballots too. Right. So when you, when you vote, your, your vote gets encrypted into a homomorphic ciphertext that when they run the tally, they, you know, multiply the ciphertext together and then decrypt the final tally. But they also publish the encryptions of all the ballots. Yes, individually.

David: Right.

Thomas: I just, I just cast my vote before we started recording and you get, you, you see the whole bullet port of all the votes that are there. Right.

Matt: And so theoretically, after the election is run, the administrators can provide a way to decrypt to sum and decrease. Right. You can implement your own verifier is what they call. You know what this is typically called and I don’t think Helios does it, but newer systems have like Nizix and other fancy things that you can do to. You can prove that this contest was a vote for one. And so there’s only one valid vote in this ciphertext and all that stuff. I don’t know that Helios does that or not.

Deirdre: I don’t see anything to indicate that. And especially because if it has to be completely in the browser sounds doable. Like I know that like fancy cryptocurrency wallets will be able.

Matt: It’s doable.

Deirdre: We’ll be able to do it. But I don’t. I have a feeling that’s just not going to be supported in this Source.

Matt: Like a 2008.

Deirdre: Yeah, yeah. Or, or, you know, even that sounds like a big chunk. That’s a big upgrade and a big chunk of work. And like, I think it’s Ben Adida, who is the. The creator of Helios. He’s still maintaining it just sort of in his copious spare time. I don’t know if that would be supportive. But yeah, having real zero knowledge proofs or at least some sort of.

Maybe not the zkSNARK or some sort of proof on top of it, I think would be a very cool evolution of these sort of systems. But yeah, they have some independent implementations to audit all the ciphertext for valid, which is cool. I don’t know if anyone uses them.

Matt: It’s always the challenge with that kind of technology. And that’s true for not just Helios, but Scantegrity or Predovote. There are a bunch of these kinds of protocols that have been proposed or even mostly implemented and used, but have never been. It turns out that there aren’t enough people who know enough about this stuff, who care enough about the outcomes of the elections and who have the time and ability to do it that they go and do it.

Thomas: I’m 80% sure that Helios itself does verification of whether the ballots are well formed, but I’m not seeing it in the original Benedita Helios paper well formed, huh?

Matt: This may be me like munging several papers together.

Thomas: Yeah, but you’re the only one here that actually understands all this stuff, so we’re just going to take your word for it.

David: I was distracted. Distracted voting. I feel like this, this failed election is really just going to act as a way to get out the vote.

Thomas: Did you vote for, did you vote for the referendum?

David: I did vote for the referendum. Yay.

Matt: This is one of the other, one of the other major problems with, with a lot of these is privacy. Right. And, and Helios has a coerce me function that you can expose how you voted. I don’t think your ballot gets counted when you click that, but yeah, maybe it does.

Deirdre: Yeah. I think they spoil it. I think they explicitly spoil it, or at least that’s what the UI says to the human. They include information to prove how well the ciphertext was formed. But I don’t think there’s anything else about, you know, making sure that things are well formed when you’re not spoiling your ballot to prove that you are able to create the ciphertext with your public key and the randomness that you use to create it. That’s one kind of, well, formedness.

Thomas: And I just checked my intuition on this. So the idea here is if you’re relying on the additive homomorphic property of alchemy, then you can tally the votes without decrypting them. So the well form in this thing is really important because when you’re tallying the votes, you’re not actually decrypting them, you’re just trusting that whatever’s in there. So if it’s like a pick two of three, then you really care about whether somebody did three of three instead of two of three or whatever. Right. And so some kind of system would have to get built to let you check, you know, let you verify the integrity of the votes themselves to make the system secure is that you could.

Matt: Do all kinds of things like have, you know, minus five votes for a candidate or something in a ciphertext that cancel out votes or, you know, it.

Deirdre: Seems like a hard problem to. Well, I don’t know about the specifics of finite field algomal, but it does seem like a difficult problem to verify anything about a ciphertext until you actually have like all this. All you have like the plaintext and the inputs and the randomness and like a public key or something like that and the ciphertext. Otherwise you just have a ciphertext. And as long as it’s like in a range, like you can’t really say much about it until you can actually decrypt it. Right?

Matt: Yeah, there’s typically several. Like in the systems that do publish proofs, there’s like several components, like the ciphertext, we call it the ciphertext, but really it’s like four different things that get published and it’s, there’s like a commit pin and some other stuff that I’m a little vague on at the.

Deirdre: Moment, but okay, that sounds better because there are other systems that use these homomorphic properties like zcash where you’re doing all of these balance computations of like I’m trying to spend a note and I’m going to send it to this thing and you know, here’s all the balances that are, you know, fully encrypted on chain, but you’re doing all this other stuff at the same time. You’re doing a full ZK snark about all the witnesses of all the inputs and you have knowledge of your spending key authority and like all this sort of stuff along with all of these little commitments. And those commitments are with elliptic curves that let you get a lot of that stuff for free.

Matt: Yeah, and that’s actually sort of the central problem in voting in particular is like you both have kind of an extreme need for privacy and a really also an extreme need for public transparency. Right. A way to like you can’t allow any voter to prove how they voted in most constructions because it leads to things like vote buying or you know, vote my way or I’m going to break your kneecaps or whatever. But if you don’t have that, it’s really hard to prove later that everything was well formed if you’re doing, especially if you’re doing homomorphism, that kind of thing. And that’s also where the coerce me thing that I talked about, there’s this notion of voters can kind of prove to themselves because as a voter, why would you believe that the system is accurately recording your vote?

Deirdre: Right, right.

Matt: I vote for candidate A. How do I know that it did that? And so the idea is that you can kind of iteratively spoil your ballot and make the system decrypted. And usually it’s decrypted with proofs of correctness that it did the right thing. Or you can rework the math yourself I guess to show. And so hopefully over time you build statistical confidence that if it was gonna cheat some amount of the time, I would have caught it by now where I’m like 90% confident or 99% or whatever that it’s recording my vote correctly.

Deirdre: And at least that gives you a system wide trust.

Matt: If people are doing it right.

Deirdre: There’s, there’s a possibility that any one ballot could still be, you know, messed with by the system. But like that is a, that is a one off ballot in a Vote that’s hopefully, you know, many, many, many, many more than that. It will not throw off the results. Yeah, and this is, this kind of gets into the, like the difficulty of voting in any, with any technology that’s not just here is my paper ballot. Here it is. Go figure out how like, I created it myself. Maybe I used my pen, maybe I used some, you know, assistive device to produce my marked paper ballot and I hand it in to somebody either via by mail or literally handing it to a human being at the, you know, at my local precinct.

Matt: Putting it into the thing that counts it yourself.

Deirdre: Exactly. And like, you know, in theory, if the computer who is counting my ballot and scanning my ballot is just like totally fucked up and like full of malware or something like that, you still just have a big pile of paper ballots that I, you know, I saw with my human eyes or, you know, my, my human senses that I produced a ballot and then I gave it to you try. And then all of these other dynamics about transparency but privacy, but also, like, I can’t like prove, you know, I voted a certain way, but I know I voted a certain way because I voted and I handed you my vote. Like, all of these dynamics are part of why voting online or voting digitally or, you know, remotely or even with encryption is like a harder problem than basically anything else that we do online, including banking, including cryptocurrency. We’re private cryptocurrency. Like, are we getting any closer? Like, you know, we can skip Helios, but like, are we getting any closer to something that we feel pretty good about, gives us anything close to the kind of like the feel good nature of. Here is my paper ballot that I produced somehow and handed to a human.

Matt: Yeah, I think in the US maybe in many countries, not as much. So. So it’s. US elections are ridiculously complicated compared to most of the world. Like, we have hundreds of items on ballots. Whereas if you vote in Germany, for example, maybe there’s two or three contests on your ballot at a time. Which is why when people say we should hand counter that kind of thing, it also doesn’t really make a ton of sense. Germany, you know, I picked them for a specific reason.

I believe it’s their constitution explicitly says, like, no election can be held with technology that the average German couldn’t understand. And so that’s where they. So like, yeah, so like homomorphic encryption gone.

Thomas: Right.

Matt: In the US because we vote for so many things. We vote for dog catcher. Right. In some jurisdictions we have to use technology to Administer elections. Right. It’s not really optional. We vote for lots of things. We have lots of different languages.

Matt: We’re a very diverse population. We have the Americans with Disabilities act that guarantees your right to. And the Help America Vote act, which tie together to, if you’re a blind voter, for example, you have to be offered the same voting experience that everybody else gets. As it turns out, that doesn’t work very well in practice.

Thomas: But.

Matt: But because of all that stuff, we have to use computers in some facility. Right. And so we have a lot of robust methods to use computers and check them that all rely on right now on paper ballots. Right. As you mentioned. And so Internet voting is still, I think, a pretty far, a long way off. We’re a lot closer to it than we were in 2008, right. When Helios came out.

But there’s still so many. Even, even just the, you know, the specific cryptographic challenges are pale in comparison to all the other problems that we have to. Not every voter has a smartphone to the coercion problem. And this is actually true for absentee voting at home as well to some extent, where if you’re filling out your ballot, not in a booth that is under watch of poll workers or whatever, you could be coerced. And even if you are, we have smartphones now, so you can take a picture of your ballot as it goes into the scanner or something, which may or may not be legal, depending on where you live. It’s complicated. But, you know, there’s that stuff. There’s.

Okay, so I’m voting on my phone. I also have client side malware on my phone that’s watching me vote. You’re creating a single point of failure. So there’s like one server or many servers that are taking in votes. What if they go down on election day? What if Cloudflare or Amazon or Microsoft have an outage? You know, let’s say just to pick an example totally at random, that’s never happened before. So there’s all of these kind of problems that stack up on each other that it’s not. It’s not even just the public evidence secret ballot problem. Like, specifically, there’s so many other challenges that we’re maybe starting to kind of solve in some ways, but not really robustly enough for everyone to vote.

Right. Like if it becomes the single. If you people are doing it, it’s probably okay because the margins are going to be wide enough or whatever. But yeah, there are substantial challenges.

Deirdre: Yeah. And like, there is legislation on a lot of, you know, different Jurisdictions, books of like, there is one voting day. Like you must vote on a day and you know, maybe they have, you know, absentee ballots or something like that. But like, everything else is like you have a single day, it must not fail. Like, you know, what do you do if someone, you know, d some critical service and you know, etc. Etc.

Matt: And so which happens, right? I mean, that’s what causes lines at polling places, right? It’s not just. Yeah, you know, there’s all manner of crazy things that happen. But the fun fact is many jurisdictions in the US and not just here, Canada also has this as well, and a couple of other countries, Estonia’s also at the top of the list, also require Internet voting for certain voters. If you are on a battleship overseas, right, or you’re in an active war zone or just in a country that doesn’t have robust mail, we can’t nail you a ballot. It’s not going to get there in time. And even if it does, it’s not going to get back to us in time. So, you know, Internet, Internet voting scare quotes, right? Has been a thing in the US for 20 or 30 years. But what it has meant historically is I’m going to fax my ballot or maybe email a PDF of my ballot, right? And so we are getting closer to making that situation better, right? Because like, you know, we can talk about, you know, homomorphic encryption all day, but if you’re faxing your ballot at the end of the day, like, so we are getting that, that is already getting better just because it has to, right? Like it’s, it’s too big to fail or whatever you want to call it.

Deirdre: I honest to God, don’t hate the idea of like filling out a PDF of my ballot and like sending it somewhere. Like, I don’t like, security wise, reliability wise, even privacy wise to a degree. I don’t mind that that much. Like all this other stuff, I’m just like, oh, that’s going to, we’re going to fuck that up. Something’s going to go wrong. But like, literally, like, here’s my ballot. I emailed it or I digitally faxed it. Like there has to be some sort of, you know, digital service that gets between that, you know, turns my PDF into like, you know, a dial tone on the back end to fax it to a number. I don’t hate that.

David: It’s all fun and games until you don’t sanitize your PDF file names. Oh God.

Deirdre: Oh God, that’ll be, that’ll be. The next thing is like, we found this terrible PDF parser vulnerability in the critical, like, absentee voting system of such and such an election.

Matt: Well, and we have. Right. I mean, it’s not just the fax and email, but also there have been several vendors who have tried to do some flavor of. Of vote by app.

Thomas: Right.

Matt: Votes is the most poignant one to me because they were a blockchain voting app right in the. And they’re still around, but their heyday was, like, right before COVID and, you know, a couple of security researchers started looking at their stuff and found out they didn’t even use a blockchain, right. Like, it’s. It turned and, you know, when they were transmitting the data, they weren’t masking it. So you could literally just watch the bytes go across the wire and tell who someone voted for because, you know, they weren’t. They were scrambling it or whatever. But it wasn’t like, actually robustly encrypted. So, like, the longer the candidate’s name was, the longer the bytes were that went to the server.

Matt: And so, you know, like, so, you know, it’s.

Deirdre: It.

Matt: You know, it wouldn’t support you voting by PDF necessarily, but, you know, there are, there are better ways to do it.

Deirdre: Oh, gosh, I, I hate, I hate that you didn’t even use the blockchain. You could, you could have. It would have been better than that.

Thomas: I have, I have a, I have a Helios question, even though none of us are necessarily Helios experts here. So if you look, there’s, if you look at the Helios paper or the first Helios paper, there’s like a, like two, four of that paper is what the whole process is and just a couple of bullets. Right? So it’s like, you know, the person who’s voting prepares a ballot for themselves. You can prepare as many ballots as you want, right? When you, you know, when, when you feel comfortable with that the ballots are valid or whatever, you’re like getting predictable thingies on the ballots. You can cast that ballot, which is essentially encrypting that ballot to the private key of the election administrators, to the trustees, effectively. So far, so good. That’s right. That sounds good.

Deirdre: That sounds. They have to do that in some fashion.

Matt: Right?

Thomas: So the key thing on the system, like all of the, you know, the voting systems of this vintage. I guess that’s going to be true of blockchain voting, too. But you cast a vote, it gets recorded by the server on a bulletin board for the vote. Right. Which is what I see when I Cast my ballot for my CR Just now is like, you don’t see people’s names. You see like an identifier. You get like a voting ID or whatever. You see the bulletin board of all of the votes cast.

That’s step two. Everybody can check that and see who’s voted. And then when the election closes and they’re about to go tally all the votes, shuffle all of the votes in the bulletin board. So the votes on the bulletin board as cast are linked to the voter, if only by metadata. Right. Like, you know, when it was cast, you can do traffic analysis to see when it was cast to count all the votes. They’re going to decrypt them, right? They’re going to.

Matt: Not individually, I don’t think.

Deirdre: Not in. Yeah, not individually.

David: Going to multiply all of them together to add them and then decrypt that.

Deirdre: Yes, yes.

Thomas: Yeah, they’re going to decrypt the tally vote thingy. Right. So they do the shuffle step because they don’t want to be operating directly on the bulletin board. Entries which are linked to the identify the identities of the voters, which is why they have all this mechanism to do the shuffle and then to produce a proof that there was a shuffle, which seems like a big part of the core of the system is like the verifiable shuffle. And the safeguard is if you don’t have that verifiable shuffle, people will know the election wasn’t valid. They’ll just say it wasn’t, it wasn’t. Right. But if you, if you skip the shuffle, you can violate the privacy of everybody that voted.

Deirdre: Yeah, it’s, it’s. I don’t think that if you don’t do the shuffle and have a verifiable proof of shuffle that you can’t still do the homomorphic tally and then decrypt it. You just lose the privacy of the, of associating IDs, times of ballot and like literally the order in which those, those encrypted ballots came in, you lose the privacy, but you don’t necessarily lose, like, quote, the integrity of the actual, of the actual results.

Thomas: So leaving the server itself, like the code behind it aside, which might enforce arbitrary policies. Right. From a cryptographic perspective, it is possible to tally all the votes that were cast without shuffling them?

Deirdre: I think so, yes. Yeah.

Thomas: And the only cryptographic safeguard that they give you is you would at least know that that happened because you wouldn’t get the cryptographic proof that they did the shuffle. This is also why they have multiple trustees. So multiple trustees can Provide a cryptographic proof that they did the shuffle.

Deirdre: Oh, I didn’t know that.

David: I mean, you could just like, take a backup, right? Like, you know, cryptographic proof that the unshuffled version.

Thomas: Well, this is kind of my. This is. This is my whole question. Right. And this, this, this gets more generally to voting systems and not just Helios. And I’m also saying this because maybe Benedicta will hear this and yell at me, but, like, do I care that much? Like, it seems like you want more safeguard then. Okay, I know the election was manipulated, right. It’s still a pretty grave privacy violation to decrypt somebody’s vote, right? To know how somebody voted.

If that’s the attack you’re worried about, that’s not an attack on the integrity of the vote. It’s an attack on the safety of individual voters. I’m wondering what I’m missing about this.

Deirdre: So I don’t think the executors of the election, the ones that you encrypt your ballot, 2. Can decrypt individual ballots.

Thomas: No. Yeah.

Deirdre: Your. Your individual ballot, clearly they cannot.

Thomas: Clearly, individual trustees cannot be cripped or.

Deirdre: Else we wouldn’t in this situation. Yeah. So it’s. There’s still a level. It’s. Yeah, like. Like you mentioned there. There’s still a level of like, this value that you cast as your ballot is still protected by the elgamal, the fact that you like it.

Deirdre: You can get a lot of meta information, metadata about the voters and when they voted and at what time they voted, and you can associate. This encrypted ballot was cast first. And based on the server logs, we can see that it was cast from somewhere in European central time or whatever.

Matt: Or somebody tweeted, hey, I just voted in the yes.

Deirdre: Yeah, so I think it’s that sort of thing. But I do not think you can decrypt literally what the very first vote cast by someone who tweeted that they did that, what the value of that vote is.

Thomas: Well, if you didn’t do the shuffle, right, like, just. Just assume you’re doing everything homomorphically. Right. You’d still know roughly what the votes were. Right. Because you know the before and after state of each one of the. Yeah, see, you’re all making faces at me. Let the record show for people listening to this, they’re all making weird faces at me.

David: I’m with you. So I guess you could homomorphic with all but one Y.

Deirdre: Like, you. Like, in theory, you could just be like, cool, the vote, like one. One vote cast. Decrypt the entire thing. Two votes cast. Decrypt the entire thing. And so on and so on.

Thomas: Yeah, so like. And like, this is not like a new attack on the system. Like, this is the whole reason they do this.

David: You would need all three.

Deirdre: Yes, you would. You still need all. All the shards or whatever, you know, the three of three. I’m not even fully sure if it’s three of three or if it’s.

Thomas: I think it.

Deirdre: I think it’s literal. Like, this version of Helios is literally.

Matt: It’s just three.

Deirdre: It’s just like, I need this chunk. It’s not even like three of three, you know, with Shamir polynomials under the.

David: Hood, it’s just everyone gets a third.

Deirdre: Yeah, I think so.

Thomas: Okay.

David: I think so.

Thomas: Even if you. Yeah, okay. So even if you wanted to, like, even if you wanted to break the whole election and violate somebody’s privacy, you need to get all three trustees to do it. After you did that, there’d be cryptographic proof that that happened, or at least there’d be cryptographic proof that you didn’t do the shuffle. But as long as any of the.

David: Trustees are doing the shuffle, there wouldn’t be cryptographic proof that you did the shuffle.

Deirdre: Right?

Thomas: That’s what I mean. Yes.

Deirdre: So the wikipedia page says 2.0. Helios abandoned the shuffle and switched to a homomorphic encryption scheme to make sure that that was kept private. So we may be out of date.

Matt: You could still do this because couldn’t you still, like, decrypt as you went, and then at the end, you still have the original ciphertext? Just add them all together and decrypt the final tally or do the shuffle or whatever, right?

Deirdre: Yes, I think so.

Matt: So I think there’s like, two things going on here.

Deirdre: Yes.

Matt: One is the privacy concern and one.

Deirdre: Is the integr integrity.

Matt: Yeah.

David: Maintain the privacy. On this podcast, we’ll have an indeterminate amount of time in between when we record this episode and when we release it. So you can’t figure time and figure out which vote came from.

Deirdre: Me and Thomas provide non interactive, zero knowledge proof that we, you know, of the time. I don’t know. Something like that.

David: Well, you just messaged Deirdre and she says yes or no, depending on if you’re on the right or left side of the time.

Thomas: I just like understanding why there are three trustees and how they’re actually, like, what the roles of these people are or what the roles of these. These components in the system are.

David: One trustee always tells the truth. One trustee Always tells lies.

Matt: Two trustees. Yeah, three trustees is a party, right? What’s the.

David: All of them are trying to cross the river to get to real world crypto.

Matt: One of them is a wolf and.

David: One of them has a chicken. One of them threw their USB stick in the lake.

Deirdre: I think what I heard is literally there was a file and it got saved down somewhere and they just couldn’t find it. I wish it was just literally there’s a USB stick and I have to plug it in and I can’t find it anymore.

Matt: Yeah, the shuffling thing is still confusing to me in that because I don’t. Does the paper talk about Elgamal?

Deirdre: The 2008 paper does.

Matt: Yeah, it does. Okay.

David: I’m just impressed. Ben has maintained a Python project for like what, 17 years? Like, that’s pretty good.

Deirdre: A solid Django project.

David: We’re even on Python 20027 in 2008.

Deirdre: Like, I don’t think so.

David: Might have been 25 still or 23242.

Deirdre: So unfortunately, even if we do the fancy whiz bang version with like fully homomorphic encryption and threshold decryption and 2 of N or, you know, however, T of N for actually decrypting the. The ballots, the full. The full tally and everything like that, it still reduces down to. You have a key and you gotta maintain that key. Sounds like a very human issue that we just don’t quite have a good way to solve. So. I don’t know, Matt, you seem to have the most experience in this field. Like, are we getting any.

Deirdre: Getting anywhere into a future where like, don’t lose this key is not just like the root of all of our problems.

Matt: I think you’re. You know, there’s. It always devolves to somebody maintaining an X509 cert in an HSM somewhere and then deriving keys from there. I don’t really know.

Deirdre: Yeah, I do think that the actually getting threshold encryption, threshold whatever, working helps so that if you lose one piece, you’re not totally fucked. You can have a configurable T of N. The trouble is that actually setting up all of those thresholdized keys is a whole other rigmarole. You can have a trusted dealer usually, and that’s maybe if you all sit in one place and you do it and you just trust each other, you could just do that. But if you’re not, you either have to just send them via some other secure confidential channel that you authenticate a.

Matt: Channel that you have another key bootstrapping.

Deirdre: Problem, or you do some sort of fancy Distributed key generation thing, which is very, it’s very popular. And they try to make that happen in like kind of the blockchain world where you don’t really trust each other and there’s. You don’t want to have any centralized, trusted authority who’s generating keys and handing them out. But depending on the kind of cryptographic system that you’re using, that can get real complicated too. Like you might have DKGs that have multiple rounds and can fail and on and on and on. And, you know, maybe you need to use something called a broadcast channel. And if you ask a cryptographer who publishes a distributed key generation algorithm in the paper, and you’re like, where can I get. Where can I pull an implementation of a broadcast channel from like GitHub? They’re like, what? What do you mean? Because that thing doesn’t exist.

So, you know, to quote Lee Kistner, cryptography tends to take security or other problems and turn them into key management problems. And that could. But it continues even down the rabbit hole of the threshold stuff, which in theory would help mitigate the. Someone loses their part of the key thing. To a point. And I don’t know, we might be improving it a little bit, but not completely.

Matt: Yeah, I mean, I can say like Election Guard does threshold, it does K of N or T of N. And yeah, you literally sit in a room with your Microsoft Surface tablets. You know, all the trustees come and they, they do a key generation ceremony. So it’s not, it doesn’t really get better than that, as far as I can tell.

David: What. What is Election Guard?

Thomas: Sorry.

Matt: Yeah, yeah. So Election Guard is an open source specification and implementation of end to end. So Helios is like classified as an end to end verifiable voting system. There’s like three properties of end to end verifiability, or it depends on who you ask. But there’s a bunch of different definitions in the literature. I think the most widely adopted one is there’s three properties. There’s cast as intended, collected as cast, and tallied as collected. Cast as intended means I’m the voter, I voted for Bob and the system recorded my vote for Bob correctly.

That’s the Helios coercing thing, where you can decrypt your ballot. There’s collected as cast, which is I submitted my ballot and I now have proof that it was received by the server. So that’s the bulletin board thing where I have the ciphertext and I can see that the ciphertext is in the same place. And again, I’ve convinced myself that the same inputs produce the same ciphertext or whatever, you know, a correct ciphertext and then there’s tallied is collected which is the homomorphic encryption thing. Anyone can grab all the ciphertexts and munch them all together, produce a tally and verify that the ballots, it’s garbage in, garbage out. Right. If the right data went in, then the right election outcome comes out. So Helios is part of a broader constellation of these end to end voting systems and Election Guard is sort of the most not, it’s definitely not the only robust.

Swiss Post actually has an implementation that I believe Olivier Pereira, who also worked on Helios did an analysis of with Vanessa Teague.

Deirdre: Heard about that one. Yeah, yeah.

Matt: And they found a bunch of problems. They went through an open process because it’s a governmental process, so they had to submit for feedback and all that kind of stuff. So Swiss Post is one variant. And Microsoft kind of their goal was like how do we make election security better? Why don’t we just put out an SDK that supports all the end to end primitives so that any vendor like a voting machine vendor or an Internet voting vendor can use it and actually do better than just beating votes and not using a blockchain and saying you’re using a blockchain.

Thomas: Right.

Matt: And there’s actually literally a couple weeks ago there was another competitor SDK kind of thing launched that also is. It was written by Free and Fair and it’s you know, Election Guard and this new thing by Free and Fair that I can’t remember the name of are, you know, they’ve done like, they’ve written up proofs in like COQ and stuff and they’ve like, you know, it’s verifiable, et cetera. Supposedly it’s correct. Yeah. So Election Guard is Microsoft versions of that, Microsoft’s version of that is probably the most widely used in the United States. It’s been taken up by one of the major voting hardware vendors. My employer reuse it for our, one of our applications. And yeah, it’s just, it’s kind of like Helios with a few more bells and whistles. That is just an SDK that you can use instead of hosting it as a web as a wholly self contained app.

Deirdre: So if it’s an SDK like is there like how does it fit into some sort of backend or is it just sort of like all sitting on, you know, basically like a, like a PC that you sit in your precinct or something like that?

Matt: Yeah. So there’s many different ways you can run it. Right. So there’s. That is one of them. And I think that’s what like Heart Intercivic, the vendor that has integrated it, VotingWorks actually also did a pilot with it as well where you have, you know, there is an Election Guard app that is what does the key ceremony and all that stuff and exports the cryptographic material and then whatever thing on the other end of it is, takes in that material and uses it to generate ciphertexts and then you export the ciphertext from whatever that thing is back to the Election Guard machine to tally, you know, and do the crypto. So like we use it for Internet voting for military and overseas voters. Right.

Harden or Civic is using it for paper ballots. Right. So you, you put your paper ballot through the scanner and it, it has a little bit of Election Guard code local to the scanner that encrypts the ballot there. And you can do, you know, the whole challenge decrypt process I think locally as well there.

Deirdre: But that’s, that’s really cool because I hadn’t heard of like the only systems that I heard of was like the Swiss Post 1 and Helios, which is like we have the whole thing and I completely understand the value of that. But also it’s like a big thing that you have to take on if you decide you want to support that. So having kind of like the SDK version, that’s really cool.

Matt: Yeah, it lets the cryptographers focus on what they’re good at and it lets like human factors people or hardware engineers or whoever focus on what they’re good at. And I think that was a really important lesson that came out of like the Star Vote project, which Josh Benilo was one of the cryptographers on. And he is the driving force behind Election Guard as well. Realizing that voting systems are really, really complicated and trying to do all of it at once is maybe not the right approach to get started.

Deirdre: Oh yeah, this is really cool. And I’m looking at that you even support ranked choice voting and all the risk limiting audits and stuff like that. Can we, can we not to completely go off of, you know, Election Guard and things like that, but can we at least talk about how if there’s anything in cryptography you have to get a quote from Ron Rivest and the New York Times got a nice quote from Ron Rivest and he was very nice about it. But Ron, like Ron Rivest is the R in rsa. So if you, if anyone knows anything about cryptography, they’ve probably heard about RSA and Ron rivest is the one, is the RSA, is the R&RSA in his like later academic career he basically has switched to secure voting and verifiable voting. And I remember when I was getting into cryptography like in 2015 or so or whatever, I went to go see a talk by Ron Rivest and he’s just talking about risk limiting audits of paper ballots whole time and he’s not talking about any math or any cryptography at all. And like at the very end he.

Matt: Kind of like handles my jar of ten sided dice that are used for risk limiting audit because you use a random number generator to draw the ballots. You have to generate a random seed as input.

Deirdre: I love, oh my God, I love that so much. And even for that you’re using, you’re just using a jar of dice, not even like a computer based seed. Like what do you think about like, like I complete, at this point in my career I completely am just like, yeah, let’s like as much as possible like try to like collapse down to paper. Like maybe you have to like fax in a P like whatever your ballot from overseas, maybe you have to have some of it is you know, via systems powered by election Guard or something like that. But like at the end of the day you’re, you know, you’re pulling everything down to paper and then you have, you have your paper record and you have like automatic risk limiting audits and things like that. What do you think about that sort of approach, especially in America? Because I’m, I’m an American and so like I’m thinking about our extremely diverse voting systems and all of that stuff.

Matt: Yeah, I mean simplicity is king. I think wherever it can be. The, you know, there are too many challenges. I don’t think we can get rid of technology altogether. Like I said, you know, if you want to know how hard hand counting is, go buy a ream of paper at Staples and count how many sheets of paper are in it and see if you get the same number as the outside of the package, you know, so I don’t think that’s ever going to be super viable. But you know, it’s sort of, this is another one of these problems where there’s like two really important things totally in tension with each other. It’s like the need to accommodate every voter and the need to be intelligible by anybody. So like, you know, there will always be blind voters who need assistance filling out a ballot in some capacity, whether it’s a paper ballot that they mark on a screen and then it gets printed out or, you know, it’s totally electronic. Whatever it turns out, if they print it out, they’re still blind, so they can’t read the paper.

Deirdre: Yeah. Yeah. Awesome. All right. Did we. Did we miss anything fun about the cryptographers not able to run their fancy or at least 2008 flavor of fancy online voting election? We kind of. We kind of touched on, like, voting is a very interesting. It’s a very social process, and there’s a lot of other.

There’s a lot of other things that we do online or do, like, extremely assisted by technology that, like, it’s different. Like, you. You want to talk to your bank. You want to do banking online. Like, cool. That’s between you and your bank. Making recommendations of specific, you know, very. We have very powerful cryptography and technology that we can try to apply, but sometimes that’s not the important thing.

It’s all these other social dynamics that matter a lot more to trust in the system. So I can both understand why people recommend it and also just sort of like, not yet, maybe not yet. We miss anything.

David: Is there a funnier thing for a group of scientists or specialists to do besides, like, cryptographers lose key and can’t count election? Like, like, physicists get stuck in a dumbwaiter. Like, like, can. Can we top this? Like, chemists, like, eat poison berries off of a bush.

Thomas: Yeah.

Deirdre: Being. I feel like the. The demon core criticality experiments, when they were. They had just started making nuclear weapons, and they’re literally. They’re literally like, twiddling two halves of a plutonium sphere with, like, a. Like a flathead screwdriver. And, like, several people died because someone went oopsie. And they.

Deirdre: They have achieved criticality of the nuclear core, like, twice. I feel like. I feel like we can’t really top that one. Matt, thank you very much for hopping on with us to. To giggle about cryptography and nerds who can’t handle their own keys because apparently we’re all human and handling keys and things like that is still difficult for real human cryptographers to do.

Thomas: Pretty sure that anybody could have gotten this right. Twitter is pretty sure that anybody could have gotten this right.

Deirdre: Anybody? Yeah, Anybody. Yeah, sure. Yeah.

David: Yeah. Yeah.

Deirdre: Cool. No, not. Not yet. Maybe we’ll make it a little easier with threshold, but still we have to figure out how to distribute the keys.

David: No, no, no, no, no, no, no, no, no. No one has ever made anything easy easier by introducing threshold cryptography. Maybe you have at best made something possible, but you haven’t made anything easier.

Deirdre: I yes.

David: No one’s taken an existing thing and been like, you know what would make this easier? Well, I would argue some groups and more people.

Deirdre: I would argue. Yeah. And then yes, because literally it goes from this failure mode, which is if one of one of them is lost, everything’s fucked to if one of them is lost, not everything is fucked, but if two of them are lost, everything’s fucked. And then you have to do all the other stuff of distributing the key shares in the first place. So anyway, thank you, Matt.

Apple’s Memory Integrity Enforcement

Fri, 31 Oct 2025 00:00:00 +0000

Apple announced its new suite of memory security improvements from the top of the stack all the way to the bottom, so we dug through what they did and how they did it (performantly).

Watch on YouTube: https://www.youtube.com/watch?v=9FJwOI2PliU

Links:

Deirdre: Iiiiin the trust zone.

David: Exactly.

Deirdre: With white curtains. No, it’s the other way around. In the white room with black curtains.

Thomas: I have nothing to do with any of what you guys are talking about.

Deirdre: Hello. Welcome to Security Cryptography Whatever. I’m Deirdre.

David: I’m David.

Thomas: I don’t know what I’m talking about in this episode.

Deirdre: That’s Thomas.

David: Thomas says that every episode. And yet I. Everyone keeps coming back.

Deirdre: Yeah. We tried really hard to get a special guest for today’s episode on Apple’s Memory Integrity Enforcement and no one from Apple would come on our podcast. So we are talking about it.

David: This should be surprising to nobody.

Deirdre: Yeah, no, like this is a fool’s errand, but we are trying to dig through this very cool innovation in low level operating system security, or system security. And all we have to go on is basically their long blog post. And so we’re trying to go through what the hell is memory integrity enforcement and how is it different than all this other stuff that’s been deployed in, say, Android or arm? So that’s what we’re trying to do.

David: And just know Apple people. We know you’re listening. We know you know who you are. We know that you know that we know who you are. And when we say things that are slightly inaccurate. You could have fixed this, huh?

Deirdre: Okay, so this is the post that Apple released, put out back in September. This is an improvement that’s getting actually.

David: Shipped in iPhone 17, available now.

Deirdre: Okay.

David: I bought one for myself, but I accidentally shipped it to an address I don’t live at anymore and then had to cancel and refund it and I haven’t gotten replaced. Replacement. Yeah, sense.

Deirdre: Very good, Very good. Opsec or something. Okay, so this is. This whole memory integrity enforcement is like a suite of things. Basically. It seems to be a bunch of improvements that they’ve already shipped to their kernel allocators and to their user land allocators, but also how they’re actually managing memory much farther down in the stack. And some of these are becoming available to previous iPod’s and Mac OSes and I assume vision OSes or whatever. But some of them are explicitly because of the hardware and improvements in the chips and the memory integrity and things like that are specifically to the hardware that’s actually getting shipped from iPhone 17 and forward.

And this is explicitly to try to improve the security posture of the entire system against memory attacks, which tend to be some of the most dangerous, costly in terms of the impact and the blast radius, but also are difficult a lot of times on our Podcast we’ve talked about, you know, write your code in a memory safe language and a lot of these vulnerabilities are addressed by writing code in a memory safe language. But you know, there’s a lot of OS code that’s still written in non memory safe languages for very, for one there’s just been a lot of investment in there. You can’t just like throw the baby out with the bathwater and rewriting everything in a memory safe language or the most important things in memory safe language is you know, either impossible, difficult, takes a long time or you know, you have to pick and choose what those things are. But also there are things that you do in your and at like the lower than the OS level, like in your kernel and like at your bootloader level and further down you really need to like get your, your hands grubby in and you can’t just, you have to be doing weird things with memory and stuff like that so you can’t rewrite the world in rust. This is a lot of stuff that’s trying to address that sort of security posture, like deep, deep, deep in the stack in a way that when you have full control tip to tail, top to bottom of your system, they seem to be uniquely positioned to do okay. So we’re just basically going to plow through this post and just branch out from there. IOS attacks, mercenary software, blah, blah, blah. Yes, very important and common denominator targeting, using iOS, Windows and Android. They exploit memory safety vulnerabilities which are interchangeable, powerful and exist throughout the industry.

Thomas: I think the interchangeable thing is actually.

David: A really big deal.

Thomas: Like I think that, I think like it’s a thing I think people are probably not gonna talk about enough. Right.

Deirdre: So are you saying that like if you have your kind of spyware as a service service stack, you basically have something that you can deploy cross platform and then you’re like cool, I’m on iOS, I’m going to plug in this, but if I’m on Android I’m going to plug in this exploit and if.

Thomas: I’m on Windows I think it’s lower level than that. Now I’m talking out of my ass and extrapolating things that we like talk to Mark doubt about and things like that. Right. But I have no inside knowledge into how these shops are organized. But my impression is you’ve got like, you know, you’ve got individual vulnerabilities and then you have a whole stack of enabling software around the individual vulnerabilities in kind of the same way that you would have multiple sandbox breaks in Chrome. Like to get from one area of the Chrome architecture to another. Right. It’s weird to call them components, or maybe they are components, I don’t know.

But there’s techniques that people use to pivot from one kind of exploit primitive to the next exploit primitive. And I think a lot of modern exploit development depends on kind of plugging and playing techniques, right? Like you’ve built code that takes like a write what where primitive from you know, point X to point Y or this kind of type confusion to point X and point Y. Right. And in addition to just trying to solve those, to break those primitives directly, it’s also valuable to make it so that every time you have a new vulnerability, you have to rebuild the whole stack of enablement stuff around it. Right. So that path from the primitive to actually doing something useful has to be built uniquely for every one of these things.

Deirdre: Yeah, that makes sense.

David: It also may be the case that like that path is like the individual components within that path are also operating specific and not just in the like obvious location where like, you know, the part that gives you control of the Windows kernel is going to be dependent on Windows. But like in a browser renderer process, if you can find like a privilege escalation through some syscall that is exposed to the renderer process, then you can like skip the step or you do like a browser sandbox escape. If you can go straight from say a renderer process to the operating system. But how your mechanism for doing that is going to vary platform to platform.

Deirdre: Okay, that makes sense. I wasn’t sure what’s the specifics were about interchangeable, but yeah, that makes sense. Apple improving memory safety Swift blah blah blah. In iOS 15 we introduced K Alloctype, a secure memory allocator for the kernel. Followed in iOS 17 with its user level counterpart Xzone Malloc Secure Allocators take advantage of knowing the type or purpose of allocation so that memory can be organized with it. It makes exploiting most memory corruption vulnerabilities inherently difficult. So I think this is the stuff that’s like getting backported to earlier devices if they can support 15 and iOS 15 and 17.

David: Well it already exists in those devices, so it’s not really getting K. Alloctype is basically an allocator that like looks at the structures that are used in the kernel and then generates a type signature basically based off of the the layout of the various fields in the struct itself.

Deirdre: That’s cool.

David: And then only like then you have like various buckets that are used at the like page level allocation and then you only put objects of the same type signature in the same bucket so that like, you can’t ever say like, have a object that has like an integer in the first eight bytes, then be in the same bucket as an object that has a pointer in the first eight bytes and then a bunch of like stuff to make that actually work in practice. So the idea is that like in a use after free situation, you’d only ever be replacing the object with an object of the same type, which is presumably harder to exploit than an object of a completely different type. Thomas, can you explain what a use after free vulnerability is?

Thomas: You all know what a use after free vulnerability is.

Deirdre: Please explain to our audience.

David: Well, I mean the name is pretty self explanatory, but like, why is it a vulnerability? I actually like didn’t understand this until I worked on Chrome.

Thomas: I mean, I think the type confusion thing might be the simple like you just kind of laid out the obvious case, right? So like, especially in like complicated C and C code bases, like you’re allocating memory and then explicitly freeing memory, and that happens in totally different places on the call chain sometimes, like you might have something fire in response to a timer or something like that, right? So like this is a really pernicious class of bugs. Not even necessarily vulnerabilities, just bugs, right? Like you freed something when you didn’t expect to free something and you held onto a pointer for it. If you induce those bugs deliberately, you wind up with this dangling pointer. And in the best case, like the dangling pointer gets used and the program crashes because it’s no longer mapped to anything. That’s what you want to have happen, right? But an attacker inducing this will set it up so that you freed the memory, you held the dangling pointer, and then it made a whole bunch of other allocations and like really strategically with the allocation pattern picked what your dangling pointer will now point to. So in that situation, like David was just saying, right, you had a struct, it had like two integers in the front of it, and now it has a pointer in the front of it, right? And like the code path that’s holding that dangling pointer somehow responds to user input. You write to the integer, and by writing to that integer, you’re writing a pointer instead of, you know, just the integer. So like you’re kind of, you’re using that piece of, you’re using that piece of memory as two different types in two different locations in the code.

Like the code is confused about what the type it is. Right. And you are now rewriting a pointer out from underneath the code and you can have it write to a location of your choosing.

Deirdre: And this is extremely valuable to an adversary who’s able to just be like, you thought you were doing this, but I’m going to twiddle it and I get to make you do something you weren’t expecting, like execute this piece of code when you weren’t supposed to. And then you can leverage that however you like.

Thomas: Yeah, it’s a way of getting a write what where primitive. Right. Usually a pretty constrained write what where primitive. I get to pick what you’re going to write and where it’s going to be written to. And that usually historically is game over. And making that not be game over. I’m saying it’s game over. And it was probably game over in like 2011.

And it’s been not game over ever since then. But whatever. Kind of one of the big things about MIE is making that not be game over anymore.

Deirdre: Oh yeah, making it not be game over. It’s game over for the attacker. Ha ha ha. Cool. So K Alloc did its nice little thing inside the kernel and then we have Exon Malloc that’s used by user lancode.

David: I would just add that even if you magically do this in the allocator, like doing this can cause weird shit to happen because sometimes you just might want to treat some memory as a different memory and there’s two pointers that are different types that happen to point at the same spot and then like stuff gets weird. Right. Or maybe you want to change something out for something else because it’s the kernel and you’re fundamentally doing unsafe things.

Deirdre: Yep.

David: Like if someone does crap like that and just like a user land C program, it’s, you know, it’s 2025, you have permission to just go slap them. But in the kernel, like that’s just kind of the way the world is sometimes. So just because you have the allocator actually using it can be fairly complicated. Which interesting Apple talks a lot about in their massive KL post from a.

Deirdre: Couple years ago, which I’m just. I keep scrolling through because this is like the first time I’m looking at it. This is in fact ginormous. And I am not a kernel hacker.

Thomas: So I feel like type specific, like general purpose type specific Allocator was new. Right. Like not a super Commodore building program. Primitive. Right. So you have like.

David: Yeah.

Thomas: You have protections on like a page based Level based mostly on allocation sizes. Right. Like you could be strategic about whether you know. And I guess you could put things in different arenas and manually in your code, pick which area things are coming out of. All with the intent of trying to avoid that situation where the struct with the integer and the struck with the pointer at the beginning don’t ever share the same memory. And then like doing that at the level of a type thing. Which requires compiler help, right? I think it requires compiler. Yeah, that’s, that’s, that’s newish.

David: Yeah. So Apple gives a lot of benefit here from basically controlling their own Clang implementation which they rely on to be able to do this in the kernel. There is a recent actual Clang and like C extension typed operator new that I believe. I don’t remember if LLVM like directly or if Apple or Google added it or some combination thereof. But like in C, instead of just overloading operator new which takes a size T and like gives back some bytes or whatever, it lets you overload operator new like a size T and then a type T which is like a 128 bit integer or something. And it just like, like hey, you know, here’s random type information. Don’t ask questions about it. Right.

I think there might be a way to provide it, to define it yourself in code. But the idea is to make like a type aware global allocator. Something you could do in userland C code, but it relies on like C semantics of operating new.

Deirdre: That’s nice. I didn’t know any of this. Okay. I think that’s like the first chunk of memory integrity enforcement which is like stuff they already shipped basically. And it’s the user land updates to Exon Malloc or introduction of Exxon Malloc and the kernel Land chaotic type.

David: Keep in mind the total number of buckets here is limited. The whole point of the way they score the like structs is to try to minimize like impact of where like one thing’s a name and one thing’s a pointer. But there’s an arbitrarily large number, at least in userland of types that you can encounter. And like at some point you have to start reusing buckets.

Deirdre: So in 2018 we were the first to deploy pointer authentication codes in the A12 chip to protect code flow integrity in the presence of memory corruption. This was very successful with Pack behind us.

David: Pack is like a goofy thing because really. Well, I mean it’s not like I.

Deirdre: Know nothing about pac.

David: It’s really hard to describe specifically what Pack does because it can be used as a primitive to just build like your regular control flow integrity. Like forwards edge, backwards edge or only one of the edges. I never remember which one is which. And like basically it boils down to like you replace like the function header in assembly with like a pack aware, jump and return.

Deirdre: Okay.

David: And you’re supposed to get CFI out of it. And then there’s like broader. But the like base concept behind pointer auth is just somehow that like there is a signature in the semi cryptographic sense and every pointer and like that signature needs to be valid for the pointer to be valid. So if you’re just dinking around with pointers like your signature is probably not valid, but I mean or it’s like not valid in the right location. But I don’t actually understand how it works specifically other than like there are people posting pack bypasses. Like there’s at least one pack bypass on Apple hardware submitted to Black Hat like every year, which is the same thing as cet. The like intel control flow integrity. It helps but like at the end of the day like you can usually find a way around it.

Deirdre: Okay.

Thomas: Brandon Azad had a talk about this in 2020 blackout CET or PAC PAC bypasses.

David: Okay, so that brings us to MTE itself or memory tagging extension, which is an ARM specification that is technically in more things than just Apple devices.

Deirdre: Memory tagging extension MTE is from arm. It’s independent of Apple. It’s just a thing anyone can use for ARM chips.

David: Or I believe it’s mandatory to implement an ARM 11 or ARM 10 or something like that. But like nice or it’s not mandatory to implement. You know, it’s a sign, not a cop. Right?

Deirdre: I can’t make you do anything. Yeah, Memory tagging and tag checking system. Every memory allocation is tagged with a secret. This is sort of similar to the pack signatures, except in the cryptographic sense they’re probably closer to max or whatever.

Thomas: Well, hold on. Yeah, MTE tags are tiny, right?

David: Yeah, MTE tags is the 4 bit number. So you’ve got your 64 bit pointer and then somewhere else there is a 4 bit number associated with that pointer and that’s your tag.

Deirdre: Okay.

Thomas: PAC signatures are larger I thought. Right. Like one of the, like one of the, like the model PAC bypasses is finding a gadget that will resign. You know, pointers. Right.

Deirdre: I just don’t know anything about PAC signatures or whatever they’re called.

Thomas: Yeah, they’re signatures.

Deirdre: Okay, cool.

David: I believe PACK is just using some of the High bits in the pointer, it’s not actually making the pointers wider because that would, like, totally screw up everybody’s code. Right. It’s supposed to be transparent. So I think you get like 16 to 24 bits of your 64 bits on an Apple machine or reserve for pack, and then the virtual address space is like, 48 bits.

Deirdre: That’s neat. Okay, so unlike that, MT has four bits that have to be kept secret.

David: But they are kept secret in the sense that they’re, like, not in the pointer. Right. They are somewhere else. They are associated with a pointer, but they are fundamentally like four bits of entropy associated with every pointer that, in theory, like, you do not have access to.

Thomas: And, like, the security model here is more like graph coloring than, like, setting things right. What you care about is a diversity of different tags within the locality of a piece of memory. Like, if you, you know, write. You know, write off the end of one thing to the next thing, you need the tags to be different and you need to not leak the tags rather than signatures.

David: Yeah. The idea is that if you access. When you allocate some piece of memory, it will have some tag. If you then free it, but the point end gets used for a new allocation, it will have a new tag, and the used after freeptr will still have the old tag. And when you go to do something with it, the processor will compare the expected tag to the actual tag and then be like, oh, no, crash your program. It’ll crash your program if it’s in synchronous mode, and if it’s in asynchronous mode, it’ll keep running your program and then crash it later.

Deirdre: Hmm. Okay.

David: Yeah. It will continue execution until there’s a context switch.

Deirdre: I mean, I guess.

David: Interrupt.

Deirdre: Yeah, I guess that’s part of the whole async thing.

David: Yes.

Deirdre: Okay.

David: Much more performant because you can delay the check till later and, like, keep executing the code and probably do the checks less. Because, like, imagine you use the same pointer like, eight times in a row to do something. Like, you really only need to, like, check it the first time.

Deirdre: Oh, okay.

Thomas: Async is, like, effectively free, right?

David: It’s not. I mean, it’s like a one. A little over 1% impact, I think.

Deirdre: Okay.

David: So this has been something that’s been around for a while, but, like, in the sense that it’s been defined, but it just hasn’t really existed in chips much. It’s in pixel phones. I think it’s in, like, Pixel starting in 10 or something like that. Pixel 8.

Thomas: It’s Pixel 8.

David: And so you can actually go into Android Settings somewhere and enable this and apps that are like aware of it can leverage it. So if you turn MTE on in a Pixel phone like Chrome will run itself in Async MTE mode. And in fact this will happen automatically. If you’re in like the Android Advanced Protection mode on your device and your device supports mte, it will get turned on in like Chrome, for example, will start using MTE in Async mode.

Deirdre: Oh, this is a developer option.

David: Yeah, so otherwise it’s in developer option, but it’s not on by default because like it’s a battery hit, just like a performance hit.

Thomas: So, and then synchronous classically has been very expensive.

David: Yeah. Then synchronous has been like double digit percentage expenses.

Thomas: But like, so graphene for instance. Graphene does synchronous in the kernel and Async out of the kernel. And then I’m guessing that the intuition there is you spend most of your time in userland, not in the kernel. So like a double digit percentage hit to a place where you’re only spending a small percentage of your time is not that big of a thing. So you can be. And also there are much more fun vulnerabilities in the kernel. So there’s a higher payoff.

David: Yes. A 1% performance hit on the latest high end phone is not the same thing as a 1% performance hit on an older phone or even a higher percentage hit on an older phone. That’s probably a more realistic comparison. It’s like, okay, it’s a 1% performance hit here, but on an older phone it’s actually a 5 to 10% performance hit. It can be easy to like, be like, oh, I have a MacBook Pro or I have a high end Chromebook, or I have a Pixel. So I’ll just take a couple percent here and there and trade it off when, like when you’re not on the highest end devices, that can actually be much more impactful.

Deirdre: I could definitely see that. Yeah, I just confirmed that if you are enrolled in Advanced Protection and you’re logged into your Google account on an Android phone that supports it, it enables MTE for you. Because I was like, I don’t remember turning this on on my phone. I was like, no, you did. Bye. Bye.

David: You can enable it on an individual device without enabling it on your account, but if you enable it on your account and sign in, it will get enabled on that device.

Deirdre: Yes. Yeah, that’s how it happened. Cool. Okay. I’M going back, that’s general MTE that’s been available to like broad arm devices in general?

David: Well, I wouldn’t say broad arm devices. Right. There was like a spec for this, but it really didn’t exist in hardware for a while. It’s never been in server software. Like Google jammed it into Pixel. We learned that, you know, Apple put it into some of their devices but like it is not cheap. It is like a large percentage of the die area to put MTE into a chip and it is not fast. Like there are other, there are other like things in this vein like CHERI for example that take like much less die area.

It’s like a very small number of gates to add CHERI. But you have to like do a code rewrite where you like. All my pointers are 128 bits. Now let’s see what happens first.

Deirdre: CHERI is also a bare performance hit, right?

David: I’m not sure actually, I think it’s smaller actually. It’s just like really you. To make use it effectively, you have to kind of define pointer domains and code yourself and at some point it’s just like dude, just rewrite it in rust.

Deirdre: Well, you know, CHERI is supposed to. Isn’t CHERI also supposed to help mitigate like Spectre micro architectural attacks to a degree as well? It’s not just about the memory safety stuff.

David: I didn’t think so, but I’m not sure. Okay, I can feel Ben Laurie getting upset listening to this.

Deirdre: CHERI is supposed to be trying to address a whole host of up and down the stack like CPU design vulnerabilities, not just the sort of memory safety stuff that I guess the MIE stuff is trying to address. So anyway, MT has core memory tagging check, memory tagging and tag checking system. This got deployed on Pixel. It’s been available in some places, but there’s costs. Apple conducted a deep evaluation and research process to determine whether MTV is designed with meter goals or.

Thomas: Okay, we don’t need to read, we don’t need to read these parts of the book.

Deirdre: Well, I’m getting back into it.

David: We went to Apple, applied the faman method to MTE and came thought real hard about the problem and came up with emte. Yes, Apple never.

Thomas: The iPhone, which has never been compromised before, now has groundbreaking new protections for the things that was.

David: Never mind the fact that there’s no malfunctor at all on iPhone. Anyway, here’s an entire post explaining how we’re patching security holes on the iPhone. Apple doesn’t really say what EMTE does. Beyond like, it’s just MTE in synchronous mode and fast. I don’t know.

Thomas: My understanding is that Emte is just another name for MTE4, right? Which is a set of like four MTE extensions. It’s canonical pack checking. It’s the one they list in the blog post. The one they list in the blog post is like your global variables or I guess your tech, your BSS or whatever the data segment is or whatever, right? Like you have variables that are not tagged regions.

David: Right?

Thomas: And in standard MTE there’s no checking for that. And in MTE4, I don’t totally understand how this works, but there is checking for memory accesses that transition from a tagged memory region to an untagged memory region. So in theory it should automatically detect, right? If you’re running off the end of a tagged memory region into untagged memory, then the tag has changed even though the new tag is nil. And I guess that wasn’t checked before. And now it is with MTE4.

Deirdre: So this is the ARM docs that Apple linked. Canonical tag checking, reporting all non address bits on a fault. Store only tag checking and memory tagging with address tagging disabled.

Thomas: I thought we already had store only tag checking. Or maybe I just don’t know what store only tag checking is. But I was saying earlier that graphene does like the kernel, asynchronous and then the usual end is asynchronous. But there’s also a thing with them where like reads are synchronous and writes are asynchronous, which I thought that might have been what store only tag checking is. I don’t. I don’t know. Fuck do I know.

David: So we have a few more capabilities around MTE itself with MTE4EMTE and then more importantly, whatever they did on their chips in conjunction with the capabilities in MTE4 coming up, Apple claimed they have done fast.

Thomas: We’re coming up on my favorite section of this post or my favorite sentence in the post, it was like, consider that you could do either async or synchronous mode. Synchronous is the good mode and asynchronous is the bad mode. We could have implemented asynchronous. We would not implement such a mechanism. Apple, please run these things by me.

David: No, the copy speculated the writing. You know, as someone Apple who’s like been making their own chips for years, you could imagine that presumably they didn’t. This isn’t their first iteration of, you know, mte, right? They’ve presumably been experimenting with this and just like not turning it on, like I can’t imagine this is the first time they ever taped out some of the chip that is required for mte. Which suggests to me that at some point someone might have implemented such a mechanism. They just didn’t tell us about it.

Thomas: All they had to do is use a different verb there. They could have just said we didn’t implement such a mechanism and it would have read fine, but they wrote we wouldn’t, which reads so weird.

Deirdre: Depends what you mean by implement. Which in this very, very massaged public facing text might mean implement and deploy and ship.

Thomas: I want to call out here that the graphene project, who by the way, if a graphene person listens to this, we would very much love to get you on and have you go through a dramatic reading of this with us and then call out because look, you hear us, we don’t know what we’re talking. David knows a little bit about what he’s talking about, but I don’t. Right. We could use the help. I want to call out though that the graphene project. There’s an angry thread that responded to this thing. I won’t read that whole thread, but it’s worth reading. And they say that there’s basically no difference that they’ve seen in terms of breaking exploits by having async versus synchronous.

Thomas: Like to them, async is enough.

Deirdre: Okay.

Thomas: Depends on how much you care about what graphene thinks. I want to say I care a lot about what graphene thinks because I.

David: Would research from Project Zero suggests otherwise. Depending on the setup that you’re in, it is what it is. The thing about MTE generally and then particularly about Async, right, Is that like, so you have four bits of entropy with the pointer. And in some cases, like let’s say you’re a web browser that runs like arbitrary JavaScript depending on what the behavior is. When like in the failure case, like if you can just run your exploit 16 times and then, you know, have a more likely than expected value of having it be successful one of those times, if all of the other 15 times are like a huge disaster and you can’t actually write that loop, like maybe that’s a problem. Like if you’re able to just do it in the background and like no one’s really the wiser somehow by like having some JavaScript that then like loads another page that tries it 16 times. So that like that process that you never see is the one that dies because it’s whatever. Then then suddenly like, you know, MTE is not like this be all, end all.

It’s much more useful in a situation where you only get one shot at it or a limited number of tries or a limited reaction time to it. And the more shots you get at it, or the more instructions you get after it fails, like the more likely it is that you’ll be able to concoct a situation in which you can get a tag match and then can do something bad. But that’s all going to depend on like you know what your program is. And of course like web browsers are stuck with the hardest mode of the problem because they’re like, let’s just run a bunch of code from arbitrary sites and like isolate some of it per process and some of it like within the process.

Deirdre: Yeah, for web browsers.

David: And it can all change dynamically. You don’t even get a canonical version of the code to download before you run it.

Deirdre: Downloaded that webpage two minutes ago. Fuck you. You don’t get to rely on that at all. Apple says that always on synchronous MTE across key attack surfaces while preserving a great high performance user experience is extremely demanding on hardware. Well, lucky Apple that they seem to be very good at designing fresh brand spanking new hardware to do everything they need to do. For MTE to provide memory safety in an adversarial context, we need to finely tune the OS to define new semantics and the confidentiality of memory tags on which MTE relies to do what we think we need to do, we would carry out a massive engineering effort spending all of I love Apple, Apple silicon operating systems and software frameworks. Excuse me, I think there’s some computers in Apple that run in the cloud, the Apple cloud, but they were not listed in that list there. So citation needed.

Okay. With the highly successful secure memory allocator work that we’ve talked about before, transform MTE from a debugging tool into a new security feature. And so the thing that they’re calling memory integrity enforcement includes the new memory allocators in the kernel and in user land, enhanced memory tagging extension in synchronous mode and extensive tag confidential enforcement policies. We haven’t talked about that at all and I think that’s down at the bottom. We have to get to that. And it’s built into Apple hardware and software and all models of iPhone 17, iPhone Air, and I think they said in their announcement that it’s going to come to either the next MacBook or the latest MacBook I forget which one soon. Cool. And it seems like the real win here is doing all of these things together.

And the quote novel thing that they did is updating their M chips or their A chips or whatever to be able to do all of this and not like crawl on all the time, synchronously always and not crawl the OS to a halt. They were able to make all these improvements, to do all this stuff all the time. And it’s still a performant iPhone and it’s not killing your battery basically. And that’s the thing that Apple is in a unique position to do to do.

David: Well, I think that like that’s the. Actually the big takeaway is that they’re doing it fast. Like all of this stuff has existed for a while and is like good, it’s effective, but it’s not like 100% effective. And it’s been in stuff for a while like not just Apple. Right. Like Chrome has had partition alloc for a number of years now, which is another user land allocator that basically does ref counting and then zaps the memory once the ref goes to zero in such a way that if it is used after freed, you end up with a crash that only works for key pointers, it doesn’t work for all pointers. And you have to make source level changes that can be automated, but it can be done. You have that stuff in other places.

David: You have had asynchronous MTE on other devices. The real takeaway is that like they bundled all of this together and made it fast such that they like turn it all on by default. Everywhere. Now look is on in like most of Chrome, but it’s not on like everywhere. Everywhere for example.

Deirdre: Okay. Yep. So they’re reviewing the memory allocators. Are you familiar with Lib pass webkits? Leadpass?

David: I believe it’s just their way of basically doing like per object heaps at like the type level.

Deirdre: Okay.

David: Yeah, it’s just like a C E version of doing the type based allocations.

Deirdre: I’ll use type information to decide how to organize memory allocations. So if those are all C, which is not strongly typed, Lib passes C. Okay.

David: All right.

Deirdre: The other two are passing more information about types to the compiler to actually be able to use the type information to do the layout and allocations and all that sort of stuff.

David: Yeah, I mean I think all of these required like some amount of compiler extensions to work in practice.

Deirdre: Use after free. Yeah, the bounds bugs overlap. Yeah, go ahead.

David: I’ll say. Speaking of compiler extensions, I Don’t think they cover this in here at all. But there’s a couple other compiler extensions that Apple has driven and LLVM have been adopted outside of Apple, including Chrome for basically tagging like in C a common pattern as you pass a pointer in a size parameter and basically at the compiler level ensuring that that size parameter is in fact enforced and that there are checks just like you would if you’re using like STD array or STD vector in C that you annotate the function call and then the compiler puts the bounds checks on the pointer axis to make sure that you don’t have spatial memory on safety. And then also like corresponding compiler passes if you don’t want to enforce that just for detecting when it happens. So you can like ban new uses of just like unsafe pointer accesses in C also very effective and can be like slowly rolled out over a code base on like a file by file basis. Like no more raw pointer accesses in this directory aside from the existing ones.

Deirdre: That’s nice. I haven’t heard about bad at all, but I’m not paying very close attention to that side of the world.

David: F bound safety or something like that is the flag for clang.

Deirdre: Cool. And so like this is sort of stuff that’s been kind of going on for years and they’re taking advantage of it for this. And then they’ve already rolled out these improved allocators.

David: Yeah. And to their credit they were driving a lot of it too. Right. Like they have a lot of Clang developers.

Deirdre: Yeah, well, I’m not surprised.

David: And they used to have. What’s this name who like created llvm? Chris Latner.

Deirdre: Cool. Yeah, that’s a. That makes a lot of sense. Okay. Type aware placement policies over secure memory allocators help to work memory corruption. Okay. Yes. Does not hit performance.

Performance is either as the same or better. Allocators can apply protections only at the granularity of memory pages. 16 kilobytes on iOS for smaller allocations. Secure allocators can use page level protections to help prevent memory corruption attacks across different type buckets. However, page level protections are too coarse defending as attacks within the same type bucket. And we use memory tagging to close this gap. So it’s not just like cool, we do stuff at the allocators and then we do memory tagging as well. It’s like no, no, no.

We have to cover the page level and cross page stuff. We via our kernel level and user land level memory allocators. And then we also have to do the Memory tagging stuff because like there’s fine grained stuff that is not covered by the page level memory allocation protection. Cool. All right. And that’s where the EMT is comes in.

David: And to be fair, that’s like most.

Deirdre: Objects, most objects are smaller than the full 16 kilobyte page.

David: We’re not out here allocating pages.

Deirdre: EMT protects against two of the most common types of memory corruption. Buffer overflows in use after free, which we talked about. Buffer overflows Allocator is responsible for using different tags for namering allocations. If a request to access memory spills over to adjacent memory and has a different tag, the hardware blocks it and the operating system can take action and terminate the process.

Thomas: Yeah, this is the easiest one to.

David: Get your head around. Or they diagram it and we covered it earlier. They have a nice diagram with emoji and colors to show how MTE works. It’s not very complicated to understand the core concept. We will save you from explaining the diagrams.

Deirdre: Yes. Wait, that’s. Yeah, that’s the buffer overflow where you’re just going over the type over the area. And this is the one where you’re using after free.

David: They diagram both bound safety and spatial safety and then temporal safety, which would.

Thomas: Be user for free, which, like my intuition for the use after free MTE story is just. It’s like you can free the pointer along with the actual memory.

Deirdre: Nice.

David: More or less.

Thomas: Yeah.

David: I would also just say in modern projects there can be spatial memory safety errors, like when you first learn about memory and safety. I feel like buffer overflow is the main thing everyone learns. But like, in practice, it’s not that hard to mitigate the like 99% plus of your spatial safety things by like using containers in C, using F bound safety, writing sane C code without like limits where you access things like having a span class or a span struct or whatever you call it. Like is fairly common and like enforcing, everybody uses that. Like, you get pretty close to very high coverage of like your spatial memory safety, at least when it comes to containers. Not necessarily like a crap on the stack or whatever.

Thomas: But life cycle is a nightmare.

David: Yeah, life cycle is a nightmare. So in practice, like the most memory safety vulnerabilities that matter, they’re all used after freeze because like we understand how to write a container these days and make it fast.

Deirdre: It’s the ones where it’s like, okay, we’ve handled all of those. It’s like, okay, later in the lifetime of this piece of memory or whatever. It either got used to when it was supposed to be already freed or something to that effect. Because you can’t just like write a container around it.

Thomas: There are intrinsically inter procedural lifecycle vulnerabilities where spatial ones aren’t necessarily. All you have to do is store enough information with the data so that whatever loop you’re doing or whatever write you’re doing into it can just check to see if you’re within bounds or whatever. Yeah, but a lifecycle vulnerability could span 15 different functions called at different times.

David: Yeah, okay, you can enable like hardened Lib C I think with a pound def or maybe a compiler flag or both. That just like puts checks everywhere in like the C standard Lib for example, because like by default only some of the methods actually like do checked accesses. It was less so that like we didn’t know how to do this for years. It was just like, oh, well, the performance impact of putting the checks everywhere is too high, so we can’t do it. We’ll assume the programmer put it in the right spot. But like, what actually happened? Like, it’s like some people got hardened LIBC into LIBC Chrome enabled that like years ago at this point. And then eventually like some other people followed as well. And like, that got the compiler people looking at it.

Then the compiler people were like, oh, actually we can write a ton of optimizations for this because like most of the time that you insert checks, like you can like deterministically prove you don’t need to do the check because you did the check earlier. This happens a lot in like Rust with iterators and stuff. Like the vast majority of the checks end up getting optimized out by the computer compiler because they’re redundant. And so like, once you actually put it the effort into writing those optimizations, then the hardened mode gets faster. But we had like this chicken and egg problem for a while where people are like, we can’t use hardened mode because compiler doesn’t know how to optimize it. And the compiler people were like, we’re not optimizing that because no one’s using it. And it was just like, oh well, actually with like a modicum of effort, like a year of effort from a compiler team at a big tech company, like you can reclaim like the FAST like 1% performance loss or whatever you got for hardened C.

Deirdre: Yeah, okay, we’re trying to zoom through this so we can wrap up before we all have to disappear. Weakness of original MTE access to non tag memory global variables not check by hardware this is nice for attackers. Yep.

Thomas: I don’t get this.

Deirdre: Okay.

Thomas: There’s a thing I don’t get about this.

Deirdre: Okay.

Thomas: Right. Which is like, so the mitigation here is that attackers have to know the tag of the regions they’re coming from. Now, to do this, we’re talking about writing into untagged memory, right? So what is the actual pattern here? This is just a thing where, like, I’m sure this is obvious if you’ve looked at the next point or whatever, but, like, what does it mean to know the region’s tag from like you’re writing from an untagged to a tagged region. What does it mean to know the tag of the tagged region? Do any of us know?

David: I mean, it’s presumably that when you’re accessing the global variable, you’re doing so from some location in code and that location has the tag and you need to, like, know it yourself. I don’t know what it would mean to actually tag the like, instruction segment or like, what that means over. Like, is it. Is it all sent through a function pointer, then that function pointer as a tag? Because the function pointer is in the. Whatever the non data segment is called. I don’t remember.

Thomas: It’s like the centerpiece of how they’re describing ente.

David: Well, I don’t believe in reading assembly. So beyond global variables, they also talk about trying to mitigate SPECTRE or the other common bypass for MTEs to use some sort of speculative execution side channel to read out whatever the tag is. And then on your first attempt still, like, overwrite. You just use the correct value.

Deirdre: This is the tag.

David: They say they mitigate this?

Deirdre: Yeah.

David: Yes, with tag confidentiality enforcement, which they back using their secure page table monitor, which I think is something along the lines of an ARM trust zone or intel sdx.

Deirdre: Is this all we know about?

Thomas: No, we know a lot.

Deirdre: No, we know a lot about the.

David: Secured page table monitor.

Thomas: There’s a paper about it that kind of unwinds the whole thing works out what all the function calls are, all that stuff.

Deirdre: This one?

Thomas: Yeah.

Deirdre: We’ll throw this in the notes.

David: And great job to the authors of this paper whose names will slaughter.

Thomas: Did I find that paper? Was that paper released like seven days ago, maybe?

David: 10Th of October 2025? Current revision?

Thomas: Hell yes.

Deirdre: 12 days ago. Oh, yeah.

David: And that’s V1.

Deirdre: Hell yeah.

David: So I guess they were. We were not the only people intrigued by. Intrigued by this blog post and reference perhaps.

Deirdre: Although this looks like it’s also a master’s thesis. So Maybe they were starting long before.

Thomas: The vibe is that you’re running a big chunk of the virtual memory subsystem of the kernel in like an enclave, I guess. So my understanding was the driving purpose for this originally was kernel exploits that would bounce off of gadgets that would change the page tables and stuff. Like you just. You’ve got control over memory and the kernel. You can bounce around. You can just flip things to be executable or not executable, whatever.

David: Whenever anyone mentions a trust zone, I just immediately think of it to the tune of the song White Room. In the white room. But I want to say cream. But anyway.

Deirdre: In the trust zone.

David: Exactly.

Deirdre: With white curtains. Now it’s the other way around. In the white room with black curtains.

Thomas: I have nothing to do with any of what you guys are talking about.

Deirdre: We need to educate you on your classic proto metal Proto.

David: We need to educate the oldest person in the chat on music that came out before we were.

Deirdre: All right, okay, so those are the three main pieces. Then we’ve got the improved type informed allocate secure allocators. We’ve got the enhanced extended memory tagging extension, whatever. And we’ve got this whatever tag confidentially enforcement, which is basically. They’re storing all this stuff in their trust zone type of dealy that they already had the secure page table monitor and that’s it. That’s memory integrity enforcement or whatever. Cool. Let’s see.

And then they probably. They of course aren’t going to say the specifics of how they made all of this fast enough. But that is like the secret sauce of like how they’re able to ship all of it in the first place. Evaluating pointer authentication instructions speculatively. Yeah, that’s. That’s Spectre v1, right?

David: Yes, that’s Vector v1, which was basically never fully mitigated. We just kind of were like, eh, it’s probably fine. We’ll split stuff at the. Like the kernel will deal with it. If you care about it at a per process level and if you know you care about it within a process, well, just split your stuff into multiple processes. Right. Like that’s what the usual mitigation is, is like figure out what your security boundary is and then, you know, cut it.

Deirdre: Yep.

David: This is why like Chrome has site isolation. Well, there’s a number of reasons why Chrome has site isolation. But the best mitigation for one site can speculatively read private data from another site in the same process is to simply not put two sites in the same process.

Deirdre: Yep. And this is like if you really care about Spectre V1, just run that process on like a core that you trust, that you don’t share with other processes from people you don’t trust and you’re good to go. That’s a bit expensive and getting that isolation is, is kind of difficult if you like to run things on a cloud hypervisor. Oh, sorry. Money please. Let’s see if we can cover the rest of this real quick.

David: Okay, I don’t think there’s much left to cover.

Deirdre: No solution to this problem. Blah, blah, blah.

David: They addressed her with the secure page table thing that we just discussed and then they’re protecting their users with memory integrity enforcement. And that user does not involve me because of my aforementioned inability to input the correct address when ordering a phone.

Deirdre: Protect all users by default. And yeah, Google took a great first step last year when they offered mte. Those are often good for them, but.

David: You technically can opt into MTE without opting into the program for at risk users. But yes, yes, it’s been on the phone for a number of years at this point.

Deirdre: You just have to go in and you have to tap the version number of Android like 15 times and turn on dev options and flick a bit. But you have to opt into it unless you are in the advanced protection program, but even so limited by lack of integration the operating systems. Blah, blah, blah.

David: Well, Deirdre figures out if there’s anything left in this blog post, which I don’t think there is. The other thing that I would add is that this is all ARM stuff, which brings us to the elephant in the room of x64. So like x64, right, is like AMD and Intel and they have some sort of like intra company board that like sets what the instruction set is. Right. Because it was basically an instruction set written by AMD to look like Intel. They are still discussing what the instructions for MTE would even look like on x64. So for all intents and purposes in the like near to medium future you should not expect like mte on any x64 devices. So this is really like an arm64 thing and a subset of arm64 thing.

And so like it’s not clear like these are good hardware features to leverage when you have them. But I don’t think they take away from the need to like write things in memory safe languages as much as possible to like fully mitigate the underlying, the underlying problems where possible. Right. There’s still edge cases with that. Like what happens is your program writes out other code into the process is legit. And that has logic bugs where it writes out the wrong code. Right. Like memory safe languages don’t help Rust, it doesn’t help you there.

But hopefully these are all things that can happen in parallel and should all combine to build a better system. Yes, but in no world can you assume that your software will only run on a device that will have mte, unless maybe you’re Apple in five years or something.

Deirdre: Yeah, and even we’ll see if they even do like emulation stuff still, because they still have the old stuff and they still have a bunch of Apple silicon. So yeah, you won’t even have that even if you’re Apple for a long, long, long, long time.

David: And like we said it is. There is a probabilistic element to all of this. It’s not deterministic. And so it may be the case that we figure out ways to make that 1 in 16 chance your exploit works to be much higher or the.

Deirdre: Lower the chance that it works.

David: The chance that it works to be much higher. Right, like. Oh, right. It could be the case that we figure out like, okay, oh, it turns out there’s this one cool trick to double your likelihood of guessing the tag on the first try.

Deirdre: Okay, so basically the lowest chances for the attacker are right now because this.

David: Is 1 in 16.

Deirdre: Yeah, they could only get better. Yeah. Okay. Use the secure allocators first. Use extended MTE to protect smaller individual allocations within a type bucket. And then knowing where and how we should deploy emte, we could accurately model the tag checking demand of the OS and designer silicon to satisfy it. So yeah, knowing being able to bleed through or look through all these layers of abstraction and control it, control your designs on both sides allows you to optimize our hardware implementation, influence additional software design decisions, reducing overhead of tag structs even further. And like, this is the power that you get by having a full vertically integrated system like this is that you can do all of that optimization work to make all of this work on by default and ship it.

And it isn’t a performance cost, it’s actually like it’s. I don’t know if they have any numbers, but it’s definitely not slower. And I don’t know if it is slightly faster than the previous generation, but it’s definitely not slower, which is not for all the other instances. It is not the case or equivalent deployments of MTE so far that are not Apple that we’re aware.

Thomas: Aware about.

Deirdre: Okay. And then checking how secure it is, any developer can begin Testing the protection including EMT on hardware that supports it using enhanced security settings next code. So if you’re a dev you still have to opt in.

David: But I would also note that it’s kind of when it comes to web browsers, it’s basically Safari only because Safari is the only. The WebKit is the only underlying browsing engine on iOS. But why don’t we. They have a. A diagram or a table further down describing how it breaks various real world exploit changes chains. I have a big diagram here for three iMessages change a Safari chain and some kernel stuff about where it gets either blocked by a secure allocator blocked by EMTE or somehow blocked by both. That’s like I, I think some of the secure. Like it’s not clear to me like this isn’t necessarily a fair way of looking at things.

And yes that like all of these exploits work. Like no one’s doing extra work to get around a mitigation that doesn’t exist at the time they wrote it. Yeah, like you can be like, okay, you know, we reversed this chain from whenever and determined that like nowadays this would be broken in like four or five of eight steps. But like what does that, what does that really mean? And so I think the notable thing for me more in this graph is just like how far to the right is the EMTE circle or icon indicator in each of these chains and the further to the left it is, I suspect that more. More effective EMTE is Right.

Deirdre: And so we’ve got one kernel LPE where it’s very far left and then we’ve got a message imessages chain or messages chain and that’s it. It’s pretty far right for the rest of us.

David: Whereas like the allocators things I almost look at like the opposite direction or like if an allocator change block something very early on it’s just like okay, well they weren’t thinking about it at all.

Deirdre: Yeah.

David: Versus like something like EMTE is more likely to kind of like cut off the base concept but who knows.

Deirdre: Yeah. Cool. I like this. It’s informative. It’s. Yeah cool. Nice stuff.

David: Apple, Apple I think has a team that’s called SEER and a team that’s called Sphere and they’re both on the security team and I find it confusing.

Deirdre: Yeah. And this post was by seer. I don’t know what SPEAR stands for. Platform Software Platform.

David: I don’t know what either of them stand for. All I know is people join them and then you never hear from them again. Disappear.

Deirdre: SEER is Security Engineering and architecture.

David: I assume eventually what happens is everyone that joins either of those teams eventually accidentally walks in a glass exterior wall at the Apple UFO building that they like didn’t see because the wall is glass and clean and it like gives them amnesia and they forget how to interact with the rest of industry.

Deirdre: Apple’s doing its damnedest to be like, no, really, we’re a very, very secure phone. You buy our phones.

David: So we’ll see if anyone introduces some sort of hardware fallout isolation for securing things like jets in the future.

Deirdre: But that’d be nice. Cool.

David: I have a whole blog post about that if you’re interested.

Thomas: Security Cryptography Whatever is a…

Deirdre: oh yeah! Cool.

Stop Using Encrypted Email with William Woodruff

Fri, 22 Aug 2025 00:00:00 +0000

There was a bug in an OpenPGP library which finally gave us an excuse to tear encrypted email via PGP to shreds. Our special guest William Woodruff joined us to help explain the vuln and indulge our gnashing of teeth on why email was never meant to be encrypted and how other modern tools do the job much, much better.

Watch on YouTube: https://www.youtube.com/watch?v=IoL3LfIozJo

Links:

—–BEGIN PGP MESSAGE—– U2FsdGVkX1/OF+EynrukxZnSAXwgksTGSIkQ6s4X9Ns7JgQ2ZymeQAp8uD09MtkJ ce5HOKcjhUkZOMbJl3I5iOcPgSxCGG8KccNXcY6msdAD3pdlmR5cWJpn6+qGwqvo KCsj+DYwFW6tltLBXP/cdnh9z8ktRXqfwQW+uhB5Zcaw28pzmNz/rA0cb0cLGiaX uxp9A0iWhwf2gFpUSiIJyXGLJAc8eeI1LXfISXi7IkowDMp4x+iDbOlrR0d6zCkp IKpNGReokcWhUrlGVONiVUrApZS2fvxQoHgaIvwLl5FM1WdrbQIV41DB+rgtZJhE NSgMkhQ0y1bBAOM25ykRjC/UUS/q0ddXz1ThGi6vRIp4/8vkqOsEXHv5M1oT9FQT UGK3zyffq0FqGBFj6kwVZ0X0JQFmtydZKhSYEPE9s4mcfvxKNQsySK7wlxMerKrf f9ZxOR7rHjE3IfqtoizX8EH+MYy2lRCoCKeLbZd0G1LcVhBhRpoXfqL2IboAWqT+ U8R2eyts7qiNuWQUtmCzKNmaJMS+1M+pVN5ZXAdSqK2OJVJZgO8Ie7q4HVZeAd3G HzP7owf+VerCguOYN41cxGle1QpeFi0xcYHNna1bgbodFZ8eGDOq5yCuvmQa04Xy J4vRv7xcp/v16CniL1rN6KhnzdW2gLky8depnYyhm8NvdMFETA6K6eIYm1roD+C2 wwOOKRxUpTI54ov+HYDDU+HUmpFykSesHQJ75o9m0w7V2kR/+E46olFMhHo8JWnL NsGd5QlD/fyedMXHAjimXuFk/YFnwa1lh4XwSwYm+c8ZnIfrS6oEEdUSwXMCwwVT 7/tMw+ab0YRsx19hBLS41oxMz+DCah+/KDMEHv0I+VxaCH8ZfaKD4tRhduSvcWkn Nat3Xp8/MAmO5xN1U8s1dFvrlnt+yqDz7Wn0kVDiax2dTJVgftetqOkoSVvGdMex 9K0ILUUMEpHYBISIaAc7NjoG4BieSeK7wuzBXdhHutVZVKp2ty+mAd8xPlrmemsX lzBhV/kcmF4rcG4eqoWcKpZQY8ZUDufwhIcNqIZEA+wQoKbmBQCR/NradwUrCAIs AQFMVhSYmr7ffA6Ty0twSWeVMDQmxdW+6gKA3EiTAJkFXPpdkhBUzuZHC7Eeph7D F0Ks8Vu/wzOhNsd2s2wYYF6Dl3xctcOj7eMw8VS1HtExszulM57TnqTDaLGPcX6o m8NORwMEtQrCbJd/fdmoNPN/cXzLPHQj3qVZ0F50iNec6zSnmBLIRX4SAYOqzN/2 icvr98Caa1oX3pUlm9W2Hcz30SXJDxOf+mqH6zL4QTAMs3/K9OkaO9nmyPelwoCw VI1q/PsMpqQhGikdM5hrzg6IcEOg5zpLB6N+wqkcGyXFzI2gSQTWYOv4thrIxPY5 G9yNi4dhU+2+KJCa6aoPyAlyc41Yd3ARTeahHEjtdj6PcueRPQdVm+qWCRp09bp3 oic7ljzMVrPRgdbRrzFyEAIhN9Fi4QZ08/yCLEt/BPG+N8j0cZixoj54SKi07uSO WRDrzGvgSegGCCIFKjAsq9ay0sBm61XLcZqdtj57NpNzd/y/yFYvjEQLyyn8VnFA RwOaM3zjrufNC+kYVkHCYzfvu+JopScZjMiuBXI9v8OTOXlj+Ai97bnftwmpQ263 5vyearRHCNATFNa96Sxd1cLjV+ECUlD4hAZQPyel8groXsyjKaMxoOkaZjG/5MDQ 8KPtes32kjTmneyLSzrUaAD0F4l/iltBXzDNiT6BHD7HJmERbdkoab7+DC1hxxC1 VuOHOX+G/U5NUNjxAercuFOY6kgAH5HM+woGjLUsoc5LESqyPdddeg==

—–END PGP MESSAGE—–

Thomas: Almost all PGP encrypted emails are— they’re encrypted because, you know, people feel cool encrypting it. They’re like play-acting. It’s like a, you know, nerf swords version of whatever it is they’re doing.

Hello, and welcome to Security Cryptography and Whatever. I’m your host, Tom, with:

Deirdre: I’m Deirdre.

David: I’m David. Oh, we did at the wrong time. I’m always second. I’m always second.

Deirdre: I know, but. Oh, well.

Thomas: And with us today is William Woodruff.

I spent, I’m a little wrecked. I spent the day moving boxes and bookshelves and furniture from my mom’s office to clear out some space for her, which is a thing I would rather do than ever read a PGP email message, which is what we are here to talk about with William Woodruff today. The secure email ecosystem. And I kind of think we should kick this off with the reason we’re talking about that this week, which is. I think there was a bug. There was a bug this week in OpenPGP?

William: Yeah. Oh, it was an openpgp.js.

Thomas: Does anyone know how it worked?

David: No.

William: It was a packet confusion of some sort.

Thomas: I was not being serious. Do you three really not know how this bug works?

David: I really do not know how this bug works, and I’m excited for you to explain it to me.

Thomas: You had one job. This is the thing we talked about that you were going to talk about. Oh, my God.

Deirdre: I read the other things.

David: You told me to overread the packet format, and I looked at it and I was like, oh, cool. The new packet formats from 1998.

Thomas: I think we should talk. I think we should talk for a little while, for a very short while, about how PGP messages are formatted. Can I ask if any of the three of you know how a PGP message is formatted?

David: It’s binary data that’s been ASCII armored and for some reason has a CRC checksum at the end.

Thomas: Oh, if only that were the case.

Deirdre: Oh.

David: Go on.

Thomas: This is the point where somebody comes in and explains why it’s not the case. All right, so there’s a blog post from. What is it? The name of the. It’s a good find. Cody and Labs, they deserve credit for this, Right? So they have a vulnerability, they. That allows you to spoof arbitrary OpenPGP messages as valid. And that message opens up with the claim that PGP has a relatively simple packet format, and then points to the RFC where they explain the grammar of The PGP packet format.

Deirdre: RFC 4880.

Thomas: This is RFC 9580. Okay, so an open PGP message is a packet or sequence of packets that adheres to, blah, blah, blah. The following grammar, which is OpenPGP message, consists of encrypted message or signed message or compressed message or literal message. Where a compressed message is a compressed data packet and a literal message is a literal data packet. It goes on and on with this in like a pseudo BNF thing. And any of these things can wrap any of these other things. So it’s like an arbitrarily nested, you know, set of packets, like, you know, type length value packets.

David: And the packets have types. So this is like every network protocol has like a type packet format.

Thomas: So why, why are we so like this? Like, this packet format has apparently been a nightmare for PGP implementers for like a really long time. There was like, in the, up until like, I guess the late 2000s, somebody’s going to call me on this. But it’s somewhere around that time frame there was a network of PGP key servers that everyone used. There was like a global Internet key server network where you could register your keys. This is by itself a bad idea and we’ll get into why that is later. But it existed, it stopped.

Deirdre: It’s a bad idea because the way the keys are used, we have bulletin boards for certain kinds of keys. That is not the worst thing in the world.

Thomas: Yeah, you’re definitely right. And we’ll get into PGP as like a PGP is like a strata for like signing things, for like signing packages and things like that. Versus for secure messaging. Right?

Yes, but like, so the thing that takes my understanding is the thing that takes the key server down is a series of DOS attacks on the key server stuff based on packet parsing problems. Like there are ways to make the parsing of those packets go quadratic so you can send like, you know, fork bombs of PGP packets. William is nodding. So I think William knows something so I can stop talking.

William: Yeah, well, the main thing that I remember was I think the big PGP key server explosion was in, I want to say 2018 or 2019 was.

David: Because that’s far too late.

William: Yeah, shockingly, I would say. And it was, you know, it was trivial to make both GPG and other PGP backends. There’s so many. But the ones as well go quadratic on key person.

Thomas: Which keys and like keys and BGP messages are themselves packets.

William: Yes. Yeah, I guess I’m using key interchangeably with what PGP calls a certificate, which is a set of packets, right?

Thomas: So I was going to say it’s easy to explain and complicated in practice, but it’s not even easy to explain, right, because there’s a grammar in 10, three of that RFC, but then there’s 12 different exceptions to the grammar and all sorts of weird shit happens, and there’s just no reason for any of this stuff to exist in the format. But it does. It’s like a 1990s format that we still live with today, or some people do, right? There was an openpgp.js vulnerability in the handling of that format. And that vulnerability was you take a valid signed PGP message from anywhere and you tack onto the end of it an additional compressed data packet, and that is the vulnerability. So the signature on that message for what preceded the message is valid. Whatever the hell you tacked into the compressed data packet at the end is not valid. It’s just a random thing you slapped to the end of the message. And openpgp.js returns the data from the unsigned thing that you slapped onto the end of the packet.

That’s the whole bug. The whole bug. Which is like, it’s interesting, right, because this is also like an XML DCIG SAML vulnerability type situation. It’s kind of the same idea, or it’s a similar vibe as what’s called XML signature wrapping, where in that format there’s this idea that you have a single XML document and a subset of the tree of that document is the signature. And kind of the way that HTML has IDs for different elements in the document, the signature in that subset of the document has an ID that points back to the part of the document that’s signed. Just saying this out loud, you can hear how fucking crazy this is. But that’s how XML DSIG works. But like, you sort of give XML Basic, you don’t give it a pass.

It’s literally the worst format. Like, literally the worst format that there is, right? But like, open BGP isn’t xml. Like, it’s not. It doesn’t. It’s not supposed to have that kind of flexibility. It doesn’t even. It doesn’t benefit from that kind of flexibility. It’s not like an extensible grammar or whatever.

It’s not like it’s not xml, but they managed to recreate the vulnerability anyways. Like, a funny thing, when you see, like, people in that ecosystem responding to this bug, it’s just like, well, this is an implementation failure, right? Like, and it is an implementation failure, right? Only openpgp.js has this bug, right? But like, there’s the obvious objection to that, right? Which is it shouldn’t be possible to have this kind of whatever. So that’s that.

David: Like, have you ever read PGP code? Like, my, my theory here, I. I did this once when I was trying to figure out, like, you can talk to like, yubikeys through some PGP protocol that’s separate from piv. And sometimes like, yeah, those that lets you do operations that aren’t exposed in PIV, like Curve Q5519. And so I was trying to understand, like, how OpenPGP did this at one point and I, you know, I went to grad school, meaning I’ve dealt with some like, bullshit code that wasn’t written by me more than perhaps in other situations. And PGP was scary, Like, I could not figure it out, like, for the life of me, like, what the code even did. Like, not even like, where it talked.

Thomas: Just.

David: It was very like 1990s C code. And I have a feeling that the packet structure is like, downstream of some imperative C code that someone wrote.

Deirdre: Okay. Because I was going to say, like.

David: Got back solved into some sort of packets format using whatever, like, style of writing C code was acceptable, popular, whatever, in 1990.

Deirdre: Because I was gonna say, like, pre K and R. The format seems like it’s like miserable and would lead to a miserable parser with all these exceptions and like circular. And like, it’s the fact that you have nested, Nested, nested types. It’s a key, but it’s also a packet. But it might also be a certificate. I would think it would be the other way around, but I could totally see it being like, no, no, no. We have code that resulted in a format, not a format that resulted in this gnarly parser code. I don’t know.

William: That’s. My understanding of the history of BGP is that the tail wagged the dog in terms of the standard. The standard came well, well after the set of initial needs were established.

Deirdre: And so awesome.

William: That’s just sort of delicious.

Thomas: I don’t think that’s necessarily a bad thing, right? Like, I think more standards should start. But, like, you want to start with something good.

Deirdre: Yes.

David: And they’re usually like the 90s.

William: Yeah. I think the history, the process itself is just pliable. It’s more. The timing is unfortunate.

Thomas: Sorry.

David: If I recall correctly, like, the early versions of like the Doc file for Microsoft Office was just like, you just mem copied or mem Mapped the struct that they used to represent a document in the program to disk and then like unmap mapped it. And this had obvious problems for years and eventually someone solved it by introducing XML and DocX. But like, same, same story, I think, type of thing where like the format, it’s perfectly fine to do things without standards, but like, if you’re operating under the constraints of the 90s, it’s likely that your format is like a little insane. It is not necessarily what it would look like if you built something without a standard that used a format today.

Thomas: Yeah, yeah. I’m not sure we’ve ever done a proper PGP takedown before. And there’s a lot wrong with PGP like this. Like the signature format is crazy. The way they handle authentication is crazy. Like there’s all this crazy stuff in it. Like if there’s anything like top line important to talk about there. I think, like, generally, if you’re kind of paying attention to us, I think pretty much everyone here mostly is written off pgp.

Every time this comes up on a message board, I’m always like, please find me one cryptographer, just one, anywhere, any, any cryptography engineer that works anywhere that will stick up for pgp. And I’m not sure that exists, right? So like going through the litany of all the things that PGP does not get right is like, I don’t know how super productive that is, but I think there’s a more important thing which is like PGP has two use cases, right? It is a package signing system for packages that people don’t check signatures on. And it is a secure messaging system for messages that no one will ever care to read.

Deirdre: Or it’s a way to encrypt data. But usually that data is a message, not like a file format, although it is also used to encrypt files.

Thomas: Yeah, I mean, that’s a fair point, right? So it’s actually, it’s three things, right? It’s is the two things I said. And then it’s also like encrypting files. And for like a very long time, a thing that really pissed me off was that none of the, like Mac os for instance, doesn’t have like a tool to just password protect and encrypt a file. You have to download something to do that, which means that people, you know, download like whatever the zip program is and then that’s like its own complete nightmare, right? And like, for that problem, like you should use age or ag or whatever, how you, however you pronounce Filippo Sting preference to pgp. But like the big problems with PGP aren’t going to screw you if you’re just encrypting a file, right? Like, I mean, I guess it has a really bad password, kdf. So don’t password, like usually use a random password or something like that, right?

But that aside, right now, yeah, I can’t remember what it was. I just remember that it’s bad. But like, so there’s the three things, right? But like, I think the, like, the important thing to talk about is PGP email, right? It’s, it’s, and it’s, it’s more broadly any attempt to get email to be secure. And like this is a thing that has been setting. This is like the fifth thing in this conversation we’re having where I’ve pointed out that something sets me off, right? But this one really sets me off, right? Which is like, there’s. So for obvious reasons, we are in a time period where we’re reading lots of security guides for activists. It’s a big problem. Lots of activists, you know, doing important work and don’t want to be surveilled, right?

So you’ve got all these security guides and there’s like, there’s two really big tells for me when I’m reading these things that like whoever wrote this was not super plugged in to, you know, serious kind of digital security stuff, right?

Number one is when they uncritically recommend that people use Firefox. I’m fine if you have a, well, a well reasoned Firefox argument, but if it just says use Firefox, it’s open source, you don’t want to, you know, be up in Google or whatever, right? Like that’s a red flag for me because that’s not, that’s not that simple. Right?

But the other thing is any attempt to get people to use PGP for email and you see this all the time, like this is like a really big recommendation that people try to give people. Like they’re trying to get people to do encrypted email. And encrypted email is bad, can’t be made to work.

Deirdre: Thomas, why is encrypted email bad and can’t be made to work?

Thomas: You, you can just disagree with me.

Deirdre: No, no, I’m, I really, I like, tell me. I, I agree with you almost entirely. Please tell me. Because I literally scratch my brain and explain this to a normie the other day and they were like, well, what? Well, why is that then? So on.

Thomas: Well, I mean, I think I Think David. So I was talking to Deirdre. I saw Deirdre’s face and then a blog post that I wrote like five years ago was in my face because she pushed the button. I think David should, should kick this off. Otherwise it’s just going to be me talking this whole time.

David: Yeah, well, I, I think we should go through this blog post by which I mean I will read out loud and pretend I am that streamer who shall not be named. This blog post called Stop Encrypted Email. Stop using encrypted email. I’ve already screwed up reading it.

Thomas: You’re reading about as well as a.

David: YouTuber would read it, which Thomas wrote in 2020 that I thought this was older than this.

Deirdre: 2020 before the world.

Thomas: It has a timeless quality about does.

David: But it began saying that email is unsafe and cannot be safe. The tools we have today to encrypt email are badly flawed. Even if those flaws were fixed, email would remain unsafe. Its problems cannot be plausibly be mitigated. Avoid using encrypted email. Which I think was just Thomas’s point.

Thomas: I think I write in a way that is difficult for people to read on streaming things.

Deirdre: Oh, we’re doing it.

David: We’re doing it. And as Thomas noted, technologists hate this argument because few of them specialize in cryptography or privacy, but all of them are interested in it. And everyone wants to use encrypted email tools. I don’t know if by everyone you really mean everyone, but I think you mean people who write guides for journalists online.

William: I think it’s also nerd currency. I mean, I definitely, when I was a teenager, I was like, man, this is the coolest thing ever. I want to encrypt emails to my friends. Which didn’t go well, but was like nerd prayer at the time.

Deirdre: I think technologists see, like, I can make this work in the golden case. And you may be able to do that, but a lot of security and privacy is like, is not the golden case. It’s the average case or often the worst case. And a lot of that comes down to kind of usability and like defaults of the whole system, which is not a technologist sort of thing. It’s like a usability and design sort of thing. And that’s not necessarily where our. That has evolved over time with the tools that we have available today. And that was not part of how encrypted email came about.

Deirdre: Really.

David: Yeah. So we have like the LARP case that Thomas mentions here of just of what you Know, William was describing of, oh, let’s send encrypted emails to each other because it’s cool. And I set up the software. But then we have the case that Thomas refers to going on in which security does matter because messages can be material to civil cases of discoveries subpoenaed by law enforcement action, all that fun stuff. Journalists, confidential sources.

Thomas: Yeah.

David: And in this case you have like actual harms coming where if the message leaks.

Thomas: I think it’s fundamentally true that almost all PGP encrypted emails are larp, right?

They’re encrypted because people feel cool encrypting it. They’re like play acting. It’s like a Nerf swords version of whatever it is they’re doing, right?

The subtext here is like, when you talk about how shitty encrypted email is, people are always like, well, what else are you going to use? What’s your suggestion? And if you say signal, they’ll scoff or whatever, right?

David: Signal was created by the US Government, Thomas.

Thomas: I, I don’t, I don’t think that’s true. But continuing, right. Like, so like you, it always kind of boils down to like, you know, like the choices are sending plain text email or sending encrypted email. And so you sound crazy when you tell people not to send encrypted email because it might go wrong. The thing I think people need to get their heads around is that those are not the only two choices, right?

The more important choice, like the important third choice is don’t send the email to begin with, right?

Like if you’re coordinating a protest like thing or a direct action or something like that. Like there are very good reasons not to trust any secure messaging system with those messages, right? Like that’s opsec. And like almost all of the discussions about secure email don’t have that premise. They all have the premise that the message has to get sent, right? And that can’t be true.

Deirdre: I do think there are some systems deployed out there that are like in our little email system where we control all the ends we require pgp, we require, you know, there’s other, there’s other things that are kind of like BGP and that like you have a message encryption key that’s encrypted under some other key, but it’s all still like bolted onto email and you can still send a plain text email and it’s really hard to enforce that in practice.

David: That stuff is all mostly S mime, which is like, yeah, S MIME is different. Separate discuss technology but like, kind of same concept but like there are ways to deploy S mime mildly effectively within the context of a single enterprise and get like exactly something maybe out of it. Out of like.

Thomas: I think most of these arguments will apply to S mime as well.

William: I would agree with that. I mean S mime is the. The basic flaws is present in both cases. The only difference is that S mime has the. The benefit of actually having a community because standards body, it’s I guess somewhat serious.

David: And you can configure like most, I think web like organization like enterprise Webmail now to be like, use S mime and you have to use S mime for emails within my organization. And like here’s the key server now like does that actually do anything if like the keys are all escrowed somewhere else? I don’t know. But if you’re really concerned about the emails existing in plain text on the mail provider server, you can understand why people might like this.

Thomas: So you are thankfully giving up on the premise of just reading this straight through, which I appreciate. Right. So like what I’m going to do is just introduce the first argument and then let you discuss and tell me if I’m wrong.

Deirdre: Okay.

Thomas: All right.

So my first argument, no matter whether you’re using S mime or PGP or the secure email system of the future, you have this problem, which is that ultimately if you’re using a system that defaults to plain text, wants to send plain text, eventually you’re going to send plaintext. Which is to say like everybody who’s ever used PGP or S mime in anger. And at a security consultancy I ran in the mid 2000s, we used S M for everything, right? Like inevitably somebody will respond to your message with an unencrypted reply which will include your message that you sent originally encrypted. Everybody who has ever used secure email has seen this happen. This is the thing. If you are, if you’re a journalist or if you’re like, you know, you know, organizing or anything like that, that can’t happen. You’re talking about like life and death there, right? And so the first reason that secure email is completely broken, right, is that that can happen. Tell me if I’m wrong or tell me or commiserate with me.

Deirdre: I think of your. This whole blog post from 2020, this is the strongest argument. And this is also the argument that some people had about the old school variant of, I think it was signal when it was tech secure, text secure, which was like it was encrypted chat over sms. It was using the best ratcheting cryptography on top of the SMS messaging protocol that was the in the clear visible to your mobile provider messaging protocol to start and that it was definitely like be careful, you can send a end to end encrypted chat message on Tech Secure or you may, you know if you are sending it to the wrong person, you may be sending it in the clear. And this is, this is also kind of what happens in my imessage to this day, which is like you use one client to send a chat message but you may or may not know that going to the non iPhone receiver phone number it will be in the clear. And if it goes to the iPhone receiver or imessage receiver it will be end to end encrypted. It’s an unfortunate failure mode for like signals way like years and years and years has been all signal clients are end to end encrypted. There is no accidental sending of a signal chat message or or WhatsApp chat message.

After they migrated their entire client base to end to end encryption, they originally were sms, they were in a nice space because they were SMS and then they migrated the whole thing to end to end encryption. Whereas signal in the very early days was kind of this, possibly both case. But that is impossible with Signal. Now everything is end to end encrypted by default. That is impossible in WhatsApp everything is end to end encrypted by default. Even though it has a little bit less metadata privacy then signal. That is not the case in encrypted email. You might have S mime, you might have this pgp, you might have everything nicely done correctly.

The protocol is still a default plaintext protocol. You are layering this extra crap on top of a default plaintext protocol and it’s up to you to never fuck up. Like what is it? You have to be perfect all the time. The adversary only has to get it right once, something like that. Or you have to fuck up once and the adversary just has to catch you. That’s the case for trying to make end to end encrypted email work. And we’ve learned those lessons of why this is bad in other places for secure communication. And it just doesn’t seem like we’re ever able to make it work with email.

Signal, WhatsApp. All these other imessage aside, they aren’t on top of the default plaintext protocol anymore. They completely moved away from it. Email is still plaintext by default. So I think this is the strongest part of your arguments here.

William: Yeah, I think kind of a funny thing that keeps happening is every once in a while someone who defends BGP will bite the bullet on this and they’ll say, well, what we’ll do is we’ll control the client and we’ll force the client not to send plaintext responses. And that gets to the argument that I’ve seen honestly before, which is that, well, if you’re going to do this entire thing where you build the whole ecosystem around PGP such that you can’t use PGP wrong, why not simply do the easier thing and not use pgp, given that you’re going to break compatibility anyways? Yeah, that’s like the Delta Chat thing. I haven’t really looked too closely at what they do, but their whole thing is they claim to do the ones who are finally done it. They finally crack the code on encrypted secure email, but they do that by totally breaking the compatibility assumptions in email.

Thomas: But I mean the one thing and that like you do that, the one thing that you are retaining from email is the possibility of being compatible with somebody who won’t encrypt their messages. That’s all you’ve saved.

Deirdre: Well, also like the sending of messages solution, like I think people are, they want to use the thing that already works, which is like the modality of sending emails, but they want to do it securely. And so they it like it’s so I can see it being so easy to just be like, well, we just don’t send emails. It looks like email smells like email, but it’s not email. But then people like, well, why can’t I email this person who uses this client who that is supposed like, it’s not secure, it’s not set up to take my anti encrypted email. And then you kind of, you’re back at square one, man.

David: I would love it if I couldn’t accept email from people. So.

Thomas: There is that subtext.

William: I think there’s a lot of like, I think about this a lot with like, with like protocols in general. There’s a lot of like nerd pattern matching. People love the username at Domain Scheme for things. And I think email in that sense is very comforting. And so the idea that you can do encryption on top of that is especially comforting.

Thomas: Speaking of speaking of the thing that users love about this, which is the username @Thing. Right.

My second argument, which I think might be stronger than the first argument. So I’m waiting for you guys to tell me I’m wrong About this. The second argument is for a serious adversary, you know, if it’s a, you know, a state level adversary or whatever, the metadata surrounding the message is often, maybe even usually just as valuable as the message itself. Right.

What they want to do is roll up the network of who’s talking to who. They’re probably starting from a point where they’ve got like some particular person or contact that they know they’re targeting and they’re just trying to work out what the network is like, who they should like expand surveillance to and all that. Right.

So metadata, super, super important. And email doesn’t just like leak the metadata. Email proudly publishes the metadata. It’s a store and forward system where every time you send a message, no matter what you’re doing to encrypt the content. The funniest thing about this whole thing by the way, is that PGP email doesn’t encrypt the subject header, which is like the subject header isn’t even metadata, it’s just message. Right.

It’s part of the, it’s the summary of the message. Right.

Deirdre: I hate this.

Thomas: But that aside, like the two in the frame of that message and that graph that you build of who’s talking to who, like this is the entire reason why signal asks for your phone number so they can draft off of your local contact list and not maintain a server side contact list. Because if they had that server side contact list, somebody would eventually target them for it, legally or otherwise, and get it and then have the entire graph of everybody who’s talking on the service. By the way, if you use like a secure messaging system where like you go from device to device and you just automatically have the complete contact list everywhere, you should ask yourself how that’s working, right? Because if the way that works is that they have a server side contact list, they’re keeping the whole graph of who’s talking to everybody. Like server side just there, right?

Deirdre: Yeah, yeah. The imessage and Apple like migration tooling and now the signal migration tooling from device to device has like become very advanced to avoid this scenario in particular, they literally take everything on your device. You do a little bit of a diffie Hellman handshake to make sure that you do a daisy chain of off and you’re authorized to move things from an old device to a new device and they go from device to device. There’s nothing going up in the cloud really other than I am registering a new device like at timestamp. Like that’s kind of it. That’s going from device to device. If you’re not doing that kind of like kind of little dance protocol between devices and things just show up on your new device. It’s because it’s up in the cloud and maybe there’s some sort of password and maybe some of it’s encrypted or whatever.

But going from device to device and not going up through somebody else’s computer is less risky and less exposed. The other part about the contact list being public and available and subpoena able or hackable or whatever, Signal’s done a lot of work to keep as much metadata about who’s talking to who, who’s in what groups, what the groups are about, the profile pictures and aliases and nicknames of people in groups and between people completely encrypted and private and not accessible or visible to Signal the service. But that has involved a lot of advanced cryptography that no one else does. WhatsApp doesn’t do it. A lot of these advanced, you know, end to end encrypted messengers that aren’t super popular yet. They’re not quite there yet either. Signal has done a lot of work and that was definitely not available when they were kind of up and coming. And that’s like why the bootstrapping of your local contact list of phone numbers in your phone, which is just on your phone and does not get uploaded and none of that occurred.

And it’s sort of like the historical legacy that’s kind of inherited into Signal doing that. Syncing privately is a ton of work and Signal may be the only encrypted messaging service that could do it. And they’re still not doing it because it’s very difficult.

Thomas: Like it’s going to sound, I think a lot here. Like we’re just boosting Signal and like really just use anything but email. And I don’t have this much of a gripe. Right. It’s just email is the problem. Right.

Use Matrix. That’s fine. I have things to say about Matrix, but I think Matrix is generally a well intentioned and heading in the right direction project. Right. Like there’s lots of different things you can use just matter most. You should, I guess, matter most.

William: The email argument or the rather the metadata argument with email is that email is uniquely profligate with how much metadata it encourages everybody to use. Like all the email clients have emoji reactions now and those are in metadata and those are also part of the message semantically in metadata. And so now people, I think probably don’t realize the five People will both use PGP and the emoji reacts in Gmail or something. You know, clear text emojis.

Deirdre: I hate that and I love emojis.

Thomas: Do we know this is. This is. You’re breaking news here. This is. So how does this work? Is it like MIME headers that get attached to the add?

William: I can’t remember what the Gino one is, but the microphone is like XMS React or something like that. And then it’s. I would have to. I would have to look up the exact details.

Thomas: But it’s like you can just off the top of your head this. You don’t actually have to have it, right? But it’s like. Is it like a single line base 64 header? Like an actual header?

William: I’m pretty sure it’s an actual header.

Thomas: I can imagine like a MIME section, right? Like it’s the. You do the whole like the messages like this set of MIME packets or whatever. I believe you when you say it’s a header. I just think that’s crazy.

William: It may also vary by email provider. Is the thing that is concerning me is that I think what I’m saying is correct possibly for Outlook, it may not be correct for genealogy. You know, may do the MIME thing. But let me. I am trying to actually find this documented somewhere.

Deirdre: I hate this so much because emojis are content. They are the body of communication. I mean you can have an entirely important, very sensitive conversation just in emoji reacts. Because I’ve done it. I’ve done it on the argument that metadata is important as content. It really depends. Some it’s important to protect it. It’s also difficult to protect it.

The emoji reacts, not being counted as content is just wrong. But like the metadata about who’s talking to who at what time and how long the conversation is and things like that. The subject line that is content that should just be encrypted and the fact that it’s not is ridiculous. But the other stuff, it’s hard to protect it because a lot of it is like control flow, like how do we route information? Even WhatsApp doesn’t encrypt this stuff. They know who is talking to who at what times and things like that signal has done a lot of work to not be able to detect a lot of this. But it got better at it over time. And the stuff that’s subpoena able from signal is literally like the time that someone registered an account like the very first time and the last time they contacted the signal service, like that’s, they’ve very proudly put up their, you know, responses to, you know, subpoenas and court orders about like give me information about XYZ users.

Thomas: Right.

Deirdre: But even if you get it, it, I think there’s like this, this has been kind of the evolution of what you can get from devices. If you just be like, just try to give me access to devices. If you can get access to devices. There’s a lot including previously secure, securely communicated, end to end encrypted content on devices or on clouds, especially like iclouds that are not fully encrypted backup or other cloud backups that you might be able to get access to. And that’s really rich. And if you can get, get access to that, that’s really good stuff. If you can’t get access to that, the metadata is useful. And especially if you’re trying to spider out from a target, if you’re trying to find people in like a communications network and you’re trying to find links, I do think it’s important, I don’t quite agree that it is as important as content in the year of our Lord 2025 because there’s just so much content available out there from random places, whether it’s the cloud or you know, just give me access to your device via some sort of like corridor door or if you want to be really targeted at a specific person, you can try and target their devices specifically and send them an attack depending on the security of the device and get everything, effectively everything right.

Thomas: Those are all totally valid points. I think the thing I’m trying to call out about the unsalvageability of email is just if you think about how email works, um, when you, there’s so many places where you can do a dragnet and just collect all of the metadata going through like a message flow for a bunch of people, right? Yeah, like every, every MX hop, whatever. Like they’re just.

Deirdre: Yeah.

Thomas: The processing of these emails leaves a log trail of who is talking to who and not just on the central, the one central place that you could potentially protect or whatever, but just like everywhere that the message goes, just like leaving this trail. Yeah. It’s also like to me another important thing here is just that governments are already really good at accessing this metadata. They understand SMTP metadata. Right.

For a long time there was a thing that got passed around about for each of the different messaging services. What could the FBI access? Which things could they actually use? And it’s like with signal it was like that you use signal and then nothing else. Right.

But like the amount of stuff they can mine out of SMTP metadata, I think is a lot more than they can, like they’re ready to get from anything else.

Deirdre: Yeah.

David: And in like every client just like rebroadcasts all the metadata from their perspective at every step. And that’s like how the protocol works. Right. You include all the parent responses, you say exactly who you’re responding to and why, and like the chain of how you got there. And then the provider signs every message to make it clear that the metadata is real. Because everything via was dkim.

Deirdre: Yeah. Is anti spam. Yeah.

David: Because everything that we had to build for spam is all about like authenticating the method, allowing servers to authenticate the metadata to each other.

Thomas: Can we do like a one minute thing about how you should never take any kind of security advice from anybody who says that dkim messages should be authentic and like that it’s a bad idea to burn DKIM signatures? This is very definitely a thing. Right.

There are definitely. This is how the Hunter Biden messages got authenticated. They were published with valid DKIM signatures. And it’s like you respond to that and say, well, we should burn the DKIM keys so that you can’t really authenticate them.

David: That’s how we fought the deep state. We would never be able to fight the deep state without DKIM keys.

Thomas: And it’s like people will say things like, well, no, we need to keep these DKIM keys secret so we can authenticate messages. Because that’s how we’ll do journalism, by like authenticating people leaked messages. That’s like you’re the adversary. You are being the adversary right now.

David: I mean, leaking them on the scale of like, you know, rotating them every one month to six months or whatever, and then like publishing the old ones. I think, yeah, I don’t think we should stop authenticating messages at time of send. Like, I for one, in a way that I’m. My inbox is only like 50% send spam and not 95% spam.

Deirdre: Yeah. And like 50% spam is like stuff that I signed up for once upon a time. And not like boner pills are us or whatever.

David: Speaking of new sponsor.

Deirdre: If you do want to sponsor us and you, you are not boner pills R Us. We’re trying to hold an event in Las vegas during blackout defcon. Contact us@securitycrotographywhatever.com are we.com.

David: Just, just contact me. Figure it out.

Deirdre: David’s the one that handles this.

David: If you send me a PGP email, I will not respond. After I defended my PhD, I sent a number of people thank you emails and then one person responded to mine with a PGP email. And to this day I still not have read it.

Deirdre: Yeah, this is the way that it stays secure is when you do send the encrypted email, no one will ever be able to decrypt it. And so that part stays secure. All this metadata discussion is reminding me that one of the pros of email of SMTP is that it is federated. That is why part of the reason it’s leaving this metadata trail all over the Internet. This is a thing that some people like about the protocol.

David: I don’t know that I would call it a pro that it’s federated. I would simply state that it is federated.

Thomas: I have a bigger thing here which is just, okay, so it’s federated and people might or might not like Federation. This is like a long time thing with signal. Like Moxie wrote a whole thing about why they weren’t federated, which really set people off, right? And like, I feel like he was utterly vindicated on that after what happened with Matrix and their attempt to convert from encrypted non encrypted to encrypted. But there’s a deeper issue here, right? People complain about Federation. Maybe that’s a colorable argument. People complain about things being open source, maybe that’s a colorable argument. People complain about running too much stuff through Google. Maybe that’s a colorable argument.

But none of those arguments are about security, right? If, if, if the premise is we’re creating a transport for messages that are life or death sensitive, then none of that can matter. It can’t matter whether or not. So if you are, if you are talking to, like if you are talking to an activist community, especially if you’re talking to an activist community in some other country, but increasingly in ours as well, right? If you’re talking to people who are like organizing to protect immigrants from ICE for instance, or something like that, right? And you tell them to use PGP email because the alternatives are not open source or federated enough for you, that’s malpractice. It’s literally malpractice. Not in a funny way, not a dunking way, like you are committing professional malpractice, right? You’re like, you’re putting people at risk to serve your weird goal of getting a federated or open source or non Google transport. And that’s fucking crazy. Like I don’t understand why people, why people’s jaws don’t drop when they see people saying this stuff out loud.

William: I think this is now getting into the crank side of the world, but I think people sometimes just don’t believe that things are actually end to end encrypted. And because they don’t believe that, they then believe contrapositive things like it should be federated. Like well they’re not going to end to end encrypted. Then I might as well do the federated thing. And this is obviously wrong to me, but I think this is why we get into these weird online arguments as a community over and over again about this stuff.

David: Yeah, like yeah, the set. The set of people that think the signal has a back door there because it’s centralized or because Moxie wrote a blog post they didn’t like or because they think the CEO is like too. Whatever.

Deirdre: Yeah.

Thomas: My next argument, this one is I think more small ball than the first two. I think the third, the, the last one, there’s four of them total. The last one gets us back to kind of grand theory stuff. This one’s really specific, right? Which is everybody who uses email has an archive of their email messages, which is a thing that secure messengers deliberately go out of their way to not have. So I can go and search through pretty much every email that anybody’s ever sent me going back like a staggeringly far back time in history in my Gmail account. Right.

So all of those things will eventually somehow leak. Like every day that you hold that archive you’re incurring some kind of risk that it’s going to leak. It’s just inevitable that at some point it has to. Right.

So there’s no plausible mechanism for doing any kind of disappearing messages in email. And I think that’s not the most super interesting, fun technical topic to talk about because it’s really simple. Right.

But I think it might be pretty important in terms of actually impacting people’s safety. Just the fact that you can’t set a maximum amount of time for a conversation to live.

David: Yeah, I think that’s actually like the most important feature for quote unquote like secure messengers for like non activists as well. Like, like even imessage like you can, if you go into settings you can set your imessage to delete after like 30 days, but it’s like per device setting.

Deirdre: Oh that’s.

David: You can end up with like imessages that are on one device from like I just saw some that were over like a year old. On this, on. On this laptop, even though I have it set to delete after 30 days on my phone. And that’s not because, like, it’s a life of your death scenario or because I’m an activist, but just because I’m like, I don’t want these messages, like, yeah, like, I just don’t want old to like, come up and bite me regardless of what it is, because it’s old. And like, oh, remember when, you know, David cheered for the wrong football team? Right? Like, even like that, like, it’s just like, no, you don’t want, you don’t want that to come to. Just like somehow get screenshotted or whatever. Right.

Thomas: I like the idea that some point in your past you cheered for Ohio.

David: No, I cheered for Michigan State for like a small period of time when I was in high school and my brother was a student there before he had the good sense to become an engineer here at Michigan.

Deirdre: Yeah, like, I’m in Gmail right now and like, Gmail’s not, I don’t know, a fold. It’s a web client. It has other, you know, desktop clients. But like, there’s no option for me to just like, automatically delete things at any age. Like, I can throw stuff in the trash that requires me to take an action and it will auto delete stuff in the trash. But like, yeah, I’ve got thousands and thousands and thousands of emails from many years in my. In all, like, and then I’ve got.

Thomas: Multiple email accounts and like a comeback you can imagine is somebody saying, okay, well, they’ll just add the feature or you’ll use an email client that has that feature. But that’s actually not the feature. Right.

The feature is the protocol accommodation where you can communicate to your counterparty that they should also delete these messages. Which is something that’s like, you could write a signal client that didn’t honor that message, but no one’s going to use it. Right.

It’s the fact that the protocol kind of. It’s an accepted feature of the protocol, which it will never be an email.

David: That’s not true. Pete Hegsess will use that client, but other than that, no one will use it.

Deirdre: PC small group. Yeah, this is sort of like one plus in the, in the kind of the Moxie. No federate argument that he made and we’re linking to that post in the Show Notes where on the off chance.

David: You’Re listening to this and you don’t know who Moxie is, He is the creator of Signal.

Deirdre: Yeah, he, he’s the, the primary, the primary creator of Tech Secure and oh gosh, I forget the name of the, the calling app that he.

William: That then got merged into the Open Whisper systems.

David: Open Whisper, the original Red Phone was the app, texting app and the company was called Whisper.

Deirdre: Open Whisper, yeah, it was Whisper System. And then there they were involved with Twitter long.

David: They got acquired by Twitter somehow.

Deirdre: Yeah. And then he made the new Open Whisper systems and everything got turned into the Signal app and the Signal service and everything is like GNU licensed and open, but you know, it’s a copy left license. So you talk to. Yeah, well, you can look at it. Yeah, so you could run it if you wanted to. Everything’s there, but you can’t anyway. But because everything is controlled and not federated, they control all the clients, they implement them themselves, are able to update and move the protocol forward because they control all the clients and they’re able to move faster and they were able to make automatic deletion and deleting messages for all the parties, all the clients in a chat, for example, a thing. And that’s so much harder to do when it’s like an open protocol such as something like smtp.

Like you can do it, but do you have the guarantees in practice that that is going to be implemented honestly and correctly when it’s an open protocol? Like okay, yeah, you may have a must in this delete this message packet header or something like that. Delete after, you know, T + 30 days according to your local clock or delete in 24 hours. And like, as I think we all know that like you can put all the musts and must nots in your protocol spec as you want. And like people may do their damnedest and sometimes issues happen and sometimes you fail and sometimes there are bugs and sometimes there are bugs in client software when you control all the clients. But generally it is less likely that you will have implementation skew and bugs between independent interoperable implementations of something like a delete me flag on a message. When you control all the clients and there’s only like three of them in the case of Signal, there’s the iOS, there’s the desktop and there’s the Android clients. That seems like less of a thing that you can do on a protocol like smtp. Although I’m very curious how MLS like protocols will do this, but it just may be more of the same of like try real hard.

David: Interoperate. Aside from the one obvious example. Well, they really want to implement disappearing messages by implementing disappearing messages and they happen to Use MLS with other web experts.

Deirdre: Europe is really incentivizing people to actually make it happen.

William: Yeah, I mean I keep. This is not even a cryptography thing. You can’t cryptographically prove deletion. This is purely a protocol application design.

Thomas: Right, right. Which makes it interesting how intractable this is for email. Right.

It’s not like, it’s not even like there’s a theory issue for it. It’s just like you’ll never get something deployed where you can reliably tell somebody else to delete an email. So.

Deirdre: Yeah.

Thomas: Last argument, last argument, Last argument. You guys ready? I think we’re ready. The last argument. Long term secrets. So eventually any secret you hold will also leak. This is the forward secrecy thing, which is like forward secrecy. If you’re talking to people like I’m imagining, I do a lot of local politics and every once in a while I’ll get asked about secure messaging stuff from people who are not computer people. And I’m trying to imagine explaining forward secrecy to somebody who is not like.

Because it’s not like it’s the, the, it’s the worst term. Right. Because it’s like it’s not about secrecy going forward, it’s about secrecy going backwards. But it’s called forward secrecy. Right.

So it’s just the idea that every solution that we have for secure email is based on static long term secrets. There’s no such thing as an ephemeral, you know, email secret exchange, which means that, you know, everything is kind of tacked down like, whatever. If you’re, you know, having ongoing conversations with people at any point, if that secret leaks, the entire backlog of everything that you’ve ever sent is also going to leak, which is a complete own goal. Right. You don’t have to have that problem in a serious messaging protocol. You could just do, you could fix that with ephemeral key exchanges. So I think that’s also a really big point.

Deirdre: Yeah. And this is fundamentally like both how S MIME and PGP based encryption schemes work is you have a encryption public private key pair. You push the public key onto one of these key servers, these bulletin boards, and then someone will usually encrypt a message encryption key to your asymmetric public key. It’s a symmetric encryption key for something like AES and they encrypt it to you under your public like RSA rec public key encryption scheme. And then you decrypt the key with your private key that goes with the public key. And then you decrypt the message with that Secret, but this is still protected by one key pair that you use over and over and over and over and over again. And so while you have a different key per say, message or whatever it is, it’s still all fundamentally protected by the same key. This is not how it works in Signal or WhatsApp or MLS or possibly MatterMost.

I forget that protocol. This is just not what modern encryption messaging protocols are like. They do a new key establishment for every message and they mix in information from when you set up the session. That kind of, that binds to identities to a little bit. You attest that you are who you say you are and that this is linked to previous messages, but every message is computed differently so that if any of those previous things leaked, the like, if any pieces of these things leak, like you’re safe. Like the previous things are safe, the future things are kind of defunct. And like depending on how the protocol is implemented, it can self heal. If you have an honest protocol and you kick out the, you know, the leak of the adversary or whatever, it can heal and then you can get back to that same security level of independent messages having different key material.

Deirdre: That is just not how it works with bep, email or S. I’m going.

Thomas: To read you something and you’re going to tell me when you know who the author of this thing is. Don’t tell who the author is. I don’t want to. But you’ll tell me. All right, here we go. Forward secrecy is somewhat overrated in end to end encrypted messaging. Most people do not want a truly off the record experience, but instead keep their messages around indefinitely. As long as those old messages exist and are accessible to the user, they’ll be just as accessible to any attacker who gets access to the secret key material.

The signal protocol somewhat excessively provides forward secrecy for each and every message sent. This is sort of pointless while the messages still exist on the screen.

William: I knew after the first sentence that I. You still don’t want me to say who it is or.

Thomas: No, you can, you can in the abstract.

William: Okay, this, this is, this is one of my favorite people on the Internet is who it is. Someone who I’ve talked with many times, or rather I don’t even talk with his. Maybe not the right way to say.

Thomas: I’m exchanged missives with he does a valuable service. Right?

So this is a commenter on Hacker News who is like the designated defender of pgp, right? And like, it’s actually pretty valuable like having like something like this be written because it forces you to kind of refine. Like he has a whole spiel about why authenticated encryption is not always good, which is like it’s. I can’t remember what the argument is. Right. It’s hard to get your head around. Like it’s something about being. It was something about like recovering corrupted messages. Like what most users want is messages where if there’s like a bit flip failure or something like that they can like recover it or something.

And authenticated encryption makes that break down or something. But it’s like having to articulate why of course you need, you know, authenticated encryption everywhere is actually kind of valuable. This is the amount of like back rationalizing you have to do to keep PGP like kind of in the story.

William: Yeah. And he has, he has a couple of. With posts that are not like inherent or. No, they’re not entirely nonsense. Like he has one about like 2048 bit RSA. Like it’s fine. Is I think the point of his argument. And it’s like, you know, is it good? I would say it’s not good to me that I would probably go to a default.

William: Bad, bad no for any rsa. But like is it the worst thing in the world?

Deirdre: No, like there’s, there’s strong arguments within like the, you know, a proper cryptographic community about how much, how big these parameter sets really need to be. Like a lot of them are arguments about symmetric primitives. Like some of the new stuff that’s based on Ketchak if you want to look up too much crypto by JP Elmundson. He makes some nice arguments about the bounds that we need in practice against known adversaries and the best known attacks so that we can arguably get just as much security with smaller parameter sets, blah, blah, blah. I don’t know if that applies to RSA 2048, but there are good faith, well founded debate about other cryptographic primitives and sizes and things like that. Arguing that you just don’t have good forward security or post compromised security just because you don’t really need it. That that’s fundamentally just like giving so much power to a possible attacker of just like again, they only have to be right once and you have to be right over and over and over again. And having these forward forward secrecy and post compromise security protocols make it so that the adversary basically has to.

It gets reset almost every time you send a message practically. It just makes it a lot, lot, lot, lot harder for someone to just, you know, take all the public information you’re sending in these ciphertext and like get a good crack at like the.

David: Whole, well, you assume every. Via Thomas’s I think principle too was that every PGP message ends up getting sent in plain text anyway. Yeah, you don’t need forward secrecy. There is because it will simply leak.

Thomas: So there’s like, there’s a kernel of like a, you know, a useful conversation in that and that argument that he has, right? Which is like, you know, people don’t, People are going to keep their messages around anyways, so what does forward secrecy matter? And it’s like there’s some truth to like, you know, I have an archive of emails going back to like whenever Gmail started apparently, right? Like, and I just, I don’t care. Like, I’d rather have them around then like opsec them out, right? Like when I’m. I just don’t use email for stuff that that would matter for, right? So like the thing that, the thing to note here is like it’s fine to say that email is fine for some kinds of conversations. Like, it’s fine to say that. Like, I’m not saying don’t ever use email. Like use email. That’s fine. I use email for all sorts of things, right? Just don’t use encrypted email.

Don’t like try to send secure emails to people, right? We get in trouble when we try to make this one system that we all like, serve life and death use cases. And if you can’t, like if you can’t articulate a threat model, like if you don’t, first of all, if you don’t know how to articulate a threat model, but if you can’t just rattle off what the different threat models are for people protecting immigrants from ICE versus people chatting with people they met on hacker news or whatever, right? Like, then you shouldn’t be giving people advice, right? And this brings me back to just like digital security guides for activists and things like this where there’s clearly no threat model in this stuff, right? Like, it’s not based on an understanding of who their adversaries are. And what’s really frustrating about that is the real advice is not that complicated. It’s not like this is just not that, like we don’t have the sophistication that we need to give people good advice. It’s just you need people to just be able to say, like, just use signal, right? Forget about all the politics of it. Forget about like whatever you think about Moxie, Marlin, Spec or Federation. Just, just use signal, right? Probably don’t use Firefox, you Know, just things like that. Which again is just like this whole thing right now for me is just my red flags for digital security guides. One of them being anybody talking about pgp.

Deirdre: Yeah. And like number one for me, a lot of people, when you’re making recommendations of like how to stay how, how to achieve digital security, trying to achieve a goal, you’re trying to organize, you’re trying to keep your team secure, you’re trying to serve some community. It needs to be easy to use and easy to get right. It can’t be. Make sure you use super special client. Oh, you know, it might not be available on this phone. Oh, like you have to make sure you tick this box. You have to add this extension, you have to do XYZ to make sure that you use it right.

That’s bound to fail. One, it’s bound to fail because it’s hard to get right and so you might actually get a security failure. Two, it’s a lot of work for people to do. If the other of the alternatives are download signal, we will add you to the chat. That’s so much easier to undo, period. And get right. Because you don’t have to do a bunch of extra steps to get it right and achieve better security. Yeah, I feel like a lot of people are just trying to, they have their values and they’re trying to say, oh, you should do XYZ because this aligns with my values as opposed to people trying to achieve something in the real world.

And if it’s too complicated and it takes too much work to achieve good security, they’re not going to do it. Or if they try to do it, they will fail and they’ll open themselves up to a vulnerability and then what’s the point of the technology in the first place? One thing I kind of wanted to point out is like, oh, if you’ve got an archive of all your messages forever and theoretically your messages will just leak because they’re around forever and you know, so what’s the point of forward security? And like one, it’s a belt and suspenders things. It’s the Swiss Swiss cheese approach of security and systems. It’s not any one thing. It’s if you don’t have forward security, you are more vulnerable to one of these things going wrong. An adversary, you know, poning one of these keys or a key server or whatever it is, one of these keys and then everything falls apart. But if you don’t have a giant message archive, like, you know, the, the blast radius is less bad and like, if you don’t have all this metadata, then, like, the blast radius is less bad. It’s all of these things together are pretty fucking bad.

If any one of these things was less bad, then it would be less bad. If all. Anyone. If any of these things were less bad together, we probably wouldn’t be talking about this at all. But they are all pretty bad together. So the forward security, you know, just. Just don’t try to do encrypted email. Use signal, use WhatsApp.

Like, some people don’t like WhatsApp for reasons. Using WhatsApp is way better than trying to use encrypted email, in my opinion.

David: It’s also, like, the only way to talk to people in Europe.

William: Yeah, I was blown away by that. Every time I go somewhere that is especially, like, southern Europe or in Africa, it’s like people will just message me randomly on WhatsApp and I will have no idea who they are. But better than anything else possible. It’s awesome.

Deirdre: Yeah. Use signal, use WhatsApp. If you need to encrypt files, signal, use Tor. Yeah. If you need to use torture, install the Tor browser, you’re done. It’s a good. It’s based on Firefox. It’s a pretty good browser.

David: Didn’t we just tell people not to use Firefox?

Thomas: Wait, hold on, hold on. Are you gonna respond to this or am I?

Deirdre: Actually, I think Brave also supports.

Thomas: You’re just trying to make my brain pop.

Deirdre: Sorry, but the Tor browser, not ironically, the Tor browser is like, everything’s set up, everything’s good to go. And I think the other options are less. Less tailored. But sorry, yes, I said that.

Thomas: I’m guessing for reasons that you’re probably familiar with Dan Guido’s argument about why the Tor browser bundle is the literally safest browser to use in the world.

William: I definitely heard him make the argument before. I can’t remember off the top of my head.

Thomas: So it’s a combination of things where it’s like, so first of all, you’re using Tor, right? Which, like, from a traffic analytic perspective, you can see that somebody’s using Tor, right, Using Firefox, which is the least secure of the mainstream browsers. And you’re using a fork of Firefox like a tracking fork of Firefox, and you’re collapsing all of the Firefox vulnerabilities down to a very small set of Tor browser bundle targets. So, like, the exploits that you need for that, you, like a serious adversary, needs a battery of exploits for all the different versions Whatever they’re using, but they don’t need that for Tor browser bundle people.

William: Yeah, I’ve definitely heard it make that art before and I find it convincing, especially for, I think it was especially true maybe 10, 12 years ago when the state of Firefox container isolation was really, really bad. It’s been a long time since I looked at browser security and so I.

Deirdre: Would say Firefox has come a long way, especially in terms of sandboxing and a lot of memory safety integration into, into the whole stack. I think arguably Safari is less good than Firefox at this point for some of those reasons. But yes, if you’re, if you’re using, if you’re using Tor browser, you are a little bit sticking out in terms of, you know, fingerprinting and all that sort of stuff. In terms of. I don’t think we’re, we’re really selling people. You should use Tor. We’re mostly doing the meme of use signal, use Tor. And if you, if you want to use Tor, like downloading the Tor browser and just using it is like the easiest, straightforwardest way to do that.

But yeah, just never mind.

Thomas: It’s not a super strongly held opinion of mine. It’s just, it’s an argument I’ve had beaten in for me into Me by Dan Guido and the Gruk.

William: But if you use Spur, you get to use the best named mitigation ever, which is the Giga Cage.

Deirdre: The what?

Thomas: The what?

William: The Giga cage.

Deirdre: Oh, Giga Cage.

William: Yeah.

Thomas: I want to say Ga Cage.

William: This is my favorite mitigation ever added to a browser, which is people kept using Ray Buffer for exploits instead of Safari. And so what they did was they put every, they put the backing store for all of food for Ray buffer into a mmapped 4 gigabyte heap region and then made all offsets 32 bit so you just can’t escape that region.

Thomas: This is a Dan Kaminsky idea from like the mid 2000s. Oh yeah, this is like his big memory, like his big memory safety thing was 64 bits.

William: Yeah.

David: This is also how the V8 sandbox works as well. It’s a little part of it. So like the, the V8 sandbox is a little more than that. But to make the, the memory regions work, they have a variety of slightly larger than 4 gigabyte regions that are only addressed in 32 bits. You can’t get off of. Cool in theory, but like then there’s a bit more to it.

William: There’s always a seal.

Thomas: We’re only going to find out over the next 20 years that Dan Kaminsky was literally right about everything. Just in like subtle ways.

David: If someone has one of those Wall Street Journal dot profile pictures.

Thomas: The stipple painting.

David: Yeah, the stipple painting. You. That just makes you correct about everything.

Thomas: I was wrong to doubt the stipple painting.

Deirdre: R.I.P.

Thomas: R.I.P.

Deirdre: Dan Kaminsky.

Thomas: Yes.

Deirdre: All right, so I think that’s it.

Thomas: I think we covered it.

Deirdre: I’m going to go install some random-ass PGP extension in my browser and I’m just going to start sending the wrap up for this recording with an encrypted email. I hope you love.

Thomas: Make sure you use TOR Browser 48.

David: We will ask the armor the episode notes.

William: Yeah, yeah, I want it with past five, the official Canadian block. So.

David: And apologies to the person who sent me that PGP email on the off chance you’re listening because it’s kind of identifiable.

Thomas: Maybe it was a really mean email.

William: Could have been.

David: Who knows?

Deirdre: All right. Yep. If you can stop using encrypted email and stop, stop telling people to use encrypted email. It’s just not, not good in our opinion.

Thomas: Good note, Deirdre. Security Cryptography, whatever is a something of side project of. Wait, it’s, it’s a side project of.

William: You, me and David.

David: Yeah, exactly. And our editor is Nettie Smith, and we sell merch at merch.securitycryptographywhatever.com. And we thank you for listening and we thank William for coming on this episode with us.

Thomas: William, thank you very much.

Deirdre: Thank you. Bye.