Entropy (Shannon)

Entropy in information theory (Shannon entropy) measures how unpredictable a random variable is, in bits. A 1-bit entropy source can produce 2 equally-likely outcomes; n-bit entropy can produce 2ⁿ. Mathematically: H = log₂(N) for N equally-likely outcomes.

Examples:

• A fair coin flip: 1 bit.
• A fair die roll: log₂(6) ≈ 2.58 bits.
• A random 8-character lowercase password: 8 × log₂(26) ≈ 37.6 bits.
• A random 16-character password from [a-z A-Z 0-9 symbols]: 16 × log₂(94) ≈ 104.9 bits.
• A UUID v4: 122 bits (6 bits are version/variant constants).

Why entropy matters for secrets: an attacker brute-forcing your password tries combinations one at a time. The expected work is 2ⁿ⁻¹ attempts where n is your password’s entropy. At a billion attempts per second:

• 40 bits: ~9 minutes to brute-force. Inadequate.
• 60 bits: ~17 years. Marginal.
• 80 bits: ~38 million years. Adequate.
• 128 bits: heat death of the universe before exhaustion. Cryptographic grade.

Common gotcha: entropy depends on the distribution, not just the value. A “random” password chosen by a human (“Password123!”) has far less entropy than its length suggests, because the human selection process isn’t uniform. Computer-generated random passwords (via crypto.getRandomValues or /dev/urandom) hit the full theoretical entropy of their charset.

Use our password generator to see the entropy meter live as you adjust length and character classes.

Worked example

Three passwords for the same imaginary account, ranked by Shannon entropy. First: Password123! — 12 characters, looks “strong” in length but the structure (dictionary word + sequential digits + obvious punctuation) drops effective entropy to roughly 20-25 bits because attackers use rule-based dictionaries (hashcat’s best64, OneRuleToRuleThemAll) that try this exact pattern. Crackable in under a minute. Second: a Diceware passphrase like correct horse battery staple — four words from the 7,776-word Diceware list, entropy = 4 × log₂(7776) ≈ 51.7 bits. Resistant to dictionary attacks for years on a single GPU. Third: 16 random characters from a 94-character alphabet via crypto.getRandomValues: 16 × log₂(94) ≈ 104.8 bits. Computationally infeasible to brute-force with any current or foreseeable technology. The lesson: entropy comes from the generation process, not from looking complicated.

An important subtlety: entropy is not the same as length. A 30-character password drawn from only lowercase letters has 30 × log₂(26) ≈ 141 bits — strong. But a 30-character “password” that’s actually a quote from a famous book has perhaps 20-30 bits because the search space is the catalogue of famous quotes, not every possible 30-character string. Attackers target the actual distribution, not the nominal one.

When and why it matters

Entropy matters every time a secret needs to resist guessing: passwords, API keys, session tokens, encryption keys, and the seeds for any cryptographic operation. NIST SP 800-63B (the modern password guidance) explicitly recommends targeting a minimum of 80 bits for long-term secrets and 128 bits for cryptographic keys. The most common mistake is generating “random” values using Math.random() — which is a non-cryptographic PRNG with at most 52 bits of effective state and is trivially predictable from a few outputs. For any security-relevant randomness, use crypto.getRandomValues() in browsers, crypto.randomBytes() in Node, secrets.token_*() in Python, or SecureRandom in Java/JVM. The second mistake is reusing a session token or nonce across multiple sessions; even a 128-bit value reused weakens the system to whatever channel leaked the original. Reference: NIST SP 800-63B — Digital Identity Guidelines.

Hardware vs software entropy sources: modern operating systems gather entropy from physical noise — keyboard timing jitter, mouse movement, network packet arrival times, and on recent CPUs, dedicated thermal-noise instructions (RDRAND on Intel, RDSEED on AMD). The Linux /dev/random historically blocked when the entropy pool ran low; /dev/urandom mixes the pool through a CSPRNG and never blocks. As of Linux 5.18 (2022) the two are essentially equivalent — both safe for cryptographic use once boot-time entropy is gathered. Cloud VMs and containers can have weak boot-time entropy; cryptographic key generation on a freshly-booted VM is one of the few remaining cases where waiting briefly for entropy to accumulate measurably matters. Reference: RFC 4086 — Randomness Requirements for Security.