# Appendix : RFCs and Standards Reference

### Introduction

This appendix provides references to the cryptographic standards, RFCs, and specifications that XRPL's cryptography is built upon. Understanding these standards helps you understand why rippled makes certain design choices.

### Cryptographic Algorithms

#### Ed25519 Digital Signatures

**RFC 8032 - Edwards-Curve Digital Signature Algorithm (EdDSA)**

* **URL**: <https://tools.ietf.org/html/rfc8032>
* **Published**: January 2017
* **Status**: Proposed Standard

**What it defines:**

* EdDSA signature scheme using Edwards curves
* Ed25519: EdDSA with Curve25519
* Ed448: EdDSA with Ed448-Goldilocks
* Test vectors and implementation guidelines

**Key parameters (Ed25519):**

* Curve: Curve25519 (Edwards form)
* Hash function: SHA-512
* Public key size: 32 bytes
* Signature size: 64 bytes
* Security level: \~128 bits

**Why XRPL uses it:**

* Fast signature verification (\~5x faster than ECDSA)
* Simple implementation
* No signature malleability
* Modern design with security proofs

#### secp256k1 Elliptic Curve

**SEC 2: Recommended Elliptic Curve Domain Parameters**

* **Publisher**: Standards for Efficient Cryptography Group (SECG)
* **URL**: <https://www.secg.org/sec2-v2.pdf>
* **Version**: 2.0, January 2010

**What it defines:**

* Elliptic curve parameters for secp256k1
* Curve equation: y² = x³ + 7 (mod p)
* Prime field size p and generator point G
* Compression/decompression of public keys

**Key parameters (secp256k1):**

```
p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE
    BAAEDCE6 AF48A03B BFD25E8C D0364141

G = (x, y) where:
    x = 79BE667E F9DCBBAC 55A06295 CE870B07
        029BFCDB 2DCE28D9 59F2815B 16F81798
    y = 483ADA77 26A3C465 5DA4FBFC 0E1108A8
        FD17B448 A6855419 9C47D08F FB10D4B8
```

**Why XRPL uses it:**

* Ecosystem compatibility
* Well-tested (used since 2009)
* Supported by many libraries and tools

#### ECDSA Signatures

**FIPS 186-4 - Digital Signature Standard (DSS)**

* **Publisher**: NIST
* **URL**: <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>
* **Published**: July 2013

**What it defines:**

* ECDSA signature algorithm
* Key generation procedures
* Signature generation and verification
* Approved curves (including secp256k1)

#### Deterministic ECDSA Nonces

**RFC 6979 - Deterministic Usage of DSA and ECDSA**

* **URL**: <https://tools.ietf.org/html/rfc6979>
* **Published**: August 2013
* **Status**: Informational

**What it defines:**

* Deterministic nonce generation for ECDSA
* Eliminates need for secure random number generation during signing
* Prevents nonce reuse vulnerabilities

**Algorithm:**

```
k = HMAC_DRBG(private_key, message_hash)
```

**Why XRPL uses it:**

* Prevents catastrophic nonce reuse
* Makes signing deterministic (same message = same signature)
* No dependency on RNG quality during signing

### Hash Functions

#### SHA-2 Family

**FIPS 180-4 - Secure Hash Standard (SHS)**

* **Publisher**: NIST
* **URL**: <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>
* **Published**: August 2015

**What it defines:**

* SHA-256: 256-bit hash (32 bytes)
* SHA-512: 512-bit hash (64 bytes)
* Padding and iteration schemes
* Test vectors

**XRPL usage:**

* SHA-512-Half: First 32 bytes of SHA-512
* SHA-256: Used in Base58Check checksums
* Both used in RIPESHA double hash

**Why SHA-512-Half:**

* Faster on 64-bit CPUs than SHA-256
* Same output size (256 bits)
* Same security level

#### RIPEMD-160

**Original Paper**: "RIPEMD-160: A Strengthened Version of RIPEMD"

* **Authors**: Dobbertin, Bosselaers, Preneel
* **Published**: 1996
* **Hash size**: 160 bits (20 bytes)

**XRPL usage:**

* Second stage of RIPESHA hash
* Used in address generation

**Algorithm:**

```
RIPESHA(data) = RIPEMD-160(SHA-256(data))
```

### Key Derivation

#### PBKDF2

**RFC 2898 - PKCS #5: Password-Based Cryptography Specification**

* **URL**: <https://tools.ietf.org/html/rfc2898>
* **Published**: September 2000
* **Status**: Informational

**What it defines:**

* Password-Based Key Derivation Function 2
* Iterated hashing to slow brute-force
* Salt for uniqueness

**Note:** XRPL doesn't use PBKDF2 for key derivation (uses sha512Half of seed), but it's relevant for password-based seed derivation in wallets.

### Encoding

#### Base58

**No formal RFC, but based on:**

* Design by Satoshi Nakamoto
* Excludes similar-looking characters (0, O, I, l)
* Used widely in blockchain systems

**Alphabet:**

```
123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
```

**XRPL implementation:**

* Base58Check with 4-byte SHA-256(SHA-256()) checksum
* Type prefix byte determines first character
* Compatible with other blockchain systems

#### Base64

**RFC 4648 - The Base16, Base32, and Base64 Data Encodings**

* **URL**: <https://tools.ietf.org/html/rfc4648>
* **Published**: October 2006
* **Status**: Proposed Standard

**XRPL usage:**

* Used in peer handshake (Session-Signature header)
* Not used for addresses (uses Base58Check instead)

### Transport Security

#### TLS 1.2

**RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2**

* **URL**: <https://tools.ietf.org/html/rfc5246>
* **Published**: August 2008
* **Status**: Proposed Standard

**What it defines:**

* Handshake protocol
* Record protocol
* Cipher suites
* Certificate verification

**XRPL usage:**

* Peer-to-peer communication
* WebSocket connections
* RPC endpoints

#### TLS 1.3

**RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3**

* **URL**: <https://tools.ietf.org/html/rfc8446>
* **Published**: August 2018
* **Status**: Proposed Standard

**Improvements over TLS 1.2:**

* Faster handshake
* Forward secrecy by default
* Simplified cipher suite negotiation

### DER Encoding

**ITU-T X.690 - ASN.1 encoding rules**

* **Publisher**: ITU-T
* **Published**: 2015

**What it defines:**

* Distinguished Encoding Rules (DER)
* Used for secp256k1 signature encoding
* Canonical binary format

**Structure:**

```
SEQUENCE {
    r INTEGER,
    s INTEGER
}

Encoded as:
0x30 [length]
    0x02 [r-length] [r]
    0x02 [s-length] [s]
```

### Random Number Generation

**NIST SP 800-90A - Recommendation for Random Number Generation**

* **Publisher**: NIST
* **URL**: <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf>
* **Published**: June 2015

**What it defines:**

* Deterministic Random Bit Generators (DRBGs)
* CTR\_DRBG, HASH\_DRBG, HMAC\_DRBG
* Entropy requirements
* Testing procedures

**XRPL usage:**

* Relies on OpenSSL's RAND\_bytes
* OpenSSL implements NIST-approved DRBGs

### Mnemonic Words

**RFC 1751 - A Convention for Human-Readable 128-bit Keys**

* **URL**: <https://tools.ietf.org/html/rfc1751>
* **Published**: December 1994
* **Status**: Informational

**What it defines:**

* Encoding 128-bit keys as English words
* 2048-word dictionary
* Checksum embedded in last word

**XRPL usage:**

* Optional seed encoding format
* Alternative to Base58 for seeds
* Easier to write down/speak

**Example:**

```
Seed (hex):  DEDCE9CE67B451D852FD4E846FCDE31C
Words:       MAD WARM EVEN SHOW BALK FELT
             TOY STIR OBOE COST HOPE VAIN
```

### Cryptographic Best Practices

**NIST SP 800-57 - Recommendation for Key Management**

* **Publisher**: NIST
* **URL**: <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf>
* **Published**: May 2020

**What it defines:**

* Key length recommendations
* Algorithm lifetime
* Key usage guidance
* Security strength equivalences

**Security Levels:**

```
Bits    Symmetric    Hash      RSA       ECC
────────────────────────────────────────────
128     AES-128      SHA-256   3072      256
192     AES-192      SHA-384   7680      384
256     AES-256      SHA-512   15360     512
```

**XRPL compliance:**

* 256-bit secret keys (ECC)
* 256-bit hashes (SHA-512-Half)
* \~128-bit security level for Ed25519
* \~128-bit security level for secp256k1

### Implementation Libraries

#### OpenSSL

**Website**: <https://www.openssl.org/>\
**License**: Apache License 2.0

**What rippled uses:**

* Random number generation (RAND\_bytes)
* Hash functions (SHA-256, SHA-512, RIPEMD-160)
* SSL/TLS implementation
* Some low-level crypto primitives

#### secp256k1

**Repository**: <https://github.com/bitcoin-core/secp256k1>\
**License**: MIT

**What rippled uses:**

* secp256k1 curve operations
* ECDSA signing and verification
* Public key derivation
* Signature parsing/serialization

#### ed25519-donna

**Repository**: <https://github.com/floodyberry/ed25519-donna>\
**License**: Public Domain

**What rippled uses:**

* Ed25519 signing and verification
* Public key derivation
* Fast implementation

### Recommended Reading

#### Books

1. **"Serious Cryptography"** by Jean-Philippe Aumasson
   * Modern cryptography handbook
   * Practical focus
2. **"Cryptography Engineering"** by Ferguson, Schneier, Kohno
   * Implementation-focused
   * Real-world protocols
3. **"Applied Cryptography"** by Bruce Schneier
   * Classic reference
   * Comprehensive coverage

#### Papers

1. **"A Graduate Course in Applied Cryptography"** by Boneh and Shoup
   * Free online: <https://toc.cryptobook.us/>
   * Modern approach
2. **"High-speed high-security signatures"** by Bernstein et al.
   * Ed25519 design paper
   * Performance analysis

#### Online Resources

1. **Cryptopals Challenges**: <https://cryptopals.com/>
   * Hands-on crypto exercises
   * Breaking weak implementations
2. **Crypto101**: <https://www.crypto101.io/>
   * Introductory book
   * Free online

### Standard Bodies

* **IETF**: Internet Engineering Task Force (RFCs)
* **NIST**: National Institute of Standards and Technology
* **ISO**: International Organization for Standardization
* **SECG**: Standards for Efficient Cryptography Group

### Summary

Key standards for XRPL cryptography:

* **RFC 8032**: Ed25519 signatures
* **RFC 6979**: Deterministic ECDSA nonces
* **FIPS 180-4**: SHA-2 hash functions
* **SEC 2**: secp256k1 curve parameters
* **RFC 5246/8446**: TLS for transport security

Understanding these standards helps you:

* Know why algorithms were chosen
* Verify implementations are correct
* Stay current with best practices
* Contribute improvements


---

# 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/module04/appendices/rfcs-and-standards-reference.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.
