Keccak implementation

[hafedh-trimeche]

Hello,

Would Keccak be implemented (224, 256, 384 and 512)?

Best regards.

[MHumm]

DEC contains SHA3 implementations for 224, 256, 384 and 512 bit. What's the difference to Keccak, which became to SHA3 back then? Can you explain?

[hafedh-trimeche]

Hello,

The outputs of SHA3 and Keccak are different:
https://www.cybertest.com/blog/keccak-vs-sha3
https://keccak.team/keccak.html
https://medium.com/@ConsenSys/are-you-really-using-sha-3-or-old-code-c5df31ad2b0

SHA3 would be named SHA-3.

SHA-3 & Keccak would be tested on:
http://emn178.github.io/online-tools/sha3_256.html
and
http://emn178.github.io/online-tools/keccak_256.html

Best regards.

[MHumm]

Ok, so your request is really to implement the original keccak implementation which got modified between the two NIST competition rounds? As far as I've read the difference is the number of rounds used internally.

[MHumm]

Can you help me to clarify the differences between Keccak and SHA3? I could start an implementation then.
Is this simply the ability to change hash length n (which is fixed to 224, 256, 384 or 512 for SHA3), block length r?
Or is the number of rounds, which I have read was changed from 18 to 24 relevant as well? And if yes, should the user be able to change this one?

[MHumm]

I started to work on it but got stuck. I seems that the only difference lies in the passing of the message. But all references pointing out where the difference in other implementations are did not really help me. Either I didn't find that code, or I didn't see where the analogous code is in DEC's implementation.

So unless I get help from somebody I'll stop working on this for now! I'll put my early attempt into the development branch, so if you want to help you can use that as starting point.

[mike1atgithub]

Hello hafedh-trimeche

just a "dirty" test... try this:
In unit DECHash
procedure THash_SHA3Base.FinalBit_LSB
there is padding code for SHAKE and SHA3

• SHAKE (1111 10*1) and
• SHA3 (01 10*1)

Replace this SHAKE/SHA3 padding code
for KECCAK (10*1) ; i.e.

• don't change lw,
• set WorkingBitLen := Bitlen;

 procedure THash_SHA3Base.FinalBit_LSB(Bits: Byte; Bitlen: UInt16;
                                     var Hashvalue: TSHA3Digest);
var
  WorkingBitLen : Int16;
  lw : UInt16;
begin
  Bitlen := Bitlen and 7;
  if Bitlen = 0 then
    lw := 0
  else
    lw := Bits and pred(word(1) shl Bitlen);

   WorkingBitLen := Bitlen; // KECCAK test

  // update state with final bits
  if WorkingBitLen < 9 then
 

Test f.e. with:

      W := THash_SHA3_256.Create;
      s := 'The quick brown fox jumps over the lazy dog';

      WriteLn('KECCAK digest (hash value) of ' + s + ' is ' + sLineBreak +
              W.CalcString(s, TFormat_HEX));
      W.Free;

Does this help?

Regards
Michael

[MHumm]

I hope to find the time within the next few days to have a look/test integration of that. If things go well I should be able to provide it at least in the development branch sooner than later.

[MHumm]

Yes, this helps ;-)

[MHumm]

Ok, the implementation of all 4 Keccack variants (224, 256, 384 and 512) is available in the development branch now, albeit still without unit tests. I will start on those in the next few minutes though!

Ok, there's still somethign in it which makes it not useable, but I've already fixed this and work on unit tests so as soon as I've made more progress on the unit tests there will be an improved commit.

[MHumm]

Ok, fixed commit but still containing some failing unit tests.

[MHumm]

I tried to implement unit tests using the original test vector files found here:
https://keccak.team/obsolete/KeccakKAT-3.zip but only those with a bit length of 0 or 1 or with a bit length which can be divided by 8 without reminder or which can be divided by 8 with a reminder of 1 run. All others seem to fail. The last commit contains the attempt for the 224 variant. The online calculator linked to above is not of much help, as that can only calculate hashes over messages with lengths which can be divided by 8 without reminder.

[MHumm]

I worked on unit testing of Keccac yesterday, with a bit of help from Michael. Status is: some of the tests run 100% flawlessly now while a few test variants still report failures. I do guess that the basic implementation of Keccak is nhot at fault but we need to check some things with the failing tests. This might take some time though...

[mike1atgithub]

Iff message length m, m mod 8 <> 0

fbl := m mod 8

NIST/DEC input and Keccak Team input are different from each other for the last byte:

• NIST/DEC: The fbl bits are aligned to the right side of the byte
• Keccak Team: The fbl bits are aligned to the left side of the byte

example from "Keccak 224" test vectors:
Len = 2
Msg = C0
MD = 6B22CDDBD1366F7B8DB2026AEE8A0AFA86B323AED7AA270AD928D1C5

Msg C0= 1100 0000

The same message in NIST/DEC format:
0000 0011 = 03

i.e. for DEC the input must be:
Len = 2
Msg = 03
MD = 6B22CDDBD1366F7B8DB2026AEE8A0AFA86B323AED7AA270AD928D1C5

Msg Keccak Format => Msg NIST/DEC format
(fbl > 0): LastByte(Msg) := LastByte(Msg) shr (8-fbl)

Another example:
Keccak msg = FD, len=5
FD = 1111 1101
=> DEC/NISt msg = 0001 1111 = 1F (=FD shr (8-5))

Tested with DEC dev and # ShortMsgKAT_224.txt # Algorithm Name: Keccak # Principal Submitter: The Keccak Team (Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche)

[MHumm]

As all the unit tests in the development branch run properly now, can I close this issue/request because it is available in development branch at least?