Sizing Keys, Digests and Entropy in the Unit Cryptographers Use
Cryptography is quoted in bits and stored in bytes. A standard names an algorithm after its security parameter — AES-256, SHA-512, Ed25519 — while the key material sitting in your secret manager, your buffer or your HSM slot is measured in bytes. Getting the translation wrong is not a cosmetic error: passing a 32-character password where a 32-byte random key was expected quietly destroys most of the strength the algorithm was chosen for.
bits = bytes × 8. So a 32-byte secret is 32 × 8 = 256 bits — exactly the key AES-256 expects, and exactly the digest length SHA-256 emits.Bits are the unit of security strength, because strength is about how many distinct values an attacker must search. Bytes are the unit of storage and transport. Almost every key-management review ends up moving between the two, usually while reading a library signature that says keyLen without saying which unit it means.
Symmetric keys
Asymmetric keys
Entropy of a secret
Checking a Key Length Before You Ship It
Measure the raw material, not its encoding
Take the byte length of the decoded secret. Base64 inflates it by roughly a third and hex doubles it, so a 44-character Base64 string and a 64-character hex string both describe the same 32 raw bytes.
Type it into the bytes field
The bit figure appears as you type, so you can step through 16, 24 and 32 bytes and watch the AES-128, AES-192 and AES-256 boundaries fall out. A comma or a dot both work as the decimal mark and spaces are ignored.
Copy the value into your spec or ticket
Each field carries its own copy button and returns the plain number with no unit attached — convenient when the figure is destined for a threat model, a key-rotation runbook or a config constant.
Reverse it to size a buffer
Swap the two fields when a standard hands you bits and you need the allocation in bytes — a 384-bit digest becoming a 48-byte array, for instance. The searchable dropdowns also reach kilobytes if you are sizing a certificate bundle rather than one key.
Key and Digest Lengths: Algorithm, Bits and Bytes Side by Side
This is the lookup most people actually want when a library rejects their key material. Notice how the RSA row breaks the pattern of the others: its byte length is large while its security strength is not.
| Algorithm or value | Quoted length (bits) | Raw storage (bytes) | Hex characters |
|---|---|---|---|
| AES-128 key | 128 | 16 B | 32 |
| AES-256 key | 256 | 32 B | 64 |
| SHA-1 digest | 160 | 20 B | 40 |
| SHA-256 digest | 256 | 32 B | 64 |
| SHA-512 digest | 512 | 64 B | 128 |
| UUID (version 4) | 128 | 16 B | 32 |
| Ed25519 private seed | 256 | 32 B | 64 |
| RSA-2048 modulus | 2 048 | 256 B | 512 |
A version-4 UUID is the clearest illustration of length versus strength: it occupies 128 bits, but six of them are fixed version and variant markers, leaving 122 bits of actual randomness.
Both fields editable during a review
Enter a figure on either side and the other updates at once, so a design review can jump between "the RFC says 384 bits" and "our buffer is 48 bytes" without retyping anything.
Large values stay legible
Thousands are separated with a space and very large figures switch to scientific notation, which helps when you are expressing a whole keystore rather than a single key.
Scales past a single secret
The searchable unit menus on both sides also cover kilobytes and megabytes, so the same page handles a key bundle, a revocation list or an exported keystore.
Values never leave the browser
All arithmetic happens locally once the page has loaded, so lengths taken from a real key inventory are not transmitted to any server.
Key Sizing Questions
Why is an AES-256 key only 32 bytes long?
The 256 in the name is the key length in bits, and 256 ÷ 8 = 32 bytes. The key is pure random material with no header, checksum or encoding, so nothing is wasted. If a library asks for 32 bytes and you hand it a 32-character password, the length matches but the unpredictability does not — that is what a key-derivation function with a salt and a high iteration count exists to repair.
An RSA-2048 key is 2 048 bits, so why is the key file several kilobytes?
The 2 048-bit figure describes the modulus alone, which is 256 bytes. A private key file also stores the two primes, the private exponent and the CRT parameters, wrapped in an ASN.1 structure and then Base64-armoured into PEM — each step adds bytes. A public key file is far smaller because it carries only the modulus and a very short exponent.
How many bits of entropy does a passphrase really have?
Entropy depends on how the passphrase was generated, not on how long it is. Words drawn uniformly at random from a 7 776-word list contribute about 12.9 bits each, so a five-word phrase carries roughly 64 bits no matter that it occupies thirty-odd bytes on disk. A phrase of the same byte length that a person invented is worth dramatically less, because the choices were never uniform.
Is a 128-bit UUID enough randomness for a session token?
A version-4 UUID is 16 bytes, of which four bits encode the version and two the variant, leaving 122 random bits. That is ample against guessing — but only if it came from a cryptographically secure generator, which many UUID implementations do not promise. Version-1 UUIDs are worse still, since they embed a timestamp and a MAC address. For tokens, generate 32 random bytes directly instead.
Why are hash outputs always described in bits rather than bytes?
Because the bit count is what determines collision resistance: a digest of n bits gives roughly n / 2 bits of resistance under the birthday bound, so SHA-256 offers about 128 bits against collisions. Calling it "a 32-byte hash" would hide that relationship. The same reasoning applies when you truncate a digest for a short fingerprint — the safe amount to keep is argued in bits.
No comments yet. Be the first to comment!