Digital Signatures - ECDSA and EdDSA

Before diving into specific algorithms, let's establish what digital signatures must accomplish.

Digital Signature Requirements:

- Signature proves signer identity
- Only private key holder can sign
- Ties transaction to specific account

- Signer cannot deny having signed
- No "my key was used without my knowledge" excuse
- Mathematical proof, not trust-based

- Signature is bound to specific message
- Any modification invalidates signature
- Cannot reuse signature for different message

- Cannot create valid signature without private key
- Even with many (message, signature) pairs
- "Existential unforgeability under chosen message attack"

High-Level Signature Flow:

SIGNING:
┌─────────────────┐
│   Transaction   │
│     Data        │
└────────┬────────┘
         │
    Hash Function
         │
         ▼
┌─────────────────┐     ┌─────────────────┐
│  Message Hash   │────►│   Sign with     │
│    (256 bits)   │     │   Private Key   │
└─────────────────┘     └────────┬────────┘
                                 │
                                 ▼
                        ┌─────────────────┐
                        │   Signature     │
                        │   (64-72 bytes) │
                        └─────────────────┘

VERIFICATION:
┌─────────────────┐     ┌─────────────────┐
│   Transaction   │────►│   Hash Again    │
│   + Signature   │     │                 │
└─────────────────┘     └────────┬────────┘
                                 │
         ┌─────────────────┐     │
         │   Public Key    │     │
         │  (from account) │     │
         └────────┬────────┘     │
                  │              │
                  ▼              ▼
              ┌───────────────────┐
              │  Verify Equation  │
              │   r ≟ computed r  │
              └─────────┬─────────┘
                        │
                ┌───────▼───────┐
                │ Valid/Invalid │
                └───────────────┘

The Mathematical Trick:

Private Key: Random number k (kept secret)
Public Key: Point K = kG on elliptic curve (published)

- Use private key k to compute signature (r, s)
- Signature involves message hash, k, and randomness
- Output reveals nothing about k

- Use public key K and signature (r, s)
- Compute a point from signature + message hash
- Check if it matches expected value

- Verification equation works ONLY if signer knew k
- Computing k from K is ECDLP (infeasible)
- Forging signature requires solving ECDLP

---

ECDSA is the original signature scheme used by Bitcoin, Ethereum, and XRPL (default). Understanding its mechanics reveals both its security and its implementation hazards.

ECDSA Signature Generation:

- Private key: d (256-bit integer)
- Message: m (transaction data)
- Curve parameters: G, n (generator point, order)

1. Hash the message: e = SHA-256(m)

1. Generate random nonce: k ∈ [1, n-1]

1. Compute curve point: R = kG

1. Extract x-coordinate: r = R.x mod n

1. Compute s = k⁻¹(e + rd) mod n

1. Output signature: (r, s)

- r: 32 bytes (256 bits)
- s: 32 bytes (256 bits)
- DER encoding overhead: 6-8 bytes
- Total: 70-72 bytes typically

ECDSA Signature Verification:

- Public key: Q (point on curve)
- Message: m (original transaction)
- Signature: (r, s)

1. Check r, s are in valid range [1, n-1]

1. Hash the message: e = SHA-256(m)

1. Compute modular inverse: w = s⁻¹ mod n

1. Compute u₁ = ew mod n

1. Compute point: P = u₁G + u₂Q

1. Verify: r ≟ P.x mod n

If equal → VALID signature
If not equal → INVALID signature

Why This Works:
P = u₁G + u₂Q
  = ewG + rwQ
  = (e + rd)wG       [since Q = dG]
  = (e + rd)s⁻¹G
  = kG               [since s = k⁻¹(e + rd)]
  = R

So P.x = R.x = r (what we verify)

ECDSA's Critical Vulnerability:

The nonce k must be:
✓ Random: Unpredictable to attackers
✓ Unique: Never reused with same private key
✓ Secret: Never revealed

If ANY of these fail, private key is compromised.

Why Nonce Reuse Is Catastrophic:

• Message 1: (r, s₁) where s₁ = k⁻¹(e₁ + rd)
• Message 2: (r, s₂) where s₂ = k⁻¹(e₂ + rd)

Note: same k → same R → same r

Attacker computes:
s₁ - s₂ = k⁻¹(e₁ - e₂)
k = (e₁ - e₂)(s₁ - s₂)⁻¹ ← Nonce recovered!

Once k known:
d = (sk - e)r⁻¹ ← Private key recovered!

From 2 signatures with same nonce → complete compromise
```

Case Study 1: Sony PlayStation 3 (2010)

Case Study 2: Android Bitcoin Wallets (2013)

EdDSA (specifically Ed25519) was designed to eliminate ECDSA's implementation pitfalls while maintaining equivalent mathematical security.

Ed25519 Signature Generation:

- Private key seed: sk (32 bytes random)
- Message: m

- h = SHA-512(sk)
- a = h[0:32] (scalar, with bit manipulation)
- prefix = h[32:64] (for nonce derivation)
- Public key: A = aB (B is base point)

1. Compute nonce: r = SHA-512(prefix || m)

1. Compute point: R = rB

1. Compute challenge: k = SHA-512(R || A || m)

1. Compute response: s = r + k·a (mod ℓ)

1. Output signature: (R, s) [64 bytes exactly]

- Nonce r derived from message + private key
- Same message → same nonce (deterministic)
- Different message → different nonce (hash output)
- CANNOT accidentally reuse nonce across different messages

Ed25519 Signature Verification:

- Public key: A
- Message: m
- Signature: (R, s)

1. Compute challenge: k = SHA-512(R || A || m)

1. Verify: sB ≟ R + kA

If equal → VALID signature
If not equal → INVALID signature

Why This Works:
sB = (r + ka)B
   = rB + kaB
   = R + kA

Exactly what we verify.

EdDSA Implementation Advantages:

1. Deterministic Nonces:

Result: Nonce reuse IMPOSSIBLE
   - Same message → same nonce (intentionally)
   - Different message → different nonce (hash)
   - No RNG quality concerns
   - No nonce generation bugs possible

1. Complete Addition Formulas:

Result: Easier to implement without side channels
   - No conditional branches on secret data
   - Constant-time easier to achieve
   - Fewer implementation footguns

1. Simpler Verification:

Result: Faster verification
   - ~3x faster in practice
   - Matters for validators

1. No Malleability:

Result: Simpler protocol design

Ed25519 Security Claims:

- Equivalent to ECDSA (~128-bit security)
- Based on discrete log hardness
- No known attack better than generic

- Same (key, message) → same signature
- Required for stateless signing
- Feature, not bug

- Even if SHA-512 collisions found
- Signatures remain unforgeable
- Hash used for derivation, not directly in equation

- Designed for constant-time implementation
- Complete addition formulas
- No secret-dependent branches in reference implementation

- Can verify multiple signatures faster than individually
- Important for validators processing many transactions
- ~2x speedup for batch of 64 signatures

---

Signature malleability is a subtle property that doesn't break authentication but can complicate protocol design.

Signature Malleability:

Definition: Given valid signature (r, s), can another valid
signature (r', s') be computed WITHOUT the private key?

- Given (r, s), the signature (r, n-s) is also valid
- This is because: s and -s both satisfy verification
- Attacker can flip any ECDSA signature

Example:
Original: (r, s) signs message m
Malleable: (r, n-s) also signs message m
Both verify correctly!
Private key NOT needed to compute malleable version.

Malleability Impact:

- If TX ID = Hash(transaction with signature)
- Malleable signature → different hash
- Same transaction, different ID

1. Alice broadcasts transaction with signature (r, s)
2. Attacker sees TX, computes (r, n-s)
3. Attacker broadcasts TX with malleable signature
4. Either TX might confirm
5. But they have different TX IDs!

- Alice's wallet tracks TX ID with (r, s)
- If attacker's version confirms
- Alice thinks TX failed (wrong ID)
- Alice might retry, sending double payment

- Mt. Gox blamed malleability for losses
- (Actually fraud, but malleability was real issue)
- Led to BIP-66 strict DER encoding
- Segwit fundamentally fixed by separating signatures

XRPL Transaction Identification:

- Hash of transaction WITHOUT signature
- Signature not included in TX hash
- Malleability doesn't affect TX ID

- Same transaction always has same ID
- Signature can vary (malleability)
- TX tracking unaffected

- Each account has sequence counter
- Must increment with each transaction
- Prevents replay regardless of TX ID

- TX ID: identifies transaction content
- Sequence: prevents duplicates
- Signature: proves authorization
- Malleability: doesn't break anything

EdDSA Non-Malleability:

- Signature is (R, s) where 0 ≤ s < ℓ
- Only one valid s value per (R, message)
- Cofactor handling ensures uniqueness

- Reject s ≥ ℓ (non-canonical)
- Reject non-canonical R encodings
- Reject points not on curve

- Each (message, key) pair has exactly one valid signature
- Verification either accepts canonical signature or rejects
- No malleability when implemented correctly

- Some implementations don't check all conditions
- Malleability possible if verification is lax
- XRPL uses strict verification

---

Beyond mathematical security, real-world signature security depends on implementation quality.

Why Constant-Time Matters:

Variable-Time Danger:
if (secret_bit == 1):
    do_operation_A()    # Takes 100 cycles
else:
    do_operation_B()    # Takes 50 cycles

Attacker measures timing → learns secret bits

- Scalar multiplication (private key involved)
- Modular inversion (nonce involved)
- Point addition (key-dependent branches)

- Many potential timing leaks
- Modular inversion particularly tricky
- Conditional branches in naive implementation

- Designed for constant-time from start
- Complete addition formulas (no branches)
- Reference implementation is constant-time
- Easier to implement safely

Evaluating Signature Libraries:

Security Factors:
□ Constant-time implementation verified?
□ Side-channel analysis performed?
□ Fuzzing/testing coverage?
□ Security audit completed?
□ Active maintenance?
□ CVE history and response?

ECDSA Specific:
□ Uses RFC 6979 deterministic nonces?
□ Low-s normalization for malleability?
□ Proper curve point validation?
□ Timing-safe modular arithmetic?

EdDSA Specific:
□ Canonical signature encoding?
□ Point validation for verification?
□ Cofactor handling correct?
□ Batch verification available?

- libsecp256k1 (Bitcoin's library, heavily audited)
- libsodium (includes Ed25519, widely used)
- BoringSSL/OpenSSL (mature, maintained)
- Avoid: Custom implementations, unmaintained libraries

RFC 6979: Fixing ECDSA's Nonce Problem

Applying signature security to real XRPL usage.

Secure Signing Checklist:

Key Management:
□ Private key generated with sufficient entropy
□ Key stored in hardware wallet or HSM
□ Key never exposed to network-connected device
□ Backup exists in secure location

Signing Process:
□ Transaction constructed correctly
□ Transaction displayed and verified before signing
□ Signing occurs on secure device
□ Signature verified before broadcast

For High-Value Accounts:
□ Use multi-signature requiring multiple keys
□ Keys stored in different locations
□ Different key types if possible (diversity)
□ Regular security audits of process

Red Flags:
✗ Signing on general-purpose computer
✗ Key stored in cloud or unencrypted
✗ Not verifying transaction details before signing
✗ Using untested/custom signing software

Signature Verification in Applications:

1. Signature is valid for transaction content
2. Signature matches account's public key
3. Account has authority to perform transaction
4. Transaction passes all other validation

Common Mistakes:
✗ Not verifying signature at all (trusting source)
✗ Verifying signature but wrong message
✗ Not checking public key matches account
✗ Accepting non-canonical signatures

- Every transaction verified before processing
- Invalid signatures rejected immediately
- No exceptions for "trusted" sources
- Cryptographic verification is absolute

Multi-Signature with Mixed Schemes:

- Multiple signers can use different key types
- Some signers: secp256k1
- Some signers: Ed25519
- Combined signatures still valid

- Diversity of cryptographic assumptions
- If one scheme weakened, others provide backup
- Allows gradual migration

- Signer 1: Ledger Nano (secp256k1)
- Signer 2: Ledger Nano (secp256k1)
- Signer 3: Software wallet (Ed25519)
- Signer 4: HSM (secp256k1)
- Signer 5: Backup key (Ed25519)

Any 3 can authorize transactions.
Mix of schemes provides defense in depth.

✅ Both ECDSA and EdDSA provide ~128-bit security under their respective assumptions. The mathematical foundations are sound. No algorithm significantly better than generic attacks exists for either scheme. Security reductions to the discrete log problem are well-established.

✅ EdDSA's deterministic nonces eliminate the most common ECDSA implementation failure mode. The nonce reuse attacks that compromised Sony PS3 and Android Bitcoin wallets are mathematically impossible with properly implemented EdDSA. This is a design property, not an optional feature.

✅ RFC 6979 brings deterministic nonce generation to ECDSA. Modern ECDSA implementations using RFC 6979 share EdDSA's protection against nonce-related failures. The fix is well-established and widely deployed.

⚠️ Implementation quality varies dramatically across libraries. The algorithms are secure; many implementations are not. Side-channel vulnerabilities, improper randomness, and subtle bugs have caused real-world compromises.

⚠️ Hardware wallet security is opaque. Users trust hardware wallet implementations without ability to audit. Security depends on vendor practices, which vary. Hardware security is easier to claim than to verify.

⚠️ Quantum computers will eventually break both schemes. Shor's algorithm solves the underlying mathematical problems efficiently on quantum hardware. Timeline is uncertain but both ECDSA and EdDSA will eventually need replacement.

🔴 Legacy ECDSA implementations without RFC 6979 remain vulnerable. Not all software has been updated. Using old signing code risks nonce reuse, especially on devices with poor entropy sources.

🔴 Custom signature implementations are almost always wrong. Cryptographic implementation is subtle. Even small deviations from specified algorithms can introduce fatal vulnerabilities. Use established libraries.

🔴 "Valid signature" doesn't mean "safe transaction." Signatures prove authorization, not wisdom. A perfectly valid signature can authorize sending all your funds to a scammer. Transaction verification is separate from signature verification.

Digital signatures are the mechanism that makes trustless value transfer possible. XRPL's support for both ECDSA and EdDSA provides flexibility—backward compatibility with the broader ecosystem (ECDSA) and improved implementation safety (EdDSA).

The mathematics is rock-solid. The danger lies in implementation: nonce handling, side channels, key management, and transaction verification. EdDSA eliminates the most dangerous implementation pitfalls, but no signature scheme protects against signing a malicious transaction or exposing your private key.

For new implementations, EdDSA is recommended. For existing systems using ECDSA with RFC 6979, the security is equivalent. What matters most is the overall security posture: proper key generation, secure key storage, careful transaction verification, and use of audited libraries.

Assignment: Create a comprehensive decision framework for choosing between secp256k1/ECDSA and Ed25519/EdDSA in XRPL applications, including risk analysis and migration guidance.

Requirements:

Part 1: Decision Tree Diagram

• New implementation vs. existing system
• Hardware wallet requirement
• Cross-chain compatibility needs
• Performance requirements (signing/verification throughput)
• Implementation team cryptographic expertise
• Risk tolerance and security requirements

Tree should lead to specific recommendations with rationale.

Part 2: Risk Comparison Matrix

For each scheme, analyze:

Include probability and impact ratings.

Part 3: Migration Guide

• Account migration procedure
• Key generation requirements
• Testing checklist
• Rollback plan
• Timeline recommendations
• Cost/benefit analysis

Part 4: Library Recommendations

• Recommended library for each scheme

• Security audit status

• Known issues or caveats

• Usage examples

• Decision tree completeness (25%)

• Risk analysis accuracy (25%)

• Migration guidance practicality (25%)

• Library research quality (25%)

Time Investment: 4-5 hours

Value: This framework becomes a reference for any XRPL development project requiring signature scheme selection, reducing the risk of poor cryptographic choices.

For Next Lesson:
We'll examine key derivation and HD wallets—how a single seed phrase generates unlimited keys while maintaining backup simplicity. Understanding derivation paths and entropy requirements reveals both the elegance of deterministic wallets and their security dependencies.

End of Lesson 4

Total words: ~6,400
Estimated completion time: 60 minutes reading + 4-5 hours for deliverable