Post-Quantum Transaction Signature Breakout #5

Transcript

Antonio Sanso: But that'll be noted.

Hello everyone, we'll give a couple minutes, as usual.

Alright, let's start, Today's a kind of special event. We're running live from Cannes. We have, as well, a different time zone, so… More than time zone, change the time, so the call is 1 hour before then used to be. In any case, this is the… Fifth occurrence of the post-quantum transaction signature breakout room. Today, is about hardware support. And, we will have the presentation. the first one from Connor Diggin from Project 11, and it will show Some of the papers that, was presented a few weeks ago. About… key derivation… Bip32 for Lattice. And, then we'll have Yannick from, Trezor, sorry, from Ledger, talking about post-quantum signatures and hardware signals.

Before to give the stage to Connor. I just want to shout out, Julio. From, Erigon. He put some, Testnet plus wallet at this, freshly… both address Daizugi. And contains some of the things we have been speaking. In the previous calls. And, so, as you can see from the screenshot, there is a… some of the algorithms we discussed, like Falcon or Dilithium, and the more recent ephemeral ECDSA for now. Probably he is working as well on some ephemeral… Hash-based signatures, let's see how it goes. And, with this, I will give the stage directly to Connor. You have about 10 minutes.

Conor Deegan: Great. Thanks, Antonio. I will just share my screen. Sorry, to Mac. Usual Mac things, just let me rejoin the call once, give it sharing permissions to Ethereum Zoom.

Antonio Sanso: Correct.

Conor Deegan: Great, sorry about that.

Antonio Sanso: All good?

Conor Deegan: Okay, great. Hopefully, you guys can see my screen.

Antonio Sanso: Sure.

Conor Deegan: Great, great. Okay. Nice to meet you, everyone, who I haven't met. I'm Connor from Project 11, I'm a cryptographer. First, Antonio, thank you for asking me to speak at this. What I want to go through today is a paper myself and my team released, I think, about 3 weeks ago at this point, which is, you know, an idea for how we can maintain BIP32 in a post-quantum setting. This is gonna be a Lattice proposal, which obviously, you know. Terium Foundation, and for those at Antonio's talk this morning, it's, you know, moving towards hash-based, so I think largely what I wanted to get across here is… is less around, like, specific schemes or hardness assumptions, more just general kind of a way of thinking as we migrate, you know, various infrastructure to post-quantum.

So, I don't think I probably have to spend a lot of time on this slide. I'm sure everyone knows what a hardware… or, sorry, a hardware… a hierarchical deterministic wallet is, but for those of you who maybe haven't read about it in a while, it is a Three of key pairs from a single master seed. And one key feature of this is Non-hardened derivation, or… extended public keys, whereby you can derive public keys from a parent public key without the presence of the private key. This is helpful for lots of reasons. One of the biggest is you can have a server which can generate fresh receiving addresses on demand, and your private key can remain on some sort of cold store or signing device.

So pretty good security posture to be able to have something like extended keys. Very easy in bit32 classical setting, because addition in elliptic curves is linear, so I'm sure we've all seen this before. That breaks as we move to post-quantum. I can touch briefly at the end, maybe on, you know, explicitly how it breaks for hashes, but, you know, TLDR is… it's next to near impossible. But lattices do offer maybe some ideas on how to do this, but there's two large problems that Lattice introduces that makes doing extended public keys or non-hardened derivation quite difficult. The first is, during things like public key generation, a lot of the schemes do rounding to drop low-order bits to reduce some sizes, which is great. It means that we get slightly smaller public keys.

But rounding destroys distribution addition. My small way brain of thinking like that is, if I ask everyone to add 2.3 and 2.3 together, you'll get a different answer whether you round before or after you perform the addition. So rounding isn't stable under addition. The other obstacle is noise. So, as I'm sure a lot of you have seen with lattice-based schemes, we have to introduce noise in a post-quantum setting. The issue is pretty easy in that one, that as we kind of generate more and more of these from a parent public key, we add more and more noise, and so after a while, we end up with a statistically different distribution, from child keys to parent keys, and one issue with that is, one key piece of bit 32 is unlinkability. I shouldn't know that one key is further up a hierarchical tree than another. We want these things to be unlinkable as much as possible.

So… Oh, sorry, maybe just to give a big shout out to some of the prior work, these are kind of the three main, major prior works, all excellent papers. I'll share the overall R paper with you at the end of this, and these are all referenced throughout. They all have different approaches to this problem. One of them, for instance, just destroys the idea of non-hardened paths. They just say, we'll only ever do hardened paths, i.e. the private key must be present. One of the others uses Q-Tesla, which was a digital signing algorithm, which is now, as far as I can tell, not maintained as much. And then the last one there, which is very impressive, just the only downside is it's

Proofs are quite complicated. They don't reduce to standard lattice assumptions, so one of the things we wanted to do is reduce our… reduce our security proofs to standard lattice assumptions. So, what do we build? We have two constructions of this HT wallet, and again, as I say, both proofs reduce to standard lattice assumptions, which is a nice assumption, because it means that we don't have to introduce new hardness assumptions. Bar are the ones that come with a lot of schemes. Construction 1 is very easy. This is not new work, this is not novel work. This is a MLDSA HD wallet. For the record, it doesn't need to be MLDSA. It is a very standard idea. We are just effectively copying what ED DSA chains do, like SUI and Aptos, whereby instead of the private key being the output from the,

tree of derivations. They treat that as a seed, and that seed further goes through a further key gen algorithm to generate private-public key pairs. So this is trivial, and we could do this with any scheme that offers a key gen function, which is any scheme. So this isn't novel or new. What we do, though, in this one is we do add full unlinkability and unforgeability proofs, so that is net new work. We prove the security of this construction under standard lattice assumptions. The second thing we do is the new work. So this is now the first, from what we can see, of non-hardened, i.e. extended public key, lattice-based post-quantum DIP32. We use a scheme called RaccoonG for this, and I'll get into why we use RaccoonG in a few minutes.

I want to be very clear on this. This is not a recommendation to deploy RaccoonG. We are not the authors of RakunG. RaccoonG didn't pass NIST's second ground of standardization, for no reason, except for the fact that NIST wanted more diversity in their algorithm selection. They didn't want lattices. It's not broken, it's still maintained, but this is not an endorsement of RakunG. But the point is, we want to demonstrate that, you know, we can still maintain BIP32 full functionality, and what the criteria to do so are, i.e. what algebraic properties you might need, a scheme to support this. Okay, so very quickly then, how does this work? So RaccoonG, as I say, it's a variant of Raccoon, which is, one of the post-quantum algorithms, and it was introduced in 2024 in Eurocrypt. Again, it's a great paper.

And the big difference between raccoon and Raccoon G is the G stands for Gaussian, so the keys are chosen rather than from a uniform distribution, they're chosen from a Gaussian distribution. Which, I'll explain why that's helpful in 2 seconds. So, how do we get over the first obstacle? So, I mentioned two obstacles a few minutes ago. There was rounding, and there is noise. Sorry, someone's calling me. there is rounding, and there is noise. So, the rounding is pretty easy. How do we get over rounding? Well, we publish the full unrounded public key. This does mean that we end up with slightly larger public keys, but it means we can do stable addition. So, again, this could be done with any scheme. You know, we could go into Dilithium, MLDSA, whatever it might be, and we could pull out the full unrounded public key.

Obstacle 2 is Gaussians have a nice property that the sum of independent Gaussians remains Gaussian. So this means that derived child… children key pairs, child key pairs, rather, sorry. remain statistically unlinkable to parents, because some of their distribution remains Gaussian. That is not the case for uniform distribution. If you add two uniform distributions, you end up with more of, like, a pyramodal, style distribution, so you'll be able to tell that these things are the addition, i.e, they're further down the hierarchical keychain. But Gaussians are… remain Gaussian under addition, which is… which is quite a nice property. So any… basically what this means is any… post-quantum scheme that uses Gaussian distributions, you know, this property could be… could be plausible. One scheme that was interesting was dilithium G, but dilithium G, which is dilithium with Gaussian, was actually removed formally due to… due to some other errors and bugs in the paper, so Raccoon G was the… the scheme we decided to use.

For those of you interested, that's effectively how public and private key derivation work. I have a GitHub and a Rust implementation at the end that I'll share, which will make this more interesting. But this is effectively how we can do public key only derivation, and then the private key can then retroactively go and make the same key pair for the signing event. As I said, one of the core things we wanted to do here was reduce all of our security to standard lattice assumptions, so that's what we did. There's largely two important assumptions we need to have. That's unlinkability and unforgeability. So, as I said, derived public keys must be indistinguishable from parent public keys. And we basically have a proof,

through a cryptographic game, that up to a certain depth, this is true. And that depth, by the way, is, like, something crazy. I think it was, like, I think it's, like, half a million. child keys, which is obviously ridiculous. I don't think any wallet's going to really get up that high, especially because BIP44, which is the most common use, like, implementation of BIP32, which is still using Ethereum today, really only goes two levels deep with non-hardened paths. So, we can say up to a million, it's still unlinkable. in, like, almost all cases, it only ever gets two levels deep anyway, so they're completely uninkable at that point. And then unfortunability, obviously, you know, crucial for any sort of key derivation scheme. And again, we reduce our entire assumption to the base underlying scheme. So the re-randomization is linear, so we can effectively

remove that re-randomization step, and then the entire unforgeability proof just reduces to the unforgeability of the underlying scheme, which in Rakun G's case, is sound. Yeah, I kind of said that already, so I don't need to go into this. What's the big downside? Well, there's… there's loads. So first is… this is lattice-based, you know, hey, we, Antonio, gave a great talk this morning, that with a kind of traction, you know, there's gonna be people who probably end up using lattices, you know, whether or not that's the kind of main decision from from others, but that's the first big trade-off. The second major trade-off is its size. I mean, here we're, you know, look at these sizes. They're pretty, pretty nasty. I don't for a second think that this is something that we should be deploying today, but I do think it's an investing step forward.

What? Do… Oh, that's from the previous… that should be on the previous slide. Apologies, I think. And then, as I said, this is not a… not a, you know, endorsement for Kunji. This is kind of, I guess, the more interesting point. This is my… penultimate slide, but, you know, I think one thing we kind of all still talk about is, you know, which schemes should we be using? I think the next phase we need to get to very quickly, is ecosystem parity from previous, you know, from the pre-quantum world, and… This is non-trivial. You know, electric curves gave us such beautiful structures that we could do a lot of things with. As we all know on these calls, that a lot of that disappears quite quickly with post-quantum. You know, we think this is one example of an area where we may want to maintain feature parity. Maybe we don't. Maybe we can say we can throw it out.

But I think a big push for us, and for me personally, in terms of the work I do, is how can we maintain, you know, infrastructure-level parity, despite changing these new schemes out underneath the hood? And that might mean rethinking how the schemes work, but ultimately maybe offer the same API, or something like this. So that's kind of the bigger point of why this work exists. hey, for… for HD wallets, maybe we can use RakunG, and maybe that solves the problem. I think there's still a lot of… plenty more work to do, but I think it's a cool start. Would love for people to tear apart the paper, play with the code. Tell us, you know, where we could make it better, or fork it off and do something cooler.

And that's it. As I said, there's some Rust code there. I don't like QR codes, because I don't scan them, so I didn't put a QR code in, but I will share these links in the chat. There's some Rust code there, there's the paper there. Thank you very much.

Antonio Sanso: Thanks a lot, Connor. I have actually two questions myself, I didn't check in the chat, but I have two questions. One is, like, it's about the key derivation. I agree with you that you say 500 million? How many derivations?

Conor Deegan: Yeah, yeah, yeah.

Antonio Sanso: I was actually wondering, just, like, out of curiosity, you probably have seen today at my presentation, the people were… I presented this, ephemeral Yes. Mode, that in theory works with any construction, right? I mean, will be possible to derive ephemerally from the seed, one public after the other with your way? Up to 500 million?

Conor Deegan: Yeah, absolutely. So, and I know that some of the folks who… who presented that ephemeral, on the call last week were there today and are here on this call, which, by the way, as me and Antonio caught up earlier, I think it's a… it's a really cool construction. This works absolutely alongside that. The ephemeral stuff, you know, you could probably take us… take it even further and do more interesting things because of the fact that we… we're kind of guaranteeing ephemeralness. So if we can remove even some of the constraints of how deep it needs to go. and actually just generate fresh key pairs. But I think to answer the question directly, Antonio, this would absolutely work alongside some sort of ephemeral scheme, where you end up with a post-quantum, stateless, reusable scheme, even in an ephemeral setting, which can be helpful, because, you know, one, obviously the drawback to the ephemeral key solution is

you know, any sort of errors require possibly signing again, which maybe requires a few time signature, whereas something like this would be fully stateless, so you could just retry, you know, unlimited times, and the security problem won't be, yeah, won't be.

Antonio Sanso: Excite.

Conor Deegan: You know, you won't be leaking key material.

Antonio Sanso: Like, for elliptic curve, basically.

Conor Deegan: It's exactly the same.

Antonio Sanso: Right. And the second question is, like. How… and I already answered it before, but what is the chance you can replicate this for… Hashbase signal.

Conor Deegan: Yeah, right? Yeah. It's… I think it's zero. I, I, I spent, a long time staring at a wall, trying to think about this. you really have to go outside the box, you know, doing anything naive doesn't work, just given the way that, you know, there is no concept of adding, you know, two hashes together, and then getting the pre-image, you know, of the second, you know, of the child hash. You'd have to, you know, if we had Grover's algorithm, we could do it, which would be fun, but without that, there just is no way. So right now.

Antonio Sanso: It's a post-post quantum algorithm, basically. Yeah, yeah.

Conor Deegan: I think right now it'd be a post-quantum only. Yeah, from what we've seen anyway, there's no nice way of doing it all with hashes. The best way is really bad, and it's probably the only way, is for the signing device to probably batch generate a couple of thousand, you know, say, key… key pairs, and then only give… send the public keys out. But I'm sure when we talk to the… we've actually spoke to both Ledger and Trezor about this problem, and I know Ledger's about to speak now. But obviously the signing device generating, you know, say, even a thousand hash-based key pairs. And then only sending the public key you know, all the public keys out to, say, the hot device, like the laptop, you know, that's still obviously a challenge. And then every time you want to refresh your batch, you have to go and plug your, you know, get back onto your signing device and ask for a new batch of keys.

Matteo Vicari: Sorry for interruption, but For, one-time signature, using, this key, the key is more light, and it can generate more faster. And, in… in this… using one-time seniors can help, the hardware device to generate more keywords, and then try to have… the same effect of the femoral key using just one time signature.

Conor Deegan: Yeah, absolutely. Something like a one-time signature, which is… the key then is the ops, I mean, the benchmarking ops for those, it's such a light operation. And that's where I think it would be better to actually probably use a smaller, you know, one-time signature or a few-time signature, because if the idea is we want to keep everything ephemeral, we might as well go with a very light algorithm choice, like a WinterNets or, you know, whatever, you know.

Matteo Vicari: Yeah, yeah.

Conor Deegan: completely agree.

Matteo Vicari: Dude, it's… Okay. And there is some BIP that can help to, because for all we can generate, we try to have a prototype for working this. We start using B44, And, use the, like, the seed of the B44 and all the key, and then, derivate the one-time signal from the, Ayy. B44, key parts. And actually, something can be done, or…

Conor Deegan: Well, actually, I would… maybe we can… I'm not sure if I'm here in Cannes, and we can maybe chat…

Matteo Vicari: We can chat, yeah, yeah.

Conor Deegan: Yeah, BIP85 is the short answer of something that we can look at, which we've used extensively, and I've done a lot of work on. So BIP85 might be another thing that we can talk about.

Antonio Sanso: If you guys look at… give a look at this here in Cannes together, it will be, like, amazing. Like, incredible.

Conor Deegan: Yeah, while we're here, we might as well, you know, have these So, no, definitely, I…

Matteo Vicari: We are in their corner food now.

Conor Deegan: Oh, nice! I just ran back to my hotel, but I'll come straight back over here.

Stefano Gogioso: I'd like to also join if you're having this discussion.

Conor Deegan: either.

Stefano Gogioso: I'm in the same place.

Conor Deegan: How are ya?

Matteo Vicari: You're all together.

Stefano Gogioso: places, everybody else.

Conor Deegan: Fantastic. All right, well, I'll come hang out with you guys after this.

Antonio Sanso: So, next is, Yannick. Yannick, I don't know if you're in Cannes as well, but, I mean, in case you just… you… welcome to join.

Yannick Seurin: No.

Antonio Sanso: And.

Yannick Seurin: Unfortunately, everything in Paris.

Antonio Sanso: Okay.

Yannick Seurin: Can you hear me well?

Antonio Sanso: Yeah, yes, yes, stage is yours. Thanks a lot for accepting the invite, and Nick.

Yannick Seurin: Yeah, sure. Thanks to you, Antonio. Let me share my screen. Can you see the slides? Can you see the slides well?

Antonio Sanso: I mean, yes, now, now yes, perfectly.

Yannick Seurin: Okay. Okay, so thank you, Antonio, for inviting us to speak here today. So, I'm Yannick, and together with Alain, we work at the security team at Ledger, more commonly called the Ledger Dungeon, and today we will speak about the challenges of implementing Post-quantum, signatures on hardware sinus. And before starting, let me precise that what we call hardware signers is what we used to call hardware wallets, but we recently decided to change the wording a bit in order to make clear what these devices do, namely hold securely your secret keys and allow you to sign transactions. And it was causing a bit of confusion, because These devices have to be used with a piece of software which is running on your laptop or your mobile phone, and people often confuse the role of the device and the role of the software.

Which is to manage your accounts, and so on. So, to clarify things, we renamed hardware wallets to Hardware Signers, and the piece of software which we use at Ledger, which was called before Ledger Live, is now called Ledger Wallets. So, I think it makes things a bit more clear. So, first, let me, recall about what… briefly recap what the current situation is. So, the blockchain landscape today is… that is, before the quantum threat started to loom, is pretty homogeneous. Every blockchain is relying on elliptic cryptography. Mostly based on the same curves, like P26K1, and mostly use the ECDSA signature scheme, or variants like Schnor or at DSA. And this…

Antonio Sanso: Yeah, Nick, sorry, I don't know if you want to change the slide. Okay, yeah, I think you were… Okay, now it's better, yeah, sorry, sorry.

Yannick Seurin: No, you see what…

Antonio Sanso: But I know… I know they said you were on the wrong slide, thank you.

Yannick Seurin: Okay, now you see the good slide, nice. So, this allowed a large blockchain support in hardware. in the hall to assign us. But now, with the threat of cryptographic… with the threat of quantum computers, we need to move to post-quantum signature seams. Unfortunately, the NIST competition for post-quantum signatures did not really target constrained platforms. The primary focus was rather to secure the internet traffic, let's say. And because of that, none of the current standards that we have, that is MLGSA, SLHDSA, and Falcon, soon to become the FNDSA standard. None of these standards is really hardware friendly. So, this doesn't mean that it's impossible to implement them in constrained platforms, but compared to elliptic curve cryptography, which was very efficient in hardware and also pretty easy to mask and to protect against physical attacks, the situation is radically different with these new standards.

So… Let me… prudent, The architecture of our hardware signals. Before that, let me precisely that this architecture is specific to Ledger devices, and other vendors have slightly different architectures, but the constraints will be pretty similar. between vendors, I think. So, our signers rely on two chips. the MCU, which is, STM32. And… and a secure limit. And the difference between the two chips is that the NCU is rather high-end, but it is also much less secure against physical attacks. On the other hand, the secure element is more constrained in terms of memory and clock frequency and so on, but it's also much more secure against physical attacks. And the way we use these two chips is that

really, the MCU, we'll only do, dumb things. Namely, it will only be used as a kind of footer between the secure element and the peripherals, like USB, Bluetooth, and so on. And because since the MCU is not very secure, we don't want to have any critical logic or any secrets inside the MCU. So, all the critical operations will be done in the secure element, and in particular, all of the secrets are stored in the secure element, and never leave the secure element when used to sign transactions. And so all the applications, like the Bitcoin application, the Ethereum application, any other application running on the device, will run inside the CQ element. There is a mechanism of application isolation based on,

ARM memory protection unit, and in particular, each application is restricted to its own memory region in the SE memory. Also, the device is restricted to a single task model, where only one application can run at a time. And the SE also provides a cryptographic accelerator, providing hardware acceleration for, for example, AES or elliptic curve operations. And in the future, as we will see, some post-quantum signatures. So, no, let me… show you how, constrained these CQ elements are. So… Here is the range of devices that are used, of secure elements that are used by our devices. As you can see, the very first device Had a very low, amount of RAM, 10 kilobytes. The next generation was a bit better, and the current generation of devices, which rely on the ST33,

have 1.5 megabytes of non-volatile memory, 64 kilobytes of RAM with 2KB of cache, and have a frequency of 70 MHz. So, as we can see, the amount of RAM is pretty scarce. And given that post-conterm signature schemes tend to have a rather large RAM footprint, this will be, a problem, as we will see. And also, the clock frequency is not that high, and for schemes like SLH GSA, which require, a lot of hash computations, for example. The time to compute a signature Will be very large, as we will see. So as I said, the, ST33 provides a number of things, like hardware acceleration for AES, and, A coprocessor for elliptic curve operations. And all this was nice up to now, because it enabled

To, efficiently and securely implement all of the pre-contem cryptography you might want to use, like… ACDSC or SNO on SECP256K1 or other curves, even pairing-based cryptography. DFLMAN-based secure channel protocols. So, this is the current situation, and now I will, give the stage to Alan to prevent the preliminary benchmarks we did with, post-quantum standards running on the ST33. Hello?

Alain Magazin: Yes, thank you, Annik. Hello, everyone. So… The goal of this project of preliminary benchmarking was, really to take the… the… The plain implementations of the three algorithms that we studied. not try and by ourselves implement anything, but really see what's out there and what can be done on our devices. The setup used is a bare metal secure element. Which is important, because that means there's no Ledger operating system running on it. And as someone mentioned in the chat, I just saw it, there is a reserved part of the RAM that is for the Ledger operating system when it's actually installed, and it's about 25 kilobytes of RAM that is already being consumed by the operating system. So in our case, we wanted to try and run,

Most algorithms… the most algorithms that we could, and therefore we did it on bare metal, but there is this additional constraint, that we have to take into account in a real-world application. So we start off with Falcon. We are, using here the C implementation, that has some optimization. That is an implementation from one of the authors of Falcon. The main thing here to see… is, the memory constraint for Falcon, right? So we have a high memory footprint. Already, we see that on the Falcon 512 version. The signing operation will barely fit in if we add the ledger operating system to the mix, so that means we are already touching on the possibilities of our current devices, and for the higher security version, it doesn't run even on bare metal.

The advantages, on the other hand, of Falcon are somewhat… Smaller object sizes, whether it's keys or signatures, and… we saw a speed that is actually not too bad from what we expected, because, as you may know, Falcon's main problem for embedded systems is the extensive use of floating-point operations. Which are not possible to implement, as is in FPUs, because they don't exist in our embedded systems. So, we see, nonetheless, decent execution time, especially for signing, and we'll get back to that when we compare with the other algorithms. The last thing I want to mention is that after talking to some of the authors in informal settings, we have the impression that, well, they didn't abandon the embedded, target, right? So they are working on implementations that will be

More adapted to constrained devices. So we are hopeful that it can improve in the future. We can move on to Dilithium. Alright. So here we used, the low RAM implementation, so here I want to, think and, shout out, ZKnox for their, implementation of Dilithium for low-RAM devices. based on the, I believe, the NXP paper that described some techniques to, lower memory footprint. For ML-DSA. So we used that implementation because the reference implementation did not run any signing operation, no matter the version of ML-DSA used. It couldn't run on our devices. So we used this one. The main hurdle outside of that for Dilithium is really the object sizes, which are bigger in every aspect, in keys and signature size. What we see for the new… this new low RAM implementation is that RAM now becomes a non-issue, it fits in comfortably.

Even for the higher security versions. But it has a trade-off, obviously, and the trade-off is, much longer operation times. specifically for the signing operation, which is crucial for devices like ours, because we don't want users to be on a screen that is blocked for 5 seconds, because a signing operation is being executed. So that's… starting to hit user experience badly at that point. it's starting to even become slower than Falcon, which we anticipated to be much slower because of the floating-point operation. So now, because we wanted to lower the memory footprint, we're seeing higher execution times, for an integer-only operation, which is, well… kind of unfortunate. But the fact that it is integer-only still has advantages that we are going to talk about later. I just want to briefly mention also security, physical security, concerns.

Dilithium has had already some research done for masking techniques that will prevent different types of hardware attacks, while for Falcon, again, because of the floating operations, we… presume it's going to be a bit more difficult, to develop effective countermeasures, so there's also that to point out. I think we can move on to, to the last one, to Sphinx or SLHDSA. So, here we are going to be very brief, because the results are quite clear. Obviously, what's great with things is, the object sizes. As we can see, they are very small for keys. However, the signature sizes on the other end are a real issue. Now, again, there are some ways to make it run on low RAM devices, and again, memory footprint is less of an issue on its own, but it does increase execution times a lot, and

even on the lower ends of the security levels, on the 128 versions, we see a signing time that is absolutely unacceptable for any user experience. I mean, 6 minutes to sign a transaction really isn't realistic, so… For now, for this use case, it is going to be very difficult for us to envision a future where SLA GSA is used as a signing operation on secure elements. So yeah, that… that would be it for the results. of our tests. Yeah, Nick, back to you.

Yannick Seurin: Thank you, Adam. So these were the benchmarks on the current CQ element we use, but, the, chip manufacturers are starting to, implement. post-quantum crystalography inside their chips, which will be good for us. And in particular, the next secure element generation that we plan to use for the future devices Have, First, they will have more memory, more flash, more RAM, 158 kilobytes, which is, Much more comfortable to implement, latency-based schemes in particular. Frequency will be higher, also. It will have some, IP for, for Ketchak. And, What's interesting for us is that it will have hardware acceleration for quantum cryptography, in particular for ML Chem.

and for ML GSA. 65. But… Right now, I don't think there is any plan to have Falcon or SLHGSA implemented in a hardware accelerator. So, if we want to summarize a bit the situation for each of the standards we have right now, so for MLDSA, we can say for sure that Will be available in the next generation. It's secure elements and devices. legacy, devices. We are pretty confident that we'll be able to have it run on these devices, with the caveat, which is… which applies to all other algorithms, which is that the benchmark that we have now implementations which are not protected against side-channel attacks. So, we'll need to, to…

implement, masking and control measures for these side channels, and it's, abuse that will, it will increase, Probably the memory footprint and the running time. So, as we've seen, the benchmarks are, encouraging for MLDSA, but, there's still this caveat that for, For a hardware signer, we need to have these control measures against such channel in place, and it's still a… Upon question, how much it will increase the memory footprint and the runtime. For Falcon, the situation is a bit different, because It will not be in hardware. accelerators of secure elements in Dysom, I think. So, as we've seen, the next generation of CQ elements is… we have much more,

room to implement Falcon into, have… side-channel content users, but as Alan said, it seems… more complicated to, to protect Falcon against side-channel attacks, so… It's… we are confident that we can have in the next generation of sequence, but it's not… it's not a given yet. And for legacy signers, it's… It's still an open question whether it will be able to run with high-channel quantum reserves in place. For… for SLHGSA. The situation is a bit different, I would say. Because as we've seen, the running times are currently unacceptable to… for generating a signature, so… So I guess, In… in legacy signals, it's, it's particularly, it will be very difficult to have, Hashbait signatures. At least stateless hash-based signatures in…

into these, into these devices. For the next generation, as there will be, like, a check accelerator, maybe we can have a check-based hash-based signature, maybe? But, we still… didn't, start to… To test this, In practice. So it's still really a question mark.

Matteo Vena: Who knows?

Yannick Seurin: Yeah, is that a question? No? Okay. And I've separated here the signature and the key generation, because there might be, Some benefits of implementing at least the key generation in legacy signals, so that people can Maybe generate a post-quantum address on their device and move their phones to this, Addresses from their old devices, and maybe next… Spence using a next-generation device, which is able to To generate signatures for these schemes. So, what's next? What are the next steps? So, for lattice-based schemes, as I said, for MLDSA and Falcon. The… the main, Work for now is to include countermeasures into, the implementations.

Polygasy signals? And for Falcon, also improved the state of the ODR for software implementation for the future, and possibly legacy signers. We have also started to work on the state-of-the-art of side-channel attacks against these algorithms. And work is currently ongoing in, our labs on… not on MLD GSA, it will be the next target, but for now we work on ML Chem, because it's the first algorithm that we will ship in our devices for our own internal use, for example, to, For… for establishing, Secure channel… secure channel is with our backend. And our devices. For SLHGSA, as we saw, the signature time is the bottleneck. One thing to say about hash-based signatures is that there are a lot of Freedom Degrees.

Like, the maximum number of signatures, whether you use a stateless, or a stateful, or some combination of the two. scheme. Which hash function you used? Do you, do you rely on, on Kitcheck, or on, possibly don't like your algebraic-friendly hash function. So all of this might change completely the, The figures, That you obtain, and so we plan to explore a bit of these degrees of freedom. And for the long term, we will keep an eye, obviously, on the NIST competition, which is still ongoing for additional signature schemes, with interesting alternatives, like multivariate schemes or MPC in the head schemes, which could give Signature schemes, which better, Performances that, the current standards. And ideally, maybe. isogenies could come to the risk queue, because these are the… the schemes which give the shortest signatures and the more efficient,

algorithms. So, maybe in a… in a couple of years, we'll have, an algorithm based on hogenes, which will fulfill all of our needs. We'll see. Thanks for listening, and if you have questions, we are happy to answer with Allow.

Antonio Sanso: Thanks a lot, Yannick and Alan. This was really, really, really useful context from the hardware perspective. I will have a couple questions. One is about, the hashing, so, signatures, and yeah, the times are horrible, you're right. But these are for 2 to 64… Signatures, so it's stat less, but, 2 to 64 signatures.

Yannick Seurin: Yeah, yeah, it's a standard, yeah, so it's…

Antonio Sanso: Yes, yes, it's alley.

Yannick Seurin: 065.

Antonio Sanso: Also, even the standards considering having a lighter version of it, let's say Sphinx Minus. That is gonna be 2 to the 32. So, just, I'm having some hope there that maybe… this kind of lighter signatures. I mean, for our use case, 32 signatures might be actually being not too bad.

Yannick Seurin: Yeah.

Antonio Sanso: I wonder…

Yannick Seurin: Unfortunately, the thing is that when you… so… people from Blockstream, like, I think they presented their work, Right. Some time ago, here. So, what is to notice is that if you play on this parameter, the maximum number of signatures, you reduce the signature size, which is nice for the, For the footprint on the blockchain. But you actually don't reduce that much the time to sign. The number of hash operations you need to do, it's globally the same, or it's even a bit more, actually, if you… If you play on this parameter. So you… you reduce the, the signature size, but unfortunately for… For the running time of the signing algorithm, it's not very beneficial. So I'm not sure it's a good deal.

It's a good bit of things off.

Antonio Sanso: This, this, these matches as well, the… The result of seeing the paper, yes. And the second question is…

Alain Magazin: Yeah, if I may add something, I will send in the chat a link to a paper that we used in the study that explores various parameter sets for Sphinx, and And if you look, none of them actually reduced the number of hashes. So the conclusion that we had was. for every parameter set that meaningfully reduces signature size, it actually only goes up in terms of execution speeds, and sometimes it goes up a lot. So yeah, just wanted to add this paper, it's an interesting study.

Antonio Sanso: Indeed, indeed. Thanks a lot, Alan. And, we'll have a second question, and then I'll go to the chat to check if there are. Second question is, if by any chance you have seen the discussion that happened in the last weeks about the… Ephemeral style of signing. And in that case, we may open the door apart, like, of course, the obvious case of elliptic curve that, I mean, in my opinion, will not have a lot of filters, because it's, like, not really pass quantum. But maybe it opens the door to Winter's needs of force, so a few times signatures. I wonder if you guys explored, or you have any intention to explore such a paradigma?

Yannick Seurin: So we… we haven't explored it yet, but yeah, it's, it's, to-do list to… Look at Either, stateful. hash-based signatures, like XMSS or LMS, and see, if the running time improves. Because, for example, if you look at… so the Bitcoin community is also looking at a lot of… at Hashbase Signatures, and there are proposals, for example, to combine stateful hash-based signatures with a fallback in case you lose your state on stateless hash-based signatures. So. You kind of get the boss of both worlds, you, you sign… With the stateful scheme, as long as you trust that you still have your… the correct state, and… In case you… You need to restore your, You're sitting on a new device or something, where you lose your state, then you fall back to the stateless scheme.

Which could be, maybe, a solution, I don't know. But yeah, we plan to explore the few-time signature schemes as well.

Antonio Sanso: Right? I mean, from my perspective, probably, I see the ephemeral case being… again, at the moment, I'm bullish on that, because it looks the perfect use case for the execution layer. Because maintaining the state is kind of, you know, it's not an easy task, so it will be nice to… to play with both. I agree that the Blogstream… papers or the experiment they are doing are interesting, and just adding the female use case into the game maybe would be nice to have some results. And again, it's on my desk as well. I don't want to put any work on your desk, of course, so let me just, like, It would be nice as a community if we can experiment a bit. Thanks a lot, and

I see one, question in the chat from Stefano. It is asking if you have any specific MPs in the head. I can ask. Oh, you can ask Stefan directly, yes.

Stefano Gogioso: I mean, I'm just literally sitting next. Antonio, yeah, just, I have one… I hope you can hear me, because I am on my headphones. Yeah, all right, sorry. Yeah, so MPC Internet specifically, because we're using it to do some early days zero-knowledge proofs for proof of seed, for our Proof of Seed project. So support for MPC in the head techniques would be… more than just signature schemes. It would have other uses, because there's zero-knowledge proof systems based on that. So it'd be quite good to, like, maybe keep in touch or have a conversation about what can be done there, because the constraints on the hardware are quite tight for anything CK.

Yannick Seurin: Yep, sure. So, probably it would have the same kind of… problems as SLHDSA, because MPC, in the head relies on a lot of symmetric, primitives operation, like ES, or… But we haven't started to look into this yet.

Stefano Gogioso: Yeah, I'm more thinking of the basic, sort of the underlying primitives, not necessarily its use for a specific signature scheme. So, like, you can implement, of course, MPC in the head directly, like, in Rust or in C, and you can implement the underlying operations, but having lower-level support would probably be… it would make things significantly faster, more performant. But anyway, this is perhaps a bit of a deep technical conversation. I had a brief question, if you don't mind, since you are here, and you mentioned the restrictions on the current generation of MCUs. nominally, the, the SCD33, the one for the Flex. has 64 kilobytes of ROM. But, at least that's the spec. But in practice, when we tried doing allocation, sort of, in app space, and we tried to do heap allocs, we noticed that they were severely limited. Like, you can't use anywhere close to the

to the full RAM, and you can't use anywhere close to the available stack space. I was wondering whether there's, like, a specific design rationale for that. Like, we saw something close to, like, 7 kilobytes. Which is 7, 8 kilobytes available for super cat logs. So, for vectors, for example.

Yannick Seurin: So I… yeah, first, I suspect LedgerOS is… Using… quite a… quite a few… kilobytes of the RAM, but why are you restrict it to 7 kilobytes, you say?

Stefano Gogioso: Yeah, so we tried allocating… we tried experiments with, sort of, deep stack allocations to see how much of the RAM we could fill with that, and it was around 30-something kilobytes, which I expect… which is reasonable, because, of course, you have, you have the OS running on probably the remaining space. But we… we noticed that the heap, the maximum heap allocation we could get, at least continuously, was around 7.5. It was slightly short of 8, perhaps. Maybe it's a fragmentation issue.

Yannick Seurin: Yeah, I don't have the answer, but I can ask internally later on.

Stefano Gogioso: Alright, yeah, and maybe, maybe something we could have a separate technical conversation about, if you don't.

Yannick Seurin: Yeah, sure.

Stefano Gogioso: Alright, I appreciate that, thank you.

Antonio Sanso: Alright, guys. I think that for today, I give you back 5 minutes of your life. It was a really nice conversation. Thanks a lot, the speakers. The presentations were really useful, and I guess I'll see you in two weeks, and do take care.

Yannick Seurin: Thank you, goodbye.

Conor Deegan: Thank you.

Alain Magazin: Goodbye.

Matteo Vicari: Bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.