Closed
Bug 195135
Opened 22 years ago
Closed 22 years ago
Add support for Elliptic Curve Cryptography to NSS & SSL
Categories
(NSS :: Libraries, enhancement, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.8
People
(Reporter: nelson, Assigned: nelson)
References
()
Details
Attachments
(2 files)
141.31 KB,
patch
|
Details | Diff | Splinter Review | |
66.80 KB,
patch
|
Details | Diff | Splinter Review |
Add ECC to NSS in freebl (blapi), softoken, pk11wrap and libSSL to implement all or part of the Internet Draft draft-ietf-tls-ecc-02.txt
Assignee | ||
Comment 1•22 years ago
|
||
Marking P2 for NSS 3.8. Highly desirable, not must have. Sun Labs has contributed code to implement this. The contribution is being reviewed and tested now. It consists of 5 new sources files and a large patch to other files in NSS. The 5 new source files are: nss/lib/freebl/GFp_ecl.{c,h} nss/lib/freebl/ec.{c,h} nss/lib/softoken/ecdecode.c Patch forthcoming.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → 3.8
Assignee | ||
Comment 2•22 years ago
|
||
Assignee | ||
Comment 3•22 years ago
|
||
New code is checked in. The tree has gone green. Marking this fixed. The new code implements numerous new ciphersuites, including: TLS_ECDH_ECDSA_WITH_NULL_SHA, /* G */ TLS_ECDH_ECDSA_WITH_RC4_128_SHA, /* H */ TLS_ECDH_ECDSA_WITH_DES_CBC_SHA, /* I */ TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, /* J */ TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, /* K */ TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, /* L */ TLS_ECDH_RSA_WITH_NULL_SHA, /* M */ TLS_ECDH_RSA_WITH_RC4_128_SHA, /* N */ TLS_ECDH_RSA_WITH_DES_CBC_SHA, /* O */ TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, /* P */ TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, /* Q */ TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, /* R */ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, /* S */ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, /* T */ Only the last of these is implemented for both client and server. The others are all client-side only at present. This implementation presently supports only the subset of the Elliptic Curves named in the draft cited above. It supports only the curves over integer prime fields, not curves over polynomial fields. An NSS-based client can interoperate with an OpenSSL-based server when the server uses a curve that is supported by NSS. The existing draft for ECC support in TLS does not provide for negotiation of supported curves. An implementation (such as this one) that does not support all the curves defined in that draft is likely to have interoperability problems with other implementations that do support them all. When a server chooses and uses a curve that is not supported by the client, the TLS handshake fails completely. The client's only recourse is to disable the ECC ciphersuites and try again. Therefore, I recommend that all the elliptic curve TLS cipher suites be disabled by default in any client, and only enabled by people who understand how to deal with any interoperability problems that may occur. Hopefully, curve negotiation will be added to the next draft of the spec for ECC TLS. (Note that the current draft expired yesterday.) Note that most of the ECC code is conditionally compiled. To enable it in an NSS build, define the environment variable XCFLAGS, and set it to the value -DNSS_ENABLE_ECC . For NSS 3.8, the QA'ed binary shared libraries will not have ECC enabled. Others building NSS from sources are free to enable it.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 4•22 years ago
|
||
This patch contains the changes contributed by Vipul Gupta <Vipul.Gupta@Sun.COM> that enable the new GF2m code that was previously contributed by Sheueling Chang Shantz <sheueling.chang@sun.com> and Douglas Stebila <douglas@stebila.ca>, Sun Microsystems Laboratories Checked into NSS 3.8 (trunk) today.
You need to log in
before you can comment on or make changes to this bug.
Description
•