Re: [Cfrg] 512-bit twisted Edwards curve and curve generation methods in Russian standardization

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Thu, 29 January 2015 08:08 UTC

Return-Path: <smyshsv@gmail.com>
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 BA0121A8F4F for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 00:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 frFf9pPRuOIa for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 00:08:30 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDA71A8F4D for <cfrg@irtf.org>; Thu, 29 Jan 2015 00:08:30 -0800 (PST)
Received: by mail-oi0-f49.google.com with SMTP id a3so24235396oib.8 for <cfrg@irtf.org>; Thu, 29 Jan 2015 00:08:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y/YsfFFEY3INo6X3p5b8dv/yZOY2w1uooxgxAiuoShk=; b=SeAtMAO14HsKA9SBzgO4drDK/eLgvtsfh6GUyULeb0+zbNMsjx5m531K+p7MqFO6xp AViShwfwHbnb0wMC0mC4kVePuUpxoMUgp7hCbXuhM3shjJxz9JtqG3Cc5wxaE3GQ9soE HOEUOnptFYNsiVyeOzIwhieEBLGyjY/L1sQ7yAj53sF86p77Q2t6N1yNuKIpSPVoKH6N blhhyD7Gy2s9YhSwBkxedXRULkK2vklrFMUVnWqrXI0ino7GgB7xr46pF/qnQYfBKJLq yYIXx939dQ9u9iyDlwl1BdJV3IgZKhT257Bk9Fjb6JkR7GAJ0oNzeXEsIufzBlmpL6bP dteQ==
MIME-Version: 1.0
X-Received: by 10.202.212.66 with SMTP id l63mr4401224oig.117.1422518909757; Thu, 29 Jan 2015 00:08:29 -0800 (PST)
Received: by 10.182.5.103 with HTTP; Thu, 29 Jan 2015 00:08:29 -0800 (PST)
In-Reply-To: <54C924AC.7060504@akr.io>
References: <CAMr0u6=prmjMv7e+S5UAGVw+uCQWPk-f86Koa04GVx8CZs4J4Q@mail.gmail.com> <C877C13D-0178-4BDD-BC58-4E7C417600D1@akr.io> <CAMr0u6=pgV8P19zoEbztCas20XX68V40wN-3qwrbqAxQeMpJQg@mail.gmail.com> <54C924AC.7060504@akr.io>
Date: Thu, 29 Jan 2015 12:08:29 +0400
Message-ID: <CAMr0u6kC_DpZo8LVtp1Ljmqzvcz1wtB_yhajEW3-bZ7mbqBbyA@mail.gmail.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
To: Alyssa Rowan <akr@akr.io>
Content-Type: multipart/alternative; boundary=001a113cf2884d6d3d050dc5feab
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/PDyblgC_34KFWhqxd86P7R34cxk>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] 512-bit twisted Edwards curve and curve generation methods in Russian standardization
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: Thu, 29 Jan 2015 08:08:34 -0000

I totally understand that a property that occurs with 2^{-18} (as Bernstein
did with BADA55 curves) can be forced to exist in the selected curve. The
example that I posted earlier is the specific curve that is standardized in
Russia, by a group of experts where the condition mentioned by Paul ("a
group where even if a single person is trusted") is satisfied ("trusted"
for us, not for the international community and CFRG, I suppose).

When we generated our curves and fixed base points, the main problem that
we addressed was to ensure that for all protocols that make use of elliptic
curves and require "provably unknown" logarithms of some points (for
example, password protected key establishment, PAKE, EKE, PACE, etc.) can
obtain such a property: x-coordinates of base points and constant points
for prototocols are chosen by hashing some random seeds – we don't want
only a blind belief of randomness of such points (the most painful example
here is Dual EC DRBG, of course). We look at curve generation problem in a
similar way: we cannot be secure against the unknown bad properties of
curves that occur with probability of 2^{-18} – even if the procedure is
totally "rigid". But at least we can be sure that if some bad property of
our curves is found, we would know that this couldn't be a "backdoor" that
can be exploited only by developers of the curve, who know some logarithms,
preimages etc. (again, as with DUAL EC DRBG).

If to talk about new curves for CFRG document, the usage of deterministic
("rigid") procedure is quite reasonable, we agree here. We've posted our
curve because we think that it can be interesting for CFRG to look at one
of the curves that have been standardized for all Russian cryptographic
community. We'll post some specific comments to the current draft later
today.

​Best regards,
Stanislav V. Smyshlyaev, Ph.D.,
Head of Information Security Department,
CryptoPro LLC