keys

Overview

Modern cryptography follows Kerckhoffs's principle: the algorithm can be public; all the secrecy lives in the key. That makes key handling — how keys are generated, stored, distributed, rotated, and destroyed — the single most important factor in whether an otherwise strong cipher actually protects anything. A perfect algorithm with a leaked, predictable, or hard-coded key protects nothing. This lesson covers what keys are and how to manage them correctly.

Learning objectives

• Explain why security depends on the key, not the secrecy of the algorithm.
• Describe how keys should be generated (randomness/entropy) and sized.
• Outline the key lifecycle: generation, storage, distribution, rotation, destruction.
• Distinguish a key from a password, and explain what a KDF does.

Core concept

A key is the secret input that makes a cryptographic operation unique. Because the algorithm is assumed to be known (Kerckhoffs's principle), an attacker who does not have the key must not be able to break the scheme. Good key management rests on a few properties:

• Unpredictability — keys must come from a cryptographically secure random source with enough entropy. A key an attacker can guess or reproduce is no key at all.
• Sufficient length/strength — the key space must be large enough to make brute force infeasible (for example, AES-128/256; RSA/ECC key sizes chosen per current guidance).
• Confidentiality of secret keys — symmetric keys and asymmetric private keys must be protected at all times.
• Proper lifecycle — keys are generated securely, stored safely, distributed only to those who need them, rotated periodically or after suspected compromise, and destroyed when retired.

A password is not the same as a key: passwords are human-chosen and low-entropy. To turn a password into a key you use a key derivation function (KDF) such as PBKDF2, scrypt, or Argon2, which stretches the password (slowly, with a salt) into a proper key.

How it works

• Generation: use the platform's secure random generator (a CSPRNG), never a predictable source like the current time, a counter, or a language's non-cryptographic rand(). Weak randomness makes keys guessable.
• Storage: keep secret keys out of source code and out of the data they protect. Use a secrets manager, a keystore, environment configuration injected at runtime, or hardware/HSM/KMS solutions. Restrict access with least privilege.
• Distribution: deliver shared symmetric keys over a secure channel (or establish them via asymmetric key exchange, as covered previously). Never email or commit keys.
• Rotation: change keys on a schedule and immediately if a compromise is suspected, so a leaked key has a limited useful lifetime.
• Destruction: securely retire old keys so they cannot be recovered and reused.

Practical example

A team ships an application that encrypts stored records with AES. Early on, a developer hard-codes the AES key as a string constant in the source so "it just works." That source is committed to the repository. Now the key travels everywhere the code does — every clone, backup, and build artifact — and anyone who reads the code (or extracts strings from the compiled binary) has the key and can decrypt every record. The fix is to generate the key from a secure random source, store it in a secrets manager or KMS outside the codebase, load it at runtime, and rotate it if it was ever exposed.

In an isolated CTF, this exact anti-pattern is a staple: challenges hand you a binary or source repository, and the "crypto" is broken not by attacking AES but by finding the hard-coded key (in the source, in embedded strings, or in a committed config file). The lesson mirrors reality — the algorithm was fine; the key management was not.

Cybersecurity relevance

Real-world breaches frequently trace back to key management, not broken math: secrets committed to public repositories, keys embedded in mobile apps, predictable keys from weak randomness, and keys that were never rotated after a known exposure. Because Kerckhoffs's principle holds, defenders treat the key as the crown jewel — generated with strong entropy, stored in dedicated secret stores, tightly access-controlled, and rotated. In CTFs, "recover the key" challenges train you to hunt for exactly these failures, which is directly the skill a defender needs to prevent them.

Common mistakes

• Hard-coding keys in source code, binaries, or committed config files.
• Generating keys from weak randomness (timestamps, counters, non-cryptographic RNGs), making them predictable.
• Using a low-entropy password directly as a key instead of deriving one with a proper KDF (PBKDF2/scrypt/Argon2) and a salt.
• Never rotating keys, so a single old leak stays exploitable indefinitely.
• Storing the key next to the data it protects, so one breach exposes both.

Key takeaways

• Security depends on the key, not the secrecy of the algorithm (Kerckhoffs's principle).
• Keys must be unpredictable (secure randomness/entropy) and long enough to resist brute force.
• Manage the full lifecycle: generate securely, store outside code in a secrets manager/KMS, distribute over secure channels, rotate, and destroy.
• A password is not a key — derive keys from passwords with a salted KDF; never hard-code keys.

Check your understanding

• Kerckhoffs's principle says the algorithm can be public. What does that imply about where all the security must reside?
• Why is deriving a key from a password with a KDF better than using the password directly as the key?