Subject: Elliptic Curve Cryptography in SSH

From: Douglas Stebila <[email-masked]>
Date: Mon, 4 Aug 2003 16:27:08 -0700 (PDT)

Is anyone looking at the use of elliptic curve cryptography in the SSH
protocol?  Specifically at either ECDH for key exchange or ECDSA for
signatures?

-- 

Douglas Stebila
Email: [email-masked]

---

From: Markus Friedl <[email-masked]>
Date: Tue, 5 Aug 2003 09:51:08 +0200

> protocol?  Specifically at either ECDH for key exchange or ECDSA for

not for openssh, since it opens another can of stupid patent problems.

---

From: Nils Larsch <[email-masked]>
Date: Tue, 05 Aug 2003 12:18:57 +0200

> not for openssh, since it opens another can of stupid patent problems.

I don't think that patents are a problem (for ECDSA and ECDH) if only
curves over GF(p), p prime, are used (see for example:
http://grouper.ieee.org/groups/1363/P1363/patents.html). Using
curves over GF(2**m) without some features (point compression,
onb basis etc.) should be possible as well.
Note: Implementing ECDSA and ECDH in OpenSSH shouldn't very difficult
as soon as OpenSSL 0.9.8 is released as OpenSSL 0.9.8 will support
ecdsa and ecdh.

Nils

---

From: Damien Miller <[email-masked]>
Date: Wed, 06 Aug 2003 14:39:47 +1000

> onb basis etc.) should be possible as well.

I was under the (possibly mistaken) impression that avoiding these 
patents eliminated many of the benefits of EC. (Not to mention that 
avoiding patents is a difficult and potentially expensive game.)

> as soon as OpenSSL 0.9.8 is released as OpenSSL 0.9.8 will support

The license that the EC stuff in OpenSSL is released under contains some 
terms that we won't accept. In particular, the patent license:

http://research.sun.com/projects/crypto/FrequenlyAskedQuestions.html

So, like RSA and SRP, another interesting crypto technology is killed 
for ~20 years.

-d

---

From: Nils Larsch <[email-masked]>
Date: Wed, 06 Aug 2003 10:44:34 +0200

Damien Miller wrote:
....
> avoiding patents is a difficult and potentially expensive game.)

As far as I know is this not true if only curve ober GF(p), p prime,
are used. Curves over GF(2^m) are another story as for example the
point compression as defined in X9.62 is afaik patented (or the
use normal bases).

> terms that we won't accept. In particular, the patent license:

Well, the basic GF(p) ec stuff and the ecdsa code were mostly written
by Bodo Moeller and me and are therefore under the standard OpenSSL
license. Sun wrote the ECDH code, but put it under the standard OpenSSL
license.

> http://research.sun.com/projects/crypto/FrequenlyAskedQuestions.html

Greping trough the OpenSSL source code I could only find one file
with the "covenant" license and that's crypto/bn/bn_gf2m.c =>
not using GF(2^m) should avoid this license.

Nils

---

From: Douglas Stebila <[email-masked]>
Date: Wed, 6 Aug 2003 10:31:24 -0700 (PDT)

> not using GF(2^m) should avoid this license.

The routines in crypto/bn/bn_gf2m.c contain comments indicating where the
algorithm originally came from. (See the file online at
http://cvs.openssl.org/getfile?v=1.10&f=openssl/crypto/bn/bn_gf2m.c) The only
algorithm referenced to Sun Microsystems is the version of BN_GF2m_mod_div from
a paper by Chang-Shantz.  Compilation of this version of BN_GF2m_mod_div is
controlled by the preprocessor flag OPENSSL_SUN_GF2M_DIV and is as far as I
know not compiled in by the default OpenSSL configure script.

Douglas