Future-Proof Your Treasury: Post quantum Accounts for Kohaku wallet

Transcript

So, hi everyone. Thanks for coming to my presentation. Um I'm going to present what we've done for Kohaku wallet in terms of post-quantum integration. Uh before I talk about post-quantum cryptography, let me just briefly present uh what is my company, Zengo Knox. So, we are only three people. Uh Nicolas Bacca that you probably know from Ledger because he he was on the co-founder of uh Ledger. Uh he's specialist in hardware integration and yeah, hacking this hardware device.

And then uh Renault and I are cryptographers. So, we work only mostly on cryptography, I would say. And uh we With Zengo Knox, we try to work on every layer of the blockchain from um hardware integration, uh smart contract. Uh yeah, we we try to focus on every layer of the blockchain. So, in this presentation, I'm I'm going to talk about a bit of hardware wallet. I have my Ledger here. Um we provide in this work the first implementation of um post-quantum signature inside the hardware wallet so that the secret never leaves the secure element and you can sign uh without uh using the software.

And I'm also going to talk about uh smart contract because we provide the first uh signature verification inside the smart contract that fits for transaction in Ethereum because we have a limit in terms of gas and so we provide the first um optimized smart contract for post-quantum signatures. So, if you need to remember something, it's that for now in on the execution layer, it's already possible to have post-quantum security. Of course, it's a bit expensive, as you will see, but it's already possible. Uh if you want more information about Zengo Knox, we try to provide some demonstration of what we do in terms of implementation and deliveries. So, yeah, feel free to check it out.

So, Kohaku is a SDK pushed by the Ethereum Foundation for focusing on privacy and security for the wallets. Actually, there is a presentation by Nicolas Cocini just right now, so you won't be able to attend it. But um if you stay after my talk, there is also a presentation by Stephen on Trustless Manifesto here. And yesterday, there was also a presentation by Renault on um hardware integration for privacy uh protocols. And this talk is using a smart account that is not included in Kohaku for now, but it will be integrated soon and as long as we have smart account, we will be able to deploy this uh

post-quantum accounts. So, you can also check the GitHub of Kohaku if you want. So, why we need post-quantum security? Um on Ethereum, we rely on ECDSA, meaning that when you want to sign and send some funds, you need to provide an ECDSA signature. So, it's a very nice signature that has very nice properties. First, they are small, around 60 bytes. It's also very efficient, so you can verify the signature efficiently and it's quite trusted because Bitcoin, Ethereum, and most of the blockchains, they use these um signatures.

The only small issue is that it's uh broken if you have a quantum computer. So, actually, there was two papers that were published yesterday about how to optimize these quantum algorithm, which makes ECDSA a bit trustless now. But, we have some alternatives for this this issue. And since almost 10 years now, there is a a standardization process by NIST so that we have different uh algorithms to to to be resistant against a quantum computer.

So, there have been many candidates for being post-quantum. Some of them have been broken and some of them are still secure. And actually, the NIST the standardization um institution uh selected three candidates that I will be presenting here. And many institutions, including uh Ethereum uh uh announced some post-quantum integration so that we can resist this uh this issue of quantum computer. So, also here, you can check uh the post-quantum roadmap for Ethereum provided by Justin Drake, if you want.

And uh yes, let me introduce the three candidates. So, there is actually two candidates based on lattice-based crypto and one based on hash functions. And you can already see that there is a a small problem. The signature size and the public key size is at least 10 times bigger than for ECDSA. So, this is an issue for a blockchain because we want to store on chain this data and this will make a big data on chain. Uh these numbers, I will go back to them soon, but it's the gas cost that you need to verify a signature on chain using our smart Solidity contract that we provide.

So, in this talk, I'm I'm going to focus on the two first column because the third one has huge signature size and it's not really designed for blockchains. There are other properties that we want from from the signature. Uh for example, we want to be able to integrate this into a hardware wallet because people use the hardware wallets. And actually, for some of the signature schemes, it's quite complicated to get this fit into a hardware wallet. So, in this talk, I'm going to show you how to sign using ML-DSA on a Ledger device. Uh there are other properties that I won't um dig into the details, but we want to be able to do public key recovery to reduce

the data on chain. Um yeah, special signature is also something nice that we would like to do uh in the post-quantum world. So, besides this um implementation, we also push some EIPs for these two candidates. So, one EIP is about ML-DSA. So, we we provide two precompiles, one for the NIST version, so complying fully to the standard, and another version using changing the hash function. Um anyway, I won't go into details on this, but we did some optimization so that the public key can be expanded to save some gas in the verification.

Uh basically, the public key is 1 kilobyte, but we expand it into 20 kilobytes, which is even bigger, but then we save some computation in the verification. Uh the second EIP is um for Falcon, so the the other candidates. And here, it's a bit different. We provide two EIPs because uh the verification is has a clean separation between hashing and verifying using entities. So, we provide two precompiles so that we get something more modular.

At the end, what you need to remember here is that a verification of a post-quantum signature is basically a few hashes and a few entities, which is not too expensive at the end when you once we have some precompiles. So, now that we have the our two signature scheme, it's also important to be able to handle the the keys properly. So, you probably know that there is something called BIP 32 for deriving your secret key for ECDSA from your mnemonic phrase. So, basically, you have your mnemonic phrase, you hash it several times, and you'll get some bytes that will be your secret key.

Uh what we provide here is a simple way to have post-quantum keys just having another keyword so that at the end, you will derive different keys, some for ECDSA, some for ML-DSA, some for Falcon, etc. So, now, how do we integrate this into Ethereum in the execu- execution layer? >> [snorts] >> Uh let me explain how it works in practice when you send a transaction. So, Alice want to send some ETH to Bob.

Uh she will first create a signature of a transaction hash that contain all the information of the transaction. And this signature will be verified at the consensus uh layer using uh the verification of the signature ECDSA. Uh something that is really nice in Ethereum is that we have smart account, which means that this verification can be done inside the smart contract. So, instead of having this uh verification of ECDSA, you can basically put whatever you want.

And in this work, we implement uh post-quantum verification inside the smart contract. So, using this um this structure, we can enable post-quantum security using smart contract. So, actually, we don't remove ECDSA and put um ML-DSA, but we rather put a hybrid verification with uh two signatures to be verified. So, one ECDSA and one could be ML-DSA or Falcon.

So, I'm going to show you a small demonstration where I first create the smart account. So, from your externally owned account, you create the smart account using uh the generation of the keys and then uh storing the account including the public keys. And in the second time, I will show you to make a transaction using a hardware device. So now we don't really need the externally owned account. We will just send some funds from the smart account to another account. And hopefully it works.

So let me show you the website. So you also you can uh trade on your laptop if you want. So here I have uh the first step is to create my account. So I will show you in software. So I write my mnemonic phrase. Of course it's not the real one. Um so for now it's connected to my Rabbi account so that I have I can create this smart account. So this is deploying the account. So

what is happening in back end is that it derives the secret key for ECDSA and for ML-DSA. And then do the key generation. Storing uh creating the smart account including the two public keys. And here we have the address of our smart account. Now if I go in the send transaction section So this is the address of my smart account. And now um I'm going to send to let's say let's try with Vitalik. Try um I don't know if it's going to work with the ENS but let's try.

And Yeah? And um um I could do the do it with the software but I will try with a ledger. So I will sign using the ledger directly. Which has the same mnemonic phrase uh yellow yellow yellow. Okay. So now it's asking for the ledger. Uh use in clear signing so I can see exactly what I want to sign including the recipient address, the amount of tokens.

And now I sign. Submitting to the bundler and now the transaction is accepted by the by the chain. So we need to wait a few seconds. Uh let me go back to the slide now. So just to conclude we provide uh smart account with post-quantum security in this presentation. Uh I provide here with the gas cost. So you see that it's quite a lot of um of of gas because it's in million of gas.

This is because we have huge public key to be stored in the smart contract. But still it's something feasible because we depending on the context you would spend a few dollar to send a transaction if you want to secure your funds against the quantum computer. Uh still it's not uh production ready because we have to audit the code. We would like also to have some version of higher security level. Uh we provide the first uh post-quantum signature implementation fully on a on a hardware device.

For Falcon it's still um close to the limit of 40 kilobytes. So it's quite complicated to implement it. And uh what is also missing is a precompile because using a precompile this cost for sending a transaction would be reduced a lot. Uh other things that are missing to get fully uh quantum security is the deactivation of the EOA. Because um we once we create the smart account we still have a way to revert this creation. So using the the EIP 7851 we would get fully full security by deactivate deactivating the EOA.

There is also um um EIP for the frame transaction which is a kind of standard for the smart account specification. And about the precompile that we would like to be pushed. We have we propose two precompiles that would lead to very small amount of gas. But we also provide another precompile that is more generic with Vitalik. Uh as you can see it's more gas to be spent. But um the main point is that at the end the cost of the verification will be mostly the data call storage and copy. So I wanted to highlight this and give you like a lower bound of how much gas cost

you will need for the data storage. So if you use Falcon and ECDSA just storing the signature uh on chain storing the public key and sending the the signature would spend at least 17 kilogas. And for ML-DSA you would have a cost of at least 46 kilogas. So at the end the the verification itself won't be very the the big cost of the of the transaction. And just to go back to the transaction.

So now we have the transaction that is on chain. So I can just check it on Sepolia. And here you have the transaction that I've done to Vitalik. And you can check the details. So you have the gas cost here. And you can get more information on the smart account transaction here. Yeah. That's it. Thank you. >> [applause] >> Uh does anybody have any questions?

Uh it looks like you are yes thanks for the talk and it's a also an amazing work I assume uh around here agrees. Uh my question is it looks like uh the post-quantum uh signature scheme you are using uh is the top two recommended by the NIST. But they are all lattice-based, right? Yes. And I assume the like according to the Strom map or something like that uh Ethereum Foundation maybe prefer to go for like uh totally hash-based version, right?

Yes. So in the Strom map in the road map of the Ethereum Foundation they focus on the consensus layer and and the execution layer. And for for this work it's only the execution layer. And we focused on the on the lattice-based um scheme because we want to we consider that the following the standard is also something that we must do. And using hash-based signature is uh really huge signature that uh would make it uh very expensive to verify on chain.

Yeah. So yeah on the on the on the consensus layer it seems that using uh hash-based solution would be better. But for the execution layers we believe that this would be the best fit to follow the standard for from web two and to get something secure. Yeah. More questions? I think that's all. Okay. Thank you.