Add ERC: PLUME Signature in Wallets #37
Conversation
Divide-By-0
changed the title
|
The commit 097e64d (as a parent of fe88c0d) contains errors. |
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
I'm waiting on the htmlproofer mess to finish merging. |
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
File
|
eip-review-bot
changed the title
|
|
||
| ## Abstract | ||
|
|
||
| ZK-SNARKs have enabled ideation for new identity applications based on anonymous proof-of-ownership. One of the primary technologies that would enable the jump from existing apps to systems that require anonymous uniqueness is the development of verifiably deterministic signatures. Because we are on ECDSA, there is no way right now for someone to verify that a signature is generated deterministically, even with ‘deterministic’ ECDSA signatures: a ZK-SNARK proof would need someone’s private key to do so, and some hardware wallets do not even allow viewing of a private key. Broadly, we don’t want to export/copy-paste the private key into a SNARK to be an intended user behavior, and most hardware wallets will not be able to run SNARK arithmetization inside a secure enclave for existing schemes (and nor do we want to standardize an entire proof system inside a wallet right now when they emerge and evolve almost every year). Thus we are left to select a new algorithm. |
There was a problem hiding this comment.
| ZK-SNARKs have enabled ideation for new identity applications based on anonymous proof-of-ownership. One of the primary technologies that would enable the jump from existing apps to systems that require anonymous uniqueness is the development of verifiably deterministic signatures. Because we are on ECDSA, there is no way right now for someone to verify that a signature is generated deterministically, even with ‘deterministic’ ECDSA signatures: a ZK-SNARK proof would need someone’s private key to do so, and some hardware wallets do not even allow viewing of a private key. Broadly, we don’t want to export/copy-paste the private key into a SNARK to be an intended user behavior, and most hardware wallets will not be able to run SNARK arithmetization inside a secure enclave for existing schemes (and nor do we want to standardize an entire proof system inside a wallet right now when they emerge and evolve almost every year). Thus we are left to select a new algorithm. | |
| ZK-SNARKs have enabled ideation for new identity applications based on anonymous proof-of-ownership. One of the primary technologies that would enable the jump from existing apps to systems that require anonymous uniqueness is the development of verifiably deterministic signatures. Because Ethereum is based on ECDSA, there is no way right now for someone to verify that a signature is generated deterministically, even with ‘deterministic’ ECDSA signatures: a ZK-SNARK proof would need someone’s private key to do so, and some hardware wallets do not even allow viewing of a private key. Broadly, we don’t want to export/copy-paste the private key into a SNARK to be an intended user behavior, and most hardware wallets will not be able to run SNARK arithmetization inside a secure enclave for existing schemes (and nor do we want to standardize an entire proof system inside a wallet right now when they emerge and evolve almost every year). Thus we are left to select a new algorithm. |
|
|
||
| ### Parameters | ||
|
|
||
| This scheme uses the secp256k1 curve, defined in SEC 2: Recommended Elliptic Curve Domain Parameters v2, page 9. |
There was a problem hiding this comment.
We don't permit external links (except as documented in EIP-1.)
This particular PDF has a very permissive license, so I'd recommend copying it into your assets directory (../assets/erc-7542/) and linking to it there.
There was a problem hiding this comment.
I had to change erc > eip to avoid error. Filed an issue: #243
Error for context:
* At ./_site/EIPS/eip-7524.html:252:
internally linking to ../assets/erc-7524/sec2-v2.pdf, which does not exist
* At ./_site/EIPS/eip-7524.html:281:
internally linking to ../assets/erc-7524/sec1-v2.pdf, which does not exist
I get this issue from HTMLProofer when referring to the erc-x folder.
|
|
||
| ### SEC1 | ||
|
|
||
| This scheme uses the SEC1 elliptic curve point encoding scheme defined in SEC 1: Elliptic Curve Cryptography v2 . Point compression is used. We use the notation $\mathsf{sec1}(pk)$ to denote the compressed encoding of secp256k1 curve point $pk$ as a bytestring of length 33. |
There was a problem hiding this comment.
Similarly, please put a copy of this PDF in your assets directory.
|
|
||
| **SHA256** | ||
|
|
||
| This scheme uses the SHA256 hash function defined in IETF RFC4634. |
There was a problem hiding this comment.
We do allow links to RFCs:
| This scheme uses the SHA256 hash function defined in IETF RFC4634. | |
| This scheme uses the SHA256 hash function defined in [RFC 4634](https://www.rfc-editor.org/rfc/rfc4634). |
|
|
||
| ### Hash-to-curve | ||
|
|
||
| We use the notation $\mathsf{htc}([a_1, ..., a_n])$ to denote the elliptic curve point which is the result of the `secp256k1_XMD:SHA-256_SSWU_RO_ (IETF Draft draft-irtf-cfrg-hash-to-curve-16 Appendix J.8.1)` hash-to-curve algorithm over the concatentation of $n$ values $a_1, ..., a_n$. |
There was a problem hiding this comment.
Can this reference be replaced with https://www.rfc-editor.org/rfc/rfc9380?
|
|
||
| ## Security Considerations | ||
|
|
||
| There are formal proofs of this specific algorithm’s cryptography in a PLUME paper. The theory has been published, and implementations have had one internal round of audit, but they have not end-to-end been formally verified or audited yet, although empirically they correctly conform to the spec laid out. We invite folks in our discussion thread to help surface more possible ways the scheme can be misused in practice. |
There was a problem hiding this comment.
Either cite this PLUME paper (see my earlier comment for an example; this comes in handy if you have a BIB file), or remove this external link.
|
|
||
| ## Security Considerations | ||
|
|
||
| There are formal proofs of this specific algorithm’s cryptography in a PLUME paper. The theory has been published, and implementations have had one internal round of audit, but they have not end-to-end been formally verified or audited yet, although empirically they correctly conform to the spec laid out. We invite folks in our discussion thread to help surface more possible ways the scheme can be misused in practice. |
There was a problem hiding this comment.
Proposals should be written so that they make sense once they move to the Final status.
| There are formal proofs of this specific algorithm’s cryptography in a PLUME paper. The theory has been published, and implementations have had one internal round of audit, but they have not end-to-end been formally verified or audited yet, although empirically they correctly conform to the spec laid out. We invite folks in our discussion thread to help surface more possible ways the scheme can be misused in practice. | |
| There are formal proofs of this specific algorithm’s cryptography in a PLUME paper. The theory has been published, and implementations have had one internal round of audit, but they have not end-to-end been formally verified or audited yet, although empirically they correctly conform to the spec laid out. |
|
|
||
| **The Interactivity-Quantum Secrecy Tradeoff** | ||
|
|
||
| Note that in the far future, once quantum computers can break ECDSA keypair security, most Ethereum keypairs will be broken, but migration to a quantum-resistant keypair in advance will keep active funds safe. Specifically, people can merely sign messages committing to new quantum-resistant keypairs (or just higher-bit keypairs on similar algorithms), and the canonical chain can fork to make such keypairs valid. ZK-SNARKs become forgeable, but yet secret data in past proofs still cannot ever be revealed. In the best case, the chain should be able to continue without a hitch. |
There was a problem hiding this comment.
[...] but yet secret data in past proofs still cannot ever be revealed.
This bit is slightly confusing.
| ### Additional Reading | ||
|
|
||
| We recommend reading the original paper, the PLUME Blog Post, the PLUME Slide Deck, and the ZK Nullifer (PLUME) Presentation at ZKSummit. |
There was a problem hiding this comment.
| ### Additional Reading | |
| We recommend reading the original paper, the PLUME Blog Post, the PLUME Slide Deck, and the ZK Nullifer (PLUME) Presentation at ZKSummit. |
Please remove this section.
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via CC0. |
There was a problem hiding this comment.
| Copyright and related rights waived via CC0. | |
| Copyright and related rights waived via [CC0](../LICENSE.md). |
Please use the exact copyright notice from the template.
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
|
Hey! We are still working on this, but I do not have the permissions to re-open it. @SamWilsn |
There was a problem hiding this comment.
Implemented all of Sam's changes! Till then, the PR with those changes is at #242.
Really? That's infuriating. I'll look into it. |
|
Aaron Thornton |
ERC 7524
Ethmagicians Discussion: https://ethereum-magicians.org/t/erc-7524-plume-signature-in-wallets/15902
Moved to #242.
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:
The PR edits only existing draft PRs.
The build passes.
Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
If matching on email address, the email address is the one publicly listed on your GitHub profile.