search

decred / dcrd

Decred daemon in Go (golang).
https://decred.org
ISC License
737 stars 291 forks source link

dcrec: switch from github.com/agl/ed25519 to filippo.io/edwards25519 #3272

Closed teknico closed 4 months ago

teknico commented 4 months ago

The dcrec/edwards module uses a 2017 commit of the github.com/agl/ed25519 library. This library is unmaintained: in 2020 its repo has been emptied, after the Go 1.13 standard library gained the crypto/ed25519 package.

Unfortunately the stdlib edwards25519 package is internal and cannot be accessed directly. The suggested alternative is to use the filippo.io/edwards25519 library. It contains a superset of the same code in the stdlib, and its field package is directly accessible.

The author is Filippo Valsorda, maintainer of the crypto code in the Go stdlib. It is described as a "safer, faster, and more powerful alternative".

It is safer because it was validated using the github.com/mit-plv/fiat-crypto formal proof tool.

It is faster because it was optimized with assembly code using the github.com/mmcloughlin/avo tool. The same tool is used by the lukechampine.blake3 library, recently introduced to dcrd.

More details:

A Wide Reduction Trick Planning Go 1.20 Cryptography Work

It requires Go 1.20. The dcrutil and txscript modules import dcrec/edwards directly, and eight more use it indirectly: they will all need Go 1.20. (Currently the dcrd module requires Go 1.19, and all the others require Go 1.17).

The API of this new library is somewhat different from the previous one. I'm adapting the dcrec/edwards code, I'll have benchmarks once I'm done.

jrick commented 4 months ago

that ed25519 package has a known bug in it, but we are stuck with it currently because it is part of consensus (script validation). it's intentionally kept at that old version.

davecgh commented 4 months ago

@jrick beat me to it, but unfortunately we can't update it because it would potentially cause old coins to become unspendable due to the known bug.

We'd have to introduce a new script version with a new address scheme to be able to use it and even then we would still need the old version to validate v0 scripts.

Aside from that, I would definitely agree and like to use a better edwards package. In fact, I'd prefer to use ristretto255 over ed25519 when updating too because ristretto255 avoids a lot of pitfalls present with ed25519 when trying to use it in higher level protocols such as hd key generation.

teknico commented 4 months ago

Good to know, thanks. I’ll pause this work.