cryptoxsystems/pycryptox

Pycryptox feels like a serious and unusually thoughtful security project. The thing that stood out to me first was that the README does not just say “post-quantum encryption” and stop there; it explains the actual threat model the library is trying to serve: password-based encryption through PURPLE, deniable asymmetric encryption through BLUE, threshold encryption through RED, and key storage through Keyx. The BLUE example is especially compelling because it immediately shows the project’s central idea: one encrypted bundle can yield a real message or a credible decoy depending on which private key is used.
The documentation is a major strength. The English docs include installation guidance, architecture, protocol pages, examples, exceptions, and a dedicated security page. I liked that the BLUE documentation walks through attacker reasoning directly, including message-size correlation, timing-oracle concerns, mono-mode detection, and bundle fingerprinting. That makes the project feel much more grounded than many crypto libraries, where the docs often hide behind vague claims. The code also reflects those concerns: PURPLE uses Argon2id with adjustable strength levels and ChaCha20-Poly1305, BLUE routes asymmetric work through ML-KEM-512 and pads messages into buckets, and RED documents its trusted-dealer limitation instead of pretending it is solved.
From an adoption perspective, the API looks approachable for a library doing fairly advanced things. import pycryptox as crx, then crx.purple.encrypt(...), crx.blue.genkeys(...), or crx.red.decrypt(...) is easy to understand, and the versioned protocol design is a smart choice for long-lived encrypted bundles. The included test runner and protocol-specific tests are also encouraging; the README mentions 269 tests, and the tests cover round trips, wrong keys, Unicode, malformed inputs, version migration, async BLUE jobs, and error paths.
The biggest improvement I would suggest is making trust signals more visible for a security-sensitive package. I did not find a standard GitHub Actions workflow, so hosted CI status across Python versions would help a lot. The project also honestly states that it has not had a third-party audit; keeping that warning is good, but adding reproducible test instructions, published audit goals, and maybe a “safe to use for / not safe to use for” section near the top would make adoption easier. The liboqs setup is also inherently heavy, so a small “first install experience” troubleshooting page would help new users get past compiler/CMake friction. Overall, Pycryptox is ambitious, well-documented, and refreshingly explicit about its limits. For a single-maintainer cryptography project, the level of threat-model writing and API discipline is impressive.