307210 - Add support for SEED (RFC 4010)

Status: RESOLVED DUPLICATE of bug 453234

(NSS :: Libraries, enhancement, P5)

Description

[Andre-John Mas]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

SEED is a Korean developed 128-bit encryption mechanism. Having been developed
outside the US it should be useable internationally, ie it should not be
affected by US export restrictions. RFC 4010 covers this encryption algorithm.
For this reason it would be good to have NSS support this natively.

Reproducible: Always

Comment 1

[Wan-Teh Chang]

The title of RFC 4010 is "Use of the SEED Encryption
Algorithm in Cryptographic Message Syntax (CMS)."
See http://www.ietf.org/rfc/rfc4010.txt.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

US export restrictions have nothing to do with the algorithm's country of origin.

Comment 3

[Andre-John Mas]

Sorry, the right RFC is 4009: http://www.isi.edu/in-notes/rfc4009.txt

Comment 4

[Wan-Teh Chang]

Our built-in software crypto module (the softokn3 shared library/DLL)
only implements algorithms that are either approved by the US National
Institute of Standards and Technology (NIST) or are commonly used
internationally.

Since NSS supports a plug-in architecture for third-party crypto
modules, you can implement SEED in a PKCS #11 module (i.e., Cryptoki
library) and configure NSS to use it for SEED.  To do this, you
need to first get new PKCS #11 "mechanisms" defined for SEED.  You
can do that by sending a proposal to the [e-mail]
mailing list.  The web page http://www.rsasecurity.com/rsalabs/node.asp?id=2143
has the instructions for subscribing to the cryptoki mailing list.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For what it's worth, the current SEED RFCs are:

ftp://ftp.rfc-editor.org/in-notes/rfc4269.txt
  The SEED Encryption Algorithm

ftp://ftp.rfc-editor.org/in-notes/rfc4162.txt
  Addition of SEED Cipher Suites to Transport Layer Security (TLS)

ftp://ftp.rfc-editor.org/in-notes/rfc4196.txt
  The SEED Cipher Algorithm and Its Use with IPsec

ftp://ftp.rfc-editor.org/in-notes/rfc4010.txt
  Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)


(In reply to comment #4)
> Our built-in software crypto module (the softokn3 shared library/DLL)
> only implements algorithms that are either approved by the US National
> Institute of Standards and Technology (NIST) or are commonly used
> internationally.

Does "commonly used internationally" include something that's the primary algorithm used in one country (South Korea, in this case)?  See http://www.kanai.net/weblog/archive/2007/01/26/00h53m55s for some more details on the situation in South Korea.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

David,  Please look at bug 361025 and the patches attached thereto.

The nation of Japan has done something similar to what the nation of 
South Korea has done, defined their own cipher (named "Camellia") 
and TLS cipher suites that use their ciphers.  

Some developers in Japan did an excellent job of it.  They not only 
got RFCs published, but they also went to the PKCS#11 working group
and defined new PKCS#11 "mechanisms" for their ciphers.  Finally 
they contributed a patch to NSS that implements the cipher in freebl,
implements the new PKCS#11 mechanisms in softoken, implemented the 
new TLS cipher suites in libSSL, and implemented tests for their 
cipher suites in NSS's QA test scripts.  

In other words, they did a complete and thorough job. (I wish we 
could get them to come work on NSS full time!)  

If some Koreans wanted to do a similarly complete job for SEED as
the Japanese have done for Camellia, and contribute a patch to NSS
as the Japanese have done, I think we'd take it, just as we are 
taking the Japanese contribution for NSS 3.12.  

But so far, this SEED RFE is asking the NSS team to do all the work,
and no one has volunteered to contribute anything.  The NSS team's
sponsors aren't interested in SEED.  That's why it's marked WONTFIX.

But like I said, if someone contributes an implementation that is as
thorough and good as the Japanese Camellia contribution, I believe
we'd take it.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #6)
> But so far, this SEED RFE is asking the NSS team to do all the work,
> and no one has volunteered to contribute anything.  The NSS team's
> sponsors aren't interested in SEED.  That's why it's marked WONTFIX.
> 
> But like I said, if someone contributes an implementation that is as
> thorough and good as the Japanese Camellia contribution, I believe
> we'd take it.

That summary seems perfectly reasonable to me, except I'm not sure the WONTFIX status reflects it accurately.  General usage of WONTFIX in other mozilla.org products is that it means that a fix would not be accepted.  (What you described sounds like the "helpwanted" keyword.)

That said, even the WONTFIX status seems reasonable given that it can be done as an extension.  I just thought I'd point out what I knew about the issues that wasn't reflected in the bug report already.

Comment 8

[Daniel Veditz [:dveditz]]

patch contributed in bug 453234