Hi Joan, On Sun, 22 Jul 2018, Joan Daemen wrote: > I wanted to react to some statements I read in this discussion. But > first let me introduce myself. I'm Joan Daemen and I'm working in > symmetric cryptography since 1988. Vincent Rijmen and I designed > Rijndael that was selected to become AES and Guido Bertoni, Michael > Peeters and Gilles Van Assche and I (the Keccak team, later extended > with Ronny Van Keer) designed Keccak that was selected to become SHA3. > Of course as a member of the Keccak team I'm biased in this discussion > but I'll try to keep it factual. Thank you *so* much for giving your valuable time and expertise on this subject. I really would hate for the decision to be made due to opinions of people who are overconfident in their abilities to judge cryptographic matters despite clearly being out of their league (which includes me, I want to add specifically). On a personal note: back in the day, I have been following the Keccak with a lot of interest, being intrigued by the deliberate deviation from the standard primitives, and I am pretty much giddy about the fact that I am talking to you right now. > [... interesting, and thorough background information ...] > > Anyway, these numbers support the opinion that the safety margins taken > in K12 are better understood than those in SHA-256, SHA-512 and BLAKE2. This is very, very useful information in my mind. > Adam Langley continues: > > Thus I think the question is primarily concerned with performance and implementation availability > > > Table 2 in our ACNS paper on K12 (available at > https://eprint.iacr.org/2016/770) shows that performance of K12 is quite > competitive. Moreover, there is a lot of code available under CC0 > license in the Keccak Code Package on github > https://github.com/gvanas/KeccakCodePackage. If there is shortage of > code for some platforms in the short term, we will be happy to work on that. > > In the long term, it is likely that the relative advantage of K12 will > increase as it has more potential for hardware acceleration, e.g., by > instruction set extension. This is thanks to the fact that it does not > use addition, as opposed to so-called addition-xor-rotation (ARX) > designs such as the SHA-2 and BLAKE2 families. This is already > illustrated in our Table 2 I referred to above, in the transition from > Skylake to SkylakeX. I *really* hope that more accessible hardware acceleration for this materializes at some stage. And by "more accessible", I mean commodity hardware such as ARM or AMD/Intel processors: big hosters could relatively easily develop appropriate FPGAs (we already do this for AI, after all). > Maybe also interesting for this discussion are the two notes we (Keccak > team) wrote on our choice to not go for ARX and the one on "open source > crypto" at https://keccak.team/2017/not_arx.html and > https://keccak.team/2017/open_source_crypto.html respectively. I had read those posts when they came out, and still find them insightful. Hopefully other readers of this mailing list will spend the time to read them, too. Again, thank you so much for a well-timed dose of domain expertise in this thread. Ciao, Dscho
