Hardware wallet integration of Privacy preserving protocols for the Kohaku wallet

Transcript

Hi, uh I'm Renault from Zk-Snarks. Uh today we're going to talk about uh the work we've done inside the Quorum framework. Uh so hardware wallet integration of privacy privacy preserving protocols. So first, uh Zk-Snarks team who has We are a huge team of three people. Uh but uh while small, we are covering the whole field uh being from uh user end so uh secure enclave hardware wallets. That's the topic today. Back end and on chain so um yeah, that's the service.

So Quorum Quorum is a privacy first tooling for the Ethereum ecosystem. It's an SDK. It's live. Uh the aim is to provide a better UX for privacy which has been identified as one of uh the limitation for wider uh adoption. And in this framework, what Zk-Snarks is providing are some experimental fixtures uh mainly uh hardware integration. Uh that's the subject. Uh fixture experimentation. We are also co-authored uh two two EIPs. Uh tomorrow uh Simon will present those results.

And uh we also provided uh 7702 uh jailbreaker to enable to uh experiment with ledger that is breaking to whitelist. Uh and everything is available in our GitHub. So yeah, what's what was the difficulty? So how is the hardware wallet gap? So Quorum wraps privacy pools and Regen uh and hardware wallets do not support Poseidon nor Baby Jubjub for those fields natively. So privacy pools both and Regen both use Poseidon over the BN254 fields. And for Regen, there is uh Baby Jubjub curve to be implemented which is not part of um common SDK for uh Arweave wallets.

Um, yeah so first, uh would like to to have a brief talk about the fact that uh indeed matter easy and uncoding are hard. So, I don't know if you have some implementers here and uh in general we spend more time uh solving encoding problems than uh implementing the elliptic curve itself. Double encoding uh cannot just uh say a uh LGTM and uh push it. So, it's also an interesting thing to have a double coding of protocol because that's what we do. Uh our stack has no external dependency.

So, some kind of bugs that we found during uh during the project was like a Lagrange interpolation bug. There was a division that was happening in a natural integers instead of uh of the fields. And I'm things that you you cannot have missed uh last week uh the privacy pool deal uh um did the did the job, but you had to to migrate from uh the first derivation. There was an improper derivation that uh crashed uh crashed the entropy. Uh there is a full article uh describing everything. So, everything has been patched uh and fixed uh fixed now. But uh it would have been solved uh while implementing this uh

um but that was not in our scope. But yeah, so basically double encoding is like having a free audit. So, back to our back to our topic. Uh so, Arigon use a Baby Jubjub, which is a twisted Edwards curve. And um yeah, mainly it was quite quite easy to implement. For the hardware constraints, the challenging uh was the Poseidon part. Uh Poseidon, for those who has used uh Circom, it's it handles uh large set of tables and this is uh this does not fit uh into constraint constraint hardware. So, what we had to do was to regenerate the constant on the fly. I use tricks such

that having starting point in the derivation. So, I know that there are initiatives to renew Poseidon as an embedded implementers, I would ask EF to consider to use not the country Cauchy construction with which implies inversions and it's a nightmare and replace it but uh maybe like circulant circulant matrix. But doing this we we were able to to have it fit fit in the hardware. So, what is Rhygon? Rhygon basically is a Zcash-like mechanism.

Uh so, um an interesting property of it is that you can separate the witness generation uh from the proving. Uh which is not the case for Tornado Cash where your nullifier, which are secret elements, has to leave uh the the enclave at at some point to be to be proven. So, this is a very interesting uh property providing the same security we we have with I guess the rest of uh your classical transaction where you don't want any malware to be able to um to steal funds. Uh and I guess that's providing this hardware integration will

also help increasing the TVL because myself I'll never use uh a software wallet to to store more like a few hundreds dollars and you should not. So, this is this is a Rhygon circuit. Um Yeah so I guess I won't go deep into details. But basically what happens uh you bought a circuit proof so the ownership of the notes uh uh after receiving uh from the signer uh uh the you take the the signing of the you take so so um yeah so as I said uh Tornado Cash

privacy pool V1 do not need this model. We are discussion uh with privacy pool they are switching to a you take some model. Yeah so another thing we are uh we have been working on is Frost. So Frost is a K out of one threshold signature scheme. So it enables to have K signers uh to produce uh valid signature. It's like what you're doing on your safe I guess when you have a governance so uh you accept a signature valid as soon as K signer from a subset of K signer from an uh agree to sign on the message. Uh basically it's based on a Lagrange interpolation.

Uh each signer only signing one of the shared secret of the key and the key itself is never reconstructed. So works Frost work for Schnorr curves like like implemented in Taproot uh Taproot Schnorr and uh by chance EDDSA which is uh what is implemented in in Sacr is is a Schnorr version which is um which which is mandatory to to be able to implement Frost. This is very uh simple compared to ECDSA constructions.

Uh yeah so as a result uh compared to uh naive uh naive K out of N N signing uh it it provide a private governance because looking at what happens on chain you have no clue if uh the Frost has been using uh used or if it's just a mono signer. And yeah it comes with no uh no overhead. So basic idea uh behind this it's using Lagrange interpolation. It's the same algorithm that is used in your CD-ROM to protect from eraser.

It's Yeah, as soon as you have K K value from a degree D T minus one polynomial, you can reconstruct the polynomial. So, this is This is the the idea behind this. So, it's used the linearity we have in Schnorr. So, if you look at the formula of the Schnorr generation R is the nonce, SK is the secret key. And the product signature is linear in the secret key. So, basically you replace the secret key by those interpolated points.

So one ancestor was Musig two, which is used in lightning and Ionic. Yeah so for completeness of the slides uh here is the full the full description. And important things we used uh GSS for the DKG. For It means that the initial uh generation of the the shared key, there is no trusted dealers, meaning that any participant uh once Yeah, you have this MPC way to to to generate the initial key.

Uh so, the idea behind this is not to rely on a single for instance a single double other signer. For now, we did the the work for Ledger. In the future, this morning Trezor presented their uh moving to a platform. We could have this in Trezor. And this way if at some point there is some supply chain attack or backdooring by one of the provider, you will still have the security of what is left. Yeah, so uh for for completeness on later, this is the world protocol. Uh this is how it has been implemented uh in uh in the ledger uh the the state machine.

Um yeah, so uh that was for ledger uh soon for uh Trezor. Um but doing all of this, so we have uh we have this working. We have a you know we have the blind signer. One thing is uh when you want to uh have clear signing uh here you have a a a larger constraint uh that is signing all the inputs. And if you look at existing uh uh privacy uh signers for instance Zcash or Namada, um clear signing is not provided uh mainly because Poseidon uh is expensive.

And one way to do this could be to instead of um um computing all the share hash inside the hardware wallet, what we have been doing is implement a verifier, a ZK verifier inside uh the hardware wallet. And once we have this, this means that basically your little uh hardware wallet has unlimited power computation uh for all uh public inputs. So, this is this has been done. Uh this can also solve all the clear signing uh trust issues that we could have uh because right now the 7730 uh initiative is discussed.

Uh the solution um as it is now uh would be to uh implement channels uh between the dapps and the hardware wallets. Uh this is good uh but here again, uh math is easy but key management is hard. Uh I guess we have like this uh resolve uh incident. Uh so, uh we know that we will have still beautiful uh disaster. So, what we could do uh would be to have the clear signing itself being computed outside uh the hardware wallet, having the verifying key inside the contract, so the hardware wallet can compute uh the proof of storage of uh of the circuits.

And then as the as the the statement, this human-readable string correspond to this uh call data uh could be the ZK statement to be verified by the hardware wallet. Meaning some as as as long as you're able to uh prove it, uh you can uh have anything uh been outsourced. Uh whole public input uh can be outsourced of the wallets. So, uh we think this is a huge improvement uh compared to what we have now and the limitations the constrained hardware implies.

Yep. So, to conclude what has been done during these those past 8 months inside Kuaiku. So, we provided the first TSS plus ZK signer complying to RFC RFC 9591 and maybe chip chip. Um we provided uh the first ZK verifier in running fully uh on a secure element. Uh running time is uh 2.8 seconds, so in term of few weeks it's quite acceptable.

Uh if you have ever used either Zcash or StarkNet uh hardware integration, uh yeah, verifying time are very long right now. Um so, we hope to have collaborations on the on the future to to integrate this kind of uh um mechanism uh for a wider use outside of Kuaiku. Yeah, so the next steps generalize the ZK clear signing to maybe more functionalities. Uh this was a obvious first application case.

Explore Stark implementation in hardware because all of this use growth 16. We We will have the Planck a verifier very soon. But it's not post-quantum resistance. Simon will present his text tomorrow, but yeah, we we began to see would it be a possible to streamline a proof generation. Not the That might be Yeah, that might be Yeah. Not sure if it's feasible, but that's something that we are exploring. And there is also another password that we are exploring. Um today uh So, right now there is only Ledger platforms. There will be Trezor, but it

would be good to have a universal VM. Meaning that you don't want to redevelop a new application for every provider. And this is something that it should will present uh in two days. So, if you're interested in integration and exploration, get in touch with us. Um Okay, and I guess that concludes the talk. If you have any question. Do you have any questions?

Nice. Thanks.