Re: Hash algorithm analysis
On 14/06/18 01:58, brian m. carlson wrote: >>> I imported the optimized 64-bit implementation of KangarooTwelve. >>> The AVX2 implementation was not considered for licensing reasons >>> (it's partially generated from external code, which falls foul of >>> the GPL's "preferred form for modifications" rule). >> >> Indeed part of the AVX2 code in the Keccak code package is an >> extension of the implementation in OpenSSL (written by Andy >> Polyakov). The assembly code is generated by a Perl script, and we >> extended it to fit in the KCP's internal API. >> >> Would it solve this licensing problem if we remap our extensions to >> the Perl script, which would then become "the source"? > > The GPLv2 requires "the preferred form of the work for making > modifications to it". If that form is the Perl script, then yes, that > would be sufficient. If your code is dissimilar enough that editing it > directly is better than editing the Perl script, then it might already > meet the definition. > > I don't do assembly programming, so I don't know what forms one > generally wants for editing assembly. Apparently OpenSSL wants a Perl > script, but that is, I understand, less common. What would you use if > you were going to improve it? The Perl script would be more flexible in case one needs to improve the implementation. It allows one to use meaningful symbolic names for the registers. My colleague Ronny, who did the extension, worked directly with physical register names and considered the output of the Perl script as his source. But this extension could probably be done also at the level of the Perl script. Kind regards, Gilles
Re: Hash algorithm analysis
Hi, On 10/06/18 00:49, brian m. carlson wrote: > I imported the optimized 64-bit implementation of KangarooTwelve. The > AVX2 implementation was not considered for licensing reasons (it's > partially generated from external code, which falls foul of the GPL's > "preferred form for modifications" rule). Indeed part of the AVX2 code in the Keccak code package is an extension of the implementation in OpenSSL (written by Andy Polyakov). The assembly code is generated by a Perl script, and we extended it to fit in the KCP's internal API. Would it solve this licensing problem if we remap our extensions to the Perl script, which would then become "the source"? On 12/06/18 00:35, brian m. carlson wrote: >> My understanding is that all the algorithms we're discussing are >> believed to be approximately equivalent in security. That's a strange >> thing to say when e.g. K12 uses fewer rounds than SHA3 of the same >> permutation, but it is my understanding nonetheless. We don't know >> yet how these hash algorithms will ultimately break. > > With the exception of variations in preimage security, I expect that's > correct. I think implementation availability and performance are the > best candidates for consideration. Note that we recently updated the paper on K12 (accepted at ACNS 2018), with more details on performance and security. https://eprint.iacr.org/2016/770 >> My understanding of the discussion so far: >> >> Keccak team encourages us[1] to consider a variant like K12 instead >> of SHA3. > > While I think K12 is an interesting algorithm, I'm not sure we're > going to get as good of performance out of it as we might want due to > the lack of implementations. Implementation availability is indeed important. The effort to transform an implementation of SHAKE128 into one of K12 is limited due to the reuse of their main components (round function, sponge construction). So the availability of SHA-3/Keccak implementations can benefit that of K12 if there is sufficient interest. E.g., the SHA-3/Keccak instructions in ARMv8.2 can speed up K12 as well. Kind regards, Gilles
Re: RFC v3: Another proposed hash function transition plan
Hi Johannes, Thanks for your feedback. On 19/09/17 00:16, Johannes Schindelin wrote: >>> SHA-256 got much more cryptanalysis than SHA3-256 […]. >> >> I do not think this is true. > > Please read what I said again: SHA-256 got much more cryptanalysis > than SHA3-256. Indeed. What I meant is that SHA3-256 got at least as much cryptanalysis as SHA-256. :-) > I never said that SHA3-256 got little cryptanalysis. Personally, I > think that SHA3-256 got a ton more cryptanalysis than SHA-1, and that > SHA-256 *still* got more cryptanalysis. But my opinion does not count, > really. However, the two experts I pestered with questions over > questions left me with that strong impression, and their opinion does > count. OK, I respect your opinion and that of your two experts. Yet, the "much more" part of your statement, in particular, is something that may require a bit more explanations. Kind regards, Gilles
Re: RFC v3: Another proposed hash function transition plan
Hi Johannes, > SHA-256 got much more cryptanalysis than SHA3-256 […]. I do not think this is true. Keccak/SHA-3 actually got (and is still getting) a lot of cryptanalysis, with papers published at renowned crypto conferences [1]. Keccak/SHA-3 is recognized to have a significant safety margin. E.g., one can cut the number of rounds in half (as in Keyak or KangarooTwelve) and still get a very strong function. I don't think we could say the same for SHA-256 or SHA-512… Kind regards, Gilles, for the Keccak team [1] https://keccak.team/third_party.html
