u/Mister_ZE

Hello everyone.

I just created a new cryptography library called Pycryptox.

I'd like your feedback on its DX. Is it pleasant to code with my library? Is it easy? Is it practical and intuitive?

I think a library with good DX is extremely important.

However, comments beyond these questions would also be welcome.

Link to the GitHub repository (main): https://github.com/Mister-ZE/pycryptox

PS: My documentation is available in two languages: English and French!

Hi all,

I'm a self-taught amateur and I've just published (yesterday) a Python library called pycryptox on PyPI (v1.0.1, Beta classifier — explicitly because I want critical review before anyone treats this as production-ready). No users yet. I'd rather get torn apart now than ship something dangerous later.

The library wraps standard primitives — ML-KEM-512 (via liboqs), ChaCha20-Poly1305 (via pyca/cryptography), Argon2id (via argon2-cffi) — into four protocols:

PURPLE : password-based encryption (Argon2id + ChaCha20-Poly1305)
BLUE : asymmetric with plausible deniability (custom construction, see below)
RED : t-of-n threshold via Shamir GF(256) over the ML-KEM-512 private key
YELLOW : placeholder for steganography (not implemented yet)

Plus an encrypted keystore system (keyx) using PURPLE.

What I believe is standard and probably fine (verify anyway): KEM-DEM internally, Argon2id at m=64 MB / t=2 / p=2 / type ID, secrets/os.urandom for randomness, AEAD via pyca's ChaCha20Poly1305, atomic keystore writes (tempfile + fsync + os.replace), Shamir reconstruction via Lagrange at x=0 in GF(256).

What I'd most appreciate scrutiny on, these are custom and I have no formal proof:

1. BLUE deniability construction. Two ML-KEM-512 channels (x, y). Each message is padded to a fixed bucket size, encrypted via the internal KEM-DEM, then the resulting bytes are scattered pseudo-randomly through a single buffer along with random noise. Position vectors ("chemkeys") are themselves encrypted under each channel's pubkey. In mono mode (only one real message), the other channel uses an ephemeral key destroyed after use. I claim this gives plausible deniability against an adversary who only sees the bundle. Is this reducible to a known scheme? Are there obvious distinguishing attacks I'm missing?
2. Open design question on keystore format. .keys and .ckeys keystores currently use distinct on-disk magic bytes (CRXKX_BLUEKEYS_1 vs CRXKX_BLUECKEY_1). One reviewer argued this leaks "this is a deniable keystore" to forensic triage. My counter-argument: any serious user keeps .ckeys off their primary device anyway, and existence-hiding is properly done by outer layers like VeraCrypt — so the on-disk format distinction is moot under a realistic threat model. Which view holds up? Genuine open question — happy to unify the magic bytes in v1.1 if the consensus says I'm wrong.
3. BLUE noise is not authenticated. Noise bytes mixed into the bundle are outside the AEAD scope. A decryption oracle could in principle map chemkey positions over many trials. I document this in source and in security.md. Is this acceptable for the at-rest use case I'm targeting, or does the oracle threat extend further than I think?

Self-acknowledged limitations: no third-party audit, single author, published today, no users yet, ML-KEM-512 only (NIST level 1), max BLUE message 1 MB in v1.0, RED is trusted-dealer (no MPC keygen yet), Python memory zeroization is symbolic only.

Links:

• GitHub: github.com/Mister-ZE/pycryptox
• PyPI: pypi.org/project/pycryptox
• Docs (EN): github.com/Mister-ZE/pycryptox/tree/main/pycryptox/documentation/en

If this post isn't an appropriate fit for the sub, please redirect rather than just removing — I genuinely want feedback and will take it anywhere it's offered. Harsh is fine. Thanks.