From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, T_DKIM_INVALID shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 86AD31F517 for ; Tue, 12 Jun 2018 16:29:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934437AbeFLQ3D (ORCPT ); Tue, 12 Jun 2018 12:29:03 -0400 Received: from ober.noekeon.org ([91.134.133.203]:46489 "EHLO ober.noekeon.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933378AbeFLQ3C (ORCPT ); Tue, 12 Jun 2018 12:29:02 -0400 X-Greylist: delayed 512 seconds by postgrey-1.27 at vger.kernel.org; Tue, 12 Jun 2018 12:29:02 EDT Received: from [127.0.0.1] (ober.noekeon.org [91.134.133.203]) by ober.noekeon.org (Postfix) with ESMTPSA id D80FA22223; Tue, 12 Jun 2018 18:20:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=noekeon.org; s=mail; t=1528820424; bh=l+AUcK6igXT4WWrVFwiORGFzjJ5hdtrkl5ZYxkXxjS8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gJs7C0UsSmV0BDUAReRsSbIbdqW6p6O0+4PuQdVqx+wacuSOGMM+S6ax5ladrcz3A 62e2ONAHAeJtOXYMaryxsH0LhUS06M9LZzLkDEC2Min5obIgmF+ow6TspRZq6zSBeO y3fQ/ZW0LiZF+ATcs1LgybPtTPvJsB0hwiLh7H7o= Subject: Re: Hash algorithm analysis To: "brian m. carlson" References: <20180609205628.GB38834@genre.crustytoothpaste.net> <20180609224913.GC38834@genre.crustytoothpaste.net> <20180611192942.GC20665@aiede.svl.corp.google.com> <20180611223520.GF38834@genre.crustytoothpaste.net> Cc: Jonathan Nieder , git@vger.kernel.org, Johannes Schindelin , demerphq , Linus Torvalds , Adam Langley , Keccak Team From: Gilles Van Assche Message-ID: <8e3fa1dd-958c-c3d5-2d6e-d52a4b424982@noekeon.org> Date: Tue, 12 Jun 2018 18:21:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180611223520.GF38834@genre.crustytoothpaste.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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