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.