# XLS-??d Quantum-Resistant Signatures

```markdown
Title: Quantum-Resistant Signatures
Revision: 1 (2025-07-08)
Type: Draft
Author:
    Atharva Lele, Trinity College Dublin
    Denis Angell, XRPL Labs
```

## Abstract

This proposal introduces quantum-resistant digital signatures to the XRP Ledger (XRPL) using the Dilithium post-quantum cryptographic algorithm. The amendment provides accounts with the ability to use quantum-resistant signatures for enhanced security against future quantum computing threats while maintaining backward compatibility with existing signature schemes.

## Motivation and Rationale

As quantum computing advances, current cryptographic signatures (secp256k1, ed25519) may become vulnerable to quantum attacks. This proposal adds support for Dilithium, a NIST-standardized post-quantum signature algorithm, ensuring long-term security for XRPL accounts.

## Amendment

This feature enables accounts to use quantum-resistant signatures with an optional enforcement mechanism.

The amendment adds:

* Support for Dilithium signature algorithm (`KeyType::dilithium = 2`)
* New account flag `lsfForceQuantum` to enforce quantum-resistant signatures
* Updated key generation, encoding, and verification systems

***

## Development Branch

### Implementation Repository

The quantum-resistant signatures implementation is currently under active development in the following branch:

**Repository**: [Transia-RnD/rippled](https://github.com/Transia-RnD/rippled)\
**Branch**: [`dilithium-full`](https://github.com/Transia-RnD/rippled/tree/dilithium-full)

### Development Status

This branch contains the working implementation of the quantum-resistant signature system, including:

* **Core Dilithium Integration**: Implementation of the Dilithium post-quantum signature algorithm
* **Key Management Updates**: Modified key generation, storage, and retrieval systems
* **Signature Verification**: Updated transaction signing and verification processes
* **Account Flag Implementation**: `lsfForceQuantum` flag enforcement mechanisms
* **Backward Compatibility**: Maintained support for existing signature schemes

### Testing and Validation

The quantum branch includes:

* Unit tests for Dilithium key operations
* Integration tests for quantum-resistant transaction processing
* Performance benchmarks comparing signature verification times
* Compatibility tests ensuring existing functionality remains intact

### Contributing

Developers interested in contributing to the quantum-resistant signatures implementation should:

1. Fork the repository and checkout the `quantum` branch
2. Review the existing implementation and test coverage
3. Submit pull requests against the `quantum` branch
4. Ensure all tests pass and maintain backward compatibility

***

## Implementation Details

### Key Specifications

| Aspect          | secp256k1  | ed25519  | **Dilithium**                   |
| --------------- | ---------- | -------- | ------------------------------- |
| Public Key Size | 33 bytes   | 33 bytes | **1312 bytes**                  |
| Secret Key Size | 32 bytes   | 32 bytes | **2528 bytes**                  |
| Signature Size  | \~70 bytes | 64 bytes | **\~2420 bytes**                |
| Security Level  | 128-bit    | 128-bit  | **128-bit (quantum-resistant)** |

### Key Generation

```cpp
// Generate quantum-resistant keys
auto keyPair = generateKeyPair(KeyType::dilithium, seed);
auto secretKey = randomSecretKey(KeyType::dilithium);
```

### Public Key Detection

```cpp
std::optional<KeyType> publicKeyType(Slice const& slice) {
    if (slice.size() == 33) {
        if (slice[0] == 0xED) return KeyType::ed25519;
        if (slice[0] == 0x02 || slice[0] == 0x03) return KeyType::secp256k1;
    }
    else if (slice.size() == CRYPTO_PUBLICKEYBYTES) {
        return KeyType::dilithium;  // 1312 bytes
    }
    return std::nullopt;
}
```

***

## Account Flag: Force Quantum Signatures

### `lsfForceQuantum` Flag

| Field             | Value        | Description                                             |
| ----------------- | ------------ | ------------------------------------------------------- |
| `lsfForceQuantum` | `0x02000000` | When set, account requires quantum-resistant signatures |
| `asfForceQuantum` | `11`         | AccountSet flag to enable/disable quantum requirement   |

### Usage

```json
{
  "TransactionType": "AccountSet",
  "Account": "rAccount...",
  "SetFlag": 11  // Enable quantum-only signatures
}
```

### Enforcement

```cpp
if (account.isFlag(lsfForceQuantum) && publicKey.size() != DILITHIUM_PK_SIZE)
    return telBAD_PUBLIC_KEY;
```

***

## Signature Operations

### Signature Generation

```cpp
case KeyType::dilithium: {
    uint8_t sig[CRYPTO_BYTES];
    size_t len;
    crypto_sign_signature(sig, &len, message.data(), message.size(), secretKey.data());
    return Buffer{sig, len};
}
```

### Signature Verification

```cpp
if (keyType == KeyType::dilithium) {
    return crypto_sign_verify(
        sig.data(), sig.size(), 
        message.data(), message.size(), 
        publicKey.data()) == 0;
}
```

***

## Migration Strategy

### Gradual Adoption

1. **Optional Phase**: Quantum signatures available but not required
2. **Account Choice**: Individual accounts can enable `lsfForceQuantum`
3. **Network Transition**: Networks can mandate quantum signatures over time

### Backward Compatibility

* Existing accounts continue using current signature types
* No breaking changes to existing functionality
* Smooth upgrade path for enhanced security

***

## Error Codes

| Error Code          | Description                                               |
| ------------------- | --------------------------------------------------------- |
| `telBAD_PUBLIC_KEY` | Non-quantum signature used with `lsfForceQuantum` account |

***

## Future Requirements

### Validator Infrastructure Updates

As quantum-resistant signatures become standard, several validator-related components will require updates:

#### Validator Code Updates

* **rippled**: Core validator software must support quantum-resistant key generation and signature verification
* **Consensus Algorithm**: Ensure quantum-resistant signatures are properly validated during consensus
* **Peer Communication**: Update peer-to-peer communication to handle larger quantum signatures

#### UNL (Unique Node List) Generation

* **UNL Tools**: Update UNL generation tools to support quantum-resistant validator keys
* **Key Format**: Modify UNL file format to accommodate larger Dilithium public keys (1312 bytes)
* **Validation**: Ensure UNL validation processes can verify quantum-resistant signatures

#### validator-keys Repository

* **Key Generation**: Update validator-keys tool to generate Dilithium key pairs
* **Key Management**: Modify key storage and management for larger quantum keys
* **Migration Tools**: Provide utilities for existing validators to transition to quantum-resistant keys
* **Documentation**: Update validator setup guides for quantum key generation

### Network Transition Considerations

* **Phased Rollout**: Gradual migration of validators to quantum-resistant keys
* **Backward Compatibility**: Maintain support for existing validator keys during transition
* **Performance Impact**: Account for increased signature verification time and bandwidth usage

***

## Dependencies

* **Dilithium Library**: pq-crystals/dilithium reference implementation

***

## Example Usage

### Generate Quantum-Resistant Keys

```cpp
// From seed
auto seed = generateSeed("masterpassphrase");
auto keyPair = generateKeyPair(KeyType::dilithium, seed);

// Random generation
auto secretKey = randomSecretKey(KeyType::dilithium);
auto publicKey = derivePublicKey(KeyType::dilithium, secretKey);
```

### Enable Quantum-Only Account

```json
{
  "TransactionType": "AccountSet",
  "Account": "rQuantumAccount...",
  "SetFlag": 11
}
```

### Sign Transaction with Quantum Key

```cpp
auto signature = sign(publicKey, secretKey, transactionData);
bool isValid = verify(publicKey, transactionData, signature);
```


---

# 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.xrpl-commons.org/core-dev-bootcamp/module05/appendices/xls-d.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.