Dear all, 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. Adam Langley says: I think this group can safely assume that SHA-256, SHA-512, BLAKE2, K12, etc are all secure to the extent that I don't believe that making comparisons between them on that axis is meaningful. If never any cryptographic algorithms would be broken, this would be true. Actually, one can manage the risk by going for cryptographic algorithms with higher security assurance. In symmetric crypto one compares security assurance of cryptographic algorithms by the amount of third-party cryptanalysis, and a good indication of that is the number of peer-reviewed papers published. People tend to believe that the SHA2 functions have received more third-party cryptanalysis than Keccak, but this is not supported by the facts. We recently did a count of number of cryptanalysis papers for different hash functions and found the following: - Keccak: 35 third-party cryptanalysis papers dealing with the permutation underlying Keccak, most of them at venues with peer review (see https://keccak.team/third_party.html) This cryptanalysis carries over to K12 as it is a tree hashing mode built on top of a reduced-round Keccak variant. - SHA-256 and SHA-512 together: we found 21 third-party cryptanalysis papers dealing with the compression functions of SHA-256 or SHA-512. - BLAKE2: the BLAKE2 webpage blake2.net lists 4 third-party cryptanalysis papers. There are also a handful of cryptanalysis papers on its predecessor BLAKE, but these results do not necessarily carry over as the two compression functions in the different BLAKE2 variants are different from the two compression functions in the different BLAKE variants. I was not surprised by the relatively low number of SHA-2 cryptanalysis papers we found as during the SHA-3 competition all cryptanalysts were focusing on SHA-3 candidates and after the competition attention shifted to authenticated encryption. 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. 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. 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. Kind regards, Joan Daemen On 22/07/2018 01:59, brian m. carlson wrote: > On Sun, Jul 22, 2018 at 12:38:41AM +0200, Johannes Schindelin wrote: >> Do you really want to value contributors' opinion more than >> cryptographers'? I mean, that's exactly what got us into this hard-coded >> SHA-1 mess in the first place. > I agree (believe me, of all people, I agree) that hard-coding SHA-1 was > a bad choice in retrospect. But I've solicited contributors' opinions > because the Git Project needs to make a decision *for this project* > about the algorithm we're going to use going forward. > >> And to set the record straight: I do not have a strong preference of the >> hash algorithm. But cryprographers I have the incredible luck to have >> access to, by virtue of being a colleague, did mention their preference. > I don't know your colleagues, and they haven't commented here. One > person that has commented here is Adam Langley. It is my impression > (and anyone is free to correct me if I'm incorrect) that he is indeed a > cryptographer. To quote him[0]: > > I think this group can safely assume that SHA-256, SHA-512, BLAKE2, > K12, etc are all secure to the extent that I don't believe that making > comparisons between them on that axis is meaningful. Thus I think the > question is primarily concerned with performance and implementation > availability. > > […] > > So, overall, none of these choices should obviously be excluded. The > considerations at this point are not cryptographic and the tradeoff > between implementation ease and performance is one that the git > community would have to make. > > I'm aware that cryptographers tend to prefer algorithms that have been > studied longer over ones that have been studied less. They also prefer > algorithms built in the open to ones developed behind closed doors. > > SHA-256 has the benefit that it has been studied for a long time, but it > was also designed in secret by the NSA. SHA3-256 was created with > significant study in the open, but is not as mature. BLAKE2b has been > incorporated into standards like Argon2, but has been weakened slightly > for performance. > > I'm not sure that there's a really obvious choice here. > > I'm at the point where to continue the work that I'm doing, I need to > make a decision. I'm happy to follow the consensus if there is one, but > it does not appear that there is. > > I will admit that I don't love making this decision by myself, because > right now, whatever I pick, somebody is going to be unhappy. I want to > state, unambiguously, that I'm trying to make a decision that is in the > interests of the Git Project, the community, and our users. > > I'm happy to wait a few more days to see if a consensus develops; if so, > I'll follow it. If we haven't come to one by, say, Wednesday, I'll make > a decision and write my patches accordingly. The community is free, as > always, to reject my patches if taking them is not in the interest of > the project. > > [0] https://public-inbox.org/git/CAL9PXLzhPyE+geUdcLmd=pidT5P8eFEBbSgX_dS88knz2q_LSw@xxxxxxxxxxxxxx/
