Re: [Cfrg] Elliptic Curves - poll on security levels (ends on February 17th)

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 10 February 2015 22:49 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E871A8741 for <cfrg@ietfa.amsl.com>; Tue, 10 Feb 2015 14:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.1
X-Spam-Level: *
X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] autolearn=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 FQnJ5OIoeqtx for <cfrg@ietfa.amsl.com>; Tue, 10 Feb 2015 14:49:49 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 773311A1A2D for <cfrg@irtf.org>; Tue, 10 Feb 2015 14:49:49 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 309EDF984; Tue, 10 Feb 2015 17:49:45 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id CEFF01FFE5; Tue, 10 Feb 2015 17:49:44 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Станислав Смышляев <smyshsv@gmail.com>
In-Reply-To: <0A06BF6D-004F-4B36-960D-FB96B20223D2@gmail.com>
References: <CAMr0u6=L0g1Edg3Q+2baab1LHo2xc7G1qDeok0PJG_tZ5OXATg@mail.gmail.com> <87siedslqq.fsf@alice.fifthhorseman.net> <0A06BF6D-004F-4B36-960D-FB96B20223D2@gmail.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Tue, 10 Feb 2015 17:49:44 -0500
Message-ID: <87lhk5qt4n.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/p_WDDi-kPr9YkSuKVibdE1dNuBk>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Elliptic Curves - poll on security levels (ends on February 17th)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2015 22:49:51 -0000

On Tue 2015-02-10 14:15:09 -0500, Станислав Смышляев wrote:

> the Russian digital signature standard strictly requires that the
> order of the prime subgroup of a curve either lies between 2^(254) and
> 2^(256) or lies between 2^(508) and 2^(512) - and one won't generate a
> curve with a cofactor of 512 (=2^(521-512)).

This feels a bit like begging the question to me: without more
explanation, saying the "Russian digital signature standard strictly
requires" still seems arbitrary.  Does the Russian digital signature
standard provide an explicit rationale for the upper bound?

Maybe more detail would be useful:

Will there be systems unable to adopt new recommended curves at that
security level because of a larger group?  how many?  what sorts of
systems?  Which Russian digital signature standard exactly?  Can you
provide a pointer so that people unfamiliar with it can see what the
constraints are themselves?

How much will the Russian Digital Signature standard need to be updated
to allow the use of any new curves?  If it needs to be updated anyway,
could it be also updated to allow 521-bit curves if we manage to get a
rough consensus from other participants?

By comparison, the NIST folks (from the US gov't) seem open to
considering new curves in the near future.  Is that flexibility
something that the agency governing the standards in question can also
provide?

I think we can take your concerns into better consideration (and we can
make better decisions as a group) the more details we know about these
constraints.

        --dkg