Hash Functions and False Promises
This section is different from the rest of the tutorial. It’s not about writing code. It’s about understanding the world you’re entering as a programmer.
In the last part, you learned how hash tables work. Now let’s talk about what happens when people build empires on hash functions - and what happens when those foundations crack.
The Promise
Cryptocurrency and “Web3” systems are built almost entirely on hash functions. Your Bitcoin wallet address? A hash. Ethereum smart contracts? Verified with hashes. NFT ownership? Tracked with hashes. The entire blockchain? A chain of hashes.
The people selling these systems often claim they’re “cryptographically secure” and “mathematically impossible to break.” Let’s look at what that actually means.
The Birthday Problem
There’s a famous puzzle in probability called the birthday problem. In a room of just 23 people, there’s a 50% chance two of them share a birthday. With 70 people, it’s 99.9%.
This seems wrong because there are 365 possible birthdays. But you’re not looking for a specific collision - you’re looking for any collision. That’s much easier.
The same math applies to hashes. A 256-bit hash has 2^256 possible values - an astronomically large number. But finding any two inputs that collide? That only takes about 2^128 attempts. Still huge, but computers are fast and getting faster.
Hash Functions Break
“Cryptographically secure” doesn’t mean “forever secure.” It means “secure until someone finds a weakness.”
MD5 was once considered cryptographically secure. Now you can find MD5 collisions in seconds on a laptop. SHA-1 was the replacement. In 2017, researchers demonstrated a practical collision attack. Google and other major companies immediately stopped trusting SHA-1 for anything important.
The hash functions used in most cryptocurrencies today (SHA-256, Keccak) haven’t been broken yet. But “not broken yet” is very different from “impossible to break.” Every cryptographic hash function ever created has eventually shown weaknesses as computers got faster and mathematicians got cleverer.
When Military-Grade Encryption Becomes a Joke
Let’s talk about DES - the Data Encryption Standard.
In 1977, DES became the official encryption standard of the United States government, published as FIPS 46 by the National Institute of Standards and Technology. This wasn’t some startup’s marketing claim. This was the federal government saying “this is how you protect classified information.”
DES was considered so sensitive that exporting it was treated like exporting weapons. The cryptographic software regulations of the time classified strong encryption as a munition. You could go to prison for sending DES code to someone in another country.
Think about who trusted DES. Military officers. Intelligence agencies. People whose literal job involves getting shot at. People who stake their lives on security assessments. These aren’t naive civilians - they’re trained professionals with access to classified threat information and the resources of nation-states behind them.
They all thought DES was secure.
By the late 1990s, DES was broken. A 56-bit key was simply too short. The EFF’s “Deep Crack” machine could break DES in under a day. Today, you can break DES on commodity hardware.
The response was Triple DES (3DES) - run DES three times with different keys. That bought some time. But 3DES is slow and awkward, and it too has been deprecated. NIST officially retired 3DES in 2023 and it’s now disallowed for protecting federal information.
Here’s the lesson: if you see DES or 3DES in any modern system, it’s a red flag. Either the people who built it don’t know what they’re doing, or they’re deliberately using broken cryptography. Neither option is good.
There’s no innocent explanation anymore. The warnings have been public for over two decades. Every security professional knows. Every standards body has said to stop using it. If someone is still building systems with DES in 2024, they’re either dangerously incompetent or actively malicious.
The same will eventually be true of today’s algorithms. SHA-256 will someday join DES on the list of “things we used to trust.” The question is whether the systems built on SHA-256 can upgrade when that day comes.
Most blockchain systems cannot.
See It For Yourself
Don’t take my word for it. Here’s a program that cracks DES. You can compile it and run it yourself.
This example uses a reduced keyspace to finish quickly (we only search 16 million keys instead of 72 quadrillion), but the principle is the same. Real DES crackers just use more hardware and more time.
The complete source code with a cross-platform Makefile is in the src/des-crack-demo directory. Here’s the program:
/*
* des_crack_demo.c - Demonstrates that DES is broken
*
* PREREQUISITES - Install these first:
*
* Ubuntu/Debian:
* sudo apt update
* sudo apt install build-essential libssl-dev
*
* Fedora:
* sudo dnf install gcc make openssl-devel
*
* macOS:
* xcode-select --install
* brew install openssl
*
* Windows: Use WSL (easiest) or MSYS2. See README.md for details.
*
* BUILD AND RUN:
*
* Using make:
* make run
*
* Manual (Linux):
* gcc -O3 -o des_crack des_crack_demo.c -lcrypto
* ./des_crack
*
* Manual (macOS with Homebrew):
* gcc -O3 -o des_crack des_crack_demo.c \
* -I$(brew --prefix openssl)/include \
* -L$(brew --prefix openssl)/lib -lcrypto
* ./des_crack
*
* WHAT THIS PROGRAM DOES:
* 1. Creates a "secret" message encrypted with DES
* 2. Brute-forces through keys until it finds the right one
* 3. Shows you the cracked key and decrypted message
* 4. Proves that "military-grade encryption" is meaningless
*/
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <openssl/des.h>
/* The message we'll encrypt and then crack */
const char *SECRET_MESSAGE = "ATTACK AT DAWN";
/*
* The "unknown" key we're trying to find (first 3 bytes vary, rest are 0x01)
* In real DES cracking, all 8 bytes would be unknown
* We use a small keyspace so this demo runs in seconds, not years
*/
unsigned char REAL_KEY[8] = {0x12, 0x34, 0x56, 0x01, 0x01, 0x01, 0x01, 0x01};
void encrypt_des(const unsigned char *key, const unsigned char *input,
unsigned char *output, int len) {
DES_key_schedule schedule;
DES_set_key_unchecked((const_DES_cblock *)key, &schedule);
/* Encrypt in ECB mode (simplest, not secure, but fine for demo) */
for (int i = 0; i < len; i += 8) {
DES_ecb_encrypt((const_DES_cblock *)(input + i),
(DES_cblock *)(output + i),
&schedule, DES_ENCRYPT);
}
}
void decrypt_des(const unsigned char *key, const unsigned char *input,
unsigned char *output, int len) {
DES_key_schedule schedule;
DES_set_key_unchecked((const_DES_cblock *)key, &schedule);
for (int i = 0; i < len; i += 8) {
DES_ecb_encrypt((const_DES_cblock *)(input + i),
(DES_cblock *)(output + i),
&schedule, DES_DECRYPT);
}
}
int main(void) {
/* Prepare the plaintext (pad to 16 bytes for two DES blocks) */
unsigned char plaintext[16] = {0};
unsigned char ciphertext[16] = {0};
unsigned char decrypted[16] = {0};
unsigned char test_key[8] = {0, 0, 0, 0x01, 0x01, 0x01, 0x01, 0x01};
strncpy((char *)plaintext, SECRET_MESSAGE, 16);
/* Encrypt the message with the "secret" key */
encrypt_des(REAL_KEY, plaintext, ciphertext, 16);
printf("=== DES CRACKING DEMONSTRATION ===\n\n");
printf("This program demonstrates why DES is broken.\n");
printf("We'll brute-force through keys until we find the right one.\n\n");
printf("Encrypted message (hex): ");
for (int i = 0; i < 16; i++) {
printf("%02X ", ciphertext[i]);
}
printf("\n\n");
printf("Starting brute-force attack on 24-bit keyspace (16,777,216 keys)...\n");
printf("(Real DES has 56-bit keys = 72,057,594,037,927,936 keys)\n");
printf("(But dedicated hardware can still crack it in hours)\n\n");
clock_t start = clock();
long long keys_tried = 0;
int found = 0;
/* Try all possible values for first 3 bytes (2^24 = 16 million keys) */
for (int b0 = 0; b0 < 256 && !found; b0++) {
test_key[0] = (unsigned char)b0;
for (int b1 = 0; b1 < 256 && !found; b1++) {
test_key[1] = (unsigned char)b1;
for (int b2 = 0; b2 < 256 && !found; b2++) {
test_key[2] = (unsigned char)b2;
keys_tried++;
/* Try to decrypt with this key */
decrypt_des(test_key, ciphertext, decrypted, 16);
/* Check if we got the right plaintext */
if (memcmp(decrypted, plaintext, 16) == 0) {
found = 1;
}
/* Progress update every million keys */
if (keys_tried % 1000000 == 0) {
printf(" Tried %lld million keys...\n", keys_tried / 1000000);
}
}
}
}
clock_t end = clock();
double seconds = (double)(end - start) / CLOCKS_PER_SEC;
if (found) {
printf("\n*** KEY FOUND! ***\n\n");
printf("Key (hex): ");
for (int i = 0; i < 8; i++) {
printf("%02X ", test_key[i]);
}
printf("\n");
printf("Decrypted message: %s\n", decrypted);
printf("\nKeys tried: %lld\n", keys_tried);
printf("Time: %.2f seconds\n", seconds);
printf("Speed: %.0f keys/second\n", keys_tried / seconds);
printf("\n=== WHAT THIS MEANS ===\n\n");
printf("Your computer just tested %.0f DES keys per second.\n", keys_tried / seconds);
printf("Full DES has 2^56 = 72 quadrillion keys.\n");
double full_crack_seconds = 72057594037927936.0 / (keys_tried / seconds);
double full_crack_years = full_crack_seconds / (365.25 * 24 * 3600);
printf("At this speed, one computer would take %.0f years.\n", full_crack_years);
printf("\nBut the EFF's Deep Crack used 1,800 custom chips in parallel.\n");
printf("It cracked DES in 56 hours in 1998.\n");
printf("Modern FPGAs and cloud computing make it even faster.\n");
printf("\nThis is why DES is dead. This is why 'military-grade' means nothing.\n");
printf("This is why anyone still using DES is either ignorant or malicious.\n");
} else {
printf("Key not found (this shouldn't happen in the demo)\n");
}
return 0;
}To build and run, navigate to the src/des-crack-demo directory:
# Using make (after installing prerequisites above):
make run
# Or manually on Linux:
gcc -O3 -o des_crack des_crack_demo.c -lcrypto
./des_crackOn most computers, this will crack the key in a few seconds and print something like:
=== DES CRACKING DEMONSTRATION ===
This program demonstrates why DES is broken.
We'll brute-force through keys until we find the right one.
Encrypted message (hex): 8A 92 3F 1C E7 B4 D8 2A ...
Starting brute-force attack on 24-bit keyspace (16,777,216 keys)...
(Real DES has 56-bit keys = 72,057,594,037,927,936 keys)
(But dedicated hardware can still crack it in hours)
Tried 1 million keys...
*** KEY FOUND! ***
Key (hex): 12 34 56 01 01 01 01 01
Decrypted message: ATTACK AT DAWN
Keys tried: 1193046
Time: 0.42 seconds
Speed: 2840585 keys/second
=== WHAT THIS MEANS ===
Your computer just tested 2840585 DES keys per second.
Full DES has 2^56 = 72 quadrillion keys.
At this speed, one computer would take 804 years.
But the EFF's Deep Crack used 1,800 custom chips in parallel.
It cracked DES in 56 hours in 1998.
Modern FPGAs and cloud computing make it even faster.
This is why DES is dead. This is why 'military-grade' means nothing.
This is why anyone still using DES is either ignorant or malicious.You just cracked military-grade encryption on your laptop. That’s the reality of cryptographic shelf life.
The Scale Problem
Consider this: if a billion people each have a crypto wallet, and each wallet address is a 160-bit hash (like Ethereum), how likely is a collision?
With 10^9 wallets and 2^160 possible addresses, the probability of at least one collision is actually quite small - for now. But the number of wallets keeps growing. The power of computers keeps growing. And unlike a password you can change, your wallet address is permanent. If someone finds a collision with your address, they control your funds.
Why This Matters
The cryptocurrency industry has moved billions of dollars based on the assumption that hash collisions are “mathematically impossible.” They’re not impossible. They’re improbable - today, with current technology, against current attacks.
Some things to consider:
Hashes were never designed to last forever. Cryptographers design for “secure for the next 20-30 years,” not “secure for eternity.”
Quantum computers change the math. Quantum computing threatens to break many current cryptographic assumptions. A sufficiently powerful quantum computer could find hash collisions much faster than classical computers.
Financial incentive attracts attackers. When breaking a hash means stealing billions of dollars, very smart people will try very hard to break it.
There’s no customer service. If a hash collision causes you to lose your cryptocurrency, there’s no one to call. No bank to reverse the transaction. No insurance. The math doesn’t care about your life savings.
The First Lesson
Hash tables are powerful tools. Cryptographic hashes are amazing achievements of mathematics. But they have limits.
When someone tells you their system is “secured by cryptography” or “mathematically guaranteed,” ask yourself: What happens when the math breaks? What happens in 30 years? What happens if there’s a bug in the implementation?
The people who understand hash functions best - the cryptographers who design them - are usually the most cautious about trusting them with irreversible, high-stakes decisions. There’s a reason traditional banks have fraud departments, reversible transactions, and insurance.
Technology built on the assumption that hash collisions are impossible is technology built on a foundation that will eventually crack. Maybe not today. Maybe not for decades. But “mathematically unlikely” is not the same as “safe.”
Cryptographic Agility: The Missing Piece
Here’s what real security engineers know: every cryptographic algorithm has a shelf life. That’s not a flaw - it’s reality. The question isn’t whether your hash function will eventually become weak. The question is whether your system can survive when it does.
Cryptographic agility means building systems that can swap out their cryptographic components when weaknesses are discovered. It’s like building a house with replaceable locks instead of welding the doors shut.
When SHA-1 was broken, responsible systems upgraded to SHA-256. When older encryption standards showed weaknesses, banks and governments rolled out new ones. Your web browser updates its security regularly. Your operating system patches cryptographic vulnerabilities. These systems were designed to evolve.
A cryptographically agile system has:
- Versioned algorithms - The system knows which algorithm was used and can use different ones
- Migration paths - A way to move from old algorithms to new ones
- Governance - Someone responsible for deciding when and how to upgrade
- Reversibility - If something goes wrong, there’s a way to fix it
Now look at most blockchain systems. They have none of this.
Bitcoin’s hash algorithm is baked into its core design. Ethereum’s address format is fixed. “Smart contracts” are specifically designed to be immutable - unchangeable forever. The whole selling point is that nobody can alter anything.
That’s not a feature. That’s a time bomb.
Calling Out the Bad Actors
Let’s be direct about something.
The cryptographers and security researchers who design hash functions are careful, thoughtful people. They publish their work. They invite attacks. They explicitly warn that their algorithms will eventually need replacement. They build systems with upgrade paths.
Many of the people promoting blockchain and Web3 systems are doing something different. They’re taking those same algorithms and wrapping them in claims of permanence and immutability. They’re selling “code is law” and “trustless systems” and “mathematical guarantees” to people who don’t understand the limitations.
Some of these promoters simply don’t understand what they’re selling. They’re repeating marketing points without grasping the technical reality. That’s ignorance, and it’s dangerous, but it’s not malicious.
But others know exactly what they’re doing.
They know cryptographic algorithms have shelf lives. They know immutable systems can’t be patched. They know that “decentralized” often means “no one is responsible when things break.” They know that the lack of reversibility means victims have no recourse.
They sell these systems anyway because there’s money to be made. They cash out before the problems become obvious. They blame users for “not understanding the technology” when things go wrong.
This is cowardice. Real engineers take responsibility for their systems. They build in safety margins. They plan for failure modes. They don’t sell bridges that can’t be inspected or repaired.
And it’s malicious. They’re transferring risk to people who don’t understand it. They’re building systems designed to make their creators rich while leaving users holding worthless tokens when the music stops. They hide behind “decentralization” to avoid accountability, while often controlling enough of the system to profit handsomely.
The tell is simple: ask them what happens when the hash function breaks. Ask them about the upgrade path. Ask them who’s responsible if there’s a bug. Watch them dodge, deflect, or disappear.
How They Target Good People
Here’s something they don’t teach you in programming classes.
The people running these schemes don’t just ignore critics. They actively try to destroy them.
If you become a programmer with integrity - someone who understands these systems and is willing to explain the risks to others - you become a threat. Not because you’re attacking anyone. But because you’re protecting people they want to exploit.
And so they’ll try to use you. Or destroy you. Or both.
The Cat’s Paw
Sometimes they’ll try to get you to do their dirty work without realizing it. They’ll present a project that sounds legitimate. They’ll use technical language that seems reasonable. They’ll offer good money. They’ll appeal to your desire to build interesting things.
Then, when the project hurts people, your name is on it. Your reputation. Your credibility. You built it, after all. You’re the engineer who made it work.
They knew what the project really was. You didn’t. But now you’re the face of it, and they’re nowhere to be found.
This is an old trick. It has a name: a “cat’s paw” - using someone else to do your dirty work, so you don’t get burned.
Reputation Destruction
If they can’t use you, they’ll try to discredit you.
Think about it from their perspective. If you’re a programmer who understands hash functions and cryptographic agility, you can explain to regular people why their “revolutionary” system is actually a house of cards. You can protect people from getting scammed. You can cost them money.
So they need you gone. Not physically - that’s too obvious. They need your credibility gone.
They’ll call you a “hater” or a “Luddite” or say you “just don’t understand the technology.” They’ll dig through your past for anything embarrassing. They’ll misrepresent your positions. They’ll flood discussions with noise so your signal gets lost.
If they can destroy your reputation, two things happen:
People stop listening to you. Your warnings don’t reach the people who need them.
Other potential critics see what happened to you. They stay quiet to avoid the same treatment.
This is why so many technical people stay silent about obvious scams. Speaking up has a cost. The scammers make sure of it.
Why They Fear You
Here’s the thing they don’t want you to understand: they’re afraid of you.
Not you personally. But what you represent. People who understand technology and have integrity are the natural predators of financial scammers.
A good programmer can look at a system and see what it actually does, not just what the marketing claims. A good programmer can explain complex ideas to non-technical people. A good programmer builds things that actually work, which exposes by comparison the things that don’t.
Every person like that is one more obstacle between them and their victims. Every person like that might be the one who writes the blog post or gives the talk or builds the tool that brings the whole scheme down.
So they try to eliminate the competition preemptively. If they can get you to ruin your own reputation by building their scam, great. If they can destroy your reputation through attacks, fine. If they can scare you into silence, that works too.
The goal is the same: remove the people who would protect others.
The Hard Questions
You’ll know enough to ask the hard questions:
- What happens when the hash function is broken?
- What’s the upgrade path?
- Who’s responsible when something goes wrong?
- Why can’t transactions be reversed?
- Who actually controls this “decentralized” system?
- Where does the money come from to pay the promised returns?
And you’ll know enough to walk away from projects that are designed to hurt people.
The Harder Skill
But there’s a harder skill than asking questions. It’s recognizing when someone is trying to use you.
Watch for the patterns:
- They need a “technical co-founder” but are vague about what the technology actually does
- They want your name and credibility more than your actual engineering skills
- The business model doesn’t make sense, but they wave away questions
- They’re in a hurry and don’t want you to do due diligence
- They react badly when you ask hard questions
- The returns they promise seem too good to be true
- They talk more about getting rich than about solving real problems
Trust your instincts. If something feels wrong, it probably is.
And if you realize you’ve been used - if you find out the project you built is hurting people - speak up. Yes, it’s embarrassing. Yes, it will cost you. But silence makes you complicit. The sooner you warn people, the fewer get hurt.
Why This Matters
You’re learning to program. That means you’re learning to build things that millions of people might use. Things that handle their money, their data, their communications.
That’s power. And with power comes people who want to exploit it.
Some will try to hire you to build their schemes. Some will try to destroy you for refusing. Some will try to use your reputation to legitimize their fraud.
Now you know. That knowledge is your first line of defense.
Build things that help people. Ask the hard questions. Walk away from projects designed to hurt people. And when someone tries to destroy your credibility for protecting others, understand it for what it is: a sign that you’re doing something right.
The scammers are afraid of people like you. Make sure they have good reason to be.
Next Up
In Part 21, we’ll get back to practical programming with text files - reading and writing data that humans can read.
Enjoyed This?
If this helped something click, subscribe to my YouTube channel. More content like this, same approach - making things stick without insulting your intelligence. It’s free, it helps more people find this stuff, and it tells me what’s worth making more of.