Antonio Sanso:Alright, let's start,
Transcript
Antonio Sanso:Today's a kind of special event. We're running live from Cannes. We have, as well, a different time zone, so…
Antonio Sanso:More than time zone, change the time, so the call is 1 hour before then used to be.
Antonio Sanso:In any case, this is the…
Antonio Sanso:Fifth occurrence of the post-quantum transaction signature breakout room.
Antonio Sanso:Today, is about hardware support.
Antonio Sanso:And, we will have the presentation.
Antonio Sanso:the first one from Connor Diggin from Project 11, and it will show
Antonio Sanso:Some of the papers that, was presented a few weeks ago.
Antonio Sanso:About… key derivation… Bip32 for Lattice.
Antonio Sanso:And, then we'll have Yannick from, Trezor, sorry, from Ledger, talking about post-quantum signatures and hardware signals.
Antonio Sanso:Before to give the stage to Connor.
Antonio Sanso:I just want to shout out, Julio.
Antonio Sanso:From, Erigon.
Antonio Sanso:He put some, Testnet plus wallet at this, freshly… both address Daizugi.
Antonio Sanso:And contains some of the things we have been speaking.
Antonio Sanso:In the previous calls.
Antonio Sanso:And, so, as you can see from the screenshot, there is a…
Antonio Sanso:some of the algorithms we discussed, like Falcon or Dilithium, and the more recent ephemeral ECDSA for now.
Antonio Sanso:Probably he is working as well on some ephemeral…
Antonio Sanso:Hash-based signatures, let's see how it goes.
Antonio Sanso:And, with this, I will give the stage directly to Connor.
Antonio Sanso:You have about 10 minutes.
Conor Deegan:Great. Thanks, Antonio. I will just share my screen.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan:This is gonna be a Lattice proposal, which obviously, you know.
Conor Deegan: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.
Conor Deegan: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
Conor Deegan:Three of key pairs from a single master seed. And one key feature of this is
Conor Deegan:Non-hardened derivation, or…
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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,
Conor Deegan: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.
Conor Deegan:So…
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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,
Conor Deegan: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
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan:Which, I'll explain why that's helpful in 2 seconds.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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
Conor Deegan: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…
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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
Conor Deegan:parent public keys. And we basically have a proof,
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan: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
Conor Deegan: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.
Conor Deegan: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…
Conor Deegan: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
Conor Deegan: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.
Conor Deegan:What? Do…
Conor Deegan: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.
Conor Deegan:This is kind of, I guess, the more interesting point. This is my…
Conor Deegan: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
Conor Deegan:ecosystem parity from previous, you know, from the pre-quantum world, and…
Conor Deegan: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.
Conor Deegan: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.
Conor Deegan:So that's kind of the bigger point of why this work exists.
Conor Deegan: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.
Conor Deegan:Tell us, you know, where we could make it better, or fork it off and do something cooler.
Conor Deegan: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
Antonio Sanso: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,
Conor Deegan: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.
Conor Deegan:So if we can remove even some of the constraints of how deep it needs to go.
Conor Deegan: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
Conor Deegan: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.
Antonio Sanso:How… and I already answered it before, but what is the chance you can replicate this for… Hashbase signal.
Conor Deegan:Yeah, right? Yeah.
Conor Deegan:It's… I think it's zero. I, I, I spent, a long time staring at a wall, trying to think about this.
Conor Deegan: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
Conor Deegan: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
Conor Deegan: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.
Conor Deegan:And then only sending the public key
Conor Deegan: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
Matteo Vicari:For, one-time signature, using, this key, the key is more light, and it can generate more faster.
Matteo Vicari:And, in… in this… using one-time seniors can help, the hardware device to generate more keywords, and then try to have…
Matteo Vicari: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.
Conor Deegan: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…
Matteo Vicari: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,
Matteo Vicari:And, use the, like, the seed of the B44 and all the key, and then, derivate the one-time signal from the,
Matteo Vicari:Ayy.
Matteo Vicari:B44, key parts.
Matteo Vicari: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 (Ledger):No.
Antonio Sanso:And.
Yannick Seurin (Ledger):Unfortunately, everything in Paris.
Antonio Sanso:Okay.
Yannick Seurin (Ledger):Can you hear me well?
Antonio Sanso:Yeah, yes, yes, stage is yours. Thanks a lot for accepting the invite, and Nick.
Yannick Seurin (Ledger):Yeah, sure. Thanks to you, Antonio. Let me share my screen.
Yannick Seurin (Ledger):Can you see the slides? Can you see the slides well?
Antonio Sanso:I mean, yes, now, now yes, perfectly.
Yannick Seurin (Ledger):Okay.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):Post-quantum, signatures on hardware sinus.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):hold securely your secret keys and allow you to sign transactions. And it was causing a bit of confusion, because
Yannick Seurin (Ledger):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.
Yannick Seurin (Ledger):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.
Yannick Seurin (Ledger):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.
Yannick Seurin (Ledger):Every blockchain is relying on elliptic cryptography.
Yannick Seurin (Ledger):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 (Ledger):No, you see what…
Antonio Sanso:But I know… I know they said you were on the wrong slide, thank you.
Yannick Seurin (Ledger):Okay, now you see the good slide, nice.
Yannick Seurin (Ledger):So, this allowed a large blockchain support in hardware.
Yannick Seurin (Ledger):in the hall to assign us.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):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.
Yannick Seurin (Ledger):None of these standards is really hardware friendly.
Yannick Seurin (Ledger):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.
Yannick Seurin (Ledger):So… Let me… prudent,
Yannick Seurin (Ledger):The architecture of our hardware signals.
Yannick Seurin (Ledger):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.
Yannick Seurin (Ledger):between vendors, I think.
Yannick Seurin (Ledger):So, our signers rely on two chips.
Yannick Seurin (Ledger):the MCU, which is, STM32.
Yannick Seurin (Ledger):And… and a secure limit.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):really, the MCU, we'll only do, dumb things.
Yannick Seurin (Ledger):Namely, it will only be used as a kind of footer between the secure element and the peripherals, like USB, Bluetooth, and so on.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):are stored in the secure element, and never leave the secure element when used to sign transactions.
Yannick Seurin (Ledger):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.
Yannick Seurin (Ledger):There is a mechanism of application isolation based on,
Yannick Seurin (Ledger):ARM memory protection unit, and in particular, each application is restricted to its own memory region in the SE memory.
Yannick Seurin (Ledger):Also, the device is restricted to a single task model, where only one application can run at a time.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):signatures.
Yannick Seurin (Ledger):So, no, let me… show you how, constrained these CQ elements are. So…
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):Had a very low, amount of RAM, 10 kilobytes.
Yannick Seurin (Ledger):The next generation was a bit better, and the current generation of devices, which rely on the ST33,
Yannick Seurin (Ledger):have 1.5 megabytes of non-volatile memory, 64 kilobytes of RAM with 2KB of cache, and have a frequency of 70 MHz.
Yannick Seurin (Ledger):So, as we can see, the amount of RAM is pretty scarce.
Yannick Seurin (Ledger):And given that post-conterm signature schemes tend to have a rather large RAM footprint, this will be,
Yannick Seurin (Ledger):a problem, as we will see. And also, the clock frequency is not that high, and for schemes like
Yannick Seurin (Ledger):SLH GSA, which require, a lot of hash computations, for example. The time to compute a signature
Yannick Seurin (Ledger):Will be very large, as we will see.
Yannick Seurin (Ledger):So as I said, the, ST33 provides
Yannick Seurin (Ledger):a number of things, like hardware acceleration for AES, and,
Yannick Seurin (Ledger):A coprocessor for elliptic curve operations. And all this was nice up to now, because it enabled
Yannick Seurin (Ledger):To, efficiently and securely implement all of the pre-contem cryptography you might want to use, like…
Yannick Seurin (Ledger):ACDSC or SNO on SECP256K1 or other curves, even pairing-based cryptography.
Yannick Seurin (Ledger):DFLMAN-based secure channel protocols.
Yannick Seurin (Ledger):So, this is the current situation, and now I will,
Yannick Seurin (Ledger):give the stage to Alan to prevent the preliminary benchmarks we did with,
Yannick Seurin (Ledger):post-quantum standards running on the ST33.
Yannick Seurin (Ledger):Hello?
Alain MAGAZIN (LEDGER):Yes, thank you, Annik. Hello, everyone. So…
Alain MAGAZIN (LEDGER):The goal of this project of preliminary benchmarking was, really to take the… the…
Alain MAGAZIN (LEDGER):The plain implementations of the three algorithms that we studied.
Alain MAGAZIN (LEDGER):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.
Alain MAGAZIN (LEDGER):Which is important, because that means there's no Ledger operating system running on it.
Alain MAGAZIN (LEDGER):And as someone mentioned in the chat, I just saw it, there is a reserved part of the RAM
Alain MAGAZIN (LEDGER):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,
Alain MAGAZIN (LEDGER):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.
Alain MAGAZIN (LEDGER):So we start off with Falcon.
Alain MAGAZIN (LEDGER):We are, using here the C implementation, that has some optimization. That is an implementation from one of the authors of Falcon.
Alain MAGAZIN (LEDGER):The main thing here to see… is,
Alain MAGAZIN (LEDGER):the memory constraint for Falcon, right? So we have a high memory footprint.
Alain MAGAZIN (LEDGER):Already, we see that on the Falcon 512 version.
Alain MAGAZIN (LEDGER):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.
Alain MAGAZIN (LEDGER):The advantages, on the other hand, of Falcon are somewhat…
Alain MAGAZIN (LEDGER):Smaller object sizes, whether it's keys or signatures, and…
Alain MAGAZIN (LEDGER):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.
Alain MAGAZIN (LEDGER):Which are not possible to implement, as is in FPUs, because they don't exist in our embedded systems.
Alain MAGAZIN (LEDGER):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
Alain MAGAZIN (LEDGER):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
Alain MAGAZIN (LEDGER):More adapted to constrained devices. So we are hopeful that it can improve in the future.
Alain MAGAZIN (LEDGER):We can move on to Dilithium.
Alain MAGAZIN (LEDGER):Alright.
Alain MAGAZIN (LEDGER):So here we used, the low RAM implementation, so here I want to, think and,
Alain MAGAZIN (LEDGER):shout out, ZKnox for their, implementation of Dilithium for low-RAM devices.
Alain MAGAZIN (LEDGER):based on the, I believe, the NXP paper that described some techniques to, lower memory footprint.
Alain MAGAZIN (LEDGER):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.
Alain MAGAZIN (LEDGER):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.
Alain MAGAZIN (LEDGER):Even for the higher security versions.
Alain MAGAZIN (LEDGER):But it has a trade-off, obviously, and the trade-off is, much longer operation times.
Alain MAGAZIN (LEDGER):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…
Alain MAGAZIN (LEDGER):starting to hit user experience badly at that point.
Alain MAGAZIN (LEDGER):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…
Alain MAGAZIN (LEDGER):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.
Alain MAGAZIN (LEDGER):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…
Alain MAGAZIN (LEDGER):presume it's going to be a bit more difficult, to develop effective countermeasures, so there's also that to point out.
Alain MAGAZIN (LEDGER):I think we can move on to,
Alain MAGAZIN (LEDGER):to the last one, to Sphinx or SLHDSA.
Alain MAGAZIN (LEDGER):So, here we are going to be very brief, because the results are quite clear.
Alain MAGAZIN (LEDGER):Obviously, what's great with things is, the object sizes. As we can see, they are very small for keys.
Alain MAGAZIN (LEDGER):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
Alain MAGAZIN (LEDGER):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…
Alain MAGAZIN (LEDGER):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.
Alain MAGAZIN (LEDGER):So yeah, that… that would be it for the results.
Alain MAGAZIN (LEDGER):of our tests.
Alain MAGAZIN (LEDGER):Yeah, Nick, back to you.
Yannick Seurin (Ledger):Thank you, Adam.
Yannick Seurin (Ledger):So these were the benchmarks on the current CQ element we use, but, the, chip manufacturers are starting to,
Yannick Seurin (Ledger):implement.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):Have, First, they will have more memory, more flash, more RAM, 158 kilobytes, which is,
Yannick Seurin (Ledger):Much more comfortable to implement, latency-based schemes in particular.
Yannick Seurin (Ledger):Frequency will be higher, also. It will have some, IP for, for Ketchak. And,
Yannick Seurin (Ledger):What's interesting for us is that it will have hardware acceleration for quantum cryptography, in particular for ML Chem.
Yannick Seurin (Ledger):and for ML GSA.
Yannick Seurin (Ledger):65.
Yannick Seurin (Ledger):But…
Yannick Seurin (Ledger):Right now, I don't think there is any plan to have Falcon or SLHGSA implemented in a hardware accelerator.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):Will be available in the next generation.
Yannick Seurin (Ledger):It's secure elements and devices.
Yannick Seurin (Ledger):legacy, devices.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):implementations which are not protected against side-channel attacks. So, we'll need to, to…
Yannick Seurin (Ledger):implement, masking and control measures for these side channels, and it's, abuse that will, it will increase,
Yannick Seurin (Ledger):Probably the memory footprint and the running time.
Yannick Seurin (Ledger):So, as we've seen,
Yannick Seurin (Ledger):the benchmarks are, encouraging for MLDSA, but, there's still this caveat that for,
Yannick Seurin (Ledger):For a hardware signer, we need to have these control measures against such channel in place, and it's still a…
Yannick Seurin (Ledger):Upon question, how much it will increase the memory footprint and the runtime.
Yannick Seurin (Ledger):For Falcon, the situation is a bit different, because
Yannick Seurin (Ledger):It will not be in hardware.
Yannick Seurin (Ledger):accelerators of secure elements in Dysom, I think.
Yannick Seurin (Ledger):So, as we've seen, the next generation of CQ elements is… we have much more,
Yannick Seurin (Ledger):room to implement Falcon into, have…
Yannick Seurin (Ledger):side-channel content users, but as Alan said, it seems…
Yannick Seurin (Ledger):more complicated to, to protect Falcon against side-channel attacks, so…
Yannick Seurin (Ledger):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.
Yannick Seurin (Ledger):And for legacy signers, it's…
Yannick Seurin (Ledger):It's still an open question whether it will be able to run with high-channel quantum reserves in place.
Yannick Seurin (Ledger):For… for SLHGSA.
Yannick Seurin (Ledger):The situation is a bit different, I would say.
Yannick Seurin (Ledger):Because as we've seen, the running times are currently unacceptable to… for generating a signature, so…
Yannick Seurin (Ledger):So I guess,
Yannick Seurin (Ledger):In… in legacy signals, it's, it's particularly, it will be very difficult to have, Hashbait signatures.
Yannick Seurin (Ledger):At least stateless hash-based signatures in…
Yannick Seurin (Ledger):into these, into these devices. For the next generation, as there will be,
Yannick Seurin (Ledger):like, a check accelerator, maybe we can have a check-based hash-based signature, maybe?
Yannick Seurin (Ledger):But, we still… didn't, start to… To test this,
Yannick Seurin (Ledger):In practice. So it's still really a question mark.
Matteo Vena:Who knows?
Yannick Seurin (Ledger):Yeah, is that a question?
Yannick Seurin (Ledger):No? Okay.
Yannick Seurin (Ledger):And I've separated here the signature and the key generation, because there might be,
Yannick Seurin (Ledger):Some benefits of implementing at least the key generation in legacy signals, so that people can
Yannick Seurin (Ledger):Maybe generate a post-quantum address on their device and move their phones to this,
Yannick Seurin (Ledger):Addresses from their old devices, and maybe next…
Yannick Seurin (Ledger):Spence using a next-generation device, which is able to
Yannick Seurin (Ledger):To generate signatures for these schemes.
Yannick Seurin (Ledger):So, what's next? What are the next steps? So, for lattice-based schemes, as I said, for MLDSA and Falcon.
Yannick Seurin (Ledger):The… the main, Work for now is to include countermeasures into, the implementations.
Yannick Seurin (Ledger):Polygasy signals?
Yannick Seurin (Ledger):And for Falcon, also improved the state of the ODR for software implementation for the future, and possibly legacy signers.
Yannick Seurin (Ledger):We have also started to work on the state-of-the-art of side-channel attacks against these algorithms.
Yannick Seurin (Ledger):And work is currently ongoing in,
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):ship in our devices for our own internal use, for example, to, For… for establishing,
Yannick Seurin (Ledger):Secure channel… secure channel is with our backend.
Yannick Seurin (Ledger):And our devices.
Yannick Seurin (Ledger):For SLHGSA, as we saw, the signature time is the bottleneck.
Yannick Seurin (Ledger):One thing to say about hash-based signatures is that there are a lot of Freedom Degrees.
Yannick Seurin (Ledger):Like, the maximum number of signatures, whether you use a stateless, or a stateful, or some combination of the two.
Yannick Seurin (Ledger):scheme.
Yannick Seurin (Ledger):Which hash function you used? Do you, do you rely on, on Kitcheck, or on,
Yannick Seurin (Ledger):possibly don't like your algebraic-friendly hash function. So all of this might change completely the,
Yannick Seurin (Ledger):The figures,
Yannick Seurin (Ledger):That you obtain, and so we plan to explore a bit of these degrees of freedom.
Yannick Seurin (Ledger):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
Yannick Seurin (Ledger):Signature schemes, which better,
Yannick Seurin (Ledger):Performances that, the current standards.
Yannick Seurin (Ledger):And ideally, maybe.
Yannick Seurin (Ledger):isogenies could come to the risk queue, because these are the… the schemes which give the shortest signatures and the more efficient,
Yannick Seurin (Ledger):algorithms.
Yannick Seurin (Ledger):So, maybe in a… in a couple of years, we'll have,
Yannick Seurin (Ledger):an algorithm based on hogenes, which will fulfill all of our needs. We'll see.
Yannick Seurin (Ledger):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.
Antonio Sanso:One is about, the hashing, so, signatures, and yeah, the times are horrible, you're right. But these are for 2 to 64…
Antonio Sanso:Signatures, so it's stat less, but, 2 to 64 signatures.
Yannick Seurin (Ledger):Yeah, yeah, it's a standard, yeah, so it's…
Antonio Sanso:Yes, yes, it's alley.
Yannick Seurin (Ledger):065.
Antonio Sanso:Also, even the standards considering having a lighter version of it, let's say Sphinx Minus.
Antonio Sanso:That is gonna be 2 to the 32.
Antonio Sanso:So, just, I'm having some hope there that maybe…
Antonio Sanso:this kind of lighter signatures. I mean, for our use case, 32 signatures might be actually being not too bad.
Yannick Seurin (Ledger):Yeah.
Antonio Sanso:I wonder…
Yannick Seurin (Ledger):Unfortunately, the thing is that when you… so…
Yannick Seurin (Ledger):people from Blockstream, like, I think they presented their work,
Yannick Seurin (Ledger):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,
Yannick Seurin (Ledger):For the footprint on the blockchain.
Yannick Seurin (Ledger):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…
Yannick Seurin (Ledger):If you play on this parameter. So you… you reduce the, the signature size, but unfortunately for…
Yannick Seurin (Ledger):For the running time of the signing algorithm, it's not very beneficial.
Yannick Seurin (Ledger):So I'm not sure it's a good deal.
Yannick Seurin (Ledger):It's a good bit of things off.
Antonio Sanso:This, this, these matches as well, the…
Antonio Sanso:The result of seeing the paper, yes. And the second question is…
Alain MAGAZIN (LEDGER):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
Alain MAGAZIN (LEDGER):And if you look, none of them actually reduced the number of hashes. So the conclusion that we had was.
Alain MAGAZIN (LEDGER):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.
Antonio Sanso: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…
Antonio Sanso:Ephemeral style of signing.
Antonio Sanso: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.
Antonio Sanso:I wonder if you guys explored, or you have any intention to explore such a paradigma?
Yannick Seurin (Ledger):So we… we haven't explored it yet, but yeah, it's, it's, to-do list to… Look at
Yannick Seurin (Ledger):Either, stateful.
Yannick Seurin (Ledger):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…
Yannick Seurin (Ledger):at Hashbase Signatures, and there are proposals, for example, to combine
Yannick Seurin (Ledger):stateful hash-based signatures with a fallback in case you lose your state on stateless hash-based signatures. So.
Yannick Seurin (Ledger):You kind of get the boss of both worlds, you, you sign…
Yannick Seurin (Ledger):With the stateful scheme, as long as you trust that you still have your… the correct state, and…
Yannick Seurin (Ledger):In case you… You need to restore your,
Yannick Seurin (Ledger):You're sitting on a new device or something, where you lose your state, then you fall back to the stateless scheme.
Yannick Seurin (Ledger):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.
Antonio Sanso:Because maintaining the state is kind of, you know, it's not an easy task, so it will be nice to…
Antonio Sanso:to play with both. I agree that the Blogstream…
Antonio Sanso: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,
Antonio Sanso:It would be nice as a community if we can experiment a bit. Thanks a lot, and
Antonio Sanso:I see one, question in the chat from Stefano.
Antonio Sanso:It is asking if you have any specific MPs in the head.
Antonio Sanso:I can ask. Oh, you can ask Stefan directly, yes.
Stefano Gogioso:I mean, I'm just literally sitting next.
Stefano Gogioso:Antonio, yeah, just, I have one…
Stefano Gogioso: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.
Stefano Gogioso:So support for MPC in the head techniques would be…
Stefano Gogioso: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
Stefano Gogioso: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 (Ledger):Yep, sure.
Yannick Seurin (Ledger):So, probably it would have the same kind of…
Yannick Seurin (Ledger):problems as SLHDSA, because MPC, in the head relies on a lot of
Yannick Seurin (Ledger):symmetric, primitives operation, like ES, or…
Yannick Seurin (Ledger):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.
Stefano Gogioso: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.
Stefano Gogioso:But anyway, this is perhaps a bit of a deep technical conversation.
Stefano Gogioso: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.
Stefano Gogioso:nominally, the, the SCD33, the one for the Flex.
Stefano Gogioso:has 64 kilobytes of ROM.
Stefano Gogioso:But, at least that's the spec.
Stefano Gogioso: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
Stefano Gogioso:to the full RAM, and you can't use anywhere close to the available stack space.
Stefano Gogioso:I was wondering whether there's, like, a specific design rationale for that. Like, we saw something close to, like, 7 kilobytes.
Stefano Gogioso:Which is 7, 8 kilobytes available for super cat logs.
Stefano Gogioso:So, for vectors, for example.
Yannick Seurin (Ledger):So I… yeah, first, I suspect LedgerOS is… Using… quite a… quite a few…
Yannick Seurin (Ledger):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.
Stefano Gogioso: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.
Stefano Gogioso:Maybe it's a fragmentation issue.
Yannick Seurin (Ledger):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 (Ledger):Yeah, sure.
Stefano Gogioso:Alright, I appreciate that, thank you.
Antonio Sanso:Alright, guys.
Antonio Sanso: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.
Antonio Sanso:The presentations were really useful, and I guess I'll see you in two weeks, and do take care.
Yannick Seurin (Ledger):Thank you, goodbye.
Conor Deegan:Thank you.
Alain MAGAZIN (LEDGER):Goodbye.
Matteo Vicari:Bye.
Chat Logs
00:21:21
Stefano Gogioso:It's a kind-of commutativity issue, isn't it in the end
00:23:57
Matteo Vena:Can you drop your tg Connor?
00:24:04
Matteo Vena:Conor*
00:32:00
Stefano Gogioso:Additionally, a smaller portion of the overall 64KB of RAM is available for heap allocations in apps (at least in our experiments).
00:32:40
alan xu:Where’s the tg group for PQTS?
00:33:45
Antonio Sanso:https://t.me/+ozVdiAeQleBhZDg0
00:42:45
Conor Deegan:Given the tradeoffs mentioned how do we as a group work together such that signers, verifiers, clients, etc work together to find a middle ground that will work across layers of the stack? “Pick your poison”
00:43:12
Antonio Sanso:Replying to "Given the tradeoffs ..."
Good question…
00:43:43
Conor Deegan:Replying to "Given the tradeoffs ..."
What is good on one side is bad for the other it feels
00:44:19
alan xu:Will Etheream choose lattice based or hash based PQ scheme?
00:45:01
Thomas Coratger:Répondre à "Will Etheream choo..."
Still an open question I think but hash based assumptions are always more conservative
00:48:16
Stefano Gogioso:We are specifically interested in MPC-in-the-Head support, would be good to have a touch point on that.
00:49:54
Alain MAGAZIN (LEDGER):https://eprint.iacr.org/2025/2203.pdf