I do some research with the candidates of the sha-3 competition. I am interested in the padding mechanisms of the skein hashfunction. For Example. I use the skein hash with 256 internal state size. Is it correct, if my message is a multiple of 256, that the input does not need to be padded? I could not find something usable in the documents of skein.

Thanks for help!


1 Answer 1


TL;DR: You only need (non-zero) padding in Skein if your message is not a multiple of 8 bits long.

Skein is built around a mode, the designers call "UBI" which relies upon a so-called tweakable block cipher, for Skein it's Threefish. A tweakable block cipher accepts three inputs: A tweak, a key and a plaintext block. The chaining value (eg the result of the last computation) is "the key" for the next block. Configuration data, like the current byte offset, the current tree parameters, and some other configuration values are fed into the tweak. The message is fed into the plaintext input, where there are two cases to distingfuish:

  • The message length is not a multiple of the block length: In this case simply zero-pad until you get a full block (the offset in the configuration will prevent collisions here)
  • The message length isn't even a multiple of 8 bits (ie an integral number of bytes long): In this case you add a special flag to the configuration value and a single set bit (ie a "1") behind your message. The rest is zero-padded again. The offset counter will only account for full bytes, thus "actual" padding is neccessary here.

If you want to read on it, the Skein specification is always there (PDF).

  • $\begingroup$ Thx. So if I have skein256-x (with 256-Bitsize) and a Message which is a multiple of 256, there will be no padding, right? And if there is a Message with 128 Bit, there will be 128 zeros as padding, right? $\endgroup$
    – chris000r
    Oct 20, 2016 at 18:53
  • $\begingroup$ @chris000r exactly. $\endgroup$
    – SEJPM
    Oct 20, 2016 at 18:57
  • $\begingroup$ @SEJPM I've implemented Skein long ago, but I guess this was due to the fact that the message length is included into the calculations at the end anyway. So there is no need for any padding scheme that can be distinguished from the message input. BTW, I do consider zero padding to be "real" padding, and should have noticed the impossibility of not padding when talking about a hash that is implemented using a (tweakable) block cipher. $\endgroup$
    – Maarten Bodewes
    Oct 20, 2016 at 19:42

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.