Cryptography in Real-World Applications

John

TLS (Transport Layer Security) – Real-World Application

What is TLS?

Transport Layer Security (TLS) is a cryptographic protocol that provides secure communication over computer networks. It’s the successor to SSL (Secure Sockets Layer) and is widely used to secure web traffic (HTTPS), email, VPNs, and other network communications.

Core Security Objectives:

  • Confidentiality: Data encrypted so only intended recipients can read it
  • Integrity: Data cannot be modified without detection
  • Authentication: Verify the identity of communicating parties
  • Forward Secrecy: Past communications remain secure even if long-term keys are compromised

TLS in the Network Stack:

Layer Protocol Example
Application HTTP, SMTP, FTP Web pages, emails, file transfers
TLS TLS 1.3 Encryption & Authentication
Transport TCP Reliable data delivery
Network IP Packet routing
Physical Ethernet, WiFi Physical transmission

TLS Version Evolution:

Version Year Status Key Features
SSL 1.0 1994 Never released Initial design (flawed)
SSL 2.0 1995 Deprecated First public version
SSL 3.0 1996 Deprecated Major redesign
TLS 1.0 1999 Deprecated Based on SSL 3.0
TLS 1.1 2006 Deprecated Fixed CBC attacks
TLS 1.2 2008 Widely used Modern crypto, AEAD
TLS 1.3 2018 Current Simplified, faster, more secure

TLS 1.2 Handshake (Detailed Walkthrough)

Scenario: Alice (client) connects to Bob’s HTTPS website

Step 1: Client Hello

Alice → Bob

Contents:

  • TLS Version: “I support TLS 1.2”
  • Random Bytes: 32 random bytes (Client Random)
  • Session ID: For resuming previous sessions
  • Cipher Suites: List of supported algorithms
  • Extensions: Server Name Indication (SNI), supported curves, etc.

Example Cipher Suites:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA

Step 2: Server Hello

Bob → Alice

Contents:

  • TLS Version: “Let’s use TLS 1.2”
  • Random Bytes: 32 random bytes (Server Random)
  • Session ID: For this session
  • Chosen Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • Extensions: Responses to client extensions

Step 3: Server Certificate

Bob → Alice

Contents:

  • X.509 Certificate Chain:
    • Server certificate (contains server’s public key)
    • Intermediate CA certificates
    • Root CA certificate (Alice must have this)

Certificate Validation Process:

  1. Check certificate is not expired
  2. Verify hostname matches certificate
  3. Validate certificate chain back to trusted root CA
  4. Check certificate has not been revoked (CRL/OCSP)

Step 4: Server Key Exchange (for ECDHE)

Bob → Alice

Contents:

  • Elliptic Curve Parameters: Which curve to use (e.g., P-256)
  • Server’s Public Key: Point on elliptic curve
  • Digital Signature: Server signs the parameters using private key

Example:

Curve: secp256r1 (P-256)
Server Public Key: (x=0x1234..., y=0x5678...)
Signature: RSA signature over (Client Random + Server Random + Key Exchange Parameters)

Step 5: Server Hello Done

Bob → Alice: “I’m finished with my part of the handshake”

Step 6: Client Key Exchange

Alice → Bob

Process:

  1. Alice generates her ECDH private key
  2. Alice computes her public key
  3. Alice sends public key to Bob
  4. Both compute shared secret using ECDH

Step 7: Key Derivation

Both Alice and Bob compute:

  • Pre-Master Secret: ECDH shared secret
  • Master Secret: PRF(Pre-Master Secret, “master secret”, Client Random + Server Random)
  • Session Keys: Derived from Master Secret
    • Client write encryption key
    • Server write encryption key
    • Client write MAC key
    • Server write MAC key
    • Client IV, Server IV

Step 8: Change Cipher Spec

Alice → Bob: “I’m switching to encrypted communication now”

Step 9: Finished Message

Alice → Bob (encrypted):

  • Hash of all previous handshake messages
  • First message sent using the new encryption keys
  • Proves Alice has the correct keys

Step 10: Change Cipher Spec + Finished

Bob → Alice (encrypted):

  • Bob also switches to encrypted mode
  • Bob sends his Finished message
  • Proves Bob has the correct keys

Result: Secure Channel Established

Alice and Bob now have:

  • Mutual authentication (Bob proved identity via certificate)
  • Shared encryption keys for confidentiality
  • MAC keys for integrity
  • Forward secrecy (ephemeral ECDH keys)

TLS 1.3 Improvements

Key Differences from TLS 1.2:

Aspect TLS 1.2 TLS 1.3
Handshake Rounds 2 round trips 1 round trip
Key Exchange RSA, DHE, ECDHE Only (EC)DHE (forward secrecy mandatory)
Cipher Suites Complex combinations Simplified: only AEAD ciphers
Hash Algorithms MD5, SHA-1, SHA-2 Only SHA-2, SHA-3
0-RTT Not supported Optional (with replay risk)

TLS 1.3 Handshake Flow:

Client                                               Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     v + supported_versions*      -------->
                                                      ^ ServerHello
                                                 Exch | + key_share*
                                                      | + supported_versions*
                                                      v
                                                        {EncryptedExtensions}
                                                        {CertificateRequest*}
                                   <--------            {Certificate*}
                                                        {CertificateVerify*}
                                                        {Finished}
       ^ {Certificate*}
Auth   | {CertificateVerify*}
       v {Finished}              -------->
         [Application Data]      <------->     [Application Data]

Key Improvements:

  • Faster: 1-RTT handshake reduces latency
  • More Secure: Removes weak cryptography
  • Forward Secrecy: Mandatory for all connections
  • 0-RTT Resumption: Even faster for repeat connections

Certificate Infrastructure (PKI)

X.509 Certificate Structure:

A digital certificate contains:

  • Subject: Who the certificate belongs to (CN=example.com)
  • Issuer: Who signed the certificate (CA)
  • Public Key: The subject’s public key
  • Validity Period: Not before / Not after dates
  • Extensions: Key usage, SANs, etc.
  • Digital Signature: CA’s signature over the certificate

Certificate Chain Example:

Root CA Certificate (self-signed)
├─ CN=GlobalSign Root CA
├─ Public Key: RSA 4096-bit
├─ Valid: 1998-2028
└─ Self-signed

    ↓ signs

Intermediate CA Certificate
├─ CN=GlobalSign Organization Validation CA
├─ Issuer: GlobalSign Root CA
├─ Public Key: RSA 2048-bit
├─ Valid: 2014-2024
└─ Signed by Root CA

    ↓ signs

End Entity Certificate
├─ CN=www.example.com
├─ SAN=example.com, www.example.com, api.example.com
├─ Issuer: GlobalSign Organization Validation CA
├─ Public Key: RSA 2048-bit
├─ Valid: 2023-2024
└─ Signed by Intermediate CA

Certificate Validation Process:

  1. Parse Certificate Chain: Extract all certificates
  2. Verify Signatures: Each certificate signed by the next
  3. Check Root Trust: Root CA must be in trusted store
  4. Validate Dates: All certificates must be valid
  5. Check Hostname: Certificate must match requested hostname
  6. Revocation Check: Ensure certificates haven’t been revoked

Certificate Revocation:

Why Revoke?

  • Private key compromise
  • CA compromise
  • Change in ownership
  • Superseded by new certificate

Revocation Methods:

  • CRL (Certificate Revocation List): Downloadable list of revoked certificates
  • OCSP (Online Certificate Status Protocol): Real-time certificate status check
  • OCSP Stapling: Server provides OCSP response

Cipher Suites and Cryptographic Algorithms

TLS 1.2 Cipher Suite Format:

Example: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS: Protocol
  • ECDHE: Key exchange (Elliptic Curve Diffie-Hellman Ephemeral)
  • RSA: Authentication (server certificate uses RSA)
  • AES_256_GCM: Encryption (AES with 256-bit key in GCM mode)
  • SHA384: Hash function for key derivation

Common TLS 1.2 Cipher Suites:

Cipher Suite Key Exchange Authentication Encryption Security
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE ECDSA AES-256-GCM Excellent
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE RSA AES-128-GCM Good
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE RSA AES-256-CBC Acceptable
TLS_RSA_WITH_AES_128_CBC_SHA RSA RSA AES-128-CBC Deprecated

TLS 1.3 Simplified Cipher Suites:

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256
  • TLS_CHACHA20_POLY1305_SHA256

Note: TLS 1.3 separates key exchange from cipher suites

Real-World TLS Examples

Example 1: HTTPS Web Browsing

User types: https://www.google.com

Step-by-step process:

  1. DNS Lookup: Resolve www.google.com to IP address
  2. TCP Connection: Connect to port 443
  3. TLS Handshake:
    • Client Hello with supported cipher suites
    • Server Hello with chosen cipher suite
    • Google presents certificate (issued by Google Trust Services)
    • Browser validates certificate chain
    • Key exchange using ECDHE
    • Both derive session keys
  4. HTTP Request: GET / HTTP/1.1 (encrypted)
  5. HTTP Response: 200 OK + HTML content (encrypted)

Browser Security Indicators:

  • Green Lock: Valid certificate, secure connection
  • Warning Triangle: Mixed content (HTTP resources on HTTPS page)
  • Red Warning: Invalid certificate, connection not secure

Example 2: Email Security (STARTTLS)

Scenario: Sending email from Gmail to Yahoo

SMTP with STARTTLS:

  1. Initial Connection: Connect to mail server on port 587
  2. EHLO Command: Client announces capabilities
  3. STARTTLS Command: Upgrade connection to TLS
  4. TLS Handshake: Similar to HTTPS
  5. Encrypted SMTP: Continue with encrypted email transmission
C: EHLO gmail.com
S: 250-mx.yahoo.com
S: 250-PIPELINING
S: 250-SIZE 41943040
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
[TLS Handshake occurs]
C: EHLO gmail.com (now encrypted)
S: 250-mx.yahoo.com
S: 250 AUTH LOGIN PLAIN
C: AUTH LOGIN
...

Example 3: API Security

REST API with TLS:

Client-side (JavaScript):

// Modern browsers automatically handle TLS
fetch('https://api.example.com/users', {
    method: 'GET',
    headers: {
        'Authorization': 'Bearer ' + token,
        'Content-Type': 'application/json'
    }
})
.then(response => response.json())
.then(data => console.log(data));

Security Features:

  • Certificate Pinning: App only trusts specific certificates
  • HSTS: Force HTTPS for all requests
  • Certificate Transparency: Public log of all certificates

7. TLS Attacks and Mitigations

Historical Attacks:

Attack Year Target Mitigation
BEAST 2011 TLS 1.0 CBC mode Use TLS 1.1+ or RC4
CRIME 2012 TLS compression Disable TLS compression
Heartbleed 2014 OpenSSL implementation Update OpenSSL, revoke certificates
POODLE 2014 SSL 3.0 CBC mode Disable SSL 3.0
FREAK 2015 Export-grade RSA Remove weak cipher suites
Logjam 2015 Weak DHE parameters Use strong DH groups (2048+ bit)

Modern Security Best Practices:

  • Use TLS 1.2 minimum (TLS 1.3 preferred)
  • Strong cipher suites only (AEAD ciphers, forward secrecy)
  • Proper certificate validation
  • HSTS headers to force HTTPS
  • Certificate Transparency monitoring
  • Regular security updates

8. Performance and Optimization

TLS Performance Costs:

  • CPU Overhead: Cryptographic operations
  • Memory Usage: Session state, certificates
  • Network Latency: Additional round trips
  • Bandwidth: Certificate chain, larger packets

Optimization Strategies:

1. Session Resumption:

  • Session IDs: Server stores session state
  • Session Tickets: Encrypted session state stored by client
  • Benefit: Skip expensive handshake for repeat connections

2. Hardware Acceleration:

  • AES-NI: CPU instructions for AES
  • Hardware Security Modules: Dedicated crypto processors
  • SSL Offload Cards: Dedicated TLS processing

3. Protocol Optimizations:

  • HTTP/2: Multiplexing reduces connections
  • OCSP Stapling: Server provides revocation status
  • False Start: Send application data before handshake complete

4. Certificate Optimization:

  • Smaller certificates: ECDSA vs RSA
  • Certificate chains: Minimize intermediate CAs
  • Certificate caching: Reuse certificates across connections

9. Future of TLS

Post-Quantum Cryptography:

Challenge: Quantum computers threaten current public-key cryptography

Solution: Quantum-resistant algorithms

  • NIST Standardization: CRYSTALS-Kyber (key exchange), CRYSTALS-Dilithium (signatures)
  • Hybrid Approach: Combine classical and post-quantum algorithms
  • Timeline: Gradual migration over next decade

Encrypted Client Hello (ECH):

  • Problem: SNI reveals which site is being visited
  • Solution: Encrypt the entire Client Hello
  • Privacy Benefit: Hide destination from network observers

QUIC and TLS 1.3:

  • QUIC: New transport protocol by Google
  • Integration: TLS 1.3 built into QUIC
  • Benefits: Faster connection establishment, better mobile performance

Conclusion: TLS is the foundation of internet security, protecting billions of connections daily. Understanding its internals helps appreciate both its strengths and the ongoing evolution needed to address new threats and performance requirements.

 

Digital Cash and Bitcoin

Digital Cash Requirements:

  • Double-Spending Prevention: Ensure digital money can’t be spent twice
  • Privacy: Transactions should be anonymous or pseudonymous
  • Unforgeability: Only authorized entities can create valid money
  • Transferability: Money can be passed from person to person
  • Divisibility: Support for fractional amounts

Cryptographic Primitives:

  • Blind Signatures: Sign without seeing content (Chaum’s e-cash)
  • Hash Functions: Create tamper-evident transaction records
  • Digital Signatures: Prove ownership and authorize transfers
  • Merkle Trees: Efficiently verify large sets of transactions
  • Proof of Work: Consensus mechanism for distributed systems

Bitcoin Innovation:

  • Blockchain: Distributed ledger without central authority
  • Mining: Incentivized transaction processing and security
  • UTXO Model: Unspent Transaction Outputs for accounting
  • Script System: Programmable transaction conditions
  • Network Consensus: Agreement on transaction history