Charm is a Python framework for prototyping advanced cryptosystems

The hybrid design is the whole idea

Charm is described as a framework for rapidly prototyping advanced cryptosystems, designed from the ground up to minimise development time and code complexity while promoting the reuse of components. The architectural decision that makes it work is the hybrid one. Performance-intensive mathematical operations are implemented in native C modules, while the cryptosystems themselves are written in a readable, high-level language. In practice that means a scheme written in Charm reads like a description of the scheme, with the group and field operations delegated to the C layer, and the same building blocks are reused across schemes instead of each one reimplementing pairing arithmetic. For a research audience that is the point, because a paper's construction can be transcribed rather than translated into C. The package is published on PyPI as charm-crypto-framework, the author and maintainer is J. Ayo Akinyele of Johns Hopkins, and the default branch is dev rather than main.

The scheme catalogue is unusually wide for a Python library

The feature list in the README is a catalogue of implemented schemes, and it is where a researcher would look first. Attribute-based encryption is the largest group, with cipher-policy ABE covering BSW07, Waters09 and FAME, key-policy ABE covering LSW08 and GPSW06, and multi-authority and decentralized variants. Identity-based encryption follows, with Waters05, Boneh-Boyen, Boneh-Franklin. Pairing-based cryptography has BN254 and BLS12-381 curve support at roughly 128-bit security, using the PBC library. Digital signatures cover pairing-based schemes including BLS, elliptic curve schemes including ECDSA, Schnorr and EdDSA, standard RSA, DSA and Lamport, and aggregation schemes including BLS aggregation and MuSig. Public-key encryption includes ElGamal, RSA, Paillier and Cramer-Shoup. The catalogue is what makes this a framework rather than a wrapper, because the components are meant to be combined into protocols that do not exist yet.

Threshold ECDSA and the ZKP compiler are the production-grade parts

Two subsystems carry explicit production claims, and they are the parts a practitioner would reach for first. Threshold ECDSA is described as production-ready t-of-n distributed signing, with three protocols: GG18, the classic Paillier-based construction from 2018, CGGMP21, which is UC-secure with identifiable aborts, and DKLS23, which offers non-interactive presigning with OT-based multiplication. The library supports secp256k1, the curve used by Bitcoin and XRP Ledger, among others. The zero-knowledge subsystem includes a compiler described as production-ready for both interactive and non-interactive proofs, covering Schnorr proofs, discrete log equality, knowledge of representation proofs, AND and OR composition for compound statements, range proofs via bit decomposition, and batch verification. A protocol engine sits alongside it to simplify multi-party protocol implementation, and a C and C++ embed API lets native applications embed Charm through the Python C API.

Post-quantum schemes are an optional module with caveats

The newest release adds a lattice-based section, and the README is careful about its status. It is marked as an optional module backed by NTL, with NTL 11.0 or newer required, and the schemes are described as simplified: a Kyber-style KEM as a simplified ML-KEM and FIPS 203, Dilithium-style signatures as a simplified ML-DSA and FIPS 204, Ring-LWE public key encryption, and lattice-based identity-based encryption. The underlying arithmetic is polynomial ring arithmetic in R_q = Z_q[X]/(X^n+1), which is the standard structure for this family. The word simplified is doing real work in those descriptions, and a reader who needs actual FIPS 203 conformance should not assume the label means certified. The optional framing is also practical: NTL is an extra system dependency that the default install does not require, and the build switches it on with a configure flag and an environment variable at install time.

Installing means native libraries first, and the script handles it

The install story is where most of the friction lives, and the README is direct about the order of operations. The one-line install pipes an install script into bash, and the script handles all system dependencies:

curl -sSL https://raw.githubusercontent.com/JHUISI/charm/dev/install.sh | bash

@@C1@@The script has modes, and the flags are worth reading before you run it. The default installs from PyPI, the from-source mode is for development, the deps-only mode installs just the system libraries for a manual pip install, and there is a help option that lists them all. The pip path on its own is short, but the README carries a note that the system libraries must be installed first, and they are specific.

sudo apt-get install libgmp-dev libssl-dev libpbc-dev flex bison

GMP 5.0 or newer for arbitrary precision arithmetic, PBC 1.0.0 for pairing-based cryptography, OpenSSL 3.0 or newer for the primitives, and NTL 11.0 or newer for the optional lattice module. PBC and NTL both have from-source recipes because they are not in every package manager.

Building from source has a configure script and a lattice switch

The development path is the standard three steps, and it differs from the pip install in one important way, because the native modules are compiled as part of it:

git clone https://github.com/JHUISI/charm.git
cd charm
./configure.sh  # add --enable-darwin on macOS
pip install -e ".[dev]"

@@C2@@The configure script takes an enable-darwin flag for macOS and an enable-lattice flag that turns on the optional module, and the lattice install additionally needs LAT_MOD set in the environment. That environment variable is the detail to remember, since a build that enables the module but leaves the variable unset will not produce the lattice components. The verification step is a one-line import of a pairing group object, and the project ships several Dockerfiles, including ones that build and test the install on Arch and Fedora, which tells you the maintainers expect the dependency matrix to be the hard part of this project rather than the Python code.

The test suite is split by subsystem, and the licence is LGPL-3.0

The testing section is worth reading because it shows how the project is organised. There is an all-tests target and then separate targets for unit tests covering the toolbox, serialisation and vectors, cryptographic scheme tests, the ZKP compiler tests, adapter tests and the embed API tests. The threshold ECDSA tests are singled out and can be run for the three protocols by name, and coverage is available through pytest with a coverage flag over the charm test directory. The repository root shows the shape of the project: the charm/ package, an embed/ directory for the C API, an examples/ directory with an XRPL memo demo, a deps/ directory, a doc/ and docs/ directory, a configure.sh, a setup.py with the extension build logic, a Dockerfile per platform and an install.sh with per-platform installers. The project is licensed LGPL-3.0 with the licence text in LICENSE.txt, and the package classifiers mark it as a beta with an intended audience of developers and researchers. The recent releases show the pace: v0.63 adding the lattice-based module, v0.61.0 adding Python 3.13 and 3.14 support, and v0.60 in January 2026.

Editorial conclusion

Charm suits a cryptography researcher or a graduate student who needs to build a new scheme or protocol and read the maths rather than call an opaque library, and who is comfortable with native toolchains and pipelining GMP, PBC and OpenSSL into a working environment. It does not suit an application team that wants a vetted, production-cryptography dependency, since the package is classified as a beta and the README labels several schemes as simplified, and it does not suit a machine without a compiler, because the Python install still needs the native libraries built. Before adopting, install the system prerequisites first, since the pip path assumes GMP, PBC and OpenSSL are already present, and note that the last push to the repository was on 2026-09-10 with v0.63 adding the lattice-based module.

Frequently asked questions

Official sources

1. JHUISI/charm on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases