Re: [Cfrg] draft-atkins-suit-cose-walnutdsa on the Independent Stream

Derek Atkins <> Wed, 29 January 2020 02:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FA831200B3 for <>; Tue, 28 Jan 2020 18:49:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZYybozWD90FZ for <>; Tue, 28 Jan 2020 18:49:54 -0800 (PST)
Received: from (MAIL2.IHTFP.ORG []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39838120122 for <>; Tue, 28 Jan 2020 18:49:54 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E8EEE2042; Tue, 28 Jan 2020 21:49:43 -0500 (EST)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 21637-04; Tue, 28 Jan 2020 21:49:37 -0500 (EST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "IHTFP Consulting Certification Authority" (not verified)) by (Postfix) with ESMTPS id 1FCEEE2040; Tue, 28 Jan 2020 21:49:37 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1580266177; bh=+roFVTNIBv50VI6EexUSEqFQAz7aBik7i3FhBs70Lo0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=VH3ybNvB7IsAnMxx9eR3m1qFuMnnXsp3drhkQ3uocTF/0IgIGll9LdCF/3fJtlLPQ LK2nw0WUrKZZOnXm4AkZn2hzlaUyvZVbthLnUqhwJkQ7Klbutzj67BS1paxZA3gMci FVW3T6Zi5DkN7A4rJB9+crquwFckpDOLErP5t+BI=
Received: (from warlord@localhost) by (8.15.2/8.15.2/Submit) id 00T2nVtT025030; Tue, 28 Jan 2020 21:49:31 -0500
From: Derek Atkins <>
To: "RFC ISE (Adrian Farrel)" <>
References: <>
Date: Tue, 28 Jan 2020 21:49:29 -0500
In-Reply-To: <> (RFC ISE's message of "Sun, 19 Jan 2020 13:55:02 -0800")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <>
Subject: Re: [Cfrg] draft-atkins-suit-cose-walnutdsa on the Independent Stream
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: Wed, 29 Jan 2020 02:49:58 -0000

Dear All,

I want to apologize for the delay in sending this response; I was traveling out of the country all of last week.

I want to reply to Kenny’s points by saying that section 5.2 of the draft deals specifically with all the analysis that occurred before, during, and since the NIST Round 1 process.  What Kenny is pointing out is old news, and it’s quite clear how to choose parameters today taking in to consideration everything that Kenny raises. Yes, the parameters chosen in 2017 were too small.  But the summary of in section 5.2 shows that each attack is exponential in parameters N and q, and amusingly they are all exponential to approximately the same degree, O(q^((N-1)/2)).  So contrary to what Kenny has said, choosing parameters today is straightforward.  Please see that paper and section 5.2 for more details.

WalnutDSA was not accepted into Round 2 and after meeting with NIST, it was explained there were a host of reasons, many unrelated to the analysis in Round 1. NIST had to make cuts somewhere, and we know they will make more cuts going into Round 3 as many valid methods may not meet the additional criteria NIST may choose to apply.  Based on recent analysis of NewHope going into Round 3, would that change how you feel about it?

This draft is an informational draft, not a standard.  More specifically, it’s a document about how one would use WalnutDSA within COSE, and not about WalnutDSA specifically.  Moreso, it specifically says that WalnutDSA is “not recommended” in the IANA considerations section.  The goal of this draft is to ensure that implementers can write interoperable code that can at least parse the COSE objects in a consistent way.  It says nothing about whether you should trust it as a result of this process, let alone use it.

While I am not asking CFRG to bless WalnutDSA, I am asking it to allow the ISE to publish our request under the guidelines and mandate it has for addressing informational drafts – nothing more and nothing less.


PS: Apologies to those who get this twice; the CFRG list bounced back my original message sent from my work address.

       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant