Slashdot Mirror

Please read the comments from the authors regarding Sha-3 http://keccak.noekeon.org/yes_this_is_keccak.html

Precisely...NIST is saying that out of 4 levels of security (224, 256, 384, 512), they are going to drop the 224 and 384 as they don't offer enough benefit for the added complexity. They are keeping the strongest option (512). The briefer was just stating that this is equivalent to 256 bits of security. Think the hash-equivalent of AES 256.

You mix up n with c, where n is the output (digest) length and c is the internal parameter "capacity". You can tell from http://keccak.noekeon.org/NoteOnKeccakParametersAndUsage.pdf section 3 that the capacity specifies the security (read preimage complexity) of the algorithm.

In fact the idea to cripple Keccak came from its creators. In their original submission they used for (n,c) the values (224, 448), (256, 512), (384, 768) or (512, 1024). In their Sakura (section 6.2) proposal they had lowered c to allow only values of 256 and 512 (Why there is no n in the second proposal: In this proposal they treated Keccak as a sponge function, where the output n may be any length (you get a PRNG and masking for free)).
In the CHES presentation, Slide 45 already uses crippled capacities.
You can read in slide 49 that NIST overtook Sakura's padding scheme.

Precisely...NIST is saying that out of 4 levels of security (224, 256, 384, 512), they are going to drop the 224 and 384 as they don't offer enough benefit for the added complexity. They are keeping the strongest option (512). The briefer was just stating that this is equivalent to 256 bits of security. Think the hash-equivalent of AES 256.

You mix up n with c, where n is the output (digest) length and c is the internal parameter "capacity". You can tell from http://keccak.noekeon.org/NoteOnKeccakParametersAndUsage.pdf section 3 that the capacity specifies the security (read preimage complexity) of the algorithm.

In fact the idea to cripple Keccak came from its creators. In their original submission they used for (n,c) the values (224, 448), (256, 512), (384, 768) or (512, 1024). In their Sakura (section 6.2) proposal they had lowered c to allow only values of 256 and 512 (Why there is no n in the second proposal: In this proposal they treated Keccak as a sponge function, where the output n may be any length (you get a PRNG and masking for free)).
In the CHES presentation, Slide 45 already uses crippled capacities.
You can read in slide 49 that NIST overtook Sakura's padding scheme.

My reaction is a variation of "Stop talking and take my money": Stop discussing this long enough to give me the code. Here it is: Reference and optimized code in C, from the article The Keccak sponge function family.

My reaction is a variation of "Stop talking and take my money": Stop discussing this long enough to give me the code. Here it is: Reference and optimized code in C, from the article The Keccak sponge function family.

In fact it should be a given that SHA-X does not suffer from the same vulnerabilities as SHA-X-1.

No, it shouldn't. Both SHA-1 and SHA-2 are based on the Merkle–Damgard construction. If there's something really wrong with it (not that there's any reason to believe so, today), both SHA-1 and SHA-2 would be affected.

Keccak (SHA-3) has a completely different design based on the sponge construction.

I spent a few hours the other day looking over all of the submissions; Keccak and Skein are my favorite contributions. My criteria was "does the hash generate a fixed-length output, or is the hash capable of also being used as a stream cipher".

There are only four unbroken contributions that can generate arbitrarily long streams of numbers: Keccak, LUX, MeshHash, and Skein. Of these contributions, LUX and MeshHash, while not broken, already have cryptanalysis done against them that make me a little uneasy using them.

I prefer Keccak over Skein, for the simple reason there is a bonda-fide 32-bit variant of Keccak that can run quickly on 32-bit systems. Skein is designed to run well only on 64-bit systems. Part 5.4 of the Skein paper talks about the possibility of making a 32-bit variant of Skein but that they need to come up with rotation and permutation constants, and figure out how many rounds a 32-bit Skein variant would need. I would like to see Schneier, et al (the team responsible for Skein) actually do this. Skein is more flexible that Keccak (I think threefish is the first tweakable block cipher since the somewhat broken Hasty Pudding Cipher), and is faster on 64-bit systems, but I would like to see it run on embedded and legacy systems better.

I'm no crypto guru, but I have read Schneier's Applied Cryptography and have read various papers describing cryptographic primitives. Looking at the blog entry (yes, I do read Slashdot for its articles), the paper hasn't been published yet. We don't know, at this point, whether this is a theoretical attack or a practical attack.

It doesn't affect AES; it may or may not affect RC4, which is pretty widely used. What it appears to affect is Radio Gatun, a nice, fairly new construction that can either be a hash or stream cipher, taking a key of any length. Radio Gatun is nice because its core can fit in under 2k of memory and it's an elegant, extensible construction.

However, scanning the paper describing the function, I note the quote "It has algebraic degree 2" on page 10. So it looks like a nice, small elegant cryptographic primitive has fallen.