CPace
Python implementation of CPace, the balanced composable password-authenticated key exchange (PAKE) recommended by the CFRG, in its CPACE-X25519-SHA512 cipher suite, with the draft's optional explicit mutual key confirmation.
A PAKE lets two parties who share a low-entropy secret (a PIN, a short password) derive a strong shared key over an insecure channel, such that an active attacker gets exactly one online password guess per protocol run and learns nothing usable for offline brute-force.
Implemented and reviewed against draft-irtf-cfrg-cpace revision 21; all known-answer tests from the draft's testvectors.json pass, including the full invalid-point rejection set.
Install
pip install cpace
Security considerations
- Anonymous unless you supply identities. With the default empty
ad/peer_ad, a verifying confirmation tag proves the peer used the same password — not which peer. To authenticate identities, bind them intociand/orad/peer_ad; what an identity is and how it is checked is the application's responsibility — the library only guarantees the run fails unless both sides agree on the bytes. As a baseline,verify()rejects a peer that merely reflects your own share and tag back, so confirmation cannot be satisfied by echoing your own messages. - Timing side channels. The password-dependent Elligator2 map is branchless (no secret-dependent branches or memory indexing), but it runs on CPython big integers, whose arithmetic is not constant-time. The draft requires the mapping to execute in constant time; that guarantee is not achievable in pure Python. This is a deliberate trade-off: it is fine for rate-limited, short-lived secrets (device-pairing PINs with attempt lockout), but reconsider before using this library with long-term passwords against an attacker who can precisely time your process (e.g. co-located on the same host).
- No secret zeroization. Python's memory model does not allow reliably wiping the scalar, ISK, or password copies from memory.
Scope
Only the CPACE-X25519-SHA512 suite in initiator-responder mode is implemented. Symmetric (unordered) mode and the other cipher suites from the draft are out of scope for now.
Metadata
Release files for cpace 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| cpace-0.1.0.tar.gz | 60.4 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| cpace-0.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 69.9 kB
Release files / cpace-0.1.0.tar.gz
| Download URL | cpace-0.1.0.tar.gz |
|---|---|
| Size | 60.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
049d30b4389c965cb2d98551f2f7361382bfa342afc5d53b6dc16b84a5759ad2
|
|
BLAKE2b-256 checksum How to use checksums |
02e90aa114fdf26b4112222ddbfd190197aa5d11bce21b4747cc1889998eead5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 13, 2026.
Transparency logRelease files / cpace-0.1.0-py3-none-any.whl
| Download URL | cpace-0.1.0-py3-none-any.whl |
|---|---|
| Size | 9.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
9fabb60a711a85934225be4081b3f5994e1ca4cd1335c5b9171770c8f1a2fda3
|
|
BLAKE2b-256 checksum How to use checksums |
fae8949c45844ad0d65d0112c2c4fa11cc8a7c4359fe2a20667e00c930860bef
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 13, 2026.
Transparency log