What Makes a Good Secret Key?

Secret keys are the backbone of modern digital security. Whether you’re building a web app, encrypting data, or securing APIs, a strong secret key can mean the difference between rock-solid protection and catastrophic vulnerability. But what exactly makes a secret key ‘good’?

High Entropy

Entropy is a measure of randomness. The higher the entropy, the harder it is for an attacker to guess your key. You can throw randomness into the key in many ways, like randomly mashing the keyboard or generating secrets with all the tools available at our disposal by default.

In summary, a good secret key should be randomly generated, long enough to resist brute-force attacks, and binary-safe (meaning all systems should interpret it, more on this below). Here’s one of the quick examples of how to generate a key in your terminal with 128 bits of entropy in base64 format.

openssl rand -base64 32

Now let’s delve into each of these and understand what’s the recommended practices.

What’s a good length for a key?

Short keys are hands down insecure! Especially in this time of GPUs, where brute-forcing is a job that a script kiddie can do. Typically, key length depends on use case, but some general rules apply. It should be long! Long enough to resist brute-force attacks.

128 bits (16 bytes) is the minimum for symmetric encryption algorithms like AES. 256 bits (32 bytes) is a modern best practice. 1024 bits (128 bytes) and 2048 bits (256 bytes) are standard lengths for asymmetric encryption keys, such as RSA. These are used not for secret keys but for public/private key pairs. They’re much longer because asymmetric algorithms rely on complex mathematical problems rather than shared secrets.

What’s a good binary safe encoding?

Wait, what does being binary safe mean? Secret keys are often stored or transmitted in text format because raw binary data can break things. it might include characters that confuse systems or can’t be displayed. To make them safe and portable, we encode them into friendly formats.

Base64 is the standard encoding format used. It’s like turning gibberish into readable-ish code using only letters, numbers, and a couple safe symbols. It’s compact, doesn’t break in transit, and works well in APIs and config files.

And then comes Hex or Hexadecimal. Think of it like a computer-friendly version of numbers. Every byte turns into two readable characters (like “f4” or “a9”). Easy to eyeball and often used in settings files.

And then there is ASCII! Just plain text! It has low entropy and hence it’s not good for creating strong keys. You might only see it in test environments, but never in production. If you see one in production, scream right there like a mad cow and get it fixed.

What’s the most secure way to store keys?

You’ve created the world’s strongest password, but then you write it on a sticky note and tape it to your laptop. That’s … the worst key storage ever to exist on this planet. Even the most secure key is useless if someone can easily find it. Here’s how to do it right!

The most obvious rule! Never hard-code in source files. Putting keys directly into your code is like shouting your password in public. Anyone who sees the code (including version control history) can steal it.

The standard one. Use .env files or secrets managers. A .env file is a simple text file that stores what’s known as the environment variables. Like secret keys, passwords, or API tokens, separately from your code, keeping it off the version control. When your applications run, they can be configured to use these variables within their scoped environment, thereby not exposing it. With proper permissions and encryption practices, .env is a good way to store secrets.

The most secure way would be to use a secret manager from the all-mighty AWS or similar services.

Good practices with keys

Besides the above requirements, the onus is also on the maintainer, you, to maintain the keys properly. Like how you pledged not to stick your secret key as a note on the computer, you should also regularly pledge to rotate the keys and use separate keys for different environments. In other words, maintain proper key discipline.

A good secret key isn’t just about bits and randomness. It’s about process. How you generate, encode, store, and rotate secrets determines your system’s real-world security. Prioritize entropy, avoid shortcuts, and treat your keys like the digital crown jewels they are.

This post was first published on January 16, 2013.