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