View source for Talk:The SHA-3 Zoo

I'm thinking about introducing another column to the list of submissions to provide a rough, overall classification of the candidates (e.g. classical Merkle-Damgaard vs. HAIFA vs. sponge vs. tree-based vs. streaming vs. ...), motivated by private messages I've got comparing the current SHA-3 Zoo with my old hash lounge.

However, finding the most appropriate category for some submissions may be a tough task; paradigms may be so distorted as to be nearly unrecognizable. Still, other candidates exhibit a much more transparent structure, and I think this information may be useful (e.g. comparing submissions that fall on distinct categories may not be as fair as comparing functions that share a high-level structure).

Would such a modification be welcome to the SHA-3 Zoo contributors?

Paulo.

I think this would be a lot of effort for a relatively minor added value; as you observe, many candidates are likely to use "uncategorizable" modes of operations. How one would classify CubeHash? It has similarities with a sponge constructions, but is not a sponge in general. Also, both MD6 and ESSENCE have a tree construction, but with different arities, parameters, etc. Finding the best tradeoff precision/readability seems difficult...

JP

Well, I don't see it as too much effort -- for <i>me</i> at any rate; I'm not asking that somebody else do the hard work &#9786;. Rather, I think it's part of trying to understand how each submission works, and it could also suggest lines of attack (particularly where the actual functions deviate from previously analyzed constructions). Besides, in cases where the authors disagree of a tentative category it might shed new light on those authors' original intent.

Paulo.

Addendum: as far as I could tell, the overall structure of the currently known proposals <b>seems</b> to be the following (disclaimer: I may be completely mistaken in many cases):<br>

{| border="1" cellpadding="4" cellspacing="0" align="center" class="wikitable"
|- style="background:#efefef;"
! width="150"| Hash Function Name      !! width="150"| Status    !!  width="150"| [[External Cryptanalysis Categories| External Cryptanalysis]]!! width="150"| Tentative Classification
|-
| [[BLAKE]]                            || submitted || none   || HAIFA/?
|-
| [[Blue Midnight Wish]]               || submitted || none   || sponge
|-
| [[Boole]]                            || submitted || yes    || streaming
|-
| [[CHI]]                              || submitted || none   || Merkle-Damgaard/Davies-Meyer
|-
| [[CRUNCH]]                           || submitted || none   || sponge?
|-
| [[CubeHash]]                         || submitted || yes    || sponge
|-
| [[Edon-R (SHA-3 submission)|Edon-R]] || submitted || yes    || sponge?
|-
| [[EnRUPT]]                           || submitted || broken || streaming
|-
| [[ESSENCE]]                          || submitted || none   || Merkle tree
|-
| [[FSB (SHA-3 submission) | FSB]]     || submitted || none   || sponge?
|-
| [[Fugue]]                            || submitted || none   || sponge?
|-
| [[Groestl|Grøstl]]                   || submitted || none   || sponge
|-
| [[HASH 2X]]                          || submitted || broken || streaming?
|-
| [[Keccak]]                           || submitted || none   || sponge
|-
| [[Maraca]]                           || submitted || none   || sponge?
|-
| [[MCSSHA-3]]                         || submitted || broken || streaming
|-
| [[MD6]]                              || submitted || yes    || Merkle tree
|-
| [[NaSHA]]                            || submitted || none   || sponge?
|-
| [[NKS2D]]                            || submitted || broken || cellular automaton
|-
| [[Ponic]]                            || submitted || none   || streaming
|-
| [[Sarmal]]                           || submitted || none   || HAIFA/Davies-Meyer
|-
| [[Sgàil]]                            || submitted || broken || Merkle-Damgaard/Davies-Meyer
|-
| [[SHAMATA]]                          || submitted || none   || sponge
|-
| [[Skein]]                            || submitted || none   || Merkle-Damgaard/UBI?
|-
| [[Spectral Hash]]                    || submitted || yes    || Merkle-Damgaard/prism?
|-
| [[Vortex (SHA-3 submission)|Vortex]] || submitted || yes    || Merkle-Damgaard/Vortex-block?
|-
| [[WaMM]]                             || submitted || broken || sponge
|-
| [[Waterfall]]                        || submitted || none   || streaming
|}





I'm in favour of adding more infos to this page. Seems like a good first shot. But surely we have to put a disclaimer to this category saying something like "this column can never we entirely correct as we would need almost 64 categories...". 

Regarding your current categorization. Why not distinguish designs that are based on a small number of permutations from designs based on a huge number of permutations (e.g. block-cipher based). This seems a crucial difference to me. 
On the other hand, do we really want to distinguish HAIFA from Merkle-Damgaard? The former is an extension of the later. 
Also, what is your way to distinguish between sponge and streaming?

-Christian

Oh, I'm definitely thinking about adding a disclaimer. Regarding HAIFA vs. MD, I wrote HAIFA when the authors explicitly state so in the documentation. I tend to call "sponge" a construction that inserts a message in "blocks" (related to the abstract design) in a "simple" way (e.g. via some block-oriented group operation), and "stream" a construction oriented toward "words" (related to popular target platforms) mixed into the state through a "complicated" operation (I admit this is rather informal to say the least); also, I again adhere to the authors' statement when they claim a design is streaming. As for permutations vs. block ciphers, I've been thinking about this... but perhaps it's better to discuss the subject privately before, so I can check my own understanding of a few concepts. And of course I'm entirely open to revising a classification if there is evidence of a mistaken prior assessment.

Paulo.

We can follow Orr and say that "everything is HAIFA" ;)

More seriously: more info would of course be valuable, but accurate information seems in this case difficult (and maybe impossible) to provide. All the functions are based on the compression function (whatever the designers say to sound original), then the variations are: how the iteration is performed? (linear or tree), how large is the state?, how many rounds are recommended and how many are broken? (it would be interesting to give this ratio, but often there's more than the "round" parameter, see eg CubeHash), are there additional inputs? (salt, key, counter, etc.). 

The iteration mode seems to be linear in most of the submissions, so providing this info may not be that useful. However it could be interesting and easy to add a column "state bitsize". If we want to say how many rounds are broken, we'll reduce to the same problem as we have with the "external cryptanalysis" column with "what is broken". 

JP