Kryptographie - Grundlagen der digitalen Sicherheit
Cryptography protects confidentiality, integrity, and authenticity: symmetric encryption (AES-256-GCM) for performance, asymmetric encryption (RSA-4096, ECC P-384) for key exchange and signatures, and hybrid methods that combine both. TLS 1.3 (mandatory, 1.0/1.1 deprecated), PKI and certificate chains, quantum threat from Shor’s algorithm → post-quantum cryptography (CRYSTALS-Kyber, CRYSTALS-Dilithium). BSI recommends: AES-256, RSA-3072+, SHA-256+.
Cryptography is the foundation of information security—without encryption and cryptographic protocols, modern IT security would be unthinkable.
Symmetric Cryptography
In symmetric cryptography, the sender and receiver use the same key for encryption and decryption.
AES (Advanced Encryption Standard)
AES is the standard solution for symmetric encryption—a block cipher that processes data in 128-bit blocks. The available key lengths are AES-128 (sufficient) and AES-256 (recommended by the BSI).
Regarding operating modes:
- ECB (Electronic Codebook): Never use—identical plaintext blocks produce identical ciphertext blocks; patterns remain visible
- CBC (Cipher Block Chaining): Obsolete for new applications
- GCM (Galois/Counter Mode): Recommended—offers authenticated encryption, combining encryption and integrity protection in a single pass
With hardware acceleration (AES-NI on modern CPUs), AES achieves over 10 GB/s. This eliminates any performance-related arguments against encryption.
ChaCha20-Poly1305
A modern stream cipher as an alternative to AES, particularly suitable for systems without AES hardware acceleration (ARM processors in IoT and mobile devices). ChaCha20-Poly1305 is secure against timing attacks (constant time) and is used in TLS 1.3, WireGuard VPN, and the Signal protocol.
3DES (Triple-DES)
3DES is deprecated and must be replaced by AES in all new systems. NIST classified the algorithm as obsolete in 2017 and banned it in 2024. The meet-in-the-middle attack significantly reduces effective security.
The Central Problem of Symmetric Cryptography
How does the key reach the recipient securely? The solution is asymmetric cryptography for key exchange.
Asymmetric Cryptography (Public-Key Methods)
The basic mathematical principle: A public key may be freely distributed, while the private key remains secret. Anything encrypted with the public key can only be decrypted with the private key—and vice versa.
RSA (Rivest-Shamir-Adleman)
The security of RSA is based on the problem of factoring large numbers. The recommended key lengths:
| Key Length | Status |
|---|---|
| RSA-1024 | Insecure – can be broken in hours |
| RSA-2048 | Still acceptable for short durations |
| RSA-3072 | BSI recommendation until 2031 |
| RSA-4096 | Future-proof (but slower) |
RSA is about 1,000 times slower than AES and is therefore only used for small amounts of data: key exchange (encrypts the AES key), digital signatures, and TLS certificates.
ECC (Elliptic Curve Cryptography)
ECC is based on the discrete logarithm problem on elliptic curves and offers the same level of security as RSA with significantly shorter keys:
- P-256 (256 bits) ≈ RSA-3072 in terms of security strength
- P-384 (384 bits): BSI recommendation
- Ed25519: modern variant, very fast and immune to errors caused by poor randomness
ECC is used in TLS, SSH, Bitcoin, Signal, and secure email.
Diffie-Hellman Key Exchange
ECDH (Elliptic Curve Diffie-Hellman) enables key agreement between two parties without a pre-shared key. Combined with Perfect Forward Secrecy (PFS), each session receives a new, ephemeral key. Even if the long-term private key is compromised later, recorded past traffic cannot be decrypted. PFS is mandatory in TLS 1.3.
TLS - Transport Layer Security
TLS secures communication over the Internet. The version is crucial here:
| Version | Status |
|---|---|
| SSL 2.0/3.0 | Prohibited (POODLE, DROWN, many other vulnerabilities) |
| TLS 1.0 | Deprecated (PCI DSS bans it starting in 2018) |
| TLS 1.1 | Deprecated (disabled since 2020) |
| TLS 1.2 | Still acceptable (only with secure cipher suites) |
| TLS 1.3 | Recommended (2018, significantly more secure and faster) |
TLS 1.3 Improvements
TLS 1.3 reduces the allowed cipher suites to three—all with Perfect Forward Secrecy:
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256
Additional improvements: 0-RTT handshake (faster, but with replay risk), no more RSA key exchange (only ECDH with PFS), and encrypted handshake messages (no more metadata leaks).
NGINX Configuration (Secure TLS Settings)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off; # TLS 1.3: Client preference applies
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
ssl_stapling on; # OCSP Stapling
ssl_stapling_verify on;Insecure cipher suites that must always be blocked: *_RC4_* (broken since 2001), *_NULL_* (no encryption), *_EXPORT_* (intentionally weakened), *_DES_* (broken since 1999), and *_anon_* (no authentication).
Digital Signatures and PKI
Digital Signature
The principle of the digital signature:
- Creation: Hash(document) → encrypted with private key = signature
- Verification: Signature → decrypted with public key = hash value → compared with the calculated hash of the document
This ensures: authenticity (only the private key owner can sign), integrity (document unchanged, since the hash matches), and non-repudiation (signature binds the signer).
Certificate Chain (Chain of Trust)
Root CA (self-signed)
→ Intermediate CA (signed by Root)
→ End-Entity Certificate (signed by Intermediate)Browsers check whether the certificate is signed by a trusted CA. The CA store contains around 150 root CAs (Mozilla/Windows/macOS). Certificate Transparency (CT) ensures that all certificates are publicly logged.
Certificate Types
- DV (Domain Validation): Domain only verified - Let's Encrypt, free
- OV (Organization Validation): Organization verified
- EV (Extended Validation): Maximum verification (padlock icon in the browser)
- Wildcard:
*.example.com- all subdomains - SAN (Subject Alternative Name): Multiple domains in a single certificate
Certificate Revocation
- CRL (Certificate Revocation List): Daily updated revocation list
- OCSP (Online Certificate Status Protocol): Real-time verification
- OCSP Stapling: Server caches OCSP response – improves privacy and performance
- OCSP Must-Staple: Enforces stapling support
Post-Quantum Cryptography
The Quantum Threat
Quantum computers can break RSA and ECC in polynomial time using Shor’s algorithm – theoretically. In practice, no sufficiently powerful quantum computer exists yet, but the "harvest now, decrypt later" attack scenario is already active: Attackers are collecting encrypted data today and plan to decrypt it as soon as quantum computers are powerful enough.
NIST estimates that cryptographically relevant quantum computers will emerge between 2030 and 2040.
NIST Post-Quantum Standards (finalized in 2024)
CRYSTALS-Kyber (now: ML-KEM): Key exchange (Key Encapsulation Mechanism) as a replacement for ECDH/RSA encryption. Lattice-based—secure against quantum computers. Already in use in Signal and newer TLS implementations.
CRYSTALS-Dilithium (now: ML-DSA): Digital signatures as a replacement for RSA/ECDSA signatures. Also lattice-based.
SPHINCS+ (now: SLH-DSA): Hash-based signatures as a more conservative alternative to Dilithium.
Migration Strategy (Crypto-Agility)
- Inventory: Which cryptographic algorithms are in use?
- Prioritization: What protects long-term data (health, finance)?
- Hybrid: Run classical and post-quantum methods in parallel (transition phase)
- Migration: Complete by 2030 at the latest (BSI recommendation)
Symmetric Cryptography and Quantum Computers
Symmetric methods are less affected: AES-256 remains secure, as Grover’s algorithm effectively halves the key length—256 bits become 128 bits in practice, which is sufficient. AES-128, on the other hand, provides only 64 bits of security against quantum attacks—no longer sufficient. SHA-256 is secure; SHA-384/512 are even better suited for post-quantum scenarios.
The acute problem is asymmetric cryptography—not symmetric.
Hashing and MACs
Cryptographic Hash Functions
A cryptographic hash function has three essential properties: It is a one-way function (the original cannot be computationally derived from the hash), collision-resistant (no M1 ≠ M2 with identical hashes), and exhibits avalanche effect (a single-bit change in the input alters approximately 50% of the hash bits).
| Algorithm | Status |
|---|---|
| MD5 | Banned - Collisions can be generated in seconds |
| SHA-1 | Banned - Google SHAttered 2017: Collision generated |
| SHA-256 | Secure, 256-bit output (gold standard for signatures) |
| SHA-384 | Recommended for high security requirements |
| SHA-512 | 512-bit, particularly suitable for post-quantum transition |
| SHA-3 | Keccak architecture, not a successor to SHA-2 |
| BLAKE3 | Very fast (>10 GB/s), secure, modern |
Password hashing (special case!)
Standard hash functions are too fast—GPUs can compute billions of hashes per second. Password hashing requires intentionally slow functions:
- bcrypt: Gold standard with adjustable work factor (e.g., cost=12)
- Argon2id: Winner of the 2015 Password Hashing Competition; memory-hard—GPU cracking becomes very expensive
- scrypt: Similar to Argon2, also memory-hard
- PBKDF2: Acceptable, used in FIPS environments
- MD5/SHA-1/SHA-256 for passwords: Strictly prohibited
Message Authentication Codes (MACs)
HMAC (Hash-based MAC): HMAC-SHA256 provides both integrity and authenticity. HMAC(Key, Message) generates a token that proves the message originated from someone with the correct key. Uses: JWT (JSON Web Token), API signatures, webhook validation.
AEAD (Authenticated Encryption with Associated Data): A modern design that always combines encryption and authenticity—AES-GCM and ChaCha20-Poly1305 are the most important examples.
