# Semaphore proof plugin system case studies https://hackmd.io/@OFccBlU5TNCiRhpIyT1m7g/By4APtMis Current applications force users to put in their private keys or Semaphore's identity secret informations into the circuit. It's quite vulnerable cause most of the applications are hosted on web browser, and access user's private information. If we can generate Semaphore proof, or all kinds of proofs that require our secret informations, from Crypt-Keeper(secure wallet), and then aggregate the proof in application's circuit, it would be more safe and will give good experiences for users. We studied the use cases for this new idea, and as the following: - voting voting is one of the most important applications for Semaphore. However if we generate the Semaphore proof and sign the message for voting (e.g. with ECDSA) in Crypt-Keeper, and then send the message to the application circuit, then it makes the privacy leak. We should reveal the public key to verify the signature. If someone can hyjack the signatures sent from the voting applications, then they are not able to know their private key, however they will know which voters has voted for specific options. - Unirep - Unirep uses Semaphore circuit as a part of their circuit. - the new scheme will make Unirep more secure. - Unirep’s business logic requires the user’s identity secret information. Unirep generates epoch_key from user’s (identity_secret, epoch, nonce) for **every epoch**. Users should provide their identity secret to the unirep circuit **even if** we seperate Semaphore part from Unirep. - In order to resolve this, Semaphore should generate additional identity per app, to be used in app's business logic. It's kind of the weak version of user's identity secret. This will cause the changes to Semaphore protocol spec. - RLN RLN is spam-preventing protocol. The proving speed is crucial for RLN, however the aggregating semaphore proof in RLN circuit will make the proving speed slower. # Conclusion Single zkSNARK circuit hides every values that live inside the circuit(except for public values). This is really powerful for security and privacy. If we seperate the circuits into two parts, this will expose a single point where the privacy leak can occur.(as we saw in voting) Also, as in the case of Unirep, even the business logic can rely on user's secret information. In current status, we should search more use cases that require this scheme before making the change to Semaphore.