Stacktrace#01sqlite/sqlite

The Hidden Message in SQLite's Random Number Generator

Four hex constants decode to a plain English phrase. They're not an easter egg - they're a cryptographic proof that there's no backdoor.

Dec 15, 20257 min read

written byKarn

Four magic numbers in SQLite's source code spell out a secret phrase. It's not an easter egg - it's cryptography's way of saying "trust me, there's no backdoor."

Every Database Needs Randomness

SQLite is everywhere. Your phone, your browser, your car, your TV - if it stores data, there's a good chance SQLite is involved. It's the most widely deployed database in the world.

And like any database, it needs random numbers. Not for games - for survival.

Think about it: every time SQLite creates a temporary file, it needs a unique name. Every time it generates a row ID, it needs something unpredictable. Without good randomness, patterns emerge. Patterns mean predictability. Predictability means someone can exploit your database.

So I went digging through SQLite's source code to see how they handle this. What I found in random.c blew my mind.

Okay, But What's a PRNG?

Before I show you the cool part, let's talk about how computers "fake" randomness.

Computers are deterministic. Give them the same input, they produce the same output. Every. Single. Time. They're basically fancy calculators - terrible at being random.

So how do we get randomness? We cheat.

A PRNG (Pseudo-Random Number Generator) takes a small piece of truly unpredictable data - called a seed-and stretches it into a long stream of numbers that look random.

I like to think of it like this:

• Seed: A single drop of food coloring
• PRNG: A blender
• Output: A smoothie where you can't tell where the original color went

If you know the seed, you can reproduce the entire sequence. But if you don't? The output is indistinguishable from true randomness.

SQLite uses a PRNG called ChaCha20. And this is where things get interesting.

The Four Magic Numbers

Here's what I found staring at SQLite's random number generator:

static const u32 chacha20_init[] = {
    0x61707865, 0x3320646e, 0x79622d32, 0x6b206574
};

Four hexadecimal constants. Looks like gibberish, right? You'd scroll right past this.

But watch what happens when you convert them to ASCII:

Put them together: "expand 32-byte k"

Someone hid a message in the source code? Sort of. But it's not an easter egg. It's actually a brilliant piece of cryptographic design. Let me explain.

The NSA Backdoor Problem

To understand why these constants spell out words, you need to know about one of cryptography's biggest scandals.

Back in 2013, documents leaked by Edward Snowden revealed something disturbing: the NSA had likely inserted a backdoor into a random number generator called Dual_EC_DRBG.

Here's how it worked: the algorithm used certain mathematical constants. Those constants looked arbitrary. But the NSA may have specifically chosen them so that anyone who knew the secret could predict the "random" output.

The algorithm was even pushed as a standard. Companies used it. And the whole time, it may have been compromised.

This freaked out the cryptography community. How can you trust any constants in an algorithm? What if the designer picked them to exploit some hidden mathematical weakness?

"Nothing Up My Sleeve"

Cryptographers needed a way to prove their constants weren't malicious. The solution? Nothing-up-my-sleeve numbers.

The name comes from magic tricks - a magician shows you their empty sleeves to prove they're not hiding anything. Same idea here.

Instead of picking arbitrary-looking constants, you choose values with an obvious, verifiable origin:

These values are mathematically arbitrary (the algorithm would work with different constants), but their origin is transparent. You can verify them yourself.

Daniel Bernstein, the cryptographer who designed ChaCha20, chose to spell out "expand 32-byte k" because:

1. It describes what the algorithm does (expands a 32-byte key)
2. Anyone can verify the constants by converting ASCII to hex
3. There's no way he could have "tuned" plain English text to create a backdoor

It's cryptographic honesty baked into the code itself.

So What Do These Constants Actually Do?

Now that you understand why the constants are what they are, let's talk about what they do.

ChaCha20 works by filling a 64-byte block with ingredients, then scrambling them until the output looks random.

┌─────────────────────────────────────────────────────────┐
│  "expa"  │  "nd 3"  │  "2-by"  │  "te k"  │  ← Constants
├─────────────────────────────────────────────────────────┤
│              Your secret key (the seed)                 │
├─────────────────────────────────────────────────────────┤
│    Counter    │         Nonce                           │
└─────────────────────────────────────────────────────────┘

The constants fill the first 16 bytes. Always "expand 32-byte k".

The key is your seed - the secret that makes your random stream unique.

The counter lets you generate different blocks without changing the key.

Then ChaCha20 scrambles this block using simple operations: add numbers, flip bits (XOR), rotate bits left and right. It does this 20 times (that's the "20" in ChaCha20).

After 20 rounds of scrambling, the original structure is completely destroyed. What comes out looks like pure noise.

Why Do Constants Matter?

Here's the key insight: without those constants, if you fed in an all-zero key, you'd get predictable patterns.

The constants break symmetry. They're like adding a handful of gravel to a cement mixer - the gravel itself doesn't matter, but it ensures everything gets properly mixed.

And because they spell "expand 32-byte k", you know they weren't chosen to exploit some obscure mathematical weakness.

ChaCha20 Is Everywhere

SQLite didn't invent ChaCha20 - they just adopted it. And they're in good company.

ChaCha20 encrypts:

• Your HTTPS connections in Chrome and Firefox
• Your Android device's storage
• WireGuard VPN tunnels
• SSH connections

It's fast, secure, and trusted by some of the biggest tech companies in the world.

SQLite could have used a simpler, "good enough" random number generator. Instead, they chose the same algorithm that secures Google's infrastructure. For a 158-line file, that's a pretty serious commitment to doing things right.

The Blessing

While I was poking around random.c, I noticed something else. Every SQLite source file starts with this:

/*
** The author disclaims copyright to this source code.  In place of
** a legal notice, here is a blessing:
**
**    May you do good and not evil.
**    May you find forgiveness for yourself and forgive others.
**    May you share freely, never taking more than you give.
*/

No license. No legal threats. Just a blessing.

In a world of GPL, MIT, Apache, and Creative Commons debates, SQLite's creator Dr. Richard Hipp just asks you to be a decent human. The entire codebase is public domain - take it, use it, do whatever you want.

There's something beautiful about that.

What I Learned

Cryptographic constants can be honest

The "expand 32-byte k" constants aren't just random values - they're proof of good faith. When you see them, you know: this is ChaCha20, implemented correctly, with nothing to hide.

Takeaway: If you need magic numbers in your code, consider making their origin obvious.

Small decisions scale massively

SQLite runs on over a trillion devices. That means this 158-line random number generator probably executes billions of times per day. The decision to use ChaCha20 instead of something simpler wasn't flashy, but it matters.

Takeaway: Infrastructure code is where craft really counts.

Public domain still exists

In an era of license audits and legal teams, SQLite proves you can build critical infrastructure and just... give it away.

Takeaway: Sometimes the best license is no license at all.

One More Thing

SQLite has about 150,000 lines of source code.

Its test suite runs over 200 million test cases before each release. Plus, their continuous fuzzing setup checks another 500 million cases every single day.

That's roughly 1000x more test code than actual code. The ChaCha20 implementation I showed you has been verified, fuzzed, and stress-tested more than most codebases will ever be.

That's what it takes to power a trillion devices.

What's the most interesting constant or magic number you've found in source code? I'd love to hear about it.

Sources:

• SQLite source code - src/random.c
• How SQLite Is Tested