Episode 359 - Lattice-based ZK Systems with Vadim Lyubashevsky

Transcript

Welcome to Zero knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week, Nico and I chat with Vadim Lubashevsky, a cryptographer in the security group at IBM research. In this episode, we dive into lattice-based ZK systems.

We discuss Vadim's initial interest in the space, how he got involved, the evolution of lattices, as well as the state of the art in lattice-based ZK systems. We learn about the challenges of mapping lattices directly into existing SNARK constructions, how lattices work differently from existing optimization techniques, and how instead researchers often need to develop new lattice-specific techniques in order to achieve interesting and efficient SNARK systems. Now, before we kick off, I just want to let you know that ZK Summit 13 is happening on May 12th in Toronto. The event is coming up fast, and if you haven't yet bought your ticket, we do encourage you to do so. Also, we do have some student tickets still available, so

if you would like to apply for a student discount, you can do so over on our website zkasummit.com. Hope to see you there. Now, Tanya will share a little bit about this week's sponsor. You might already know the ZK jobs board, a place where teams can share open roles with our community. But when it comes to key hires, finding the right fit in our niche space can be difficult. That's where Missing Link comes in. They're a talent team built for the Web3 era, helping projects across the ecosystem connect with the right candidates at the right time.

They've worked with names you'll recognize: Ethereum Foundation, Mina, Web3 Foundation, and many more, filling critical roles that drive these teams forward. Whether you're an established project looking to fill a senior leadership role or a startup searching for specialized talent to refine your product market fit, Missing Link can help. They've done it for some of the biggest teams in the space, helping them and now you find the right people fast. For more details, check out the show notes and visit their website at missing-link.io.

So, thanks again, Missing Link. And now, here's our episode. Today, Nico and I are here with Vadim Lyubashevsky, a cryptographer in the security group at IBM Research Europe. Welcome to the show, Vadim. Thanks, Anna and Nico. Nice to be here. Hello, Nico. How are you doing? Hello, hello. All good, thanks. So, Nico, we've wanted to do this episode on lattices for a while now. Like, I think it was the end of last year in our closing year-end episode, we kind of like predicted, "We're going to do it."

Yeah. It's taken us 4 months. We finally set it on course. This topic came up in an episode I did in November with Dan Boneh. He mentioned He sort of covered briefly some of the recent work on lattice-based SNARKs systems. And yeah, it's it's sort of piqued our interest. So, I'm very excited to have you on, Vadim. I'm so excited we're going to get a chance to dig into this with you. I'm very happy to be here and answer all your questions. Cool. I think actually as a starting point, it would be really great to understand what got you interested in cryptography, kind of back to the beginning, and specifically what got you excited about lattices.

Yeah, so if you're expecting some deep answer about me loving privacy or loving cryptography You've always wanted to be a cryptographer. Yeah, no, no, nothing like Unfortunately, nothing like that. I arrived as a grad student at UC San Diego and um there was a professor there, uh Daniele Micciancio, who was uh one of the experts on lattice cryptography. Mhm. And that's just uh what we ended up doing. It uh turns out later that hey, actually I do enjoy it very much. I do enjoy the the parts of it that are um that are more practice-oriented, and there was a lot of uh open problems in terms of practice and the theoretical stuff that that were not answered yet. It was a very young field.

And yeah, I just took it from there. Very cool. Um lattice sort of lattices as a concept, that's a I'm I'm assuming this is a field that's broader than just cryptography. Cryptography is like an application for it. But can you share a little bit about the history of that field? Like maybe even before it joins forces with cryptography? Uh yeah, sure. So, mathematically it was I guess in the 1900s, it was Minkowski who created this field called the geometry of numbers. Mhm.

So, he realized that actually if you look at some um number fields, you can actually look at them which which are very algebraic in nature, you can actually look at them geometrically, and you can get results on them by looking at their geometry. So, that was something that drew the interest of mathematicians. And um then, let's say in the 1980s, lattices became a cryptanalytic tool. So, the famous LLL algorithm by Lenstra Lenstra Lenstra was used um to attack uh certain proposed cryptosystems. And even to this day, that algorithm and its descendants are used to attack things like RSA.

So, it was a cryptanalytic tool in the in the '80s. Basically, because you could find short vectors in lattices. You know, not very short, but short enough to be interesting cryptanalytically. Mhm. But then in the '90s, it was uh began to use for cryptography because and actually it was uh so Miklos Ajtai, he said, "Hey, actually uh the shortest vector problem is NP-hard." So, because people didn't even know that. I mean, that's not enough for cryptography, but even that was not known before.

Uh and actually there is this interesting random distribution which is as hard as some lattice problems. And this got a lot of people interested in cryptography. And I should obviously say Miklos Ajtai was at IBM Research as well uh in Almaden. Yeah. This is interesting. So, like lattices were first used to attack systems and then they realized some of the characteristics could be used within systems, I guess. Right. So, it was used to attack and but then the problems were still hard enough that you couldn't solve them completely. So, then you can base cryptography on the kind of harder versions of the problems that you could solve. So, yeah, it is kind of interesting that it's both. We saw the same with uh pairings that were quite familiar in our like ZK

landscape. Like at first it's a way to attack discrete log base systems. And then we start using them to build like new stuff. Right. And this is uh not so uncommon. For example, in isogenies now, something my colleagues work at IBM on, the signature scheme they're using, they uh like a big part of the algorithm was an attack against their encryption scheme. Hmm. So, this is uh yeah, this this happens a lot, right? In the I don't know why, but uh just yeah. So, after I mean, you sort of talked a little bit about your academic work, um what led you to work at IBM?

Uh so, of course there were some personal reasons for moving to Zurich, but also I I really enjoyed that um there is this um academic yet a bit more urgent than academic uh outlook in the in the industrial research lab like IBM. So, you're allowed to work on research, but you're also encouraged to make sure your research has some uh middle-term uh you know applications. Yeah, yeah. So, something like 5 years. And this is this is what I really enjoy the most. Like, it allows you like this 5 to 10-year um you know, window allows you to kind of think of in work on interesting problems, but also something that you can actually uh you you actually can see people use.

Mhm. I guess that ties in nicely with the IBM's efforts in recent standardizations uh from NIST, right? Right. Right. So, we we did uh along with um other collaborators propose some algorithms at the start of the NIST standardization process in around 2016. So, NIST wanted to uh create the next cryptographic suite to replace the discrete log and factoring and elliptic curve um based methods. And yeah, so it went through all this I don't know. NIST didn't want to call it a competition, but whatever it was uh this process. And yeah, so the two things that we submitted were chosen as the primary standards. So, they are

based on lattices. Mhm. So, the kind of lattices from that point on, I think it became much more mainstream. People said, "Hey, this is the most efficient thing we can do at least for encryption. For signatures, uh you know, there's lots of trade-offs. And uh it seems to be pretty well-studied. Um so, this could be the future. Well, we have we have to see, of course. I think we're just we're sort of just using the term like lattice-based, lattice-based, but maybe it would help the listener who isn't familiar with lattices in general to describe kind of like what are they? What do they look like? What do they seem like? How are they How are they constructed? And maybe I mean, we can think of a more basic

version of a of one. Maybe just so that we can start somewhere. And then we'll understand more how it's being applied. Okay. So, when whenever people ask me this question, like what is a lattice problem? I actually don't give them a lattice problem. Don't even explain what a lattice is. I just give you uh a problem that is much easier to understand. And kind of ignore the fact that you won't know what a lattice is uh from this problem. So, this is called the knapsack problem. So, this is something that dates from the '70s, the '60s. And this is actually a problem that um optimization people want to solve in practice. So, let's say I give you um I don't know. Uh a thousand numbers, random numbers. I generate a thousand random numbers, and each has a thousand

digits. And then I pick 500 of them at random. And I sum them up. Right? And I give you the sum. And then I ask you, which 500 numbers did I sum up? Or maybe if there is a, you know, more than one set of 500 numbers, find any set of 500 numbers. I don't care. This is the knapsack problem. Okay? And uh this is actually also a lattice problem because uh a solution to this problem is a shortest vector in a lattice. And I'll define a lattice. And this is what I mean by this geometry of numbers thing. So, when I gave you this knapsack problem, it seems like a completely combinatorial problem. Yet, it's actually a geometric problem that that is solved using this LLL algorithm,

for example. So, a lattice is uh an infinite um grid, you know, generated by a by a basis. So, I give you a few vectors. Let's say the vector 3 1 and uh you know, 4 2. Mhm. And I say, okay, all the linear combinations of these two vectors, they they generate my lattice. Mhm. Right? And now from these two vectors, well, you say, okay, fine. So, that's an infinite grid. Now, I can ask you, okay, so what linear combination of these two vectors will give you the smallest possible vector? So, maybe, I don't know, is maybe you can somehow combine them together to get something much short shorter than 3 1 or 4 2, maybe like 1 1. I don't know if you can, but uh whatever. Right?

And um so in two dimensions, okay, it's an easy problem, but now if it's in the thousand dimensions with you know, a thousand um let's say vectors in this basis, now it becomes a hard problem. Mhm. Right? And actually, if you can solve that problem, then you can solve this knapsack problem cuz the knapsack problem is a linear combination that is actually that sums up to that number that is actually quite short. Because, you know, it's a zero one cuz I chose 500 numbers, right? So you either picked it or didn't. So they're either zero or one. And that actually you can reformulate that problem as a as a as a lattice problem.

Mhm. When you're using it as a hard problem though, like are you trying to find something in that lattice? Yeah, a short vector. Doesn't have to be the shortest, but something short, right? So when I give you a bit a bunch of basis vectors, right? Like when I gave you maybe 4 2 and 3 1 wasn't a bit good example. Maybe like 137 and uh 12 uh 49, right? Find me a short vector, right? In this lattice. And how is this problem known? Like what's the name of this problem? this is the shortest vector problem. It is a very uncreative name, but that's that's that's what it is, right?

It says what it does. Exactly. No, yeah. And so is this problem the basis of most lattice based cryptography? Um yeah, so uh shortest vector or perhaps a close vector problem. Sometimes I may say, "Okay, don't find me cuz the shortest vector you can think of it as finding a a short like a vector close to the origin." I can also say, "Hey, can you find me a vector close to, you know, some random point in the uh in in the sp- in space?" So that's the close vector problem. So there is basically two of those. Um there's of course some nuance, you know, like the close vector problem becomes easier if if I'm promised to be actually very close to the lattice and it becomes kind of hard kind of its complexity, you know, computational complexity changes a

bit uh depending on that. But, the best algorithm for all of these close vector short vector, um you know, this close vector when you with a promise it's all the same. It's all this this extension of this LLL algorithm from the '80s, which has been refined, has been um you know, improved upon. But, yeah, so that's that's why I say that really in lattices we have kind of one one problem, or at least we have one algorithm that uh attacks all these problems that are a little different, but really quite re- related to each other.

We often also hear about the learning with errors problem, LWE. Is that related to shortest vector? Uh yeah, it's it's really the basically a the close vector problem. Because so, learning with errors, um the way it's usually defined is you have a matrix or a random matrix, you multiply this matrix by some vector, so you get a linear combination of this vector, and then you add an offset. Right? So, basically, if I give you a product of a matrix of a vec- and a vector, and I ask you, "Hey, can you find me this vector that I multiplied by?"

That's actually very easy, you know, in most cases, cuz that's Gaussian elimination, if this matrix is square, let's say. Yeah. Right? So, that's not a hard problem, but if you then actually multiply it by a vector, and then say, "Okay, I'm not going to give you the exact product, I'm going to move move myself off from it a little bit." That becomes a hard problem. And that's actually the close vector problem as well, right? Cuz you're not quite on the lattice, but you're a little bit off. Right. So, if I manage to get this error off, it becomes easy. Yeah, if you Exactly, exactly. So, it really is finding the close vector to the lattice is this learning with errors problem.

Why is this kind of construction considered post-quantum or hard for quantum computers? Like I don't know, in in the description you shared, it doesn't make it clear why it would be harder than elliptic curve cryptography or something else. Yeah, of course that's the million-dollar question. Um, and a lot of people have been thinking about it actually. I would say that a lot of modern lattice cryptography came from the quantum world. So, this learning with errors problem, it was first defined by Oded Regev who actually wanted to find an algorithm a quantum algorithm for this problem.

Okay. But he could not and he actually could show that if you could solve it then there is a quantum algorithm that can find short of vectors in all lattices. Huh. Right. And then he said, "Okay, this is very similar to what I tie did with his kind of version of the a lattice problem." And so that we have we got cryptography out of it. But yeah, a lot of people in the quantum algorithms world have been trying to solve this problem. Um, and the best answers to why we think it's hard is exactly that, right? It's that a lot of people in the quantum world have been trying to solve this problem. They actually it's gotten to the point where they actually base some quantum result

quantum theorems based on the assumption that this is hard. So, for example, yeah, they they say, "Hey, you know, we can prove that something is is doing quantum things under the assumption that this this problem is hard." You know, we we recently did an episode on quantum engineering, but I think I still I don't quite understand how cryptography and quantum engineering like how people reason about it because it feels like you're trying to imagine a system that wouldn't be broken by a quantum system that might not exist yet.

You know what I mean? Or or like in what you just said is like you're assuming a quantum system is working in the way you think it's working based on like a thing that could be broken somehow. So, the thing about quantum computers is, while they don't exist yet, we know once they exist what they will do, like what how to write code for them, what code they will be able to run. Right? So, just because we don't have a supercomputer doesn't mean we don't know what it's going to do, right? Mhm. Um like a supercomputer that's more powerful than today's supercomputers, whatever that means. Um so, once a quantum computer is built, it's not going to give us any surprises. Like we will be able to if it's good enough, it will be able to run the code that's the

algorithms we expect it to run. Now, in terms of why, you know, do we have confidence that better algorithms won't be invented? Um of course, we have less confidence in that than in classical algorithms, but just because it's a newer field and less less people writing algorithms for quantum computers. But that's that's kind of all you can say. Like what I I think I I think an interesting point is that in the '90s or 2000s, so I heard that they did um did a survey at theoretical uh conferences asking people, "Do you think factoring is in is in polynomial time?" And 50% of the people said yes.

And this was back back when the number field sieve was coming out. So, you know, factoring kept getting easier and easier and people thought, "Well, maybe it'll never stop, right? I mean, the number field sieve is not the right algorithm for it. Something better will be invented." So, there there is always doubt, and that's unfortunately how cryptography uh has to has to work. Public key cryptography cannot exist based on information theoretic um hardness assumptions, right? So, until we have proof that one-way functions exist we cannot have 100% certainty of any cryptographic assumption, right?

I want to move on to how lattices start to combine with ZK. Like over the years, people have started to like kind of describe SNARKs in these different components and modules, like IOPs, polynomial commitment schemes. There's sort of like a Yeah, kind of a description What do we What do we call this, Nico? Like a of how to build them, no? A recipe Yeah, that's a nice way of putting it. But what When it comes to lattices, I'm sort of curious like which part of the SNARK are lattices actually replacing? Like are lattices currently being used when you start to build SNARKs using lattices? Are they being used instead of like the polynomial commitment scheme that we usually use? Are they being used as like something more fundamental

underneath like the underlying I don't know, like problem that everything is built on top of? Um maybe we can formulate the question in the negative of why is it hard to make lattice-based zero-knowledge proofs? Like why can we not just port everything we know from elliptic curve land to lattice land? Okay, so that's that's a good question. So first, let me just say that I will start answering this question by using zero-knowledge proof in the original meaning of zero-knowledge proof. So a proof that does not reveal any information about the witness, okay?

So, even the very, very basic zero-knowledge proof. So what's the most basic zero-knowledge proof that exists? I would say a Schnorr signature, right? So a Schnorr signature, you're just proving knowledge of an exponent. And so, why can't lattice sign So if we want a lattice-based signature, why can't we just port that? It turns out that this is quite messy. So the reason is So a lattice problem, you can formulate it as as I did a knapsack problem. Here's another simple way to formulate it is I'm given a random matrix, let's say it's matrix with I don't know, 500 rows and 1,000 columns whatever.

And then I multiply this matrix by a Let's say a 0 1 vector, right? And I give you the the result, right? So now the the hard problem is to find the 01 vector. So now you can think of it it's it's almost like the knapsack problem, except instead of adding integers, I'm adding vectors, right? I chose a subset of vectors instead of subset of integers. Okay? So this is the one-way function that plays the same role as let's say the discrete log function in classical cryptography. So now why not just be able to prove that you know a 01 vector, right? So the problem comes in exactly because of this restriction of smallness, that I have to prove not just prove to you that

I know a a vector S so that AS equals T. I actually have to prove that S is short. And this is very different than uh in discrete log, where you just have to prove some sort of algebraic relation, whereas here you have to prove an algebraic relation and the fact this this geometric thing that something is small. And of course to prove that something is small, it becomes um kind of a higher degree equation, you can think of it. To prove something is 01, you can prove that X times uh you know 1 minus X is 0, right? So now it becomes more difficult.

And maybe this also comes back to why can't why how is this different than all these discrete log pairing things, that why can't quantum computers break this? Well, quantum computers they can do um let's say these algebraic things, but there's this geometric part in here that seems to stumble them. But it also stumbles, you know, is a stumbling block for for protocol designers, right? Even a lot of space signatures, this is the thing that got standardized by uh by NIST recently, ML-DSA, so before it was called Dilithium, it is so much more messy than just the Schnorr protocol. So you do kind of the Schnorr thing, then you say, "Ah, but now the vectors are too big, so let's not uh send all of them." And then, you know, yada yada yada, there's a there's

a big mess. And even then, even the signatures, right? They don't quite prove what we know. So, in Schnorr, you know an x so that g to the x equals y, you prove that I know x so that g to the x equals y. That's it. Here, in the in the lattice-based signatures, I know an x so that ax equals y. I don't prove to an x is has 0 1 coefficients, for example. I don't prove to you that x is 0 1 coefficients. I prove to you that there is a some small x maybe with coefficients that are up to 1,000. So, much more relaxed thing. And not even I don't even prove to you that ax equals y. I prove to you that ax is some multiple of y. So, we're proving something much much weaker.

Huh. And now when you want to do zero knowledge, when you act you know, in zero knowledge proofs, when you actually do care about proving the zero one, right? Like let's say I'm trying to give a zero knowledge proof of I don't know how much I have in my wallet or something that the sum of two two dollar amounts is I need I need an exact thing. I can't say well, it's approximately this. And then it becomes much much more complicated. And and this is something that even this basic basic thing, just proving this one-way function up until, let's say, seven years ago, this just the proof itself, you know, we're not doing any SNARK. There is there is nothing. We're just asking for a linear-size proof, it was already, you know, megabytes long.

Oh. And then only only recently we said, "Okay, there's lots of other techniques that we can do uh we we can apply uh we can kind of invent um that will allow us to, you know, get re- reduce this these megabytes to something on the order of kilobytes now. Huh. And so, the thing that I I really like, kind of goes back to your question of what what do lattices do? What do they replace? Is that we have to, instead of applying generic techniques, so we could of of course say, "Oh, lattice is just the hash function."

Yeah. It's just a commitment scheme. Replaces the I you know the Merkle Yeah, Fry or something. Yeah, exactly. Replaces the Merkle tree and blah blah blah. Okay, you can obviously do that and you know this is something that we did do as a first step saying, "Hey, can we do it?" But, this generic thing never results in something optimal. So, like what I what I like I like to think that hey, you have to actually use some I don't know lattice-y techniques Ah. to to kind of get the most out of lattices. And this is what led to a lot of recent improvements in lattice constructions and as you know knowledge proof. So, let's say up until three or four years ago, we could barely do linear size

proofs with any sort of efficiency. And now we can do SNARKs. Interesting. Okay, so what I'm hearing from you is like the way we think of SNARKs where there's a sort of like plug in plug out. Like there's you sort of choose a type of cryptography. I mean you could use Fryer you can use KZG you know like basically you can take things like Fry and that could replace KZG. Yes, you have to alter it, but like you can kind of fit it in. In the case of lattice, it sounds like you actually have to rethink maybe at a more meta level what you're trying to accomplish with the overall system. This is like sort of what I'm getting from you that you can't necessarily just like plug and play.

So, you you can because you know the safe cryptography primitives you can get from lattices and so you of course you can plug them in. But, you won't get something that's interesting. Or something that works well and that's efficient. Yeah, well that to me that's the the same thing. Um so, like for example, let me let me let me say this. Why are lattices in why are they interesting and give you something like FHE? Hm. Right? So, if you think about pairings or whatever you exponentiation, you take it you it's a some map, right? That takes a number and and maps it into a group, right? A pairing takes something, maps it to some group, and you're kind of done. You cannot keep doing this operation. Whereas with a with lattice operations, right? This this ax equals

y, I'm taking a vector and I'm just mapping it to another vector. And so, the algebra of the range is pretty similar to the algebra of the domain. And this is what you have to take advantage of if you want to kind of get the most out of lattices, cuz this is I think their special feature, right? So, this is what a lot of this is what is done in a lot of constructions. You compute some this function this lattice function, so the a times a x. And then now you now you have another vector.

The only difference is now it's instead of having small coefficients, it has big coefficients. So, if you do this again, now it's no longer a hard problem. I guess from the perspective of a verifier, we need to know that the composition was done correctly, right? And so, that would add extra steps of proving and verifying. Uh yeah, but that's right. That's okay. Okay. Like that's not too much of a problem. Yeah, because we can always binary decompose. And that's just a linear operation, so if we can prove linear relations and smallness, we can prove as many of these hashing binary decomposition, hashing binary decomposition. Okay? So, that's that's nice. And the other the other nice thing is that when you map into you

because it retains its algebraic structure, now you can again do these now you can linearly combine all these all these results. And maybe you can prove something about the linear combination of them instead of each of individuals. Now, you don't need to store everything. You can just store linear combination. And again, this is where the fact that the algebra of the outputs is basically the same the simple algebra of the input really helps us out. Um, another thing is um, I'm just listing all these uh, you know, these things in our that we put into our toolbox in the last in the last couple of years. Okay, so proving that something is small, okay, it's proving that the norm is small,

right? And the the ring over which we work in lattices for efficiency is not not the integers, right? But it's a polynomial ring. So you can work over the integers, but it's much more efficient over polynomial rings. So all the NIST standards are over polynomial rings. And the nice thing is that hey, over polynomial rings, that's our basic operation. If you want to do inner product, well, that's actually the product of two polynomials if you just look at the first coefficient. If you kind of transform them correctly. So we can even describe the norm, the kind of this basic thing that we need as a lattice operation.

Right. Another thing is to prove shortness. You can use something called the Johnson-Lindenstrauss lemma, right? It was used for reducing the dimension dimensionality of you know, data. So basically if you have a lot of points, you know, in high dimensions, you can actually say hey, I'm going to look at a linear, you know, I'm going to look at the like some logarithmic number of dimensions and it and basically the norm is going to be preserved, you know, it's going to be scaled but preserved. So that's something we can do for lattices as well. We can say hey, look, to prove that something is small, let's actually prove that when you apply this this random transformation into a much smaller dimensional space, if that's small, then your original thing was small too.

And that's kind of pretty crucial if if your hard problem relies on this norm. But but of course this this causes a problem. I think this is something that maybe maybe it was mentioned by Dan Boneh that now if you're multiplying by this matrix, now it's very long. So now the verifier cannot be efficient. Mhm. So that's you know, that's something maybe we shouldn't do if we care about efficient verifiers, but maybe sometimes we don't care about efficient verifiers. So, we can do that. So, these are all these new techniques where which didn't exist, right? For with with anything else just because they weren't needed there.

Right? Are these being introduced in once you combine it with ZK or once you're trying to get it into FHE? Um so, FHE did not really use much of that. Of course, it used polynomial rings, but not that. But yeah, if you want to start proving things in ZK, then you you start actually caring about proving shortness. Got it. Um and yeah, so these techniques are very much related to these these proof systems. They were developed for this purpose. I do want to double-check because I think I you know, my initial question was about a SNARK.

Um you're talking more about like ZK and lattices, but not necessarily SNARKs and lattices. So, Right. but are lattices being used to construct SNARKs as well? Yes. So, once we got these these techniques in the toolbox, right? Then you could say, "Okay, what else can we do?" And actually, we can get uh something that is fairly SNARKy. So, there was this a SNARK kind of? Yeah. Yeah. Yeah, right. Got it. And this is why again, maybe we don't replace one to one. Okay. Yeah, so because you know, SNARK again could means different things to to many to different people. Like some people say it has to have an efficient verifier, some people say it doesn't.

Uh things like that. So, uh yeah, it's I I want to be maybe a little precise so that maybe there was a very efficient scheme that proposed by two colleagues at IBM. Uh so, Labrador by uh Ward Beullens and Gregor Zaverucha. And this actually uses a lot of the things that were developed in this this toolbox that I was talking about to come up with very short proofs. So, the verifier is still linear size, but the proofs are, you know, let's say about 50 kilobytes. It's so they'll never beat pairing based proofs, but they will beat hash based proofs in size.

What is it asymptotically? Asymptotically it's I think it's almost log log n, I think. Okay lovely. It is yeah, there is if you look at their paper, the size of the proof barely increases with the number of constraints. Maybe it goes from 50 to 55 as you go from like a thousand to a billion constraints. So it's it's short. But the interesting thing is okay, can you make the verifier efficient? So now there is these other ideas that maybe are using more traditional zero knowledge tricks like Folding?

Fold folding, right, right. Recursive composition as well. Exactly, exactly. Until recently it's really been two different groups of people that were working on these lattice things and the zero knowledge thing. And now they're being slowly merged. And I think you have the zero knowledge people learning the lattice techniques and you have the lattice people learning the zero knowledge techniques and and you you should be able to get things that are more efficient. So for myself for example, I mean I think even before getting to snark there's a lot of interesting things that one can do. For example, all the um anonymous credentials and identity solutions thing that doesn't require snarks or at least doesn't require efficient

verifiers because the the statements are not very long. It does require small proofs because you don't want to output too much. But efficient verifiers is not something crucial there. Yeah, simply because we don't get to big problems, right? So it doesn't matter. Right, right. So so you can do everything with lattices. The only question is can you do it efficiently? Yeah, and is it better than what already is being used there? Yeah, yeah. Actually you've touched on two things that I now wanted to inquire about. It's uh efficiency, like actually how do these things compare to discrete log-based systems, and practically, like how do we deploy these kind of systems and how do we write these sort of

proofs? Okay. So, at a at a low level, I would say that lattices should be a lot more efficient than anything else, even the classical stuff. So, as an as an example, so in the NIST competition, right? So, we So, we have the the current standard that that was chosen uh ML-KEM. It is faster than any other encryption scheme. So, in terms of computation size, it is maybe orders of magnitude faster just because these polynomial operations are so fast, and especially if you can take advantage of the uh parallel parallelism in in hardware.

Right, which which you can, right? This AVX2, AVX512 now, so this this all helps us enormously. It's bigger, though. So, if you if um transmission is an issue, then then now you have to uh count what saves you more the high efficiency of your local computation versus the transmission, right? So, in terms of that, lattices are are great. So, I was asking about efficiency. I was also curious about practicality, like how do we deploy these proofs? How do we write anonymous credentials, systems that use lattice-based cryptography?

Mhm. Yeah, this is this is hard, right? These proofs are, let's say, not trivial. The the building blocks are quite messy of these things. Uh something that I I've been trying to do uh with uh my colleagues here is to actually write these these basic building blocks, and then have a nice interface uh so people can use them. So, this is um So, we we have this laser library that we've been working on. Uh so, it allows you to prove, uh, some relations in zero knowledge and then the you in Python you can just call these, um, call these lattice operations, call these proofs and let's say in let's say 50 to 100 lines of simple Python you can

actually write your anonymous credentials, your blind signatures, uh, things like that, your aggregate signatures. But, I I I would say a lot of the research and maybe this is not even like zero knowledge related, but once you get to anything past encryption and signatures, I I think I feel like a lot of research should be on, uh, verifiability, right? You need you need some code or some logical system to verify that what you've written is actually correct. Because these systems are are very very complicated.

Mhm. So, just to be clear here, you mean like some kind of formal verification of the code. Yeah. Exactly. Exactly. So, formal verification is I think one of the more important areas of cryptography because, you know, there's an argument now between, um, kind of the English-speaking countries and non-English-speaking countries. I don't know why it broke down this way, but that's the argument that's how that's how the borders were drawn, that in the new uh quantum-safe um cryptography world, once you start using these quantum-safe schemes, do you use them in conjunction with the classical ones?

Mhm. In hybrid mode? Or do you just say, "Look, the classical ones we don't care about. We are confident in the quantum-safe ones. Let's just do the quantum-safe ones." So, the let's say the non-English-speaking world, and this is a perfectly valid argument, say, "Hey, look, we trusted these, uh, classical schemes. It doesn't harm anyone to keep using them in parallel with the quantum-safe the newer quantum-safe ones." The The other side is saying, "Hey, look, actually combining the two, even though it's trivial, like the theoretically, actually that's where all the mistakes happen in the real world, right? So, So, even for something so trivial as just combining two schemes together,

people are afraid that mistakes will be made. So, even if that that is kind of a worry, then I I would worry a lot about these extremely complicated pieces of software being rolled out that let's say not many people are looking at to to be to be honest, right? How many people look at these 100,000 line Oh, you're talking at a community of people who writes billions of lines of code and no one's looking at it and we love it. But yeah, there's a lot to to be checked here.

Yeah, but but I would say that that's maybe verification is the more urgent research area, right? Because we we have a lot of cryptography. Right? We we cryptography we can do everything with it. But do we have enough cryptography or attack techniques? Exactly. Attack attacking? Yeah. That's that's an area that that needs to needs a lot more research, needs a lot more people to go into it and formal verification. Yeah. So, but but those are not the I don't know, these are not the the cool areas, not the sexy areas, right? You want to be designing efficient snarks, you want to be doing this and no one wants to do this, you know, this auditing almost.

Yeah. If you call right? This is this is a bit of an issue but that's it's been like that all the time, so I want to go back just one step to some of the techniques that you were you were talking about. I think we got we started talking about lookup arguments which are not something that's being explored right now, but you did mention folding and you mentioned So, Nico, you mentioned recursive composition. I just I I feel like we kind of moved away from that in the conversation and actually I think we might be covering this on a future episode in more detail, but I did want to just briefly talk to you about how is folding being used alongside lattices?

Do lattices have certain qualities that make them like extra easy to fold? Yes, I think lattices are very easy to fold because of their algebraic structure. Like I said, if you are just apply the lattice function this AX equals Y, right? Now you can just break up your X into two parts, linearly combine them. That's basically your folding. Right? So to to prove that you know this Y, you can just break up X into two parts, linearly combine them, and the because all our functions are just linear.

Uh-huh. It's it's essentially folded, right? The hard part is always proving smallness. Hmm. The messy part is always proving smallness, right? So you can even try this as an experiment yourself. Like let pretend that the hard problem is there's no smallness involved. You don't have to prove smallness. Okay? I think I think these SNARKs will be trivial to design. Right? So you just because it it lends itself so naturally to folding. I can even tell us the the story when when Gregor and Ward were working on Labrador. I mean their first kind of drafts so they were they were work working of Bulletproofs.

Oh yeah. And trying to get the the folding from there. And then, you know, they were try they were trying and this is something I was involved in before as well in some theoretical paper. And we kind of said, "Okay, we're going to you know, try to mimic Bulletproofs." Right? And this is kind of what you were saying before like have you tried these techniques? And I was saying, "Ah, we should try the lattice things." Right? So when trying to to put lattices into the Bulletproofs uh construction pigeonhole or whatever. Construction, yeah, yeah, the technique. Yeah, you could get something, right? But then eventually they realized, "Hey, this this folding is just so natural to lattices. We don't need any of we don't even need to think about Bulletproofs when we do it." Just this linear combination

thing is I don't know in retrospect almost obvious. And I think that's what's being used kind of in all these other these other papers as well. And like I said, the hard part is how do you prove uh smallness? Well, I I I like that there's a lot of different techniques now for proving smallness, lots of ideas. Uh you know, there's the sum check way, there's the the the way we were doing the Johnson-Lindenstrauss way. And the interesting thing is that it is very nicely composable, right? So, you could cuz you could start with one technique, right? You get which is let's say leads to an efficient verifier, and you switch to the other technique, which actually leads to efficient small proofs.

Mhm. Right? Because after the first step, you don't care about efficient verifier anymore. Right? And I think the this composability is My prediction is this is the way it's going to be done uh with lattices. We're going to start with one technique and then move move over to possibly something like Labrador at the end. You kind of highlighted a few things that lattices bring, which you talked about like they're post-quantum. They in certain cases can perform better. But um I did wonder I I think the first time I heard about lattice-based ZK was actually in the context of FHE.

Would another benefit of using lattices just be that you could then start to do like combined FHE and ZK in an easier way? Like because you're using some of the same maths underneath? Uh for sure, for sure. This is This is something that um that is pretty important for designing efficient schemes, that you want the algebraic uh structure to be the same, right? So, for example, this is why when um uh designing uh you know, anonymous credentials, we want to prove some relation some lattice relations cuz and it makes sense to use lattice-based zero-knowledge proofs to prove these relations because the the algebra is compatible.

Mhm. Right? So, that that absolutely helps. You You could of course do um you know, you can just use Fry, right, to prove some lattice relation. And people have tried it, but it's extremely inefficient. Okay. Just because the algebra, you have to convert one algebra to the other, and it doesn't match. So, yes, of course, if if you have FHE, which uses which is basically using the same ring structure, Mhm. um, maybe bigger rings, but the ring structure is the same, and you want to prove something about it, it makes a lot of sense that you will use lattice-based ZK techniques That's cool.

to to prove it. So, that should definitely help. Nice. One thing I I did want to ask, and we sort of touched upon different techniques and different protocols throughout the episode, but I wanted to ask, what does the state of the art look like for uh, lattice-based ZK and lattice-based succinct proofs? Okay. So, I would say we're still in a very, very early stage of uh, succinct proofs. So, currently, the state of the art, if you just care about succinctness in um, terms of proof size, then it's the Labrador scheme, which is uh, we would say about 50 kilobytes for arbitrary-sized proofs.

Um, then if you care about uh, succinct verifiers, there's now been a lot of work on this. There's the kind of Greyhound um, addition to to Labrador, which uh, which came out maybe uh, 2 years ago. Now, there's Lattice Fold, Lattice Fold Plus, you know, and it's uh, A lot of folding. I don't know if it's how confidential it is, and I'm I'm on the committee for the crypto conference, and you know, there's tons of papers being submitted about is ZK lattice-based SNARKs. And you can see that it's really some of it is by lattice community, but some of it is by the zero-knowledge community trying to learn lattices. And you see that they're not quite there on the literature, just like the lattice people are probably not quite there on the ZK literature, but it's very hopeful to me. I'm I'm very

happy to see this, that the that it's clearly an area that's going to grow, like hash-based systems, for example. I mean, they've had a 20 20-year head start, Yeah. perhaps. So, I'm quite quite optimistic that if we spend another 5 10 years, uh lattice proofs will be even more efficient than they are now. Cool. You just mentioned the hash-based side of things. Um when you were talking about lattices, you know, they're post-quantum, they're quantum like secure against quantum computers, but hash-based SNARKs, at least, are also supposed to be safe against quantum computers.

Like, are lattices better? Are they more safe? Is there any sort of comparative there? Like, is there a reason why, at least on that um metric, lattices would be preferred? So, in terms of safety, I would say the hash-based schemes require you to assume much less. They just require you assume that something like SHA or AES is uh is hard. Okay. And, you know, these problems have very little structure, and we do believe that SHA and AES are hard. Mhm. So, in terms of assumptions, hash-based schemes are definitely preferable there.

Uh lattices, on the other hand, they do require some algebraic structure, and, you know, maybe there's a way that quantum computers can latch on to some structure, this algebraic or geometric structure, to break them. So, the assumptions, if I were to bet, if if anyone were to bet, they would, of course, bet on uh hash-based having a smaller chance of being broken than anything like lattice-based cryptography. Uh so, that's where hash-based is better. But, because lattices have these algebraic assumptions, uh the math behind them is is, let's say, is easier to implement.

Oh. So, they're going to be faster. So, lattices, I believe, will win on efficiency, whereas hash-based wins on uh the probability of being broken. Interesting. It's hard to say that they win on security, right? Because they both could be equally hard. Okay. It's just that if you're going to bet and somebody tells you one of them is, you know, some somebody tells you one of them is definitely broken, well, it's going to be lattices, right? All right. Is it just because they've been around like not as long? They haven't been battle tested? No, lattices. Lattices in this context.

Oh, no, I would I would say even for classical algorithms, right? Discrete log pairings are those are much more likely to be broken than anything hash based. It's the structure versus unstructured thing, right? Exactly. Exactly, Nico, right. Because lattices and all these other discrete log assumptions, they're all structured. They have a something that quantum computers can latch onto. But it's always about the efficiency and this is where the structure helps. I will throw a little spanner in the works, though, which is that all our hash based proofs are only proven secure in the random oracle model.

Yeah. Is that also the case with lattice based proofs? Or Yes. Yes. Oh, it's also random oracle? All the anything interesting is going to be in the random oracle model. Okay. Yeah. That's super interesting that lattice based proofs are still in the random oracle model because with discrete log and like pairing based proofs, we do have systems that are in the structured reference string model, but no random oracles involved at all. Okay. So, now, I could be saying something very wrong. Um but I think there could be a way to not have random oracles if you make some crazy assumptions.

Right. And in the pairing world, nothing has at least nothing that I know of as somebody who's maybe not very deep into it, but just an outsider, that has gone wrong with these crazy assumptions. Whereas in the lattice world, things have gone wrong. So, all there's been a very interesting recent paper that showed all a lot of knowledge assumptions where you say ah the only way for you to do this is if you know this. Basically, if you know how to do this, then there is an extractor that can extract this information from you that people try to make about lattices and it turns out to be completely broken in the quantumly.

Interesting. Right? So, yeah, so it is a bit and these these these knowledge assumptions uh these um yeah, unfalsifiable assumptions, I think they are quite in the you know, ZK world. If you're going to not use maybe random articles or something like that. But, they are dangerous to make for lattices. So, I would much rather go with random articles. I don't see a big problem with them. Uh rather than these assumptions these assumptions which have not shown themselves to be very stable.

Yeah. Fair. Um so, you've been involved in the development of standards for encryption and signatures for NIST and we've mentioned them a bit earlier. Uh ML-KEM and ML-DSA. Can you tell us a bit more about them and how they work and how they compare to existing encryption and signature techniques? I think the best way to understand what the difference between lattice and discrete log is to to think about um the key exchange. So, Diffie-Hellman key exchange, right? So, Diffie-Hellman you have g to the x equals uh you know, g to the x1 equals y1, g to the x2 equals y2. And then you have g to the x1x2 is the is the shared Yep.

Think. So, with lattices you don't have that because the the equivalent of like g to the x is the LWE function like a * x + an error. Right. And now, if you have a * x + error and the other guy has like some x1 * a + error, you can do the appropriate thing. But, now you end up with errors. You now you end up multiplying by the errors as well. Right. We have these cross terms sort of that start appearing. Yeah, exactly. Exactly. These cross terms which you don't know about cuz I don't know your error, you don't know my error, so we don't know what the cross term And we obviously cannot reveal our errors to each other, otherwise it's all broken.

Exactly. Exactly. So it's a Diffie-Hellman key exchange is actually something that does not work. This Nike is quite bad for that. You can do it. You can set the parameters so that it it works out with high probability, but then it becomes really terrible. But with public key encryption, it's not so bad because because there we're not there there is some interaction involved, right? Whereas in the in Diffie-Hellman key exchange, there's no interaction. Here basically that you we can do something. But it's again about clearing out these errors. So this is what This is what ML-KEM is. It's like the It's how you naturally apply ElGamal, how you translate ElGamal to lattices, and then you take care of the errors.

And that's the messy part. Uh the ML-DSA, it's this is something we mentioned before. I said, "Okay, you it's you're trying to do the zero-knowledge proof." And you try to do as efficient a zero-knowledge proof as possible, proving something that's good enough is good enough for signatures. And this is yeah, it's like you take Schnorr and you say, "Okay, what goes wrong when I try to apply it to lattices?" And then let's let's keep fixing it up and optimizing it. So that's ML-DSA. So if you actually look at that tutorial and you look at ML-KEM and ML-DSA, you don't need to know what a lattice is to understand what they are because it's just matrix vector operations.

Do you think the whole of lattice-based cryptography is going to end up in a space where people don't need to know what a lattice is? So for cryptanalysis, you do need to know what a lattice is. Uh but I think um we could end up in the scenario where uh kind of similar to the pairing scenario, where people know what pairings do, but they have no idea what pairings are, what is underneath. I mean even with elliptic curves, right? We have Yeah, a group, and we don't even need to think about the curve. Right. So you you could it could be distilled enough to say, okay, look, we have this I mean, where lattices really come in and they they trapdoor functions. So, that's uh you do need to kind of know what a lattice is there, but you could distill it and say, here's here's a

matrix, you get this pre-image, and you know, don't worry about it. It's good enough. Yeah, so we we could get to this point, and that would be really good. Uh but I think it right now the research is not quite there. I think if you're going to do research, you're going to come up with something more efficient, uh you should know what a lattice is. Right. Yeah, especially for cryptanalysis. I mean, there there it's much more complicated, and I think you still need to understand what the cryptanalysis is, what the lattice that people be attacking in your scheme are going to be to to design the most efficient scheme.

So, that means specific to the parameters chosen? Yeah. Yeah. I mean, there there are there are scripts, of course, that say, okay, if you can use parameters this, but I still think you have to understand. There's there's too many mistakes that one can make, um you know, just trying to apply things without any understanding. We're not we're not there yet. But I I don't see why why eventually we we will not be. So, now uh in terms of encryption and signatures, I would say we're in a pretty good state. We have standards, people are deploying them. Of course, it's hard work. You're replacing all the current algorithms with uh quantum-safe versions, because first you have to find where the cryptography is.

And actually, a lot of like work being done by my colleagues at IBM is really on that, trying to up be able to upgrade these systems. But but now I actually have a question maybe for you guys. So, in in your space, in your um you know, the the the blockchain uh SNARK space, there's a lot of stuff that is not quantum-safe. Mhm. And so, what what do you think uh the urgency is? Or what what do people think about upgrading to quantum-safe? So, something that, you know, the the the reason that you want to upgrade to quantum safe. I I think there are two reasons, right? One is harvest and decrypt, right? So, everything that's encrypted now uh using classical cryptography can be stored and then decrypted later. Uh so,

the secrecy part is gone. So, that's I think that's the main thing people worry about. But, I think in in the blockchain like your space, there's a second one that you can actually deploy systems now that really have no path for migration. Mhm. So, like and as an example, I can give you a very simple example like um you know, digital cash, right? With blind signatures. Right? If you get somebody to sign uh you know, random things now and these are my tokens, once quantum computers come about, what do I do with these tokens, right? The the signatures are invalid.

So, okay, anyone can forge them. So, you can't you can't sort of allow these to exist, but you also can't just say, "Well, everything's invalid." because now everyone lost all their money. Mhm. Right? So, now that that's what I mean, but there's really no path to migration. There's nothing you can do. that's interesting. Yeah. I I'm going to split what you just said into two parts because I think on the blockchain payment side, I know one project that's trying to help with the migration to a post-quantum system, but it's not within the cryptography of the system itself. It's actually in creating like a parallel quantum secure blockchain that would have some benefit of migrating over.

Hard sell for some people, but it is a possibility. That's on the blockchain payment side, but what you were talking about was also like the ZK basically any of the systems that are still using elliptic curve pairing based cryptography. And a trend that's actually happened in our space was in especially in the last 2 years is like there's a move there's been a movement towards more systems being hash based because there was like the desire to scale. That's where a lot of the funding was coming from. So, So, was like small fields, proving server-side, privacy doesn't matter. Let's go hash-based. Throw a bunch of compute at it. It's kind of quantum secure-ish.

But, there is now recently this move to like return to client-side, and there you're seeing pairing still being kind of relevant. But, my my sense, and Nico, I wonder if you're following this closer, but like my sense is there's often like transformations along the way where like maybe a a quantum-secure version could be introduced. If you're doing recursion, or if you're doing like is it and can you just kind of add a quantum-secure system? Would it make the whole thing system secure, or does it actually not help at all? For all our proof systems, we're fine because we do have these hash-based proofs, and it's just a matter of tweaking the parameters to make sure that we're secure against like quantum adversaries.

Mhm. What Vadim was also talking about is like all our signature-based systems, so our layer ones that are using Yeah, just ECDSA. Mhm. Um how how do they fare, and how do we upgrade them? And we discussed this actually in another episode of the podcast was with Orza Toth. Oh yes. And he talks about uh super interesting techniques like signature lifting, and this idea that Okay, so right now what we're doing is we take some kind of seed, we hash it, get a private key, and then we publish the public key. A quantum computer will go from the public key to the private key, but cannot reverse this like hash. And so, the idea is there is to use the seed as our private key, and the hash of it,

which would have been the private key before, as our public key now. Oh wow. And so, that's one way to sort of save these legacy systems. Uh it's not very pretty, but it allows you to sort of in an emergency transfer your funds away. Mhm. And yeah, otherwise you have to build from the ground up with post-quantum secure primitives. Yeah, and just encourage incentivize people to move it over. There is a project, Project 11, my friend Alex Pruden just joined. They're doing exactly that. We might get them on the show at some point. But yeah, it's a it's a tougher it's more like a social challenge to just like convince people to move to a new chain or you know, to trust it.

Yeah. Also, Harvest now decrypt later. This is a big deal because I do see a lot of people talk about, "Oh, let's encrypt medical data and put it on chain." No. No, please do not. Even if you do it with post-quantum secure algorithms, you never know what's going to happen in the future. So, just don't do it. Put our commitments on chain. Those are perfectly hiding and we're okay with that. Right. Yeah, so I think what you brought up, right, is is very it's kind of similar to what I was thinking, right? You don't need to do a lot now, right, to to get your system to the point where you actually can migrate later, right?

So, these like the the signature thing you were describing, yeah, it will not work once we actually do have quantum computers cuz that still can be you know, that that the part once the seed is expanded. That then then you can start forging, right? You can still use everything until quantum computers are built normally. And then once they exist, you can say, "Hey, look, I still have this information that could not be cracked by quantum computers. Let me now, you know, do something with it. Let me exchange it. Let me whatever." So, there are very simple things you could do without actually becoming quantum safe. So, we we sometimes say it's a quantum ready, right? you can at least have a path to for migration.

Well, quantum ready almost by accident, right? It's like, "I'm ready, but I didn't know I was going to be." Well, yeah, okay. So, in that case, yes, but there are some things like what I described with like with with the bloodline signatures, right? There, you do have to do one little step, right, to become quantum ready. So, and these are very cheap things. So, I'm just wondering if if the community is saying, "Okay, look, we we don't want to implement ML-DSA right now because we don't know if it's going to be needed in 5 or 10 years. Let's let's kind of push everything back as far as possible, but maybe we should have a path to migration.

Mhm. I almost get the feeling that when it feels easy to migrate, people don't take the threat as seriously. It's like, "Oh, it's fine. It's easy. We'll figure it out when we get there." You know, and maybe you need a bit more, you know, fear. Right. Well, every time there's big quantum announcements, people for a second scramble to check. Yeah, for for a second. So, Vadim, before we sign off, is there anything like maybe you can share what you're working on today? What can people expect in terms of research coming out of out of your group?

Yeah. So, right, I think we've touched on many of the things that we're working on. So, one thing is of course trying to get more compact SNARKs. Another thing is to try to get zero knowledge, actual zero knowledge in the way Privacy. uh use. Privacy, yes, privacy. ZK ZK SNARKs? ZK Yeah, yeah, ZK ZK. Okay, that's I didn't know that was the terminology. No, no, I'm just joking. Like, ZK SNARKs is supposed to have ZK in it. It just gets kind of misused, so Right. So, with Lattice, as it turns out, it's let's say there there is some added complexity when you actually want to add ZK to SNARKs. So, we're trying to to work to work that into now our like Labrador

library for Labrador system, for example, and try to make it as efficient as possible. And that, of course, like I said before, that will not just be particular to Labrador, because I think later you may want to combine have it be the the lower level of your of your full protocol right? And once you have the the top layer using whatever you want, and then you kind of feed the result into Labrador, you want that part to be zero knowledge as well. Uh if you care about privacy, which which I think we do. Yeah.

Cuz a lot of it is also like anonymous credentials, identity solutions, this this like central bank digital currency stuff like that. This is something that it is on the radar that does require all these privacy-based solutions. And that's something that it that interests me right now. But of course also reading these new results that are coming out of the zero-knowledge world, right? About about fast verification, about using all these techniques that we haven't used yet when we're developing the lattice toolbox. And obviously I'm I'm going to go on not a very dangerous limb to say obviously this will be somehow combined together and we will get something much better when these two communities come together. So this is

something that I'm definitely looking forward to. That's awesome. seeing in the next next couple of years. Uh yeah, personally I feel like the field isn't going in a really good good direction. Uh so there's a lot more work happening, right? So maybe some people would be stressed out but you have to keep up with a lot of it. But on the other hand as somebody who's worked and who cares that this is going in the right direction, I'm actually quite happy and more relaxed that's saying hey look maybe it won't be me who does it but it will be done, right? So so I'm very let's say very optimistic for uh what's going to happen in the field. Vadim, thank you so much for coming on the show.

Uh thanks a lot Anna and Eran, that was really good questions, really nice conversation. And I'm so glad we got a chance to do a proper deep dive into lattice-based CK systems, something we've wanted to do for a long time. Maybe not even only the CK side of things, just lattices in general. This has been great. I want to thank Dan Boneh for the intro. He basically recommended we get in touch with you Vadim for such an episode. So yeah, thanks again Dan. Thanks a lot Vadim for coming on the show. This was super enlightening. Looking forward to seeing our research communities merge a bit more.

Yeah. Yeah, me too. All right, I want to say thank you to the podcast team, Rachel, Henrik, and Tanya and to our listeners. Thanks for listening.