Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt

Basil Dolmatov <dol@cryptocom.ru> Wed, 05 January 2011 18:50 UTC

Return-Path: <dol@cryptocom.ru>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E893A6C40 for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 10:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.129
X-Spam-Level:
X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPerkJvIsafX for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 10:50:36 -0800 (PST)
Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id B6FCF3A6BE9 for <dnsext@ietf.org>; Wed, 5 Jan 2011 10:50:36 -0800 (PST)
Received: from [192.168.63.201] (unknown [91.79.139.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id DA58946451 for <dnsext@ietf.org>; Wed, 5 Jan 2011 21:52:41 +0300 (MSK)
Message-ID: <4D24BDF9.4020406@cryptocom.ru>
Date: Wed, 05 Jan 2011 21:52:41 +0300
From: Basil Dolmatov <dol@cryptocom.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: dnsext@ietf.org
References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <a06240801c94a3ed54f9e@[10.31.200.116]> <4D24ADA3.20305@vpnc.org>
In-Reply-To: <4D24ADA3.20305@vpnc.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2011 18:50:39 -0000

05.01.2011 20:42, Paul Hoffman пишет:
>
> > The obvious reason for implementor to require something is to ensure
> > that all elements in this chain are equally reliable. Unfortunately,
> > "bits of strength" are not the obvious characteristics of reliability
> > which are good for comparison in all cases.
>
> We disagree here. I understand that, given the tight limitations of 
> GOST, that might be true in your market. However, in a future world 
> where there are multiple hash algorithms (thinking ahead to SHA-3), 
> some of which will have the same effective strengths, effective 
> strength is a reasonable measurement.
>
> > So, the demand of equality of some bits figures looks somewhat 
> artificial.
>
> In the GOST world, yes; in the less-restricted space of open 
> standards, no.
I did not make any GOST references, moreover I did not imply any GOST 
peculiarities in my comment, it is true for _any_ algorithm (the fact 
that GOST belongs to "space of open standards" too is worth mentioning, 
but irrelevant).

In any space of cryptographic standards the strength of algorithm is 
measured not by "bits of strength" or "bits of key or hash length" but 
by the number of operations which should be performed for given attack.
If one bothers to compare the algorithm strength more accurately then 
the product of (operations)*(memory required) is used.

Other figures have mostly marketing meaning rather than technical one.

dol@