Symmetric Cryptosystems: DES, AES, RC4 and Blowfish

A symmetric cipher is one of two structural families. Both can be made arbitrarily secure with the right design; they differ in how they handle data shape.

A block cipher operates on a fixed-size block of plaintext, typically 64 bits (DES, Blowfish, 3DES) or 128 bits (AES, Twofish, Camellia, ARIA). Encrypt and decrypt are bijections on the block space, parametrised by the key. Messages longer than one block need a mode of operation that defines how to split, chain or otherwise process the data. Messages shorter than one block need padding (PKCS#7 is the standard) or a streaming mode that avoids padding entirely.

A stream cipher produces a pseudo-random keystream from the key (and usually a nonce). Plaintext is XORed with the keystream byte-by-byte or bit-by-bit. There is no block alignment, no padding, and the same key with two different nonces produces independent ciphertexts. RC4 is the historical example; ChaCha20 and Salsa20 are the current ones. Block ciphers in CTR or OFB mode behave as stream ciphers, which is why "stream cipher" today often means "any cipher used in a streaming way."

The practical implication for examiners: a captured ciphertext file's length tells you a lot. A file whose size is an exact multiple of 16 bytes plus 16 (one IV plus PKCS#7 padded blocks) is almost certainly AES-CBC. A file whose size is "any length" with no obvious alignment is either CTR-mode, GCM (with a 12-byte nonce prefix and 16-byte tag suffix), or a true stream cipher. The size shape is the first diagnostic before any byte-level analysis. UPI's NPCI specification mandates AES-256 in GCM mode for the transaction payload between the issuer PSP and the switch, so a forensic capture of a UPI flow at a merchant terminal carries that 28-byte overhead per encrypted block, which is the shape signature CFSL Hyderabad uses to confirm the channel was unmodified before the bank server saw it.

A block cipher on its own encrypts 16 bytes at a time. Real messages are longer. The mode of operation defines what happens between the blocks.

• ECB (Electronic Codebook). Each plaintext block encrypts independently under the same key. Deterministic: the same plaintext block always produces the same ciphertext block. Catastrophic in practice because plaintext patterns leak through. The "ECB penguin" image (encrypt a bitmap of Tux the penguin in ECB and you can still see the penguin) is the canonical demonstration. Forensic flag: an "encrypted" file whose ciphertext shows visibly repeating 16-byte patterns where the plaintext had repeating structure is almost always ECB-mode.
• CBC (Cipher Block Chaining). Each plaintext block is XORed with the previous ciphertext block before encryption. The first block uses a random IV (initialisation vector). Deterministic patterns are destroyed. Requires padding for non-aligned input. Vulnerable to padding-oracle attacks if no MAC is applied: an attacker who can submit ciphertexts and learn whether the padding parses successfully can decrypt arbitrary ciphertexts byte-by-byte. The 2010 ASP.NET vuln, the 2013 Lucky 13 TLS attack and the 2014 POODLE attack all turned on CBC without proper authentication.
• CTR (Counter). Encrypt a counter (nonce concatenated with a sequence number) under the key and XOR the output with the plaintext. Turns the block cipher into a stream cipher. No padding needed. Random access for free (decrypt block N by encrypting counter N). Requires a unique nonce per message per key, forever, or security collapses (two messages with the same nonce yield XOR of plaintexts on inspection).
• GCM (Galois/Counter Mode). CTR mode for confidentiality plus a Galois-field MAC for integrity. The result is an AEAD: one primitive provides confidentiality and integrity together. TLS 1.3 default cipher suite is TLS_AES_128_GCM_SHA256 (or AES_256_GCM_SHA384). Per-message nonce is 12 bytes; per-key nonce reuse breaks both confidentiality and authentication.
• XTS (XEX-based Tweaked-codebook with ciphertext Stealing). Designed for full-disk encryption. Each sector is encrypted with a tweak derived from the sector number, so identical plaintext sectors at different positions produce different ciphertexts. Two AES keys are used (key1 for data, key2 for tweak). BitLocker (Windows 10+), FileVault 2 (macOS), LUKS2 (Linux default since 2018) and dm-crypt all use AES-XTS-128 or AES-XTS-256. The forensic workflow for recovering these volumes (key extraction from RAM, hibernation files, escrow, hashcat brute force) is in Data Recovery, File Carving and Recovering Deleted, Hidden & Encrypted Content.
• OFB (Output Feedback) and CFB (Cipher Feedback). Legacy streaming modes from the 1980s, mostly displaced by CTR and GCM. Still seen in older S/MIME and in some hardware HSMs for backward compatibility.

The Data Encryption Standard (DES) was published as FIPS 46 in 1977, the first cipher to be openly standardised by the US National Bureau of Standards (now NIST) for non-military use. It defined the symmetric-encryption landscape for two decades.

Structural facts an examiner needs:

• 64-bit block size, 56-bit effective key length. The key is specified as 64 bits but every eighth bit is a parity bit; the actual entropy is 56 bits.
• Feistel network with 16 rounds. Each round splits the 64-bit block into 32-bit halves, applies a key-dependent function to one half, XORs it into the other, and swaps. Feistel structure means encryption and decryption use the same circuitry (just with the round subkeys applied in reverse order), which was a hardware-cost advantage in 1977.
• Eight 6-by-4 S-boxes provide the nonlinear element. The S-box design was contributed by IBM with input from the NSA; for years the cryptographic community suspected backdoors, but Eli Biham and Adi Shamir's 1990 paper on differential cryptanalysis revealed that the S-boxes had been specifically tuned to resist exactly that attack, which IBM and NSA had known about 15 years before academia rediscovered it.

DES's fate was sealed by Moore's law. The EFF DES Cracker ("Deep Crack"), built in 1998 for under $250,000, brute-forced a DES key in 56 hours; a follow-up effort with distributed.net got it to 22 hours. By 2010 a moderate cluster could do it in minutes. DES is dead.

Triple-DES (3DES, TDEA) keeps the DES engine but applies it three times with three different 56-bit keys: ciphertext = E_k3(D_k2(E_k1(plaintext))). The encrypt-decrypt-encrypt structure preserves backward compatibility (set k1 = k2 = k3 and you have plain DES). The effective key length is 112 bits, not 168, because of the meet-in-the-middle attack that lets an attacker trade memory for time and break two-key-equivalent constructions in roughly 2^112 work. 3DES survived in legacy banking systems through the 2010s. NIST SP 800-131A formally deprecated 3DES after December 2023; it is now forbidden for new federal cryptographic deployments. Indian banks running legacy PIN-block protection have been migrating to AES under RBI guidance since 2020.

1. Identify DES traffic in casework
   DES ciphertext is 64-bit (8-byte) blocks. ECB-DES files show 8-byte repeats on structured plaintexts. PKCS#5 padding (a variant of PKCS#7 for 8-byte blocks) is the giveaway.
2. Try the known key list
   Legacy banking and SCADA systems often used default or weak DES keys (the famous DES weak keys 0x0101010101010101, 0xFEFEFEFEFEFEFEFE, and the 14 semi-weak keys are checked first).
3. Brute force is now trivial
   John the Ripper with the 'des' mode runs DES at hundreds of thousands of keys per second per CPU core; cloud GPU farms cover the 2^56 space in under a day at modest cost. For a 2026 case, the assumption is that any DES traffic captured is recoverable if the case justifies the spend.
4. 3DES is harder but not safe
   2^112 effective work is beyond brute force in 2026, but 3DES with weak key-derivation (poor passphrases, short PBKDF2 iteration counts) is breakable. The Sweet32 birthday attack against 64-bit-block ciphers in CBC mode makes 3DES additionally fragile on long sessions over 32 GB.

The Advanced Encryption Standard (AES) was published as FIPS 197 in November 2001, capping a four-year open NIST competition (1997 to 2000) that received 15 submissions, narrowed to 5 finalists (MARS, RC6, Rijndael, Serpent, Twofish) and selected Rijndael by Belgian cryptographers Joan Daemen and Vincent Rijmen.

AES's structural facts:

• 128-bit block size, fixed. The original Rijndael supported 128, 192 and 256-bit blocks; AES standardised only 128.
• Three key sizes: 128, 192, 256 bits. Corresponding round counts: 10, 12, 14.
• Substitution-Permutation Network (SPN), not Feistel. Encryption and decryption use different operations (S-box vs inverse S-box; MixColumns vs inverse MixColumns), which costs more silicon but gives sharper diffusion per round.
• Per-round operations: SubBytes, ShiftRows, MixColumns, AddRoundKey. The final round skips MixColumns (a quirk of the design to make decryption symmetric).

The four operations, in detail:

AES-NI (AES New Instructions) is Intel's hardware acceleration introduced in the Westmere microarchitecture in 2010 and matched by AMD's Bulldozer in 2011. The instructions (AESENC, AESENCLAST, AESDEC, AESDECLAST, AESKEYGENASSIST) compute one full AES round per instruction in 4 to 8 CPU cycles. The performance jump from software AES (T-table based, around 16 cycles per byte) to AES-NI (under 1 cycle per byte) was about 20x, and crucially AES-NI is constant-time by construction, which closed the door on the cache-timing attacks (Bernstein 2005, Osvik et al 2006) that had plagued software AES.

AES-256 vs AES-128. Both are believed secure against all known attacks. AES-128 has 2^128 brute-force complexity (out of reach for any classical attacker in 2026). AES-256 has 2^256, well beyond brute force even under aggressive Grover-algorithm speedups in a future cryptographically-relevant quantum computer (which would halve the effective key length to 128 bits, still secure). Indian government and Aadhaar-tier systems mandate AES-256 across the board on the principle of long-life data confidentiality.

RC4 (Rivest Cipher 4, 1987). A stream cipher designed by Ron Rivest at RSA Security. Internally it maintains a 256-byte state permutation S and two indices i and j. The Key Scheduling Algorithm (KSA) seeds S from the key; the Pseudo-Random Generation Algorithm (PRGA) outputs one keystream byte per step. Variable-length key from 40 to 2048 bits. RC4's selling points were speed (the simplest stream cipher to implement) and minimal memory footprint. It powered SSL 3.0 / TLS 1.0 / TLS 1.1 web traffic, WEP, WPA-TKIP and countless proprietary protocols.

RC4's death was slow but inevitable:

• 1995: Wagner and Roos independently identified weak keys in RC4's KSA.
• 2001: Fluhrer, Mantin and Shamir published the FMS attack, exploiting the first-byte bias to recover WEP keys with a few million captured packets.
• 2005: Klein's analysis of RC4 showed new statistical correlations between the keystream and the key, improving on FMS; the practical WEP crack to under a minute came in 2007 via the PTW attack (Pyshkin, Tews, Weinmann) using aircrack-ptw.
• 2013: Microsoft, Mozilla and Google began deprecating RC4 in browsers.
• 2015: RFC 7465 formally prohibited RC4 in TLS.

RC4 is prohibited for new deployments. In 2026, an examiner encounters it only on legacy hardware (very old Cisco gear, older Windows domain controller traffic, MS Office 97-2003 password protection on .doc files), in malware that uses RC4 as a configuration-decryption layer, and in WEP-secured IoT devices. Its presence is a forensic finding in itself.

Blowfish (Bruce Schneier, 1993). A 64-bit block, Feistel-style cipher with 16 rounds and a variable key length of 32 to 448 bits. Public domain (unpatented and free for any use), which made it the symmetric cipher of choice for open-source projects in the 1990s. It is fast on 32-bit CPUs but the 64-bit block makes it vulnerable to Sweet32 birthday attacks for long sessions (after roughly 32 GB on one key, ciphertext collisions become probable, leaking plaintext via XOR). Blowfish is not recommended for new bulk-encryption applications.

The one place Blowfish survives in mainstream production is bcrypt, the password-hashing function based on a deliberately expensive Blowfish key schedule. Niels Provos and David Mazieres designed bcrypt in 1999; it is still the default password hash in PostgreSQL, OpenBSD, and many Rails / Laravel / Django stacks. bcrypt's strength is the tunable cost factor (work parameter from 4 to 31), which lets defenders make password cracking deliberately slow.

Twofish (1998). Schneier's successor to Blowfish, an AES finalist with a 128-bit block and 128/192/256-bit keys. Lost to Rijndael in the AES competition but is still used in some VeraCrypt installations (selectable as an alternative cipher) and in older PGP versions. No serious cryptanalytic break is known.

Other named symmetric ciphers an examiner might meet:

• CAST-128 (RFC 2144). 64-bit block, 40 to 128-bit key. Used in older PGP and S/MIME.
• IDEA (Lai and Massey, 1991). 64-bit block, 128-bit key. Used in PGP 2.x. Patent-encumbered through 2012, which slowed its adoption.
• GOST 28147-89. Russian state standard, 64-bit block, 256-bit key. Replaced by Kuznyechik (GOST R 34.12-2015) in 2015. Still seen in Russian government and some FSB-mandated banking traffic.
• Camellia and ARIA. 128-bit block, AES-class. Japanese and Korean national standards respectively. ISO/IEC 18033-3 standardised, used in select TLS suites.

ChaCha20-Poly1305 (Bernstein 2008, RFC 8439). A modern stream cipher (Salsa20 family) plus the Poly1305 MAC, packaged as an AEAD. The TLS 1.3 alternative cipher suite TLS_CHACHA20_POLY1305_SHA256 was designed specifically for devices without AES-NI hardware: phones, embedded systems and older servers. On AES-NI-equipped hardware, AES-128-GCM and ChaCha20-Poly1305 are roughly equal in throughput. On non-AES-NI hardware (most Android phones through 2018, embedded ARM, IoT), ChaCha20 is several times faster in software and was Google's reason for adding it as a TLS option in 2014.

The strength of a symmetric cipher is dominated by its key length and by any known attack that reduces the effective key length below the brute-force bound.

Hardware vs software implementations. Three layers an examiner needs to distinguish:

• Hardware HSM. A dedicated cryptographic processor (Thales Luna, Utimaco, AWS CloudHSM, indigenous SCL HSMs deployed in Indian banking) that holds keys in tamper-resistant hardware, performs operations on-chip, and never exposes private key material outside the chip boundary. FIPS 140-3 Level 3 and 4 modules are HSMs.
• CPU instruction set extension. AES-NI on Intel/AMD; ARM Cryptography Extensions on ARMv8 (AESE, AESD, AESMC). Single-cycle round operations, constant-time, side-channel-resistant. The default for any modern AES deployment.
• Pure software. OpenSSL or BoringSSL or libsodium running AES in C with T-tables (older builds) or constant-time bitsliced AES (newer builds when AES-NI is absent). Slower; potentially vulnerable to cache-timing attacks if the implementation uses T-tables.

Constant-time crypto is the defensive design principle that the execution time, memory-access pattern and power profile of an implementation must not depend on the secret key or the plaintext. The motivating attacks are timing leaks (Kocher 1996 against RSA, Bernstein 2005 against AES T-tables), cache-side-channel attacks (Flush+Reload, Prime+Probe), and power-analysis attacks against smartcards. AES-NI is constant-time by hardware design; ChaCha20 in C is naturally constant-time because it has no data-dependent branches or table lookups. Pure-software AES is harder to make constant-time and bitsliced implementations are the modern answer.

The Indian regulated stack binds these choices to real infrastructure:

• Aadhaar / UIDAI (UIDAI DBoEMRYS). PID block encryption uses AES-256 in GCM mode; session keys are RSA-2048-wrapped for transport to UIDAI; STQC-validated HSMs hold the AUA signing keys.
• UPI / BHIM. Pay-leg encryption uses AES-256 with ECDH-derived session keys; HSM-backed RSA-2048 certificates anchor PSP identity at the NPCI switch.
• RBI 2023 PoS encryption mandate. All Point-of-Sale terminals deployed in India after 1 January 2024 must implement AES-128 or AES-256 encryption for card-present transactions (per RBI master direction on card transactions). DUKPT (Derived Unique Key Per Transaction) key management under AES replaces the legacy Triple-DES DUKPT.
• DigiLocker. Document encryption at rest uses AES-256-CBC with HMAC-SHA-256 in encrypt-then-MAC composition; access tokens are JWTs signed with RS256.
• CCA-licensed CAs. DSC signing operations occur inside FIPS 140-3 Level 3 HSMs at e-Mudhra, Sify, NSDL e-Gov, IDRBT and NIC.

A forensic report on Indian regulated-system evidence should name the cipher (AES-256), the mode (GCM, CBC with HMAC, CTR for token streams, XTS for full-volume), the key length (128 or 256), the IV/nonce handling, and the implementation layer (AES-NI, HSM, software). All five details are required for a defensible chain-of-custody narrative; cross-link Asymmetric Cryptosystems, Hashing, PKI and Digital Signatures for the signature side of the same chain.