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