Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01

Dan Brown <> Mon, 24 February 2020 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E45F3A0EAF for <>; Mon, 24 Feb 2020 11:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jlo9gXgW__DH for <>; Mon, 24 Feb 2020 11:42:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 520313A0E2A for <>; Mon, 24 Feb 2020 11:42:29 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 01OJbaec186949; Mon, 24 Feb 2020 14:42:27 -0500
Received: from ( []) by with ESMTP id 2yb0ea4yfn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 24 Feb 2020 14:42:26 -0500
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Mon, 24 Feb 2020 14:42:26 -0500
Received: from ([fe80::ac8d:3541:704c:478a]) by ([fe80::ac8d:3541:704c:478a%5]) with mapi id 15.01.1847.003; Mon, 24 Feb 2020 14:42:26 -0500
From: Dan Brown <>
To: Alexey Melnikov <>, "" <>
Thread-Topic: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01
Thread-Index: AQHV5LqSzhDV77G67kCVyHUzr9DmiagqxE8Q
Date: Mon, 24 Feb 2020 19:42:26 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840."; boundary="----=_NextPart_000_002F_01D5EB20.A1002600"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002240143
Archived-At: <>
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-kangarootwelve-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Feb 2020 19:42:32 -0000

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.






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



From: Cfrg <> On Behalf Of Alexey Melnikov
Sent: Sunday, February 16, 2020 6:16 AM
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 ( <> ). 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.