Some Random Notes

1. Security and Cryptography Fundamentals v0

5 min read

1. System Design Security Layers: Architecture Classification

To secure a distributed system, you cannot rely on a single barrier. Enterprise security demands Defense in Depth across distinct layers.

graph TD
    subgraph Client ["1. Perimeter & Client Layer"]
        A["API Gateway / WAF / Rate Limiting"]
    end

    subgraph Transport ["2. Transport Layer (In Transit)"]
        B["TLS 1.3 / mTLS / Certificate Pinning"]
    end

    subgraph App ["3. Application & API Layer"]
        C["Spring Security / OAuth2 / JWT / RBAC / Password Hashing (Argon2id)"]
    end

    subgraph Message ["4. Event Streaming Layer"]
        D["Kafka SASL_SSL / mTLS / Topic-Level ACLs"]
    end

    subgraph Storage ["5. Storage & Data Layer (At Rest)"]
        E["AES-256-GCM / Envelope Encryption / AWS KMS / pgvector encryption"]
    end

    A --> B --> C --> D --> E

2. Cryptographic Primitives: MD5, SHA, and RSA

A. Hashing Functions: MD5 vs. SHA Family

Hashing is a one-way cryptographic mathematical operation that converts data of arbitrary size into a fixed-size fingerprint (digest).

1. MD5 (Message-Digest Algorithm 5)

  • History: Developed by Ronald Rivest in 1991 as a successor to MD4. Designed to be fast and simple.
  • The Need: Rapid file integrity checking and checksum verification.
  • The Vulnerability: Cryptographically broken. In 2004, researchers demonstrated practical collision attacks (generating two different files with the exact same MD5 hash).
  • System Design Verdict: Never use MD5 for security. Acceptable only for legacy checksums or non-cryptographic hash tables (e.g., hash maps).

2. SHA Family (SHA-2, SHA-3)

  • History: Published by NIST starting in 2001 (SHA-2) and selected via competition in 2015 (SHA-3, based on the Keccak sponge construction).
  • Implementation Mechanics: Uses a Merkle-Damgård construction (SHA-2) or sponge construction (SHA-3) applying bitwise operations, modular additions, and compression functions.
  • The Need: Cryptographic integrity, digital signatures, blockchain blocks, and secure tokens.
  • The Avalanche Effect: Changing a single bit in the input flips roughly 50% of the bits in the output digest.

B. Asymmetric Cryptography: RSA & Public Key Infrastructure (PKI)

  • History: Invented by Ron Rivest, Adi Shamir, and Leonard Adleman in 1977.
  • The Need: Secure key exchange and digital signatures across untrusted networks where parties have no pre-shared secret.
  • Mathematical Foundation: Relies on the integer factorization problem—it is easy to multiply two large prime numbers ( and ) to get a composite number , but extremely difficult to factor back into and if they are hundreds of digits long.

Key Generation Algorithm Overview

  1. Choose two distinct large random primes and .
  2. Compute modulus .
  3. Compute Euler’s totient function: .
  4. Choose an integer (public exponent, typically ) such that and .
  5. Compute the private exponent such that .
  6. Public Key: ; Private Key: .

WARNING

Raw RSA is mathematically deterministic and vulnerable to chosen-ciphertext attacks. Production systems must use secure padding schemes like OAEP (Optimal Asymmetric Encryption Padding) for encryption and PSS (Probabilistic Signature Scheme) for signatures.

3. Password Hashing: Beyond MD5/SHA for Credentials

If you hash a user’s password using standard SHA-256, an attacker running a GPU cluster can compute billions of guesses per second, exploiting precomputed rainbow tables.

  • The Solution: Use slow, salt-integrated, memory-hard hashing algorithms.
  • Key Algorithms:
  • Bcrypt: Relies on the Blowfish cipher and features a tunable cost factor (work factor).
  • Argon2id (Winner of Password Hashing Competition): Combines data-independence and data-dependence, making it highly resistant to GPU and ASIC parallel cracking hardware by consuming massive CPU memory.

4. Layer-by-Layer Enterprise Security Implementation

Layer 2: Transport Layer Security (TLS 1.3 & mTLS)

  • TLS 1.3 Features: Reduced handshake to 1-RTT (or 0-RTT for resumed sessions), eliminated weak ciphers (RC4, DES, CBC-mode), and encrypted all handshake parameters after the Server Hello to prevent surveillance.
  • mTLS (Mutual TLS): Both the client and server present X.509 certificates to each other. Widely used in service-to-service microservices architectures (e.g., Istio, Linkerd mesh networks) to guarantee Zero Trust identity verification without application-level credential passing.

Layer 3: Application, REST, & PKI (Java Security)

  • REST Security: Stateless architecture using JSON Web Tokens (JWT) digitally signed (JWS) or encrypted (JWE) using RSA or HMAC-SHA256.
  • Java Security / JCA (Java Cryptography Architecture): Enterprise Java applications use javax.crypto.Cipher, KeyStore, and Spring Security filter chains.
  • PKI Integration: Java applications load trusted root certificates into a secure Java Truststore (cacerts) and private identity keys into a Keystore (.p12 or JKS) to establish outbound TLS or sign payloads.

Layer 4: Event Streaming Security (Apache Kafka)

  • Encryption in Transit: Configured via ssl.endpoint.identification.algorithm=HTTPS and robust cipher suites between clients, brokers, and ZooKeeper/Kraft metadata nodes.
  • Authentication: Implemented using SASL/SCRAM (Salted Challenge Response Authentication Mechanism) or mTLS.
  • Authorization: Enforced via Kafka ACLs (Access Control Lists) mapping Principal names (e.g., User:producer-service) to topic resource permissions (READ, WRITE, DESCRIBE).

Layer 5: Storage Layer (At Rest & Envelope Encryption)

  • AES-256-GCM (Galois/Counter Mode): Provides both confidentiality (encryption) and integrity/authenticity (authenticated encryption with associated data - AEAD).
  • Envelope Encryption Architecture:
  1. Data Key (DEK): Encrypts the actual database record or file using AES-256.
  2. Key Encryption Key (KEK / Master Key): Stored securely in an external HSM or cloud KMS (e.g., AWS KMS, HashiCorp Vault) which encrypts the DEK.
  3. Storage Pattern: The ciphertext payload and encrypted DEK are stored together. Decryption requires calling the KMS with proper IAM/RBAC permissions.

Further Reading & Standards References

  1. NIST Special Publication 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management (Crucial for password hashing and credential management).
  2. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (Defines modern secure transport architecture).
  3. OWASP Top Ten Web Application Security Risks: Industry standard reference for application-layer threat modeling.
  4. AWS Key Management Service Cryptographic Details: Whitepaper covering envelope encryption patterns and HSM standards.

Backlinks