python-ecdsa: pure Python signatures for learning and testing

Elliptic curve cryptography you can read in one sitting

python-ecdsa is an easy to use implementation of elliptic curve cryptography written entirely in Python, covering ECDSA for signatures, EdDSA for Edwards curve signatures and ECDH for key agreement. The README describes the workflow it supports: create key pairs with a signing key and a verifying key, sign messages, verify signatures, and agree on a shared secret key from exchanged public keys.

The reason to write this in Python rather than bind to a native library is legibility. The library exists in the ecosystem of tlsfuzzer, the TLS fuzzing project, and the audience it serves is people who want to see what the signature computation actually does rather than trust a binary. The README makes the trade explicit in one line: the keys and signatures are very short, making them easy to handle and incorporate into other protocols.

It is also the kind of library that lets a protocol implementer work without a working C toolchain, which matters on restricted platforms and in test environments where the real crypto provider is unavailable.

The licence position needs a small note. The README states the library is released under the MIT license and points at the license file for details, while the licence field on the GitHub repository is one that GitHub cannot classify, so the LICENSE file is the place to confirm the exact terms rather than the badge.

The last push was on 2026-06-08 and the most recent release is 0.19.2 from 2026-03-26, with 0.19.1 from 2025-03-13 and 0.19.0 from 2024-04-08 behind it.

Which curves are actually implemented

Curve coverage is where a library like this either holds up or does not, and the README is specific.

The core is five NIST Suite B GF(p) prime field curves with key lengths of 192, 224, 256, 384 and 521 bits, identified by the short names the OpenSSL tool lists with openssl ecparam -list_curves: prime192v1, secp224r1, prime256v1, secp384r1 and secp521r1.

Alongside them is the 256-bit curve secp256k1 used by Bitcoin, which is the one most people arrive for. The regular non-twisted variants of the Brainpool curves are supported from 160 to 512 bits, with the names brainpoolP160r1 through brainpoolP512r1. A few small curves from the SEC standard are also included, the README says mainly to speed up testing of the library itself: secp112r1, secp112r2, secp128r1 and secp160r1.

Key generation, signing and verifying are also supported for Ed25519 and Ed448.

The boundary is stated as well: no other curves are included, but the README says it is not too hard to add support for more curves over prime fields. That sentence is the honest description of the project, a finite list of curves with a documented path for extending it, rather than an open ended selection of parameters.

gmpy2 is detected at start-up, six is the only hard dependency

The dependency story is unusually light. The library uses only Python and the six package, and the requirements file contains exactly one line:

six

The packaging metadata agrees, with install_requires set to six>=1.9.0 and two extras declared for the optional native backends:

install_requires=["six>=1.9.0"],
extras_require={"gmpy2": "gmpy2", "gmpy": "gmpy"},

The optional accelerators are worth understanding, because the behaviour changes without any configuration file. If gmpy2 or gmp is installed, they are used for faster arithmetic, and either can be installed after the library itself, since python-ecdsa detects their presence on start-up and uses them automatically. The README recommends gmpy2 on Python 3 for optimal performance.

That detection is convenient and also surprising. A deployment that installs gmpy2 in one environment and not in another silently gets different arithmetic backends and different timings, with no configuration switch and no warning in the documentation. If you benchmark or if you depend on reproducible timing characteristics, pin the backend deliberately rather than letting start-up detection decide.

The package supports Python 2.6, 2.7 and 3.6+, and the README says it also supports execution on alternative implementations like pypy and pypy3. The setup metadata reflects that old range with python_requires set to >=2.6 excluding 3.0 through 3.5, while the classifiers list 3.6 up to 3.13.

Installing from PyPI, with an optional native speedup

The library is on PyPI as ecdsa and the recommended install is pip:

pip install ecdsa

If higher performance is wanted and using native code is not a problem, the README gives two extra variants. The preferred one pulls in gmpy2:

pip install ecdsa[gmpy2]

The second is described as the slower, legacy option and pulls in gmp:

pip install ecdsa[gmpy]

Those two lines are the entire install story for the library itself. There is no build step to run and no system package to configure, which is the main reason to choose a pure Python implementation in the first place.

If you want to see the speed characteristics on your own machine rather than trust a published table, the README points at tox -e speed to generate the table locally. The table it publishes was measured on an Intel Core i7 4790K at 4.0GHz and lists, among other rows, NIST256p key generation at 0.00051s, signing at 0.00054s and verification at 0.00098s, with secp256k1 in the same range. Those are the maintainer's published figures for that machine, not a general guarantee, which is exactly why the tox target exists.

The production warning and how it is tested against OpenSSL

The most important line in the README is a bold note: this library should not be used in production settings, with a pointer to the Security section for details. Everything else in the documentation should be read with that in mind.

A pure Python implementation of elliptic curve arithmetic is where timing and side channel concerns live, and a project that states the limitation plainly is more trustworthy than one that does not mention it. For test suites, fuzzing harnesses, teaching material and protocol prototyping, the warning costs nothing. For signing real transactions or verifying real certificates, it is disqualifying.

The project does put serious effort into correctness verification. To run the OpenSSL compatibility tests, the openssl tool must be in your PATH, and the README lists the releases this library has been tested successfully against: OpenSSL 0.9.8o, 1.0.0a, 1.0.2f, 1.1.1d and 3.0.1, among others.

The repository layout shows the same attitude. Beyond the src/ directory holding the package, there is a docs/ directory, a sql/ directory, tox.ini for the test matrix, conftest.py for pytest configuration, speed.py for the benchmark table, versioneer.py for version derivation from the repository metadata, a NEWS file for the changelog, and a SECURITY.md. The presence of cosmic-ray.toml and cosmic-ray-12way.toml, together with the cosmic-ray shell scripts, shows that mutation testing is part of the workflow, which is a stronger test of a cryptography library than line coverage alone. The README badges track condition coverage and mutation score, along with CodeQL analysis and a gitleaks configuration.

Licence, versions and the shape of a project that predates Python 3

Two practical points about maintenance. The last push was on 2026-06-08, and the release line is at 0.19.2, tagged on 2026-03-26. The version numbering has stayed below 1.0 for a long time, and for a library with a production warning attached that is a signal about intent rather than about quality.

The second point is the Python version floor. The library still declares support for Python 2.6 and 2.7, and it still carries the six compatibility shim as its only required dependency. For a project you intend to adopt today, that compatibility surface is mostly a legacy constraint rather than a feature, but it does explain the shape of the code and the dependency footprint. The README is candid that the library uses only Python and the six package, and the setup metadata lists classifiers for Python 2.6 and 2.7 alongside 3.6 through 3.13.

For anyone integrating it, the licence is the other thing to settle. The README says MIT, and the LICENSE file is the authoritative text that GitHub could not classify on its own. That distinction matters more than usual for a cryptography library, because the licence governs how the code may be redistributed inside a product that does real signing work.

Editorial conclusion

python-ecdsa fits engineers who need readable ECC code for tests, teaching, protocol work or a dependency free environment, since it runs on plain Python with only six required. It does not fit anyone signing real production traffic, because the README states the library should not be used in production settings. Verify first that the curve and algorithm you need are present, that you understand the gmpy2 detection at start-up and what it changes, and that you read the LICENSE file, since GitHub cannot classify the licence on this repository even though the README calls the library MIT.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. tlsfuzzer/python-ecdsa on GitHub