The Four Pillars of Security

← Back to Cryptography I: Blockchain Security and Cryptographic Foundations

Introduction

Before we dive into code, we need to understand what cryptography actually promises us. In rippled, every cryptographic operation serves one or more of four fundamental guarantees. These aren't abstract concepts—they're concrete properties that protect billions of dollars in value and enable a decentralized financial system to function without trusted intermediaries.

The Cryptographic Promise

When you interact with the XRP Ledger, cryptography provides four essential security properties. Understanding these properties—what they mean, why they matter, and how they're achieved—is foundational to everything else in this module.

1. Confidentiality

Confidentiality means that sensitive information remains hidden from those who shouldn't see it.

In XRPL Context

When two rippled nodes establish a connection, their communication is encrypted so that eavesdroppers on the network can't read their messages. The SSL/TLS layer provides this guarantee, ensuring that even though the internet is fundamentally public, peer-to-peer conversations remain private.

How It Works

// From src/libxrpl/basics/make_SSLContext.cpp
// SSL context is configured with strong cipher suites
auto ctx = boost::asio::ssl::context(boost::asio::ssl::context::tlsv12);
ctx.set_options(
    boost::asio::ssl::context::default_workaround |
    boost::asio::ssl::context::no_sslv2 |
    boost::asio::ssl::context::no_sslv3 |
    boost::asio::ssl::context::single_dh_use);

Rippled uses TLS 1.2 or higher with carefully selected cipher suites that provide forward secrecy—even if a node's long-term key is compromised later, past communications remain protected.

Why It Matters

Without confidentiality:

• Attackers could monitor which transactions nodes are sharing

• Network topology could be mapped by observing communication patterns

• Strategic information about ledger state could leak to adversaries

2. Integrity

Integrity ensures that data hasn't been tampered with. A single flipped bit could change "send 1 XRP" to "send 100 XRP"—or worse, redirect funds to a different account entirely.

In XRPL Context

When you receive a transaction, you need to know that every byte is exactly as the sender intended. Hash functions provide this guarantee by creating unique fingerprints of data that change completely if even a single bit is modified.

How It Works

// Transaction ID is computed from transaction data
uint256 transactionID = sha512Half(serializedTransaction);

// Any change to the transaction changes the ID completely
// Original: "Payment of 1 XRP"     → ID: 0x7F3B9...
// Modified: "Payment of 2 XRP"     → ID: 0xA21C4...
// Even 1 bit different: completely different hash

The SHA-512-Half hash function used throughout XRPL ensures that:

• You can't find two different transactions with the same ID (collision resistance)

• You can't create a transaction that produces a specific ID (preimage resistance)

• Changing even one bit produces a completely different hash (avalanche effect)

Why It Matters

Without integrity:

• Transactions could be modified in transit

• Malicious nodes could alter payment amounts

• The entire concept of "this transaction" becomes meaningless

Real-World Example

// Original transaction
{
  "Account": "rN7n7otQDd6FczFgLdlqtyMVrn3LNU8B4C",
  "Destination": "rLHzPsX6oXkzU9w7fvQqJvGjzVtL5oJ47R",
  "Amount": "1000000"  // 1 XRP
}
// Hash: 0x7F3B9E4A...

// Attacker tries to change amount
{
  "Account": "rN7n7otQDd6FczFgLdlqtyMVrn3LNU8B4C",
  "Destination": "rLHzPsX6oXkzU9w7fvQqJvGjzVtL5oJ47R",
  "Amount": "100000000"  // 100 XRP - just one character different!
}
// Hash: 0xA21C4F8D... - completely different!

The hash changes so dramatically that any modification is immediately detectable.

3. Authenticity

Authenticity proves the identity of the sender. When a transaction claims to come from a particular account, cryptographic signatures prove that the holder of that account's private key actually created it.

In XRPL Context

Every transaction on XRPL must be signed with the private key corresponding to the sending account. Without this signature, the transaction is rejected. The signature is mathematical proof that only someone with the secret key could have created it.

How It Works

// Signing a transaction
Buffer signature = sign(
    publicKey,   // Can be shared publicly
    secretKey,   // Must remain secret
    txData       // Transaction to sign
);

// Anyone can verify the signature
bool valid = verify(
    publicKey,   // Sender's public key
    txData,      // Transaction data
    signature    // Signature to verify
);

The mathematical relationship between public and secret keys ensures:

• Only the secret key holder can create a valid signature

• Anyone with the public key can verify the signature

• The signature proves authorization for this specific transaction

Why It Matters

Without authenticity:

• Anyone could claim to be anyone

• Funds could be stolen by impersonating account owners

• The entire concept of ownership would collapse

Attack Scenario (Prevented)

// Attacker tries to steal funds
Transaction fakeTx = {
  "Account": "rVictimAccount...",  // Victim's address
  "Destination": "rAttackerAccount...",
  "Amount": "1000000000"  // Attacker tries to drain account
};

// Attacker creates fake signature
Buffer fakeSignature = attacker.tryToForge();

// Verification fails!
bool valid = verify(victimPublicKey, fakeTx, fakeSignature);
// Returns false - attacker doesn't have victim's secret key

Without the victim's secret key, it's computationally infeasible to create a valid signature. The attacker would need to solve the discrete logarithm problem—which would take longer than the age of the universe with all of humanity's computing power.

4. Non-Repudiation

Non-repudiation means that once you've signed something, you can't later deny you signed it. The mathematics of digital signatures make this guarantee absolute: if your private key created a signature, there's no ambiguity, no room for doubt.

In XRPL Context

This property is crucial for a financial system where disputes might arise and proof of authorization is essential. If you signed a payment, that signature is irrefutable proof that you authorized it.

How It Works

Digital signatures create an undeniable link between:

• The signer (proved by possession of the secret key)

• The message (what was signed)

• The time (when it was signed, via timestamps or ledger sequence)

// Alice signs a payment
auto [alicePubKey, aliceSecKey] = generateKeyPair(KeyType::ed25519);
Buffer sig = sign(alicePubKey, aliceSecKey, payment);

// Later, Alice claims: "I never authorized that payment!"
// But the signature proves otherwise:
bool proofOfAuthorization = verify(alicePubKey, payment, sig);
// Returns true - irrefutable proof Alice signed this

Why It Matters

Without non-repudiation:

• Senders could deny authorizing payments after they complete

• Dispute resolution would be impossible

• Legal accountability for transactions wouldn't exist

• Financial systems couldn't function reliably

Real-World Scenario

Timeline:
1. Alice signs transaction paying Bob 1000 XRP
2. Transaction is validated and included in ledger
3. Alice's balance decreases by 1000 XRP
4. Alice claims: "Someone stole my money! I never authorized this!"

Investigation:
- Retrieve the transaction from ledger history
- Extract Alice's signature from the transaction
- Verify signature against Alice's public key
- Signature verifies ✓

Conclusion:
Alice's secret key created this signature. Either:
a) Alice authorized the payment, or
b) Someone gained access to Alice's secret key

Either way, the signature is cryptographic proof that whoever held
Alice's secret key at the time authorized this payment. This is why
protecting secret keys is absolutely critical.

How These Pillars Work Together

These four properties aren't independent—they work together to create a complete security system:

       ┌─────────────────────────────────────────┐
       │         XRPL Security Model              │
       └─────────────────────────────────────────┘
                          │
          ┌───────────────┴───────────────┐
          │                               │
    ┌─────▼─────┐                  ┌──────▼──────┐
    │ Transport │                  │ Application │
    │  Security │                  │  Security   │
    └─────┬─────┘                  └──────┬──────┘
          │                               │
    ┌─────▼────────┐              ┌──────▼───────┐
    │Confidentiality│              │ Authenticity │
    │  (SSL/TLS)    │              │ (Signatures) │
    └──────────────┘               └──────────────┘
          │                               │
    ┌─────▼────────┐              ┌──────▼───────┐
    │  Integrity    │              │Non-repudiation│
    │   (Hashing)   │              │ (Signatures) │
    └───────────────┘              └──────────────┘

Example: A Complete Transaction

Let's see all four pillars in action:

// 1. AUTHENTICITY - Alice creates and signs a transaction
auto tx = Payment{
    .account = alice.address,
    .destination = bob.address,
    .amount = XRP(100)
};

Buffer signature = sign(alice.publicKey, alice.secretKey, tx);
// Only Alice's secret key can create this valid signature

// 2. INTEGRITY - Transaction is serialized and hashed
auto serialized = serialize(tx, signature);
uint256 txID = sha512Half(serialized);
// Any tampering changes the hash completely

// 3. NON-REPUDIATION - Signature proves Alice authorized this
bool authorized = verify(alice.publicKey, tx, signature);
// Alice cannot later deny signing this transaction

// 4. CONFIDENTIALITY - Transaction is sent to peers via encrypted connection
sslStream.write(serialized);  // Protected by TLS encryption
// Network observers can't read transaction details

Mathematical Foundations

The four pillars rest on hard mathematical problems:

For Authenticity and Non-Repudiation: The Discrete Logarithm Problem

Given: PublicKey = SecretKey × G (where G is a generator point)
Hard Problem: Find SecretKey given only PublicKey

Computing PublicKey from SecretKey: microseconds
Computing SecretKey from PublicKey: longer than age of universe

This asymmetry enables public-key cryptography. You can freely share your public key, and no one can derive your secret key from it.

For Integrity: Collision Resistance

Given: hash = SHA512Half(data)
Hard Problems:
1. Find different data' where SHA512Half(data') = hash (preimage)
2. Find data and data' where SHA512Half(data) = SHA512Half(data') (collision)

Computing hash from data: microseconds
Finding data from hash: computationally infeasible

This one-way property makes hashes perfect for integrity checking.

For Confidentiality: Symmetric Key Security

Given: Encrypted = AES_Encrypt(key, plaintext)
Hard Problem: Find plaintext without key

With key: decryption in microseconds
Without key: trying all 2^256 possible keys

TLS negotiates shared secret keys that both parties know but attackers don't.

Trust Model

These four pillars enable a trust model where:

You don't have to trust:

• Network operators

• Node operators

• Other validators

• Anyone else

You only have to trust:

• Mathematics (that the cryptographic problems are actually hard)

• Your ability to protect your own secret keys

• The open-source implementation (which you can audit)

This is the fundamental shift blockchain enables: from institutional trust to mathematical trust.

Security in Depth

Rippled doesn't rely on one cryptographic technique—it uses multiple layers:

Defense Layer 1: Network Security
└─ TLS encryption (confidentiality)
   └─ Prevents eavesdropping on communications

Defense Layer 2: Transaction Security
└─ Digital signatures (authenticity, non-repudiation)
   └─ Proves who authorized what
   └─ Hash-based integrity (integrity)
      └─ Detects any tampering

Defense Layer 3: Protocol Security
└─ Consensus mechanism
   └─ Requires majority agreement
   └─ Byzantine fault tolerance

Even if one layer has a vulnerability, others provide protection.

Practical Implications

Understanding these four pillars helps you:

When reading code:

• Recognize which security property a function provides

• Understand why certain checks are performed

• Identify what would break if a step is skipped

When writing code:

• Choose appropriate cryptographic primitives

• Implement proper error handling

• Avoid introducing vulnerabilities

When debugging:

• Identify which security property is failing

• Trace the cryptographic operation responsible

• Understand what went wrong and why

Summary

The four pillars of cryptographic security are:

1. Confidentiality - Keep secrets secret (via encryption)

2. Integrity - Detect tampering (via hashing)

3. Authenticity - Prove identity (via signatures)

4. Non-repudiation - Prove authorization (via signatures)

These properties work together to create a system where trust is mathematical rather than institutional. In the chapters ahead, you'll see exactly how rippled implements these properties through specific cryptographic algorithms and careful coding practices.