RE: Comments on ECC draft

["Dominikus Scherkl" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----

Hello.

> 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
curves,
> 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
mail: [e-mail]

-----BEGIN PGP SIGNATURE-----
Version: Biodata SecureDesk OpenPGP CryptoEngine Version 2.1
Comment: Biodata SecureDesk - http://securedesk.biodata.com

wsBcBAEBAQAQBQI7l0r5CRArmDw6wJyywAAAtEcH/jAhv3NkJOf4+F7Q8DG6jvQR
yHfRijvIvHVXlWKR8OuIdGXnMRxI3En0az28Ydr4w3WEHL6i/LPz33BYI7mI0Igy
FiQ1bcuz+Ox9PLNhW4rx9uJ8mXzhjyDIZIrLElGfgntUKA7yrSkcm/NRdsohyb+k
fHFHHEqGMAalziiN2tBu4ltqRJifksFaWZpBF6x3YOQXIZonGshqtcCJKyqA9p7J
AXXKml0cFTUAnHCDupk7j+YEnzprsWylmpMjpUub3PVdofWXHvDHKsldKoRtcIFN
MhGSmrqDp3qAgWTtbapJ51l5yxjge7TQAaioq5TjUIY87DSlNGyq4hinbvFSYj8=
=/8KB
-----END PGP SIGNATURE-----