-
Notifications
You must be signed in to change notification settings - Fork 1.7k
[WIP] add ed25519 signature verification precompile #8330
Conversation
It looks like @oberstet hasn't signed our Contributor License Agreement, yet.
You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io Once you've signed, plesae reply to this thread with Many thanks, Parity Technologies CLA Bot |
[clabot:check] |
It looks like @oberstet signed our Contributor License Agreement. 👍 Many thanks, Parity Technologies CLA Bot |
@oberstet Hey, is this still WIP? |
@5chdn yeah, definitely! well, I am willing to do more work, but I am stuck on getting some guidance / decision. as described here https://gitter.im/ethereum/AllCoreDevs?at=5ad2e7587c3a01610de35a31, the main options for the ed25519 library we could use are
I think the latter would be a robust, conservative and practical choice, and I would rewrite/expand the PRs (not only this here) - if there is support. If not, this is just a waste of time .. |
Just a note, as we can always do this later once the actual spec settled down: Do we consider using the dalek version (https://github.com/dalek-cryptography/ed25519-dalek)? It indeed has less peer reviews but is pure Rust. If we can at least provide a feature flag to enable that version, that would be cool! |
@sorpaas I am a Rust newbie, don't know the community/ecosystem much, so take this with a grain of salt:
The library you link: https://github.com/dalek-cryptography/ed25519-dalek#warnings => is using https://github.com/isislovecruft/curve25519-dalek for curce 25519 math - and that lib is quite new. and while Isis (https://github.com/isislovecruft) is certainly super cool dev, mmmh. If you ask me right away, what to go for, I would only consider libsodium and HACL. Eg if we fuck this up, and it is because we have chosen some "random code from the Web", users will be angry. Righly so. In that light, I could only continue sleeping well choosing sth that can be defended - the choice (if there is an issue .. which always can happen). |
Rgd compile switch to swap the actual implementation being used: could do, question is why? for "regular" use, implementations will behave identical .. the problem is the corner cases: does the elliptic curve math implementation fall apart for certain corner cases? testing this using a handful of test vectors is not enough. and because that is tricky, I'd rather rely on ideally one underlying implementation for all the Eth clients. From how I understood the discussion that happened on Gitter channel, this is also what others hinted at (to address the "consensus failure" catastrophic scenario). |
Hi @oberstet - are you still working on this? |
Marking this as stale. Happy to reopen this whenever you get back to it. 🤗 |
See also:
TODO: fill in test vectors in unit test