Keccak-256

Keccak-256 turns any sequence of bytes into a 32-byte digest. Ethereum uses it when hashing transaction signing payloads, messages, and many other values. The function sees only bytes; it does not know what those bytes mean.

Follow one small input through the whole calculation: the text abc, encoded as the three bytes 61 62 63. The diagrams start with this input. You can change its length to explore other cases, then use Reset to abc to return to the example.

The whole journey

Keccak keeps a 200-byte working state, initially all zeros. Each input block contributes 136 bytes to that state. The remaining 64 bytes receive no input directly, but participate in the mixing.

For abc, the calculation is:

Pad: extend the three input bytes to a 136-byte block.
Absorb: combine that block with the first 136 bytes of the state using XOR.
Mix: run 24 rounds over all 200 state bytes.
Read: serialize the first 32 bytes of the resulting state as the digest.

A longer input needs several blocks. Absorb one, mix, then absorb the next into the state you already have. Only after the last block do you read the digest.

The 136-byte input/output portion is called the rate; the remaining 64 bytes are the capacity. These are Keccak-256's fixed parameters, not values calculated from the message length. The 256 in the name refers to the 256-bit output, not the input block or the working state.

Make room for padding

Our three bytes do not fill a 136-byte block. Padding supplies the ending and fills the space before absorption.

For a byte-aligned message, append 01, fill the remaining space with zeros, and set the highest bit of the block's final byte. Usually that final byte becomes 80. If just one byte is available, both markers occupy it: 01 | 80 = 81.

For abc, the padded block is 61 62 63 01, followed by 131 zero bytes, then 80. That is exactly 136 bytes. The added bytes are part of the calculation, not more message text.

Input \cdot abc \cdot 61 62 63 Reset to abc

Input length3 B

Block 01136 B · hex bytes

Input 3 BPadding 133 B

Each outlined block holds 136 bytes. Input bytes show their actual hexadecimal values; the outlined region contains padding, with hollow dots standing for 00. The 01 and 80 markers show its beginning and end.

What if the message already fills a block?

Compare input lengths of 135 and 136 bytes using the slider. At 135 bytes, only one byte remains: both markers share it, giving 01 | 80 = 81. At 136 bytes, the input fills the block, so a whole additional block carries the padding. Even an empty input needs one padded block. Reset to abc before continuing the worked example.

The bit-level rule is pad10*1: a starting 1, zero or more 0 bits, then a final 1. For byte-aligned Keccak-256 input, this gives the byte ending shown here. Unlike SHA-256 ⁠, it does not append an eight-byte message-length field.

From bytes to bits

The padding picture counts bytes. The state pictures below show bits. These are two views of the same data: one byte contains eight bits.

For abc, the first eight padded bytes are 61 62 63 01 00 00 00 00. Here are the first eight bytes of the currently selected block. Each row shows one byte in hexadecimal, then expands it into eight 0 or 1 values. Select a row to highlight its eight bits.

Input \cdot abc \cdot 61 62 63 Reset to abc

First 8 bytesEach row = 1 byte

ByteHex01234567

Each row is 1 byte. Eight rows form one 64-bit lane.

Read each row from bit 0 on the left to bit 7 on the right, matching the bit pictures used below. Their weights are 1, 2, 4, 8, 16, 32, 64, and 128. So hex 01 appears as 1 0 0 0 0 0 0 0; hex 80 would appear as 0 0 0 0 0 0 0 1. This is the reverse of how binary numbers are usually printed.

The eight rows together contain 8 × 8 = 64 bits. Keccak groups these eight bytes into one lane. In the next diagrams, each small square is one lane: the same eight rows of bits, with dark dots for 1 and pale dots for 0. Those diagrams show the state after absorbing or mixing; this table shows the input bytes before those operations.

Keep a larger state

Now return to the 200-byte working state. Group its bytes eight at a time: 200 ÷ 8 = 25 lanes. We draw these as a 5×5 grid. Each small square contains the eight rows of bits just introduced; a lane is not a separate hash.

The padded block has 136 ÷ 8 = 17 groups of eight bytes. Those groups will enter the first 17 state lanes. The other 8 lanes form the capacity.

Two regions have different roles:

Region	Size	Direct input/output
Rate	1,088 bits · 136 bytes · 17 lanes	Receives input blocks; supplies output bytes
Capacity	512 bits · 64 bytes · 8 lanes	No direct input XOR or output extraction

Both regions participate in every permutation. Capacity is not unused space, nor is it a secret key. It is state that the sponge interface does not expose directly.

We label a lane A[x,y]. In the diagrams, x increases to the right and y increases downward. Bytes visit lanes in the order x + 5y, starting with A[0,0]. The first seventeen positions are the rate.

Absorb one block

XOR combines corresponding bits: equal bits give 0; different bits give 1. It is written ⊕.

For example, 01 ⊕ 00 = 01, while 01 ⊕ 01 = 00. XOR is neither addition with carry nor overwriting a value.

The initial state is all zeros. XORing our padded abc block into it therefore leaves the input bits unchanged: the first 17 lanes now show the padded bytes. The 8 capacity lanes remain zero at this absorption step. The mixing that follows can change every lane.

For a later block, continue from that permutation's output. Do not reset the state. XOR the next block into the same rate positions and permute again.

Input \cdot abc \cdot 61 62 63 Reset to abc

Input length3 B

A[0,0]

State in0000000000000000

⊕ Input word0000000001636261

= Absorbed0000000001636261

After 24 rounds4fa945ea7a65034e

1 dot = 1 bit101 lane = 64 bits

Rate · 17 lanesCapacity · 8 lanes

With abc selected, choose A[0,0]. Its incoming value is zero, so its absorbed value equals the input word. Choose a capacity lane to see that it receives no input word. The separate ‘After 24 rounds’ value previews the mixing step described next.

Bytes enter each lane least significant first. With abc, the first eight padded bytes are 61 62 63 01 00 00 00 00. As a 64-bit number, that is 0000000001636261. The apparent reversal is byte order, not another hashing operation.

To explore a later block, set the input length to 137 and select Block 2. Its incoming state is the mixed result of Block 1, so XOR no longer looks like copying the input.

This repeated input-and-mixing process is the absorbing phase of a sponge construction. The rate determines how much input enters per permutation; the capacity remains internal while the two regions mix.

Mix twenty-five lanes

The next operation mixes what is already in the state; it does not add more message bytes. Its name is Keccak-f[1600], and it applies 24 rounds to the same 1,600 bits.

Each round lets bits influence other positions. First information crosses columns, then bits rotate within lanes and lanes move across the grid. Neighboring lanes are combined, and a round-specific constant is added by XOR. Repeating these operations spreads the input's influence through the state.

The five steps always run in this order. For a first reading, follow what each step does; the equations are optional:

Step	What changes	Where information travels
θ · theta	XOR a correction into each lane	Across columns
ρ · rho	Rotate bits within each lane	Between bit positions
π · pi	Move lanes to new coordinates	Across the grid
χ · chi	Combine three lanes with XOR, NOT, AND	Across rows, nonlinearly
ι · iota	XOR a round constant into `A[0,0]`	Break round symmetry

Input \cdot abc \cdot 61 62 63 Reset to abc

Round 0

A[0,0]

Before0000000001636261

⊕ D[0] = 0000000000000001

After θ0000000001636260

1 dot = 1 bit101 lane = 64 bits

The matrix shows the state after the selected step. Each tile contains its actual 64 bits: bit indexes increase left to right, then top to bottom. Select a lane to compare its complete before-and-after values. Dashed outlines mark dependency positions in the incoming state; for π, the lane tiles move to their destination coordinates. The round slider covers rounds 0–23 of the selected block's permutation.

The five steps in equations

Theta first XORs the five lanes in each column to get a column parity. For column $x$ , combine the parity to its left with a one-bit rotation of the parity to its right. XOR that correction into every lane in column $x$ .

C[x]=\bigoplus_{y=0}^{4} A[x,y],\qquad D[x]=C[x-1]\oplus\operatorname{ROTL}_1(C[x+1])

A'[x,y]=A[x,y]\oplus D[x]

Column indexes wrap modulo five. The outlined columns in the theta view provide the two parities; the selected lane contributes its original value as well.

Rho rotates each lane left by its fixed offset. Pi then moves that rotated lane from $(x,y)$ to $(y,\,2x+3y\bmod5)$ . These operations redistribute existing bits; neither introduces a new message block.

Chi uses the current lane and its next two neighbors in the same row:

A'[x,y]=A[x,y]\oplus\bigl(\neg A[x+1,y]\land A[x+2,y]\bigr)

All lanes in this equation come from the state before chi. Updating a lane and immediately using that changed value for its neighbor would compute the wrong function. NOT is restricted to 64 bits.

Iota changes only A[0,0] by XORing a fixed round constant. Round zero uses 0000000000000001. The offsets and constants are public parameters of the algorithm, not keys. The Keccak specification summary lists the complete tables.

For our single-block abc input, completing round 23 finishes the mixing. For a multi-block input, the next action would instead be to XOR in the next block and run another 24 rounds.

Read the digest

After the final padded block has been absorbed and permuted, serialize the rate lanes in the same order used for input. Each lane becomes eight bytes, least significant first.

Keccak-256 needs only 32 output bytes. Those fit inside the 136-byte rate, so take the first four lanes. No extra permutation is needed between the last absorption permutation and this output.

Input \cdot abc \cdot 61 62 63 Reset to abc

A[0,0]64 bits

Numeric hex

4fa945ea7a65034e

↓ Least-significant byte first

4e03657aea45a94f

Keccak-25632 B

With abc selected, the digest is:

TEXT

4e03657aea45a94fc7d47ba826c8d667
c0d1e6e33a64a036ec44f58fa12d6c45

These two lines form one continuous 64-digit hexadecimal value: two hex digits per byte, for 32 bytes. The full 200-byte state still exists internally; the digest exposes only its first 32 serialized bytes.

More output, and why the digest does not reveal the input

A general sponge can produce more output by reading the rate, permuting again, and reading another rate-sized portion. That is the squeezing phase. Keccak-256 stops after 32 bytes; an application cannot change its digest length and still call the result Keccak-256.

The permutation itself is reversible if its entire state is known. That does not make the hash reversible: the digest leaves most state bits unobserved, and the original input may have contained many blocks. Seeing a changed input spread across the state illustrates diffusion; it is not by itself a proof of cryptographic security.

Three similar names

Keccak-256 and SHA3-256 use the same state size, rate, capacity, and permutation. For byte-aligned inputs, the distinguishing change is the delimited suffix: Keccak-256 starts the ending with 01; SHA3-256 uses 06. If only one byte remains, their endings become 81 and 86 respectively.

That small input difference passes through the whole permutation and changes the digest. SHA-256 is a different design altogether: 64-byte input blocks, 32-bit words, a message schedule, and compression rounds. Its 32-byte output length does not make it interchangeable with either one.

Input \cdot abc \cdot 61 62 63 Reset to abc

Input length3 B

Keccak-256Suffix 01

4e03657aea45a94fc7d47ba826c8d667c0d1e6e33a64a036ec44f58fa12d6c45

SHA3-256Suffix 06

3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532

SHA-256

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

At length zero, Keccak-256 begins c5d24601, SHA3-256 begins a7ffc6f8, and SHA-256 begins e3b0c442. These empty-input vectors are a useful first check that a library is using the intended algorithm. The complete values are shown above.

SHA3-256's suffix and sponge parameters are specified in FIPS 202. Ethereum uses Keccak-256, including Solidity's keccak256. Substituting sha3_256 from another library produces the wrong Ethereum digest.

Bytes before the hash

The hash function sees bytes, not the intent behind them. UTF-8 text "0x1234" consists of six bytes; decoding hexadecimal 0x1234 produces two. Hashing those two inputs gives different results even when both callers say they are hashing “0x1234”.

For a transaction ⁠, the protocol defines the serialized bytes to hash. EIP-191 ⁠ adds a message prefix. EIP-712 ⁠ combines a domain hash with a structured-message hash. Those formats decide which bytes enter Keccak-256; the sponge then applies the same calculation.

That separation matters when debugging signatures. First reproduce the exact input bytes, then check the hash algorithm. A correct Keccak implementation cannot compensate for a missing prefix, different field order, or incorrect byte encoding.

0xa.eth