CRYPTREC

From Wikipedia, the free encyclopedia
Jump to: navigation, search

CRYPTREC is the Cryptography Research and Evaluation Committees 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..

Contents

[edit] 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[citation needed] therefore conflicts in their selections and recommendations should be examined with care. 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.

[edit] 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.

[edit] 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.

[edit] 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).

[edit] 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

[edit] 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

[edit] External links

Personal tools
Namespaces
Variants
Actions
Navigation
Interaction
Toolbox
Print/export
Languages