Antonio Sanso:Alright, let's do it.
Transcript
Antonio Sanso:So, welcome, post-quantum transaction signature number… 7?
Antonio Sanso:SSZ, a quick recap.
Antonio Sanso:Of the previous calls.
Antonio Sanso:We… last things we did was… Julio presenting testnet 0.
Antonio Sanso:And today's topic, instead, is… A few more solutions that are purely post-quantum.
Antonio Sanso:Just to give a quick recap of this question, if you remember.
Antonio Sanso:post-quantum Transaction Signal 4. We got Riva Labs presenting, their, Ephemeral key solution.
Antonio Sanso:It was based… on elliptic groove, so…
Antonio Sanso:the idea is simple but brilliant. You have, A stable address?
Antonio Sanso:That you never reveal the public key, and…
Antonio Sanso:Every time you are doing a transaction, you use ephemeral elliptical points, so an address, a freshly addressed every single time.
Antonio Sanso:And It's beautiful, it's nice, it's quick.
Antonio Sanso:It has one little issue, though, that is not fully past quantum.
Antonio Sanso:But we, as a community immediately recognize that we can actually transfer the same
Antonio Sanso:the same infrastructure for hash-based solution, using a combination of long-term keys, like Sphinx, for example, and, short-term…
Antonio Sanso:keys like Windows Nit or, FORS.
Antonio Sanso:And today, we actually will have both incarnations.
Antonio Sanso:This is the agenda. We'll have, Riva Labs presenting.
Antonio Sanso:the solution that use winter nets, and…
Antonio Sanso:And we'll have Nico presenting the solution that used force instead.
Antonio Sanso:And we'll have, eventually, the last presentation from Maddie.
Antonio Sanso:That will present a bit… something a bit more fancy.
Antonio Sanso:So, just quick housekeeping.
Antonio Sanso:Riva and Nico, you guys have 15 minutes, and Maddie, you have 10 minutes. I need to be pretty strict with the time, so when you're approaching 15 minutes, I need to tell you, otherwise we are gonna be extra tired.
Antonio Sanso:And without further ado, I give you the control to anyone from Riva Labs. Stop sharing here.
Alessandro Baiocchi:Yeah, I'll share, if it's okay.
Alessandro Baiocchi:It should be… Okay.
Alessandro Baiocchi:Okay, good. You may… you should be able to see my screen.
Alessandro Baiocchi:Right?
Antonio Sanso:Yeah, yeah, I'm good.
Alessandro Baiocchi:Okay, good. So, hi everyone. Thanks, Antonio, for the introduction. And, okay, as you, as you may recall, we presented the… this idea for, the idea behind Nestri, which is female keys, and this presentation is where we are today, so,
Alessandro Baiocchi:Is that… okay.
Alessandro Baiocchi:Mmm…
Alessandro Baiocchi:The… to recap a bit, the… the main idea, as Antony was saying, we… we have… we leverage a construction to basically decouple the user identity on-chain, which is stable and is kept by the smart contract wallet, and the signer identity, which is rotated at every reconstruction.
Alessandro Baiocchi:This rotation makes me so that given ACDSC keys, I'll save, the…
Alessandro Baiocchi:Besides this short exposure, because the next signer is a fresh address, which has… which public key has not been exposed.
Alessandro Baiocchi:Since then, we've built on that idea, we've wrote a comprehensive spec, and we consolidated our implementation of the ACDSA wallet.
Alessandro Baiocchi:We also went on to study more signal schemes, and we decided to go with a watts mode. We added a watts mode, which is based on WinterMith's one-time signatures.
Alessandro Baiocchi:And… which is a hash-based scheme, so it's a post-control resistance by design… post-control resistance by design, yeah.
Alessandro Baiocchi:And both, standard schemes have a very similar architecture, and we'll see now in detail. Stacks from CVSA mode. We…
Alessandro Baiocchi:Inside, nice try, we have the… this… this is the mode based on the original idea.
Alessandro Baiocchi:And this is safe until, there is a very fast, let's say, quantum-relevant, cryptographically relevant quantum computer, and… and this is,
Alessandro Baiocchi:This is because we know of a vulnerability, which is the public key being exposed while the transaction is in the manpool.
Alessandro Baiocchi:And to… an attacker could possibly break a CDSA while the transaction is still not executed and frontrun the user.
Alessandro Baiocchi:Basically attacking it, attacking the user and stealing, funds.
Alessandro Baiocchi:the… The idea here is that, the solution, like, is safe.
Alessandro Baiocchi:And it, like, it imposes a strict constraint on the attack window.
Alessandro Baiocchi:And is, is meant to be a bridge solution, that can be implemented now with the… the… without…
Alessandro Baiocchi:basically any gas, overhead, over a counterstruction, and has, little to no changes to, to the, like, has no changes into the Ethereum architecture, the Ethereum ecosystem.
Alessandro Baiocchi:And… Okay, yeah.
Alessandro Baiocchi:So, this is… was our starting idea, then to, like, overcome the… the…
Alessandro Baiocchi:the issue we had with, exposure in the manpool, because the CDSA is not, by design, post-quantum, we went with, unstudied post-quantum signals, so quant… the hash-based, we went with, as I was saying, with, one… one-time signals.
Alessandro Baiocchi:And here, basically, the idea is we, instead of ECDSA, we use Watts, which, being hash-based, they are quantum-safe by design, and they don't require additional assumptions, such as trust implement pool.
Alessandro Baiocchi:And in our design, the fact that the signals are one-time is basically offset by the fact that we already are using each signal group one time. So, the fact that we have a female keys match goes very well with one-time signal groups.
Alessandro Baiocchi:And the, the reason we chose Watts is because they present
Alessandro Baiocchi:very low signature size, we have, for example, an implementation with 460 bytes signature, and very low verification cost, too. And, for example, now a full validated user setup is, with that signal drug size, is 93K gas.
Alessandro Baiocchi:But the… these two parameters can be… can be moved around, because there is a trade-off, of course, between signal size and verification gas, and the trade-off is basically an engineering decision, depending on the need of the user or in this customer.
Alessandro Baiocchi:Using one-time signals, this has some downsides, of course. For example, if a transaction is broadcast but not executed, like, we add it to the mempool, but, for example, the user has put a wrong nonce.
Alessandro Baiocchi:the transaction cannot be executed, so the signer on chain cannot be rotated, because the signer is still kept in the smart contract wallet as a commitment of the public key, basically in the same way a CDSA addresses… signers are kept into addresses.
Alessandro Baiocchi:And…
Alessandro Baiocchi:So, the… the point here is that we cannot use the signer, because it is still the one authorized on the smart contract wallet, but it's a one-time signature that's already being used. So, we have backup signers.
Alessandro Baiocchi:And… which are other signers which are authorized to sign on that smart contract toilet environment to be used to basically rotate the main signer in the event that something goes wrong with the transaction.
Alessandro Baiocchi:These backup signals can take the form of values, like assigners, for example, some other words, signers pre-committed, or one signer that uses a stateless PQ signature, for example, syncs.
Alessandro Baiocchi:And… or if you trust a Memple, you can even use a trash ECDSA address. In any case, these are just meant to be used as a backup to recover, like, if something goes wrong.
Alessandro Baiocchi:And using one-time signatures also has some issue with, for example, multi-device, because you need to synchronize your… you would need to, like, you avoid using the same key across the multiple devices, and if you share
Alessandro Baiocchi:the same mnemonic on two devices. If you are using the same three, you need to synchronize the devices. So we decided we can go around that.
Alessandro Baiocchi:And the idea is basically, instead of having the same derivation path on multiple devices, if a user wants to have multiple devices, he can register multiple signers.
Alessandro Baiocchi:And from the same mnemonic, we use world-specific salt to derive a completely different derivation path, so you have a distinct keystream that does not need to be synchronized with the other device keystream.
Alessandro Baiocchi:to not have, reuse of the same, of the same key, basically. You just have different signer on those Mac control wallets.
Alessandro Baiocchi:And another issue we had to tackle is basically off-chain signing, because if you want to sign off-chain, you cannot… you have to produce a signature without changing the signer on-chain. And that's a… that may be a vulnerability in the account.
Alessandro Baiocchi:So, we decided to basically split the signer, and we have one signer, that's the one used for Validate User Group, and this is located every transaction inside validate user group itself to avoid user, possible errors.
Alessandro Baiocchi:And there is another signer, which is only authorized to do off-chain signing, and…
Alessandro Baiocchi:this is basically rotated on demand. The user can choose when to rotate it, so it can use to sign off-chain, then the off-chain signal can be validated, and then the user can rotate it when he wants, or if he deems he signs something he doesn't trust anymore.
Alessandro Baiocchi:So, like, to have an overview of what's, what's in Maestra at the moment, we have different modes, and each modes have, different, like, different trade-offs. For example.
Alessandro Baiocchi:while the quantum threat is still, like, in a theoretical state, as is today, we can use the ACDSA mode, which is easy, plug and play, it basically has no overgrad, and it's, like, as far as we know, it's safe with today's quantum computers.
Alessandro Baiocchi:And as QDay approaches, the threat gets more concrete, and we can use, quantum, say, PQ signatures, like watts.
Alessandro Baiocchi:And, that eliminates the Memple trust assumption, and offer quantum resistance by design at the cost of slightly more costly signal tubes, large signals and costly vilification.
Alessandro Baiocchi:Of course, in the meantime, if other PQ signals more convenient, more efficient signals emerge, those can also be interrogated into the design without changing the whole protocol.
Alessandro Baiocchi:And now for the security analysis, I'll leave the work to Connor from Project 11.
Conor Deegan:Yeah, so as part of this, we also looked at a complete security analysis,
Conor Deegan:of both the protocol and the cryptography. I guess one thing that's important to say is.
Conor Deegan:Quite a lot of the security for this comes down to the protocol implementation, given the one-time nature of some of the signature schemes.
Conor Deegan:So we looked at the rotation protocol in general, ECSA mode, Watts mode, some of the ideas for derivation paths that we've had, and then also the Watts parameters, selection. For those interested, there's a repository we'll share at the end, which has all of the files listed at the bottom, which are specific to the security analysis.
Conor Deegan:Maybe most important here is…
Conor Deegan:you know, the one thing we were aiming for is NIST level 1 security across the watts parameter set, which was possible. Even, you know, we were trotting different watts parameter sets to optimize for gas and verification and signatures, etc. But what's important is that we don't lose the security level of any of those. They all came within reasonable security bounds.
Conor Deegan:And then we… I dive into, you know, all of the limitations Alexander just mentioned, some of the off-chain signing, multi-device, and some of the re-signing is discussed in detail as well.
Conor Deegan:as I say, most of that comes down to a…
Conor Deegan:the implementation security, and then we have some… some cryptographic security processes in there as well. But yeah, as I say, for those interested, we'll share a repo at the end, and those files listed are the most notable to look at.
Matteo Vena | Riva Labs:I'll continue from here, so thank you, Connor, thank you, Alessandro.
Alessandro Baiocchi:It was muted.
Matteo Vena | Riva Labs:Yeah, so the core of the work also is related to UX. UX is extremely important here, because all of this remains theoretical otherwise. So now I'm gonna share with you a demo of what we have been working on. Can you see my screen right now?
Antonio Sanso:Sure, yeah, pretty well.
Matteo Vena | Riva Labs:Yeah.
Matteo Vena | Riva Labs:So this is a first version of our wallet, which is called NiceTry, where basically a user can go ahead and…
Matteo Vena | Riva Labs:create a wallet that implements, it's currently in testnet, everything that you have seen. The setup, experience, it's quite similar to anything that you would expect from a traditional wallet.
Matteo Vena | Riva Labs:outside of the fact that eventually you will have to choose, at least for now, the security mode, which it can be a CDSA, can be Watts, as explained, and very soon it can be also with a few time signatures that we are experimenting with, and the moment you confirm your choice, you basically end up with a very…
Matteo Vena | Riva Labs:Familiar wallet experience, something that you already know of.
Matteo Vena | Riva Labs:And our work has been very much focused on making sure that you can actually do something with these wallets, rather than just having a theoretical design. So I'm gonna move into a version, into an extension, where I already have some ETH. This is, again, on Ethereum testnet.
Matteo Vena | Riva Labs:I'll switch it to sidebar mode, and as you can see, this is the testnet environment, the official testnet environment from Lido, which is the largest, obviously, protocol on Ethereum for liquid staking.
Matteo Vena | Riva Labs:And this is, what's, mode of Nice Try. And over here, you can just go ahead and…
Matteo Vena | Riva Labs:steak.
Matteo Vena | Riva Labs:some EATH, which is what we are doing here as a test of interacting with DeFi protocols.
Matteo Vena | Riva Labs:And the wallet covers the entire logic, the destructing the keys, switching to the next signer, doing everything that you have seen for what's in the presentation, in a way that the user is just basically there.
Matteo Vena | Riva Labs:Waiting for a transaction to confirm. And to the user, there is no specific overhead outside of
Matteo Vena | Riva Labs:just using a wallet that can be, again, used as an extension, or in our case, also as a side panel. Now, the transaction obviously has to be
Matteo Vena | Riva Labs:validated, you can follow down here to see what is going on, and this being on Ethereum, it's slightly slower. Now it's done, the stake happened, and if we go and check
Matteo Vena | Riva Labs:the transaction. On Etherscan, it's still validating.
Matteo Vena | Riva Labs:Yeah, but as you can see from the logs of the transaction.
Matteo Vena | Riva Labs:what happened here, besides the stake that obviously increased our SV-ETH balance.
Matteo Vena | Riva Labs:There is the owner rotate function being called, and you can keep track, through the wallet itself of what was the previous signer.
Matteo Vena | Riva Labs:And what is the next signer? Now, since here we are in WATS mode, there are some details that we invite you to check in the spec to understand how this exactly works, but it's very… it's working, it's working today, we are making it compatible with as many DeFi as possible.
Matteo Vena | Riva Labs:And there is also a gas consideration to be made, because if I go to a simple send transaction like this, you basically have
Matteo Vena | Riva Labs:185,000 gas units, consumed in watts mode, and much less in the CDSA, which, if you include all the overhead coming from, from the…
Matteo Vena | Riva Labs:account abstraction, it's, we believe, pretty notable, and so people expect this to cost some crazy number, like 3 million gas units or something, but instead it's, pretty sustainable even today.
Matteo Vena | Riva Labs:And in terms of what's next to close off on our presentation, we are working on recovery implementations, we are working on few-time signatures, we are working on hardware support and multi-sig support, especially on SAFE, and we have in the works a concept for multi-chain ephemeral keys accounts.
Matteo Vena | Riva Labs:Besides also some gas-bumping strategies. If you have any questions for us or for Connor, which we thank for his extremely helpful contributions, you can email us here, or if you want, you can check the repo that we will also share in the chat.
Matteo Vena | Riva Labs:Thank you, and thank you, Antonio.
Antonio Sanso:This is really great. I mean, I'm impressed by the demo, to be fair. I have actually two questions, if you don't mind? Sure. The first one is, like, do… you used the… your demo was based on the… what Winters needs. But which one was, like, the recovery mode? Was, will there be…
Matteo Vena | Riva Labs:Recovery mode is still not implemented in full, because we will have, as explained, both spare keys for recovery or another signature sphinx, and we are working on the verifier, we're also waiting to see the work of the others and today's presentation to see what is already done and what we can add.
Matteo Vena | Riva Labs:But yeah, so far the wallet doesn't cover that, and it's only meant to showcase actual interaction with DeFi. But it's gonna be there soon.
Antonio Sanso:But, I mean, there also, the recovery more… I mean, the stable address was a… was an easy DSA, basically.
Antonio Sanso:I mean, since you had a stable address, the stable address, when the identity was derived by normally
Antonio Sanso:harsh of the public here.
Alessandro Baiocchi:Yeah, basically, yeah, it's described, like, in the same way we do with the CDSA, so basically we have about the what's public key, and we hash it and take the last, 20.
Antonio Sanso:Here's the greats.
Alessandro Baiocchi:So that's the same way, yeah.
Antonio Sanso:And the other things, like, I've seen, when you set up the wallet, you had 3 choices, and the red would have been…
Antonio Sanso:female AC, then you choose, like, the yellow mode that is, like, your interest needs. And ideally, I think your idea is, like, if you want a green model that covers, potentially, the more corner cases, like, you will use Jordan with Fords, potentially. Am I wrong on that?
Matteo Vena | Riva Labs:No, actually, we are looking into a few time signatures, yes, that's correct. Obviously, we are looking at it from…
Matteo Vena | Riva Labs:The same angle of the rest of the protocol, so we're gonna try and see what is the ideal way to implement it, but definitely the protocol is meant to implement as many modes as possible, and then different use cases, different choice.
Antonio Sanso:Perfect. A few questions here, Jeevan, in ECDC mode, what happens if a transaction gets reverted? Do you rotate the key as it first step, regardless? I think in ECDC mode, you don't need to rotate. There's no risk to spend twice the…
Matteo Vicari | Riva Labs:No, the, the idea…
Matteo Vicari | Riva Labs:in the GDSA, is, if, for example, the transaction is failed, for, reason, inside the transaction, for example, I, I don't know, something, what's wrong with the protocol you try to interact.
Matteo Vicari | Riva Labs:the key is rotated in any way, okay? So, the only problem, the transaction is… the key is not rotating if the transaction is invalid. For example, you put wrong notes inside the transaction, or the transaction exceeds the gas limit, but in any case.
Matteo Vicari | Riva Labs:Also, the second case, when the transaction exceeds the gas limit, can be avoided, adding gas policy that, in any case, try to rotate the key, and then do other stuff.
Matteo Vicari | Riva Labs:So, there is not a regarding issue, because you can just send another transaction with the same address and rotate the key again.
Antonio Sanso:Perfect.
Matteo Vicari | Riva Labs:That's it.
Antonio Sanso:Okay, thanks a lot. We can take always offline in the Telegram channel questions, and thanks a lot for the demo, guys. Thanks a lot, Connor, for the security analysis. I will read the document for sure.
Antonio Sanso:And, yeah, let's go to the… to Nico, that we will present Jardin. Basically, it will be an incarnation
Antonio Sanso:Of the same idea, using… I would love to say a more conservative choice on the ephemeral part.
Antonio Sanso:Because you're allowed to sign with the same key more than once, in theory.
Antonio Sanso:Am I correct, Nico?
Nico C:Hello, yes, it's, slightly different because, than you…
Nico C:don't need rotation anymore, basically. But, it's… yeah, it's exactly what they just described with the…
Nico C:With the… few-time signature scheme instead of the watch, you could have a very similar design.
Antonio Sanso:So, out of curiosity, would it be interested to, like, integrate your things in the NestTry wallet? Just out of curiosity.
Nico C:I mean, Claude will do it in 5 minutes.
Antonio Sanso:Again?
Nico C:Claude will probably do it in 5 minutes, so…
Antonio Sanso:Okay, okay, wow, great.
Nico C:I think it's just putting a verifier in the right spot, and then…
Nico C:Maybe changing the UX, but yeah, all that.
Antonio Sanso:Again, like, you probably heard me in the past, like, complaining about bad UX, and I mean, I have to admit that the UX of this Nestra wallet impressed me, I mean, it's…
Antonio Sanso:Of course, it's like, alpha, it's super new, and… but I mean, if the user experience looks like this, I mean, it's pretty smooth.
Antonio Sanso:Yup. Right.
Nico C:I agree.
Nico C:So… Okay, so let me start. I had a website, but just…
Nico C:Push something wrong to the website.
Nico C:Okay, it's back. Let's go.
Nico C:Alright, let's see, let's see, Al, I'm gonna share my screen.
Nico C:Can you see my screen now?
Antonio Sanso:Yep.
Nico C:Alright, so I just created this website very quickly, so we are able to visualize Sphinx variants.
Nico C:So… to start with the beginning, Sphinx is the stateless hash-based signature algorithm that has been standardized by NIST.
Nico C:But NIST, when they standardized the signature scheme, they took a budget that is very, very high, and when I say a budget, I mean the number of signatures that you can produce with a single key pair, and they took it to 2 to the 64, which is an insanely big number.
Nico C:If you look, on-chain, actually, if you look on Shane,
Nico C:99.99% of users who did a transaction in 2025 had less than 3,000 transactions.
Nico C:So if you take this number, you can quickly realize that just to go to 2 to the 20, which is about a million transactions, it would take years for the most intensive Ethereum users to get there.
Nico C:So basically, what we can do is that we can reduce the signature budget on Sphinx, and have something that is a little bit more lightweight.
Nico C:And a little bit more, blockchain friendly.
Nico C:And it turns out that we are very lucky, because two weeks ago, NIST actually published a draft of a variant that is closer to this. So in this draft, they use a parameter set for
Nico C:2 to the 24 signatures. And so what you see on my screen right now is a representation of this.
Nico C:So I truncated the 2 to the 24, Merkle tree, because this can't be represented on a screen, but basically you get the ID.
Nico C:And so here, you can zoom in and zoom out and see how the signature works inside. So this is the what's…
Nico C:signature, You can go here, and you can see here how a force signature is working.
Nico C:Basically, it's just a nice tool to visualize the…
Nico C:The trade-offs, and you can look at security at different parameters.
Nico C:And here, what is super interesting with this scheme is that I didn't… so this is brand new, this is an introduction, let's say, to Jordan. So this was published, two weeks ago, but implementing this scheme
Nico C:with Chateau, so with the NIST variant.
Nico C:I ended up finding this very nice, gas number.
Nico C:So previously in my, Sphinx experimentation, I was instantiating, the schemes with sketchak instead of Chateau.
Nico C:Why? Because Kit Shack is an upcode, and SHA2 is a precompile, and the precompile overhead can be quite large, especially if you have multiple layers here. So, for example, in this,
Nico C:In this variant, that is one that is used in Jordan, you have five layers of XMSS3.
Nico C:But in this one, there is only one, so we can actually use it, we can actually use SHA-2 directly.
Nico C:So what I did is I deployed this variant here, I deployed also a Ketchak tweaked version, but the very interesting news from this week is basically that we have a NIST variant.
Nico C:that… will probably be FIPS compliant, because NIST is looking into
Nico C:Making this, an official FIPS.
Nico C:And it actually just works. It just works on Ethereum for 142K in pure Verify, so that gives you,
Nico C:like a 300K, 4337 transaction, but also it gives you, something like a 200K frame transaction, which is, which is really acceptable.
Nico C:At, current gas price.
Nico C:So this is great, this is amazing, but the problem is this was designed for a certificate and firmware signing.
Nico C:And so this is designed for HSMs or big computers.
Nico C:And it actually works with my laptop in, like, 1 minute or two minutes to sign. It works on an HSM that I tried in a few seconds.
Nico C:But the problem is, like, obviously, not everyone has HSM at home.
Nico C:But the ones who do really need FIPS financial institutions, they have to use an IHSN signer, because using a hardware wallet is not FIPS compliant.
Nico C:So, in a sense, this new parameter set that was, drafted by NIST two weeks ago, opens the door to, on-chain verification,
Nico C:For financial institutions, for post-quantum wallets, and we can do this without any pre-compiler, without any protocol change.
Nico C:Okay, so this is, like, the… the news, this is… this is very cool.
Nico C:But for regular users, it's kind of a problem, because here, you could use this one with a laptop, as I said, if you have a powerful laptop.
Nico C:But you can't use it with a hardware wallet, and most users, I would say 99.999%, are not able to secure a SID on a laptop, so they really need hardware wallets if they want to use blockchain securely.
Nico C:And so, I am currently writing a paper, which is Jardian, and there is a public repo already, it's just, written Jardian like this, so you can go and check it. I'm gonna give this one in the chat right now.
Nico C:Oop.
Nico C:Okay, I will give it in the chat right after.
Nico C:Anyway, what this repo is doing, it's basically a smart account design, which is building on top of the Shrinks idea. So Shrinks is an idea from Janasnik from Blockstream Research. And,
Nico C:Basically, it's… Combining,
Nico C:It's, like, shrimps and shrinks are two designs combining a stateless, pass and a stateful pass.
Nico C:So, you can think of it as the stateless path being,
Nico C:Being a signature that you can use many, many times, and that you can reuse without fearing of doing something wrong, at the cost of being somewhat expensive.
Nico C:And, so in our case, it means that the signature is gonna be bigger, and it's gonna cost more gas.
Nico C:But the interesting part is that, if you use the right, sphinx minus variance, oop.
Nico C:Okay, this is the bug. If you use a variant like this one, you have a very signer-friendly experience, because the entire,
Nico C:tree computation that you have to do is only the top layer, so you have a small Merkle tree to compute, and with this Jardian design, we actually managed to sign on a ledger device with the compact pass in about 3 seconds.
Nico C:And for the stateful pass, we are right now at, 40… 45 seconds.
Nico C:So the design is the following. You first deploy your, contract, then you do, what we call a Type 1 transaction, and so the Type 1 transaction is going to use the stateful, sorry, the stateless pass, which is
Nico C:Which is, which is the Sphinx variant that I just showed here. So this is a pure Sphinx, variant. When I say pure Sphinx, it doesn't use any grinding, no woods grinding, no force grinding. I took this to be able to work on the security proof.
Nico C:In an easy way, so I contacted some of the Sphinx otters, and a bunch of,
Nico C:prestigious cryptographers, and they told me, yeah, it will probably be easier if we do just a regular Sphinx, so I went for regular Sphinx, and it also turns out that regular Sphinx is more signer-friendly.
Nico C:So yeah, basically, with this design, you can sign on a hardware wallet, and you can use this Sphinx variant on, your ledger.
Nico C:And, what you do is that you register what I call a lane, and it's very similar to the shrinks,
Nico C:idea, for those who are familiar with shrinks.
Nico C:So when you have a lane, basically, you register a key, a public key, to…
Nico C:Be able to sign in that lane?
Nico C:And this key can sign for 128 transactions, and it can be a much lighter, transaction. It can be a… it can be a plain force, tree, so a few times, signature in a stateful, way.
Nico C:And so what it does is it's gonna… it's gonna be very light and very fast to sign. This… this is the Type 2 transaction. So basically, once every hundred…
Nico C:28 transaction, you need to do a Type 1, which is expensive. By expensive, I mean, like, 400K gas and a 6KB signature.
Nico C:And then, every subsecond transaction is going to be a Type 2, so about 100,
Nico C:70K gas, this is a 60K Verify, so 60K Verify.
Antonio Sanso:A quick one. On the lane or type 2 transaction, it's happened… you said that it's a 128 signatures, but it's like, you rotate this, or there's no rotation here happening?
Nico C:There is, no rotation. The rotation happens on,
Nico C:the registration slot. So basically, when you finish your entire lane, you register a new slot, and this last, this old slot is basically destroyed, slash, not useful.
Antonio Sanso:Okay. With the type 2, or, like, you signed 128 times, that's it?
Nico C:Yep.
Antonio Sanso:There's no degradation after, like, signing twice, three times, up to 128 times, there's no degradation in securities.
Nico C:So there is no degradation in security, because, so it's stateful, so you sign with a different instance all the time, but this is also true for, like, what's the one-time signature scheme. But the reason why I used the few-time signature scheme here
Nico C:is, in a stateful design, you will have a number, let's say Q, which will represent the index, like the…
Nico C:The transaction, the next transaction that you're assigning is supposed to be number 5.
Nico C:And if you use a one-time signature scheme, and you re-sign number 5 twice, then your entire security is gone.
Nico C:And so, from an attacker point of view.
Nico C:This is what I explained in the post here. From an attacker point of view, it's,
Nico C:It's quite easy to roll back a signer, to…
Nico C:Let's say, confuse the state of a signer.
Nico C:And here, when I say signer, I mean hardware wallets. So it's doable on most hardware wallets, but it's extremely doable on any browser signing anything that is not hardware.
Nico C:On hardware, you already have a bunch of,
Nico C:Attacks that are showing that this is possible to do.
Nico C:The best people to… to do this are probably,
Nico C:Ninja… Ninja Labs, the Ledger, Donjo team, and Overture. They've shown
Nico C:plenty of attacks that are showing that it's easy to do a fault injection on a hardware signer, and then you would end up in a situation where you sign twice. And so to prevent this, we decided, in Jardine to go with the few time signature
Nico C:And with a few times signature… sorry, I'm getting lost here. So with a few times signature, in case you reuse the signature, you still keep some good amount of security.
Nico C:So depending on the force design that you select, you can keep up to, you know, up to 110 bits, let's say, at resigning.
Nico C:And so what this means is that if, someone is attacking me and,
Nico C:altering my signer state, let's say I'm in a software wallet, someone managed to hack me into
Nico C:And to make me sign, twice, I'm still at 110 bits.
Nico C:And so this is good, this is good because, then I, I still survive this attack. And so this is the entire reason to, to choose, force.
Nico C:Instead of a one-time signature. And it's good to mention that no smart contract design can help to prevent that. So basically, this attack would be offline, local, on the signer.
Nico C:So it would look like, you sign a transaction, the transaction is not even broadcast, it doesn't even leave anywhere to a mempool, it just goes to the attacker, and then they make you sign again, like you feel like there was a bug on your browser extension, and then that's it. Your money is gone.
Nico C:And so to prevent that, I believe that using a few-time signature is actually the right choice.
Nico C:But it comes with the trade-off of being, of being…
Nico C:way bigger. Like, the signature size for force has to be above 2K, 2KB, so it's gonna be somewhere between 2 and 3 kilobytes for…
Nico C:A few times signature waste force.
Nico C:And so, yeah, this is the main idea behind Jardine. You register a line with the stateless pass, and then you can sign every subsecond transaction with the few-time signature scheme. And when you're done with your line, you can just register a new slot.
Nico C:And start, again.
Nico C:And using a… using a salt, on the…
Nico C:on the Type 2, you can use the same hardware or different hardware. I also, propose,
Nico C:a hardware signer, integration, so I wrote the… a ledger application, but I'm also going to write
Nico C:a Trezor… application and different hardware. But basically here in this fork, you can find
Nico C:the Sphinx implementation, so yeah, this…
Nico C:allows you to do this on a ledger device, and it works. Obviously, this is experimental, this is not audited, so please don't use it in…
Nico C:in production yet, but yeah, in the future, I could see a few audits on
Nico C:On the hardware signer and on the verifiers, and we would be, good to go.
Nico C:So the main achievement, in Jordan is basically adapting this to the very, very constrained, environment of the…
Nico C:ledger devices, which are running on secure elements.
Nico C:If we are not in such a constrained environment, we can just use
Nico C:A Sphinx minus variant, like, like this one, and we're good to go.
Nico C:And so you have this, Hebrew design with, with Jardin, where you can, use one of these variants, actually this one.
Nico C:To be the… the stateless pass.
Nico C:And then what you have, the force, in the compact pass is basically just this. You remove everything that's above, and you just do this inside a Merkle tree.
Nico C:So yeah, this is, based on what the Bitcoin people have been doing, and it's…
Nico C:In my opinion, a decent solution to have.
Nico C:It's probably not a long-term perfect solution. The UX…
Nico C:It's still a bit tricky, and could be improved, in the… in the ledger device signing, because you still have to do some key gen at the beginning, and it still takes, quite some time. But, yeah, it can be… it can be improved,
Nico C:And then I will be doing an integration inside a wallet, so I will probably be doing this inside the Kohaku demo extension.
Nico C:But yeah, the great news this week is that we can now sign,
Nico C:a NIST-compliant scheme on Ethereum. We can do this with Chateau, not Ketchak, and this only costs
Nico C:142K gas, and we are in touch with NIST to try to have a variant that goes even more in our direction.
Nico C:And we also have a path to, to do, something quite similar and make it available, to regular users through,
Nico C:through Jardine, a design that is a hybrid account design that allows you to sign a very light version
Nico C:of Sphinx, and that… That works on a hardware wallet.
Nico C:And so that's… that's about it. I could, sign a bunch of transactions, turn the camera on, but, yeah, this is…
Nico C:This is for probably the next presentation, where I will have, an integration inside a wallet, and this will be,
Nico C:Much, much better to look at, rather than me passing a few comments in the terminal.
Nico C:Perfect.
Antonio Sanso:Thanks a lot, Nico. I have a question, and then we need to move on to the last presentation, so we can continue this.
Antonio Sanso:on the chat, on Telegram later. But basically, to recap, it's this. You will use this new Sphinx Manus for, for,
Antonio Sanso:laptop, and you will use Jordan only for, for a harder wallet, correct?
Nico C:Correct. Then,
Nico C:We need a little bit more thinking into this, because if we do this, basically we reveal the usage of hardware wallet on-chain, which is also not great.
Nico C:Because basically, I could look at the chain and know when you have access to hardware or when you have access to laptop.
Nico C:So, right now, I would frame this as, if I'm an institution, I would use, I would use this with an HSM, and that's end of the day. By this, I mean the SLH.
Nico C:Right. That NIST just published. And for regular users, we still need to continue the research, but yeah, we would probably have something like a Jordan account.
Nico C:And that would… Put regular users in a very safe spot.
Antonio Sanso:And there will be… the regular user, they could use as well with the wallet, a normal wallet, Jordan, as well. I mean, it's not… it's not… Yeah. Okay, perfect.
Antonio Sanso:There are some questions, but there's some, as well, suggestions from Benedict. I suggest you to give a look at the chat, because there are some suggestions about your proof, but I really need to give the stage to Mehdi. Thanks a lot, Nico, and I'm sure that we'll hear more about
Antonio Sanso:these solutions.
Antonio Sanso:Perfect.
Nico C:Thank you so much.
Antonio Sanso:Time to shine.
Mahdi Sedaghat:Hey, everyone, good afternoon, good morning. I'm going to share my screen.
Mahdi Sedaghat:Okay, I hope that you can see my screen.
Mahdi Sedaghat:All good?
Antonio Sanso:Yep, yep, we see that.
Mahdi Sedaghat:Okay, amazing. So, yeah, as already Antonio mentioned, first of all, I mean, these are really brilliant ideas and, like, an improvement on top of, like, the keys.
Mahdi Sedaghat:And as Anthony already mentioned, okay, this is going to be a fancy solution for keeping the addresses and not, like, rotating the keys frequently in the order of the transaction that is going to be made.
Mahdi Sedaghat:I already, like, opened a thread on it research that you can, follow here. I will share the link afterwards in the chats, but you can also leave your comments over there.
Mahdi Sedaghat:So, very quickly, I mean, everybody knows about what is a threat, but what I want to highlight here in this slide is that whenever we only reveal the hash of the public key, we are going to be safe.
Mahdi Sedaghat:And as long as the account is not making a transaction, it means that the public key has not been exposed, and there is no chance for the quantum adversity to drain the signing key and drain the account and have a full control on the asset.
Mahdi Sedaghat:So…
Mahdi Sedaghat:And as you know, like, a thermal key rotation is that, for every transaction you're making, send the remaining, or…
Mahdi Sedaghat:your on-chain asset to another account, which hasn't done any transaction, but there are some caveats and some drawback for the solution, as you know that the private land pool is needed. Otherwise.
Mahdi Sedaghat:There are some, like, a way for the quantum adversity to observe the mempool and run the short algorithm in a matter of minutes, and then train that count in a similar way.
Mahdi Sedaghat:Another problem is, what if that transaction is being failed, and how we can, like, protect the assets on that case is also a big question mark. So what I want to, like, highlight here that other people also mentioned today is about the other type of wallet types, like HSM wallets and HSM hardwares.
Mahdi Sedaghat:As you know, there are a lot of boundaries for this type of systems, and we cannot, like, generate indefinite number of keys inside these HSM units, because there are some limitations for the memory and other aspects.
Mahdi Sedaghat:Another problem is for the MPCs, as you know, that if you want to, like, run DKG per transaction, this is going to be a pain, and it's extremely hard for these type of accounts to rotate the keys.
Mahdi Sedaghat:And, a good solution, I mean, you already mentioned some of the good solutions, and the solution that I did, I mean, ended up to…
Mahdi Sedaghat:This is, like, hiding the poppy key, and it is not a new idea, it's already been discussed in different years and different, like.
Mahdi Sedaghat:Brett, even you can check this if research, by this title. I already left it on the GitHub that I'm going to share the link with you guys.
Mahdi Sedaghat:But the core idea is quite simple. Never reveal the public key, and all the time prove in zero knowledge that you have access to signing key that generates a valid signature on top of the transaction details. And with this approach, I mean, you don't need to rotate the keys, and you only need to do it once.
Mahdi Sedaghat:And there is only one part that I have to highlight, that we need to delegate the asset in the initial account to this, new, account to make sure that the, the initial address is not going to be broken by the quantum adversity, and the assets are already protected in this case. But as you can see, and, like, the…
Mahdi Sedaghat:project here that we need, essentially, to have some conditions for the user who is trying to get access to this asset to check this validity of the CK proof on-chain and inside the smart contract that I'm going to walk through with.
Mahdi Sedaghat:So, what we expect from this CK proof is definitely it should be post-quantum and provide us the post-quantum soundness, and we need to bind both copy key and also the signature components. You might ask that why we need to, I mean, hide the signature components. The reason is that for easy DSA, once you have access to RNS,
Mahdi Sedaghat:values, you can reconstruct and rebuild the property.
Mahdi Sedaghat:Which is extremely important, but you can, I mean, reveal as a statement the public key of the hash… I mean, the hash of the property and the hash of the transaction that are, like, necessary for the validity of the transaction that are going to be checked.
Mahdi Sedaghat:Another important aspect is, like, the proving system should be client-side. As you know, there are a lot of, I mean, interfaces that are, the wallets are being run is either, like, a web browser or the mobile devices that they are having limited resources. And thanks to recent digital identity efforts for that regard.
Mahdi Sedaghat:We have multiple proving systems that they are post-quantum, and we… they enable us to have a client-side proving.
Mahdi Sedaghat:much faster compared to the existing, like, ZKVMs or other solutions that exist. So another aspect that I want to highlight here, the proving system, that we already, like, tried to use it in this, in this benchmarking and this, like, a proof of concept is entirely hash-based, and there is no, other assumptions that being involved.
Mahdi Sedaghat:Which is one of the added value for Ethereum Foundation that they are being considered in this thread.
Mahdi Sedaghat:So, there is a link to this repo that we already implemented. This is entirely a vanilla design, and there are a lot of rooms for the improvement. Feel free to leave your comments, and also open the PR
Mahdi Sedaghat:And what we are using and we are doing is over the Longflow ZK, which is one of the existing digital identity systems that is being deployed and also maintained by the Google, but there is also an independent implementation of this, library, in Rust by another, like, programmers.
Mahdi Sedaghat:that the link is also available in the repo. As you can see, the proving time is extremely fast, 87 milliseconds, and the reason is that this proving system is specialized designed for legacy curves, like SECB256K1, which is the curve that the Ethereum is using.
Mahdi Sedaghat:And also, as you can see, the proof size is slightly larger than what we expect from the other, I mean, definitely, like, an order of magnitudes larger than the post-quantum signatures.
Mahdi Sedaghat:And the gas unit that we are using is, like, in the order of millions. But there are a lot of, rooms for the extra improvements. As you can see, like, at the moment, we are opening 132
Mahdi Sedaghat:columns for the Ligero. At the end, this is like a sum check protocol plus Ligero for this proving system, and if you reduce the number of the columns that is being opened by the verifier, we can have a significant improvement in the verification and the proof size.
Mahdi Sedaghat:Another aspect is, we can definitely use some other EIPs to reduce the cost. And another aspect that I'm currently working on, essentially, the circuit is a designated verifier, because we don't need to verify the ECDSA signature
Mahdi Sedaghat:entirely inside the circuit, and we can, use some optimizations here, because the prover has access to the signing key, and the prover is the sign… I mean, the signer, essentially, in this scenario.
Mahdi Sedaghat:So, how does it look like? Basically, we can run the EIP7710 or some other, like, EIPs that they are specifically designed for the delegation purposes. The initial address that the public key is already exposed is going to delegate the asset to this hash of the public key.
Mahdi Sedaghat:And then, essentially, we put some… some caveat and some limitations for, withdrawal of the assets, and this caveat and this, like, limitation is going to be providing a valid CK proof that verifies under… under the hash of the public key.
Mahdi Sedaghat:So, as I said before, there are some open problems that we are just actively working on. One of the interesting open problems that we can consider here is how we can, like, further optimize the validity of the, I mean, running the circuit, and also reducing the proof size and the verification time
Mahdi Sedaghat:Another aspect is, whenever I'm talking about the MPC solution, so it is not entirely keeping the assumptions that we have for the MPC, because essentially, in the MPC accounts running at DKG, we are revealing some components in the exponent of the generator, and we are just relaxing the assumption in this case. And having, like, a solution for generalizing this concept to the tertial ZK proving might be an interesting research question.
Mahdi Sedaghat:As well, like, that we are working here.
Mahdi Sedaghat:So, more than happy to receive your comments and suggestions, and happy to answer the questions if there is any.
Antonio Sanso:Thanks a lot, maybe.
Antonio Sanso:Makes a lot of sense. Anyone? Any question?
Antonio Sanso:Okay, I see one question.
Antonio Sanso:You want to read yourself, Manny, and answer?
Mahdi Sedaghat:Give me a second, one of the tasks, okay.
Antonio Sanso:If you don't see the chat, I can read it for you, tell me.
Mahdi Sedaghat:Yeah, that would be great, I cannot see the.
Antonio Sanso:So it tells Matteo from Riva, he's asking, once the EOA's classical key is recovered by a quantum computer, what stops the attacker from signing a fresh EIP7702 authorization with it and re-delegating the EOA?
Mahdi Sedaghat:Yeah, that's a good question. So, what we are just doing right now, we need to just put some restrictions for extra setup, because the initial setup, we assume that it's happening whenever the actual quantum computer, I mean, cryptographically relevant quantum computer is with us, and the setup should happen beforehand.
Mahdi Sedaghat:And once this is done, the condition for rotating again should be providing the ZK proof.
Mahdi Sedaghat:So it is not,
Mahdi Sedaghat:As straightforward as it is, but after that, we need to also update this type of accounts that have been delegated to not be delegated again to another address and to another account.
Antonio Sanso:Alright. Matteo, are you happy with the answer?
Matteo Vena | Riva Labs:Yes, sure, thank you.
Antonio Sanso:Cool. Any other question?
Mahdi Sedaghat:I'm going to, share the links with you guys, happy to receive your comments, in the IT research and also the GitHub that we already have publicly available.
Antonio Sanso:Alright, thank you.
Antonio Sanso:So, I guess we got a pretty busy call today, a lot of good stuff, and I'm happy to wrap the call here for today. Thanks a lot to the presenters and the people who attended.
Antonio Sanso:And I'll see you in two weeks!
Antonio Sanso:Thanks a lot.
Conor Deegan:Thanks, everyone.
Matteo Vena | Riva Labs:Thank you, thank you, bye.
Alessandro Baiocchi:Thank you.
Miha Stopar:Thank you.
Jeevan Siddharth:Thank you.
Chat Logs
00:16:34
alan xu:https://github.com/firedancer-io/firedancer/pull/9446 Looks like Solana has chosen falcon for PQTS, what about ethereum?
00:17:26
Nico C:I will do less than 15 all good !
00:32:03
Jeevan Siddharth:In ECDSA mode what happens if a txn got reverted , do we rotate the key as first step regardless ? , since now we have txn history of that key right ?
00:33:47
Matteo Vena | Riva Labs:https://github.com/RivaLabs-Core/Ephemeral-Keys
00:47:41
Benedikt Wagner:@Nico C for security proofs in the context of grinding, you may look into our aborting RO framework (designed for the XMSS signatures on the CL): https://eprint.iacr.org/2026/016.pdf
00:55:33
Miha Stopar:Did you perhaps think about what could be a (PQ) SNARK to be used for this signature scheme?
00:56:03
Benedikt Wagner:Replying to "Did you perhaps thin..."
I think this is for the EL, so why do we need a SNARK for it?
00:57:20
Miha Stopar:Replying to "Did you perhaps thin..."
In general, I am looking for a PQ signature scheme with PQ snark with efficient on-chain verifier for a PSE project.
00:57:25
Nico C:https://sphincsminus.org/
00:57:30
Nico C:https://github.com/nconsigny/SPHINCs-
00:58:34
Nico C:https://github.com/nconsigny/sphincs-ethereum-app/tree/sphincs-c11
00:59:03
Nico C:https://github.com/nconsigny/JARDIN
01:00:28
Nico C:I will open two ethresearch blogpost (one for SPHINCS- and one for JARDIN). Just waiting on some feedback but most of it are already available in the repos
01:01:07
Ooia oo [OKX]:Replying to "Did you perhaps thin..."
I guess there is another use case for high value wallets. Where signature is ideally multisig/mpc-ish (or anyways where u can separate the storage key material completely)
01:03:27
Antonio Sanso:Replying to "https://github.com/f..."
It seems the direction is going toward hash based and dilithium
01:07:15
Matteo Vena | Riva Labs:Once the EOA's classical key is recovered by a CRQC, what stops the attacker from signing a fresh EIP-7702 authorization with it and re-delegating the EOA to a contract they control?
01:08:44
Ooia oo [OKX]:Multi-proving technqiues might be able to reduce computation required for the zkproof
But then u need techniques to prevent collusion 😭
01:09:16
Lumi | Wonderland:ty everyone!
01:09:21
Ottie | Wonderland:Thanks everyone!
Summary
14 highlights
· 2 action itemsExperimental
Summary
14 highlights · 2 action itemsExperimentalephemeral keys implementation
- Riva Labs demo: NiceTry wallet supports ECDSA and WOTS modes with rotation00:17:04
- WOTS mode: 93K gas validation, 460-byte signatures, quantum-safe by design00:24:41
- Live demo: DeFi interaction (Lido staking) working on testnet with key rotation00:28:19
- WOTS backup signers address transaction failure scenarios (wrong nonce, gas limits)00:31:25
sphinx variants
jardin design
- JARDIN: Hybrid stateless/stateful design combining SPHINCS- with FORS few-time signatures00:44:51
- Type 1 (stateless): 400K gas, 6KB signature; Type 2 (stateful): 170K gas, 128 transactions per lane00:46:53
- Ledger implementation working: 3-second compact signing, 45-second stateful signing00:53:19
- FORS prevents catastrophic key reuse from fault injection/state rollback attacks00:49:22
zk proof approach
- Longfow ZK proving: 87ms client-side, hides public key via zero-knowledge ECDSA proof01:01:11
- Current implementation: ~2M gas, 20KB proofs; optimizations in progress (column reduction, designated verifier)01:03:41
- EIP-7702 delegation protects assets post-key-exposure by requiring ZK proof for withdrawals01:04:43