Symmetric Key Cryptography: Algorithms, Modes, Attacks & Applications

Core Concepts: What is Symmetric Key Cryptography?

Symmetric key cryptography is a shared-secret encryption method where the same key is used for both encryption and decryption. Unlike asymmetric cryptography (Unit 5), it relies on a single key, making it faster but requiring secure key distribution.

How It Works: The Basics

1. Sender and Receiver agree on a secret key (e.g., 128-bit string).
2. Sender uses the key + algorithm (e.g., AES) to encrypt plaintext → ciphertext.
3. Receiver uses the same key + algorithm to decrypt ciphertext → plaintext.

stateDiagram-v2
    [*] --> Plaintext: "Sender has data"
    Plaintext --> Encryption: "Apply key + algorithm (e.g., AES-128)"
    Encryption --> Ciphertext: "Output: unreadable data"
    Ciphertext --> Transmission: "Sent over network"
    Transmission --> Decryption: "Receiver applies same key"
    Decryption --> Plaintext: "Recover original data"
    Plaintext --> [*]

Key Properties:

• Confidentiality: Only parties with the key can read the data.
• Integrity: If the key is compromised, the ciphertext can be decrypted (unlike hash functions, which are one-way).
• Speed: Symmetric algorithms are 100–10,000x faster than asymmetric (e.g., RSA).

Key Algorithms: DES vs. AES vs. Blowfish

1. Data Encryption Standard (DES)

• Developed: 1970s (NIST, USA).
• Key Size: 56 bits (now obsolete due to brute-force attacks).
• Structure:
  • 16 rounds of Feistel network (substitution + permutation).
  • S-boxes (non-linear substitution boxes) confuse attackers.
• Weaknesses:
  • Vulnerable to differential cryptanalysis (analyzing input-output patterns).
  • Triple DES (3DES) was a temporary fix (3 × 56-bit keys).

2. Advanced Encryption Standard (AES)

• Standardized: 2001 (NIST, replaces DES).
• Key Sizes: 128, 192, or 256 bits.
• Structure:
  • SubBytes (S-box substitution),
  • ShiftRows (permutation),
  • MixColumns (linear mixing),
  • AddRoundKey (XOR with key).
• Rounds: 10 (128-bit key), 12 (192-bit), or 14 (256-bit).
• Advantages:
  • No known practical attacks (resistant to differential/linear cryptanalysis).
  • Used in WPA2, TLS, SSH, and eSewa transactions.

3. Blowfish

• Designed: 1993 (Bruce Schneier).
• Key Size: Up to 448 bits.
• Structure:
  • 16 rounds (variable for longer keys).
  • Uses P-boxes (permutation) and S-boxes (substitution).
• Use Cases:
  • Older systems (e.g., PGP/GPG for email encryption).
  • Less common today (AES dominates).

Encryption Modes: How Data is Processed

Modes determine how blocks of plaintext (typically 64 or 128 bits) are encrypted. Poor modes (e.g., ECB) leak patterns; secure modes (e.g., GCM) add authentication.

Comparison Table: Common Modes

Key Management: The Achilles’ Heel

Symmetric keys must be:

1. Random: Generated via CSPRNG (Cryptographically Secure Pseudorandom Number Generator).
2. Securely Stored: Never hardcoded (use key derivation functions like PBKDF2 or Argon2).
3. Distributed: Shared via:
   • Pre-shared keys (e.g., Wi-Fi passwords).
   • Key exchange protocols (e.g., Diffie-Hellman in TLS).
   • Key escrow (backup keys for recovery).

Worked Example: eSewa Transaction Key Exchange

1. User enters PIN → PBKDF2 derives a 256-bit key from PIN + salt.
2. eSewa server generates a session key (AES-256) for the transaction.
3. Session key is encrypted with the user’s public key (asymmetric) and sent.
4. User’s device decrypts the session key using its private key.
5. Transaction data (amount, recipient) is encrypted with the session key (symmetric, fast).

sequenceDiagram
    participant User
    participant eSewaServer
    User->>eSewaServer: PIN entered (hashed via PBKDF2)
    eSewaServer->>eSewaServer: Generate Session Key (AES-256)
    eSewaServer->>User: Encrypt Session Key with User's Public Key
    User->>User: Decrypt Session Key with Private Key
    User->>eSewaServer: Encrypt Transaction Data with Session Key
    eSewaServer->>User: Decrypt & Process Payment

Attacks on Symmetric Cryptography

Performance vs. Security Trade-offs

In the Real World

1. eSewa (Nepal)

   • Idea Used: AES-256 in GCM mode for encrypting transaction data between your phone and eSewa’s servers.
   • How: When you pay via QR code, your device generates a session key, encrypts the payment details, and sends them. eSewa’s server decrypts using the same key (shared via TLS handshake). The GCM mode ensures both confidentiality and integrity (detects tampering).

2. Khalti (Nepal)

   • Idea Used: Symmetric encryption for tokenization (replacing card numbers with encrypted tokens).
   • How: When you link a bank card to Khalti, your card details are encrypted with a master key (stored securely by Khalti). During payments, only the token (not the real card number) is sent to merchants, encrypted with a session key derived from your device’s key pair.

3. Ncell’s 4G/LTE Encryption

   • Idea Used: AES in CTR mode for encrypting voice/data packets.
   • How: Your phone and Ncell’s tower agree on a temporary key during the handshake. Voice packets are encrypted block-by-block using AES-CTR, which allows parallel processing (critical for real-time calls). Weakness: If the key is reused (e.g., due to a bug), calls can be decrypted.

4. Daraz’s Order Processing

   • Idea Used: Symmetric hashing (HMAC-SHA256) to verify order integrity.
   • How: When you place an order, Daraz computes a hash of your order details using a shared secret key. This hash is sent to the warehouse to authenticate that the order wasn’t altered in transit. If the hash doesn’t match, the order is rejected (preventing tampering).

5. Nepal Rastra Bank’s SWIFT Messages

   • Idea Used: Triple DES (3DES) for legacy SWIFT transactions (being phased out to AES).
   • How: When NRB sends interbank funds to, say, India, the SWIFT message is encrypted with a 3DES key shared between banks. While 3DES is slow, it’s still used for compliance with older systems. Risk: If an attacker guesses the key (possible with quantum computing), funds could be diverted.

Worked Example: Encrypting a Message with AES-CBC

Scenario: You’re sending a secret message to a friend using WhatsApp (which uses AES-256-CBC under the hood).

1. Plaintext: "Meet at 5pm near the temple"
2. Key: AES-256 key (256 random bits, e.g., 0x603deb1015ca71be2b73ae10857d77811f352c073b6108d72d9810a30914dff4)
3. IV: 16 random bytes (e.g., 0x000102030405060708090a0b0c0d0e0f)

Step-by-Step:

Output:

• Ciphertext: 0x3ad77bb40d7a3660a89ecaf32466ef97f30d822eaf37ef08... (hex)
• Friend decrypts by reversing the steps (XOR with previous ciphertext block, then AES-256 decrypt).

Real-World Tie-In:

• WhatsApp uses Signal Protocol, which combines Diffie-Hellman (asymmetric) for key exchange + AES-256-CBC for message encryption. If an attacker intercepts your messages, they see only gibberish like:

  874a2b1e6d9f3c8a7b5e4d2f1a9c7b6e5d4a3f2c1b0a9e8d7c6b5a4f3e2d1c0b9a8...
  

Common Pitfalls and How to Avoid Them

1. Reusing Keys

   • ❌ Bad: Using the same AES key for all users (e.g., in a database).
   • ✅ Fix: Generate a unique key per user/session.

2. ECB Mode for Sensitive Data

   • ❌ Bad: Encrypting a JPEG with ECB → visible patterns (e.g., faces in images).
   • ✅ Fix: Use CBC or GCM.

3. Weak Key Generation

   • ❌ Bad: key = "password123" (predictable).
   • ✅ Fix: Use CSPRNG (e.g., /dev/urandom or secrets module in Python).

4. Ignoring IVs

   • ❌ Bad: Using IV = 0 or repeating IVs.
   • ✅ Fix: Generate a random IV per encryption (send IV with ciphertext).

5. Not Validating Libraries

   • ❌ Bad: Using outdated OpenSSL (e.g., Heartbleed vulnerability).
   • ✅ Fix: Update to OpenSSL 3.x or use Libsodium.

Exam Tip

What Examiners Look For

1. Definitions:

   • Clearly distinguish between block ciphers (AES, DES) and stream ciphers (RC4).
   • Explain Feistel networks vs. Substitution-Permutation Networks (SPN).

2. Worked Examples:

   • Must show:
     • Plaintext → ciphertext steps (e.g., AES-CBC).
     • Key derivation (e.g., PBKDF2).
     • Attack scenarios (e.g., "How would an attacker exploit ECB mode?").

3. Comparisons:

   • Tables comparing DES vs. AES vs. Blowfish (speed, security, use cases).
   • Modes of operation (ECB vs. CBC vs. GCM).

4. Real-World Applications:

   • Link to Nepali examples (eSewa, Khalti, Ncell) or global (TLS, WPA2).
   • Explain why AES-256 is used in banks (not DES) and how session keys work.

5. Common Mistakes to Avoid:

   • ❌ Saying "AES is slower than DES" (actually, AES is faster on modern hardware).
   • ❌ Confusing symmetric (same key) with asymmetric (public/private key).
   • ❌ Forgetting IVs in CBC/CTR modes.

High-Scoring Answers Include:

• Diagrams: Draw AES rounds, Feistel network, or CBC mode.
• Code Snippets: Show Python/Pseudocode for encryption (e.g., using pycryptodome).
• Attack Scenarios: "How would an attacker break this system?" (e.g., "Reusing IVs in CBC allows pattern leakage").
• Nepal Context: Tie examples to eSewa, Khalti, or Ncell (examiners love local relevance).

Quick Revision Checklist

• Can you list 3 symmetric algorithms and their key sizes?
• Draw AES encryption rounds and label SubBytes/ShiftRows.
• Explain why ECB is insecure with a real-world analogy (e.g., Daraz order patterns).
• Describe how eSewa uses symmetric keys for transactions.
• Name 2 side-channel attacks and how to mitigate them.
• Compare CBC vs. GCM in a table.