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..
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):
---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