Security Model

libcrypto is used by wallets, exchanges, and infrastructure that handle real funds. This page describes what the library guarantees, what it does not, and how to use it safely.

What the library guarantees

  • Correct, standard output. Every address, key, signature, and hash is validated against published test vectors (BIP32, BIP39, RFC 6979, EIP-55, EIP-191, Bech32/Bech32m, Base58Check, Keccak-256, RIPEMD-160).
  • Correct primitives per chain. Ethereum/TRON use true Keccak-256, never SHA3-256. Signatures are canonical low-S by default to avoid malleability.
  • No hidden dependencies. There are no third-party runtime dependencies and no network access. All computation is local and auditable.
  • Deterministic behavior. Signing uses RFC 6979 deterministic nonces, so the same key and message always produce the same signature.

What the library does not do

  • It does not manage key storage, encryption at rest, or secure memory wiping. Keys live in ordinary Python objects and integers.
  • It does not provide constant-time guarantees against local side-channel attackers. The pure-Python big-integer arithmetic is not hardened against timing analysis. Do not run key operations on hardware shared with untrusted tenants when timing side channels are part of your threat model.
  • It does not protect you from unsafe operational practices (logging keys, committing secrets, weak randomness sources on broken platforms).

Randomness

Private keys and mnemonics use os.urandom, the operating system CSPRNG, via a rejection sampler that stays within the valid secp256k1 range. Ensure your platform's entropy source is healthy.

Operational rules

  • Never commit or log private keys, mnemonics, WIF keys, or seed material.
  • Never send private keys to remote services.
  • Only export xpub (never xprv) to online or third-party systems.
  • Keep account roots hardened so a leaked xpub cannot compromise the parent key.
  • Prefer offline execution for key generation and signing of high-value assets.
  • Always verify address output with independent test vectors before integrating into high-value systems.
  • Treat any CSV/JSON/text file containing keys as top-secret data.

Reporting a vulnerability

Report suspected security issues privately to the maintainer at pymmdrza@gmail.com rather than opening a public issue. Include a minimal reproduction and the affected version.

Disclaimer

This software is provided for development, research, and infrastructure use. Cryptocurrency key handling is security-critical. The authors and contributors are not responsible for lost funds, insecure deployments, compromised keys, incorrect integrations, or misuse of the library. Always test carefully before production use.