Published kernelsalpha
The kernel packages the moxzi project publishes, what each provides, and the state of their review.
These packages are built, reviewed and pinned by the moxzi project; their source is public at icdevsorg/moxzi-kernels (MIT OR Apache-2.0), maintained by ICDevs.org. At their released pins they're tier-1: they build without asking you to accept them. Opt in as described in Using kernels.
Packages#
| Package | Provides |
|---|---|
moxzi-hash | SHA-256, SHA-512, HMAC-SHA-256, HMAC-SHA-512, RIPEMD-160, BLAKE3 (plain and keyed) |
moxzi-secp256k1 | Keys, point arithmetic, ECDSA with RFC 6979 nonces, BIP340 Schnorr signatures, key tweaks, DER signatures |
moxzi-p256 | NIST P-256 keys, ECDSA with RFC 6979 nonces, DER signatures |
moxzi-ed25519 | Ed25519 keys, signing and strict verification (RFC 8032) |
moxzi-bls12-381 | Ethereum BLS signatures (verify, proof of possession, aggregates), G1 and G2 arithmetic and multi-scalar multiplication, RFC 9380 hash-to-curve, pairing checks |
moxzi-ml-dsa | ML-DSA-44 (FIPS 204) keys, signing and verification |
moxzi-rsa | RSA-3072 PSS signatures with SHA-256. Rsa3072.sign has no Motoko body: without the kernel it traps |
moxzi-base58 | Base58 and Base58Check |
moxzi-bech32 | Bech32 and Bech32m, bit regrouping, segwit addresses |
moxzi-bitcoin | Bitcoin hashes, addresses, BIP32 public derivation, scripts, transaction signature hashes |
ic-agent | The BLS signature check behind certificate verification |
Every function with a kernel also has a Motoko body (except Rsa3072.sign), and the two give the same results.
Security status#
Most of the cryptography in the kernels comes from published Rust crates, used unmodified. Some was written for these kernels: the Montgomery arithmetic and CRT signing in moxzi-rsa, the fixed-base tables and point addition used for keys and signatures in moxzi-secp256k1 and moxzi-p256, and P-256 verification. That code has had automated adversarial review, checks of the compiled wasm for branches and memory accesses that depend on secrets, and differential tests against reference implementations and official test vectors. It hasn't had an independent audit by cryptography experts. Until it has, don't use moxzi-rsa, moxzi-secp256k1 or moxzi-p256 to protect significant value.
Known limitations:
| Limitation | Detail |
|---|---|
| ML-DSA signing time varies | FIPS 204 signing retries until a candidate signature passes its checks, so the time depends on the key and message. The standard is designed this way; the rejected candidates don't reveal the key |
| RSA signing accepts only standard 3072-bit keys | The key needs two primes of exactly 1,536 bits and reduced CRT parameters, as every 3072-bit key from OpenSSL or Node has. Other keys trap with Rsa3072.sign: key shape not supported |
| RUSTSEC-2026-0387 (crypto-bigint) | moxzi-secp256k1 and moxzi-p256 use a crypto-bigint version with this advisory: compiled code can branch on secret values. The compiled kernels are checked instead. The one such branch they contain never sees a zero scalar, so its timing doesn't vary. The kernels don't use a fixed crypto-bigint yet |
| Young and unmaintained crates | moxzi-ml-dsa uses libcrux-ml-dsa, which hasn't reached 1.0. moxzi-secp256k1 uses the field arithmetic of libsecp256k1-core, which is no longer maintained |
| Secrets stay in memory | Kernel scratch memory is reclaimed by the garbage collector, not erased, so copies of a secret key remain until the memory is reused. On the Internet Computer, node providers can read canister memory in any case |