Dirk Praet September 4, 2013 7:37 PM

Warning: not for the faint at heart, or for those with a limited math and cryptography background.

Nick P September 4, 2013 8:13 PM

I have a limited math and crypto background. There were plenty of slides I didn’t get. That said, there was enough I understood in there for me to say that this is an excellent piece of design and engineering. It’s good in so many ways. Plus, the competition weren’t even in the same ballpark as SHA-3 on ASIC/FPGA performance. That will be important with all the crypto support going into chips. Trusted boot, memory integrity protection, tamper detection and other applications could use a 2-3x performance boost over existing hashes. 🙂

@ Bruce/cryptographers

It said in there that it could be used as a stream cipher. Showed a drawing. It seems like they set it up with some input, then they just iterate the hash and the output of each iteration is what you encrypt a chunk of data with. Am I interpreting it correctly or what am I missing?

People know I love both stream ciphers and reusable, secure components. SHA-3 will be in chips in the near future. I’ve previously used AES-based designs for both encryption and authentication to leverage hardware acceleration of AES. Being able to do that with SHA-3 will totally kick ass.

AC2 September 4, 2013 11:14 PM

IANAC but 2 questions

  • The paper says it can be used with a salt and number of rounds for password hashing. But for a function that is built to be highly performant how many rounds would be needed to force an attacker with an ASIC to spend 1sec per hash. And what would that mean for a regular system to perform those many rounds.

  • The paper also says it can be used for encryption. Not sure how that works… Esp slide 43

A. Thulin September 5, 2013 1:14 AM

Is that really the right slides? Was Kelsey just reading a presentation? All indications are that the authors are the names in the first slide: Bertoni, Daemen , Peeters, Van Assche …

Clive Robinson September 5, 2013 3:24 AM

For all those thinking “stream ciphers” and “block ciphers” and combinations there of, the answer is yes you can use a hash function to make them often quite effectivly (oh and to a lesser extent stream ciphers and block ciphers can be used to make hashes).

The reason is they all reley on “one way” functions to generate the confusion.

So put a counter into a hash, and the output gives you a stream cipher. Put the hash in a Fiestel round and you have a block cipher. In both cases the “key” is XORed with the input to the hash function.

Obviously there are other arangments such as using the hash in a feed back/forward loop to make a stream cipher but there can be dangers in doing this such as ending up with short cycles.

Perseids September 5, 2013 4:11 AM

@Nick P:
Yes. The sponge construction allows them to “squeeze” an arbitrary amount of data out of Keccak. Using it as a hash function you only need 512 bit, but you can also generate a pseudo random stream for use as a stream cipher. Even better, you can do fast authenticated encryption (with associated data) with Keccak (page 43). I hope that will be one of the modes NIST standardizes.

Just Me September 5, 2013 4:11 AM

A bit off topic, but I would be happy if anyone could answer me.

A few years ago I desgined a new symmetric block cipher encryption algorithm. The special features are, that it doesn’t use XOR, block- and key-length is easily variable, it is very fast (from my perspective, but I’m no professional in this) and it would work perfect on smartcards if needed. Maybe there are more advantages I didn’t recognize. As far as I can say, meet in the middle doesn’t work on it.

Is there an institution I could send the functional description, to evaluate it and possibly make it public?

eas September 5, 2013 4:16 AM


Slide 43 is showing how you can use the sponge construction to encrypt and hash a message at the same time. At every stage, a few more bytes are combined into the input function and the same number of bytes is extracted from the output of the function. Running over the length of the message, the output is the encrypted form of the message.

The final two steps are for verification. Their output can be tacked on to an ecrypted message as verification that decryption is done properly.

AC2 September 6, 2013 9:54 AM

Given the latest reveals should we stop trusting NIST and focus on the non winners in the last round?

Skein FTW!

sg September 8, 2013 3:17 PM

I don’t think you linked to the correct slide deck. Which slides did you intent to link to? The slides from his invited talk at CHES? I don’t know whether they are publicly online. But he did send them to all the SHA-3 mailing list subscribers. I guess it’s OK for me to link to them directly via my dropbox. If not, tell me and I’ll remove again.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.