Re: [Cfrg] ECC mod 8^91+5
Hanno Böck <hanno@hboeck.de> Sat, 21 October 2017 18:03 UTC
Return-Path: <hanno@hboeck.de>
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 980CA1320DC for <cfrg@ietfa.amsl.com>; Sat, 21 Oct 2017 11:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sDRlClYbnqJE for <cfrg@ietfa.amsl.com>; Sat, 21 Oct 2017 11:03:26 -0700 (PDT)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B84A13219B for <cfrg@irtf.org>; Sat, 21 Oct 2017 11:03:26 -0700 (PDT)
Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 21 Oct 2017 20:03:23 +0200 id 0000000000000010.0000000059EB8BEB.00001419
Date: Sat, 21 Oct 2017 20:03:21 +0200
From: Hanno Böck <hanno@hboeck.de>
To: cfrg@irtf.org
Message-ID: <20171021200321.38549d9a@pc1>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501BD8D19@XMB116CNC.rim.net>
References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501BD8D19@XMB116CNC.rim.net>
X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/mndRSyxHiacSSAcv1pN9wYskb8s>
Subject: Re: [Cfrg] ECC mod 8^91+5
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
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: Sat, 21 Oct 2017 18:03:29 -0000
On Mon, 16 Oct 2017 15:08:16 +0000 Dan Brown <danibrown@blackberry.com> wrote: > The main point of this curve is to use it in a system of > multiply-applied diverse crypto, where its security features (special > CM curve, minimal room for trapdoor) could complement those of other > crypto algorithms (including PQC and other ECC algorithms). Using > this variant of ECC as the sole (PK) crypto would be risky (due to > lack of track-record/aegis/scrutiny/etc.). People rarely do multi-crypto these days, and if they do they usually have good reasons. I don't see those reasons here. As we all remember we had a very lengthy discussion about new ECC curves not so long ago. New curves were standardized with what many people consider desirable security properties. As you indicate some people want to combine that with pqc. In this case multi-crypto makes sense, because it can give you something that you can't have in a single algorithm: well-tested crypto and postquantum crypto. But standardizing yet another new ecc method seems a rather obscure threat scenario. You'd assume that you use multiple ECC methods and there's a security flaw that affects all others, but not your new curve. If you feel you want multiple different standardized ECC methods you can already use nist ecc + c25519 in combination. I'm not aware that anyone is doing this. In general I feel it's not desirable to have as many standardized algorithms as possible, as it only complicates algorithm choices. A new algorithm should always have good reasoning for its existence. Therefore I'm against standardizing this unless further arguments are brought up why it's advantageous compared to existing standardized ecc schemes. -- Hanno Böck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
- [Cfrg] ECC mod 8^91+5 Dan Brown
- Re: [Cfrg] ECC mod 8^91+5 David Jacobson
- Re: [Cfrg] ECC mod 8^91+5 Dan Brown
- Re: [Cfrg] ECC mod 8^91+5 Dan Brown
- Re: [Cfrg] ECC mod 8^91+5 Thomas Garcia
- Re: [Cfrg] ECC mod 8^91+5 Ilari Liusvaara
- Re: [Cfrg] ECC mod 8^91+5 Dan Brown
- Re: [Cfrg] ECC mod 8^91+5 Dan Brown
- Re: [Cfrg] ECC mod 8^91+5 Ilari Liusvaara
- Re: [Cfrg] ECC mod 8^91+5 D. J. Bernstein
- Re: [Cfrg] ECC mod 8^91+5 Samuel Neves
- Re: [Cfrg] ECC mod 8^91+5 D. J. Bernstein
- Re: [Cfrg] ECC mod 8^91+5 Dan Brown
- Re: [Cfrg] ECC mod 8^91+5 Dan Brown
- Re: [Cfrg] ECC mod 8^91+5 Paterson, Kenny
- Re: [Cfrg] ECC mod 8^91+5 Hanno Böck
- Re: [Cfrg] ECC mod 8^91+5 Salz, Rich
- Re: [Cfrg] ECC mod 8^91+5 Stephen Farrell
- Re: [Cfrg] ECC mod 8^91+5 Dan Brown