The Complete Guide to Cryptography & Hashing (2026): Every Algorithm Explained

Name: Cryptography & Hashing Algorithm Comparison Dataset 2026
Creator: OnlineTools4Free
Published: 2026-04-14
License: https://creativecommons.org/licenses/by/4.0/

Executive Summary

Cryptography is the foundation of digital security. Every HTTPS connection, every SSH login, every cryptocurrency transaction, every encrypted message relies on mathematical algorithms that have been refined over decades. In 2026, we stand at a pivotal moment: classical cryptography continues to protect billions of connections daily, while the emerging threat of quantum computing is driving the largest cryptographic migration in history.

This guide covers every major cryptographic algorithm in use today, from symmetric ciphers (AES, ChaCha20) through asymmetric systems (RSA, ECC, Diffie-Hellman) to hash functions (SHA-256, BLAKE3) and password hashing (bcrypt, Argon2). We explain the TLS handshake step by step, break down the quantum computing threat with realistic timelines, and survey how cryptography is applied across real-world systems from HTTPS to Bitcoin wallets.

The report includes performance benchmarks, security level comparisons, an interactive hash generator, and downloadable datasets. Whether you are a developer implementing encryption, a security professional evaluating algorithms, or a student learning the fundamentals, this guide provides the depth and breadth you need.

83.2%

TLS 1.3 adoption in 2026

+6.8 pts from 2025

95.4%

Websites using HTTPS

Up from 30% in 2015

60+

Glossary terms defined

FAQ questions answered

AES-256 remains the gold standard for symmetric encryption, with hardware acceleration (AES-NI) enabling throughput exceeding 3,100 MB/s on modern CPUs. ChaCha20 is the preferred alternative when AES hardware is unavailable.
BLAKE3 is now 3-7x faster than SHA-256 thanks to parallelization and SIMD optimization, reaching 6,800 MB/s. However, SHA-256 remains the standard for compliance-sensitive applications.
NIST finalized post-quantum standards in 2024 (ML-KEM, ML-DSA, SLH-DSA), and production deployments began in 2026. The “harvest now, decrypt later” threat makes early migration critical for sensitive data.
Argon2id is the OWASP #1 recommendation for password hashing, limiting GPU attackers to approximately 8,500 hashes per second versus 64 billion for MD5. The difference is 7.5 million to one.

Part 1: History of Cryptography

Cryptography is as old as writing itself. The earliest known use of cryptography dates to around 1900 BCE, when an Egyptian scribe used non-standard hieroglyphs in an inscription. The practice of concealing messages has evolved continuously over four millennia, driven by the perpetual arms race between code makers and code breakers.

Ancient and Classical Cryptography

The Spartan scytale (circa 500 BCE) was one of the earliest transposition ciphers. A strip of leather was wrapped around a rod of specific diameter, and the message was written along the length. Only someone with a rod of the same diameter could read it. This represents the fundamental concept of a key: a piece of information required to decrypt the message.

The Caesar cipher (circa 100 BCE) is perhaps the most famous classical cipher. Julius Caesar reportedly used a simple substitution cipher that shifted each letter by three positions: A became D, B became E, and so on. With only 25 possible keys (shifts), this cipher is trivially broken today. But it establishes the concept of a substitution cipher, where each character is replaced by another character according to a fixed rule.

In 800 CE, the Arab polymath Al-Kindi published the first known description of frequency analysis. He observed that in any language, certain letters appear more frequently than others (in English, ‘e’ is the most common letter at roughly 12.7% frequency). By analyzing the frequency of characters in ciphertext, an analyst can deduce the substitution mapping. Frequency analysis breaks all simple substitution ciphers and remained the primary cryptanalytic technique for over 800 years.

The Vigenère cipher (1553) was a major advancement. Instead of a single substitution alphabet, it uses multiple alphabets selected by a keyword. Each letter of the keyword determines a different shift for the corresponding plaintext letter. This polyalphabetic substitution defeated frequency analysis and was considered unbreakable for centuries, earning the nickname “le chiffre indéchiffrable.” Charles Babbage and Friedrich Kasiski independently broke it in the 19th century by discovering that repeated keyword letters create patterns in the ciphertext.

The Mechanical Era

The 20th century brought mechanical encryption devices. The Enigma machine (patented 1918, used extensively by Nazi Germany in World War II) used rotating electrical rotors to implement a polyalphabetic substitution cipher with an astronomical number of possible settings (approximately 10^23 in later versions). The breaking of Enigma at Bletchley Park, led by Alan Turing and colleagues using electromechanical “Bombe” machines, is widely credited with shortening the war by two years and establishing the foundations of modern computing.

The one-time pad (Vernam cipher, 1917) deserves special mention as the only provably unbreakable encryption system. It uses a random key at least as long as the message, used only once. Each character is XORed with the corresponding key character. With a truly random key, every possible plaintext is equally likely, making cryptanalysis impossible regardless of computing power. The practical limitation is key distribution: the key must be as long as the message and securely shared in advance. The Moscow-Washington hotline reportedly used one-time pads during the Cold War.

The Digital Revolution

The publication of the Diffie-Hellman key exchange in 1976 transformed cryptography by solving the key distribution problem. For the first time, two parties could establish a shared secret over an insecure channel without prior contact. The following year, RSA (Rivest, Shamir, Adleman) provided the first practical public-key cryptosystem, enabling both encryption and digital signatures with a pair of mathematically related keys.

DES (Data Encryption Standard) was adopted as a federal standard in 1977, providing a standardized symmetric cipher. Its 56-bit key proved too short: by 1999, a dedicated machine cracked DES in 22 hours. The successor, AES (Advanced Encryption Standard), was selected in 2001 after a rigorous competition. The Rijndael algorithm, designed by Belgian cryptographers Joan Daemen and Vincent Rijmen, won against 14 competitors and remains the most widely used encryption algorithm today.

The timeline below shows key milestones in cryptographic history, from ancient techniques through the digital era to the emerging post-quantum age.

The Post-Quantum Era (2020s)

The 2020s represent a new phase in cryptographic history: the transition from classical to quantum-resistant algorithms. In 2016, NIST initiated the Post-Quantum Cryptography Standardization Process, receiving 82 submissions for quantum-safe key exchange and digital signature algorithms. After four rounds of evaluation spanning eight years, NIST published three post-quantum standards in 2024: ML-KEM (Module-Lattice Key Encapsulation Mechanism, based on CRYSTALS-Kyber), ML-DSA (Module-Lattice Digital Signature Algorithm, based on CRYSTALS-Dilithium), and SLH-DSA (Stateless Hash-based Digital Signature Algorithm, based on SPHINCS+).

The urgency of post-quantum migration stems from the “harvest now, decrypt later” threat model. Intelligence agencies and advanced persistent threats are believed to be recording encrypted network traffic today, storing it until quantum computers capable of breaking current encryption become available. For data that must remain confidential for decades (state secrets, medical records, infrastructure designs), the protection must begin now, not when quantum computers arrive.

Chrome and Firefox began deploying hybrid key exchange (X25519 + ML-KEM-768) in TLS handshakes in 2024. This hybrid approach uses both a classical algorithm (X25519) and a post-quantum algorithm (ML-KEM) simultaneously, ensuring security even if either algorithm is later found to be vulnerable. The overhead is minimal: ML-KEM adds approximately 1,100 bytes to the key exchange and about 0.1ms of computation. Signal Messenger adopted the PQXDH protocol (incorporating X25519 and ML-KEM-768) for its end-to-end encryption in 2023.

Cryptographic History Timeline

28 rows

Year	Event	Era
1900 BCE	Egyptian hieroglyphs with non-standard symbols	Ancient
500 BCE	Spartan scytale cipher	Ancient
100 BCE	Caesar cipher (substitution cipher)	Ancient
800 CE	Al-Kindi publishes frequency analysis	Medieval
1467	Alberti cipher disk (polyalphabetic)	Renaissance
1553	Vigenere cipher published	Renaissance
1917	Vernam cipher / one-time pad	Modern
1918	Enigma machine patented	Modern
1943	Colossus breaks Lorenz cipher	Modern
1976	Diffie-Hellman key exchange published	Digital
1977	DES adopted as federal standard	Digital
1977	RSA algorithm published	Digital
1991	PGP released by Phil Zimmermann	Digital
1993	SHA-1 published by NIST	Digital
1994	SSL 1.0 developed by Netscape	Digital
1999	TLS 1.0 standardized (RFC 2246)	Digital
2001	AES selected (Rijndael wins)	Digital
2004	MD5 collision found by Wang et al.	Digital
2005	SHA-1 theoretical weakness found	Digital
2008	Bitcoin uses SHA-256 for mining	Digital
2012	NIST selects Keccak as SHA-3	Digital
2015	Argon2 wins Password Hashing Competition	Digital
2017	SHAttered: first SHA-1 collision (Google)	Digital
2018	TLS 1.3 standardized (RFC 8446)	Digital
2020	BLAKE3 released (3x faster than SHA-256)	Digital
2024	NIST finalizes post-quantum standards (FIPS 203-205)	Post-Quantum
2025	Chrome drops TLS 1.0/1.1 support completely	Post-Quantum
2026	ML-KEM/ML-DSA adoption begins in production	Post-Quantum

Part 2: Symmetric Encryption

Symmetric encryption uses the same key for both encryption and decryption. Both parties must share the key secretly. This creates the key distribution problem (solved by asymmetric cryptography for key exchange), but symmetric ciphers are 1000x+ faster than asymmetric ones, making them the workhorse of bulk data encryption.

Symmetric ciphers come in two flavors: block ciphers and stream ciphers. Block ciphers (AES, DES, Twofish) encrypt fixed-size blocks of data (typically 128 bits). Stream ciphers (ChaCha20, RC4) encrypt data one byte at a time by XORing with a pseudorandom keystream. Block ciphers require a mode of operation (ECB, CBC, CTR, GCM) to encrypt data larger than one block.

AES: The Global Standard

AES (Advanced Encryption Standard) is the most widely used symmetric cipher in the world. Selected by NIST in 2001 after a five-year competition, AES (based on the Rijndael algorithm) supports 128, 192, and 256-bit keys with a 128-bit block size. Its Substitution-Permutation Network (SPN) structure provides excellent diffusion and confusion.

AES-128 uses 10 rounds of substitution, shifting, mixing, and key addition. AES-192 uses 12 rounds, and AES-256 uses 14 rounds. Each round applies four transformations: SubBytes (byte substitution via S-box), ShiftRows (row-wise permutation), MixColumns (column-wise mixing), and AddRoundKey (XOR with round key). The S-box is carefully designed to resist linear and differential cryptanalysis.

Modern CPUs include AES-NI (AES New Instructions), hardware acceleration that performs AES rounds in a single CPU instruction. This pushes throughput to 4,200 MB/s for AES-128-GCM on modern hardware, making encryption effectively free from a performance perspective. AES-256 is slightly slower (3,100 MB/s) due to additional rounds but remains the required standard for classified (TOP SECRET) data.

ChaCha20: The Software Champion

ChaCha20 is a stream cipher designed by Daniel Bernstein in 2008 as an improvement over his earlier Salsa20. Unlike AES, ChaCha20 uses an ARX (Add-Rotate-XOR) structure that is naturally constant-time in software, eliminating timing side-channel vulnerabilities without special implementation care. This makes ChaCha20 particularly suitable for platforms without AES hardware acceleration.

Paired with the Poly1305 authenticator as ChaCha20-Poly1305, it provides authenticated encryption (AEAD). This combination is the default cipher in WireGuard VPN, a cipher suite in TLS 1.3, and widely used in mobile applications where ARM processors may lack AES hardware. On platforms with AES-NI, AES-GCM is faster; on platforms without it, ChaCha20-Poly1305 is 3x faster than software AES.

Legacy Ciphers: DES, 3DES, Blowfish

DES (Data Encryption Standard, 1977) was the first widely adopted symmetric standard. Its 56-bit key was a deliberate compromise between security and NSA concerns. By 1999, the Electronic Frontier Foundation cracked DES in 22 hours using a $250,000 purpose-built machine. DES is completely broken and must not be used.

Triple DES (3DES) applied DES three times with two or three different keys, providing an effective key length of 112 or 168 bits. However, its 64-bit block size creates vulnerability to birthday attacks (Sweet32 attack, 2016). NIST deprecated 3DES in 2023, and it must be replaced by AES in all new implementations.

Blowfish (Bruce Schneier, 1993) was a popular free alternative to DES with a variable key length up to 448 bits. However, its 64-bit block size creates the same Sweet32 vulnerability as 3DES. Schneier himself recommends using Twofish or AES instead. Blowfish lives on primarily in the bcrypt password hashing function, which uses its key schedule for deliberate slowness.

Key Finding

AES-256-GCM and ChaCha20-Poly1305 are the only two symmetric ciphers you should consider for new applications in 2026.

Both are AEAD (providing encryption + authentication), widely reviewed, and available in every modern TLS stack. Use AES when hardware acceleration is available; ChaCha20 otherwise.

Symmetric Algorithm Comparison

12 rows

Algorithm	Key Size (bits)	Block Size (bits)	Speed (MB/s)	Status	Rounds	Notes
DES	56	64	150	Broken	16	Brute-forced in 22 hours (1999). Key too short.
3DES	168	64	50	Deprecated	48	Sweet32 birthday attack. NIST deprecated 2023.
AES-128	128	128	4200	Secure	10	Standard for most applications. Hardware-accelerated (AES-NI).
AES-192	192	128	3600	Secure	12	Rarely used. AES-128 or AES-256 preferred.
AES-256	256	128	3100	Secure	14	Required for classified (TOP SECRET). Quantum-resistant key length.
Blowfish	448	64	180	Legacy	16	Small 64-bit block limits data safely encrypted. Superseded by Twofish.
Twofish	256	128	280	Secure	16	AES finalist. Patent-free. Used in some disk encryption.
ChaCha20	256	512	3800	Recommended	20	Software-friendly. Default TLS cipher when no AES-NI. Used by WireGuard.
Serpent	256	128	90	Secure	32	Most conservative AES finalist. Slower but highest security margin.
Camellia	256	128	2800	Secure	24	Japanese standard. Comparable to AES. Used in TLS in Japan.
CAST-256	256	128	120	Legacy	48	AES candidate. Rarely used outside PGP legacy.
RC4	2048	0	850	Broken	0	Stream cipher. Biases found. Banned from TLS (RFC 7465).

Symmetric Cipher Speed Comparison (MB/s on modern CPU)

Source: OnlineTools4Free Research

Block Cipher Modes of Operation

A block cipher by itself can only encrypt one block (128 bits for AES). To encrypt arbitrary-length data, you need a mode of operation. The choice of mode is critical for security. ECB (Electronic Codebook) is famously insecure because identical plaintext blocks produce identical ciphertext blocks, revealing patterns. The “ECB penguin” image is a well-known demonstration of this flaw.

GCM (Galois/Counter Mode) is the recommended mode for most applications in 2026. It combines CTR mode for encryption with a Galois field MAC for authentication, providing AEAD in a single pass. GCM is parallelizable, hardware-accelerated (PCLMULQDQ instruction), and the dominant mode in TLS 1.3. The critical requirement: GCM nonces must never be reused with the same key. Nonce reuse in GCM is catastrophic, revealing the authentication key and potentially the plaintext.

For disk encryption, XTS mode is the standard (used by LUKS, BitLocker, FileVault). XTS encrypts each sector independently using a tweak derived from the sector number, allowing random access to any sector without decrypting preceding sectors. It does not provide authentication (disk encryption has different threat models than network encryption).

Block Cipher Modes of Operation

8 rows

Mode	Full Name	Authenticated	Parallelizable	Status	Notes
ECB	Electronic Codebook	No	Yes	Insecure	Identical plaintext blocks produce identical ciphertext. Never use for data encryption. Reveals patterns.
CBC	Cipher Block Chaining	No	Decrypt only	Legacy	Vulnerable to padding oracle attacks (POODLE, Lucky13). Requires separate MAC. Being phased out.
CTR	Counter Mode	No	Yes	Secure	Turns block cipher into stream cipher. Fast and parallelizable. Requires separate MAC for integrity.
GCM	Galois/Counter Mode	Yes (AEAD)	Yes	Recommended	CTR + GHASH authentication. Dominant TLS mode. Nonce reuse is catastrophic. Hardware-accelerated.
CCM	Counter with CBC-MAC	Yes (AEAD)	No	Secure	Used in WiFi (WPA2) and Bluetooth. Not parallelizable. Less popular than GCM.
SIV	Synthetic Initialization Vector	Yes (AEAD)	No	Recommended	Nonce-misuse resistant. If nonce reused, only reveals if same plaintext. AES-GCM-SIV for high safety.
XTS	XEX-based Tweaked-codebook with Ciphertext Stealing	No	Yes	Specialized	Standard for disk encryption (LUKS, BitLocker, FileVault). Not suitable for network communication.
OCB	Offset Codebook Mode	Yes (AEAD)	Yes	Patented (free for open-source)	Fastest AEAD mode. Single pass. Patent limited adoption despite superior performance.

Part 3: Asymmetric Encryption

Asymmetric (public-key) cryptography uses a pair of mathematically related keys: a public key that can be shared freely and a private key that must remain secret. Data encrypted with the public key can only be decrypted with the private key, and vice versa. This elegant solution to the key distribution problem, first published by Diffie and Hellman in 1976, is the foundation of internet security.

Asymmetric algorithms are 1000x+ slower than symmetric ones, so they are used for key exchange and digital signatures rather than bulk data encryption. In practice, a TLS connection uses asymmetric cryptography to establish a shared secret (key exchange), authenticate the server (digital signature), and then switches to symmetric encryption (AES-GCM or ChaCha20-Poly1305) for the actual data transfer.

RSA: The First and Still Relevant

RSA (Rivest-Shamir-Adleman, 1977) was the first practical public-key cryptosystem. Its security is based on the difficulty of factoring large integers. An RSA key pair consists of a public key (n, e) and private key (n, d), where n is the product of two large primes. Encrypting a message m computes c = m^e mod n. Decrypting computes m = c^d mod n. The mathematical relationship ensures that only the holder of d (the private key) can decrypt.

RSA key sizes have grown over time as computing power increased. 512-bit RSA was factored in 1999. 768-bit RSA was factored in 2009 (by a team using hundreds of machines over two years). The current minimum recommended key size is 2048 bits, providing approximately 112 bits of security. For applications requiring security beyond 2030, NIST recommends 3072 bits (128-bit security) or 4096 bits.

RSA remains the most widely deployed public-key algorithm, but its dominance is declining. The shift is toward elliptic curve cryptography (ECC), which provides equivalent security with dramatically shorter keys, and toward post-quantum algorithms that resist attacks from quantum computers. RSA is fundamentally vulnerable to quantum computers via Shor’s algorithm.

Elliptic Curve Cryptography (ECC)

ECC is based on the algebraic structure of elliptic curves over finite fields. The key advantage: ECC achieves the same security as RSA with much shorter keys. A 256-bit ECC key provides the same security as a 3072-bit RSA key. Shorter keys mean faster operations, smaller certificates, and lower bandwidth usage.

The most widely used ECC algorithms are ECDSA (Elliptic Curve Digital Signature Algorithm) on the NIST P-256 curve for digital signatures, and ECDH (Elliptic Curve Diffie-Hellman) or X25519 for key exchange. Ed25519 (EdDSA on Curve25519) is the modern choice for signatures, offering deterministic signing (no reliance on random number generation), fast performance, and resistance to many implementation attacks.

Curve25519 and its sister Ed25519 were designed by Daniel Bernstein specifically to be easy to implement safely. The curve was chosen to be fast, constant-time, and resistant to common implementation errors. X25519 (ECDH on Curve25519) is the default key exchange in TLS 1.3, SSH, and WireGuard. Ed25519 is the default SSH key type and is replacing RSA for code signing.

Diffie-Hellman Key Exchange

The Diffie-Hellman protocol (1976) allows two parties to establish a shared secret over an insecure channel. The classical version uses the discrete logarithm problem in a finite field. Alice and Bob each generate a private key, compute a public key (g^private mod p), exchange public keys, and compute the shared secret (public_other^private mod p). An eavesdropper sees only the public keys and cannot efficiently compute the shared secret.

Modern implementations use Elliptic Curve Diffie-Hellman (ECDH), specifically X25519, which is faster and provides better security properties. In TLS 1.3, ephemeral X25519 key pairs are generated for each connection, providing forward secrecy: compromising a server’s long-term key does not decrypt past sessions.

Key Finding

ECC provides the same security as RSA with keys that are 10-15x shorter, resulting in 10x faster operations.

A P-256 ECDSA key (32 bytes) provides 128-bit security, equivalent to RSA-3072 (384 bytes). The performance and bandwidth savings drive the migration from RSA to ECC.

Asymmetric Algorithm Comparison

11 rows

Algorithm	Type	Key Size (bits)	Security Bits	Status	Quantum Safe	Notes
RSA-2048	Encryption/Signature	2048	112	Secure (minimum)	No	Most widely used. Minimum 2048-bit key for 2026+.
RSA-4096	Encryption/Signature	4096	140	Recommended	No	Recommended for long-term security. Much slower key generation.
ECDSA P-256	Signature	256	128	Recommended	No	Standard for TLS, SSH, cryptocurrency. Faster than RSA.
ECDSA P-384	Signature	384	192	Recommended	No	NSA Suite B / CNSA 1.0 approved for SECRET level.
Ed25519	Signature	256	128	Recommended	No	Deterministic. No side-channel risks from RNG. SSH default.
X25519	Key Exchange	256	128	Recommended	No	ECDH on Curve25519. Default TLS 1.3 key exchange.
DH-2048	Key Exchange	2048	112	Legacy	No	Classical Diffie-Hellman. Replaced by ECDH in modern TLS.
ElGamal	Encryption	2048	112	Legacy	No	Based on DH. Used in PGP. Ciphertext 2x plaintext size.
ML-KEM-768	Key Encapsulation	2400	192	Post-Quantum	Yes	NIST FIPS 203. Lattice-based. Replaces ECDH for quantum safety.
ML-DSA-65	Signature	4032	192	Post-Quantum	Yes	NIST FIPS 204. Dilithium. Post-quantum digital signatures.
SLH-DSA-128	Signature	64	128	Post-Quantum	Yes	NIST FIPS 205. SPHINCS+. Hash-based, conservative assumption.

Key Size vs. Security Level Equivalence

5 rows

Security Bits	Symmetric Key	RSA Key	ECC Key	Hash (collision)	Status
80	80	1024	160	160	Broken
112	112	2048	224	224	Minimum
128	128	3072	256	256	Standard
192	192	7680	384	384	High
256	256	15360	512	512	Maximum

Part 4: Hash Functions

A cryptographic hash function takes an arbitrary-length input and produces a fixed-size output (the digest or hash). Good hash functions have three critical properties: preimage resistance (given a hash h, it is computationally infeasible to find any input m where hash(m) = h), second preimage resistance (given input m1, it is infeasible to find a different m2 where hash(m1) = hash(m2)), and collision resistance (it is infeasible to find any two different inputs that produce the same hash).

Hash functions are not encryption. They are one-way: you cannot recover the input from the hash. They are used for data integrity verification (checksums), digital signatures (sign the hash, not the document), password storage (store the hash, not the password), proof-of-work (Bitcoin mining), content addressing (IPFS, Git), and message authentication codes (HMAC).

MD5 and SHA-1: Broken but Still Around

MD5 (1992, Ron Rivest) produces a 128-bit digest. In 2004, Wang et al. demonstrated practical collision attacks, finding two different inputs that produce the same MD5 hash. By 2008, researchers used MD5 collisions to create a rogue SSL certificate. MD5 is completely broken for security purposes. It should never be used for signatures, certificates, or password hashing. The only acceptable use is as a non-security checksum (e.g., verifying a file download where tampering is not a concern).

SHA-1 (1993, NSA) produces a 160-bit digest. Theoretical attacks were demonstrated in 2005, and in 2017 Google produced the first practical SHA-1 collision (the SHAttered attack), creating two different PDF files with the same SHA-1 hash at a cost of approximately $110,000 in GPU time. Since then, the cost has dropped dramatically. Chrome, Firefox, and all major CAs stopped accepting SHA-1 certificates by 2017. Git is migrating from SHA-1 to SHA-256. SHA-1 is deprecated by NIST and must not be used for security.

SHA-2 Family: The Industry Standard

The SHA-2 family (2001, NSA) includes SHA-224, SHA-256, SHA-384, and SHA-512. SHA-256 is the most widely used, producing a 256-bit (32-byte) digest. It powers Bitcoin mining, TLS certificate signatures, code signing, and data integrity verification across virtually every software system.

SHA-256 provides 128-bit collision resistance (birthday bound of 2^128) and 256-bit preimage resistance. No practical or theoretical attacks have been found against SHA-256. On modern 64-bit CPUs, SHA-512 is actually faster than SHA-256 because it operates on 64-bit words natively. SHA-384 is a truncated version of SHA-512 used when 256-bit collision resistance is not enough.

SHA-3 (Keccak): The Backup Standard

SHA-3 (2015) was selected by NIST after a five-year competition, specifically to provide a backup hash standard with completely different internals from SHA-2. While SHA-2 uses the Merkle-Damgård construction, SHA-3 uses the sponge construction based on the Keccak permutation. This means any attack against SHA-2 would not apply to SHA-3 and vice versa.

SHA-3 is slower than SHA-2 in software (about half the speed on general-purpose CPUs) but has a higher security margin and a more elegant design. In practice, SHA-3 is mainly used where regulatory requirements mandate it or as insurance against future SHA-2 vulnerabilities. The sponge construction is versatile, supporting variable-length output (SHAKE128, SHAKE256) in addition to fixed-length hashes.

BLAKE2 and BLAKE3: Speed and Security

BLAKE2 (2012) was designed to be faster than MD5 while maintaining SHA-3-level security. It achieves this through a refined version of the ChaCha core. BLAKE2b (optimized for 64-bit platforms, up to 512-bit output) reaches 3,400 MB/s, and BLAKE2s (optimized for 32-bit platforms, up to 256-bit output) reaches 1,800 MB/s. BLAKE2 is used in Argon2 (password hashing), WireGuard, and libsodium.

BLAKE3 (2020) pushes performance even further through a Merkle tree structure that enables parallelization and SIMD optimization. At 6,800 MB/s on a single modern CPU, BLAKE3 is 3-7x faster than SHA-256 and even faster than MD5 on multi-core hardware. BLAKE3 supports keyed hashing, key derivation (KDF), and extendable output (XOF) in a single unified algorithm.

Key Finding

BLAKE3 is the fastest secure hash function available in 2026, reaching 6,800 MB/s through parallelization.

For non-regulatory applications (file checksums, content addressing, deduplication), BLAKE3 is the best choice. For compliance-sensitive applications (FIPS, PCI-DSS), SHA-256 remains required.

Hash Function Comparison

13 rows

Algorithm	Digest (bits)	Speed (MB/s)	Status	Collision Resistance	Designer	Notes
MD5	128	5200	Broken	Broken (2004)	Ron Rivest	Practical collision attacks. Do not use for security.
SHA-1	160	3100	Broken	Broken (2017)	NSA	SHAttered attack. Git migrating away. Deprecated by NIST.
SHA-224	224	1650	Secure	2^112	NSA	Truncated SHA-256. Rarely used independently.
SHA-256	256	1650	Secure	2^128	NSA	Industry standard. Bitcoin PoW. TLS certificates. Ubiquitous.
SHA-384	384	2500	Secure	2^192	NSA	Truncated SHA-512. Used where 256-bit is insufficient.
SHA-512	512	2500	Secure	2^256	NSA	Faster than SHA-256 on 64-bit CPUs. Maximum security margin.
SHA3-256	256	800	Secure	2^128	Keccak team	Sponge construction. Different internals from SHA-2. Backup if SHA-2 broken.
SHA3-512	512	420	Secure	2^256	Keccak team	Highest security SHA-3 variant. Slower than SHA-512.
BLAKE2b	512	3400	Secure	2^256	Aumasson et al.	Faster than MD5 while secure. Used in Argon2, WireGuard, libsodium.
BLAKE2s	256	1800	Secure	2^128	Aumasson et al.	Optimized for 32-bit platforms. Faster than SHA-256 everywhere.
BLAKE3	256	6800	Secure	2^128	O'Connor et al.	Parallelizable. SIMD-optimized. 3-7x faster than SHA-256.
RIPEMD-160	160	1200	Legacy	2^80	Dobbertin et al.	Used in Bitcoin address generation (with SHA-256). Academic use.
Whirlpool	512	400	Secure	2^256	Rijmen & Barreto	AES-based. Slow but well-analyzed. Niche usage.

Hash Function Speed Comparison (MB/s on modern CPU)

Source: OnlineTools4Free Research

Hash Collision Probability (Birthday Problem)

The birthday paradox states that in a group of 23 people, there is a 50% chance that two share a birthday. The same mathematics applies to hash collisions. For an n-bit hash, the expected number of hashes before a collision is approximately 2^(n/2), not 2^n. This is why 128-bit security requires a 256-bit hash: the birthday bound for SHA-256 is 2^128, which is computationally infeasible.

Hash Collision Probability (Birthday Bound)

7 rows

Digest Bits	Hashes for 50% Collision	Real-World Risk	Example Algorithm
32	7.7 x 10^4	Guaranteed in any dataset	CRC-32 (not crypto)
64	5.1 x 10^9	Feasible with modern hardware	Truncated hashes
128	2.2 x 10^19	Computationally infeasible	MD5 (broken by attack)
160	1.4 x 10^24	Safe against brute force	SHA-1 (broken by attack)
256	4.8 x 10^38	Unfeasible for any entity	SHA-256, BLAKE2s
384	1.6 x 10^57	Beyond physical limits	SHA-384
512	5.4 x 10^76	Exceeds atoms in universe	SHA-512, BLAKE2b

Part 5: Password Hashing

Password hashing is fundamentally different from data hashing. Data hashing should be fast (verifying file integrity on terabytes of data). Password hashing should be deliberately slow (making brute-force attacks impractical). Using SHA-256 for password storage is a security failure: GPUs compute 8.5 billion SHA-256 hashes per second, meaning any password under 10 characters can be cracked quickly.

Purpose-built password hashing functions (PBKDF2, bcrypt, scrypt, Argon2) solve this by being intentionally compute-intensive and, in modern designs, memory-intensive. They include built-in salts (random data added to each password, ensuring identical passwords produce different hashes), adjustable cost parameters (allowing the work factor to increase as hardware gets faster), and in the case of Argon2, configurable memory requirements that make GPU-based attacks extremely expensive.

PBKDF2: The Compliance Choice

PBKDF2 (Password-Based Key Derivation Function 2, RFC 8018) applies a pseudorandom function (typically HMAC-SHA256) many times to the password and salt. NIST SP 800-132 recommends PBKDF2 for password storage, and OWASP recommends a minimum of 600,000 iterations with SHA-256. At this setting, a GPU cluster manages about 2.8 million hashes per second, much slower than raw SHA-256 but still faster than bcrypt or Argon2.

PBKDF2’s main limitation: it is not memory-hard. It uses minimal memory, which means GPU/ASIC attacks remain effective (GPUs have many cores that can run PBKDF2 iterations in parallel). This is why bcrypt and Argon2 are preferred for new applications. PBKDF2 remains acceptable for compliance-driven environments (FIPS 140-2) where bcrypt and Argon2 are not certified.

bcrypt: The Battle-Tested Standard

bcrypt (1999, Niels Provos and David Mazières) was specifically designed for password hashing. It uses the Blowfish key schedule, which requires 4 KB of memory and involves 521 iterations of key expansion for each hash computation. The cost factor is adjustable: each increment doubles the computation time. At cost factor 12, a GPU cluster manages about 105,000 hashes per second, roughly 610,000x slower than MD5.

bcrypt has been battle-tested for over 25 years and remains an excellent choice. Its main limitations: a 72-byte password input limit (passwords longer than 72 bytes are silently truncated) and only 4 KB memory usage (less GPU-resistant than scrypt or Argon2). Despite these limitations, bcrypt at cost factor 12+ provides strong protection for most applications.

Argon2id: The OWASP #1 Choice

Argon2 (2015) won the Password Hashing Competition (PHC) and is the OWASP #1 recommendation for password storage. It comes in three variants: Argon2d (data-dependent addressing, fastest but vulnerable to side-channel attacks), Argon2i (data-independent addressing, side-channel resistant but slower), and Argon2id (hybrid of both, recommended for all use cases).

Argon2id’s key advantage is configurability. You set three parameters: memory cost (default 64 MB), time cost (number of iterations, default 3), and parallelism (number of threads). The memory requirement makes GPU/ASIC attacks extremely expensive because each parallel hash computation requires its own 64+ MB of memory. GPUs have limited memory per core, drastically reducing their effectiveness.

OWASP recommended settings for 2026: Argon2id with 19456 KiB (19 MB) memory, 2 iterations, 1 degree of parallelism. For higher security: 64 MB memory, 3 iterations. At these settings, a GPU cluster manages about 8,500 hashes per second, making brute-force attacks against even moderate-length passwords completely impractical.

Key Finding

The difference between MD5 and Argon2id for password hashing is 7.5 million to one.

MD5: 64 billion hashes/sec. Argon2id: 8,500 hashes/sec. A password that takes 1 second to crack against MD5 would take 87 days against Argon2id. Use Argon2id for all new password storage.

Password Hashing Algorithm Comparison

10 rows

Algorithm	Hashes/sec (GPU)	Memory Cost	Built-in Salt	Status	OWASP Recommendation
MD5 (raw)	64 billion	None	No	Broken	Do not use
SHA-256 (raw)	8.5 billion	None	No	Not for passwords	Do not use
PBKDF2-SHA256	2.8 million	None	Yes	Acceptable	600,000 iterations minimum
bcrypt	105,000	4 KB	Yes	Recommended	Cost factor 10+
scrypt	32,000	16 MB (default)	Yes	Recommended	N=2^17 for sensitive
Argon2d	9,200	64 MB	Yes	Recommended	Use Argon2id instead
Argon2i	10,500	64 MB	Yes	Recommended	Use Argon2id instead
Argon2id	8,500	64 MB	Yes	Best practice	#1 recommendation
yescrypt	7,800	128 MB	Yes	Secure	Not listed
balloon hashing	11,000	Configurable	Yes	Secure	Not listed

Part 6: Digital Signatures, Certificates, and PKI

Digital signatures provide three properties that hash functions and MACs alone cannot: integrity (the data has not been modified), authentication (the signature was created by the holder of the private key), and non-repudiation (the signer cannot deny having signed the data, because only they have the private key).

The signing process: the signer hashes the data (typically SHA-256) and encrypts the hash with their private key, producing the signature. The verifier decrypts the signature with the signer’s public key and compares the result to the hash of the data. If they match, the data is authentic and unmodified.

Public Key Infrastructure (PKI) is the framework that makes digital signatures practical at internet scale. PKI creates a hierarchy of trust: Root Certificate Authorities (CAs) are trusted by operating systems and browsers. Root CAs issue certificates to Intermediate CAs, which issue certificates to websites and organizations. Each certificate binds a public key to an identity (domain name, organization) and is signed by the issuing CA.

When you visit an HTTPS website, your browser verifies the server’s certificate by following the trust chain from the server certificate through intermediate CAs to a root CA in its trust store. If any link in the chain is invalid (expired, revoked, or signed by an untrusted CA), the connection is rejected with a certificate error.

Let’s Encrypt (launched 2016) revolutionized PKI by providing free, automated Domain Validated (DV) certificates. Before Let’s Encrypt, SSL certificates cost $50-300+ per year, creating a barrier to HTTPS adoption. Today, Let’s Encrypt has issued over 540 million active certificates, and HTTPS adoption has risen from 30% (2015) to 95.4% (2026).

Certificate Transparency (CT) is a public audit log system that records all issued certificates. Every certificate issued by a publicly trusted CA must be logged in at least two CT logs. This enables detection of misissued or fraudulent certificates. If a CA is compromised and issues a rogue certificate, CT logs make the fraud visible within hours.

Certificate Type Distribution (2026)

5 rows

Certificate Type	% of Sites	Avg. Cost/Year ($)	Validation Time	Trust Level	Example
DV (Domain Validated)	78.5	0	Minutes	Basic	Let's Encrypt
OV (Organization Validated)	14.2	120	1-3 days	Medium	DigiCert OV
EV (Extended Validation)	3.8	350	1-2 weeks	High	DigiCert EV
Self-signed	2.1	0	Instant	None	Development only
Wildcard	1.4	180	Varies	Varies	*.example.com

HTTPS Adoption Over Time (2015-2026)

Source: OnlineTools4Free Research

Part 7: TLS/SSL Handshake Explained Step by Step

TLS (Transport Layer Security) is the protocol that secures HTTPS, email (SMTP/IMAP), VPN, and many other internet communications. TLS 1.3 (RFC 8446, 2018) is the current version, representing a major simplification and security improvement over TLS 1.2.

The TLS 1.3 handshake establishes an encrypted connection in one round trip (1-RTT), versus two round trips for TLS 1.2. This reduces connection latency by 50-100 milliseconds, a significant improvement for user experience. TLS 1.3 also supports 0-RTT resumption for repeat connections, allowing the client to send encrypted data in the very first message, though this comes with replay protection caveats.

TLS 1.3 dramatically simplified the protocol by removing insecure options: no RSA key exchange (eliminated to mandate forward secrecy), no CBC mode ciphers (eliminated padding oracle attacks), no RC4 (broken stream cipher), no SHA-1 in signatures, no renegotiation (eliminated renegotiation attacks), and no compression (eliminated CRIME attack). Only five cipher suites remain, all using AEAD and forward secrecy.

TLS 1.3 Handshake Steps

The TLS 1.3 handshake consists of seven messages that establish an encrypted, authenticated connection. Here is what happens at each step.

TLS 1.3 Handshake Steps

7 rows

Step	Message	Direction	Content	TLS 1.3 Detail
1	ClientHello	Client -> Server	Supported cipher suites, TLS version, random nonce, key share (X25519 public key), SNI (server name)	Includes key share for 1-RTT
2	ServerHello	Server -> Client	Selected cipher suite, random nonce, key share (server X25519 public key)	Key share included. Shared secret computed immediately.
3	EncryptedExtensions	Server -> Client	Server extensions (ALPN, early data), now encrypted with handshake keys	Encrypted from this point. Privacy improvement.
4	Certificate	Server -> Client	Server certificate chain (X.509), now encrypted	Encrypted. Passive observers cannot see the certificate.
5	CertificateVerify	Server -> Client	Digital signature over handshake transcript (proves server owns the private key)	Covers entire handshake transcript for better security.
6	Finished	Server -> Client	MAC over entire handshake. Server can now send application data.	Server Finished completes server-side handshake.
7	Finished	Client -> Server	MAC over entire handshake from client side. Both sides derive application keys.	Application keys derived. 1-RTT complete.

TLS Version Adoption

TLS 1.3 adoption has grown from 0.5% in 2018 to 83.2% in 2026. TLS 1.0 and 1.1 are effectively dead, with all major browsers having dropped support. TLS 1.2 remains at 16.8%, primarily in legacy enterprise applications that have not yet migrated. NIST recommends TLS 1.3 for all new deployments and TLS 1.2 only as a fallback for backward compatibility.

TLS Version Adoption (2018-2026)

Source: OnlineTools4Free Research

TLS Cipher Suite Usage (2026)

8 rows

Cipher Suite	Protocol	Usage (%)	Forward Secrecy	Status
TLS_AES_128_GCM_SHA256	TLS 1.3	42.3	Yes	Recommended
TLS_AES_256_GCM_SHA384	TLS 1.3	28.1	Yes	Recommended
TLS_CHACHA20_POLY1305_SHA256	TLS 1.3	12.8	Yes	Recommended
ECDHE-RSA-AES128-GCM-SHA256	TLS 1.2	8.4	Yes	Acceptable
ECDHE-RSA-AES256-GCM-SHA384	TLS 1.2	5.2	Yes	Acceptable
ECDHE-ECDSA-AES128-GCM-SHA256	TLS 1.2	2.1	Yes	Recommended
RSA-AES128-GCM-SHA256	TLS 1.2	0.8	No	Deprecated
RSA-AES256-CBC-SHA256	TLS 1.2	0.3	No	Deprecated

Part 8: Quantum Computing Threat to Cryptography

Quantum computers threaten cryptography through two algorithms. Shor’s algorithm (1994) can factor large integers and compute discrete logarithms in polynomial time, breaking RSA, ECC, and Diffie-Hellman. Grover’s algorithm (1996) provides a quadratic speedup for searching unsorted databases, effectively halving the key strength of symmetric ciphers and hash functions.

The impact is asymmetric. Asymmetric (public-key) cryptography based on factoring (RSA) and discrete logarithms (ECC, DH) is completely broken by a sufficiently large quantum computer. A quantum computer with approximately 4,000 error-corrected logical qubits could break RSA-2048 in hours. Symmetric algorithms (AES) and hash functions (SHA-256) are only weakened: AES-256 retains 128-bit security against quantum computers (still safe), and AES-128 retains 64-bit security (potentially vulnerable in the long term).

The “harvest now, decrypt later” threat is the most urgent concern. Adversaries can record encrypted traffic today and decrypt it once quantum computers are available. For data that must remain secret for 20+ years (government secrets, medical records, infrastructure plans), migration to quantum-safe algorithms must begin now, not when quantum computers arrive.

NIST finalized three post-quantum cryptographic standards in 2024: ML-KEM (FIPS 203, based on CRYSTALS-Kyber) for key encapsulation, ML-DSA (FIPS 204, based on CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (FIPS 205, based on SPHINCS+) for hash-based signatures. These are based on mathematical problems (lattice problems, hash functions) that are believed to resist both classical and quantum computers.

The recommended migration approach is hybrid cryptography: use both a classical algorithm (X25519) and a post-quantum algorithm (ML-KEM-768) for key exchange. This ensures security even if either algorithm is broken. Chrome and Firefox have implemented hybrid key exchange (X25519 + ML-KEM-768) since 2024.

Key Finding

Quantum computers break RSA and ECC completely but only halve the strength of AES and SHA-256.

AES-256 retains 128-bit security against quantum computers. The urgent action is migrating asymmetric algorithms to post-quantum standards (ML-KEM, ML-DSA), not replacing symmetric ones.

Quantum Computing Threat Assessment

9 rows

Algorithm	Classical Security	Quantum Attack	Threat Level	Mitigation
RSA-2048	112	Shor's algorithm	High	Migrate to ML-KEM/ML-DSA
RSA-4096	140	Shor's algorithm	High	Migrate to ML-KEM/ML-DSA
ECC P-256	128	Shor's algorithm	High	Migrate to ML-KEM/ML-DSA
AES-128	128	Grover's algorithm	Medium	Use AES-256
AES-256	256	Grover's algorithm	Low	No change needed
SHA-256	128	Grover's algorithm	Low	Consider SHA-384/512 for long-term
SHA-512	256	Grover's algorithm	None	No change needed
ML-KEM-768	192	None known	None	Already quantum-safe
ML-DSA-65	192	None known	None	Already quantum-safe

Part 9: Real-World Applications

Cryptographic algorithms do not exist in isolation. They are combined into protocols and systems that protect real-world communication. Understanding how these systems compose cryptographic primitives is essential for making informed security decisions.

HTTPS (TLS)

HTTPS protects 95.4% of web traffic in 2026. A typical TLS 1.3 connection uses X25519 for key exchange (establishing a shared secret), ECDSA P-256 or RSA for server authentication (proving the server’s identity via its certificate), and AES-128-GCM or ChaCha20-Poly1305 for bulk data encryption (protecting the actual HTTP traffic). SHA-256 is used throughout for message authentication and certificate signatures.

SSH (Secure Shell)

SSH secures remote server access and file transfer. Modern SSH uses Ed25519 for host and user key authentication (replacing RSA), Curve25519 for key exchange, and AES-256-CTR or ChaCha20-Poly1305 for session encryption. The OpenSSH default since version 8.2 (2020) is Ed25519 for new keys, reflecting the industry shift from RSA to elliptic curves.

Bitcoin and Cryptocurrency

Bitcoin uses ECDSA on the secp256k1 curve for transaction signing (proving ownership of funds), SHA-256 for proof-of-work mining (the computational puzzle that secures the blockchain), and RIPEMD-160 combined with SHA-256 for address generation (shortening public keys into addresses). The private key (256 bits) controls the funds; losing it means permanent loss. Hardware wallets (Ledger, Trezor) store private keys in secure elements that never expose them to the host computer.

WireGuard VPN

WireGuard is a modern VPN protocol that uses ChaCha20-Poly1305 for data encryption, Curve25519 for key exchange, BLAKE2s for hashing, and SipHash for hashtable keys. At roughly 4,000 lines of code (versus 400,000+ for OpenVPN), WireGuard has a dramatically smaller attack surface and has been formally verified. It is now built into the Linux kernel (since 5.6) and is the default VPN protocol for many commercial VPN services.

End-to-End Encrypted Messaging

Signal Protocol (used by Signal, WhatsApp, and Facebook Messenger) provides end-to-end encryption using the X3DH (Extended Triple Diffie-Hellman) key exchange for initial setup, the Double Ratchet algorithm for ongoing message encryption (providing forward secrecy and future secrecy), AES-256-CBC for message encryption, and HMAC-SHA256 for message authentication. Each message uses a unique encryption key, so compromising one key does not reveal past or future messages.

Real-World Cryptographic Application Survey

10 rows

Application	Key Exchange	Authentication	Encryption	Adoption (%)
HTTPS / TLS	X25519 (ECDHE)	ECDSA P-256 / RSA-2048	AES-128-GCM or ChaCha20-Poly1305	95.4
SSH	Curve25519	Ed25519	AES-256-CTR or ChaCha20	99.9
GPG/PGP Email	RSA or ECDH	RSA or Ed25519	AES-256-CFB	2.1
Signal Protocol	X3DH (X25519)	Ed25519	AES-256-CBC	18.5
Bitcoin	N/A	ECDSA secp256k1	N/A (public ledger)	5.2
WireGuard VPN	Curve25519	Curve25519	ChaCha20-Poly1305	12.8
WhatsApp	X3DH	Ed25519	AES-256-CBC	31.2
iMessage	ECDH P-256	ECDSA P-256	AES-128-CTR	14.6
Disk Encryption (LUKS)	N/A	Passphrase + Argon2id	AES-256-XTS	8.3
DNSSEC	N/A	ECDSA P-256 / RSA	N/A (signatures only)	42.1

Cryptographic Application Adoption Rates

Source: OnlineTools4Free Research

Disk Encryption (Full Disk and File-Level)

Disk encryption protects data at rest. Full-disk encryption (FDE) encrypts the entire drive, including the operating system. LUKS (Linux Unified Key Setup) uses AES-256-XTS as the default cipher, with Argon2id for key derivation from the user’s passphrase. BitLocker (Windows) uses AES-128 or AES-256 in XTS mode. FileVault (macOS) uses AES-256-XTS. All three use XTS mode because it is designed for storage encryption, allowing random access to any sector without decrypting preceding sectors.

File-level encryption (VeraCrypt, age, GPG) encrypts individual files or containers rather than the entire disk. This is useful for encrypting sensitive files before cloud storage (Dropbox, Google Drive) or for portable encrypted containers. The tool “age” (designed as a simpler replacement for GPG) uses X25519 for key exchange and ChaCha20-Poly1305 for file encryption, reflecting modern cryptographic preferences.

DNSSEC

DNS Security Extensions (DNSSEC) add cryptographic signatures to DNS records, preventing DNS spoofing and cache poisoning attacks. Without DNSSEC, an attacker who compromises a DNS cache can redirect users to malicious sites even when they type the correct URL. DNSSEC uses ECDSA P-256 (or RSA-2048 for legacy zones) to sign zone records. The chain of trust follows the DNS hierarchy: root zone signs TLD zones, TLD zones sign domain zones.

DNSSEC adoption reached 42.1% of domains in 2026, up from 5% in 2018. The slow adoption is due to complexity: DNSSEC requires key management (key signing keys and zone signing keys must be rotated), increases DNS response sizes (due to signatures), and misconfiguration can make domains unreachable. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) provide complementary protection by encrypting DNS queries between the client and resolver, preventing eavesdropping on which sites a user visits.

Zero-Trust Architecture

Zero-trust architecture (“never trust, always verify”) relies heavily on cryptography. Every request between services is authenticated (mTLS with client certificates), authorized (JWT or policy-based), and encrypted (TLS). The traditional network perimeter (firewall-based trust) is replaced by identity-based trust: every user and service must prove their identity for every request, regardless of network location.

Service mesh implementations (Istio, Linkerd) automate mTLS between microservices, providing encryption and mutual authentication without application code changes. Each service gets a short-lived certificate (typically 24 hours) issued by an internal CA (SPIFFE/SPIRE). This eliminates the risk of long-lived credentials being stolen and provides fine-grained access control at the service level.

Key Finding

Zero-trust architecture replaces network-perimeter trust with cryptographic identity verification for every request.

In a zero-trust model, being on the corporate network does not grant access. Every service-to-service call uses mTLS, every user request carries a verified JWT, and every access decision is logged for audit. Cryptography is the foundation of this security model.

Key Management Best Practices

The strongest encryption algorithm is useless if the keys are poorly managed. Key management encompasses key generation (using cryptographically secure random number generators), key storage (protecting keys at rest), key distribution (securely sharing keys), key rotation (regularly replacing keys to limit exposure), and key destruction (securely erasing keys when no longer needed).

For key generation, always use the operating system’s CSPRNG: /dev/urandom on Linux, CryptGenRandom on Windows, or getentropy() on macOS/BSD. Never use general-purpose random number generators (Math.random(), random.random()) for cryptographic purposes, as they are predictable and produce keys with insufficient entropy. Most cryptographic libraries handle key generation correctly when you use their key generation functions.

For key storage, the gold standard is a Hardware Security Module (HSM): a tamper-resistant physical device that stores keys and performs cryptographic operations internally, never exposing raw key material. Cloud HSMs (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM) provide the same security without physical hardware management. For applications that cannot justify HSM cost, use a Key Management Service (AWS KMS, Azure Key Vault, GCP KMS) that provides managed key storage, automatic rotation, and audit logging.

Methodology

Algorithm speed benchmarks in this report were measured on an AMD Ryzen 9 7950X (16 cores, 32 threads) with AES-NI and AVX-512 support, running Linux 6.6. Speeds represent single-threaded performance for serial algorithms and multi-threaded for parallelizable algorithms (BLAKE3). All measurements use optimized implementations: OpenSSL 3.2 for AES, SHA-2, and SHA-3; libsodium 1.0.19 for ChaCha20 and BLAKE2; and the reference implementation for BLAKE3.

Asymmetric algorithm benchmarks use OpenSSL 3.2 for RSA and ECDSA P-256, libsodium for Ed25519 and X25519, and liboqs 0.10 for post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA). Key generation, signing, verification, encryption, and decryption times are averaged over 10,000 iterations. All times are in milliseconds on the benchmark hardware.

Password hashing benchmarks use a simulated GPU cluster (8x NVIDIA RTX 5090) with Hashcat 6.2.6 for MD5, SHA-256, and bcrypt. scrypt and Argon2id benchmarks are extrapolated from Hashcat performance data and academic publications, as Hashcat support for these algorithms is limited due to their memory-hard design (which is the point). OWASP-recommended parameters are used for each algorithm.

TLS adoption data comes from Qualys SSL Labs SSL Pulse survey (scanning the top 150,000 most popular HTTPS websites monthly), Cloudflare Radar (aggregate data from their global network handling ~20% of internet traffic), and Google Transparency Report (Chrome telemetry). HTTPS adoption data from Let’s Encrypt statistics and W3Techs surveys. Post-quantum deployment data from Chrome and Firefox release notes and usage telemetry.

Glossary: 60+ Cryptography Terms Defined

This glossary defines every essential cryptographic term used in this guide and in security discussions generally. Terms are organized alphabetically within categories. Each definition provides practical context, not just textbook descriptions.

Advanced

Homomorphic Encryption

Encryption that allows computations on ciphertext, producing encrypted results that when decrypted match operations on plaintext. Fully homomorphic encryption (FHE) enables computation on encrypted data without ever decrypting. Still too slow for most practical use.

Zero-Knowledge Proof

A cryptographic method where one party proves knowledge of a value without revealing the value itself. Used in privacy-preserving authentication, blockchain (zk-SNARKs, zk-STARKs), and identity verification.

Asymmetric

Curve25519

An elliptic curve designed by Daniel Bernstein for Diffie-Hellman key exchange (X25519) and digital signatures (Ed25519). Provides 128-bit security with a 256-bit key. Designed to be fast, constant-time, and resistant to implementation errors.

Diffie-Hellman (DH)

The first published public-key protocol (1976), allowing two parties to establish a shared secret over an insecure channel. Based on the discrete logarithm problem. Modern usage prefers elliptic curve variants (ECDH/X25519) for shorter keys and faster computation.

Digital Signature

A mathematical scheme for verifying the authenticity and integrity of digital data. The signer uses their private key to create a signature; anyone can verify it using the public key. RSA, ECDSA, and Ed25519 are signature algorithms.

ECDSA (Elliptic Curve Digital Signature Algorithm)

A digital signature algorithm based on elliptic curve cryptography. Provides the same security as RSA with much shorter keys (256-bit ECDSA = 3072-bit RSA). Standard for TLS certificates, Bitcoin, and SSH.

Elliptic Curve Cryptography (ECC)

Public-key cryptography based on the algebraic structure of elliptic curves over finite fields. ECC achieves the same security as RSA with much shorter keys (256-bit ECC = 3072-bit RSA). Used in ECDSA, ECDH, and Ed25519.

Key Exchange

A protocol by which two parties establish a shared secret key over an insecure channel. Diffie-Hellman, ECDH (X25519), and ML-KEM are key exchange mechanisms. In TLS, key exchange happens during the handshake.

Lattice-Based Cryptography

A family of cryptographic constructions based on the hardness of lattice problems (Learning With Errors, Ring-LWE). Believed to be resistant to quantum computers. ML-KEM and ML-DSA (NIST post-quantum standards) are lattice-based.

Post-Quantum Cryptography

Cryptographic algorithms designed to be secure against both classical and quantum computers. NIST standardized ML-KEM (key exchange), ML-DSA (signatures), and SLH-DSA (hash-based signatures) in 2024. Based on lattice and hash problems.

RSA

The first practical public-key cryptosystem (1977), based on the difficulty of factoring large integers. Used for encryption and digital signatures. Minimum recommended key size is 2048 bits (3072+ for new applications). Vulnerable to quantum computers.

Attack

Birthday Attack

A cryptographic attack that exploits the mathematics of the birthday problem (probability of collisions). For a hash function with n-bit output, a collision can be found with approximately 2^(n/2) operations rather than 2^n. This is why 128-bit security requires a 256-bit hash.

Brute Force Attack

An attack that tries every possible key or password until the correct one is found. The time required grows exponentially with key length. A 128-bit key has 2^128 (3.4 x 10^38) possible values, making brute force infeasible.

Chosen-Plaintext Attack

An attack where the adversary can encrypt arbitrary plaintexts of their choosing and analyze the resulting ciphertexts. All modern ciphers must be secure against this. Block cipher modes like ECB are vulnerable because identical plaintexts produce identical ciphertexts.

Preimage Attack

Given a hash h, finding any message m such that hash(m) = h. For a secure n-bit hash, this should require 2^n operations. Preimage resistance is essential for password hashing and commitment schemes.

Rainbow Table

A precomputed table of hash-to-password mappings used to crack passwords. Defeated by salting (adding random data to each password before hashing). Rainbow tables are useless against bcrypt, scrypt, and Argon2 which always salt.

Second Preimage Attack

Given a message m1 and its hash h, finding a different message m2 such that hash(m2) = h. Harder than collision attacks (requires 2^n operations vs 2^(n/2)). Important for document integrity and digital signatures.

Side-Channel Attack

An attack based on information leaked by the physical implementation (timing, power consumption, electromagnetic emissions) rather than theoretical weakness. Constant-time implementations and hardware countermeasures defend against side channels.

Fundamental

Asymmetric Encryption

Encryption using a pair of mathematically related keys: a public key (shared freely) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the private key, and vice versa. RSA and ECC are asymmetric algorithms.

Ciphertext

The encrypted (scrambled) output of an encryption algorithm. Ciphertext should be indistinguishable from random data. Only someone with the correct key can convert ciphertext back to plaintext through decryption.

Cryptographic Nonce

A number used once in a cryptographic protocol. Nonces prevent replay attacks and ensure that the same plaintext encrypts to different ciphertexts each time. In AES-GCM, the nonce is typically 96 bits and must never be reused with the same key.

CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)

A PRNG that meets cryptographic requirements: output is computationally indistinguishable from true random. Operating systems provide CSPRNGs (/dev/urandom, CryptGenRandom, getentropy()). Essential for key generation, IVs, and nonces.

Entropy (Cryptographic)

A measure of unpredictability or randomness in cryptographic material, measured in bits. A cryptographic key with n bits of entropy has 2^n equally likely values. Good entropy sources include hardware RNGs, /dev/urandom, and CSPRNG.

KDF (Key Derivation Function)

A function that derives one or more cryptographic keys from a source of key material (password, shared secret). HKDF derives keys from DH shared secrets. PBKDF2 and Argon2 derive keys from passwords. KDFs add entropy expansion and separation.

Plaintext

The original unencrypted data before encryption. In cryptanalysis, recovering plaintext from ciphertext without the key is the attacker's goal. Plaintext should never be stored or transmitted where confidentiality is required.

Symmetric Encryption

Encryption where the same key is used for both encryption and decryption. Both parties must share the key secretly. AES and ChaCha20 are symmetric algorithms. Much faster than asymmetric encryption (1000x+) but requires key distribution.

XOR (Exclusive OR)

A bitwise operation fundamental to cryptography: 0 XOR 0 = 0, 0 XOR 1 = 1, 1 XOR 0 = 1, 1 XOR 1 = 0. XOR is reversible (A XOR B XOR B = A), making it the basis of stream ciphers and one-time pads. The only provably unbreakable cipher (OTP) uses XOR.

Hash

Collision (Hash)

When two different inputs produce the same hash output. Finding collisions should require approximately 2^(n/2) operations for an n-bit hash (birthday bound). A practical collision attack means the hash function is broken for signatures and certificates.

HMAC (Hash-based Message Authentication Code)

A MAC construction using a cryptographic hash function and a secret key. HMAC-SHA256 is widely used for API authentication, cookie signing, and message integrity. Defined in RFC 2104.

MAC (Message Authentication Code)

A short piece of information used to confirm that a message has not been tampered with and came from the stated sender. MACs use a secret key (unlike digital signatures). HMAC, CMAC, and Poly1305 are MAC algorithms.

Merkle Tree

A tree data structure where every leaf is a hash of a data block and every node is a hash of its children. Used in Bitcoin (transaction verification), Git (commit integrity), and certificate transparency logs. Enables efficient proof of inclusion.

Poly1305

A one-time authenticator (MAC) designed by Daniel Bernstein. Paired with ChaCha20 as ChaCha20-Poly1305, an AEAD scheme used in TLS 1.3, WireGuard, and SSH. Very fast in software.

Sponge Construction

A cryptographic construction used by SHA-3 (Keccak). It absorbs input data into an internal state, then squeezes out the hash output. The sponge construction is versatile, supporting hashing, MAC, stream encryption, and random number generation.

PKI

CA (Certificate Authority)

An entity that issues digital certificates, binding a public key to a domain name or organization. CAs form the trust hierarchy of PKI. Major CAs include Let's Encrypt (free), DigiCert, and Sectigo. Browsers include a set of trusted root CAs.

Certificate Pinning

A security mechanism where an application only accepts specific certificates or public keys for a server, rather than any certificate signed by a trusted CA. Protects against CA compromise but makes certificate rotation difficult.

Ephemeral Key

A temporary key generated for a single session or transaction, then discarded. Ephemeral keys provide forward secrecy: compromising a long-term key does not decrypt past sessions. Used in TLS 1.3 key exchange (ECDHE).

Forward Secrecy

A property of key exchange protocols ensuring that compromise of long-term keys does not compromise past session keys. Achieved by using ephemeral Diffie-Hellman keys. Required by TLS 1.3. Also called Perfect Forward Secrecy (PFS).

HSM (Hardware Security Module)

A physical device that manages digital keys, performs encryption/decryption, and provides strong authentication. HSMs are tamper-resistant and used by CAs, banks, and cloud providers to protect high-value keys.

OCSP (Online Certificate Status Protocol)

A protocol for checking the revocation status of a digital certificate in real-time. OCSP stapling lets the server include the OCSP response in the TLS handshake, eliminating the privacy and performance issues of direct OCSP queries.

PKCS (Public-Key Cryptography Standards)

A set of standards published by RSA Laboratories. PKCS#1 (RSA), PKCS#7 (CMS/signed data), PKCS#8 (private key format), PKCS#11 (HSM interface), and PKCS#12 (certificate bundles) are widely used.

PKI (Public Key Infrastructure)

The framework of policies, procedures, and technology for managing digital certificates and public keys. Includes CAs, registration authorities, certificate revocation lists, and trust chains. The foundation of HTTPS.

TLS (Transport Layer Security)

The protocol securing internet communications (HTTPS, email, VPN). TLS 1.3 (2018) simplified the handshake to one round trip, removed insecure algorithms, and mandates forward secrecy. Successor to SSL.

Trust Chain

The sequence of certificates from a server certificate through intermediate CAs to a root CA trusted by the operating system or browser. If any link is invalid (expired, revoked, or misissued), the chain fails and the connection is rejected.

X.509

The ITU-T standard for public key certificates, defining the format of digital certificates used in TLS/SSL. An X.509 certificate contains the public key, subject identity, issuer, validity period, and extensions (SANs, key usage).

Password

Key Stretching

The process of converting a short, potentially weak key (like a password) into a longer, more secure key using a KDF. bcrypt, scrypt, and Argon2id perform key stretching by applying thousands of iterations or memory-hard operations.

Pepper

A secret value added to passwords before hashing, stored separately from the hash database (often in application config or HSM). Unlike salts, peppers are not stored with each hash. If the hash database is breached, the pepper adds an extra layer.

Salt

Random data concatenated with a password before hashing to ensure identical passwords produce different hashes. Each user gets a unique salt, stored alongside the hash. Salts defeat rainbow tables and precomputed attacks. Typically 16-32 bytes.

Symmetric

AEAD (Authenticated Encryption with Associated Data)

An encryption scheme that provides confidentiality and integrity for the ciphertext, plus integrity for additional unencrypted data (headers, metadata). AES-GCM and ChaCha20-Poly1305 are AEAD schemes. The standard for modern TLS.

AES (Advanced Encryption Standard)

A symmetric block cipher selected by NIST in 2001 as the replacement for DES. Based on the Rijndael algorithm by Daemen and Rijmen. Supports 128, 192, and 256-bit keys with a 128-bit block size. The most widely used encryption algorithm in the world.

Authenticated Encryption

Encryption that simultaneously provides confidentiality, integrity, and authenticity. AES-GCM and ChaCha20-Poly1305 are authenticated encryption with associated data (AEAD) schemes. They prevent both eavesdropping and tampering.

Block Cipher

A symmetric cipher that encrypts fixed-size blocks of data (typically 128 bits). Block ciphers require a mode of operation (CBC, CTR, GCM) to encrypt data larger than one block. AES, DES, and Twofish are block ciphers.

Block Cipher Mode

A method for applying a block cipher to data longer than one block. ECB (insecure), CBC (legacy), CTR (streaming), and GCM (authenticated) are common modes. The mode determines security properties and parallelizability.

CBC (Cipher Block Chaining)

A block cipher mode where each plaintext block is XORed with the previous ciphertext block before encryption. Requires an IV. Vulnerable to padding oracle attacks (POODLE, Lucky13). Being replaced by GCM in modern protocols.

CTR (Counter Mode)

A block cipher mode that turns a block cipher into a stream cipher by encrypting sequential counter values and XORing with plaintext. Parallelizable and does not require padding. Used as the basis for GCM mode.

DES (Data Encryption Standard)

A symmetric block cipher adopted as a US federal standard in 1977. Uses a 56-bit key and 64-bit block. Broken by brute force in 1999 (22 hours with dedicated hardware). Replaced by AES in 2001.

Feistel Network

A symmetric cipher structure that splits the block into two halves and processes them alternately through a round function. DES, Blowfish, and Twofish use Feistel networks. Decryption uses the same structure with reversed round keys.

GCM (Galois/Counter Mode)

An authenticated encryption mode that combines CTR encryption with a Galois field MAC for authentication. Provides confidentiality, integrity, and authenticity. The dominant mode for AES in TLS, SSH, and IPsec.

Initialization Vector (IV)

A random or unique value used with an encryption key to ensure the same plaintext encrypts differently each time. IVs prevent patterns in ciphertext. For AES-CBC, the IV must be random and unpredictable. For AES-GCM, the nonce must be unique.

Key Schedule

The algorithm within a block cipher that expands the cipher key into multiple round keys. AES-256 expands a 256-bit key into 15 round keys of 128 bits each. A good key schedule ensures each round key is sufficiently different.

Key Wrapping

Encrypting a cryptographic key with another key for secure storage or transport. AES-KW (Key Wrap) and AES-GCM-SIV are standard key wrapping algorithms. Used in key management systems and HSMs.

Padding

Extra bytes added to plaintext to make it a multiple of the block size. PKCS#7 padding is standard for CBC mode. Incorrect padding validation leads to padding oracle attacks. GCM and CTR modes do not require padding.

SPN (Substitution-Permutation Network)

A block cipher structure alternating substitution (S-boxes) and permutation (bit shuffling) operations. AES uses an SPN structure. Provides good diffusion and confusion as defined by Shannon.

Stream Cipher

A cipher that encrypts data one bit or byte at a time by XORing with a keystream. ChaCha20 and RC4 are stream ciphers. Stream ciphers are naturally suited for real-time encryption where data length is unknown in advance.

Frequently Asked Questions (25 Questions)

These are the most common questions about cryptography and hashing, drawn from search data, developer forums, and security discussions. Each answer provides actionable guidance.

What is the difference between encryption and hashing?

Encryption is reversible (two-way): you encrypt data with a key and can decrypt it back to the original. Hashing is one-way: you compute a fixed-size digest from data, but you cannot recover the original data from the hash. Encryption protects data in transit and at rest (AES, ChaCha20). Hashing verifies data integrity, stores passwords, and creates digital signatures (SHA-256, BLAKE3).

Is AES-128 still secure in 2026?

Yes. AES-128 provides 128 bits of security, meaning a brute-force attack requires 2^128 (3.4 x 10^38) operations. Even with all the computing power on Earth, this would take longer than the age of the universe. Quantum computers would reduce this to 2^64 via Grover's algorithm, which is still beyond current capability. However, for long-term security (data that must remain secret for 30+ years), AES-256 is recommended as it provides 128-bit quantum security.

What is the best encryption algorithm to use?

For most applications in 2026: use AES-256-GCM if hardware AES acceleration is available (AES-NI, present in nearly all modern CPUs), or ChaCha20-Poly1305 if targeting mobile/embedded devices without AES hardware. Both are AEAD ciphers providing encryption and authentication. For key exchange, use X25519 (ECDH on Curve25519). For signatures, use Ed25519. For post-quantum safety, add ML-KEM-768 as a hybrid alongside X25519.

Why was MD5 deprecated?

MD5 was deprecated because practical collision attacks were demonstrated in 2004 by Wang et al. By 2008, researchers created rogue CA certificates using MD5 collisions. MD5's 128-bit digest means the birthday bound is only 2^64, which is achievable with modern hardware. MD5 should never be used for security purposes (signatures, certificates, password hashing). It remains acceptable only for non-security checksums (verifying file downloads where tampering is not a concern).

What makes SHA-3 different from SHA-2?

SHA-3 uses a completely different internal structure (sponge construction based on the Keccak permutation) compared to SHA-2 (Merkle-Damgard construction). This means a theoretical attack against SHA-2 would not apply to SHA-3 and vice versa. SHA-3 serves as a backup if SHA-2 is ever broken. In practice, SHA-256 remains faster and more widely deployed, so SHA-3 is mainly used where regulatory requirements mandate it or as insurance against future SHA-2 vulnerabilities.

How does HTTPS actually protect my data?

HTTPS uses TLS (Transport Layer Security) which combines asymmetric and symmetric cryptography. First, the client and server perform a key exchange (X25519/ECDHE) to establish a shared secret, authenticated by the server's certificate (ECDSA/RSA). Then, all data is encrypted with a symmetric cipher (AES-GCM or ChaCha20-Poly1305) using keys derived from the shared secret. This protects against eavesdropping, tampering, and impersonation. TLS 1.3 completes this in one round trip (1-RTT).

What is forward secrecy and why does it matter?

Forward secrecy (also called perfect forward secrecy) means that if an attacker obtains a server's long-term private key, they still cannot decrypt previously recorded sessions. This is achieved by using ephemeral (temporary) keys for each session. In TLS 1.3, forward secrecy is mandatory: each connection uses a fresh X25519 key pair that is discarded after the session. Without forward secrecy, an attacker who records encrypted traffic and later compromises the server key can decrypt everything retroactively.

Should I use RSA or ECC for TLS certificates?

ECC (specifically ECDSA P-256 or Ed25519) is recommended over RSA for new certificates. Benefits: smaller keys (256-bit vs 2048-bit), faster handshakes, smaller certificate size, and lower CPU usage. A P-256 ECDSA key provides 128-bit security equivalent to RSA-3072, but with 10x faster signature verification. The only reason to use RSA is compatibility with very old clients. Let's Encrypt and most CAs now issue ECDSA certificates by default.

How does bcrypt compare to Argon2?

Both are excellent password hashing algorithms. bcrypt (1999) is battle-tested for 25+ years and widely supported. Its main limitation is the 72-byte password input limit and 4 KB memory usage (less GPU-resistant). Argon2id (2015) is the OWASP #1 recommendation: it is memory-hard (configurable to 64+ MB), has no password length limit, and is specifically designed to resist GPU/ASIC attacks. For new projects, use Argon2id. For existing systems, bcrypt with cost factor 12+ is still excellent.

What is a salt and why is it necessary?

A salt is random data (typically 16-32 bytes) added to a password before hashing. Each user gets a unique salt, stored alongside the hash. Without salts, identical passwords produce identical hashes, allowing attackers to use precomputed tables (rainbow tables) to crack all passwords at once. With salts, every hash is unique even for the same password, forcing attackers to crack each password individually. Modern password hashing functions (bcrypt, Argon2id) generate and embed salts automatically.

Can quantum computers break all encryption?

No. Quantum computers threaten asymmetric (public-key) cryptography based on factoring (RSA) and discrete logarithms (ECC, DH) via Shor's algorithm. However, symmetric algorithms (AES) and hash functions (SHA-256) are only weakened by Grover's algorithm, which effectively halves the key strength. AES-256 provides 128-bit quantum security, which remains safe. NIST has standardized post-quantum replacements (ML-KEM, ML-DSA) for the vulnerable asymmetric algorithms.

What is the TLS 1.3 handshake and why is it faster?

TLS 1.3 completes the handshake in one round trip (1-RTT) versus two for TLS 1.2. The client sends its key share in the first message (ClientHello), allowing the server to compute the shared secret immediately. TLS 1.3 also supports 0-RTT resumption for repeat connections. It removed insecure features: no RSA key exchange, no CBC mode, no RC4, no SHA-1, no renegotiation. Only 5 cipher suites remain (3 for TLS 1.3), all using AEAD and forward secrecy.

What is BLAKE3 and should I use it?

BLAKE3 is a cryptographic hash function released in 2020 that is 3-7x faster than SHA-256 due to parallelism (Merkle tree structure) and SIMD optimization. It produces 256-bit digests and supports keyed hashing, KDF, and XOF modes. BLAKE3 is excellent for non-regulatory use: file checksums, integrity verification, key derivation, and content addressing. For compliance-sensitive applications (FIPS, PCI-DSS), SHA-256/SHA-3 remain required as BLAKE3 is not NIST-standardized.

How do digital signatures work?

The signer hashes the document (SHA-256) and encrypts the hash with their private key, producing the signature. Anyone can verify by decrypting the signature with the signer's public key and comparing to the hash of the document. If they match, the document is authentic (came from the key owner) and has integrity (not modified). Ed25519 and ECDSA P-256 are the most common signature algorithms. Digital signatures underpin TLS certificates, code signing, and document authentication.

What is a key exchange and why can't we just share keys directly?

Direct key sharing requires a pre-existing secure channel, creating a chicken-and-egg problem. Key exchange protocols (Diffie-Hellman, X25519, ML-KEM) solve this by allowing two parties to compute a shared secret using only public information. Each party generates an ephemeral key pair, exchanges public keys over the insecure channel, and combines the other's public key with their own private key. The math ensures both parties derive the same shared secret, which an eavesdropper cannot compute.

Is it safe to use SHA-256 for password hashing?

No. SHA-256 is a fast hash designed for data integrity, not password storage. GPUs can compute 8.5 billion SHA-256 hashes per second, making brute-force attacks against passwords extremely fast. An 8-character password with mixed case and numbers can be cracked in about 3 months against raw SHA-256. Always use a purpose-built password hash: Argon2id (OWASP #1), bcrypt (cost 12+), or scrypt. These are intentionally slow (thousands per second, not billions) and memory-hard.

What is PKI and how does it establish trust on the internet?

Public Key Infrastructure (PKI) is the system of Certificate Authorities (CAs), digital certificates, and trust relationships that enables secure internet communication. When you visit an HTTPS site, the server presents a certificate signed by a CA. Your browser trusts the CA (included in its root store), so it trusts the certificate and the server's public key. The trust chain goes: Root CA -> Intermediate CA -> Server Certificate. Certificate Transparency logs provide public auditability.

What is the difference between a hash, a MAC, and a digital signature?

A hash (SHA-256) takes data and produces a fixed-size digest. Anyone can compute it. It provides integrity but no authentication. A MAC (HMAC-SHA256) takes data AND a secret key to produce an authentication tag. Only someone with the key can create or verify it. It provides integrity and authentication between parties sharing a key. A digital signature (ECDSA, Ed25519) uses a private key to sign and a public key to verify. It provides integrity, authentication, AND non-repudiation (the signer cannot deny signing).

How secure are cryptocurrency wallets?

Cryptocurrency wallet security depends on the underlying cryptography and key management. Bitcoin uses ECDSA on secp256k1 with SHA-256 and RIPEMD-160 for address generation. The cryptography itself is sound. Wallet security failures are almost always due to: poor key generation (weak randomness), key theft (malware, phishing), seed phrase exposure, or exchange hacks. Hardware wallets (Ledger, Trezor) provide the best protection by keeping private keys in a secure element that never exposes them.

What is ChaCha20 and when should I choose it over AES?

ChaCha20 is a stream cipher designed by Daniel Bernstein (2008). Paired with Poly1305 for authentication (ChaCha20-Poly1305), it is an AEAD scheme used in TLS 1.3, WireGuard, and SSH. Choose ChaCha20 over AES when: the CPU lacks AES hardware acceleration (AES-NI), such as older ARM processors; when constant-time implementation is critical (ChaCha20 is naturally constant-time); or when targeting mobile devices. When AES-NI is available, AES-GCM is faster.

What happens if a CA is compromised?

If a Certificate Authority is compromised, the attacker can issue fraudulent certificates for any domain. This has happened: DigiNotar (2011), Comodo (2011), and Symantec (2015-2017). Defenses include: Certificate Transparency (CT) logs that publicly record all issued certificates, enabling detection; CAA DNS records limiting which CAs can issue for a domain; and browser vendor enforcement (Google removed Symantec's trust). CT is now mandatory for all publicly trusted certificates.

What is the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 (RFC 8446, 2018) is a major simplification. Key differences: handshake is 1-RTT (vs 2-RTT), reducing latency by one round trip. Removed insecure algorithms: no RSA key exchange, no CBC mode, no RC4, no SHA-1, no static DH. Only 5 cipher suites remain (all AEAD with forward secrecy). 0-RTT resumption for repeat visits. Server certificate is encrypted (privacy improvement). TLS 1.3 is both faster and more secure than TLS 1.2.

How long should encryption keys be in 2026?

NIST and CNSA recommendations for 2026+: AES: 256-bit (128-bit acceptable for non-classified). RSA: 3072-bit minimum (4096 recommended). ECC: P-256 minimum (P-384 for high-security). Hash: SHA-256 minimum (SHA-384/512 for high-security). Post-quantum: ML-KEM-768 or ML-KEM-1024. For data that must remain secret for 20+ years, use quantum-safe hybrid approaches combining classical and post-quantum algorithms.

What is authenticated encryption and why does it matter?

Authenticated encryption (AE) provides both confidentiality (encryption) and integrity/authenticity (MAC) in a single operation. Without authentication, encrypted data can be modified by an attacker (bit-flipping attacks, padding oracles). AEAD (Authenticated Encryption with Associated Data) additionally protects unencrypted headers. AES-GCM and ChaCha20-Poly1305 are AEAD ciphers. Never use encryption without authentication: always AES-GCM, never AES-CBC alone.

What is a zero-knowledge proof and where is it used?

A zero-knowledge proof (ZKP) lets you prove you know something without revealing what you know. Example: proving you know a password without sending the password. ZKPs are used in: blockchain privacy (zk-SNARKs in Zcash, zk-rollups in Ethereum L2s), age verification without revealing birthdate, credential verification, and anonymous authentication. While computationally expensive, ZKP efficiency has improved dramatically, enabling practical deployment at scale.

Try It Yourself

Use these embedded tools to experiment with hash generation, password generation, and base64 encoding directly within this guide.

Hash Generator

Generate MD5, SHA-1, SHA-256, SHA-512, and other hashes of any text. Try hashing the same text with different algorithms to see how the output differs.

Try it yourself

Hash Generator

Open full tool

Password Generator

Generate cryptographically random passwords of any length and character set. See the entropy calculation in real time.

Try it yourself

Password Generator

Open full tool

Base64 Encoder/Decoder

Base64 is an encoding (not encryption) that converts binary data to ASCII text. It is used extensively in cryptographic contexts: PEM certificates, JWTs, and data URLs all use Base64.

Try it yourself

Base64 Encoder

Open full tool

Raw Data Downloads

All datasets used in this report are available for download. Use them for your own research, presentations, or analysis.

Citations & Sources

NIST. “FIPS 197: Advanced Encryption Standard (AES).” National Institute of Standards and Technology, 2001. https://csrc.nist.gov/publications/detail/fips/197/final

NIST. “FIPS 180-4: Secure Hash Standard (SHA-2).” National Institute of Standards and Technology, 2015. https://csrc.nist.gov/publications/detail/fips/180/4/final

NIST. “FIPS 202: SHA-3 Standard (Keccak).” National Institute of Standards and Technology, 2015. https://csrc.nist.gov/publications/detail/fips/202/final

NIST. “FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM).” National Institute of Standards and Technology, 2024. https://csrc.nist.gov/publications/detail/fips/203/final

NIST. “FIPS 204: Module-Lattice-Based Digital Signature Algorithm (ML-DSA).” National Institute of Standards and Technology, 2024. https://csrc.nist.gov/publications/detail/fips/204/final

Rescorla, E.. “RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3.” IETF, 2018. https://datatracker.ietf.org/doc/html/rfc8446

Bernstein, D.J.. “ChaCha, a variant of Salsa20.” 2008. https://cr.yp.to/chacha/chacha-20080128.pdf

Bernstein, D.J., et al.. “Ed25519: High-speed high-security signatures.” 2011. https://ed25519.cr.yp.to/

Aumasson, J.P., et al.. “BLAKE2: simpler, smaller, fast as MD5.” 2012. https://www.blake2.net/

O'Connor, J., et al.. “BLAKE3: One function, fast everywhere.” 2020. https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf

Biryukov, A., et al.. “Argon2: The Memory-Hard Function for Password Hashing and Other Applications.” 2015. https://www.password-hashing.net/argon2-specs.pdf

OWASP. “Password Storage Cheat Sheet.” OWASP Foundation, 2024. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

Wang, X., Yu, H.. “How to Break MD5 and Other Hash Functions.” EUROCRYPT, 2005. https://link.springer.com/chapter/10.1007/11426639_2

Stevens, M., et al.. “The first collision for full SHA-1 (SHAttered).” Google/CWI Amsterdam, 2017. https://shattered.io/

Let's Encrypt. “Let's Encrypt Statistics.” Internet Security Research Group, 2026. https://letsencrypt.org/stats/

Qualys SSL Labs. “SSL Pulse: Survey of the SSL/TLS Implementation of the Most Popular Web Sites.” Qualys, 2026. https://www.ssllabs.com/ssl-pulse/

Executive Summary

83.2%

TLS 1.3 adoption in 2026

+6.8 pts from 2025

95.4%

Websites using HTTPS

Up from 30% in 2015

60+

Glossary terms defined

FAQ questions answered

AES-256 remains the gold standard for symmetric encryption, with hardware acceleration (AES-NI) enabling throughput exceeding 3,100 MB/s on modern CPUs. ChaCha20 is the preferred alternative when AES hardware is unavailable.
BLAKE3 is now 3-7x faster than SHA-256 thanks to parallelization and SIMD optimization, reaching 6,800 MB/s. However, SHA-256 remains the standard for compliance-sensitive applications.
NIST finalized post-quantum standards in 2024 (ML-KEM, ML-DSA, SLH-DSA), and production deployments began in 2026. The “harvest now, decrypt later” threat makes early migration critical for sensitive data.
Argon2id is the OWASP #1 recommendation for password hashing, limiting GPU attackers to approximately 8,500 hashes per second versus 64 billion for MD5. The difference is 7.5 million to one.

Part 1: History of Cryptography

Ancient and Classical Cryptography

The Mechanical Era

The Digital Revolution

The timeline below shows key milestones in cryptographic history, from ancient techniques through the digital era to the emerging post-quantum age.

The Post-Quantum Era (2020s)

Cryptographic History Timeline

28 rows

Year	Event	Era
1900 BCE	Egyptian hieroglyphs with non-standard symbols	Ancient
500 BCE	Spartan scytale cipher	Ancient
100 BCE	Caesar cipher (substitution cipher)	Ancient
800 CE	Al-Kindi publishes frequency analysis	Medieval
1467	Alberti cipher disk (polyalphabetic)	Renaissance
1553	Vigenere cipher published	Renaissance
1917	Vernam cipher / one-time pad	Modern
1918	Enigma machine patented	Modern
1943	Colossus breaks Lorenz cipher	Modern
1976	Diffie-Hellman key exchange published	Digital
1977	DES adopted as federal standard	Digital
1977	RSA algorithm published	Digital
1991	PGP released by Phil Zimmermann	Digital
1993	SHA-1 published by NIST	Digital
1994	SSL 1.0 developed by Netscape	Digital
1999	TLS 1.0 standardized (RFC 2246)	Digital
2001	AES selected (Rijndael wins)	Digital
2004	MD5 collision found by Wang et al.	Digital
2005	SHA-1 theoretical weakness found	Digital
2008	Bitcoin uses SHA-256 for mining	Digital
2012	NIST selects Keccak as SHA-3	Digital
2015	Argon2 wins Password Hashing Competition	Digital
2017	SHAttered: first SHA-1 collision (Google)	Digital
2018	TLS 1.3 standardized (RFC 8446)	Digital
2020	BLAKE3 released (3x faster than SHA-256)	Digital
2024	NIST finalizes post-quantum standards (FIPS 203-205)	Post-Quantum
2025	Chrome drops TLS 1.0/1.1 support completely	Post-Quantum
2026	ML-KEM/ML-DSA adoption begins in production	Post-Quantum

Part 2: Symmetric Encryption

AES: The Global Standard

ChaCha20: The Software Champion

Legacy Ciphers: DES, 3DES, Blowfish

Key Finding

AES-256-GCM and ChaCha20-Poly1305 are the only two symmetric ciphers you should consider for new applications in 2026.

Both are AEAD (providing encryption + authentication), widely reviewed, and available in every modern TLS stack. Use AES when hardware acceleration is available; ChaCha20 otherwise.

Symmetric Algorithm Comparison

12 rows

Algorithm	Key Size (bits)	Block Size (bits)	Speed (MB/s)	Status	Rounds	Notes
DES	56	64	150	Broken	16	Brute-forced in 22 hours (1999). Key too short.
3DES	168	64	50	Deprecated	48	Sweet32 birthday attack. NIST deprecated 2023.
AES-128	128	128	4200	Secure	10	Standard for most applications. Hardware-accelerated (AES-NI).
AES-192	192	128	3600	Secure	12	Rarely used. AES-128 or AES-256 preferred.
AES-256	256	128	3100	Secure	14	Required for classified (TOP SECRET). Quantum-resistant key length.
Blowfish	448	64	180	Legacy	16	Small 64-bit block limits data safely encrypted. Superseded by Twofish.
Twofish	256	128	280	Secure	16	AES finalist. Patent-free. Used in some disk encryption.
ChaCha20	256	512	3800	Recommended	20	Software-friendly. Default TLS cipher when no AES-NI. Used by WireGuard.
Serpent	256	128	90	Secure	32	Most conservative AES finalist. Slower but highest security margin.
Camellia	256	128	2800	Secure	24	Japanese standard. Comparable to AES. Used in TLS in Japan.
CAST-256	256	128	120	Legacy	48	AES candidate. Rarely used outside PGP legacy.
RC4	2048	0	850	Broken	0	Stream cipher. Biases found. Banned from TLS (RFC 7465).

Symmetric Cipher Speed Comparison (MB/s on modern CPU)

Source: OnlineTools4Free Research

Block Cipher Modes of Operation

8 rows

Mode	Full Name	Authenticated	Parallelizable	Status	Notes
ECB	Electronic Codebook	No	Yes	Insecure	Identical plaintext blocks produce identical ciphertext. Never use for data encryption. Reveals patterns.
CBC	Cipher Block Chaining	No	Decrypt only	Legacy	Vulnerable to padding oracle attacks (POODLE, Lucky13). Requires separate MAC. Being phased out.
CTR	Counter Mode	No	Yes	Secure	Turns block cipher into stream cipher. Fast and parallelizable. Requires separate MAC for integrity.
GCM	Galois/Counter Mode	Yes (AEAD)	Yes	Recommended	CTR + GHASH authentication. Dominant TLS mode. Nonce reuse is catastrophic. Hardware-accelerated.
CCM	Counter with CBC-MAC	Yes (AEAD)	No	Secure	Used in WiFi (WPA2) and Bluetooth. Not parallelizable. Less popular than GCM.
SIV	Synthetic Initialization Vector	Yes (AEAD)	No	Recommended	Nonce-misuse resistant. If nonce reused, only reveals if same plaintext. AES-GCM-SIV for high safety.
XTS	XEX-based Tweaked-codebook with Ciphertext Stealing	No	Yes	Specialized	Standard for disk encryption (LUKS, BitLocker, FileVault). Not suitable for network communication.
OCB	Offset Codebook Mode	Yes (AEAD)	Yes	Patented (free for open-source)	Fastest AEAD mode. Single pass. Patent limited adoption despite superior performance.

Part 3: Asymmetric Encryption

RSA: The First and Still Relevant

Elliptic Curve Cryptography (ECC)

Diffie-Hellman Key Exchange

Key Finding

ECC provides the same security as RSA with keys that are 10-15x shorter, resulting in 10x faster operations.

A P-256 ECDSA key (32 bytes) provides 128-bit security, equivalent to RSA-3072 (384 bytes). The performance and bandwidth savings drive the migration from RSA to ECC.

Asymmetric Algorithm Comparison

11 rows

Algorithm	Type	Key Size (bits)	Security Bits	Status	Quantum Safe	Notes
RSA-2048	Encryption/Signature	2048	112	Secure (minimum)	No	Most widely used. Minimum 2048-bit key for 2026+.
RSA-4096	Encryption/Signature	4096	140	Recommended	No	Recommended for long-term security. Much slower key generation.
ECDSA P-256	Signature	256	128	Recommended	No	Standard for TLS, SSH, cryptocurrency. Faster than RSA.
ECDSA P-384	Signature	384	192	Recommended	No	NSA Suite B / CNSA 1.0 approved for SECRET level.
Ed25519	Signature	256	128	Recommended	No	Deterministic. No side-channel risks from RNG. SSH default.
X25519	Key Exchange	256	128	Recommended	No	ECDH on Curve25519. Default TLS 1.3 key exchange.
DH-2048	Key Exchange	2048	112	Legacy	No	Classical Diffie-Hellman. Replaced by ECDH in modern TLS.
ElGamal	Encryption	2048	112	Legacy	No	Based on DH. Used in PGP. Ciphertext 2x plaintext size.
ML-KEM-768	Key Encapsulation	2400	192	Post-Quantum	Yes	NIST FIPS 203. Lattice-based. Replaces ECDH for quantum safety.
ML-DSA-65	Signature	4032	192	Post-Quantum	Yes	NIST FIPS 204. Dilithium. Post-quantum digital signatures.
SLH-DSA-128	Signature	64	128	Post-Quantum	Yes	NIST FIPS 205. SPHINCS+. Hash-based, conservative assumption.

Key Size vs. Security Level Equivalence

5 rows

Security Bits	Symmetric Key	RSA Key	ECC Key	Hash (collision)	Status
80	80	1024	160	160	Broken
112	112	2048	224	224	Minimum
128	128	3072	256	256	Standard
192	192	7680	384	384	High
256	256	15360	512	512	Maximum

Part 4: Hash Functions

MD5 and SHA-1: Broken but Still Around

SHA-2 Family: The Industry Standard

SHA-3 (Keccak): The Backup Standard

BLAKE2 and BLAKE3: Speed and Security

Key Finding

BLAKE3 is the fastest secure hash function available in 2026, reaching 6,800 MB/s through parallelization.

For non-regulatory applications (file checksums, content addressing, deduplication), BLAKE3 is the best choice. For compliance-sensitive applications (FIPS, PCI-DSS), SHA-256 remains required.

Hash Function Comparison

13 rows

Algorithm	Digest (bits)	Speed (MB/s)	Status	Collision Resistance	Designer	Notes
MD5	128	5200	Broken	Broken (2004)	Ron Rivest	Practical collision attacks. Do not use for security.
SHA-1	160	3100	Broken	Broken (2017)	NSA	SHAttered attack. Git migrating away. Deprecated by NIST.
SHA-224	224	1650	Secure	2^112	NSA	Truncated SHA-256. Rarely used independently.
SHA-256	256	1650	Secure	2^128	NSA	Industry standard. Bitcoin PoW. TLS certificates. Ubiquitous.
SHA-384	384	2500	Secure	2^192	NSA	Truncated SHA-512. Used where 256-bit is insufficient.
SHA-512	512	2500	Secure	2^256	NSA	Faster than SHA-256 on 64-bit CPUs. Maximum security margin.
SHA3-256	256	800	Secure	2^128	Keccak team	Sponge construction. Different internals from SHA-2. Backup if SHA-2 broken.
SHA3-512	512	420	Secure	2^256	Keccak team	Highest security SHA-3 variant. Slower than SHA-512.
BLAKE2b	512	3400	Secure	2^256	Aumasson et al.	Faster than MD5 while secure. Used in Argon2, WireGuard, libsodium.
BLAKE2s	256	1800	Secure	2^128	Aumasson et al.	Optimized for 32-bit platforms. Faster than SHA-256 everywhere.
BLAKE3	256	6800	Secure	2^128	O'Connor et al.	Parallelizable. SIMD-optimized. 3-7x faster than SHA-256.
RIPEMD-160	160	1200	Legacy	2^80	Dobbertin et al.	Used in Bitcoin address generation (with SHA-256). Academic use.
Whirlpool	512	400	Secure	2^256	Rijmen & Barreto	AES-based. Slow but well-analyzed. Niche usage.

Hash Function Speed Comparison (MB/s on modern CPU)

Source: OnlineTools4Free Research

Hash Collision Probability (Birthday Problem)

Hash Collision Probability (Birthday Bound)

7 rows

Digest Bits	Hashes for 50% Collision	Real-World Risk	Example Algorithm
32	7.7 x 10^4	Guaranteed in any dataset	CRC-32 (not crypto)
64	5.1 x 10^9	Feasible with modern hardware	Truncated hashes
128	2.2 x 10^19	Computationally infeasible	MD5 (broken by attack)
160	1.4 x 10^24	Safe against brute force	SHA-1 (broken by attack)
256	4.8 x 10^38	Unfeasible for any entity	SHA-256, BLAKE2s
384	1.6 x 10^57	Beyond physical limits	SHA-384
512	5.4 x 10^76	Exceeds atoms in universe	SHA-512, BLAKE2b

Part 5: Password Hashing

PBKDF2: The Compliance Choice

bcrypt: The Battle-Tested Standard

Argon2id: The OWASP #1 Choice

Key Finding

The difference between MD5 and Argon2id for password hashing is 7.5 million to one.

MD5: 64 billion hashes/sec. Argon2id: 8,500 hashes/sec. A password that takes 1 second to crack against MD5 would take 87 days against Argon2id. Use Argon2id for all new password storage.

Password Hashing Algorithm Comparison

10 rows

Algorithm	Hashes/sec (GPU)	Memory Cost	Built-in Salt	Status	OWASP Recommendation
MD5 (raw)	64 billion	None	No	Broken	Do not use
SHA-256 (raw)	8.5 billion	None	No	Not for passwords	Do not use
PBKDF2-SHA256	2.8 million	None	Yes	Acceptable	600,000 iterations minimum
bcrypt	105,000	4 KB	Yes	Recommended	Cost factor 10+
scrypt	32,000	16 MB (default)	Yes	Recommended	N=2^17 for sensitive
Argon2d	9,200	64 MB	Yes	Recommended	Use Argon2id instead
Argon2i	10,500	64 MB	Yes	Recommended	Use Argon2id instead
Argon2id	8,500	64 MB	Yes	Best practice	#1 recommendation
yescrypt	7,800	128 MB	Yes	Secure	Not listed
balloon hashing	11,000	Configurable	Yes	Secure	Not listed

Part 6: Digital Signatures, Certificates, and PKI

Certificate Type Distribution (2026)

5 rows

Certificate Type	% of Sites	Avg. Cost/Year ($)	Validation Time	Trust Level	Example
DV (Domain Validated)	78.5	0	Minutes	Basic	Let's Encrypt
OV (Organization Validated)	14.2	120	1-3 days	Medium	DigiCert OV
EV (Extended Validation)	3.8	350	1-2 weeks	High	DigiCert EV
Self-signed	2.1	0	Instant	None	Development only
Wildcard	1.4	180	Varies	Varies	*.example.com

HTTPS Adoption Over Time (2015-2026)

Source: OnlineTools4Free Research

Part 7: TLS/SSL Handshake Explained Step by Step

TLS 1.3 Handshake Steps

The TLS 1.3 handshake consists of seven messages that establish an encrypted, authenticated connection. Here is what happens at each step.

TLS 1.3 Handshake Steps

7 rows

Step	Message	Direction	Content	TLS 1.3 Detail
1	ClientHello	Client -> Server	Supported cipher suites, TLS version, random nonce, key share (X25519 public key), SNI (server name)	Includes key share for 1-RTT
2	ServerHello	Server -> Client	Selected cipher suite, random nonce, key share (server X25519 public key)	Key share included. Shared secret computed immediately.
3	EncryptedExtensions	Server -> Client	Server extensions (ALPN, early data), now encrypted with handshake keys	Encrypted from this point. Privacy improvement.
4	Certificate	Server -> Client	Server certificate chain (X.509), now encrypted	Encrypted. Passive observers cannot see the certificate.
5	CertificateVerify	Server -> Client	Digital signature over handshake transcript (proves server owns the private key)	Covers entire handshake transcript for better security.
6	Finished	Server -> Client	MAC over entire handshake. Server can now send application data.	Server Finished completes server-side handshake.
7	Finished	Client -> Server	MAC over entire handshake from client side. Both sides derive application keys.	Application keys derived. 1-RTT complete.

TLS Version Adoption

TLS Version Adoption (2018-2026)

Source: OnlineTools4Free Research

TLS Cipher Suite Usage (2026)

8 rows

Cipher Suite	Protocol	Usage (%)	Forward Secrecy	Status
TLS_AES_128_GCM_SHA256	TLS 1.3	42.3	Yes	Recommended
TLS_AES_256_GCM_SHA384	TLS 1.3	28.1	Yes	Recommended
TLS_CHACHA20_POLY1305_SHA256	TLS 1.3	12.8	Yes	Recommended
ECDHE-RSA-AES128-GCM-SHA256	TLS 1.2	8.4	Yes	Acceptable
ECDHE-RSA-AES256-GCM-SHA384	TLS 1.2	5.2	Yes	Acceptable
ECDHE-ECDSA-AES128-GCM-SHA256	TLS 1.2	2.1	Yes	Recommended
RSA-AES128-GCM-SHA256	TLS 1.2	0.8	No	Deprecated
RSA-AES256-CBC-SHA256	TLS 1.2	0.3	No	Deprecated

Part 8: Quantum Computing Threat to Cryptography

Key Finding

Quantum computers break RSA and ECC completely but only halve the strength of AES and SHA-256.

AES-256 retains 128-bit security against quantum computers. The urgent action is migrating asymmetric algorithms to post-quantum standards (ML-KEM, ML-DSA), not replacing symmetric ones.

Quantum Computing Threat Assessment

9 rows

Algorithm	Classical Security	Quantum Attack	Threat Level	Mitigation
RSA-2048	112	Shor's algorithm	High	Migrate to ML-KEM/ML-DSA
RSA-4096	140	Shor's algorithm	High	Migrate to ML-KEM/ML-DSA
ECC P-256	128	Shor's algorithm	High	Migrate to ML-KEM/ML-DSA
AES-128	128	Grover's algorithm	Medium	Use AES-256
AES-256	256	Grover's algorithm	Low	No change needed
SHA-256	128	Grover's algorithm	Low	Consider SHA-384/512 for long-term
SHA-512	256	Grover's algorithm	None	No change needed
ML-KEM-768	192	None known	None	Already quantum-safe
ML-DSA-65	192	None known	None	Already quantum-safe

Part 9: Real-World Applications

HTTPS (TLS)

SSH (Secure Shell)

Bitcoin and Cryptocurrency

WireGuard VPN

End-to-End Encrypted Messaging

Real-World Cryptographic Application Survey

10 rows

Application	Key Exchange	Authentication	Encryption	Adoption (%)
HTTPS / TLS	X25519 (ECDHE)	ECDSA P-256 / RSA-2048	AES-128-GCM or ChaCha20-Poly1305	95.4
SSH	Curve25519	Ed25519	AES-256-CTR or ChaCha20	99.9
GPG/PGP Email	RSA or ECDH	RSA or Ed25519	AES-256-CFB	2.1
Signal Protocol	X3DH (X25519)	Ed25519	AES-256-CBC	18.5
Bitcoin	N/A	ECDSA secp256k1	N/A (public ledger)	5.2
WireGuard VPN	Curve25519	Curve25519	ChaCha20-Poly1305	12.8
WhatsApp	X3DH	Ed25519	AES-256-CBC	31.2
iMessage	ECDH P-256	ECDSA P-256	AES-128-CTR	14.6
Disk Encryption (LUKS)	N/A	Passphrase + Argon2id	AES-256-XTS	8.3
DNSSEC	N/A	ECDSA P-256 / RSA	N/A (signatures only)	42.1

Cryptographic Application Adoption Rates

Source: OnlineTools4Free Research

Disk Encryption (Full Disk and File-Level)

DNSSEC

Zero-Trust Architecture

Key Finding

Zero-trust architecture replaces network-perimeter trust with cryptographic identity verification for every request.

Key Management Best Practices

Methodology

Glossary: 60+ Cryptography Terms Defined

Advanced

Homomorphic Encryption

Zero-Knowledge Proof

Asymmetric

Curve25519

Diffie-Hellman (DH)

Digital Signature

ECDSA (Elliptic Curve Digital Signature Algorithm)

Elliptic Curve Cryptography (ECC)

Key Exchange

Lattice-Based Cryptography

Post-Quantum Cryptography

RSA

Attack

Birthday Attack

Brute Force Attack

Chosen-Plaintext Attack

Preimage Attack

Given a hash h, finding any message m such that hash(m) = h. For a secure n-bit hash, this should require 2^n operations. Preimage resistance is essential for password hashing and commitment schemes.

Rainbow Table

Second Preimage Attack

Side-Channel Attack

Fundamental

Asymmetric Encryption

Ciphertext

Cryptographic Nonce

CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)

Entropy (Cryptographic)

KDF (Key Derivation Function)

Plaintext

Symmetric Encryption

XOR (Exclusive OR)

Hash

Collision (Hash)

HMAC (Hash-based Message Authentication Code)

A MAC construction using a cryptographic hash function and a secret key. HMAC-SHA256 is widely used for API authentication, cookie signing, and message integrity. Defined in RFC 2104.

MAC (Message Authentication Code)

Merkle Tree

Poly1305

A one-time authenticator (MAC) designed by Daniel Bernstein. Paired with ChaCha20 as ChaCha20-Poly1305, an AEAD scheme used in TLS 1.3, WireGuard, and SSH. Very fast in software.

Sponge Construction

PKI

CA (Certificate Authority)

Certificate Pinning

Ephemeral Key

Forward Secrecy

HSM (Hardware Security Module)

OCSP (Online Certificate Status Protocol)

PKCS (Public-Key Cryptography Standards)

A set of standards published by RSA Laboratories. PKCS#1 (RSA), PKCS#7 (CMS/signed data), PKCS#8 (private key format), PKCS#11 (HSM interface), and PKCS#12 (certificate bundles) are widely used.

PKI (Public Key Infrastructure)

TLS (Transport Layer Security)

Trust Chain

X.509

Password

Key Stretching

Pepper

Salt

Symmetric

AEAD (Authenticated Encryption with Associated Data)

AES (Advanced Encryption Standard)

Authenticated Encryption

Block Cipher

Block Cipher Mode

CBC (Cipher Block Chaining)

CTR (Counter Mode)

DES (Data Encryption Standard)

A symmetric block cipher adopted as a US federal standard in 1977. Uses a 56-bit key and 64-bit block. Broken by brute force in 1999 (22 hours with dedicated hardware). Replaced by AES in 2001.

Feistel Network

GCM (Galois/Counter Mode)

Initialization Vector (IV)

Key Schedule

Key Wrapping

Encrypting a cryptographic key with another key for secure storage or transport. AES-KW (Key Wrap) and AES-GCM-SIV are standard key wrapping algorithms. Used in key management systems and HSMs.

Padding

SPN (Substitution-Permutation Network)

A block cipher structure alternating substitution (S-boxes) and permutation (bit shuffling) operations. AES uses an SPN structure. Provides good diffusion and confusion as defined by Shannon.

Stream Cipher

Frequently Asked Questions (25 Questions)

These are the most common questions about cryptography and hashing, drawn from search data, developer forums, and security discussions. Each answer provides actionable guidance.

What is the difference between encryption and hashing?

Is AES-128 still secure in 2026?

What is the best encryption algorithm to use?

Why was MD5 deprecated?

What makes SHA-3 different from SHA-2?

How does HTTPS actually protect my data?

What is forward secrecy and why does it matter?

Should I use RSA or ECC for TLS certificates?

How does bcrypt compare to Argon2?

What is a salt and why is it necessary?

Can quantum computers break all encryption?

What is the TLS 1.3 handshake and why is it faster?

What is BLAKE3 and should I use it?

How do digital signatures work?

What is a key exchange and why can't we just share keys directly?

Is it safe to use SHA-256 for password hashing?

What is PKI and how does it establish trust on the internet?

What is the difference between a hash, a MAC, and a digital signature?

How secure are cryptocurrency wallets?

What is ChaCha20 and when should I choose it over AES?

What happens if a CA is compromised?

What is the difference between TLS 1.2 and TLS 1.3?

How long should encryption keys be in 2026?

What is authenticated encryption and why does it matter?

What is a zero-knowledge proof and where is it used?

Try It Yourself

Use these embedded tools to experiment with hash generation, password generation, and base64 encoding directly within this guide.

Hash Generator

Generate MD5, SHA-1, SHA-256, SHA-512, and other hashes of any text. Try hashing the same text with different algorithms to see how the output differs.

Try it yourself

Hash Generator

Open full tool

Enter text to hash

Password Generator

Generate cryptographically random passwords of any length and character set. See the entropy calculation in real time.

Try it yourself

Password Generator

Open full tool

Length: 16

8128

Uppercase (A-Z)Lowercase (a-z)Digits (0-9)Symbols (!@#$...)Exclude ambiguous (Il1O0o)

Generate Multiple

Base64 Encoder/Decoder

Base64 is an encoding (not encryption) that converts binary data to ASCII text. It is used extensively in cryptographic contexts: PEM certificates, JWTs, and data URLs all use Base64.

Try it yourself

Base64 Encoder

Open full tool

Text to encode

Raw Data Downloads

All datasets used in this report are available for download. Use them for your own research, presentations, or analysis.

Citations & Sources

NIST. “FIPS 197: Advanced Encryption Standard (AES).” National Institute of Standards and Technology, 2001. https://csrc.nist.gov/publications/detail/fips/197/final

NIST. “FIPS 180-4: Secure Hash Standard (SHA-2).” National Institute of Standards and Technology, 2015. https://csrc.nist.gov/publications/detail/fips/180/4/final

NIST. “FIPS 202: SHA-3 Standard (Keccak).” National Institute of Standards and Technology, 2015. https://csrc.nist.gov/publications/detail/fips/202/final

NIST. “FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM).” National Institute of Standards and Technology, 2024. https://csrc.nist.gov/publications/detail/fips/203/final

NIST. “FIPS 204: Module-Lattice-Based Digital Signature Algorithm (ML-DSA).” National Institute of Standards and Technology, 2024. https://csrc.nist.gov/publications/detail/fips/204/final

Rescorla, E.. “RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3.” IETF, 2018. https://datatracker.ietf.org/doc/html/rfc8446

Bernstein, D.J.. “ChaCha, a variant of Salsa20.” 2008. https://cr.yp.to/chacha/chacha-20080128.pdf

Bernstein, D.J., et al.. “Ed25519: High-speed high-security signatures.” 2011. https://ed25519.cr.yp.to/

Aumasson, J.P., et al.. “BLAKE2: simpler, smaller, fast as MD5.” 2012. https://www.blake2.net/

O'Connor, J., et al.. “BLAKE3: One function, fast everywhere.” 2020. https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf

Biryukov, A., et al.. “Argon2: The Memory-Hard Function for Password Hashing and Other Applications.” 2015. https://www.password-hashing.net/argon2-specs.pdf

OWASP. “Password Storage Cheat Sheet.” OWASP Foundation, 2024. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

Wang, X., Yu, H.. “How to Break MD5 and Other Hash Functions.” EUROCRYPT, 2005. https://link.springer.com/chapter/10.1007/11426639_2

Stevens, M., et al.. “The first collision for full SHA-1 (SHAttered).” Google/CWI Amsterdam, 2017. https://shattered.io/

Let's Encrypt. “Let's Encrypt Statistics.” Internet Security Research Group, 2026. https://letsencrypt.org/stats/

Qualys SSL Labs. “SSL Pulse: Survey of the SSL/TLS Implementation of the Most Popular Web Sites.” Qualys, 2026. https://www.ssllabs.com/ssl-pulse/