2
$\begingroup$

I would like to check if my following understanding of Keccak padding has any flaws and if there are, please feel free to point them out and correct them.

The Keccak version I am interested is the original Keccak with 256 bits output (not the SHA3 from NIST).

It has a bitrate of 1088 bits and a 256 output bits.

Assuming that a Keccak function operation has a absorbing phase followed by a squeezing phase, Keccak-256 would require 136 bytes (1088 bits) of memory space to compute on for every absorbing phase.

During the absorbing phase, a part of the input message of 136 bytes of length would be copied into the computation states (blocks/lanes ..etc..). If the copied message into the states are insufficient, a padding has to be applied otherwise if the message states are sufficient (exactly 136 bytes), nothing has to be done.

When padding occurs on the bit level, it will begin with bit 1 followed by a string of 0 until finally the last bit is also a 1 for the original Keccak-256.

I would like to know the flaws of my above description and what are the correct description in a very simply and easy to understand manner I should approach it from.

$\endgroup$

1 Answer 1

4
$\begingroup$

According to Keccak submission 3rd document on page 10, the padding scheme changed from round 2 to round 3.

We shortened and simplified the padding rule. The new padding rule is the pad101 rule

In the original specifications on page 3;

$\texttt{pad}(M, n)$ returns a bit string obtained by appending to the bit string M a single 1 and the smallest number of zeroes such that the length is a multiple of n.

In Sponge Construction Functions, The Keccak team proved that both satisfies

the sponge construction offers protection against generic attacks if the padding rule is sponge-compliant, i.e., it is injective and ensures that the last block is different from the all-zero block

They changed it because of this rationale:

pad101 is simpler to describe and to implement than the rounds 1-2 padding rule

In Short, Keccak padding rule evolved during the submissions.

$\endgroup$
1
  • $\begingroup$ Note: I was looking for the reasoning of the padding scheme of SHA-3, and come up with this question unanswered. Nothing special here :) $\endgroup$
    – kelalaka
    Commented Sep 1, 2019 at 18:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.