Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01
Gilles Van Assche <gilles.vanassche@st.com> Tue, 25 February 2020 15:10 UTC
Return-Path: <gilles.vanassche@st.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87613A0BA4 for <cfrg@ietfa.amsl.com>; Tue, 25 Feb 2020 07:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=st.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaXK2f8QH6M4 for <cfrg@ietfa.amsl.com>; Tue, 25 Feb 2020 07:10:27 -0800 (PST)
Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [62.209.51.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF9F3A0BCD for <cfrg@irtf.org>; Tue, 25 Feb 2020 07:10:27 -0800 (PST)
Received: from pps.filterd (m0046037.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01PF8eF9024616; Tue, 25 Feb 2020 16:10:23 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=STMicroelectronics; bh=FAzQzltQThVZbvQak7XkPxMW+1s/v5HZD8GxbXL06Xc=; b=LZtW2zM3btjGYbwhns/waR68F2sOc6jwmKWhHelPTVGMoZsZElNX2XNafd+fgoJNMB9B 1a7MyJ3OFYgNZDnsm46RkLsgPe9S0SZm2drHCRQ/dhF7ml7CkEKfHZQw41sjOFmWFRj+ 2HpENrgqnOTAHhQFqkdZ2eZwKE7Jrvi1XXG3J2fG8BVWicDqbhFyojDYyyCblnS5pppQ hj7/0pPrMJtyt2+LyDRbEWI0AwWXAJEsjGCxpx8oUMR2Hio9SkLW7My3g81qsNsV+4+c vDJmmpO9VBFw+P92kDFcR/CMH6YmQODf2yOraDse+8OMaW2ak22r2LI/VpcRFe7nIfHl sg==
Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 2yaty1gdxt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 16:10:23 +0100
Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E560210002A; Tue, 25 Feb 2020 16:10:22 +0100 (CET)
Received: from Webmail-eu.st.com (sfhdag6node2.st.com [10.75.127.17]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id C64842BC7A2; Tue, 25 Feb 2020 16:10:22 +0100 (CET)
Received: from [10.137.3.119] (10.75.127.44) by SFHDAG6NODE2.st.com (10.75.127.17) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 25 Feb 2020 16:10:21 +0100
To: Dan Brown <danibrown@blackberry.com>, Alexey Melnikov <alexey.melnikov@isode.com>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <DF952AED-7578-47B8-B42F-F6A18A927C31@isode.com> <f5fd0c43578847e9b0ba01171447ba47@blackberry.com>
From: Gilles Van Assche <gilles.vanassche@st.com>
Message-ID: <c7fbb8d6-f42a-c9e1-3047-b9cfc11cff79@st.com>
Date: Tue, 25 Feb 2020 16:11:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <f5fd0c43578847e9b0ba01171447ba47@blackberry.com>
Content-Type: multipart/alternative; boundary="------------2AAAFFCB730535BDCBFDDEAE"
Content-Language: en-US
X-Originating-IP: [10.75.127.44]
X-ClientProxiedBy: SFHDAG7NODE1.st.com (10.75.127.19) To SFHDAG6NODE2.st.com (10.75.127.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-25_05:2020-02-21, 2020-02-25 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/6xFUigfysvJQfB1YidbAQlhvB0Q>
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2020 15:10:32 -0000
Dear Dan, Thanks for your comments and questions. About your first question, NIST LWC is about having algorithms that fit in a very constrained environment. The candidates of the NIST LWC likely are much slower than K12 on a general purpose processor. So we don't think there is overlap there. About your last two questions, we simply think that K12 is a solution that can benefit to many users. Probably that there are not many use-cases that, say, SHA-256 cannot handle, but K12 is more optimal in a number of ways. Specifically, K12 is the only hash function that is at the same time not broken *and* very fast in software *and* directly based on such a long record of third-party cryptanalysis. (Other arguments can be found in Benoît's slides https://benoit.viguier.nl/files/K12atMontreal.pdf .) Kind regards, Gilles, for the K12 authors On 2/24/20 8:42 PM, Dan Brown wrote: > > I have not studied this draft, so I do not oppose it, but I am quite > puzzled by the motivation. > > > > It may be too late now to ask for explanations that would unpuzzle > (only) me: they were probably discussed during the call for adoption. > If so, please disregard the rest of the message. > > > > *** > > > > Background: > > > > My understanding, which I expect is simplistic, is that this (K12) is > a fast variable length hash (XOF) which uses fewer rounds than the > existing NIST XOF (or similar constructs). > > > > For sake of argument, let us assume K12 is secure, and it has merit of > being faster than some alternatives, especially NIST XOF. > > > > General questions, with some details: > > > > 1. CFRG or NIST? > > > > Isn’t NIST also running a lightweight crypto (LWC) project? Are some > algorithms there even faster than Kangaroo12? > > > > But CFRG decided to wait for NIST PQC, so why would CFRG try to race > with NIST LWC? > > > > I could guess that an answer is that NIST PQC is a matter of security, > but NIST LWC is a matter of efficiency, so is more fair game for > CFRG? But maybe there’s a better answer. > > > > 2. Too many solutions to the same problem? > > > > The more options in a system, meaning solutions to a problem, in this > case, variable-length hashing, has some downsides, such as adversaries > negotiating the weakest option. > > > > There are mitigation (secure negotiation), and upsides: agility > (reacting to attacks) and compounds (defense in depth). > > > > Perhaps, this draft or the CFRG should address this larger issue. > > > > 3. Is this a solution looking for a problem? > > > > Sorry to use the bad cliché above, but is there a real world use case > where K12 works, but the alternatives do not? Or is it just a generic > strategy to choose optimal efficiency for a given security? > > > > Dan Brown > > BlackBerry > > > > *From:* Cfrg <cfrg-bounces@irtf.org> *On Behalf Of *Alexey Melnikov > *Sent:* Sunday, February 16, 2020 6:16 AM > *To:* cfrg@irtf.org > *Subject:* [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01 > > > > Dear CFRG participants, > > This message is starting 2 weeks RGLC on > draft-irtf-cfrg-kangarootwelve-01 ("KangarooTwelve"), that will end on > March 1st 2020. If you've read the document and think that it is ready > (or not ready) for publication as an RFC, please send a message in > reply to this email or directly to CFRG chairs (cfrg-chairs@ietf.org > <mailto:cfrg-chairs@ietf.org>). If you have detailed comments, these > would also be very helpful at this point. > > > > Thank you, > > Alexey, for CFRG chairs. > > ------------------------------------------------------------------------ > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other > than the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and > delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg
- [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01 Alexey Melnikov
- Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve… Stephen Farrell
- Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve… Benoît Viguier
- Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve… Stephen Farrell
- Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve… Benoît Viguier
- Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve… Stephen Farrell
- Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve… Stanislav V. Smyshlyaev
- Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve… Dan Brown
- Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve… Gilles Van Assche