RE: Comments on ECC draft

"Dominikus Scherkl" <> Thu, 06 September 2001 10:30 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id GAA19115 for <>; Thu, 6 Sep 2001 06:30:21 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by (8.11.6/8.11.3) id f86A8B015154 for ietf-openpgp-bks; Thu, 6 Sep 2001 03:08:11 -0700 (PDT)
Received: from ([]) by (8.11.6/8.11.3) with ESMTP id f86A8AD15150 for <>; Thu, 6 Sep 2001 03:08:10 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(5.0.2195.2966); Thu, 6 Sep 2001 12:07:54 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: Comments on ECC draft
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Thu, 6 Sep 2001 12:07:53 +0200
Message-ID: <>
Thread-Topic: Comments on ECC draft
Thread-Index: AcE2c0aNs1DEE9/xQwKDT5DCo/DqbgAQ4KuA
From: "Dominikus Scherkl" <>
To: <>
Cc: <>
X-OriginalArrivalTime: 06 Sep 2001 10:07:54.0024 (UTC) FILETIME=[CB462280:01C136BB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by id f86A8BD15151
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 8bit



> We have been looking at the ECC issue and have a few comments on the
> proposed draft by Dominikus Scherkl and Christoph Fausak.
Thank you for your comments.

> As efficiency is much of the motivation for going to EC
> technology, we should try to preserve it.
There are fields providing much better performance than even
binary fields do (see below).

> As candidates for the specific fields to use, we recommend
> the selections from NIST [fips186-2], used as ECC groups in IKE
> [draft-ietf-ipsec-ike-ecc-groups-03]. These fields are being deployed
> and are in use in some environments. They provide for efficient
> implementations.
The named curves mentioned in section 9 are exactly these (and a few
more), even using the same names. But as I heared, it's some of
these which patents are claimed for (especialy the Kobliz curves) :-(

> The last point we would like to make is about the field representation
> format (section 4.4 in the draft), where again we would propose
> to reduce the number of options in order to improve interoperability.
> 16 options is too many.
All the parameters are only nessessary for user defined curves.
And they provide an efficient storage format for the named curves,
too (but that's an implementation detail).
If we rely only on the named curves, we don't need them ever.

> If the group does want to pursue additional field types, we would like
> to see some rationale for the use of prime extension field types 4-9.
Especialy the field F(2^31-1)[x]/(x^7-7) [in my own description: D = 4,
r = 31, c = 1, m = 7, w = 7] whose elements can be represented as serven
32bit words provide extremely fast arithmetics (an arbitrary field
multiplication requires only about 6 machine multiplications - on
32bit machines of course) with over all security of 206 bit.
(binary fields of equal length requires about 1400 additions)
I'd add some courves over this field soon.

> we do not think it is possible to convert from a normal basis
> into a polynomial basis representation without additional information
That is not true. You can use an arbitrary root (which can be
calculated efficiently) to convert to some polynomial basis - but
you need to reconvert any result to the normal basis, before using it.
In Fact, this conversion also takes time, so normal bases are not
that fast, I agree.

> (One organizational point: section 4.4 actually describes custom
> and we would prefer to see the draft focus on predefined curves.

I think it's easy to leave out some parts of my draft, although it's
the better way to have covered all as to have only some parts and need
to make something completey different if we encounter patented pars. ;-)

best regards.
- -- 
Dominikus Scherkl
Biodata Application Security AG

Version: Biodata SecureDesk OpenPGP CryptoEngine Version 2.1
Comment: Biodata SecureDesk -