Cipher and Hash Identifier, Explained

After reading this you will be able to look at an unknown string and reason about what it is: which hash produced it, which encoding wrapped it, or which classical cipher scrambled it, using length, character set and two frequency statistics you can compute by hand.

You paste in a string and want to know what it is. Is 5d41402abc4b2a76b9719d911017c592 a hash? Which one? The answer is almost forced by its shape: 32 hexadecimal characters, no other alphabet, no separator. That length is the fingerprint of MD5. The string above is in fact MD5 of the word hello. No key, no cracking, just counting characters and recognizing an alphabet.

Identification is the first move in any CTF crypto challenge and in most forensic work. You cannot attack a ciphertext until you know its family. This article shows the reasoning the tool automates: measure length, classify the alphabet, then run letter statistics to separate substitution from transposition.

What the identifier actually decides

The tool answers three separate questions in order, because each one narrows the next.

Is it a fixed-length digest?
Hashes have exact output sizes. MD5 is 128 bits, SHA-1 is 160, SHA-256 is 256. Written as hex that is 32, 40 and 64 characters. If the string is exactly one of these lengths and contains only 0-9a-f, a hash is the leading guess.
Is it an encoding?
Base64, hex and Base58 are reversible transports, not secrets. They announce themselves by alphabet: Base64 uses A-Za-z0-9+/ and often ends in = padding, hex uses 16 symbols, Base58 drops the confusable 0OIl.
Is it a classical cipher?
If the text is mostly letters with spaces and reads like scrambled language, frequency analysis tells you whether letters were swapped (substitution) or merely reordered (transposition).

Hash and encoding fingerprints by length

Length plus alphabet identifies most digests uniquely. The table below lists the common cases. Note that bcrypt breaks the pattern: it carries its own prefix, so you read the algorithm directly instead of counting.

Common digests and encodings by length and alphabet
CandidateLengthAlphabetTell
MD532hex32 hex chars, no prefix
SHA-140hex40 hex chars
SHA-25664hex64 hex chars
SHA-512128hex128 hex chars
bcrypt60base64ishstarts $2b$
Base64multiple of 4A-Za-z0-9+/=trailing =

Length is a guess, not proof. A 32-character hex string could be MD5, NTLM, MD4, or half of a SHA-256. The tool reports MD5 first because it is most common, but the same digits fit several algorithms. Treat every identification as a hypothesis to test, never as a verdict.

The index of coincidence

Once you know the string is scrambled language rather than a hash, one number does most of the work. The index of coincidence (IC) measures how uneven the letter frequencies are. It is the probability that two letters drawn at random from the text are the same letter.

IC = \sum_{i=1}^{26} \frac{n_i (n_i - 1)}{N (N - 1)}

Here n_i is the count of letter i in the text, and N is the total number of letters. The numerator n_i(n_i-1) counts ordered pairs of that letter; the denominator N(N-1) counts all ordered pairs. Divide and you get the chance that a random pair matches.

The intuition: English is lumpy. The letter e is roughly 12.7 percent of text, so matched pairs are common. Random text spreads evenly across 26 letters, so matches are rare. That gives two anchor values you should memorize.

IC_{\text{English}} \approx 0.0667 \qquad IC_{\text{random}} \approx \frac{1}{26} \approx 0.0385

A monoalphabetic substitution (each letter always maps to one other letter) preserves the frequency shape. Swapping every e for x keeps x at 12.7 percent, so the lumpiness survives and IC stays near 0.067. A transposition (letters reordered, not replaced) does not change any count at all, so its IC is also near 0.067. A polyalphabetic cipher like Vigenere flattens the distribution toward random, pulling IC down toward 0.04.

A worked example on the demo text

Computing IC for a Caesar-shifted sentence

Take the demo sample WKH TXLFN EURZQ IRA, which is THE QUICK BROWN FOX shifted forward by 3 (a Caesar cipher). Drop the spaces and you have 16 letters.

  1. Count letters: W 1, K 1, H 1, T 1, X 2, L 1, F 1, E 1, U 2, R 2, Z 1, Q 1, I 1, A 1. That is N = 16.
  2. Sum the pair counts n_i(n_i-1). Only the three letters with count 2 contribute: X, U and R each give 2 \times 1 = 2. Every count-1 letter gives 0. The sum is 2 + 2 + 2 = 6.
  3. Divide by N(N-1) = 16 \times 15 = 240. So IC = 6 / 240 = 0.025.

That 0.025 is below both anchors, which looks like random text. The lesson is not that Caesar flattens frequencies (it does not), but that 16 letters is far too short to measure IC reliably. The statistic needs a few hundred characters before it settles near its true value. On a full English paragraph, this Caesar cipher would read close to 0.067, correctly flagging it as monoalphabetic.

With no JavaScript: as a Vigenere key gets longer, the index of coincidence of the ciphertext falls from the English value of 0.067 toward the random value of 0.0385. A key of length 1 (a Caesar cipher) leaves IC at 0.067; a key of length 10 drops it to about 0.044.

Reading the frequency profile

IC tells you the cipher family. The letter frequency bar chart tells you which one and helps you break it. A monoalphabetic cipher produces a lumpy chart with the same profile as English but relabeled: one tall bar (the disguised e), a cluster of medium bars, and a long tail of rare letters.

English frequencies fall off steeply from e at 12.7 percent; random text sits flat at 3.85 percent for every letter. Substitution preserves the steep shape, Vigenere flattens it.

If the chart is steep, guess the tall bar maps to e and the next few to t, a, o. If the chart is flat, you are looking at a polyalphabetic cipher, and IC across different assumed key lengths will help you find the period.

Common mistakes

Three errors account for most wrong identifications.

Measure IC on enough text. Below about 100 letters the estimate swings wildly, as the 16-letter example showed. Aim for 300 or more before trusting the family verdict.

First, confusing an encoding with encryption. Base64 and hex are not secret. If a string decodes cleanly to readable bytes, it was never encrypted, only transported. Decode it and look again at what falls out. Second, trusting length alone: a 40-character hex string is SHA-1 by default, but it could be RIPEMD-160 or a truncated hash. Third, ignoring the alphabet. A string of digits and letters that excludes 0, O, I and l is almost certainly Base58, used in Bitcoin addresses, not Base64.

Related tools on this site

Once you suspect a cipher, you need to break it. If the frequency profile stays lumpy but no simple substitution reads out, test XOR: try the XOR Cipher and Brute-forcer, which sweeps all 256 single-byte keys and scores each output for readable English. If the identifier flags a non-standard alphabet, confirm the encoding with the Base32 / Base58 / Base85 Encoder by decoding and checking whether printable text appears.

Frequently asked questions

Can the tool tell MD5 from other 32-character hashes?

Not with certainty. MD5, MD4 and NTLM all produce 32 hex characters. The identifier ranks MD5 first because it is by far the most common, but you confirm by hashing the suspected input yourself and comparing, or by context (NTLM comes from Windows password dumps).

Why does a short Caesar cipher show a low index of coincidence?

Because IC is a statistic that needs volume. On 16 letters, a handful of accidental repeats dominate, and the estimate lands near 0.025. On a full paragraph the same cipher reads near 0.067, the true English value, since substitution never changes letter counts.

How does IC estimate a Vigenere key length?

Split the ciphertext into every Nth letter for candidate key lengths N. When N equals the real key length, each slice was encrypted with a single Caesar shift, so each slice reads near 0.067. Wrong lengths give slices near 0.0385. The N whose slices jump to 0.067 is the key length.

Is Base58 more secure than Base64?

No. Both are encodings, not encryption, and both are trivially reversible. Base58 only drops confusable characters to reduce copy errors in addresses. Neither hides anything from anyone.

What does bcrypt look like?

A 60-character string beginning with $2a$, $2b$ or $2y$, followed by a cost factor like $10$ and then the salt and hash. The prefix names the algorithm directly, so no length counting is needed.