How to secure communication (cryptography edition Part 2)
Hey everyone In this we are going to talk about how to secure communication using cryptography.
So in the last article we saw about cryptography and we saw about the types of it but in this we will see some vulnerabilities and some techniques that are being used to break encryption.
In OWASP top 10 2025 list We have a No:04 Cryptography failures In that the weakness focuses on Failure related to the lack of cryptography, insufficiently strong cryptography, leaking of cryptographic key, and related errors. Some common weakness are Use of broken or risky cryptographic algorithm, Insufficient entropy, use of predictable algorithms in random number generator and so on, and there are some different type of things to include in this like Playing with mathematical logic In where the cryptography is not broken, But not implementing it perfectly will.
Generally, data in transit should be encrypted at the transport layer, or OSI Layer 4. Historically, the main obstacles were CPU overhead and the complexity of managing private keys and certificates. Modern CPUs now include hardware acceleration for encryption algorithms such as AES, while services such as Let’s Encrypt and cloud-provider certificate-management platforms have made certificate deployment and maintenance much simpler.
Transport-layer encryption is only one part of a broader data-protection strategy. Organizations must also determine which data requires encryption at rest and which information needs additional, application-level encryption while in transit. Passwords, payment-card data, health records, personally identifiable information, and business secrets typically require stronger protection.
Examples of cryptographic failures in application security include using weak or outdated algorithms, such as MD5 for password hashing, and failing to encrypt sensitive data in transit, like transmitting personal information over plain HTTP instead of HTTPS. These failures can lead to data breaches and unauthorized access to sensitive information.
Common Examples of Cryptographic Failures:
Weak or Outdated Algorithms
- MD5 for Password Hashing: Using MD5, which is known to be vulnerable, can lead to easy compromise of hashed passwords.
- SHA-1: Similar to MD5, SHA-1 has been deprecated due to its weaknesses, making it unsuitable for secure applications.
Insecure Data Transmission
- Plain HTTP Instead of HTTPS: Transmitting sensitive data, such as personal information or credentials, over unencrypted HTTP exposes it to interception by attackers.
- Lack of TLS: Not enforcing Transport Layer Security (TLS) for all pages can allow attackers to downgrade connections and access sensitive data.
Poor Key Management
- Hardcoded Keys: Storing cryptographic keys directly in source code makes them vulnerable if the code is accessed.
- Improper Key Rotation: Failing to regularly update or rotate keys can leave systems exposed to attacks.
Misconfigured Protocols
- Certificate Validation Failures: Not properly validating the full certificate chain can allow attackers to impersonate trusted services.
- Cleartext Transmission of Sensitive Information: Sending sensitive data without encryption can lead to unauthorized access.
For example, consider a website that does not enforce TLS across all pages or supports outdated or weak encryption. An attacker monitoring traffic perhaps on an unsecured wireless network may be able to downgrade an HTTPS connection to HTTP and intercept the user’s requests. If the attacker obtains the user’s session cookie, they can replay it to hijack the authenticated session and access or modify private data.
The attacker could also tamper with the data being transmitted. In a financial application, for instance, they might change the recipient of a money transfer before the request reaches the server. Using strong, consistently enforced TLS helps prevent eavesdropping, session hijacking, and tampering with data in transit.
Now next talking about vulnerabilities on point isn’t “cryptography is broken” AES, RSA, and ECDSA are not broken. The point is that how you use them matters as much as which algorithm you pick: a bad mode, a missing padding scheme, or a reused random value can undo all of the underlying math’s security.
- Vulnerability 1: Caesar cipher — broken by frequency analysis
Vulnerability 2: Vigenère cipher — broken by Index of Coincidence
Vulnerability 3: Repeating-key XOR — broken by Hamming distance + frequency analysis
Vulnerability 4: AES-ECB mode — structural pattern leakage
Vulnerability 5: Textbook RSA — factored in 1.3 milliseconds
Vulnerability 6: ECDSA nonce reuse — full private key recovery
💡Before reading this you need to know topics like AES, RSA, and ECDSA etc to understand.
Vulnerability 1: Caesar cipher broken by frequency analysis
What was attacked: A message encrypted by shifting every letter by a
fixed amount (26 possible keys total).
How it broke: English letters don’t appear equally oftenE is far
more common than Z. Trying all 26 shifts and scoring each result against
known English letter frequencies (a chi-squared statistic) identifies the
correct shift instantly, with no brute-force guessing of words required.
Root cause: The cipher preserves the statistical shape of the
plaintext; it just relabels letters. Any relabeling is undone by comparing
label frequencies to a known reference.
Real-world fix: There isn’t one for a fixed-shift cipher this is why
no serious system has used pure substitution ciphers for centuries. The
lesson generalizes: any cipher whose output preserves plaintext statistics
is vulnerable to this class of attack, no matter how the shifting is done.
Vulnerability 2: Vigenère cipher broken by Index of Coincidence
What was attacked: A repeating-key cipher (a different Caesar shift
per key letter, cycling through the key).
Get MainEkHacker’s stories in your inbox
Join Medium for free to get updates from this writer.
How it broke: Two-step attack:
- Find the key length using the Index of Coincidence (IC) split the
ciphertext into N interleaved streams for candidate lengths N, and
measure how “English-like” each stream’s letter distribution is. The
correct key length produces streams that individually look like normal
English (each stream was encrypted with a single, consistent shift). - Recover each key letter by running the Caesar attack (Vulnerability
- independently on each of the N streams.
Root cause: A repeating key just means N independent Caesar ciphers
interleaved together. Once the key length is known, each stream is exactly
as vulnerable as Vulnerability 1.
A wrinkle worth knowing: IC alone is noisy, especially on short
ciphertext, and can favor a multiple of the true key length nearly as
strongly as the real answer (e.g. 12 instead of 6). The robust fix used
here was to generate a shortlist of candidate lengths, actually decrypt
with each, and keep whichever produces real English words — real-word
matching is far more discriminating than aggregate letter frequency, since
garbled text can coincidentally match letter frequencies but essentially
never produces real dictionary words by chance.
Real-world fix: Same as Vulnerability 1 no repeating-key substitution
cipher is safe against this. Real symmetric ciphers (AES) don’t work this
way at all; they mix the entire block together nonlinearly, so there’s no
“one shift per position” structure to exploit.
Vulnerability 3: Repeating-key XOR broken by Hamming distance + frequency analysis
What was attacked: Plaintext bytes XORed against a short repeating key.
How it broke: Same two-step shape as Vigenère, adapted to bytes:
- Guess the keysize by measuring the normalized Hamming distance
(bit-level difference) between consecutive blocks of various candidate
sizes. The correct keysize tends to minimize this distance, because
blocks encrypted with the same key bytes are more similar to each
other than blocks encrypted with different key bytes. - Recover each key byte by isolating every Nth byte (all bytes XORed
with the same key byte) and running single-byte frequency analysis on
that column.
Root cause: Identical to Vigenère XOR with a short repeating key
means the ciphertext is really many independent single-byte XORs
interleaved.
Debugging note worth keeping: This attack genuinely requires enough
ciphertext for the statistics to separate from noise a couple of
sentences (under ~200 bytes) isn’t enough; a few paragraphs is. This isn’t
a bug to route around, it’s a real, documented property of the technique.
Separately, the byte-level scoring had to be fixed to penalizenon-printable output directly (control characters, high bytes) rather than
only scoring the letters it found — a wrong key that happened to produce
mostly non-letter garbage was initially scoring better by having less
letter-data to be judged on.
Real-world fix: Never reuse a short key across more ciphertext than
the key itself. A proper stream cipher (like ChaCha20) or AES in a proper
mode generates a unique keystream per message (via a nonce), so there’s no repeating structure for Hamming-distance analysis to find.
Vulnerability 4: AES-ECB mode structural pattern leakage
What was attacked: A real, unbroken block cipher (AES-128) but used
in ECB (Electronic Codebook) mode, which encrypts each 16-byte block of
plaintext completely independently.
How it broke: No statistics needed at all this is a structural flaw.
Identical plaintext blocks always produce identical ciphertext blocks.
An image with a solid-colored rectangle and circle was encrypted; out of
12,288 total blocks, 12,249 were exact duplicates in the ECB ciphertext.
Rendering that ciphertext as an image shows the original shapes clearly
outlined visible to the naked eye, no cryptanalysis required. The same
image encrypted with AES-CBC (which chains each block against the
previous ciphertext block) produced zero duplicate blocks and looked
like pure random noise.
Root cause: ECB provides no mechanism to make identical inputs produce
different outputs. AES itself never had a flaw here the algorithm
correctly and securely encrypts each block. The mode of operation
(how blocks relate to each other) is the entire problem.
Real-world fix: Never use ECB mode for anything beyond a single block
of random-looking data. Use CBC with a random IV, or better, an
authenticated mode like AES-GCM, which also protects integrity.
Vulnerability 5: Textbook RSA factored in 1.3 milliseconds
What was attacked: RSA implemented directly from its mathematical
definition, with small (16-bit) primes and no padding.
How it broke: Given only the public key (e, n), trial division
factored n back into its two secret primes p and q almost instantly.
From there, the private exponent d is a direct, deterministic
calculation no guessing involved. The recovered private key correctly
decrypted a message that had been encrypted with the public key.
A second, independent flaw was also demonstrated: textbook RSA is
deterministic encrypting the same message twice produces identical
ciphertext both times, which leaks information (an attacker can tell when
the same value was sent again, or build a lookup table for small message
spaces).
Root cause: RSA’s entire security rests on factoring n being
computationally infeasible. Trial division is O(√n); for our small demo
key, √n is only about 65,000 instant. Real RSA uses 2048-bit or larger
n, where √n is astronomically large (~10³⁰⁸), making trial division
(and every other known factoring method) impractical.
Real-world fix: Use adequately large keys (2048+ bits, ideally larger
today) and, critically, use proper padding OAEP which adds
randomness to every encryption so the same message never produces the
same ciphertext twice, and prevents several other structural attacks that
apply to unpadded (“textbook”) RSA.
Vulnerability 6: ECDSA nonce reuse full private key recovery
What was attacked: A correct ECDSA implementation, correct curve
(secp256k1), correct math but deliberately signing two different
messages while reusing the same random value (the nonce, k).
How it broke: ECDSA’s signing equation involves the nonce in a way
that, when the same k is reused across two signatures, the two
resulting equations can be combined algebraically to solve for k
directly no guessing. Once k is known, the private key d follows
immediately from simple modular arithmetic. Demonstrated concretely: two
signed messages ("$100 to Bob" and "$5000 to Mallory") were enough to
recover the signer's entire private key, which was then used to forge a
valid signature on a brand-new message the real signer never signed
("$1,000,000 to Attacker") and that forged signature verified
successfully against the real public key.
Root cause: ECDSA’s security proof assumes every signature uses a
fresh, unpredictable nonce. Reusing it (or using a predictable one)
breaks that assumption completely, independent of key size or curve
choice — a 2048-bit-equivalent curve offers zero protection against this.
This is not a hypothetical. This exact vulnerability class was
responsible for extracting Sony’s PlayStation 3 code-signing private key
in 2010 — their implementation used a hardcoded, non-random nonce for
every signature ever produced by the console.
Real-world fix: Always generate the nonce using a cryptographically
secure random number generator, or deterministically derive it from the
message and private key per RFC 6979 (which is provably safe against
this exact reuse scenario while remaining reproducible). This is exactly
why the standard cryptography library.
Made a complete hands-on project implementing symmetric and asymmetric cryptography from first principles, then attacking every single implementation using nothing but ciphertext or public signatures. Every attack in this project was actually run and verified then recovered keys and decrypted messages you see are real, not scripted. GITHUB PROJECT
Now this all the things is also known as or comes under the cryptanalysis. And there is more to learn more to lean into it. So, if you like this hit that like button Share this with friends So they can learn it.
Thankyou For Reading :)
