ML-DSA-44

ML-DSA44 (Module-Lattice Digital Signature Algorithm, Security Level 2) is the post-quantum signature scheme used throughout Armchain. It's standardized by NIST in FIPS 204.

This page covers the algorithm's parameters, performance characteristics, and how it's used in Armchain. You don't need to understand lattice math to build on Armchain (the SDK handles all of this), but this background is useful if you're curious about the cryptographic foundations.

Algorithm Overview

ML-DSA is a lattice-based signature scheme derived from CRYSTALS-Dilithium. Its security relies on the hardness of the Module Learning With Errors (MLWE) problem, a problem believed to be hard for both classical and quantum computers.

How Lattice Signatures Work (Simplified)

1. Key Generation: Create a matrix A and vectors s₁, s₂ with small coefficients. The public key includes A and t = As₁ + s₂

2. Signing: Use rejection sampling to produce a signature z and a hint h that don't leak information about the secret key

3. Verification: Check that the signature is consistent with the public key and the message hash

The security guarantee: recovering s₁ from A and t requires solving MLWE, which no known quantum algorithm can do efficiently.

Parameters (ML-DSA44)

Parameter	Value	Description
Security Level	NIST Category 2	~128-bit classical + quantum security
Private Key Size	2,560 bytes	Full secret key material
Public Key Size	1,312 bytes	Verification key
Raw Signature Size	2,420 bytes	ML-DSA44 detached signature
Signature Blob Size	3,732 bytes	Raw signature (2,420) + public key (1,312) - used in transactions
Seed Size	32 bytes	Random seed for key generation
Matrix Dimension (k, l)	(4, 4)	Module rank
Polynomial Degree (n)	256	Ring degree
Modulus (q)	8,380,417	Prime modulus
η (eta)	2	Secret key coefficient bound
γ₁	2¹⁷	Signature coefficient range
γ₂	(q-1)/88	Low-order rounding range

Why ML-DSA44 (Not 65 or 87)?

ML-DSA comes in three security levels:

Variant	NIST Level	PK Size	Sig Size	Security
ML-DSA44	2	1,312	3,732	~128-bit
ML-DSA65	3	1,952	3,309	~192-bit
ML-DSA87	5	2,592	4,627	~256-bit

Armchain chose ML-DSA44 because:

1. 128-bit security is sufficient: NIST recommends Category 2+ for most applications

2. Smaller signatures: Reduces bandwidth and storage across all nodes

3. Better performance: Faster signing and verification

4. Industry consensus: Most PQC migration efforts target level 2

Implementation in Armchain

JavaScript / TypeScript (SDK)

The @armchain-ethersv6/ethers library uses @noble/post-quantum v0.5.1 for ML-DSA44 operations (key generation, signing, and verification).

See the Ethers SDK documentation for usage examples.

Go (Node Client)

The armchain-client uses github.com/cloudflare/circl for ML-DSA44 (key generation, signing, and verification).

Address Derivation

Addresses are derived from ML-DSA44 public keys using the same process as Ethereum, but with the larger public key:

ML-DSA44 Public Key (1,312 bytes)
        │
        ▼
   Keccak-256 hash (32 bytes)
        │
        ▼
   Take last 20 bytes
        │
        ▼
   Address (20 bytes, 0x-prefixed)

Addresses look identical to Ethereum addresses (e.g., 0x742d35Cc6634C0532925a3b844Bc9e7595f2bD18) but are derived from ML-DSA44 public keys.

HD Derivation

Armchain uses a modified BIP-44 HD derivation scheme:

m / 44' / 65536' / account' / 0 / address'

Component	Value	Notes
BIP-44 purpose	44'	Standard
Coin type	65536'	Armchain-specific
Account	n'	Per-account derivation (hardened)
Change	0	Always 0 (no change addresses)
Address index	m'	Hardened (unlike Ethereum's non-hardened)

All derivation indices are hardened to prevent public key derivation, which is critical because ML-DSA44 does not support the same public key derivation properties as secp256k1.

Derivation Process

Since ML-DSA44 key generation takes a 32-byte seed (not a scalar like ECDSA), the HD derivation uses HMAC-based key derivation to produce child seeds from a BIP-39 master seed. Each child seed is then passed to the ML-DSA44 key generation function to produce a key pair.

Master Seed (from BIP-39 mnemonic)
        │
        ▼
   Key derivation function
        │
        ▼
   Master key (32 bytes)
        │
   ┌────┼────┐
   ▼    ▼    ▼
  Derive child seeds via HMAC chain
        │
        ▼
   32-byte seed → ML-DSA44 keygen → (pubkey, privkey)

See the @armchain-ethersv6/ethers SDK for the reference implementation.

Performance

Benchmarks on a modern x86_64 CPU (@noble/post-quantum in JavaScript):

Operation	Time	Notes
Key Generation	~2.0 ms	From 32-byte seed
Signing	~3.5 ms	Includes rejection sampling
Verification	~5.0 ms
HD Child Derivation	~4.1 ms	Full path derivation
Address Computation	~0.3 ms	Keccak-256 of public key

Benchmarks on the Go client (circl library):

Operation	Time	Notes
Key Generation	~0.1 ms	Optimized Go implementation
Signing	~0.3 ms
Verification	~0.1 ms	Node validates every inbound tx

Security Considerations

Known Attack Vectors (Mitigated)

1. Side-channel attacks: The @noble/post-quantum library uses constant-time operations. Rejection sampling is implemented to prevent timing leaks.

2. Seed reuse: HD derivation ensures unique seeds per account/address.

3. Hash collisions: ML-DSA44 uses internal SHAKE-256 hashing, which is quantum-resistant.

Assumptions

• ML-DSA44's security relies on the hardness of MLWE. If this problem is found to be easy, the scheme breaks.

• NIST Category 2 corresponds to ~128-bit security against quantum attacks (equivalent to AES-128 key recovery).

• The scheme is considered secure against all currently known quantum algorithms.

Further Reading

• FIPS 204 Standard

• CRYSTALS-Dilithium Specification

• @noble/post-quantum Library

• Cloudflare CIRCL

• PQC Overview: Why post-quantum cryptography matters

• Transaction Types: How signatures are encoded in transactions