--- tags: pjm, cryptkeeper --- # In zk world , where should we store private keys ? * we are in the very early days of ZK adoption * We should try and grow adoption * Getting product feedback loops started is gonna have a big impact on growing the space * There are many possible futures but an impotant one is wallets focused UX vrs dapp focused UX * This centers around private keys and how they are secured * Privatey key security is super important in the zk world. * The consequences of losing a private key are huge, not only could you impersonate that user you could also berak that users anonimity and if you manage to get a majority of users private keys you could break almost all users anonimity. ## Dapp focused private key storage * in the dapp focused world the dapp in the browser holds the private key in memory * This memory is accessible by java script * Only that dapp can access this private key * This significantly limits interoperability * I can't build a new dapp that uses the same private key wihtout asking the users to share that private key with my acpplicaion, which could tivially copy it. ## Wallet focused private key storage * Instead of having dapps storaging private keys it seems better to user wallets store them * Just like metamask a browser plug that dapps talk to. * This way a dapp will just ask the extension to create a certain proof * If a dapp needs an exotic type of proof this can be a problem for the user extension * Its just like asking metamask to add a new signature scheme * If one "signature scheme" (or ZKP) is broken and leaks the private key then the private key can be found by an attacker * This means that our browser plugin needs to audit every new ZKP they are adding or ask the suers to do this. Sounds like a terrible UX / Devex. Making a new ZKP and then having to convince wallet developers to support it. ## What do we want to hide * The private key, This is the most important thing we want to hide. If an attacker gets this they can imporsonate you and de anonamize you. * The preimage of the nullifier this is globally identifying information. If an attacker gets this they can de anonamize you. * hash of nullifier pre image with external nullifier, This is fine to be public. It is a format of the nullifier that we want public. ## Example plugin architecture * Aggregation is a tool that lets you merge together many zkps. The key part is that it lets us hide data that is being passed between differnt proofs. * We can use aggragation to solve this problem. We can have our browser plugin make a very simple and very secure ZKP and then asllow dapps to aggragate this proof with the proof that does the difficult t * Lets have a single proof that calcualte the hash of the users nullifier with the external nullifier do this in our browser plug in. And let the rest of the logic for apps live inside antoehr proof that the browser creates ## New version of semaphore * The new version of semaphore should be built in a way that takes these applicaions into accound and tries to build a proof that can smooth the UX * The new version of semaphore should try and minimsie crypto assumtions , spefiically it should use traditional hash function to calcualte the hash (nullifier, external nullifier) and where ever else possible. ## Open questions * Is this enough for all the applicaitons we care about ? * WHat does a case study of unirep look like ? * What does a case study of rln look like ? * ZKRSA and ZKecdsa should be used for sign ups