npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@lib-q/ml-kem

v0.0.7

Published

NIST ML-KEM (Module-Lattice-based Key Encapsulation Mechanism) for Node.js

Readme

lib-Q ML-KEM - Module-Lattice-Based Key-Encapsulation Mechanism

Pure Rust implementation of the Module-Lattice-Based Key-Encapsulation Mechanism Standard (formerly known as Kyber) as described in FIPS 203 (final).

About

ML-KEM is an algorithm which uses public-key cryptography to securely transfer a symmetric key between two parties who want to establish encrypted communications with each other. It uses algorithms which resist potential attacks by hypothetical future quantum computers which, when such computers are sufficiently mature, pose a problem for the algorithms we typically use for secure key establishment using public-key cryptography such as (EC)DH and RSA key encipherment.

Originally developed as CRYSTALS-Kyber (a.k.a. "Kyber"), ML-KEM is a refinement of the original Kyber algorithm after it was selected for standardization by NIST's Post-Quantum Cryptography (PQC) competition. The Kyber algorithm received considerable feedback as part of the standardization process and as such, ML-KEM includes many changes from the original Kyber. It can be thought of as the official successor of Kyber.

In summary, ML-KEM stands at the forefront of post-quantum cryptography, offering enhanced security and efficiency in key encapsulation mechanisms to safeguard sensitive communications in an era where quantum computers potentially pose a looming threat.

Security implementation

  • Infallible operations on public paths where the design allows it, plus strict size checks on wire objects.
  • Constant-time intent on sensitive comparisons and decapsulation logic; full guarantees require target-specific review.
  • Optional hardening — feature hardened (see Cargo.toml): atomic gate enabling masking, NTT randomisation, and subtle comparisons; pairs with random and getrandom. Do not split the feature set.
  • Screening — workspace crate lib-q-sca-test can run TVLA/timing-style checks against hardened code paths (lab / CI smoke, not a certification).

This crate has not been independently audited; see the warning below.

Usage

This crate is primarily used as a dependency for lib-q-kem. For direct usage:

// Doctest temporarily disabled due to complex trait import resolution
// The functionality works correctly as demonstrated by unit tests
//
// To use ML-KEM:
// 1. Add lib_q_ml_kem to your Cargo.toml
// 2. Use the appropriate ML-KEM variant (MlKem512, MlKem768, MlKem1024)
// 3. Generate keypairs and perform encapsulation/decapsulation

Supported Algorithms

| Algorithm | Security Level | Public Key Size | Secret Key Size | Ciphertext Size | |-----------|----------------|-----------------|-----------------|-----------------| | ML-KEM 512 | Level 1 (128-bit) | 800 bytes | 1,632 bytes | 768 bytes | | ML-KEM 768 | Level 3 (192-bit) | 1,184 bytes | 2,400 bytes | 1,088 bytes | | ML-KEM 1024 | Level 5 (256-bit) | 1,568 bytes | 3,168 bytes | 1,568 bytes |

All algorithms produce a 32-byte shared secret.

Features

  • deterministic — deterministic encapsulation for testing.
  • random — wiring to lib-q-random for implementations that need it.
  • std — compatibility flag (the crate is already usable with std without it).
  • wasmwasm-bindgen exports where enabled.
  • hardened — side-channel-oriented hardening (see above); enable only as a complete feature set.

The zeroize crate is always linked: EncodedSizeUser::as_bytes returns zeroize::Zeroizing stack buffers so serialized key material is cleared when the value is dropped, and ephemeral secrets such as SecretB32 use the same mechanism.

Default feature set is std; enable what your integration needs (CI often adds random).

WASM / JavaScript (wasm feature)

ml_kem_generate_keypair, ml_kem_encapsulate, and ml_kem_decapsulate expose decapsulation keys and shared secrets to JS as Uint8Array (not owned Vec<u8> through the bindgen boundary). Rust stores those fields in Zeroizing buffers. Callers must still overwrite or discard sensitive Uint8Array values in JavaScript after use (for example fill(0)); Rust cannot erase the JS heap once bytes have crossed the boundary.

Testing

# Run all tests
cargo test

# Run with specific features
cargo test --features deterministic

# Run benchmarks
cargo bench

Security Warning

The implementation contained in this crate has never been independently audited!

USE AT YOUR OWN RISK!

However, this implementation follows the practices outlined above.

Related crates

License

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Subresource integrity (SHA-384)

Paths in integrity-manifest.json are relative to the package root (including web/ and nodejs/ when both ship).