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)
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)
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
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
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
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
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
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
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
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
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
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
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
"Serious Cryptography" by Jean-Philippe Aumasson
Modern cryptography handbook
Practical focus
"Cryptography Engineering" by Ferguson, Schneier, Kohno
Implementation-focused
Real-world protocols
"Applied Cryptography" by Bruce Schneier
Classic reference
Comprehensive coverage
Papers
"A Graduate Course in Applied Cryptography" by Boneh and Shoup
Free online: https://toc.cryptobook.us/
Modern approach
"High-speed high-security signatures" by Bernstein et al.
Ed25519 design paper
Performance analysis
Online Resources
Cryptopals Challenges: https://cryptopals.com/
Hands-on crypto exercises
Breaking weak implementations
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
Last updated