CRYPTREC

CRYPTREC is the Cryptography Research and Evaluation Committee set up by the Japanese Government to evaluate and recommend cryptographic techniques for government and industrial use. It is comparable in many respects to the European Union's NESSIE project and to the Advanced Encryption Standard process run by NIST in the U.S..

Comparison with NESSIE

There is some overlap, and some conflict, between the NESSIE selections and the CRYPTREC draft recommendations. Both efforts include some of the best cryptographers in the world, and actual (or apparent) conflicts in their selections and recommendations should be examined very carefully. For instance, CRYPTREC recommends several 64 bit block ciphers while NESSIE selected none, but CRYPTREC was obliged by its terms of reference to take into account existing standards and practices, while NESSIE was not. Similar differences in terms of reference account for CRYPTREC recommending at least one stream cipher, RC4, while the NESSIE report specifically said that it was "notable" that they had not selected any of those considered. RC4 is widely used in the SSL/TLS protocols; nevertheless, CRYPTREC recommended that it only be used with 128-bit keys. Essentially the same consideration led to CRYPTREC's inclusion of 160-bit message digest algorithms, despite their suggestion that they be avoided in new system designs. Also, CRYPTREC was unusually careful to examine variants and modifications of the techniques, or at least to discuss their care in doing so; this resulted in particularly detailed recommendations regarding them.

Background and sponsors

CRYPTREC includes members from Japanese academia, industry, and government. It was started in May 2000 by combining efforts from several agencies who were investigating methods and techniques for implementing 'e-Government' in Japan. Presently, it is sponsored by
*the Ministry of Economy Trade and Industry,
*the Ministry of Public Management, Home Affairs and Post and Telecommunications,
*the Telecommunications Advancement Organization, and
*the Information-Technology Promotion Agency.

Responsibilities

It is also the organization providing technical evaluation and recommendations in regard to regulations implementing Japanese laws: examples include that on Electronic Signatures and Certification Services (Law 102 of FY2000, taking effect as from April 2001), the Basic Law on the Formulation of an Advanced Information and Telecommunications Network Society of 2000 (Law 144 of FY2000), and the Public Individual Certification Law of December 2002. Furthermore, CRYPTEC has responsibilities with regard to the Japanese contribution to the ISO/IEC JTC 1/SC27 standardization effort.

Techniques evaluated

The Committee issued public calls for submissions in June 2000 and in August 2001, and received a total of 63 submissions. In addition it compiled a list of techniques which were not directly submitted but which have been adopted as recommended techniques elsewhere and judged important (called "indispensable cryptographic techniques"), or whose evaluation was requested by other organizations or which had special legal significance in Japan (called "specific evaluation target techniques").

The Committee has issued reports on its progress in 2001, 2002, and 2003, and produced a draft report and recommendation in August 2003. The draft report recommends many cryptographic algorithms, protocols, and techniques, but some of them are recommended only conditionally. The list below includes the conditions noted (in "italics").

Evaluated techniques (as of 2002)

NB: there is overlap between the two 'not submitted' groups. This arose from the history and has no other meaning.

indispensable cryptographic techniques (not submitted to CRYPTREC)::Public Key Algorithms (aka asymmetric key w/ public/private key property algorithms)::authentication::signature:::DSA (NIST Digital Signature Algorithm from the Digital Signature Standard FIPS Pub 186-2; ANSI X9.30, part 1):::ECDSA (ANSI X9.62) (Elliptic Curve Digital Signature Algorithm; ANSI X9.62, SEC1 by Standards for Efficient Cryptography Group - 2000):::RSASSA-PKCS1 v1.5::confidentiality:key agreement::Diffie-Hellman (Diffie-Hellman -- ANSI X9.42-2001 specification only):Symmetric Key Cipher Algorithms::64-bit block ciphers:::DES (NBS(NIST)/NSA, FIPS Pub, and other, std):::Triple DES (Tuchman et al, FIPS Pub, and other, std)::128-bit block ciphers:::AES (NIST Advanced Encryption Standard, FIPS Pub std):Cryptographic Hash Algorithms:::MD5 (Message Digest algorithm 5 (Rivest)):::RIPEMD-160 RIPE project Message Digest at 160-bit length:::SHA-1 (NIST/NSA Secure Hash Algorithm -- 160 bit digest):::SHA-256 (... 256 bit digest):::SHA-384 (... 384 bit digest):::SHA-512 (... 512 bit digest):Cryptographic Pseudo-Random Number Generators:::PRNG for DSA in FIPS Pub 186-2 Appendix 3:::PRNG in ANSI X9.42-2001 Annex C.1/C.2:::PRNG in ANSI X9.62-1998 Annex A.4:::PRNG in ANSI X9.63-2001 Annex A.4:::PRNG for general purpose FIPS Pub 186-2 (inc change notice 1) Appendix 3.1:::PRNG in FIPS Pub 186-2 (inc change notice 1) revised Appendix 3.1/3.2

specific evaluation targets (not submitted to CRYPTREC)::Public Key Algorithms (aka asymmetric key w/ public/private key property algorithms)::authentication::signature:::DSA:::ECDSA (in ANSI X9.62):::ESIGN (Nippon Telegraph and Telephone):::RSASSA-PKCS1 v1.5 (RSA Labs, 2002):::TSA-ESIGN (Trisection Size Hash ESIGN -- NTT)::confidentiality:::RSAES-PKCS1 v1.5 (RSA Labs)::key agreement -- none in this group:Symmetric Key Cipher Algorithms:::DES/Triple DES (40, 56 & 168 bit keys):::RC2 (40 & 128 bit keys):::SEED (S Korean Government standard block cipher, 128 bit key)::stream ciphers:::RC4 (40 & 128 bit keys):Cryptographic Hash Algorithms -- none in this group:Cryptographic Pseudo-Random Number Generators -- none in this group

submitted techniques: :Public Key Algorithms (aka asymmetric key w/ public/private key property algorithms)::authentication::signature:::ECDSA(SEC1):::ESIGN:::RSA-PSS::confidentiality:::ECIES(SEC1) (formerly ECAES, SECG 2000):::HIME(R) (Hitachi)::key agreement :::ECDH(SEC1) (SECG 2000):::PSEC-KEM:::RSA-OAEP:Symmetric Key Cipher Algorithms::64-bit block ciphers:::Hierocrypt-L1:::MISTY1:::CIPHERUNICORN-E::128-bit block ciphers:::Camellia:::CIPHERUNICORN-A:::Hierocrypt-3:::RC6 (by Rivest; withdrawn by submitter and not further evaluated):::SC2000::stream ciphers:::MUGI:::MULTI-S01:Cryptographic Hash Algorithms -- none submitted:Cryptographic Pseudo-Random Number Generators -- none submitted

Recommended techniques (as of Nov 2002, pub in Aug 2003 draft report)

NB: "italics" denote contingent recommendation condition(s)
Public Key Algorithms (aka asymmetric key algorithms w/ public/private key property):authentication -- "none recommended":signature::DSA::ECDSA (ANSI X9.62, SEC 1) (empirically secure)::---ESIGN ("forgeable factor discovered does not have provable security")::---TSH-ESIGN ("does not have provable security")::RSA-PSS (provably secure)::RSASSA-PKCS1 v1.5 (empirically secure):confidentiality::---ECIES ("vulnerable to chosen plaintext attacks")::---HIME(R) ("no provable security, specification errors")::RSA-OAEP (provably secure)::RSAES-PKCS1 v1.5 ("Permitted 'for the time being' (as empirically secure), due to use in SSL3.0/TSL1.0 -- use only with maximum caution"):key agreement ::DH (empirically secure)::ECDH (empirically secure)::PSEC-KEM ("recommended only in Data Encapsulation Mechanism construction w/ elliptic curve parameters as defined by SEC 1")
Symmetric Key Cipher Algorithms:64-bit block ciphers ("128 bit block ciphers are preferable if possible") ::CIPHERUNICORN-E::Hierocrypt-L1::MISTY1::3-key Triple DES ("Permitted 'for the time being' if used as specified in FIPS Pub 46-3, and if specified as a de facto standard"):128-bit block ciphers -- "only 128-bit block ciphers are recommended"::AES::Camellia::CIPHERUNICORN-A::Hierocrypt-3::SC2000:stream ciphers::MUG1::MULTI-S01::RC4 ("128-bit keys only")
Cryptographic Hash Algorithms ("256-bit or larger digests are to be preferred in new designs. The two 160-bit digest algorithms listed are acceptable if already included in a current public key specification"):RIPEMD-160 (160 bit digest):SHA-1 (160 bit digest):SHA-256:SHA-384:SHA-512
Cryptographic Pseudo-Random Number Generators -- those listed are examples only, "none is recommended":RPNG based on SHA-1 in ANSI X9.42-2001 Annex C.1:PRNG based on SHA-1 for general purposes in FIPS Pub 186-2 (inc change notice 1) Appendix 3.1:PRNG based on SHA-1 for general purposes in FIPS Pub 186-2 (inc change notice 1) revised Appendix 3.1

External links

* [http://www.cryptrec.jp/english/ Main CRYPTREC Web page]