Cryptographic Weaknesses to Know

Weak or predictable randomness. Cryptography depends on unpredictable values: keys, salts, initialisation vectors, session tokens, nonces. Generating them with an ordinary (non-cryptographic) random source, or from a predictable seed such as the current time, makes them guessable, which undoes the cryptography built on them. This connects to the session-token prediction of Module 2: a token is only as unguessable as the randomness that made it. Fix: use the platform's cryptographically secure random source for anything security-relevant.

Reused initialisation vectors or nonces. Many encryption modes require a value that must be unique (and sometimes unpredictable) for each use; reusing it can leak information about the plaintext or, in some modes, be catastrophic. Fix: follow the mode's rules, generate the value correctly, never reuse it with the same key.

Encryption without integrity. Encrypting data so it is confidential while doing nothing to detect tampering allows an attacker to alter ciphertext in ways that change the plaintext meaningfully without being detected. Modern practice uses authenticated encryption, which provides confidentiality and integrity together. Fix: use an authenticated mode rather than encryption alone.

Insufficient key length. A sound algorithm with too short a key is weak; standards specify minimum lengths (for example RSA keys below 2048 bits are considered inadequate). Fix: use current recommended key sizes.

Weaknesses in key management

Key management is where much real cryptographic failure lives, because the algorithms are fine and the keys are mishandled.

Hard-coded keys. A key embedded in source code, in a configuration file in the repository, or in a compiled application. Anyone who reads the code or the file has the key, and the code is often in a public repository (the committed-secret finding from the reconnaissance chapter). Fix: keys in a secret-management system, never in code.

Keys stored with the data they protect. Encrypting a database and storing the key in the same database, or on the same server with the same access controls, means one breach yields both. This is the flaw that makes encrypting passwords pointless. Fix: separate the key from the data, ideally in a dedicated key-management service or hardware module.

No key rotation. A key used indefinitely means a single compromise, whenever it occurs, exposes everything ever protected with it. Fix: rotate keys on a schedule and on suspected compromise, and design so rotation is possible.

Keys shared too widely. A key distributed to every machine or every developer is a key that will leak. Fix: least privilege for keys, as for everything else.

The one that is a category of its own: rolling your own

Home-made cryptography. Designing a custom cipher, a custom protocol, or a custom "obfuscation" scheme, in the belief that secrecy of the method adds security. It is almost always weaker than a standard, for reasons the encryption chapter gave: security should rest on the key with the method assumed public, and standard algorithms are secure precisely because they have been attacked by experts for years without breaking. A custom scheme has had no such scrutiny.

The rule, which examiners like as a flat statement: do not invent cryptography; use vetted, standard implementations. This extends to not implementing even a standard algorithm yourself where a reviewed library exists, because implementation mistakes (timing side channels, incorrect padding handling) are themselves a rich source of weakness.

A worked example

A tester reviews an application's use of cryptography and reports each finding with its category and fix.

Not one of these is a broken algorithm in the mathematical sense; every one is a standard tool used wrongly or an obsolete tool retained, which is the chapter's thesis demonstrated.

What beginners get wrong

• Imagining cryptographic weakness means broken ciphers. Almost all real findings are misuse: wrong algorithm, wrong parameters, bad key management, or home-made schemes.
• Using a fast unbroken hash for passwords. SHA-256 is not broken and is still wrong for passwords because it is fast; use a slow purpose-built hash.
• Trusting weak randomness. Keys, salts, tokens and nonces from a non-cryptographic or predictable source undo the cryptography built on them.
• Encrypting without integrity. Confidentiality without tamper-detection lets an attacker alter ciphertext; use authenticated encryption.
• Hard-coding keys or storing them with the data. One breach then yields both; separate the key and keep it out of code.
• Rolling your own cryptography. Unvetted schemes are almost always weaker than standards; use reviewed implementations and do not implement primitives yourself.
• Reporting encoding as encryption. No key, reversible by anyone, no security.

Quick revision

• The insight: real cryptographic weakness is almost always a sound primitive used wrongly, not a broken cipher.
• Choosing the primitive: obsolete algorithms (MD5, SHA-1 for collision-dependent uses, DES, RC4, old TLS) replaced by current standards; a fast hash for passwords replaced by a slow one; encryption where hashing is needed or the reverse; encoding treated as encryption.
• Using it: no salt or shared salt; weak or predictable randomness for keys, salts, tokens, nonces; reused IVs or nonces; encryption without integrity (use authenticated encryption); insufficient key length.
• Key management: hard-coded keys, keys stored with the data, no rotation, keys shared too widely.
• Do not invent cryptography; use vetted standard implementations, and do not implement primitives yourself where a reviewed library exists.

Test yourself

1. What is the organising insight of this chapter, and why does it matter for defence?

That real cryptographic weaknesses are overwhelmingly cases of a sound, standard, unbroken algorithm used incorrectly rather than a cipher being mathematically broken. It matters because it means the fixes are known and mechanical, matching the tool to the job and following its rules, rather than requiring cryptographic research, so a defender can address the whole class through the distinctions the block established.

1. Give three examples of a sound primitive used wrongly, with the fix for each.

Storing passwords with a fast hash such as SHA-256, fixed by using a slow purpose-built hash like bcrypt or Argon2; generating session tokens or keys from a predictable source such as the current time, fixed by using a cryptographically secure random source; and encrypting data without integrity protection, fixed by using authenticated encryption that provides confidentiality and tamper-detection together.

1. Why is weak randomness a cryptographic weakness even when the algorithm is sound?

Because cryptography depends on unpredictable values, keys, salts, initialisation vectors, session tokens and nonces, and if these are produced by a non-cryptographic generator or from a predictable seed, they can be guessed, which undermines everything built on them regardless of the strength of the algorithm. A session token, for example, is only as unguessable as the randomness that produced it.

1. What are the principal key-management failures, and what do they have in common?

Hard-coded keys embedded in code or configuration, keys stored alongside the data they protect, keys that are never rotated, and keys shared too widely. They have in common that the algorithm is sound while the key is mishandled, so an attacker obtains the key without breaking any cryptography, which is why key management is where much real cryptographic failure lives.

1. Why is home-made cryptography discouraged, and how far does the rule extend?

Because security should rest on the secrecy of the key with the method assumed public, and standard algorithms are trusted precisely because they have withstood years of expert attack, scrutiny a custom scheme has not had, so custom schemes are almost always weaker. The rule extends to not implementing even standard algorithms oneself where a reviewed library exists, because implementation mistakes such as timing side channels and incorrect padding handling are themselves a significant source of weakness.