# 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](https://csrc.nist.gov/pubs/fips/204/final).

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`](https://github.com/paulmillr/noble-post-quantum) v0.5.1 for ML-DSA44 operations (key generation, signing, and verification).

See the [Ethers SDK documentation](/developers/overview-1.md) for usage examples.

### Go (Node Client)

The `armchain-client` uses [`github.com/cloudflare/circl`](https://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](https://csrc.nist.gov/pubs/fips/204/final)
* [CRYSTALS-Dilithium Specification](https://pq-crystals.org/dilithium/)
* [@noble/post-quantum Library](https://github.com/paulmillr/noble-post-quantum)
* [Cloudflare CIRCL](https://github.com/cloudflare/circl)
* [PQC Overview](/pqc/overview.md): Why post-quantum cryptography matters
* [Transaction Types](/pqc/transaction-types.md): How signatures are encoded in transactions


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.armchain.org/pqc/mldsa44.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.