Padding-kk-bit state machine
The 136-byte output of the Padding-KK SM must first be translated to bits before it can be used as the Keccak-F SM's input. This is where the Padding-KK-Bit sta
The 136-byte output of the Padding-KK SM must first be translated to bits before it can be used as the Keccak-F SM's input.
This is where the Padding-KK-Bit state machine comes into the picture.
The Padding-KK-Bit SM play the role of converting bytes to bits in both directions. It also serves as a bridge between the bit-wise operating Keccak-F SM and the byte-wise operating Padding-KK SM.
The Padding-KK-Bit SM is in charge of validating each action connected to the inputs and outputs of the Keccak-F permutation blocks in addition to being a two-way bytes-to-bits converter.
Design strategy
Here's how this state machine facilitates operations between the Padding-KK SM and the Keccak-F SM.
A block of 136 rows of bytes in the Padding-KK SM corresponds to rows in the Padding-KK-Bit SM. The picture below, displays the correspondence, also shows three subdivisions of the rows (corresponding to ).

First subdivision: Consists of rows, where each of the byte-rows has been expanded into rows (i.e., rows for the bits plus row for the byte that represents the bits). The decomposition of the bytes into the 8 bits (with an extra row, just for the byte), is done for easy implementation in PIL. This subdivision of rows represents the bitrate of the KECCAK-F permutation. Therefore, a strategy to ensure that the bits are accurately and correctly provided, as input to the KECCAK-F SM, needs to be derived.
Second subdivision: Consists of the rows, and represents the capacity input-bits in the -bit state of the KECCAK-F SM. Within the KECCAK-F state machine, unlike the bits in the first subdivision of rows, the capacity bits are not affected by any exterior bits.
Third subdivision: Consists of rows represents the 256 bits of the intermediate hash value produced by the KECCAK-F permutation. At the end of hashing each 1088 bits (136-byte) string, this intermediate hash value actually coincides with the final hash of the KECCAK-256 hash function. Each hash value, the final digest, is packed into eight 32-bit registers at the final row of this subdivision.
Bytes to bits correspondence
This section elaborates how the Padding-KK-Bit SM handles the correspondence of bytes between state machines, and correct positioning of bits with respect to the powers of 2.
Starting with the first subdivision, the rows related to the bit decomposition of each byte, the following registers are utilised:
-
The Padding-KK-Bit state machine has a column named , which records all the bits associated with the decomposition of each of the bytes of the Padding-KK SM.
-
In order to relate the byte to its bit decomposition between the two states machines, a register called is added in both state machines as a bit-to-parent-byte identifier.
-
Also, another register called , is added for the sole purpose of sequentially constructing each byte from the bits.
-
A factor register is used to correctly place each bit in the parent, with respect to the powers of 2.
-
Therefore, each complete byte is recorded at the last row of such a 9-row byte block of the register. This row is flagged with a "1" in the same row of another register called . This ensures that is 0 in all rows except the last row of a 9-row byte block.
Example: Representation of two bytes
Here's an example of how two bytes, and , from the Padding-KK SM look like in the Padding-KK-Bit SM. The horizontal lines mark the end of a byte block.
Note that is equal to 1 in the last row of each byte block, and this is the same row where the corresponding complete byte is found in the column.
The following constraint applies to the column,
It is very important for to be "" when is "". If this is not the case, then there is no guarantee that the register will reset to in the next block.
It is also necessary to ensure that is binary, by using the next constraint,
Validating transitions of bits
The challenge of breaking down bytes into bits has been the main focus up to this point. Here, it is intended to verify the bit transitions following the KECCAK-F operation, which is carried out for each block of 136 bytes. For this, a few columns are introduced.
-
: This register stores the input bit of the current KECCAK-F permutation block.
-
: This register stores the output bit of the current KECCAK-F permutation block.
-
: The same idea as in the Padding-KK state machine applies here. The register is constant within a block, and reflects that the output of the previous permutation KECCAK-F is connected to the current one. That is, it indicates that the previous 136-byte block belongs to the same string as the current block.
-
: This register records "" in the very last row of each of the -row block corresponding to a 136-byte block of the Padding-KK SM, and everywhere else.
Below figure depicts a schema of how to relate the above columns with the KECCAK-F sponge construction.

Constraints for bit transitions
These constraints are needed to ensure correct transition between rows.
There is a need to make sure the register is constant in each block. Hence, the following constraint should be added,
It is also mandatory to test whether and are binary. For these two checks, the following equations are used,
The register is actually computed from , and columns. Recall that, at the first block of the sponge function, the input bits to the KECCAK-F permutation actually coincide with . However, after the first block, an of and must be performed, as seen in the above figure.
Therefore, is computed using an auxiliary register as follows,
A quick analysis shows the following,
-
If is , then equals , which is precisely what needs to happen in the first KECCAK-F permutation block.
-
But if is , then equals , which is actually the of and .
Below table shows all the cases of the above computation.
Capacity connection in the 512 rows
The second subdivision of the Padding-KK-Bit SM's -row block consists of the rows, corresponding to KECCAK-F SM's capacity bits. It is mandatory to ensure these capacity bits (the middle subdivision of each -row block) are not affected by any exterior bit.
First, a new register called is added, and it is defined such that it records in each of the rows corresponding to the capacity bits, and everywhere else. Hence, the following relationship is added.
This ensures that in each -row block, is everywhere in the rows corresponding to the capacity bits. This results in XOR-ing with a . And thus, for the rows corresponding to the capacity bits, computing , amounts to .
Therefore, these equations guarantee that the capacity bits are not modified by any exterior bits.
Output calculations in the (256 + 1) rows
Now, the last part of the Padding-KK-Bit SM is to keep track of the last subdivision of each -row block. Recall that this third subdivision consists of rows, and it is in charge of storing each bit of the intermediate hashes of the KECCAK-F permutation blocks. The bits of the KECCAK-F permutation output are sequentially and cumulatively stored in eight 32-bit registers . In a similar method used for the read operations in the Padding-KK SM, eight (8) factor columns are used to ensure correct positioning (of each of the bits in ) with respect to powers of .
Example: Storing 256-bit intermediate hash outputs
Consider the 256 bits, , where "" separates every set of 32 bits. The table below displays how the rows of a -block are stored in the registers .
Observe how factors , in the above table, are used to construct the -bit registers . Note that the last row contains the complete set of the bits. These columns fulfil the following relations,
where .
The register ensures that is not constrained at the very beginning of each -block, but only until the third subdivision is reached, where the begin to attain non-zero values.
This concludes our design for creating the Padding-KK-Bit SM. What is left to be done is to connect both states machines and check the validity of the last hash.
Padding-KK SM and Padding-KK-Bit SM connection
This section describes how these two state machines, the Padding-KK SM and the Padding-KK-Bit SM, connect via Plookup.
First of all, observe that there's a need to check whether the bytes received in one state machine are the same as those in the other. Also, corresponding sequential order of these bytes should be checked. The identifier register is added in both states machines for the very reason. In addition, each byte should have the same value in register. Hence, the following Plookup is added in the Padding-KK state machine,
The Padding-KK state machine has the registers while the Padding-KK-Bit state machine has the registers, which must be related to some point during the execution. Yet, up this point, the order of the hashes has not been checked in any way. Hence, as previously done, an register is added in both machines in order to identify each of these hashes.
In particular, is an increasing sequence of integers which increases by one at each processed block. That is, in the Padding-KK state machine, increases by one in each block of rows, whilst in the Padding-KK-Bit state machine, it increases by one in each block of rows. This is because a single block of rows in the Padding-KK SM corresponds to a single block of rows in the Padding-KK-Bit SM.
Hence, the following Plookup is added:
Last updated on
Padding-kk state machine
All Keccak-related state machines are accessed through the Padding-KK state machine. It is therefore responsible for handling queries from the Main state machin
Bits2Field state machine
The Bits2Field state machine is one of the auxiliary state machines used specifically for parallelizing the implementation of KECCAK-F SM. Its source code is av