sign in sign up
<<
Home , Avalanche effect, Cryptography, Cryptography standards, CRYPTREC, Padding (cryptography), Present

CRYPTREC 2001

CRYPTREC Report 2001

March 2002 - Promotion Agency, Japan Telecommunications Advancement Organization of Japan

CRYPTREC 2001

Contents

Introduction 1 On the CRYPTREC Evaluation Committee Report 3 Note on the use of this report 7

1 Overview of Cryptographic Technique Evaluation 8 1.1 Evaluation Organs and Schedule ･･････････････････････････････････････････8 1.2 How evaluation was carried out. ･･････････････････････････････12 1.3 Terminology ･････････････････････････････････････････････････････････13 1.4 Evaluation Committee Members ･････････････････････････････････････････14

2 Evaluation of public cryptographic techniques 17 2.1 Target of Evaluation and Evaluation Method ････････････････････････････････17 2.1.1 Evaluated Cryptographic Techniques ･･･････････････････････････････････17 2.1.2 Evaluation Policy･･･････････････････････････････････････････････････17 2.1.3 Evaluation Method ･････････････････････････････････････････････････19 2.2 Evaluation result ･･････････････････････････････････････････････････････21 2.2.1 Outline of evaluation result ･･･････････････････････････････････････････21 2.2.2 General Evaluation of the Difficulty of Arithmetic Problems･････････････････23 2.2.3 Overall Judgment of Cryptographic Techniques that were the Target of Detailed Evaluation ･････････････････････････････････････････････････23 2.2.4 Overall Judgment of Cryptographic Techniques under ･･･････････26 2.2.5 Overall Judgment of that were Targets of Screening Evaluations in 2001 ････････････････････････････････････････27 2.3 Evaluation of the Difficulty of Arithmetic Problems ･･････････････････････････28 2.3.1 Factorization Problem ･･･････････････････････････････････････････････28 2.3.2 Discrete Problem ･･････････････････････････････････････････32 2.3.3 Problem ･･････････････････････････････36 2.4 Evaluation of Individual ･････････････････････････････････････････40 2.4.1 DSA ･････････････････････････････････････････････････････････････40 2.4.2 ECDSA ･･････････････････････････････････････････････････････････43 2.4.3 ESIGN Signature･･･････････････････････････････････････････････････49 2.4.4 RSA (RSA-OAEP, RSA-PSS, RSA signatures) ･･･････････････････････････58 2.4.5 EPOC-2 ･･････････････････････････････････････････････････････････67

i

CRYPTREC 2001

2.5 Evaluation of Cryptographic Techniques under Observation ････････････････････71 2.5.1 ECIES in SEC1 ････････････････････････････････････････････････････71 2.5.2 ECDH in SEC1 ････････････････････････････････････････････････････74 2.5.3 DH ･･････････････････････････････････････････････････････････････76 2.6 Evaluation of Cryptosystems that are the Target of Screening Evaluation･･････････78 2.6.1 OK-ECDSA･･･････････････････････････････････････････････････････78 2.6.2 NTRU ･･･････････････････････････････････････････････････････････80 2.6.3 HIME(R) ･････････････････････････････････････････････････････････81 2.6.4 OK-ECDH････････････････････････････････････････････････････････83 2.6.5 PSEC-KEM ･･･････････････････････････････････････････････････････85

3 Evaluation of symmetric-key cryptographic techniques 87 3.1 Evaluation method ････････････････････････････････････････････････････87 3.1.1 Evaluation method of symmetric -key ciphers･････････････････････････････87 3.2 Overall evaluation ･････････････････････････････････････････････････････94 3.2.1 64- block ciphers･････････････････････････････････････････････････94 3.2.2 Overall security evaluation ･･･････････････････････････････････････････96 3.2.3 128-bit block ciphers･･･････････････････････････････････････････････104 3.2.4 Overall security evaluation ･･････････････････････････････････････････107 3.2.5 Stream ･････････････････････････････････････････････････････ 116 3.3 Evaluation of ciphers targeted for detailed evaluation (individual ciphers)････････ 119 3.3.1 CIPHERUNICORN-E･･････････････････････････････････････････････ 119 3.3.2 Advanced Standard (AES) ･････････････････････････････････126 3.3.3 CIPHERUNICORN-A･･････････････････････････････････････････････133 3.3.4 SEED ･･･････････････････････････････････････････････････････････142 3.3.5 MULTI-S01 ･･････････････････････････････････････････････････････149 3.4 Evaluation of Ciphers under Monitoring ･･････････････････････････････････161 3.4.1 -L1 ････････････････････････････････････････････････････161 3.4.2 MISTY1 ･････････････････････････････････････････････････････････167 3.4.3 Triple DES ･･･････････････････････････････････････････････････････173 3.4.4 ･････････････････････････････････････････････････････････174 3.4.5 Heirocrypt-3･･････････････････････････････････････････････････････180 3.4.6 RC6 ････････････････････････････････････････････････････････････186 3.4.7 SC2000 ･････････････････････････････････････････････････････････190

ii

CRYPTREC 2001

3.5 Evaluation of Ciphers Selected for Screening Evaluation ･････････････････････196 3.5.1 MUGI･･･････････････････････････････････････････････････････････196 3.5.1 A Comments of Evaluators (Unmodified Excerpts) ･･･････････････････････198

4 Hash-Function Evaluation 200 4.1 Evaluation Method ･･･････････････････････････････････････････････････200 4.1.1 How to Evaluate Harsh Functions ･････････････････････････････････････200 4.2 General Evaluation ･･･････････････････････････････････････････････････200 4.2.1 Hash-Function Evaluation ･･･････････････････････････････････････････200 4.3 Detailed (Individual) Evaluation of Cryptograph ･････････････････････････････201 4.3.1 draft SHA-256/384/512 ･････････････････････････････････････････････201 4.4 Monitoring Process Evaluation ･･････････････････････････････････････････212 4.4.1 RIPEMD-160･････････････････････････････････････････････････････212 4.4.2 SHA-1 ･･････････････････････････････････････････････････････････217

5 Evaluation of Pseudorandom Number Generation System 218 5.1 Evaluation Method ･･･････････････････････････････････････････････････218 5.1.1 Method for Evaluating Pseudorandom Number Generation ･････････････････218 5.2 Overall Evaluation ･･･････････････････････････････････････････････････218 5.2.1 Pseudorandom Number Generation System ･････････････････････････････218 5.3 Evaluation of the Ciphers under Monitoring ･･･････････････････････････････220 5.3.1 PRNG Based on SHA-1 ････････････････････････････････････････････220 5.4 Evaluation of Ciphers to be Screening-Evaluated ･･･････････････････････････227 5.4.1 TAO ･･･････････････････････････････････････････････････････227

6. Evaluation of SSL-protocol cryptographic techniques 229 6.1 Overall evaluation ････････････････････････････････････････････････････229 6.1.1 Purpose ･････････････････････････････････････････････････････････229 6.1.2 Target and scope of the investigation ･･････････････････････････････････229 6.1.3 Method･･････････････････････････････････････････････････････････230 6.1.4 Result ･･･････････････････････････････････････････････････････････230 6.1.5 SSL/TLS application and considerations of actual use･････････････････････232 6.2 Implementation of SSL/TLS protocol and evaluation of operation ･･････････････233 6.2.1 Security associated with ･････････････････････････････････233 6.2.2 Security associated with protocol mechanism････････････････････････････234

iii

CRYPTREC 2001

6.2.3 Security on implementation･･････････････････････････････････････････234 6.2.4 Security in operation ･･･････････････････････････････････････････････234 6.2.5 Comparison of SSL/TLS ････････････････････････････････････････････235 6.2.6 Expansion work of TLS･････････････････････････････････････････････235 6.2.7 General descriptions ･･･････････････････････････････････････････････235 6.3 Evaluation of cryptographic technique used in SSL/TLS･･････････････････････236 6.3.1 Investigation on vulnerability in key sharing and schemes using RSA (1024 and 2048) ･･････････････････236 6.3.2 DES (40-/56 bit-key DES, 168bit-key Triple DES) ･･･････････････････････241 6.3.3 RC2 (40,128)･････････････････････････････････････････････････････246 6.3.4 RC4 (40, 128) and Arcfour (128) ･････････････････････････････････････248

7 Intellectual Property Information, Licensing Policy and Reference List of Cryptosystem Scheduled to be Evaluated in 2002 251 7.1 Cryptosystem in Monitoring State ･･･････････････････････････････････････251 7.1.1 Public -Key Cryptosystem ･･･････････････････････････････････････････251 7.1.2 Common Key Cryptographic Technique････････････････････････････････255 7.2 Candidates of Cryptosystems to be Evaluated in Detail in 2002 ････････････････267 7.2.1 Public Key Cryptographic Techniques ･････････････････････････････････267 7.2.2 Common Key Cryptographic Techniques ･･･････････････････････････････272

8 Cryptographic Techniques Evaluated 274

iv

CRYPTREC 2001

Introduction

This report summarizes the evaluation work done in 2001 by the CRYPTREC Evaluation Committee. This committee has been actively undertaking evaluation of cryptographic techniques as part of the CRYPTREC Project for the list-up of cryptographic techniques useful for the Japanese e-Government whose foundation is to be established by the 2003.

Construction of the Japanese e-Government has been under way in recent to establish a system for electronic administrative procedures such as applications, notifications and government procurement. Use of a cryptographic technique is indispensable for higher-level security of the e-Government services. Various cryptographic techniques have been developed in the , and many products and software packs using such a technique are offered on the market now. It is quite important for the e-Government to gather information on the security of such a technique before actually using it. Under these circumstances, the Ministry of Economy, Trade and Industry (formerly the Ministry of International Trade and Industry) entrusted the task of evaluating cryptographic techniques useful for the e-Government to the Information-technology Promotion Agency, Japan (IPA) in 2000, and the CRYPTREC Report 2000 was compiled. (The CRYPTREC Report 2000, JIS-TR X0050, was issued on Nov.1, 2001.)

In 2001, IPA and Telecommunications Advancement Organization of Japan (TAO) became a joint secretariat for the CRYPTREC Evaluation Committee, which works together with the newly organized CRYPTREC Advisory Committee (for which the Ministry of Public Management, Home Affairs, Posts and Telecommunications and the Ministry of Economy, Trade and Industry function as its secretariat). Representatives of the Ministry of Public Management, Home Affairs, Posts and Telecommunications, Ministry of Economy, Trade and Industry, Cabinet Office, National Police Agency, Defense Agency, Ministry of Justice, Ministry of Foreign Affairs, and Ministry of Finance attended meetings of the committee as observers, thus ensuring cross-sectional evaluation activities. Many Japanese and foreign specialists were commissioned to do the actual evaluation work. The Cryptography Evaluation Workshop in January 2002, Call for Comment and other programs were undertaken to seek the opinion of people in different industries and different fields in an effort to ensure fairness and openness.

Turning our eyes to advancements in the rest of the world, we will note the Advanced Encryption Standard (AES) program which will replace the (DES) as the ’ next -generation federal standard, the New European Schemes for Signature, Integrity and Encryption (NESSIE) project in Europe, and ISO/IEC international standard activities for cryptogra phic technology. In view of this, we believe that the Japanese cryptographic technique evaluation project is a significant activity in accordance with the trend of the world in cryptographic technology.

1 CRYPTREC 2001

We will be very happy if this report will impart helpful information on cryptographic technology for the Japanese e-Government system and prove useful for those concerned.

In conclusion we wish to express our deepest gratitude to Professor Imai for his unceasing and untiring efforts and dedication to the fu rtherance of the CRYPTREC Evaluation Committee’s activity for the past two years as chairman of that committee. We would also like to express our thanks to Professor Tsujii for stating his opinion from a higher and broader standpoint as the Committee’s Senior Advisor. Sincere thanks are also extended to Professor Kaneko, Chairman of Symmetric-Key Cryptography Subcommittee, and Professor Matsumoto, Chairman of Public-Key Cryptography Subcommittee, for their diligent efforts and unceasing enthusiasm. To all other committee members and ministerial representatives, we are deeply grateful for their efforts and contributions.

March 2002

O. Naito, Director, Security Center, Information-Technology Promotion Agency, Japan

K. Suzuki, Senior Director, Research, Planning and Administration Dept., Telecommunications Advancement Organization of Japan

2 CRYPTREC 2001

On the CRYPTREC Evaluation Committee Report

This report contains the results of the activities of the CRYPTREC Evaluation Committee (CRYPTREC) obtained in 2001. This committee was formed for the purpose of evaluating cryptographic techniques that might possibly be available for use in the area of the electronic government (e-Government). It should be noted that it was extremely difficult to evaluate properly and objectively such a large number of cryptographic techniques in such a short period of time. However, because all committee members were solemnly aware that this evaluation project was and is indispensable -- not only to the nation's e-Government, but also to the development of Japan's 21st century networking capability --the project achieved great success and made in the area of cryptology in Japan. This success was obtained through the consistent devoted cooperation and collaboration of all parties concerned. I believe that this report contains the essential information we have been seeking concerning the evaluation of cryptographic techniques currently available for the e-Government. I sincerely hope that this report is utilized directly as an efficient means of successfully creating e-Governments at various levels across our country in the very near future.

Prior to the start of the activities of the CRYPTREC, in fiscal year 1999, two study groups were created: "Investigation and Research on Standard (Criteria) for Government Procurement" via the Information-technology Promotion Agency, Japan (IPA), and "Study Group on Promotion and Advancement of Cryptographic " (chaired by Professor Shigeo Tsujii of Chuo University) via the Ministry of Posts and Telecommunications (the now Ministry of Public Management, Home Affairs, Posts and Telecommunications).

In their reports, both groups stated that a governmental evaluation of cryptographic techniques was required. One of the common points, stated emphatically in both reports, stressed that the existing cryptographic techniques, on which information security is based, required objective verification -- especially in terms of security -- from a technical and highly professional viewpoint.

In response to these proposed reports, the consulting committee of the above-mentioned Investigation and Research Group of the IPA was dissolved in May 2000. It was followed by the establishment of the CRYPTREC Evaluation Committee, the secretariat of which is the IPA Security Center, as a project sponsored by the Ministry of International Trade and Industry (the now Ministry of Economy, Trade and Industry). This committee comprised of specialists who were equipped with the academic background and highly developed specialized knowledge of cryptography and cryptographic security techniques, and was tasked with the responsibility of evaluating cryptographic techniques in terms of security and efficiency.

3 CRYPTREC 2001

In 2001, the evaluation task was carried out through coordination between the Cryptographic Technique Investigation Committee, for which the Ministry of Public Management, Home Affairs, Posts and Telecommunications and Ministry of Economy, Trade and Industry function as its secretariat, and the CRYPTREC Evaluation Committee, for which Telecommunications Advancement Organization of Japan (TAO) and IPA serve as its secretariat, to broaden the scope of evaluation activity laterally across the governmental organization.

It is assumed that the e-Government for the network society will be based on an open network. In this open network, all that essentially matters is the strategy in which the security of information handled is maintained. Viewed from this context, it is indisputable that information security technology is a primary technological factor that will support the e-Go vernment and that cryptographic techniques will form the framework for this technology. Accordingly, one of the most essential tasks aimed at the furtherance of creating the e-Government in today's network society is the evaluation of cryptographic techniques.

It should be especially noted, as far as evaluation of security of cryptographic techniques is concerned, that meaningful results will not be obtained unless cryptographic are made open to the public. Moreover, even if cryptographic algorithms are open, with no attack techniques surfacing over a certain period, it does not necessarily mean that the security is guaranteed. And yet, an explicit description of security levels is indispensable to the successful creation of the e-Government. Moreover, according to "Guidelines for Cryptography Policy" recommended by the OECD council, an independent evaluation of cryptographic techniques to be used for the e-Government, on which public welfare is to be based, is naturally the solemn duty of those government organizations responsible for implementing the e-Government systems. Thus, the role of the CRYPTREC Evaluation Committee established to share this duty of the government organizations is extremely heavy.

However, the technological levels available for cryptography evaluation at this time are not satisfactory at all. This makes it very hard to fully evaluate the security of cryptographic algorithms. And security of cryptographic algorithms is not something guaranteed for future years. To take a concrete example, we will consider the concept of "". At the current technological levels, provable security implies a approved based on a certain assumption. It is certainly one important property to be considered when security is assessed. Even if, however, provable security is proved to a certain system, it does not necessarily mean that the system is really secure. Only qualified and experienced experts can be trusted to make a proper determination of the security offered by cryptographic algorithms and, of course, only after careful examination. Those different experts may have different opinions, but in many cases, those experts who are in the front line of cryptographic techniques, taking an active part on international stages, share common concerns and a mutual understanding of the issues involved. It was these common concerns and agreed upon understandings that were, to the greatest degree possible, gathered

4 CRYPTREC 2001

together to form the basis for this report. However, when a consensus in agreement could not be reached on a certain point, the committee worked to ensure that sufficient discussions were conducted from all possible angles and then biased the conclusion toward the side, or the more exacting side in terms of evaluation. This was considered unavoidable if the committee was to fulfill its mandate for evaluating cryptographic techniques that were actually to be used for the e-Government.

This report contains the results of the best possible evaluations at present for the e-Government recommended ciphers which is to be chosen in fiscal 2002 in Japan, and, I believe, will play a significant role in the establishment of the e-Government. Since no similar evaluation task had been undertaken by the government in the past, its criteria for evaluation of proposed/submitted techniques was modeled after the corresponding criteria of the AES Project of the United States, and the activities in 2000 were fully taken into consideration. In August 2001, proposals/submissions were publicly invited. In October, the CRYPTREC Cryptographic Submissions Briefing for introducing proposed/submitted techniques was held. In January 2002, the CRYPTREC Cryptographic Technique Evaluation Workshop was held. Caution was always exercised to ensure fairness and openness. The evaluation results mentioned earlier are the outcome of examinations by use of the currently available know-how and are in no way conclusive. The evaluation work will be continued with the results of the government-level CRYPTREC Advisory Committee’s activities taken into account.

Cryptographic techniques are sure to herald great advancements, and the security levels of current cryptographic systems will be subject to drastic change. With this in mind, I hope this cryptography research and evaluation project will continue for a meaningful period of time. I also hope that an organization dedicated specifically to the ongoing evaluation of cryptographic techniques will be established and I strongly hope that the activities of the CRYPTREC Evaluation Committee will provide the foundation of that organization.

I am pleased to note that we were able to gather together so many of Japan's most influential cryptography researchers to take part in the CRYPTREC Evaluation Committee and its two subcommittees: the Symmetric-Key Cryptography Subcommittee, and the Public-Key Cryptography Subcommittee. Despite the pressures of his or her public duties, each committee member worked diligently to find the time necessary to participate in the activities of the CRYPTREC, willingly embracing and discharging the duties and responsibilities as a committee member. Furthermore, I would like to express my special thanks to Professor Toshinobu Kaneko of University of Tokyo and Professor Tsutomu Matsumoto of Yokohama National University, the subcommittee chairpersons, for their fruitful collaboration aimed at incorporating the whole evaluation activities into this report. Of course, I also wish to thank all the committee members for sharing their knowledge and experience in order to help advance the activities of this project, taking full of the researchers' network. Included among the committee and the subcommittee members were

5 CRYPTREC 2001

the designers of the cryptographic algorithms under evaluation. Let me express again my thanks and sincere appreciation to these committee members who worked openly and collaborated freely toward the shared goals of the project, without allowing their viewpoints to be in any way biased by their personal interests .

In conclusion, I wish to express my deepest thanks to all the parties involved in this project, the first Japanese cryptographic evaluation project, for their cooperation in approaching the project from the standpoint of their career.

March 2002

Hideki Imai Chairperson The CRYPTREC Evaluation Committee

6 CRYPTREC 2001

Note on the use of this report

This report assumes that readers have a basic general knowledge of information security. Those who are engaged in business related to cryptosystems for electronic government such as or GPKI systems, for exa mple, are targeted readers of this report. However, it is desirable to have a certain level of knowledge on cryptosystems to read and understand the evaluation result of each cipher.

The overview of the evaluation work is described in Chapter 1, and evaluations of individual cryptographic techniques are presented in Chapter 2 to 5. Public-key cryptographic techniques are described in Chapter 2, symmetric-key cryptographic techniques (block ciphers and stream ciphers) in Chapter 3, the in Chapter 4, and pseudo-random number generators in Chapter 5. Investigations on SSL protocols are presented in Chapter 6.

This cryptography evaluation was compiled by CRYPTREC Evaluation Committee, which is composed of Japan's foremost cryptography experts. However, due to the nature of cryptographic techniques, the result of security evaluation described in this report may not remain valid in the future. Thus, it is considered necessary to continue such evaluations for a long time to come.

The evaluation was conducted in accordance with technical specifications submitted in response to a call for submissions for cryptographic techniques in August and September of 2001. Therefore, some of the cryptographic techniques may differ from those used for products of the same name or proposed to other organizations including ISO/IEC.

Since the target of evaluation of this year was limited to those whose specifications had been disclosed to the public, the technical specifications of the cryptographic techniques submitted for evaluation can be obtained through the Web sites of the applicants. Note that this committee shall not be held responsible for any inadequacies, incompleteness, etc. of the information provided.

In implementing cryptographic techniques submitted for this cryptography evaluation, the recommended and utilized methodology is to obtain advice from experts with special knowledge of the cryptographic technique in question, or to use cryptography tools (libraries) prepared by experts skilled in cryptographic techniques.

For further information, please contact the Security Center or Telecommunications Advancement Organization of Japan. All opinions and comments are welcome.

e-mail: [email protected]

7 CRYPTREC 2001

1 Overview of Cryptographic Technique Evaluation

1.1 Evaluation Organs and Schedule

The evaluation of cryptographic techniques started in 2000, which will provide a common security basis for the e-Government to be established by 2003, was continued in the year 2001 (from April, 2001 to March, 2002). Construction of such a common security basis is regarded as an important task. Cryptographic techniques, among others, carry outstanding weight as a means for and integrity of electronic information and for electronic certification, and are therefore important basic security know-how for the e-Government.

For appropriate usage of cryptographic techniques for the Japanese e-Government system, this report contains evaluations of the security, practicability, etc. of cryptographic techniques judged useful for the Japanese e-Government system from technical and expert standpoints. The report is intended as reference data about e-Government-related tasks, the Electronic Signature Law, GPKI, etc.

To reinforce the cryptography evaluation organs, the CRYPTREC Advisory Committee was formed in 2001 under the joint names of the Director-General for Technology Policy Coordination Ministry of Public Management, Home Affairs, Posts and Telecommunications and the Head of the Business Affairs and Information Bureau, Ministry of Economy, Trade and Industry. This committee gives judgment from the standpoint of specific policies, and the CRYPTREC Evaluation Committee set up jointly by the Information–technology Promotion Agency and Telecommunications Advancement Organization of Japan evaluates cryptographic techniques. (See Fig.1.1.) Reference should be made to reports of the CRYPTREC Advisory Committee also.

*Cryptographic Advisory Committee CRYPTREC Evaluation Committee (chaired by H. Imai)

Public-Key Cryptography Subcommittee Symmetric-Key Cryptography (chaired by T. Matsumoto) Subcommittee (chaired by T. Kaneko)

*Secretariat: Ministry of Public Management, Home Affairs, Posts and Telecommunications and Ministry of Economy, Trade and Industry

Fig.1.1 CRYPTREC Organs

9 CRYPTREC 2001

In 2001, as in the previous year, submissions of a cryptographic technique were publicly invited. As in 2000, what were publicly sought were submission of both public-key cryptographic techniques (, signature, key sharing and ) and symmetric-key cryptographic techniques (64-bit block ciphers, 128-bit block ciphers, stream ciphers, hash function and pseudo-random number generators). Some of the cryptographic techniques submitted in 2001 have already been evaluated in detail. However, the persons who submitted them are asked to submit them with the new evaluation information after the time of original submission taken into account and with the necessary editorial corrections made in the submission papers. New submissions are subject to a technical requirement. They must be at least equal in features to the above submissions already evaluated in detail.

In 2001, submissions were invited from August 1 to September 27, and 31 submissions in all were received. On October 8 and 9, 2001, the CRYPTREC Cryptographic Submissions Briefing for explanation of the submissions received was held, and on that occasion, all submitters explained their cryptographic techniques.

To identify the techniques evaluated in 2001, refer to the list of evaluated cryptographic techniques in Chapter 8.

Opinion and comments on the details of evaluations and investigations and other matters were publicly sought through Call for Comment and the Cryptography Evaluation Workshop (held on January 28, 2002).

Table 1.1 Major Activities of CRYPTREC Evaluation Committee

May, 2000 CRYPTREC Evaluation Committee organized. June to July, 2000 Cryptographic technique submissions publicly invited for the Year 2000. August to October, 2000 Cryptography screening evaluation for 2000. October, 2000 Cryptographic technique Symposium (explanation of the purposes of CRYPTREC activities). October, 2000 to March, 2001 Detailed evaluation of cryptographic techniques for 2000 March, 2001 Issue of CRYPTREC Report 2000 April, 2001 CRYPTREC Workshop (report on CRYPTREC activities in 2000).

August to September, 2001 Cryptographic technique submissions for 2001 publicly invited. October, 2001 The CRYPTOREC Cryptographic Submissions Briefing October, 2001 to March, 2002 Detailed evaluation of the re-submissions in 2001 and other cryptographic techniques deemed in need of evaluation. Screening evaluation of new submissions in 2001. January, 2002 Cryptography Evaluation Workshop (Report on the actualities of screening evaluation and detailed evaluation) March, 2002 Issue of CRYPTREC Report 2001

10 CRYPTREC 2001

Forty-four cryptographic techniques in all were subject to evaluation. The cryptographic techniques include those judged to be in need of evaluation by the CRYPTPREC Evaluation Committee, those to be evaluated at the request of the CRYPTREC Advisory Committee, and those mentioned in the Execution Rule for Law on Electronic Signature and Certification and the Guidelines for Authorizing Special Certification Businesses under the Law of Electronic Signatures and Certification Businesses. (Refer to Chapter 8.)

The following is an outline of the Execution Rule for Law on Electronic Signature and Authentication and the Guidelines for Authorizing Special Certification Businesses under the Law of Electronic Signatures and Certification Businesses:

(a) Excerpt from the Execution Rule for Law on Electronic Signature and Certification which was put into force on April 1, 2001 according to Article 2-3 of the Law on Electronic Signature and Authentication:

Specific Authentication Actions

Article 2 The criterion of the competent ministry’s order mentioned in Article 2-3 requires

that security of electronic signature be based on the difficulty involved in one of the following

processes:

1. Factorization of an integer which is the product of two almost equally sized integers composed of 10020 or more . 2. Calculation of a discrete logarithm in a multiplication group of finite fields which is composed of 10024 or more bits. 3. Calculation of a discrete logarithm in a group of points, composed of 160 or more bits, on an elliptic curve. 4. Process recognized by the competent minister as one involving an equivalent of the difficulty inherent in the process defined in 3 above.

11 CRYPTREC 2001

(b) Excerpt from Guideline on Recognition of Specific Authenticating Actions Under Law on Electronic Signature and Authentication:

Requirements of electronic signature associated with specific authenticating action Article 3 Electronic signatures which fit one of the definitions given below meet the requirement in Article 2 of the Rule:

1. RSA type (object identifier: 1 2 840 113549 1 1 5 or 1 2 840 113549 1 1 4) with a modulus which is composed of 1214 or more bits. 2. ECDSA type (object identifier: 1 2 840 1 0045 4 1). Both defined and order of an elliptic curve are composed of 160 or more bits. 3. DSA type (object identifier: 1 2 840 1 0040 4 3) with a modulus prime number which is composed of 10024 or more bits. 4. ESIGN type (object identifier: 0 2 440 5 5 3 4 or 0 2 440 5 5 3 3) with a modulus composed of 1024 or more bits and an exponent for verification, composed of 8 or

1.2 How cryptography evaluation was carried out.

In 2001, the CRYPTREC Evaluation Committee decided on an evaluation principle, and the Symmetric-Key Cryptography Subcommittee and the Public-Key Cryptography Subcommittee performed the evaluation work. Symmetric-key and public-key cryptographic techniques were evaluated in slightly different ways because of the difference in nature between the two categories. Reputable specialists in Japan and abroad were commissioned to make a detailed evaluation of cryptographic techniques in both categories, and the Symmetric-Key Cryptography Subcommittee and the Public-Key Cryptography Subcommittee drew their conclusions based on the results of evaluations of techniques in the respective categories. Reputable Japanese specialists were as ked to make a screening evaluation, and then the above two subcommittees drew their conclusions based on the results of that screening evaluation of techniques in the respective categories.

(a) Evaluation by Symmetric-Key Cryptography Subcommittee The evaluation by the Symmetric-Key Cryptography Subcommittee can be broadly divided into these parts: (1) Detailed evaluation of those cryptographic techniques subject to such evaluation in 2000. (2) Screening evaluation of the cryptographic techniques newly submitted in 2001. (3) Evaluation of those cryptographic techniques which were judged to be in need of evaluation, by the CRYPTREC Evaluation Committee.

12 CRYPTREC 2001

As for the detailed evaluation of the techniques subject to such evaluation in 2000, the evaluation efforts were directed mainly to those techniques about which no final conclusion could be drawn in 2000 by the Symmetric-Key Cryptography Subcommittee. SEED which was proposed to ISO/IEC JTC1 SC27 by the Republic of Korea and RC2, RC4, DES and Triple DES used for SSL/TLS, which is a standard security protocol, were also evaluated at the request of the CRYPTREC Evaluation Committee. Among the techniques evaluated at the request of the CRYPTREC Evaluation Committee, SEED was committed for evaluation from the standpoint of international contribution/ international cooperation. (b) Evaluation by Public-Key Cryptography Subcommittee. The evaluation by the Public-Key Cryptography Subcommittee in 2001 can be broadly divided into these parts: (1) Detailed evaluation of the cryptographic techniques scheduled for such evaluation in 2000. (2) Screening evaluation of the cryptographic techniques newly submitted in 2001. (3) Evaluation of those cryptographic techniques which were judged to be in need of evaluation by the CRYPTREC Evaluation Committee. The Public-Key Cryptography Subcommittee carries out detailed evaluation of the cryptographic techniques subject to detailed evaluation in 2000, and the cryptographic techniques mentioned in the Guidelines for Authorizing Special Certification Businesses under the Law of Electronic Signatures and Certification Businesses. As for evaluation of the cryptography (RSA cryptosystem) used for SSL/TLS, special attention was focused on the usage in SSL/TLS. In 2001, an investigation concerning factorization problems was started to support primitive security evaluation. That investigation involved primarily evaluation of computation complexity through a experiment with the aim of improving the accuracy of estimation of the difficulty in factorization of a composite number, which is viewed as a highly difficult task at present. Since it was expected that SSL/TLS will be used as the primary for users and the e-Government system, an investigation was made into the current status of SSL/TLS as a cryptographic protocol, e.g., known problems involved in it and other matters.

1.3 Terminology

Definitions of and remarks on some of the CRYPTREC Evaluation Committee’s terms used in this report are given in this section:

(1) Submitted cryptographic techniques (ciphers) Cryptographic techniques submitted in response to the call for submissions by the CRYPTREC Evaluation Committee.

13 CRYPTREC 2001

(2) Other cryptographic techniques (ciphers) ( to be evaluated besides submission) Cryptographic techniques which are judged to be in need of evaluation, regardless of whether those are submitted or not. (3) Screening evaluation Primary evaluation of submitted cryptographic techniques to detect any obvious security problem or any problem associated with a third party’s implementation. (4) Full evaluation Evaluation in such aspects as resistance to known methods of attack, parameter or key setting criteria and implementation prospect, to determine practicability for the e-Government. (5) Follow-up evaluation Evaluation of those cryptographic techniques which the CRYPTREC Evaluation Committee judges to be in need of further evaluation. (6) Specific evaluation Evaluation of cryptographic techniques in such specific fields subject to a definitely prescribed set of requirements, e.g., those used under the Electronic Signature Law. (7) Monitoring phase cryptographic techniques (ciphers) Cryptographic techniques judged free of a security problem at the time of evaluation and monitored for threat by a new technical advanced . They may be re-evaluated according to a change of the conditions.

1.4 Evaluation Committee Members

CRYPTREC Evaluation Committee (titles, etc. as of end of March 2002)

Chairman Hideaki Imai Professor, University of Tokyo Committee member Shigeo Tsujii Professor, Chuo University Committee member Eiji Okamoto Professor, Toho University Committee member Tatsuaki Okamoto Fellow, NTT Nippon Telegraph and Telephone Corporation Committee member Toshinobu Kaneko Professor, Science University of Tokyo Committee member Head Researcher, Corporation Committee member Tsutomu Matsumoto Professor, Yokohama National University

Public-key Cryptography Subcommittee (titles, etc. as of end of March 2002)

Chairman Tsutomu Matsumoto Professor, Yokohama National University Committee member Seigo Arita Senior Researcher, NEC Corporation Committee member Kazuo Ohta Professor, the University of Electro Committee member Jun Kogure Senior Researcher, LABORATORIES LTD. Committee member Yasuyuki Sakai Senior Researcher, Mitsubishi Electric Corporation

14 CRYPTREC 2001

Committee member Hiroki Shizuya Professor, Tohoku University Committee member Atsushi Shinmbo Research Scientist, Corporation Committee member Seiichi Susaki Researcher, Ltd. Committee member Natsume Matsuzaki Senior Researcher, Matsushita Electric Industrial Co., Ltd. Committee member Hajime Watanabe National Institute of Advanced Industrial Science and Technology

Symmetric-Key Cryptography Subcommittee (titles, etc. as of end of March 2002)

Chairman Toshinobu Kaneko Professor, Science University of Tokyo Committee member Kiyomichi Araki Professor, Tokyo Institute of Technology Committee member Shinichi Kawammura Senior Research Scientist, Toshiba corporation Committee member Masayuki Kanda Research Engineer, NTT Nippon Telegraph and Telephone Corporation Committee member Tohru Kohda Professor, Kyushu University Committee member Kazukuni Kobara Research Associate, University of Tokyo Committee member Kouichi Sakurai Assistant Professor, Kyusyu University Committee member Takeshi Shimoyama Researcher, FUJITSU LABORATRIES LTD. Committee member Kazuo Takaragi Senior Manager, Hitachi, Ltd. Committee member Makoto Tatebayashi Chief Engineer, Matsushita Electric Industrial Co., Ltd. Committee member Yukiyasu Tsunoo Principal Researcher, NEC Corporation Committee member Toshio Tokita Head Researcher, Mitsubishi Electric Corporation Committee member Masakatsu Morii Professor, University of Tokushima

Observers (Title, etc. as of the end of March 2002)

Tsukasa Akaiwa Info-Communications Bureau, National Police Agency Hideyuki Torii Info-Communications Bureau, National Police Agency Masahiro Masuga Command Division, Japan Defense Agency Noriyasu Matsui Grand Staff Office, Japan Defense Agency Taku Kiyasu Information and Communications Policy Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications Takeshi Tandai Information and Communications Policy Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications (Until June, 2001) Hiroshi Monma Information and Communications Policy Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications Kiyoharu Imai Information and Communications Policy Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications (Until June, 2001) Hiroki Dodo Information and Communications Policy Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications (Until July, 2001) Akira Fukuoka Information and Communications Policy Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications Masato Wakitani Administrative Management Bureau, Ministry of public Management, Home affairs, Post and Telecommunications Hiroshige Yamamot Administrative Management Bureau, Ministry of public Management, Home affairs, Post and Telecommunications

15 CRYPTREC 2001

Sadao Okumura Communications Division, Ministry of Foreign Affairs Yoshitaka Toui Business Affairs and Information Policy Bureau, Ministry of Economy, Trade and Industry (Until May, 2001) Hidetoshi Ohno Business Affairs and Information Policy Bureau, Ministry of Economy, Trade and Industry Mondo Yamamoto Business Affairs and Information Policy Bureau, Ministry of Economy, Trade and Industry Yuji Tanabe Business Affairs and Information Policy Bureau, Ministry of Economy, Trade and Industry Noboru M achida Industrial Technology Environment Bureau, Ministry of Economy, Trade and Industry Tatsuo Kido Industrial Technology Environment Bureau, Ministry of Economy, Trade and Industry Masato Katsumata Industrial Technology Environment Bureau, Ministry of Economy, Trade and Industry Taro Fukazawa Industrial Technology Environment Bureau, Ministry of Economy, Trade and Industry Osamu Takizawa Communication Research Laboratory

Secretariat

Information-technology Security center, Information–technology Promotion Agency, Japan. Masahiko Kobayashi (Until June, 2001), Osamu Naito, Hideharu Tokano, Kazuhiro Amijima, Takashi Kurokawa, Junji Shikata, Masaki Takeda, Yasuhiro Takeya, Kimiaki Tanaka, Hidema Tanaka、Ken’ichi Yada、Atsuhiro Yamagishi, Kyouichi Kurokawa, Akihiko Nakazawa Telecommunications Advancement Organization of Japan Kaoru Suzuki, Kazuharu Yamada, Kazumaro Aoki, Shigeru Amano, Yasushi Kasai, Kayoko Nakajima,Akihiro Yamamura

16 CRYPTREC 2001

2 Evaluation of public key cryptographic techniques

2.1 Target of Evaluation and Evaluation Method

2.1.1 Evaluated Cryptographic Techniques

The cryptographic techniques targeted for evaluation in the year 2001 are classified into the following three categories:

1. Submitted cryptographic techniques (newly submitted and continuously evaluated techniques) ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification), ECDSA in SEC1, EPOC-2, RSA-OAEP, RSA-PSS, HIME(R), OK-ECDSA, NTRU, OK-ECDH, PSEC-KEM 2. Cryptographic techniques listed in the Guideline on the Law concerning Electronic Signatures and Certification *1 DSA, ECDSA (ANSI X9.62), ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification) RSA signature (PKCS#1v1.5 *2) 3. Cryptographic techniques under observation ECIES in SEC1, DH, ECDH in SEC1

In 2001, screening evaluations were made of newly submitted cryptographic techniques. In addition, of cryptographic techniques that were the target of full evaluation in 2000, further evaluation was made of those with which CRYPTREC Evaluation Committee decided to continue the review depending on the result of the previous year, on condition that the applicants had the intention of being given further assessment and that the procurement was possible. For the former, the necessary condition was that they had the characteristics (on security or implementability) equal to or higher than the cryptographic techniques evaluated in detail in 2000. For the latter, the evaluation was focused on the items that were assumed to require further assessment based on the result of full evaluation of 2000.

2.1.2 Evaluation Policy

Cryptographic techniques should have the following basic characteristics to be used for e-Government: the cipher in concrete form with specific parameter designation is secure at present with little possibility of becoming insecure, and consensus is obtained that it will continue to be effective over a decade. Empirical knowledge that the technique has a good track record with no particular security problems will help build

*1 Refer to section 1.1 (a) and (b). *2 Since this method is specified in standard RSA PKCS#1v1.5 and taken up by standard RSA PKCS#1v2.0 or later, it is described as RSA-PKCS#1v1.5 in this report.

17 CRYPTREC 2001

such consensus. However, it is effective to use the concept of provable security in eliminating ambiguous points as much as possible in evaluating the security.

Evaluation was made under the following policies this year.

1. With regard to public key cryptographic techniques that have a firm track record of use and evaluation over relatively long period of time, and whose specifications cannot be changed easily from the viewpoint of interoperability, provable security may not necessarily be presented. 2. With regard to new public key cryptographic techniques that have little track record of use, provable security must be presented, since its specifications can be defined apart from existing cryptographic techniques. 3. Until the deadline of application, the end of September 2001, there may be a case where cryptographic techniques submitted in 2000 with specification change may be accepted for evaluation, but the target of evaluation in 2001 are the ones submitted during the application period.

It should be noted that provable security referred to here does not mean that the security of a cipher has been proved. In this chapter, the expression "has provable security under a certain assumption," refers to the following: The expression that a certain public key cipher has provable security means that if there is an attack against a certain cipher or its idealized cipher, thus threatening the security to be maintained by that cipher, it can be proved that, under a certain assumption, a method of solving another mathematical problem with lower number of computations can be derived. Note that an idealized cipher of a certain cipher means a virtual cipher that is identical to the original cipher except that the auxiliary function such as a hash function used by that cryptographic scheme is replaced with a virtual one (such as a random function). The expression "under a certain assumption" is used because there is a difference in the target of attacks (whatever the cipher itself or an idealized cipher), and a difference of type, computational difficulty of mathematical problems, security in question, type of attacks, and preconditions, thus affecting the reliability of cipher security and bringing about the diversity of reliabilities.

As far as the proof of provable security itself is correct, there is never a case where a certain cipher with provable security will lose it with time. However, the estimated the computational complexity of a mathematical problem changes depending on the development of theoretical concept or change of technological environment. Therefore, even if a cipher has provable security under a certain assumption, and the assumption is considered to be satisfied at present, the cipher may change into the one that is not secure enough in the future. Moreover, if it has not been proved that a certain cipher has provable security at present, it does not necessarily mean that it is not secure enough. There may be a case where a certain cipher has a track record of use and security problems have not been found with it, yet with the present authentication techniques it cannot be expressed in terms of provable security.

18 CRYPTREC 2001

2.1.3 Evaluation Method

Evaluation is classified into screening evaluation, full evaluation, and related investigation, depending on the type of ciphers to be evaluated. Public-key Cryptography Subcommittee consigned the evaluations to researchers at home and abroad, and reviewed and summarized the result of the evaluations.

2.1.3.1 Screening evaluation

Screening evaluations were made according to the submitted documents to judge whether detailed investigation should be made. Evaluation items are shown below.

• Check to make sure that all the information required for full evaluation (such as completeness of description, theoretical consistency or completeness of described content) are available • Check of defects that can be detected easily by reading the document (such as a defect of decryption) • Check of the contents and validity of submitted cryptographic technique specifications and self-evaluation report

One of the characteristics of the evaluations made in 2001 is that it expected to obtain techniques with the characteristics equivalent to or higher than the cryptographic techniques that were evaluated in detail in 2000 (in terms of security and implementability). With regard to PSEC-KEM, since major specification change had been made with it, it was regarded as a newly submitted technique. Screening evaluations were commissioned to cryptography researchers at home and abroad. (See Table 2.1.)

Table 2.1: Number of requests for external screening evaluation

Method of evaluation Target of Number of overseas Number of domestic Total evaluation evaluations evaluations Screening evaluation OK-ECDSA — 3 3 NTRU — 3 3 HIME (R) — 3 3 OK-ECDH — 3 3 PSEC-KEM 1 2 3

2.1.3.2 Full evaluation

Only security evaluation was made in 2001. One of the features of evaluation in 2001 was that with regard to the cryptosystems already evaluated in 2000, only the items requiring further review were the focus of evaluation. Security evaluations were consigned to researchers of cryptography at home and abroad (see Table 2.2). Implementability evaluations were not made this year, because the majority of the cryptosystems targeted for evaluations were already assessed in 2000, or seemed to have a firm track record.

19 CRYPTREC 2001

Table 2.2 Number external full evaluations

Method of Target of evaluation Number of Number of Total evaluation overseas domestic evaluations evaluations Full Integer factoring problem (experiment) — 1 1 evaluation Integer factoring problem (investigation) — 1 1 (difficulty of number Integer factoring problem in specific form 3 1 4 theoretic problems) Discrete logarithm problem 2 1 3 Elliptic curve discrete logarithm problem 2 — 2 Full EPOC-2 2 2 4 evaluation RSA-OAEP, RSA-PSS 2 2 4 (scheme) ESIGN 3 1 4 DSA 3 2 5 ECDSA 3 1 4 n Items of full evaluation: The security of each cryptographic technique was evaluated in terms of difficulty of arithmetic problems and schemes, with focus mainly fallen on the following points.

• Security evaluation items regarding the difficulty of arithmetic problems i) Factorization problem - Investigation of known algorithms and comparison of their efficiency - Comparison between pq type and pdq type (d ³ 2) ii) Discrete logarithm problem - Investigation of known algorithms and comparison of their efficiency iii) Elliptic curve discrete logarithm problem - Investigation of known algorithms and comparison of their efficiency - Investigation of several restricted class of curves (such as Koblitz curve) • Security evaluation items regard ing cryptographic schemes i) DSA - Security evaluation of primitives and schemes - given by FIPS186-2 Appendix 3 ii) ECDSA - Provable security of existential unforgeability in a generic group model - Security evaluation of Koblitz curve iii) ESIGN - Adequacy of the size of recommended parameters - Approximate e-th root problem

20 CRYPTREC 2001

iv) RSA - Security evaluation of RSA signatures - Provable security of RSA-PSS, RSA-OAEP - Manger’s attack against RSA-OAEP v) EPOC-2 - Evaluation of conversions - Adequacy of the selection of recommended parameters

2.1.3.3 Related investigations

In order to clarify the requirements of cryptographic techniques for e-Government used by the government, we received a request for investigation from the Cryptographic Technique Investigation Committee. Public-Key Cryptography Subcommittee evaluated RSA (1024-and 2048-bit) and investigated SSL/TLS protocols. The evaluations were consigned to researchers at home with due consideration given to the following points (see Table 2.3).

• With regard to signature schemes or key agreement using RSA, the security of attacks taking advantage of protocol specifications and operations • Known security holes (including the one generated by implementation), countermeasures to be taken, and cautions in operation • Difference between SSL 3.0 and TLS1.0, and details of TLS1.0 revision project Refer to Chapter 6 for the result of evaluations.

Table 2.3 Number of requests for ext ernal investigations

Method of Target of evaluation Number of Number of Total evaluation overseas domestic evaluations evaluations Related Vulnerability of RSA, Investigation of — 1 1 evaluation protocols — 2 2 (SSL/TSL)

2.2 Evaluation result

2.2.1 Outline of evaluation result

Public key cryptographic techniques evaluated in 2001 can be classified in Table 2.4 depending on the functions and associated number theoretic problems.

21 CRYPTREC 2001

Table 2.4 Evaluation result of public key cryptographic techniques

Integer factoring problem (Elliptic curve) discrete logarithm problem problem Signature ESIGN (2) DSA (1) RSA signature (1) ECDSA (1) RSA-PPS (1) ECDSA in SEC1 (1) OK-ECDSA (7) Confidentiality EPOC-2 (4) HIME (R) (5) ECIES in SEC1 (3) NTRU (7) RSA-OAEP (1) Key agreement DH (1) ECDH in SEC1 (1) OK-ECDH (7) PSEC-KEM (6)

Evaluations were made according to the policy shown in section 2.1.2, and the following results from (1) to (7) were obtained. In Table 2.4, the evaluation result is shown at the end of the name of each cryptosystem.

(1) It is considered that RSA signature (RSA-PKCS#1v.1.5), RSA-PSS, RSA-OAEP, DSA, ECDSA (ANSI X9.62), ECDSA in SEC1, DH, ECDH in SEC1, which are targets of full or specific evaluations, present no problem if used for e-Government. Note, however, that a proper parameter should be selected for use. (2) It was revealed that the signature scheme ESIGN, which is a target of a specific evaluation and listed in the Guideline on the Law concerning Electronic Signatures and Certification, contains parameters with which signatures can be forged with non-negligible if used with a certain parameter the recommended by the submitter. Therefore, it is not recommended to use ESIGN for e-Government without making full evaluations. (3) With regard to ECIES in SEC1, one of the cryptosystems that has been monitored, a doubt about the security emerged. Therefore, it is not recommended to use it for e-Government without making full evaluations. (4) EPOC-2 (of specifications targeted for evaluations of CRYPTREC 2001) is a new cryptosystem requiring further evaluations. Full evaluations revealed that it has insufficiency in the argument of provable security described in its self-evaluation report. Therefore, it is not recommended to use EPOC-2 for e-Government. (5) With regard to HIME(R) targeted for screening evaluations, there is some doubt in the proof of provable security described in its self-evaluation report. Judgment cannot be made whether it can be used for e-Government without making full evaluations.

22 CRYPTREC 2001

(6) PSEC-KEM targeted for screening evaluations is supposed to have provable security as a mechanism. However, since the key encapsulation mechanism is a relatively new technique, further review is required before using it for e-Government. (7) NTRU is a new cryptosystem that is a target of screening evaluations, but the proof of security is not given in its self-evaluation report. OK-ECDSA is a new cryptosystem that is also a target of screening evaluations, and its provable security is the same as ECDSA. OK-ECDH is a new cryptosystem that is a target of screening evaluation, but its provable security is the same as ECDH. The resistance against side channel attacks of OK-ECDSA and OK-ECDH cannot be fully verified only by the contents described in their self-evaluation reports. Therefore, it is not recommended to use those three cryptosystems for e-Government.

2.2.2 General Evaluation of the Difficulty of Number-Theoretic Problems

2.2.2.1 Integer factoring problem

With regard to the integer factoring problem, a composite number n is supposed to be secure as of 2001 if n = pq with |p| = || and |n| ³ 1024, or if n = p2q with |p| = |q| and |n| ³ 1024. Prospects on the difficulty of the integer factoring problem are described in detail in section 2.3.1.3.

2.2.2.2 Discrete logarithm problem

With regard to the discrete logarithm problem of a subgroup (of order q) of a prime field p, it is considered to be secure at present time if |p| ³ 1024 and |q| ³ 160. Prospects on the security of the discrete logarithm problem are described in detail in 2.3.2.3.

2.2.2.3 Elliptic curve discrete logarithm problem

With regard to the elliptic curve discrete logarithm problem, it is considered to be secure enough at the present time, if the order of a group (more precisely the order of the base point) has a prime factor of 160 bits or longer, except for some special elliptic curves. Prospects on the security of the elliptic curve discrete logarithm problem are described in 2.3.3.4.

2.2.3 Overall Judgment of Cryptographic Techniques that were the Target of Full evaluation

2.2.3.1 DSA (Signature)

DSA depends on the difficulty of the discrete logarithm problem on the . Provable security has not

23 CRYPTREC 2001

been proved. DSA, which was proposed and standardized by NIST (National Institute of Standards and Technology), is one of the signature schemes that is listed in the Guideline on the Law concerning Electronic Signatures and Certification. A doubt on pseudorandom number generation in Appendix 3 of FIPS 186-2 has been presented, so it is recommended to follow the procedure of pseudorandom number generation shown in Change Notice of FIPS 186-2 presented by NIST in October 2001. Although the size of parameter p can be selected in the original DSA specification, we strongly recommended to select 1024 bits from the viewpoint of security. Note that NIST develops the new specification in order to make larger size parameters to be selected.

2.2.3.2 ECDSA (Signature) n ECDSA (ANSI X9.62): This is a digital signature scheme, and its security depends on the difficulty of the elliptic curve discrete logarithm problem. Provable security has been verified in a specific model, but the adequacy of the model has not been clarified. As of 2001, problems that may threaten its security greatly have not been reported. In the Guideline on the Law concerning Electronic Signatures and Certification, ECDSA with the parameter of 160 bits or longer is listed. With regard to the pseudorandom number generator, the procedure listed in FIPS186-2 is specified, but since a problem was pointed out in DSA, which is the original form of ECDSA, it is recommended to pay attention to the development of the pseudorandom number generator described by NIST in FIPS186-2 Change Notice. n ECDSA in SEC1: This is a digital signature scheme, and its security depends on the difficulty of the elliptic curve discrete logarithm problem. Provable security has been verified in a specific model, but the adequacy of the model has not been clarified. As of 2001, problems that may threaten its security greatly have not been reported. Specific elliptic curves recommended for use are listed in SEC2. No problems on these elliptic curves have been pointed out. Koblitz curve (or anomalous binary curve) included in SEC2 because of its high-speed processing and its history of usage is an elliptic curve in a restricted class, so there is a possibility that attacks specifically against the class may emerge. Attention should be paid to the possibility.

2.2.3.3 ESIGN (Signature)

The security of the primitive is based on the difficulty of the n = p2q type factorization problem and the e-th root approximation problem. Signature generation speed of ESIGN is faster than RSA signature. ESIGN signature has multiple specifications. Of those specifications, ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification), which is one of the signature systems listed in the Guideline on the Law concerning Electronic Signatures and Certification, was evaluated as shown below. n ESIGN (specified by the Guideline on Law concerning Electronic Signatures and Certification):

24 CRYPTREC 2001

Provable security is not verified. A part of security parameters specified in the Guideline on the Law concerning Electronic Signatures and Certification (when SHA-1 is used, for example, |n| = 2048 and e = 8) may invite with the probability that cannot be neglected. Of MD5 and SHA -1, which were designated as hash functions, the use of MD5 is not recommended. Revision of the Guideline on the Law concerning Electronic Signatures and Certification should be considered.

2.2.3.4 RSA (Signature)

The security of a primitive depends on the difficulty of n = pq type factorization problem. RSA has a track record of use over a long period of time, and its security has been evaluated from various points of view. It is considered experientially secure. Signatures using RSA primitives have various specifications. Evaluations were made on RSA-PKCS#1v1.5 and RSA-PSS (IEEE P1363a version). n RSA-PKCS#1v1.5: RSA-PKCS#1v1.5 does not have provable security. RSA-PKCS#1v1.5 is one of the signature systems listed in the Guideline on Law concerning Electronic Signatures and Certification. No problems on its security have so far been reported. However, since forgery of signature on encoding of many signature schemes has been presented, security of the encoding method adopted in this system must be reviewed further. In the Law concerning Electronic Signatures and Certification, MD5 and SHA -1 are specified as hash functions, but the use of MD5 is not recommended as is pointed out in CRYPTREC Report 2000. On the other hand, there is an opinion that points out superiority of RSA-PSS, because it presents the similar efficiency and its security has been verified. n RSA-PSS (IEEE P1363a version): RSA-PSS (IEEE P1363a version) has provable security in the model. One of its features is that it can prove tighter reduction relations than other signature schemes (such as universal hash method). Since there is a slight difference between the method submitted to CRYPTREC for evaluation and the one that was proved in the paper, it is necessary to assess the relation of corresponding parameters and select design parameters. It is required to study the possibility of specifying RSA-PSS in the Guideline on the Law concerning Electronic Signatures and Certification.

2.2.3.5 RSA (Confidentiality)

The security of a primitive depends on the difficulty of n = pq type factorization problem. RSA has a track record of use over a long period of time, and its security has been evaluated from various points of view. Therefore, it is considered to be secure enough. n RSA-OAEP : RSA-OAEP has provable security in the random oracle model. Since the indication by Shoup in 2000, its security has been discussed. As a result, its security has been verified even though the security reduction efficiency has been reduced. Since there is a slight difference between the method

25 CRYPTREC 2001

submitted to CRYPTREC for evaluation and the one that was proved in the paper, it is required to assess the relation of corresponding parameters and select design parameters.

2.2.3.6 EPOC-2 (Confidentiality)

EPOC-2 submitted to CRYPTREC for evaluation in 2001 has specifications in which the encoding method was defined precisely in CRYPTREC in 2000. Its security depends on the difficulty of n = p2q type factorization problem. The detailed investigation revealed that the argument of provable security given in the self-evaluation report had some inadequacy. It must be noted that the difficulty of n = p2q type factorization problem differs from that of n = pq type factorization problem. Improper use of a with symmetric key cryptosystem may compromise security, so attention should be paid to modes of operation of the block cipher.

2.2.4 Overall Judgment of Cryptographic Techniques under Observation

2.2.4.1 ECIES in SEC1 (Confidentiality)

ECIES in SEC1 was submitted to CRYPTREC as ECAES in SEC1 in 2000. In 2001 the name of cryptographic technique submitted was changed to ECIES in SEC1. The security of ECIES in SEC1 depends on the difficulty of the elliptic curve discrete logarithm problem. A new argument on security came up recently, so further security evaluation must be made.

2.2.4.2 DH (Key agreement)

DH’s security depends on the difficulty of the discrete logarithm problem. Since Diffie-Hellman method has many variations of protocols, each protocol must be evaluated individually. (See: Examples of actually used protocols: RFC2631, ISO 11770-3, Oakley, PGP) No problems have so far been pointed out against passive attacks (the attacks that do not affect the data transmitted for key agreement), but when using a basic scheme, attention should be paid to at least the following three points against active attacks (the attacks that may affect the transmitted data for key agreement).

• A measure to secure the bond between the public key and the Entity must be assured. • When using a session key agreement system (assuming updating), the public key to be exchanged should be a temporary one. • The , which makes the shared key indistinguishable from random bit strings, must be used.

26 CRYPTREC 2001

2.2.4.3 ECDH in SEC1 (Key agreement)

ECDH in SEC1 was submitted to CRYPTREC as ECDHS in SEC1 in 2000. In 2001 the name of cryptographic technique submitted was changed to ECDH in SEC1. The security of ECDH in SEC1 depends on the difficulty of the elliptic curve discrete logarithm problem. No major problems have so far been pointed out on passive attacks, but attention should be paid at least to the following two points against active attacks.

• A measure to secure the bond between a public key and the Entity must be assured. • When using a session key agreement system (assuming updating), the public key to be exchanged should be a temporary one.

With regard to elliptic curves specifically presented by SEC2, it has been proved that existing efficient attacks cannot be applied to any of those curves. Koblitz curve, which is included in SEC2 because of its high-speed processing and the firm track record of use, is an elliptic curve in a restricted class, so there is a possibility that attacks specifically against the class may emerge. Attention should be paid to the possibility.

2.2.5 Overall Judgment of Cryptosystems that were Targets of Screening Evaluations in 2001

2.2.5.1 OK-ECDSA (Signature)

OK-ECDSA is a digital signature scheme, and one of its features is that it uses Montgomery elliptic curve. Its security depends on the difficulty of the discrete logarithm problem on Montgomery elliptic curve. Provable security has been verified in a specific model, but the adequacy of the model has not been clarified. Resistance against side-channel attacks cannot be checked only with the description of the self-evaluation report.

2.2.5.2 NTRU (Confidentiality)

Its security is based on the difficulty of the shortest vector problem of a lattice. Its key characteristic is that its performance is faster than that of other existing public key cryptosystems. The applicant insists that:

(1) It becomes IND-CPA by random of the message. (2) IND-CCA2 can be achieved by applying Fujisaki-Okamoto conversion to IND-CPA.

However, since the proof of (1) has not been given, provable security has not been verified. There is also a concern about the particularity of the problem on which its security is based.

27 CRYPTREC 2001

2.2.5.3 HIME(R) (Confidentiality)

HIME(R) is a public key system for confidentiality, and its security depends on the difficulty of the factorization problem in a specific form. The argument on security in the self-evaluation report is questionable, so it is not recommended to use it for e-Government without making full evaluations. There is a possibility that its performance is faster than that of RSA-OAEP.

2.2.5.4 OK-ECDH (Key agreement)

OK-ECDH is a public key system for key agreement, and one of its features is that it uses Montgomery elliptic curve. Its security depends on the difficulty of the discrete logarithm problem on Montgomery elliptic curve. Problems on passive attacks have not been pointed out, but there is an indication that it is vulnerable to active attacks. The resistance against side-channel attacks cannot be fully checked by reviewing the description of the self-evaluation report only.

2.2.5.5 PSEC-KEM (Key agreement)

PSEC-KEM is a key encapsulation machanism (KEM) based on a public key cryptosystem. Its security is based on the difficulty of the elliptic curve discrete logarithm problem. In the present situation where a key encapsulation mechanism has not had a fixed evaluation result as a cryptographic method for e-Government, further study is required to use PSEC-KEM for e-Government, even though it is considered to have provable security.

2.3 Evaluation of the Difficulty of Number-Theoretic Problems

2.3.1 Integer Factoring Problem

Full evaluation was made on the current status of the difficulty of integer factoring problem. This was conducted in order to give a common evaluation criteria for the cryptographic schemes and their underlying primitives of which security depends on the intractability of integer factoring problem. According to the evaluation results, the most powerful factorization algorithms at present, and the size of secure modulus and its prospects are summarized in this section. Some issues that may affect the difficulty of the problem are referred to at the end.

2.3.1.1 Powerful Algorithms

In order to review the difficulty of factoring moduli that are used in cryptographic primitives, a composite number to be factored is restricted to a form of n = prq (p, q: prime numbers, p < q, r ³ 1). When r = 1, it becomes a modulus used in RSA for example, and when r ³ 2, it becomes a modulus used in ESIGN or the like.

28 CRYPTREC 2001

There are some known algorithms that are used to solve the factorization problem. They are roughly classified into two categories depending on the major element to dominate the running time. One category includes algorithms of which running time is estimated depending on |p|, the size of the minimum prime factor of n, and the other includes those of which running time depends only on |n|, the size of n. The fastest one in the former category is the elliptic curve method (ECM)[5], and the fastest one in the latter is the general number field sieve method (GNFS)[6]. Both of them require subexponential time.

Integer factoring algorithms Elliptic curve method (ECM) General number field sieve method (GNFS) Input n prq, p

Practical |p| £ qe |n| £ qg execution condition (qe = 183 as of 2001) (qg = 512 as of 2001)

"Practical execution condition" in the above table is defined as the condition where factorization can be performed within practical time with the use of the algorithm and resources. Since it is defined by an ambiguous as "practical", and available computing resources are not limited, qe and qg are naturally non-standardized uncertain values. However, it is not very unnatural to determine them according to successful examples of factorization. In this sense, it is considered that qe = 183 (reference [8]), and qg = *3 512 (reference [3]) . Prospects of qe and qg will be discussed later.

ECM and GNFS are evolving. In fact researches for speeding the running time have been conducted without changing the basic strategy of the algorithms both in the case of ECM and GNFS (refer to [9] for ECM, and [4] for GNFS). It should be noted that those algorithms referred to here are as of 2001.

The lattice factoring method (LFM)[1] is an algorithm specialized for modulus n = prq. If |p| = |q| and r is of order log2p, this algorithm runs in time polynomial in |n|. This means that the modulus is easily factored. However, if r is a small constant (for example r = 1, 2, or 3), it takes exponential time, and therefore slower than ECM or GNFS.

*3 According to the announcement on the Internet on January 21, 2002, a modulus n = pq with |n| = 524 (i.e. 158 in decimal digits) was factored with GNFS. F. Bahr, J. Franke, T. Kleinjung, "Factorization of 158-digit cofactor of 2953 + 1," http://www.crypto-world.com/announcements/c158.txt

29 CRYPTREC 2001

2.3.1.2 The size of a secure modulus

"The size of a secure modulus at a certain time" is defined as the presumed size of modulus n that cannot be practically factored even if one exploits the fastest algorithm and computing resources available at the time.

As is seen in the above description on powerful factoring algorithms, in order to secure modulus n = prq (p < q, r ³ 1), all of the following conditions ((1), (2) and (3)) must be satisfied.

(1) r must be a small constant.

(2) |p| >> qe

(3) |n| >> qg

The purpose of condition (1) is to avoid the attacks by LFM. The purpose of condition (2) is to avoid the attacks by ECM, and that of condition (3) is to avoid the attacks by GNFS.

However, qe and qg are not standardized. Even if they are standardized, unnecessarily large |p| and |n| would produce undesirable side effects on the performance of the scheme (for example, time for encryption, decryption, signature generation, and signature verification). Therefore, it is necessary to assess the practically secure range of |p| and |n|, with the values of qe and qg in 2001 taken into consideration.

In full evaluations made this year, four of the five evaluators accepted the argument that if |p| = |q|, both of the following (a) and (b) can hold as of 2001. (One evaluator did not clearly refer to the specific range that is considered to be secure.)

(a) As of 2001, n is supposed to be secure if n = pq, |p| = |q| and |n| ³ 1024. (b) As of 2001, n is supposed to b e secure if n = p2q, |p| = |q| and |n| ³ 1024.

Note that some important supplementary comments on details were given. One of them was on the margin.

Intuitively, the notion of margin designates the difference of the size that determines the practical execution condition of algorithms (such as qe and qg) and the actual size (such as |p| and |n|). The reason for taking the margin into consideration is as follows: Assume that the margin of a modulus is small. Under this assumption, if either algorithms or available computing resources are improved dramatically, and hence qe and qg increase, then it becomes more likely that the modulus of small margin is factored. The margin in question was the margin against ECM. For example, for n = pq and n = n2q, if both satisfy |n| = 1024, the size of the minimum prime factor |p| will differ, and it is clear that the margin is smaller for n = p2q than for n = pq. One of the evaluators noticed that, concerning the margin against ECM, the modulus n of the form n = p2q should satisfy |n| = 1280 if this modulus is expected to have a margin equivalent to that for n = pq with |n| = 1024. (The evaluator also claimed that a modulus n is not secure if n = p3q and |n| = 1024.) Another evaluator insisted that |n| of n = p2q should be even larger in order to achieve the margin against ECM equivalent to that for n = pq with |n| = 1024. Although the evaluation of the margin is important to assess the size of secure modulus, such arguments above do not disprove the assertions (a) and (b) as of 2001.

30 CRYPTREC 2001

When reviewing the lifetime of security of each scheme based on the integer factoring problem, it is important to estimate the value of qe and qg in the future. Such estimate cannot be made easily, but an equation to estimate what sort of modulus will be factored by what year is presented in reference [2]. The equation was introduced by considering the Moore's law and extrapolating the record of the size of modulus factored in the past. According to the equation, for n = pq and n = p2q, if |n| = 1024 and |p| = |q|, computing the minimum prime factor of the former (512 bits) will become practical in a year around 2048, and computing the minimum prime factor of the latter (342 bits) will become practical in a year around 2027. For n of any form, if |n| = 1024, factoring n by GNFS will become practical in 2018. Therefore, under the assumption that "the estimate of reference [2] is correct", if |n| is set to be 1024 that is the lower bound in the assertions (a) and (b), it will work as a modulus that cannot be practically factored for over 10 years from 2002, even though it is unavoidable for the margin to decrease with time.

On the other hand, reference [7] presents the lower bound of |n| recommended at that time (year). While reference [2] described above indicates |n| that is estimated to be factored at that time, reference [7] presents the recommended lower bound and estimates the margin to achieve sufficient security at that time. Consequently, the values of reference [7] naturally becomes larger than those of reference [2]. Note that in reference [7], the estimation is based on their own assumption which is a slight extension of the Moore's law.

2.3.1.3 Supplemental remarks

Generally speaking, the existing algorithms have the possibility of being studied and improved, thus the two fastest algorithms, the elliptic curve method (ECM) and the general number field sieve method (GNFS), could offer higher performance. The lattice method (LFM), on the other hand, is capable of factoring in polynomial time, and in view of the fact that it is not long since it was invented, its potentiality is considered to be relatively large. It must be noted that in consideration of these above, the assertions (a) and (b) hold “as of 2001”. It should also be noted that as described in the argument of the margin, for n = pq and n = p2q, if |p| = |q| and |n| = 1024, then n = pq and n = p2q do not share the same margin against ECM.

Some of the items that may affect the difficulty of the integer factoring problem are listed below.

• When quantum reaches the level of practical use, the integer factoring problem will be solved efficiently, thereby terminating the role of the integer factoring problem as a . • It is necessary to pay attention to efficient algorithms for number-theoretic problems that have reductions with the integer factoring problem. For example, the problem to factor n = prq (r > 1) reduces in polynomial time to the problem of extracting the squarefree part of a composite number. The squarefree part problem is a problem that on input n, outputs {u, v} such that n = u2v and v is

31 CRYPTREC 2001

squarefree. (Integer v is said to be squarefree if v does not have factors of the form a2 with a > 1.) If an efficient algorithm for this is discovered, factoring n = prq (r > 1) will be computed easily. However, it is not known that the problem to factor n = pq (r = 1) reduces to the squarefree part problem. • In the structural complexity theory, if a dramatic result concerning the inclusion relationships among the computational complexity classes is proved, the intractability of many number-theoretic problems as well as the integer factoring problem will be seriously affected. • The size of a modulus that can be practically factored may be affected by the time when Moore's law will be broken down. It is considered that the lifetime of Moore's law is extended over to 2005 or later. However, if it is broken down, at least the threat by speeding up single CPU will be relieved, and the size that can be factored may stop increasing. Even if it happens, however, there still remains the threat of the factorization by massively distributed computing by enormous number of CPUs.

Reference s [1] D. Boneh, G. Durfee, N. Howgrave-Graham, "Factorillg N = pr q for large r," Proc. Crypto'99, LNCS l666, Springer-Verlag, pp.326-337, 1999. [2] R. P. Brent, "Recent progress and prospects for integer factorisation algorithms," Proc. COCOON 2000, LNCS 1858, Springer-Verlag, pp.3-22, 2000. [3] S. Cavallar, W. Lioen, H. te Riele, B. Dodson, A. K. Lenstra, P. L. Montgomery, B. Murphy, K. Aardal, G. Guillerm, P. Leyland, J. Marchand, F. Morain, A. Muffett, C. C. Putnam, P. Zimmerman, "Factorization of a 512-bit RSA modulus," Report MAS-R0007, CWI, Feb. 29, 2000. [4] D. Coppersmith, "Modifications to the number field sieve, " J. Cryptology, vo1.6, pp.169-180, 1993. [5] H. W. Lenstra, Jr., "Factoring integers with elliptic curves," Annals of , vol.126, pp.649-673, 1987. [6] A. K. Lenstra, H. W. Lenstra, Jr., M. S. Manasse, J. M. Pollard, "the number field sieve," Proc. 22nd STOC, pp.564-572, 1990. [7] A. K. Lenstra, E. Verheul, "Selecting cryptographic key sizes," Proc. PKC 2000, LNCS 1751, Springer-Verlag, pp.446-465, 2000. [8] I. Miyamoto, Report on ECM-net, Oct. 2001. http : //www. loria. fr/~zimmerma/records/ecmet. html [9] E. Okamoto, R. Peralta, "Faster factoring of integers of a special form," IEICE Trans. Fundamentals, vo1.E79-A, pp.489-493, 1996. 2.3.2 Discrete Logarithm Problem

In order to make a full evaluation of cryptographic schemes, whose primitives’ security is based on the difficulty of the discrete logarithm problem (hereafter denoted by DLP) of a finite group, a full evaluation

32 CRYPTREC 2001

was made as to the current situation of DLP. Based on the result of the evaluation, the typical attacking algorithms, the that is considered to be practically secure, and its prospects are summarized in this section. The factors that may affect the difficulty of the problem itself will be described at the end.

2.3.2.1 Definition of the discrete logarithm problem

Let G be a finite group. When the element of G, g, and u= gx (xÎ ) are given, discrete logarithm problem (DLP) is defined as a problem to find the value of x. When used in cryptographic application, multiplicative group of a finite field or the group of rational points of an elliptic curve defined over a finite field are often taken as G. Elliptic curve discrete logarithm problem (ECDLP) will be discussed in the next section. This section mainly discusses the DLP of the multiplicative group of a finite field.

2.3.2.2 Attacks

The methods of attacking DLP are roughly classified into two groups: one is the general method that can be applied to general finite fields, and the other is the index calculus method [6] that uses the characteristics of the multiplicative group of a finite field. The following tables show the summary of known attacks of each group and their complexities. The complexity of the general method is exponential time order of group order bit length, while the complexity of the index calculus method is subexponential time order. Therefore, the speed of the index calculus method is faster than that of the general method.

General method

If N is the order of a group, the complexity of the general method depends on N. Of the methods listed in the following table, Pollard’s method can be parallelized. So if mPC’s are used, the complexity required for solving DLP can be estimated as pN / 2 / m [7]. See the next section for the record of breaking ECDLP.

Name of the attack Complexity Reference Exhaustive search method O (N) Pohlig-Hellman method reduced to DLP on prime order subgroups [8] Baby-Step/Giant-Step method [10] ON()

Pollard’s method pN / 2 [9]

Index calculus method

The index calculus method is roughly classified into two groups. The one is the number field sieve method that can be applied to the multiplicative group of a prime field, and the other is the function field sieve

33 CRYPTREC 2001

method that can be applied to the multiplicative group of an extension field with small characteristics. The table below shows the summary of the complexity of each method and the record of breaking DLP as of b(log q)a(log log q)1-a 2001. q in the table indicates the order of the finite field, and Lq[a,b] indicates Lq[a,b] = e .

There are some reports that DLP in 2 607 was solved in 2002 [13] [12].

Name of the attack Complexity Record of Reference break General number field sieve method Lq[1/3,c+o(1)],c=(64/9) 1/3 =1.9229... 120 digits [3, 11] Special number field sieve method Lq[1/3,c+o(1)],c=1.5262... 129 digits [14,11] Function field sieve method Lq[1/3,c+o(1)],c=(32/9) 1/3 2521 [4,1]

2.3.2.3 Secure key size

When adopting cryptographic primitives whose security is based on the difficulty of DLP, the key size must be large enough to make it impractical to solve DLP. In considering the secure key size to be used in the future, it is required to take various factors into consideration, such as the development of computers and solving algorithms. The following are the famous two "predictions" that are often referred to and their concepts.

Brent's prediction equation [2]

This is an equation used to predict the year when an integer factoring problem of certain digits will be solved. It is based on the existing record of solving the integer factoring problem. The year Y when the integer factoring problem of decimal D digits will be solved can be predicted as:

Y = 13.24D1/3 + 1928.6

There is a report that the time required for solving the prime field DLP corresponds to that for solving the 20 bits longer integer factoring problem. Based on this report, the equation to predict the year Y when D-digit prime field DLP will be solved is as follows.

Y = 13.24 (D + 6)1/3 + 1928.6

The year Y can be predicted as follows when the number of bits is 1024, 2048, or 4096.

In the case of the multiplicative group of a finite field of characteristic 2, it is recommended to use longer bit length because the break record shows that the problem with longer digits than the prime field has been solved.

Year Bit length

34 CRYPTREC 2001

2019 1024 2042 2048 2070 4096

Lenstra-Verheul table [5]

Lenstra-Verheul table (hereafter denoted by LV) indicates the key length required for obtaining the strength equivalent to that of DES in 1982 in the given year. Note that whereas Brent's prediction equation presents the key length that can be solved in that year, LV presents the key length with relatively large margin that is considered to be secure in that year.

For the index calculus method ,which is the fastest algorithm against DLP, the bit length of the base field must be taken into consideration. For the schemes that use relatively small order subgroups such as DSA, it must be also taken into consideration that general attacks against subgroups should not be more efficient than the index calculus method. For the schemes that use the subgroup DLP, it is necessary to allow not only the bit length of the base field but also the order of the subgroup to be larger than the value shown in the table. The table below shows the values excerpted from LV table at the interval of every 10 years.

Year Bit length Order of the group 2002 1028 127 2010 1369 138 2020 1881 151 2030 2493 165 2040 3214 179 2050 4047 193

2.3.2.4 Others

The following are the factors that may affect the difficulty of DLP.

• When quantum computers are realized, DLP will be solved effectively, thereby eliminating the role of DLP as a cryptographic primitive. • It should be noted that if some mathematical breakthrough should happen that might allow a solving algorithm of DLP more efficient than the index calculus method to be found, the above prediction may be changed greatly.

References

[1] L. Adleman, A subexponential algorithm for the discrete logarithm problem with applications to cryptography. In ANTS I(1994), L.Adleman and M.-D. Huang, Eds., vol. 877 of Lecture Notes in

35 CRYPTREC 2001

Computer Science. [2] R. P. Brent, “Recent progress and prospects fo r integer factorisation algorithms ”, Proc. COCOON 2000, LNCS 1858, Springer-Verlag, pp.3-22, 2000. [3] A. Joux and R. Lercier, Discrete in GF(p), Announcement on the NMBRTHRY Mailing List, 17. April 2001. [4] A. Joux and R. Lercier, Discrete logarithms in GF(2n), Announcement on the NMBRTHRY Mailing List, 25. September 2001. [5] A. K. Lenstra, E. Verheul, “Selecting cryptographic key sizes ”, Proc. PKC 2000, LNCS 1751, Springer-Verlag, pp.446-465, 2000. http://www.cryptosavvy.com/table.htm [6] K. McCurley, The discrete logarithm problem. In Cryptography and computational number theori, Proc. Symp. Apll. Math(1990), C. Pomerance, Ed., vol.42 of Amer. Math. Soc., pp.49-74. [7] P. van Oorschot and M. Wiener, Parallel collision search with applications to hash functions and discrete logarithms, 2nd ACM Conference on Computer and , 210-218, ACM Press 1994. [8] S. Pohlig and M. Hellman, An improved algorithm for computing logarithms over GF(p) and its cryptographic significance, IEEE Trans. on Infor. Th., 24, 106-110, 1978. [9] J. Pollard, Monte Carlo methods for index computations mod p, Math. Comp., 32, 918-924, 1978. [10] D. Shanks, Class number, a theory of factorization and genera, In Proc. Symp. Pure Math. 20(1971), AMS, Providence, R.I., pp.415-440. [11] O. Schirokauer, Discrete logarithms and local units, Phil. Trans. R. Soc. London A 345(1993), pp.409--423. [12] E. Thomé, Computation of discrete logarithms in GF(2607), In Proc. ASIACRYPT 2001, LN CS 2248, pp. 107-124. [13] E. Thomé, Discrete Logarithms in GF(2607). http://www.lix.polytechnique.fr/Labo/Emmanuel.Thome/announcement/an nouncement.html [14] D. Weber and T. Denny, The solution of mccurleys discrete logarithm challenge, In Advances in Cryptology - Crypto '98, vol. 1462 of LNCS, pp. 458-471.

2.3.3 Elliptic Curve Discrete Logarithm Problem

2.3.3.1 Definition

k Let K = q be a finite field of characteristic p of order q = p . An elliptic curve E on K is a nonsingular plane curve defined by the following form of equation;

2 3 2 Y + a1XY + a3Y = X + a2X + a4X + a6

36 CRYPTREC 2001

with ai’s in K.

Rational points E(K) on E over K consists a group. Let PÎE(K) be a point of order N and Q be an element of a cyclic group generated by P.

Elliptic curve discrete logarithm problem (ECDLP)

Find the integer nÎ[0, N - 1] that satisfies Q = nP for given E, q, P, N and Q.

The above E, q, P, N and Q are called elliptic curve parameters in elliptic curve cryptosystems. The point P is called the base point.

2.3.3.2 Attacks

Attacks against ECDLP are divided into the following two categories. The one is a general method that does not use the characteristics of an elliptic curve itself, and the other is a special method that uses the characteristics of an elliptic curve. Tables below show known general and special attacks respectively, with the conditions to avoid those attacks. "® DLP on xxx" of the item "complexity/resulting problem" in the tables indicates that ECDLPin reduced to DLP on the group xxx.

General method

Name of the attack Complexity/resulting problem Conditions to avoid Reference Exhaustive search O (N) Make N large enough Pohling-Hellman method ® DLP on a prime order subgroup Make N be an almost [1] prime number (Note 1) Baby-Step/Giant-Step method N > 2160 (Note 2) ON()

160 Pollard method pN / 2 (Note 3) N > 2 (Note 2) [2]

Note 1: That N is an almost prime number means that N is the product of a prime number of almost the same size as N and a smaller integer (such as 1, 2 and 4). Note 2: It is considered that Baby-Step/Giant-Step method and Pollard method are impracticable if N > 2160 at the present time.

Note 3: Pollard method is a "Las Vegas" type algorithm, and its evaluation of complexity is the statistical estimate of the number of additions on an elliptic curve required. Pollard method can be parallelized, so if m are used, the number of computations per one can be estimated as pN / 2 / m [3].

Special method

37 CRYPTREC 2001

Suppose N is amostly a prime, and let its maximum prime factor be l .

Name of the attack Complexity/resulting problem Conditions to avoid Reference Automorphism method With m-th order automorphism, (Note 1) [4, 5] Pollard method becomes m faster. Weil/Tate Pairing method ® DLP on the multiplicative group of N qs-1 (1 £ s £ 30) [6, 7] s the extension field q Anomalous curve method ® DLP on the additive group of the p ¹ l [8, 9, 10] prime field p Weil descent method ® DLP on hyperelliptic curves p = 2, k: prime [11] or p ¹ 2 (Note 2) Note 1: It is noted that the automrophism method can use only some special automorphisms such as the complex multiplication of Koblitz curves. The automorphism method reduces the complexity of ECDLP only 5 bits at most for 163 bits elliptic curves. See section 2.4.2 ECDSA for Koblitz curves.

Note 2: Diem [12] recently suggests that even in the case of odd characteristic, when k = [ q : p] = 5, 7, Weil descent method can be possible. When using OEF (Optimal Extension Field), care must be taken.

2.3.3.3 Experimental Results

Certicom has sponsored ECC challenge to promote researches to break ECDLP since 1997.

Escott et al. [13] solved ECCp-97 that is one of the objectives of ECC challenge by using the parallelized Pollard method. ECCp-97 is an elliptic curve of 97-bit order on the prime field. It is reported that to solve ECCp-97, more than 1200 computers were used to perform 2 ´ 1014 times additions on the elliptic curve for the period of 53 days.

Harley et al. [14] solved ECC2K-108 that is one of the objectives of ECC challenge by using the parallelized Pollard method assisted by the automorphism method. ECC2K-108 is a Koblitz curve of 108-bit order with characteristic 2. It was reported that to solve ECC2K-108, approximately 9500 computers were used to perform 2.3 ´ 1015 times additions on the elliptic curve for the period of 4 .

2.3.3.4 Secure group orders

At the present time, the elliptic curve discrete logarithm problem is considered to be secure enough if the order of a group (more precisely the order of the base point) includes a prime factor of 160 bits or longer, except for the special elliptic curves listed in special methods. In order to estimate the secure size of the group order at a certain time in the future, it is required to assess the actual number of computations to

38 CRYPTREC 2001

execute breaking algorithms, the increase of the maximum number of computations that can be executed making the most of Internet resources, and the development of breaking algorithms. It is difficult to calculate the precise numbers of those. The estimate by Lenstra and Verheul [15] is listed below.

Estimate by Lenstra and Verheul [15] of the secure size of the group order

Year Bit length of the group order (no Bit length of the group order (with progress) progress) 2002 135 139 2010 146 160 2020 161 188 2030 176 215 2040 191 244 2050 206 272

The above table shows the bit length of the group order to allow the ECDLP to have the strength in the relevant year that is equivalent to DES in 1982. The values shown as the "bit length of the group order (no progress)" are the ones estimated on the assumption that breaking algorithms themselves will not be improved, while the values shown as the "bit length of the group order (with progress)" are the ones estimated on the assumption that the number of computations required to solve the ECDLP will be improved at the speed of being reduced to one half in 18 months.

References [1] S. Pohlig and M. Hellman, An improved algorithm for computing logarithms over GF(p) and its cryptographic significance, IEEE Trans. on Infor. Th., 24, 106-110, 1978. [2] J. Pollard, Monte Carlo methods for index computations mod p, Math. Comp., 32, 918-924, 1978. [3] P. van Oorschot and M. Wiener, Parallel collision search with applications to hash functions and discrete logarithms, 2nd ACM Conference on Computer and Communications Security, 210-218, ACM Press 1994. [4] R. Gallant, R. Lambert and S. Vanstone, Improving the parallelised Pollard lambda search on binary anomalous curves, Math. Comp., 69, 1699-1705, 2000. [5] M. J. Wiener and R. J. Zuccherato, Faster attacks on elliptic curve cryptosystems, Selected Areas in Cryptography - SAC 1999, Springer-Verlag LNCS 1556, 190-200, 1999. [6] A. Menezes, T. Okamoto and S. Vansone, Reducing elliptic curve logarithms to logarithms in finite fields, IEEE Trans. on Infor. Th., 39, 1639-1646, 1993. [7] G. Frey and H. -G. Rück, A remark concerning m-divisibility and the discrete logarithm in the divisor

39 CRYPTREC 2001

class group of curves, Mathematics of Computation, 62, 865-874, 1994. [8] P. N. Smart, The discrete logarithm problem on elliptic curves of trace one, J. Cryptology 12, 193-196, 1999. [9] T. Satoh and K. Araki, Fermat Quotients and the Polynomial Time Discrete Log Algorithm for Anomalous Elliptic Curves, COMMENTARII MATHEMATICI UNIVERSITATIS SANCTI PAULI, vol. 47, No. 1, 81-92, 1998. [10] I. A. Semaev, Evaluation of discrete logarithms in a group of p-torsion points of an elliptic curves in characteristic p, Math. Comp. 67, 353-356, 1998. [11] P. Gaudry, F. Hess and N. Smart, Constructive and destructive facets of Weil descent on elliptic curves, HP Labs Tech. Report, HPL-2000-10, To appear in J. Cryptology. [12] C. Diem, The GHS-attack in odd characteristic, preprint, 2001. Available at http://www.exp-math.uni-essen.de/~diem/english.html [13] A. Escott, J. Sager, A. Selkirk and D. Tsapakidis, Attacking elliptic curve cryptosystems using the parallel Pollard rho method, CryptoBytes - The Technical Newsletter of RSA Laboratories, volume 4, number 2, Winter 1999, 15-19. Also available at http://www.rsasecurity.com [14] R. Harley, Elliptic Curve Discrete Logarithms: ECC2K-108. http://cristal.inria.fr/~harley/ecdl7/ [15] A. K. Lenstra, E. Verheul, Selecting cryptographic key sizes, Proc. PKC 2000, LNCS 1751, Springer-Verlag, pp.446-465, 2000.

2.4 Evaluation of Individual Ciphers

2.4.1 DSA

2.4.1.1 Technical overview

DSA (Digital Signature Algorithm) is a signature scheme suggested and standardized by NIST (National Institute of Standards and Technology) of the United States [1, 2]. DSA is also one of the signature schemes listed in the Guideline on the Law concerning Electronic Signatures and Certification.

The security of DSA is based on the difficulty of the discrete logarithm problem on the finite field.

2.4.1.2 Technical specifications

Key generation is performed as shown below.

1. Prime number p (2511+64j < p < 2512+64j (j Î {0, 1, ….., 8})) is selected.

40 CRYPTREC 2001

2. Prime number q of 160 bits (2159 < q < 2160) to divide p - 1 is selected. 3. g = h (p-1)/q mod p is calculated. Note that h is an integer which meets the condision 1 < h < p - 1. 4. Random number x (0 < x < q) is generated. 5. y = gx mod p is calculated.

The public key is (p, q, g, y), and the private key is x.

Signature generation Signature generation for M is performed as shown below.

1. Random number k (0 < k < q) is generated. 2. r = (gk mod p) mod q is calculated. 3. s = (k-1 (SHA -1(M) + xr)) mod p is calculated. Note that SHA -1(M) is the result of conversion of plaintext M performed by using Secure Hash A lgorithm specified in FIPS 180-1.

The signature is (M, r, s).

Signature verification Verification for signature (M', r', s') is performed as shown below.

1. w = (s')-1 is calculated. 2. u1 = ((SHA-1(M'))w) mod q is calculated. 3. u2 = ((r')w) mod q is calculated. 4. v = ((g)u1(y)u2 mod p) mod q is calculated. 5. It is checked if v = r'.

Only when v equals to r' in the above procedure, the received signature can be authenticated.

2.4.1.3 Evaluation of security

Random number generation of FIPS 186-2 Appendix 3 FIPS 186-2 Appendix 3 defines pseudorandom number generator G with the output range of (0, 2160) to generate a private key x as shown below.

x = G(t, XVAL) mod q, where t and XVAL are random numbers.

Basically, a private key x should be generated with the same probability in the range of (0, q - 1). However, in the above method, the probability of x to be within the range (0, 2160 - q - 1) becomes twice as high as the probability of x to be within the range (2160 -q, q - 1) through the influence of round trip effect.

41 CRYPTREC 2001

D. Bleichenbacher presented an attack utilizing this problem [3], and in October 2001, NIST modified the procedure of random number generation by adding Change Notice to FIPS 186-2. Although the details of Bleichenbacher's attack have not been disclosed, the use of the random number generated through the modified procedure allows the original problem to be avoided. Therefore, it is recommended to follow the procedure described in Change Notice of FIPS186-2.

With regard to pseudorandom number generator G described above, the methods utilizing SHA-1 and DES are designated in Appendix 3 of FIPS 186-2. There is a report that since the method using DES has specific properties, it is better to use SHA -1. However, even if DES is used, the designated properties do not seem to affect the security of DSA.

Parameter selection As is described in the above technical specifications, the size of parameter p can be selected from 512 to 1024 bits in steps of 64 bits in the original DSA specification. On the other hand, the Guideline on the Law concerning Electronic Signatures and Certification and FIPS 186-2 Change Notice confine the size of parameter p to 1024 bits. Furthermore, NIST started to review the revision of specifications in order to allow a parameter of a larger size to be selected (including parameter q) [4]. At present, there are various opinions on how many secure parameter sizes exist, and the precise value cannot be assessed. However, a widely held view is that the 512-bit parameter does not allow security to be maintained with the capability of computers at present taken into account. Therefore, we strongly recommend that the most secure parameter size in the present specifications, 1024 bits, be selected. We also think it necessary to pay careful attention to the development of new specification. See "2.3.2 Discreet logarithm problem" for secure parameter size.

With regard to random number k used for signature generation, it is required to select a different random number per signature generation, because if the same random number k is used to sign the different plaintext, private key x may be compromised.

There is also a report that if the bit of a part of a random number k is revealed, the private key will be calculated. The attack shown in reference [5] depends on the lattice reduction technique. The result of the experiment shown there is as follows. When 70 pieces of signatures (with 512-bit parameter p) are given, the private key can be computed with a probability of 100% if 5 bits of random number k is known, and with a probability of 90% if 4 bits is known. The author of reference [5] also suggests the possibility of attacks with fewer bits, and thereby the need to pay attention to the development of further researches.

Other than the above, the attacks by using some special parameters (such as g = 0) have been reported. So it is desirable to select a proper parameter when using DSA.

42 CRYPTREC 2001

Provable security If a slight modification is made to DSA, provable security equivalent to the difficulty of the discrete logarithm problem can be presented in the random oracle model. With regard to DSA itself, however, provable security on a proper model or assumption has not so far been reported.

However, in view of the fact that DSA has been widely used and has a firm track record, it does not seem to present problems that may greatly affect the security at present.

References [1] FIPS PUB(Federal Information Processing Standards publication) 186-2: DIGITAL SIGNATURE STANDARD (DSS). [2] ANSI X9.30 Public Key Cryptography for the Financial Services Industry: Part 1: The Digital Signature Algorithm (DSA). [3] Lucent , Press releases: Scientist discovers significant flaw that would have threatened the integrity of on-line transactions, http://www.lucent.com/press/0201/010205.bla.html [4] NIST Workshop: Key Management Guideline (Draft), http://csrc.nist.gov/encryption/kms/workshop2-page.html [5] P. Q. Nguyen and I. E. Shparlinski, The insecurity of the Digital Signature Algorithm with partially known nonces, Journal of cryptology, to appear.

2.4.2 ECDSA

2.4.2.1 Technical overview

ECDSA is a signature scheme that uses an elliptic curve. ECDSA has multiple specifications. In this report, the target of evaluation is ECDSA in SEC1 [8][9] that was submitted to CRYPTREC in 2000, and ANSI X9.62 [1] that is listed in the Guideline on the Law concerning Electronic Signatures and Certification. ECDSA in SEC1 is a specification designed by SECG (Standards for Efficient Cryptography Group).

43 CRYPTREC 2001

2.4.2.2 Technical specifications

Signature generation and signature verification by ECDSA are performed as shown below.

An elliptic curve parameter is defined as T. T includes the base point G whose order is a prime number n.

Key generation: Integer dÎ [1, n - 1] is selected at random as a secret key, and Q = dG is defined as a public key.

Signature generation: Signature of plaintext M is generated as follows.

1 A random integer kÎ [1, n - 1] is selected.

2 R = kG = (x1, y1) is calculated.

3 r = x1 mod n is calculated. 4 e = h(M) is calculated. Note that h is a hash function SHA-1. 5 s = k-1(e + dr) mod n is calculated. 6 (r, s) is defined as the signature of plaintext M.

Signature verification: Verification of signature (r,s), for plaintext M,and public key Q is performed as follows.

-1 -1 1 R' = (x2, y2) = (s h (M))G + (s r)Q is calculated.

2 It is verified that x2 mod n = r holds.

2.4.2.3 Result of evaluation

Based on the evaluation result in CRYPTREC report 2000, full evaluations were made from the following points.

• Validation of provable security of ECDSA, provable security in generic group model in particular • Verification of security of Koblitz curve (for ECDSA in SEC1)

Full evaluation results are described below, beginning with the summary of difference of specifications between the two. n Difference between ECDSA in SEC1 and ANSI X9.62: The same ECDSA signature scheme is used for both ECDSA in SEC1 and ANSI X9.62. The major differences of specifications between the two are:

• Recommended specific elliptic curve parameter • Pseudo-ramdom number generator

In ECDSA in SEC1, specific recommended elliptic curve parameters are given in SEC2 document. With regard to the elliptic curve with characteristic p and characteristic 2, with multiple definition sizes, the curve selected at random in a verifiable format and Koblitz curve are recommended. The method of selecting a

44 CRYPTREC 2001

curve at random in a verifiable format is described in ANSI X9.62. With regard to pseudorandom number generators, no specific algorithm is listed.

In ANSI X9.62, on the other hand, no specific curve parameters are recommended, only with sample elliptic curve parameters shown in the appendix. However, a procedure of selecting elliptic curve parameters is shown in the appendix, which lists the method of random selection in a verifiable format and other methods (Weil method and CM methods). With regard to pseudorandom number generators, the method described in FIPS186 is specified. n Security of primitives: In ECDSA, the security of primitives is based on the elliptic curve discrete logarithm problem. See "Section 2.3.3 Elliptic Curve Discrete Logarithm Problem" for the evaluation results of this problem. n Provable security: In ECDSA, provable security in the random oracle model is not recognized. On the other hand, proof of security in a generic group model (also called a generic model) is summarized by Brown [2]. Correctness of the paper and the significance of provable security in a generic group model were discussed this year.

Brown discusses the proof of security in a generic group model for generic DSA, which is the abstraction of ECDSA.

Definition (Generic DSA): Let G be the base point of an additive group such that its order is a prime number n.

Let ¦: ® [0, n - 1] be a reduction function, and h: {0, 1}* ® [0, n - 1] be a hash function.

Key generation: Integer dÎ [1, n - 1] is selected at random as a secret key, and let Q = dG be a public key.

Signature generation: The signature of a plaintext M is generated by the procedure shown below.

1 An integer kÎ [1, n - 1] is selected at random. 2 R = kG is calculated. 3 r = ¦ (R) is calculated. 4 e = h (M) is calculated. 5 s = k -1 (e + dr) mod n is calculated. 6 (r, s) is defined as the signature of plaintext M.

Signature verification: Verifies that the following equation holds for plaintext M, signature (r, s), and public key Q.

r = ¦ (s-1h(M)G + s-1rQ)

45 CRYPTREC 2001

The ECDSA is an instance of the generic DSA that specifies a concrete reduction function ¦ and a hash function h using the group of an elliptic curve.

Generic group model is a virtual model that holds on the assumption that the expression of group element is given at random. In other words, this model assumes a generic group oracle by which bijective s from additive group Zn to bit string set S Ì {0, 1} is defined at random, thus computing generic group element by referring to generic group oracle.

Brown proves the following theorem and claims that one can prove the security (in the strongest sense) for the generic DSA provided that the hash function is collision free.

Theorem: Assuming that forger Fh succeeds in existential forgery by adaptive chosen message attack (with the number of chosen plaintext of q) within execution time of τ with probability ε or higher, algorithm

Ch exists, by which collision of a hash function h can be obtained within execution time of τ' with probability of ε' or higher, where τ' and ε' are defined as follows:

We basically verified the correctness of the theorem even though the proof of the theorem in [2] is too simplified. "Basically" because an external evaluator independently constituted the proof, thus verifying the argument of the theorem in principle, despite there are differences in the evaluated probability and execution time.

Significance of proof of security in generic group model is described below.

Generic group model was introduced to show the lowest bound of the computations of discrete logarithm problem by Nechaev [4] and Shoup [7]. It was then used by Schnorr-Jakobsson [5] [6] for the proof of security of and Signed ElGamal cipher using the combined model of generic group model and the random oracle model. Other than those, almost no argument can be found at present concerning the proof of security of signature scheme using generic group model. Therefore, it is not a confirmed method to be used for proving security at present. It is considered that its history of research differs from that of the random oracle model, which is often used for argument of provable security. There is also an opinion that there exists a gap, which is not small, between ECDSA and that in a generic group model. In other words, it is an opinion that in the case of ECDSA, function s that defines the expression of group element cannot be considered to be at random. The following is a specific example of this argument. When an attack that a forger receives a signature (r, s) for message m from the signing oracle by expanding adaptive chosen message attack and obtains another signature (r', s') for the same message m is considered to be reasonable, existential forgery using ECDSA can be succeeded. By using the property that when (r, s) is a signature for message m, (r, -s) can also be a signature for message m, the concrete method of forgery can be disclosed

46 CRYPTREC 2001

easily. In a generic group model, on the other hand, even if chosen message attack is expanded in this way, the proof of the above theorem holds. Thus there is a discrepancy between ECDSA and that in the generic group model.

There is also an opinion that gives credit to the provable security in a generic group model. The proof in a generic group model gives an index of security against attackers at present, since the solution algorithm of the elliptic curve discrete logarithm problem is considered to be a generic group model type method adopting group calculation, which is made to be a .

As can be seen above, adequacy or practicality of the proof of security in a generic group model has yet to be settled. n Security of Koblitz curve : Koblitz curve is a curve on characteristic 2 finite fields that can be defined by the following equation. It is also called an anomalous binary curve (ABC curve).

y2 + xy = x3 + ax2 + 1 (a Î {0, 1})

m Note that the curve should be defined over 2 . One of the characteristics of this curve is that scalar multiplication of points can be done at high speed by using Frobenius mapping. Also on the prime field p exists a curve whose endomorphism mapping can be calculated at high speed. ECDSA in SEC1 classifies such curves also in "Koblitz curve."

As an attack unique to Koblitz curve, Wiener-Zuccherato [10] and Gallant-Lambert-Vanstone [3] presented a method of speeding up the parallel collision search method using ρ method for discrete logarithm problem. In this method, high-speed point calculation that is the characteristics of Koblitz curve is used, thus m allowing discrete logarithm problem for Koblitz curve on 2 to be solved at the speed of 2m times faster. To be more specific, when m is 160, the number of calculation steps of discrete logarithm problem is equivalent to approximately 276, which means that the calculation can be done approximately 16 times faster than with an ordinary elliptic curve, but that the total number of calculation steps has not been improved much.

Other than the speeding up method of ρ described above, no peculiar attacks have so far been discovered. However, since Koblitz curve is classified in relatively restricted type curve, great attention should be paid to the possibility of the emergence of attacks unique to that class. n Pseudorandom number generator: ANSI X9.62 describes a pseudorandom number generator specified in FIPS186-2 (DSA). Bleichenbacher presented a method of attacking DSA using the characteristics that k = rand mod n, which is generated by this pseudorandom number generator, is not distributed uniformly in [1, n -1]. As a countermeasure for this attack, NIST presented the modification of pseudorandom number generator in Change Notice of FIPS186-2. To be more specific, it uses two random numbers rand and rand'

47 CRYPTREC 2001

to establish k = (rand||rand') mod n. Modification of specifications of pseudorandom number generator for ECDSA has not been proposed yet. However, since there is a possibility that the same kind of attack is made against the pseudorandom number generator used in ECDSA, careful attention should be paid to the future trend.

See also "2.4.1 DSA" for this matter. n Verification of elliptic curve parameters: There is an opinion that it should make it verifiable that elliptic curve parameters, which are system parameters used in ECDSA, have no trap doors.

In view of the above, a method for validating the elliptic curve parameters by checking the avoidance condition of known attacks against elliptic curve discrete logarithm problem is specified in ECDSA in SEC1. The presented avoidance condition is sufficiently effective enough at present, but a new attack may be found in the future. There is a potential risk that it is used as a trapdoor, so attention should be paid to the research activities of attacks.

See also "2.3.3" for the elliptic curve discrete logarithm problem.

References [1] ANSI X9.62, “Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digial Signature Algorithm (ECDSA) ”, American National Standard for Financial Services, 1998. [2] D. Brown, “The exact security of ECDSA”, Technical Report CORR 200-34, Dept. of C & O, Univers ity of Waterloo, 2000. Available at http://www.cacr.math.uwaterloo.ca [3] R. Gallant, R. Lambert and S. Vanstone, “Faster Point Multiplication on Elliptic Curves with Efficient Endomorphisms ”, Advances in Cryptology CRYPTO2001, Lecture Notes in 2139, Springer-Verlag, pp.190-200, 2001. [4] V.I. Nechaev, “Complexity of a determinate algorithm for the discrete logarithm”, Math. Notes 55, pp.165-172, 1994. [5] C.P. Schnorr and M. Jakobsson, “Security of discrete log cryptosystems in random oracle + generic model”, Conference on the Mathematics of Public-Key Cryptography, The Fields Institute, Tronto, Canada, 2000. Available at http://www.mi.informatik.uni-frankfurt.de/research/papers.html [6] C.P. Schnorr and M. Jakobsson, “Security of Signed ElGamal cipher”, Advances in Cryptology- ASISCRYPT2000, Lecture Notes in Computer Science 1976, Springer-Verlag, pp.73-89, 2001. [7] V. Shoup, “Lower bounds for discrete logarithms and related problems ”, Advanced in Cryptology - EUROCRYPT'97, Lecture Notes in Computer Science 1233, Springer-Verlag, pp.256-266, 1997. [8] Standards for Efficient Cryptography, “SEC1:Elliptic Curve Cryptography'”, Certicom Research,

48 CRYPTREC 2001

Ver.1.0, September 2000. [9] Standards for Efficient Cryptography, “SEC2:Recommended Elliptic Curve Domain Parameters”, Certicom Research, Ver.1.0, September 2000. [10] M. Wiener and R. Zuccherato, Faster attacks on elliptic curve cryptosystems'', Selected Areas in Cryptography, Lecture Notes in Computer Science 1556, pp.190-200, 1999.

2.4.3 ESIGN Signature

2.4.3.1 Technical overview

ESIGN signature is a scheme used for signature. ESIGN signature has multiple specifications, and they are roughly divided into two categories. The one is the specification where no provable security is presented. The other presents provable security of existential unforgeability against an adaptive chosen message attack on the basis of the difficulty of the e-th root approximation problem in the random oracle model.

Signature scheme listed in the Guideline on the Law concerning Electronic Signatures and Certification is classified in the former. This is called ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification). TSH-ESIGN signature [8] presented in IEEE P1363a [4] is classified in the latter.

Those two ESIGN signatures were evaluated in 2001. The result of the evaluation is shown below.

• ESIGN (The guideline on the Law concerning Electronic Signatures and Certification): A part of the security parameters specified in the Guideline on the Law concerning Electronic Signatures and Certification (when SHA-1 is used, for example, |n| = 2048 and |e| = 8) may invite forgery with the possibility that cannot be neglected. Of MD5 and SHA -1 that were designated as hash functions, the use of MD5 is not recommended. • TSH-ESIGN: Proved security is a little weaker than the known security.

Remarks in using ESIGN signature for e-Government are described at the end of this chapter.

In the following sections of this chapter, unless otherwise stated, the evaluation is for ESIGN of both specifications.

2.4.3.2 Technical specifications

Specification change of ESIGN signature was made several times, so there are various versions other than the one submitted to CRYPTREC [6].

The difference of specifications is summarized in Table 2.5. Recommended parameters are becoming larger year by year. With the development of security theory researches, it was also changed into the scheme that

49 CRYPTREC 2001

can prove the strongest security (on a certain assumption) of signature systems.

Table 2.5 Various ESIGN signatures

Recommended parameter Provable security Guideline on the Law concerning |n| ³ 1024, e ³ 8 NO at present Electronic Signatures and Certification CRYPTREC 2001 |n|=1152, e=1024 CRYPTREC 2000 |n| ³ 960, e ³ 8 YES (existential unforgery against the adaptive chosen message attack IEEE P1363a (Not specified according to IEEE under the approximate e-th root policy) problem assumption and the p2q NESSIE |n|=1152, e=1024 type factorization assumption in the random oracle model) * The presenter states that NESSIE is to make a change to these recommended parameters [6].

Specifications of the primitive part of ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification) and TSH-ESIGN are the same. The following are the summary of specifications.

Key generation Input: k Security parameter (positive integer) e Exponent of 8 or larger (positive integer) Output: PK Public key (n, k, e) SK Private key (p, q) Step 1 Choose two prime numbers of k bit, p and q. Step 2 Compute n = p2q. Step 3 Return PK = (n, k, e) and SK = (p, q).

Signature generation primitive: SP-ESIGN Input: PK Public key (n, k, e) SK Secret key (p, q) f Message, an integer that meets 0 £ ¦ £ 2k-1 Output s Signature, an integer that meets 0 £ s < n Step 1 Pick rÎ {1, 2, …, pq -1} at random that meets GCD (r, n) = 1. Step 2 Compute z = ¦•22k. Step 3 Compute a = (z - re) mod n.

Step 4 Compute w0 = .

Step 5 Set t = , then compute s = r + tpq. Step 6 Return s.

50 CRYPTREC 2001

Signature authentication primitive: PV-ESIGN Input: PK Public key (n, k, e) s Signature, an integer that meets 0 £ s < n Output: ¦ Signature data, an integer that meets 0 £ ¦ < 2k-1 Step 1 Compute T = s2 mod n. Step 2 Compute ¦ = . Step 3 If ¦ is not in the range 0 £ ¦ < 2k-1, return "invalid", and then terminate the operation. Step 4 Return ¦.

Note: The two prime numbers, p and q, must be distinct to maintain the security of ESIGN signature. However, ESIGN specification [6] does not specify this point. Our evaluation was made on the assumption that p and q are distinct prime numbers.

2.4.3.3 Security of primitives

The security of ESIGN signature primitives is based on the following two problems.

• approximate e-th root problem • n = p2q type factorization problem

If one of the above problems is solved, the private key of ESIGN signature will be disclosed to the adversary or the signature will be forged. We made an evaluation with respect to these two points. n Approximate e-th root problem: Approximate e-th root problem, which is the base of the security of ESIGN signature, is difined as follows.

Definition 1 (AER problem): Let g be the key generator of ESIGN. The approximate e-th root problem (AER problem) is, for given pk:={n, e} ¬ g (1k) and y ¬ r {0, 1}k-1, to find xÎ ( /n ) \ p such that 0||y = [xe mod n]k, where the distribution of (n,e,k) follows that of g (|n|=3k).

The assumption that AER problem is intractable is defined as follows [7].

Definition 2 (AER assumption): The approximate e-th root problem is intractable, if for any non-uniform probabilistic polynomial time algorithm Adv, for any constant c, for sufficiently large k,

Pr [Adv (k, n, e, y) ® x] < 1 / kc where 0||y = [xe mod n]k, the probability is taken over the coin flips of g and Adv. The assumption that the approximate e-th root problem is difficult is called the e-th root approximation assumption (AER assumption).

51 CRYPTREC 2001

• The case of e = 2 and e = 3 When e = 2, signature is successfully forged by using Brickell and DeLaurentis ’s method [1]. The following is the outline of the method.

If x is an integer approximate to n1/2, x2 mod n is O(n1/2), which meets the verification equation of ESIGN signature when message m = 0. The method allows this principle to be applied to arbitrary m to find the approximate value of the root by using continued-fraction expansion.

The method by Brickell and DeLaurentis can be expanded easily to the case where e = 3.

Valée, Girault and Toffin presented a signature forgery that uses the lattice basis reduction algorithm such as LLL algorithm when e = 2 [12, 13]. With regard to solving multivariable polynomial over the finite field by using the lattice basis reduction algorithm, the improvement by Coppersmith is well known [2, 3].

• The case of e ³ 4 With regard to the case where e ³ 4, no solution has been reported that is more effective than factoring the modulus n. n n = p2q type factorization problem: If factorization of modulus n is given, approximate e-th root problem can be solved. As distinct from n = pq (p and q are of the same size) that is used in RSA cryptosystem, ESIGN signature modulus is of the type n = p2q (p and q are of the same size). It is required to review the difficulty of the factorization problem of this type. See 2.3.1 for the difficulty of the factorization problem.

2.4.3.4 Security of the scheme

As is stated in the previous section, ESIGN signature has multiple specifications. From the viewpoint of message encoding, it is classified into the following two specification groups: ESIGN (the Guideline on the Law concerning Electronic Signatures and Certification) that does not have provable security at present, and TSH-ESIGN that is considered to have provable security of existential unforgeability against an adaptive chosen message attack on the basis of the difficulty of the approximate e-th root problem in the random oracle model. Details of security evaluation of the above two are described below. n Security notion for the signature: The type of attacks against a signature scheme is identified first, and then evaluation is made with respect to the following two points.

1. Security evaluation of the mathematical problem used (in the case of ESIGN signature, the approximate e-th root problem or the factorization problem) 2. Evaluation of the relation between the mathematical problem used and the signature scheme

In the previous section, the mathematical problem was evaluated. This section describes the evaluation of

52 CRYPTREC 2001

the relation between the mathematical problem and the signature scheme. The types of attacks against a signature scheme and the type of forgery are listed in Tables 2.6 and 2.7 [11]. The strongest security in a signature scheme is assured by

" Existential unforgeability against an adaptive chosen message attack (CMA)."

When a signature scheme is not deterministic, multiple valid signatures exist for one message. With CMA, the inquiry can be made to the signature oracle more than once (multiple signatures can be obtained). On the other hand, Stern proposed an ,

"Single-Occurrence adaptive chosen message attack (SO-CMA)" [10].

With SO-CMA, inquiry to the signature oracle can be made only once per message (only one signature can be obtained).

Table 2.6 Type of attacks against a signature scheme

Attack Details Passive attack Key-only attack This attack uses a public key only. Known message attack This attack is applicable when signatures for some random message can be obtained. Active attack Chosen message attack This attack is applicable when the signature for some messages previously designated by the attacker can be obtained. (Note, however, that all the message to be signed must be selected before the attack.) Adaptive chosen message attack This attack is applicable when a signature can be selected by referring to the signatures obtained by that time and the information on the corresponding message.

53 CRYPTREC 2001

Table 2.7: Type of signature forgery

Type of forgery Details Universal forgery The adversary is able to forge the signature of any message Selective forgery The adversary succeeds in forging the signature of some message of his choice Existential forgery The adversary succeeds in forging the signature of one message, not necessarily of his choice.. n TSH-ESIGN: In message encoding of TSH-ESIGN, a hash function H with output length of k-1 bit is used to calculate the hash value of message m, and m is encoded as follows.

0||H(m)||02k

Stern proved the security of TSH-ESIGN signature in the random oracle model as shown below [10].

Theorem 3 (Stern [10]): Let A be a SO-CMA adversary against TSH-ESIGN signature scheme that produses an existential forgery, with success probability e, within time t, making qH queries to the hash function and qs distinct requests to the signing oracle respectively. Then approximate e-th root problem can be solved with probability e' and within time t', where

k e æ 3 ö 1 e'³ - (q + q ) ´ - H s ç ÷ k-1 qH è 4 ø 2

t '£t + k(qs + qH )× Texp (k)

Where Texp(k) denotes the computing time of modular exponentiation.

The approach of introducing this theorem and its proof is associated with the argument of Shoup on OAEP [9]. It should be noted that what this theorem proves is not existential unforgeability against general adaptive chosen message attack (CMA), but existential unforgeability against single-occurrence adaptive chosen message attack (SO-CMA). Stern also pointed out the following.

• Contrary to what is claimed in [8], the result only applies to single-occurrence adaptive chosen message attacks. • We do not know how to extend the proof to with the stronger CMA model. n ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification): In ESIGN signature listed in the Guideline on the Law concerning Electronic Signatures and Certification, that is, the ESIGN signature submitted to CRYPTREC for evaluation in 2001, a message encoding method called EMSA is used [6]. Stern reported that ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification) succeeds in signature forgery with the probability that cannot be neglected [10]. The following is the outline of his report.

54 CRYPTREC 2001

The outline of EMSA encoding method is as follows. In this conversion method, the hash value of message m is calculated first by using the hash function H that outputs hLen £ k - 16-bit length string, and then the k - hLen-bit length string is attached to the hash value. The format is expressed in hexadecimal notation as follows.

00||PS||FF||H (m) where PS is a byte string other than FF. In this way, message m is converted to k-bit string.

This padding string PS has a quite negative effect on the security. The security in not in terms of approximate e-th root problem, but in terms of the following variant of approximate e-th root problem.

Definition 4 (variant of approximate e-th root problem [10]): Given n of bit-size 3k and a bit string v of length hLen, find x such that the binary expansion of xe mod n has a window of bits which coincide with v at positions 2k + 1, …, 2k + hLen.

This variant of approximate e-th root problem can be solved easily when e is small. If the following condition holds, the signature can be forged [10].

2k ³ e (hLen + log2 + 8)

The Guideline on the Law concerning Electronic Signatures and Certification designates SHA -1 and MD5 as hash functions. In the case of SHA-1 (hLen = 160), the above equation becomes as follows.

n > e 253.04

Therefore, when SHA -1 is used, signature forgery is successfully committed in the following cases, for example.

• |n| = 1024 and e £ 4 • |n| = 2048 and e £ 8

In the case of MD5 (hLen = 128), the above equation becomes as follows.

n > e 205 .04 Therefore, when MD5 is used, signature forgery is successfully committed in the following cases, for example.

• |n| = 1024 and e £ 4 • |n| = 2048 and e £ 9

These parameters includes the parameters specified in the Guideline on the Law concerning Electronic Signatures and Certification such as the case where |n| = 2048 and e = 8.

55 CRYPTREC 2001

2.4.3.5 Auxiliary function

ESIGN signature uses the hash function as an auxiliary function. ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification) adopts two schemes. In one of them, MD5 is used as the hash function, and in the other, SHA-1 is used. The use of MD5 is not recommended. Refer to document [5] and Chapter 4 for security of hash functions.

2.3.4.6 Implementability

Performance test conducted by the submitter [7] shows key generation of 610ms, signature generation of 1.04ms, and signature verification of 0.70ms, when modulus n is 1152 bits, and security parameter e is 1024 on single Celeron 800MHz.

RSA signature and ECDSA signature have been implemented in various platforms by various researchers, and their speed has been measured. However, there are almost no implementation examples of ESIGN signature other than the one by the submitter. Therefore, it is not known to what extent it will be speeded up. Note, however, that a part of the speedup technique used for speeding up of RSA such as exponentiation operation can be applied to ESIGN signature.

Signature generation speed of ESIGN signature is higher than that of RSA signature.

2.4.3.7 Summary of ESIGN signature • ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification): By using a part of security parameters specified in the Guideline on the Law concerning Electronic Signatures and Certification (for example by using SHA-1 under the condition where n is 2048 bits and e is 8 or smaller), signature can be successfully forged with the probability that cannot be neglected. Of MD5 and SHA -1 specified as hash functions, the use of MD5 cannot be recommended. • TSH-ESIGN: Proved security is a little weaker than the known security. • Approximate e-th root problem on which the security of ESIGN signature is based is easier than the problem of finding the e-th root on which the security of RSA signature is based. In other words, the degree of assumption of security is stronger than that of RSA.

56 CRYPTREC 2001

n About the use of ESIGN signature listed in the Guideline on the Law concerning Electronic Signatures and Certification: ESIGN (specified by the Guideline on the Law concerning Electronic Signatures and Certification) includes the parameters in the range of e and n, which may allow signature forgery to be committed with the probability that cannot be neglected. Therefore, full evaluation should be made before deciding to use it for e-Government. Of MD5 and SHA-1 specified as hash functions, the use of MD5 is not recommended.

References [1] E. Brinckell, J. DeLaurentis, “An Attack on a Signature Scheme proposed by Okamoto and Shiraishi,” Advances in Cryptology - CRYPTO'85, LNCS, 218 (1986), Springer-Verlag, 28-32. [2] D. Coppersmith, “Finding a Small Root of a Univeriate Modular Equation,” Advances in Cryptology - EUROCRYPT'96, LNCS, 1070 (1996), Springer-Verlag, 155-165. [3] D. Coppersmith, “Finding a Small Root of a Bivariate Integer Equation; Factoring with High Bits Known,” Advances in Cryptology - EUROCRYPT'96, LNCS, 1070 (1996), Springer-Verlag, 178-189. [4] “IEEE P1363a Draft Version 9 Standard Specifications for Public Key Cryptography: Additional Techniques,” IEEE (2001), available at http://grouper.ieee.org/groups/1363/ [5] Information Technolo gy Promotion Agency, Japan ,“CRYPTREC Report 2000,” (2000). [6] NTT Information Sharing Platform Laboratories, “The Specification of ESIGN,” (2001), available at http://info.isl.ntt.co.jp/esign/CRYPTREC/index-j.html [7] NTT Information Sharing Platform Laboratories, “Self evaluation of ESIGN,” Submission documents to CRYPTREC 2001, (2001), available at http://info.isl.ntt.co.jp/esign/CRYPTREC/index-j.html} [8] T. Okamoto, E. Fujiaki, H. Morita, “TSH-ESIGN:Efficient Digital Signature Scheme Using Trisection Size Hash,” Submission to P1363a, available at http://grouper.ieee.org/groups/1363/StudyGroup/submissions.html (1998) [9] V. Shoup, “OAEP Reconsidered,” Advances in Cryptology - CRYPTO 2001, LNCS, 2139 (2001), Springer-Verlag, 239-259. Also available at http://shoup.net/papers/ [10] J. Stern, “Evaluation Report on the ESIGN Signature Scheme,” (2001) [11] M. Une, T. Okamoto, “Latest Trend of the Research of Public Key Cryptosystem Theory”, IMES Discussion Paper Series 98-J-28, (1998)

[12] B. VALLÉE, M. GIRAULT, P. TOFFIN, “How to Break Okamoto's Cryptosystem by Reducing lattice Bases,” Advances in Cryptology - EUROCRYPT'88, LNCS, 330 (1988), Springer-Verlag, 281-291.

[13] B. VALLÉE, M. GIRAULT, P. TOFFIN, “How to Guess $l$th Roots Modulo $n$ by Reducing Lattice Bases,” AAECC-6, LNCS, 357 (1988), Springer-Verlag, 427-442.

57 CRYPTREC 2001

2.4.4 RSA (RSA-OAEP, RSA-PSS, RSA signature s)

2.4.4.1 Technical overview

CRYPTREC made an evaluation of RSA-OAEP, RSA-PSS and RSA signatures as cryptographic techniques that use RSA primitives. RSA-OAEP (Optimal Asymmetric Encryption Padding) is a cryptosystem used for confidentaility of information, whereas RSA-PSS and RSA signatures are a cryptosystem used for digital signature.

Since it is pointed out that the method standardized in PKCS#1v1.5 can be attacked by a certain type of attacks (using the information that the cipher does not meet the predetermined condition) by Bleichenbacher in 1998, encryption algorithm has been required to meet strong resistance (IND-CCA2) against adaptive chosen attacks.

RSA-OAEP is a cryptosystem whose provable security has been presented that it meets the strongest security (IND-CCA2) on the assumption that the RSA primitive is one-way (this condition is called "Difficulty of RSA problem").

With regard to the signatures that use RSA, there exist many specifications including the following: 1) so called "textbook" RSA signature, 2) ANSI X9.31, 3) RSA-PKCS #1 v1.5 (method listed in the Guideline on the Law concerning Electronic Signatures and Certification *4), 4) RSA-FDH (Full-Domain Hash Schemes; FDH), 5) RSA-PSS (research paper version of Bellare-Rogaway) and 6) RSA-PSS (IEEE P1363a version).

The target of full evaluation was focused on RSA-PKCS#1v1.5 that is listed in Guideline on the Law concerning Electronic Signatures and Certification, and RSA -PSS (IEEE P1363a version) that is submitted to CRYPTREC for evaluation in 2001.

2.4.4.2 Technical specifications n RSA primitive : A public key is defined as (N, e), and a secret key is defined as (N, d). e is an odd number of 3 or larger that satisfies GCD {e, (p - 1) (q - 1)} = 1, and de º 1 (LCM {p - 1, q - 1}).

RSA encryption primitive RSAEP and RSA signature verification primitive RSAVP are defined to meet the following equation.

RSAEP ((n, e), x) = RSAVP ((n, e), x) = xe mod N (2.1)

Decryption primitive RSADP and signature generation primitive RSASP are defined to meet the following equation.

*4 This method is specified in RSA-PKCS#1v1.5, and inherited to RSA-PKCS#1v2.0 or later. So it is described as RSA-PKCS#1v1.5 in this report.

58 CRYPTREC 2001

RSADP ((n, d), y) = RSASP ((n, d), y) = yd mod N (2.2)

In the above equations, x and y are integers in {0, 1, …, N - 1} = ZN. The octet number of N is defined as k (hereafter described as |N| = k) n RSA-OAEP: The following is the configuration of RSA-OAEP.

EME-OAEP -Encode (M, P, emLen)

1. If the octet length of P is longer than the input limitation of the hash function (261 - 1 octet for SHA-1), "parameter string too long" is outputted, terminating the operation. 2. If mLen > emLen - 2hLen - 2, "message too long" is outputted, terminating the operation. 3. Data string PS that includes (emLen - mLen - 2hLen - 2) zero octets is generated. |PS| = 0 may be permitted. 4. pHash = Hash (P) that is a string of the length of hLen octet is generated. 5. DB = pHash || PS || 01 || M. 6. A random string of the length of hLen octet, , is generated. 7. dbMask = MGF (seed, emLen - hLen - 1). *5 8. MaskedDB = DB Å dbMask. 9. seedMask = MGF (MaskedDB, hLen). 10. MaskedSeed = seed Å seedMask. 11. EM = 00 || MaskedSeed || MaskedDB. 12. EM is outputted. EME-OAEP -Decode (EM, P)

1. If the octet length of M is longer than the input limitation of the hash function (261 - 1 octet for SHA-1), "decoding error" is outputted, terminating the operation. 2. If emLen < 2hLen + 2, "decoding error" is outputted, terminating the operations. 3. EM = X || MaskedSeed || MaskedDB, where |X| = 1, |MaskedSeed| = hLen, |MaskedDB| = emLen - hLen - 1. 4. seedMask = MGF (MaskedDB, hLen). 5. seed = MaskedSeed Å seedMask . 6. dbMask = MGF (seed, emLen - hLen - 1). 7. DB = MaskedDB Å dbMask. 8. Let hLen octet string be pHash = Hash (P).

*5 In RSA-OAEP specifications submitted by RSA Security, Inc.(01espdif), the number of bytes of MGF output (that corresponds to function G) is shown as emLen - hLen. However, emLen - hLen - 1 is considered to be correct.

59 CRYPTREC 2001

9. DB = pHash ' || M', where |pHash'| = hLen. 10. M' = a || T || M. T is the leftmost octet in M' that is not zero. |T| = 1. 11. If pHash' ¹ pHash , X ¹ 00, or T ¹ 01, "decoding error" is outputted.*6 12. T and a (all are made of zero) are removed from M' to generate M. 13. M is outputted.

In RSA-OAEP, plaintext M is encrypted, and ciphertext C is decrypted as follows.

Fig. 2.1: RSA-OAEP-Encode

RSAES -OAEP -Encrypt ((n, e), M, P)

1. EM = EME-OAEP-Encode (M, P, k). If "message too long" is outputted by encoding operation, "message too long" is outputted, terminating the operation. 2. C = RSAEP ((n, e), EM). 3. C is outputted.

RSAES -OAEP -Decrypt ((n, d), C, P)

1. EM = RSADP((n, d), C). 2. M = EME-OAEP -Decode (EM, P). If "decoding error" is outputted by decoding operation, "decryption error" is outputted, terminating the operation. 3. M is outputted. n RSA-PSS: The configuration of RSA-PSS is as follows.

EMSA-PSS-Encode (M, emBits)

1. If the octet length of M is longer than the input limitation of the hash function (261 - 1 octet for

*6 In this step, it was decided that the same error notice is outputted simultaneously irrespective of the reason of the errors. This is a newly introduced implementation method as a countermeasure for the attacks pointed out in reference [9].

60 CRYPTREC 2001

SHA-1), "message too long" is outputted, terminating the operation. 2. mHash = Hash (M) that is a string of the length of hLen octet is generated.

3. If emBits < 8hLen + 8sLen + 8t + 1, "encoding error" is outputted, terminating the operation (t is an option of Trailer field, and takes the value 1 or 2.) 4. A random string of the length of sLen, , is generated. If sLen = 0, salt becomes null. 5. m' = 00 00 00 00 00 00 00 00 || mHash || salt. m' is an octet string of the length of (8 + hLen + sLen) that includes 8 zero octets (it is so set that P = 00 00 00 00 00 00 00 00) at the front. 6. An octet string of the length of hLen, H = Hash (m'), is generated. 7. A data string PS that includes zero octet of the number of (emLen - sLen - hLen - t - 1) is generated. There may be a case where |PS| = 0. 8. DB = PS || 01| salt. 9. dbMask = MGF (H, emLen - hLen - t). 10. MaskedDB = DB Å dbMask . 11. (8emLen - emBits) bits from the left of the leftmost octet of MaskedDB are set to zero. 12. If t = 1, TF = bc, and if t = 2, TF = HashID || cc, where bb, cc are hexadecimal notation of one octet, and HashID is an identification of the function Hash . 13. EM = MaskedDB || H || TF. 14. EM is outputted.

EMSA-PSS-Decode (M, EM, emBits)

1. If the octet length of M is longer than the input limitation of the hash function (261 - 1 octet for SHA-1), "inconsistent" is outputted, terminating the operation. 2. Let hLen octet string be mHash = Hash (M). 3. If emBits < 8hlen + 8sLen + 8t + 1, "decoding error" is outputted, terminating the operation. *7 4. If t = 1, TF = bc, and if t = 2, TF = HashID || cc, where bc, cc are hexadecimal notation of one octet, and HashID is an identification code of the function Hash . 5. If the rightmost t octet does not coincide with TF, "inconsistent" is outputted, terminating the operation. 6. It is regarded that EM = MaskedDB || H || TF, where |MaskedDB| = emLen - hLen - t, and |H| = hLen. 7. If (8emLen - emBits) bits from the left of the leftmost octet of MaskedDB do not coincide with zero, "inconsistent" is outputted, terminating the operation.

*7 In the RSA-PSS specification (01espdif) submitted from RSA Security, Inc., it is described as emBits < 8hLen + 8sLen + 2t + 1. However, it is considered that emBits < 8hLen + 8sLen + 8t + 1 is correct.

61 CRYPTREC 2001

8. dbMask = MGF (H, emLen - hLen - t). 9. DB = MaskedDB Å dbMask . 10. (8emLen - emBits) bits from the left of DB are set to zero. 11. If (emLen - hLen - sLen - t - 1) octet from the right of DB does not coincide with zero, or if the (emLen - hLen - sLen - t - 1)th octet from the right does not coincide with 01, "inconsistent" is outputted, terminating the operation. 12. The last sLen octet of DB is defined as salt. 13. m' = 00 00 00 00 00 00 00 00 || mHash || salt. m' is (8 + hLen + sLen) octet string that includes eight zero octets. 14. Let hLen octet string be mHash ' = Hash (m'). 15. If H = H', "consistent" is outputted. Otherwise "inconsistent" is outputted.

In RSA-PSS, the signature for message M is generated, and the signature S is authenticated as follows.

RSA-PSS-Sign ((n, d), M)

1. EM = EMSA-PSS-Encode (M, modBits - 1). If "message too long" is outputted by encoding operation, "message too long" is outputted, terminating the operation. 2. S = RSASP ((n, d), EM). 3. Signature S is outputted.

RSA-PSS-Verify ((n, e), M, S)

1. EM = RSAVP ((n, e), S). 2. Result = EMSA -PSS-Decode (M, EM, emBits), where emLen = [(modBits - 1)/8] octet, and modBits is the bit length of modulo n. If "consistent" is outputted by encoding operation, "valid" is outputted. Otherwise "signature invalid" is outputted. n RSA-PKCS#1v1.5: RSA-PSA -PKCS#1v1.5 (the method listed in the Guideline on the Law concerning Electronic Signatures and Certification) is specified in the standard RSA PKCS#1v1.5 [11] and inherited to the standard RSA PKCS#1v2.0 [12] and later.

The description on the signature scheme in the two documents published by RSA can be summarized as shown below.

1. Standard v1.5 describes a hash function MD5 (OID), but it does not describe a hash function SHA -1 (OID) (Chapter 11 of document [11]). 2. Standard v2.0 states that SHA -1 can be newly used as EMSA -PKCS1-v1_5 encoding method (OID) (Section 10.1 of document [12]).

The format specified as EMSA -PKCS1-v1_5 encoding method is shown in Fig. 2.3. T is specified by Distinguished Encoding Rule (DER), and the top field specifies a hash function, and the next field includes

62 CRYPTREC 2001

a hash value.

Fig. 2.2: RSA-PSS

00 01 PS(FF…..FF) 00 T (Includes hash_Id at the top.) Fig. 2.3: Output format of EMSA-PKCS1-v1_5

PS is an octet string of 8 octets or longer consisting of value FF (in hexadecimal notation).

2.4.4.3 Security n Security of primitives: The security of primitives of RSA is based on

• n = pq type factorization problem.

The evaluation result of the factorization problem is described in section 2.3.1. With regard to the provable security of RSA, equivalence to the difficulty of the factorization problem of the above type has not been proven. However, it is believed to be secure based on the past experiences. Security evaluation has been made based on the track record of use over a long period of time, and from various points of view. All the four evaluators reported that the description of the self-evaluation report on RSA primitives presented no problems. Usage restriction to both the encryption and the signature are pointed out as follows. 1) sharing of modulo value, 2) the threat when a secret key d is small, 3) fear of revealing the whole information through partial information of the key. With regard to the use as a cipher, 1) the threat when the public key e is small

63 CRYPTREC 2001

(Coppersmith's attack), and 2) the threat of the broadcast attack (by Hastad and Coppersmith), etc. were reported. n Security of RSA-OAEP: Shoup pointed out flaws in the argument of security presented in the original paper of Bellare-Rogaway, the committee discussed and reviewed the security of RSA-OAEP at the end of 2000 [10].

As a result, it was revealed that even though the security reduction efficiency lowers, provable security of RSA-OAEP holds on the basis of the difficulty of the RSA problem [7]. A problem in implementation of OAEP was pointed out in 2001 [9], but it is confirmed that the measures for the problem have been taken in the submitted specification. n Security of RSA-PSS: Probabilistic Signature Schemes, PSS, is a digital signature encoding scheme proposed by Bellare and Rogaway. By adding a random component to the message to be signed, even static signature scheme such as RSA signature is allowed to generate different signatures. RSA-PSS not only changes the static signature scheme probabilistically, but is also proven its security in the random oracle model [4].

As signature schemes whose security has been proved, Full Domain Hash Schemes, FDH [2], and a conversion method by which a digital signature can be composed based on identification [6] have been proposed. However, PSS has a feature that prove tighter reduction can be proved than these methods.

Coron proposed a technique to obtain tighter FDH reduction relations (Coron's technique) [5]. Jonsson reevaluated the security of PSS by applying Coron's technique [8]. In addition to evaluating a tight reduction relations, it indicated the following.

1. The proof of security can be given if salt length is made variable. 2. The efficiency of reduction relations was evaluated, including the case where Hash function and MGF have correlation.

In Jonsson's proof, Hash-ID was not the target of review. However, since security evaluations were made including the attacks with variable salt length and the one having the correlation between the two functions used for encoding operation, it was judged that Hash-ID was reliable.

RSA-PSS Signature Scheme RSA-PSS has been proven to be existentially unforgeable against adaptive chosen-message attacks in the random oracle model under the RSA assumption. The reduction is tight, and so the assurances provided by he security proof are strong. More guidance should be given on the desired length of the salt used in the RSA -PSS encoding operation.

Care should be taken when selecting the size of salt and modulo, because the introduction of a new parameter may reduce the tightness of reduction.

64 CRYPTREC 2001

n RSA-PKCS#1v1.5: Although the security of RSA-PKCS#1v1.5 has not been proven, no doubt on its security was pointed out, either. Because the methods of signature forgery are proposed with respect to many signature encoding methods, it is required to continue evaluating the security of encoding methods shown in Fig. 2.3.

There was a suggestion that since RSA-PKCS#1v1.5 has no proof of security, RSA-PSS, which has the same degree of efficiency and proof of security, should be adopted instead of RSA-PKCS#1v1.5:

RSA-PKCS1-v1.5 Signature Scheme. There is no formal proof of security of RSA -PKCS1-v1.5. SinceRSA-PSS is as efficient as RSA-PKCS-v1.5 and has a security proof, there is no reason to use RSA-PKCS1-v1.5.

2.4.4.4 Summary n RSA-OAEP: The proof of provable security is reliable in the random oracle model. However, since there is a slight difference between the method submitted to CRYPTREC for evaluation and the method proved in the paper, it is required to assess the relation of corresponding parameters and select design parameters.

The difference between the specifications of RSA-OAEP and those being discussed by the committee that conforms to [3] (corresponding notations) is summarized in the following table.

OAEP[3] « EME-OAEP m « PS || M n « 8 ´ mLen 0k1 « pHash

k0 « 8 ´ hLen

k1 « 8 ´ hLen G(.) « MGF(., emLen - hLen-1) H(.) « MGF(., hLen) r « seed k « 8 ´ emLen s « MaskedDB t « MaskedSeed

Note 5: It should be noted that document [3] uses the notation by the bit, while RSA-OAEP uses the notation by the byte.

There is an opinion of recommending RSA-OAEP+ instead of RSA -OAEP from the standpoint of the reduction efficiency：

RSA-OAEP Encryption Scheme. RSA-OAEP has been proven to be semantically secure against

65 CRYPTREC 2001

adaptive chosen-ciphertext attacks in the random oracle model under the RSA assumption. However, the reduction is not tight, and thus it is not clear what security assurances the proof provides. We recommend that RSA -OAEP be modified to RSA-OAEP+ which has a tighter security reduction, and furthermore can be easily modified to allow encryption of arbitrarily-long messages (see [10]). n RSA-PSS: The proof of security is reliable in the random oracle model. However, since there is a slight difference between the method submitted to CRYPTREC for evaluation and the one proved in the paper [4], the relation of corresponding parameters must be assessed to select design parameters.

It is necessary to discuss the addition of RSA-PSS to the Guideline on the Law concerning Electronic Signatures and Certification, with the condition of use and the lifetime of RSA-PKCS#v1.5 scheme taken into consideration.

The following table shows the difference between RSA-PSS specifications and those conforming to [4] that are under discussion by the committee (correlation of notation).

PSS [4] « EMESA-PSS m « P || mHash r « salt

k0 « 8 ´ sLen 0k2 « PS

k2 « emBits - 8 ´ hLen -8 ´ sLen -8 k « emBits

k1 « ´ hLen w « H s || t « zero is set to the first (8emLen - emBits) bits via MaskedDB. G(.) « zero is set to the first (8emLen - emBits) bits via MGF(.,\emLen - \hLen-1) H(.) « Hash function1

Note 6: Note that in reference [4], notation by the bit is used, while in RSA-PSS notation by the byte is used. n RSA signature listed in the Guideline on Law concerning Electronic Signatures and Certification (RSA-PKCS#v1.5): There seems to exist no problem on the security at present, but the security of encoding method shown in Fig. 2.3 must be continued. The Guideline on the Law concerning Electronic Signatures and Certification specifies MD5 and SHA-1 as hash functions to generate T in Fig. 2.3. However, the use of MD5 is not recommended as is pointed out in CRYPTREC Report 2000.

References [1] M. Bellare, A. Desai, D. Pointcheval, and P. Rogaway. Relations among notions of security for public-key encryption schemes. In H. Krawczyk, editor, Advances in Cryptology — CRYPTO'98, pages 26-45. Springer, 1998. Lecture Notes in Computer Science No. 1462.

66 CRYPTREC 2001

[2] M. Bellare and P. Rogaway. Random oracles are practical: A for designing efficient protocols,. In Proc. of the First ACM Conference on Computer and Communications Security, pages 62-73. ACM Press, 1993. [3] M. Bellare and P. Rogaway. Optimal asymetric encryption — how to encrypt with RSA. In A.D. Santis, editor, Advances in Cryptology — EUROCRYPT'94, volume 950 of Lecture Notes in Computer Science, pages 92-111, Berlin, Heidelberg, New York, 1995. Springer-Verlag. [4] M. Bellare and P. Rogaway. The exact security of digital signatures - how to sign with RSA and Rabin. In U. Maurer, editor, Advances in Cryptology —EUROCRYPT'96, volume 1070 of Lecture Notes in Computer Science, pages 399-416, Berlin, Heidelberg, New York, 1996. Springer-Verlag. [5] J. S. Coron. On the exact security of full domain hash. In M. Bellare, editor, Advances in Cryptology — CRYPTO2000, volume 1880 of Lecture Notes in Computer Science, pages 229-235, Berlin, Heidelberg, New York, 2000. Springer-Verlag. [6] A. Fiat and A. Shamir. How to prove yourself. In A.M. Odlyzko, editor, Advances in Cryptology — CRYPTO'86, volume 263 of Lecture Notes in Computer Science, pages 186-208, Berlin, Heidelberg, New York, 1986. Springer-Verlag. [7] E. Fujisaki, T. Okamoto, D. Pointcheval and J. Stern. RSA-OAEP is chosen-ciphertext secure under the RSA assumption. In J. Kilian, editor, Advances in Cryptology — CRYPTO2001, volume 2139 of Lecture Notes in Computer Science, pages 260-274, Berlin, Heidelberg, New York, 2001. Springer-Verlag. [8] Jakob Jonsson. Security proofs for the RSA-PSS signature schemes and its variants - draft 1.1. Available at http://eprint.iacr.org/2001/053/, 2001. [9] J. Manger. A chosen ciphertext attack on optimal asymmetric encryption padding (OAEP) as standardized in PKCS# v2.0. In J. Kilian, editor, Advances in Cryptology — CRYPTO2001,volume 2139 of Lecture Notes in Computer Science, pages 230-238, Berlin, Heidelberg, New York, 2001. Springer-Verlag. [10] V. Shoup. OAEP reconsidered. In J. Kilian, editor, Advances in Cryptology — CRYPTO2001, volume 2139 of Lecture Notes in Computer Science, pages 239-259, Berlin, Heidelberg, New York, 2001. Springer-Verlag. [11] PKCS #1: RSA Encryption Standard ，An RSA Laboratories Technical Note Version 1.5, Reviesed November 1, 1993 [12] PKCS #1 v2.0: RSA Cryptography Standard, RSA Laboratories, October 1, 1998 2.4.5 EPOC-2

2.4.5.1 Technical overview

EPOC-2 is an algorithm designed for securing confidentiality. It is a public key cryptosystem designed to

67 CRYPTREC 2001

have the provable security of strict confidentiality (IND-CCA2) against adaptive chosen ciphertext attack, on the assumption that the factorization problem of modulus n = p2q (p and q are different prime numbers) is difficult in the random oracle model. Its basic construction is to convert the cryptographic primitives proposed in [2] by the method of achieving IND-CCA2 proposed in [1]. EPOC-2 uses a symmetric key cryptosystem as part of its technique.

EPOC-2 was submitted for evaluation as the modification of the cryptographic technique submitted to CRYPTREC 2000 for evaluation. The change displayed in the modified version is only that the encoding method is specified mo re precisely. Since its technique is essentially the same, the Committee decided to continue its full evaluation.

2.4.5.2 Technical overview

The specifications of the primitive part of EPOC-2 (overview) are shown below. See specifications for details. n Key generation: KGP-OU: KGP-OU is defined as follows.

Input: k Security parameter, nonnegative integer Output: PK OU public key (n, g, h, pLen) SK OU secret key (p, q, pLen, w) Procedure: 1. Two prime numbers p,q(2k-1£ p,q <2k, p ¹ q) are selected, and n: = p2q is calculated.

p-1 2 2. g Î ( /n )* that meets the condition that the order of gp: = g mod p becomes p is selected at random.

n 3. h0 Î ( /n )* is selected at random. Let h : = hn0 mod .

4. pLen: = k

x -1 5. w = L (gp), where L(x) = p

6. PK = (n, g, h, pLen) and SK = (p, q, pLen, w) are outputted. n Encryption primitive: EP-OU: EP-OU is defined as follows.

Input: PK OU public key (n, g, h, pLen) m Message, integer to meet 0 £ m < 2pLen-1 r Random number, an integer to meet 0 £ r < n Output: c Ciphertext, integer to meet 0 £ c < n Error: "invalid"

68 CRYPTREC 2001

Procedure: 1. If m does not meet 0 £ m < 2pLen-1, "invalid" is outputted as an error, terminating the operation. 2. c = gmhr mod n is calculated. 3. c is outputted. n Decryption primitive: DP-OU

DP-OU is defined as follows.

Input: SK OU secret key (p, q, pLen, w ) c Ciphertext, an integer to meet 0 £ c < n Output: m Message, an integer to meet 0 £ m < 2pLen-1 Error: "invalid" Prerequisite: The secret key SK is correct. Procedure: 1. If a cyphertext c does not meet 0 £ m < n, "invalid" is outputted, terminating the operation.

p 2 2. cp = c -1 mod p is calculated. L(c ) 3. m = p mod p 2 is calculated. w

4. If m meets 0 £ m < 2pLen-1, m is outputted. Otherwise "invalid" is outputted as an error, terminating the operation.

A brief summary of specifications of the scheme part is shown below. The scheme is the conversion of the above encryption primitive by using the method proposed in [1]. The scheme uses the encoding process called EME3. See the specifications for details. n Encryption scheme: ES -EPOC-2-ENCRYPT: Input/output of ES-EPOC-2-Encrypt is as follows.

Input: PK OU public key (n, g, h, pLen) M Message to be encrypted expressed in terms of an octet string P Octet string (can be null)

Output: (C1, C2) Ciphertext consisting of two octet strings Error: "invalid" n Decryption scheme: DS -EPOC-2-DECRYPT: Input/output of DS-EPOC-2-Decrypt is as follows.

Input: PK OU puglic key (n g, h, pLen) SK OU secret key (p, q, pLen, w )

(C1, C2) Ciphertext to be decrypted consisting of two octet strings P Octet string encoding parameter (can be null)

69 CRYPTREC 2001

Output: M Octet string message Error: "invalid"

2.4.5.3 Security evaluation n Provable security: The encryption primitives used are slightly different from the one presented in the original paper [2]. To be specific, the selection of h0 in KGP -OU, and the method of generating h are different. In EPOC-2,

n h0 Î ( /n )* is selected at random, and let h be h := h0 mod n .

In [2], on the other hand, h meets

h = gn mod n.

Multiple evaluators pointed out that specifications of EPOC-2 submitted do not endorse that it is IND-CCA2. These evaluators also pointed out that by selecting h as in the same way as [2], it meets IND-CCA2. A request for specification change was presented by the submitter as shown in the next section. n n = p2q type factorization problem: As distinct from n = pq (p and q are the same size) type, modulo n used in EPOC-2 cryptosystem is in the form of n = p2q (p and q are the same size). Therefore, it is necessary to closely examine the difficulty of this type of the factorization problem when discussing the security of the encryption. See the evaluation result in a separate section for the difficulty of the factorization problem. n Other points to notice: Care should be taken to the mode of operation when using a block cipher in a symmetric key cryptosystem. The reason for this is that notes in use are not listed in the specifications, thus raising the possibility that IND-CPA cannot be met even if a secure block cipher is used. Because of this, IND-CCA2 may not always be assured.

Since the specification has only the minimum description, extreme care should be taken in selecting the parameters such as prime number p.

2.4.5.4 Others

In the lump session of cryptographic technique evaluation workshop held on January 28, 2002, a request for change was submitted from the submitter. Furthermore, on January 30, 2001, a self-evaluation report of the submitter on the proof of security on the basis of specification change was sent to the address to which CRYPTREC Evaluation Committee is inviting comments. The following (A) and (B) are the details of the email.

(A) In "Selection of h" in section 5.1 in EPOC-2 specifications

70 CRYPTREC 2001

(1) A detailed report is in the self-evaluation report submitted to NESSIE 2001 project on the proof that provable security is assured when h=g^n mod n (other parameters conform to the specification). The report is available in

http://info.isl.ntt.co.jp/epoc/nessie/index-j.html

(2) There are no known attacks even when h is selected as in the present specifications. (B) In the present specification, hLen is set shorter than Eurocrypt '98 (Appendix B), but if the condition (1) is met (if h=g^n mod n), the provable security can be verified. Note, however, that the security reduction efficiency is reduced to approximately two thirds of the case where hLen is set to the same as Eurocrypt '98. Details are described in the above self-evaluation report.

Because specifications different from those submitted to the committee are not to be evaluated, CRYPTREC Evaluation Committee did not evaluate the above. The description of hLen seems to be the comparison with [1] and not with [2].

References [1] E. Fujisaki and T. Okamoto, Secure Integration of Asymmetric and Symmetric Encryption Schemes, CRYPTO'99, LNCS1666, pp.537-554, Springer-Verlag, 1999. [2] T. Okamoto and S. Uchiyama, A New Public-Key Cryptsystem as Secure as Factoring, Eurocrypt'98, LNCS1403, pp.308-318, Springer-Verlag, 1998. [3] Specification of EPOC-2, Submitted document to CRYPTREC2001 [4] Self Evaluation of EPOC-2, Submitted document to CRYPTREC2001

2.5 Evaluation of Cryptographic Techniques under Observation

2.5.1 ECIES in SEC1

2.5.1.1 Technical overview

ECIES in SEC1 is a public key cryptographic technique designed by SECG (Standards for Efficient Cryptography Group) that adopts an elliptic curve cryptosystem. This cryptographic technique was submitted to CRYPTREC for evaluation in 2000 as ECAES in SEC1. In 2001, it was submitted as ECIES in SEC1. Note that they are the same cryptosystem.

2.5.1.2 Technical overview

The specifications (general) of ECIES in SEC1 are as follows. See the specification for details. Elliptic curve parameters (i) (p, a, b, G, n, h) or (ii) (m, f(x), a, b, G, n, h):

71 CRYPTREC 2001

(i) A parameter consisting of a prime p specifying the finite field p, two elements a, b Î p specifying 2 3 the elliptic curve defined by the equation E: y = x + ax + b (a,b Î p), a base point G on E ( p), a prime n which is the order of G, and an integer h which is the cofactor h = # E ( p)/n.

(ii) A parameter consisting of an integer m specifying the finite field 2m, an irreducible binary

polynomial f(x) of degree m specifying the representation of 2m, two elements a, b Î 2m specifying 2 3 2 the elliptic curve defined by the equation E: y + xy = x + ax + b (a,bÎ 2m), a base point G on E ( 2m),

a prime n which is the order of G, and an integer h which is the cofactor h = # E ( 2m) /n. KDF: Key Derivation Function MAC: Code ENC: Symmetric Key Encryption or XOR Secret key: Integer d (Î [1, n - 1]) Public key: Q, d-fold point of G

Encryption: Ciphertext C for plaintext M is outputted in the following procedure.

1. An integer kÎ[1, n - 1] is selected, and R = kG is calculated. 2. The x-coordinate of kQ, Z = x (kQ), is calculated. 3. K = KDF (Z) is calculated, and then the key used in ENC, EK, and the key used in MAC, MK are calculated by K = EK || MK. 4. Plaintext M is encrypted by ENC that uses EK, EM = ENC (EK, M) (EM = EK Å M in the case of XOR) 5. Message authentication code D = MAC (MK, EM) is calculated from EM using MAC function with the key MK. 6. Ciphertext C = R || EM || D is outputted.

Decryption: Plaintext M for ciphertext C, or "invalid" is outputted in the following procedure.

1. R', EM', and D' are calculated by C = R' || EM' || D' 2. The x-coordinate of dR', Z' = x (dR'), is calculated. 3. K' = KDF (Z') is calculated, and then key EK' used in ENC and key MK' used in MAC are calculated by K' = EK' || MK' 4. It is verified if D' = MAC (MK', EM') holds. If it doesn't, "invalid" is outputted. 5. EM' is decrypted by ENC that uses the key EK' by M = ENC (EK', EM') (M = EK' Å EM' in the case of XOR) 6. Plaintext M is outputted. 2.5.1.3 Security evaluation

ECIES in SEC1 is a public key cryptosystem based on the difficulty of the elliptic curve discrete logarithm problem.

72 CRYPTREC 2001

There are various known attacks for the elliptic curve discrete logarithm problem. With regard to ECIES in SEC1, elliptic curve parameters, to which existing attacks cannot be applied in practically valid number of bits, are specifically presented in SEC 2 document. (Note that these are recommended parameters, and the use of other elliptic curves is also allowed.) These elliptic curves consist of the ones selected at random in verifiable forms and the one called Koblitz curve (see 2.4.2.3 "Security of Koblitz curve"). Since Koblitz curve can be processed at high speed and has a track record of use, it is included in SEC 2. However, as it is the curve in a restricted class, attention should be paid to the possibility that attacks specific to that class may emerge (see 2.4.2.3 "Security of Koblitz Curve").

It appears that the specifications of ECIES in SEC1 are slightly different from the system described in papers [1], [2] and [3]. It has been proved that the scheme described in paper [1], [2] and [3] is semantically secure under adaptive chosen ciphertext attack (IND-CCA2) based on the adaptive hash Diffie-Hellman independence assumption [1] (or the oracle Diffie-Hellman assumption [2] [3]), when the ENC and MAC are secure. However, since these assumptions were presented only recently, its adequacy must be reviewed carefully. In addition, it appears that the specifications of ECIES in SEC1 are different from those of papers [1], [2] and [3] in some points, attention should be paid also to the validity of the argument on the provable security.

On the other hand, it has been pointed out by evaluators of full evaluation in 2000 that the security of ECIES in SEC1 can be reduced to the Gap-Diffie-Hellman problem assuming the KDF is the random function. (The Gap-Diffie-Hellman problem is the problem to solve the DH problem, having access to an DDH oracle.) In other words, it has been pointed out that ECIES in SEC1 is semantically secure under adaptive chosen ciphertext attack (IND-CCA2) in the random oracle model, based on the Gap-Diffie-Hellman assumption, when the ENC and MAC are secure. Note that attention should be paid to the Gap-Diffie-Hellman problem, because it is a relatively new problem.

2.5.1.4 Latest development

Since no specific problem was presented on the security of ECIES in SEC1 in the evaluation of 2000, we handled this cryptosystem as the one under observation in the evaluation of 2001. However, V. Shoup pointed out a problem on ECIES [7] recently, so it is required to make continuous evaluation of the security including this problem.

References [1] M. Abdalla, M. Bellare and P. Rogaway, ``DHAES: An encryption scheme based on the Diffie-Hellman Problem'', submission to IEEE P1363a, September, 1998. [2] M. Abdalla, M. Bellare and P. Rogaway, “The Oracle Diffie-Hellman Assumptions and an Analysis

73 CRYPTREC 2001

of DHIES”, Topics in Cryptology, - CT-RSA 2001, LNCS 2020, pages 143-158, Springer-Verlag, 2001. [3] M. Abdalla, M. Bellare and P. Rogaway, “DHIES: An encryption scheme based on the Diffie-Hellman Problem”, a full version of [4] [2], September 18, 2001. Available at http://www-cse.ucsd.edu/users/mihir/ [4] M. Bellare and P. Rogaway, “Minimizing the Use of Random Oracles in Schemes ”, Information and Communications Security, LNCS 1334, pages 1-16, Springer-Verlag, 1997. [5] Certicom Research, standards for efficient cryptography group (SECG), September 20, 2000. Version 1.0. Available at http://www.secg.org/ [6] IEEE P1363a/D9 - standard specifications for public key cryptography: Additional techniques, June 2001. Draft version 9. [7] V. Shoup, “A Proposal for an ISO Standard for Public Key Encryption”, Version 2.0, September 17, 2001. Version 2.1, December 20, 2001. Available at http://shoup.net/papers/

2.5.2 ECDH in SEC1

2.5.2.1 Technical overview

ECDH in SEC1 is a public key cryptosystem designed by SECG (Standards for Efficient Cryptography Group) that adopts a key agreement system using an elliptic curve. This cryptosystem was submitted to CRYPTREC for evaluation in 2000 as ECDHS in SEC1, and in 2001, it was submitted as ECDH in SEC1. Note that they are the same system.

2.5.2.2 Technical overview

The specifications of ECDH in SEC1 (general) are as follows. See the specification for details.

Elliptic curve parameters (i) (p, a, b, G, n, h) or (ii) (m, f(x), a, b, G, n, h):

(i) A parameter consisting of a prime p specifying the finite field p, two elements a, b Î p specifying 2 3 the elliptic curve defined by the equation E: y = x + ax + b (a,b Î p), a base point G on E ( p), a prime n which is the order of G, and an integer h which is the cofactor h = # E ( p)/n.

(ii) A parameter consisting of an integer m specifying the finite field 2m, an irreducible binary

polynomial f(x) of degree m specifying the representation of 2m, two elements a, b Î 2m specifying 2 3 2 the elliptic curve defined by the equation E: y + xy = x + ax + b (a,bÎ 2m), a base point G on E ( 2m),

a prime n which is the order of G, and an integer h which is the cofactor h = # E ( 2m) /n. KDF: Key Derivation Function

74 CRYPTREC 2001

Initialization:

1. Users U and V decide key derivation function (KDF) and elliptic curve parameters ((p, a, b, G, n, h) or (m, f(x), a, b, G, h, h)).

2. Users U and V generate private keys dU, dV and public keys QU, QV for U and V respectively.

• User U: Selects an integer dU Î [1, n - 1] at random, and calculates QU = dUG.

• User V: Selects an integer dV Î [1, n - 1] at random, and calculates QV = dVG.

Key agreement: Users U and V generate the shared key information K as follows.

• User U: Calculates the x-coordinate of dUQV, Z = x (dUQV) and then K = KDF (Z).

• User V: Calculates the x-coordinate of dVQU, Z = x (dVQU) and then K = KDF (Z).

2.5.2.3 Security evaluation

The security of ECDH in SEC1 is based on the elliptic curve discrete logarithm problem.

At present, various attacks against the elliptic curve discrete logarithm problem are known. In ECDH in SEC1, elliptic curve parameters, to which existing attacks cannot be applied in practically valid number of bits, are specifically presented in SEC 2 document. (Note that these are recommended parameters, and the use of other elliptic curves is also allowed.) These elliptic curves consist of the ones selected at random in verifiable forms and the one called Koblitz curve (see 2.4.2.3 "Security of Koblitz curve"). Since Koblitz curve can be processed at high speed and has a track record of use, it is included in SEC 2. However, as it is the curve in a restricted class, attention should be paid to the possibility that attacks specific to that class may emerge (see 2.4.2.3 "Security of Koblitz Curve").

ECDH in SEC1 is the Diffie-Hellman key agreement system that uses an elliptic curve, and it is the most basic key agreement system. No serious problems have been pointed out against passive attacks. However, it is not secure against active attacks, nor does it meet forward-secrecy. In particular, care must be taken when using a fixed key as the pair of private key d and public key Q.

Since it is necessary to assume active attacks when the key agreement system is actually operated, the use combined with a digital signature or the like should be reviewed. In this connection, some researchers have proposed a key agreement system which adopts ECDH in SEC1 primitive, is combined with a digital signature scheme, has provable security against active attacks, and achieves forward -secrecy.

Reference [1] Certicom Reserch, standards for efficient cryptography group (SECG), September 20, 2000 Version 1.0.

75 CRYPTREC 2001

2.5.3 DH

2.5.3.1 Technical overview

DH is a public key cryptosystem to achieve key agreement function that was proposed by W. Diffie and M.E. Hellman in 1976.

2.5.3.2 Technical specifications

Setting of a parameter common to the system

1. Prime number p is generated.

2. Let be the primitive element of order l.

Let (p, l, g) be the parameter common to the system.

Initialization by user A

1. Random number xA that meets 0 < xA < l is generated.

x 2. yA = g A mod p is calculated.

Let xA be a secret key, and yA a public key.

Initialization by user B

1. Random number xB that meets 0 < xB < l is generated.

x 2. yB = g B mod p is calculated.

Let xB be a secret key, and yB a public key.

Processing of key agreement

x A x B x A 1. Processing of A: K = yB mod p = g mod p

x B x A x B 2. Processing of B: K = yA mod p = g mod p According to the above, K is shared.

2.5.3.3 Security evaluation a) The scheme described in the previous section has a very simple basic form. Since there are many variations of protocols in Diffie-Hellman system, evaluation of individual protocols is required. (Examples of protocols actually used: RFC2631, ISO 11770-3, Oakley, PGP) The target of evaluation is basic schemes only. b) If passive attacks only are assumed, the basic part as a secret key protocol is reduced to Diffie-Hellman problem. However, in the sense that it cannot be distinguished from random bit strings,

76 CRYPTREC 2001

it is reduced to Decisional Diffie-Hellman problem by limiting the range or the like. Basically, a key derivation function that makes it indistinguishable from random bit strings should be used. c) In the scheme where a common secret is used as a session key, there are various factors that affect the security. The combination of these factors climbs up to an enormous number, so it is difficult to evaluate the security of every combination. The following are some examples of the factors to be taken into consideration. 1) Whether the pair of the key is static or ephemeral 2) Whether the correspondence between a public key and the entity is guaranteed or not (nocert/cert). Moreover, whether it is guaranteed that the entity has a corresponding secret key (strongcert). 3) Whether the public key is signed or not when it is exchanged (unsigned/signed). d) In the scheme where a symmetric key is used as a session key, the use in the form described in the previous section may raise problems, which will be described in the following section. Therefore, it is required at least to "provide the means to secure the comb ination of the key and the entity, and if used as a session key, a public key to be exchanged should be ephemeral." e) The following are examples of problematic combination and actual attacks. 1) When both keys are static Fixed-session-key attack: Since the session key is static, the use in counter mode reveals the secret if the same Vernam pad is used in each session. 2) When the combination of a secret key and a public key is not assured (not strongcert) Unknown key-share attacks: The attacker makes it appear as if the attacker himself is communicating by disguising that the public key of each user is the attacker's public key, thus intruding each user. 3) Others Captured session key attacks: When at least one is a fixed key, once the session key is revealed, the same session key will be used continuously afterwards. Key-translate attacks: In the case of nocert/unsigned, a-folding the key makes a different key to be shared. Reveal attacks: When the secret coin (information to be kept secret) is revealed during public WS operation, it affects other secret information (lack of forward secrecy). Attacks intrinsic 2-flow AKE (Authenticated Key-Exchange protocols): When there are only two flows, and the second flow is independent of the first, there arise problems such as no forward secrecy of strong-corruption model, and no A -to-B/B-to-A authentication. f) Some problems may be solved by making improvement on the system, for example, by using the signature for the public key in combination.

77 CRYPTREC 2001

Reference [1] W. Diffie and M. E. Hellman, “New directions in cryptography”, IEEE Trans. , vol. IT-22, pp.644-654, 1976

2.6 Evaluation of Cryptosystems that are the Target of Screening Evaluation

2.6.1 OK-ECDSA

2.6.1.1 Technical overview

OK-ECDSA is classified as a signature scheme. It is a modification of ECDSA that is standardized in ANSI X9.62 and so on. OK-ECDSA is designed for being implemented securely and efficiently on the . Its feature is to use Montgomery elliptic curve, and it adopts ECDSA as a signature scheme without making any modification.

The computation on Montgomery elliptic curve can be executed without using y coordinate of the point. The submitter insists that because of this, processing can be made at high speed without increasing the codes and memory sizes. The submitter also insists that since scalar multiplication can be executed in the same execution procedure without depending on the scalar value, which is a secret parameter, it has high resistance against timing attacks and SPA attacks. Furthermore, by using randomized projective coordinates, it also has the high resistance against DPA attacks , he also insists.

2.6.1.2 Result of screening evaluation

OK-ECDSA does not have provable security in the random oracle model. The resistance against side-channel attacks, which the submitter emphasizes, cannot be fully verified according to the description of the self-evaluation report only. n Provable security: OK-ECDSA is the same as ECDSA except for the type of an elliptic curve used. Since the provable security of ECDSA in the random oracle model has not been verified, OK-ECDSA does not have provable security in the random oracle model, either.

Although a reference shows a result that presented the proof of security of ECDSA in the generic group model[1], there are less academic research results on proof of security of a signature system in the generic model than that in the random oracle model. There is a negative opinion that the gap between ECDSA and that in the generic group model is not small. On the other hand, some people value the proof in the generic group model as an evaluation model against attacks that perform group calculation by making it a black box. The problem of the adequacy of the model or practical meaning has not been settled yet. n Security of primitives: The security of primitives is based on the discrete logarithm problem on

78 CRYPTREC 2001

Montgomery elliptic curve. Montgomery elliptic curve is a restricted class of curves, but there is an assumption that approximately 40% of Weierstrass elliptic curve can be converted [2], so it is considered that the degree of limitation is small. Moreover, attacks specifically against Montgomery elliptic curve have not been found.

The order of Montgomery elliptic curve can be divided by 4 without exception. Therefore, in order to assure the equivalent degree of security against the discrete logarithm problem where a normal curve with cofactor of 1 is used, it is recommended to make the size of the definition field of Montgomery elliptic curve larger by 2 bits, and use a curve with cofactor of 4. The submitter of OK-ECDSA also recommends the above. n Resistance against side-channel attacks: The degree of resistance of OK-ECDSA against side-channel attacks cannot be fully verified.

OK-ECDSA is designed for enhancing the resistance against side-channel attacks by specifying the concrete procedure of mu ltiplication by scalars. However, even with other signature systems such as ECDSA, the resistance can be enhanced by specifying another procedure of multiplication by scalars. Therefore, the measures by specifying the computation procedure are not unique t o OK-ECDSA.

There is a possibility that the resistance against side-channel attacks is greatly affected by the difference at the implementation level, in addition to the algorithm level including computation procedures as shown above. It is doubtful that the countermeasures by computational procedures only as in OK-ECDSA offer enough resistance against side-channel attacks. There is a possibility that the resistance shown by the submitter of OK-ECDSA may be based on a certain aspect only. As a case where the threat by side-channel attacks is great, the implementation on smart cards is considered. However, the self-evaluation report of OK-ECDSA shows no result of smart card implementation or the result of experiments on attacks. Therefore, it does not have foundation firm enough to eliminate the concern that it may be attacked due to the lack of careful implementation even if measures are taken in computational procedures.

Generally speaking, with regard to the resistance against side-channel attacks, there are no established open criteria with respect to the points to be considered to secure sufficient resistance. Therefore, full evaluation requires high cost. On the other hand, the objectivity to decide whether the evaluation is sufficient enough cannot be obtained easily. In order to properly evaluate the system that features the resistance against side-channel attacks, the establishment of an objective evaluation method is a hurdle to overcome. n Implementability: There is no inadequacy in the details of the cryptographic technique specification. It is considered that the implementation by the third person is possible.

The processing speed, program size, and memory size between the systems, to which countermeasures against side-channel attacks are provided at computational procedure level, can be compared. The

79 CRYPTREC 2001

self-evaluation report of OK-ECDSA shows a part of these comparisons from the viewpoint of the computation amount. The scalar multiplication specified in OK-ECDSA requires approximately 1/2 of that using the algorithm with dummy computation added, which indicates the high speed of OK-ECDSA. However, comparison of performances in the state where it is actually implemented to software or hardware was not made. Therefore, the superiority in implementation such as memory size or program size has not been verified.

References [1] D. Brown, “The exact security of ECDSA”, Technical Report CORR 200-34, Dept. of C&O, University of Waterloo, 2000. Available at http://www.cacr.math.uwaterloo.ca [2] T. Izu “Computation of elliptic curve cryptography", 1999 Ciphers and Information Security Symposium (SCIS'99), pp.275-280, 1999.

2.6.2 NTRU

2.6.2.1 Technical overview

NTRU is an encryption algorithm for confidentiality. Its operations are basically those of a polynomial ring with integer coefficients, and its security is considered to be associated with the shortest vector problem of a lattice.

2.6.2.2 Technical specifications

The basic operations of NTRU are shown below.

• Parameters N, p, q: positive integers. p, q, and XN - 1 are relatively prime R = [X] / (XN - 1) The operations of the polynomials are executed in the ring R. • Key generation f (X), g (X) Î [X]: randomly selected polynomials with small coefficients

-1 fq (X) º f (X) mod q –1 fp (X) º f (X) mod p

h (X) º pfq (X) g (X) mod q

¦ (X), ¦p (X) are private keys, and h (X) is a public key. • Encryption m (X)Î [X] : Message, a polynomial with its coefficients reduced mod p

80 CRYPTREC 2001

r (X)Î [X] : a randomly selected polynomial with small coefficients e (X) º r (X)h(X) + m (X) mod q : Ciphertext • Decryption a (X) º ¦ (X)e(X) mod p

d (X) º ¦ p(X)a(X) mod p: Decrypted message

In detailed specifications of NTRU, the operations such as message formatting must be performed in addition to the basic operations shown above. The description of such operations is omitted here.

2.6.2.3 Result of screening evaluation • The applicant emphasizes that the performance is faster than the existing public key cryptosystems. Though the performance measurement evaluation was not made in the screening evaluation, from a theoretical point of view, the argument of the applicant is considered to be adequate to a certain point. • About provable security the applicant insists that: (1)It becomes IND-CPA by random padding of the message. (2)IND-CCA2 can be achieved by applying Fujisaki-Okamoto conversion to IND-CPA. However, the argument (1) has not been proved. It is considered disadvantageous to a relatively new cryptosystem with not much experience in use that it does not have a proof of reduction to well-studied problems. • The security of NTRU is based on the shortest vector problem or the closest vector problem of a lattice. In the case of NTRU, the lattice in question is of a special form called CML (Convolution Modular Lattice). Therefore, there is a concern about the existence of attacks using special algorithms other than LLL algorithm for general lattices. The attention should be paid to the development of attacks against Convolution Modular Lattice. For example paper [1] discusses the attacks against NTRU when N is composite. Note, however, that if N is prime as listed in recommended parameters, this attack cannot be applied.

Reference [1] C. Gentry, Key Recovery and Message Attacks on NTRU-Composite, Advances in Cryptology— EUROCRYPT 2001, Springer-Verlag, LNCS 2045, pp.182-194 (2001).

2.6.3 HIME(R)

2.6.3.1 Cryptographic technique

HIME(R) is Rabin -OAEP using modulo N = pdq. A secret key consists of prime numbers p, q, a public key is an integer N, and the encryption of plaintext m and decryption of ciphertext y are performed as shown

81 CRYPTREC 2001

below.

Encryption

1. x ¬ OAEP encode of m. 2. y ¬ x2 mod N

Decryption

1/2 1. xi ¬ y mod N

2. mi ¬ OAEP decode of xi.

In the first step of decryption, square root calculation with modulo N is required. HIME(R) adopts an original algorithm using pq-base expansion of an integer instead of the well-known method using CRT [1]. The applicant insists the following.

1. HIME(R) can be proved to be secure against an adaptive chosen ciphertext attack in the random oracle model on the assumption that N = pdq type factorization problem is difficult.

2. HIME(R) performs encryption and decryption faster than RSA-OAEP.

2.6.3.2 Result of screening evaluation

The screening evaluation revealed that the cryptographic technique specification of HIME(R) had no problem even though some errors in description were found. However, its self-evaluation report had the problems as shown below.

1. It is indicated that HIME(R)’s square root calculation algorithm, used in the decryption process, is faster than the well-known method. However there remains some doubt about its effect in the practical situation. 2. The evaluation of the number of computations required to solve N = pdq type factorization problem is not sufficient enough. In order to calculate the specific bit length of secure N, quantitative evaluations of the number of computations of the number field sieve method and the elliptic curve method should be g iven based on experiments beyond the asymptotic level. 3. It is reasonable that HIME(R) becomes IND-CCA2 in the random oracle model, when compared with the results of others, for example, that Rabin-SAEP [2] is IND-CCA2. However, there remains some doubt about the validity of the proof of security presented in the self-evaluation report. 4. There is no description on the case where d = 2, 3 does not hold. So, it is not clear how to handle the cases where d is not equal to 2, 3.

The problems stated above are not serious enough to disprove the validity of the argument 1 and 2 by the applicant.

82 CRYPTREC 2001

References [1] T. Takagi, Fast RSA-type Cryptosystem Modulo pkq, Advances in Cryptology - CRYPTO ‘98, LNCS 1462, Springer-Verlag, pp. 318-326, 1998. [2] D. Boneh, Simplified OAEP for the RSA and Rabin functions, Advances in Cryptology - CRYPTO 2001, LNCS 2139, Springer-Verlag, pp. 275-291, 2001.

2.6.4 OK-ECDH

2.6.4.1 Technical overview

OK-ECDH is classified as a key agreement scheme. It is a modification of ECDH that is standardized in ANSI X9.63 and so on. OK-ECDH is designed for being implemented securely and efficiently on the smart card. Its feature is to use Montgomery elliptic curve, and it adopts ECDH as a key agreement scheme without making any modifications.

The computation on Montgomery elliptic curve can be executed without using y coordinate of the point. The submitter insists that because of this, processing can be made at high speed without increasing the codes and memory sizes. The submitter also insists that since scalar multiplication can be executed in the same execution procedure without depending on the scalar value, which is a secret parameter, it has high resistance against timing attacks and SPA attacks. Furthermore, by using randomized projective coordinates, it also has high resistance against DPA attacks, he also insists.

2.6.4.2 Result of the screening evaluation

OK-ECDH does not have provable security in the random oracle model. The resistance against side-channel attacks, which the submitter emphasizes, cannot be fully verified according to the description of the self-evaluation report only. n Provable security: OK-ECDH is the same as ECDH except for the type of an elliptic curve used. Even though the problems of ECDH against passive attacks have not been found, it has been pointed out that ECDH is weak against active attacks. It is recommended to use ECDH in combination with the signature system. n Security of primitives: The security of primitives is based on the discrete logarithm problem on Montgomery elliptic curve. Montgomery elliptic curve is a restricted class of curves, but there is an assumption that approximately 40% of Weierstrass elliptic curve can be converted [1], so it is considered that the degree of limitation is small. Moreover, attacks specifically against Montgomery elliptic curve have not been found.

83 CRYPTREC 2001

The order of Montgomery elliptic curve can be divided by 4 without exception. Therefore, in order to assure the equivalent degree of the security against the discrete logarithm problem where a normal curve with cofactor of 1 is used, it is recommended to make the size of the definition field of Montgomery elliptic curve larger by 2 bits, and use a curve with cofactor of 4. The submitter of OK-ECDH also recommends the above. n Resistance against side-channel attacks: The degree of resistance of OK-ECDH against side-channel attacks cannot be fully verified.

OK-ECDH is designed for enhancing the resistance against side-channel attacks by specifying the concrete procedure of multiplication by scalars. However, even with other key agreement schemes such as ECDH, the resistance can be enhanced by specifying another procedure of multiplication by scalars. Therefore, the measures by specifying the computation procedure are not unique to OK-ECDH.

There is a possibility that the resistance against side-channel attacks is greatly affected by the difference at the implementation level, in addition to the algorithm level including computation procedures as shown above. It is doubtful that the countermeasures by computational procedures only as in OK-ECDH offer enough resistance against side channel attacks. There is a possibility that the resistance shown by the submitter of OK-ECDH may be based only on a certain aspect. As a case where the threat by side-channel attacks is great, the implementation on smart cards can be considered. However, the self-evaluation report of OK-ECDH shows no result of smart card implementation or the result of experiments on power analysis attacks. Therefore, it does not have foundation firm enough to eliminate the concern that it may be attacked due to the lack of careful implementation, even if measures are taken in computational procedures.

Generally speaking, with regard to the resistance against side-channel attacks, there are no established open criteria for the points to be considered to secure sufficient resistance. Therefore, full evaluation requires high cost. On the other hand, the objectivity to decide whether the evaluation is sufficient enough cannot be obtained easily. In order to properly evaluate the system that features the resistance against side-channel attacks, the establishment of an objective evaluation method is a hurdle to overcome. n Implementability: There is no inadequacy in the details o f the cryptographic technique specification. It is considered that the implementation by the third person is possible.

The processing speed, program size, and memory size between the systems, to which countermeasures against side channel attacks are provided at computational procedure level, can be compared. The self-evaluation report of OK-ECDH shows a part of these comparisons from the standpoint of the computation amount. The scalar multiplication specified in OK-ECDH requires approximately 1/2 of that using the algorithm with dummy computation added, which indicates the high speed of OK-ECDH. However, comparison of performances in the state where it is actually implemented to software or hardware was not made. Therefore, the superiority in implementation such as memory size or program size cannot be

84 CRYPTREC 2001

verified.

Reference [1] T. Izu “Computation of elliptic curve cryptography", 1999 Ciphers and Information security Symposium (SCIS'99), pp.275-280, 1999.

2.6.5 PSEC-KEM

2.6.5.1 Technical overview

PSEC-KEM is a key encapsulation mechanism in a sense described in [2] that uses an elliptic curve ElGamal cipher as a primitive. According to [2], the key encapsulation mechanism can be used as a component of construction of hybrid cipher. The key encapsulation mechanism consists of an encryption algorithm E and a decryption algorithm D, and the encryption algorithm E outputs ciphertext c0 and shared key k from the input of the public key of the receiver. The decryption algorithm D outputs for the shared key k that is the same as the encryption side from the input of the receiver’s secret key and ciphertext c0.

PSEC-KEM was submitted for CRYPTREC2001 as a revised version of PSEC-2 (that was submitted for CRYPTREC2000 and that is used for the purpose of confidentiality). However, as a result of the review by Public-key Cryptography Subcommittee, a screening evaluation of PSEC-KEM was conducted as a "new application."

2.6.5.2 Result of screening evaluation

Provable security

In [2], the definition of IND-CCA2 ( against adaptive chosen ciphertext attack) as a key encapsulation mechanism is described. According to the argument of the applicant, the feature of PSEC-KEM is to have the provable security in the sense described above in the random oracle model, on the assumption of the difficulty or ECDH. In the self-evaluation report, it is proved that if an attacker Adversary A with the following capability is used, the algorithm to compute the ECDH problem can be constructed:

Adversary A: When a ciphertext c0 and bit string k* are given, it can judge whether the bit string k* is a random or the correct key.

The screening evaluation revealed the following.

• The definition of provable security of the key encapsulation mechanism shown in [2], is considered reasonable. However, it is not shown whether IND-CCA2 is the strongest, since the definition of the security of the key encapsulation mechanism is different from that of the public key encryption in [1].

85 CRYPTREC 2001

• There are no problems in the proof of IND-CCA2 in the self-evaluation report. • The concept of the random oracle model is generally known as an effective method of proving the security of encryption schemes, so it is considered reasonable.

However, one evaluator points out that this cryptographic scheme does not present provable security of the key agreement system in general, since there is no argument on a security model of the key agreement system.

Others

• The self-evaluation report describes the comparison between a cryptosystem used for the purpose of confidentiality. It is pointed out, however, that since the definition of types and the security of the submitted cryptosystem and the one used for the purpose of confidentiality are different, comparison cannot be made. • With regard to an elliptic curve parameter used as a primitive, the report only suggests that SECG be referred to. There is an opinion that the report lacks self-completeness as a specification.

References [1] M. Bellare, A. Desai, D. Pointcheval, and P. Rogaway, “Relations Among Notions of Security for Public-Key Encryption Schemes,” Proc. of Crypto’98, Springer-Verlag, LNCS 1462, pp.26-45 (1998). [2] : “A Proposal for an ISO Standard for Public Key Encryption,” Available at http://shoup.net/papers/

86 CRYPTREC 2001

3 Evaluation of symmetric-key cryptographic techniques

3.1 Evaluation method

3.1.1 Evaluation method of symmetric-key ciphers

3.1.1.1 Security evaluation

The security of cryptography is classified into two categories: the security based on the amount of information (information-theoretic security), and the security based on computational complexity (computational security). The information-theoretic security is a theory presented by Shannon. To put the theory into practice, the amount of keys must be larger than the amount of plaintext, which is not practicable. The security of symmetric-key cipher is indicated not by the amount of information but by computational complexity. The computational security can also be expressed as the degree of difficulty of estimating a secret key. However, there is no absolute method of evaluating the computational security at present. Therefore, the security is evaluated by actually carrying out attacks, thereby assessing the cost required (such as the computational complexity, the amount of data and memory). Since attacks are actually carried out, it is predicated that the encryption algorithm is known to the public. Depending on the available information conditions, the attacking methods are classified as follows.

• Ciphertext only attack only can be used. • Known plaintext attack Ciphertexts corresponding to respective can be used. The attacker carries out an attack by using pairs of p laintext and ciphertext obtained in some way. • Chosen plaintext attack Plaintexts freely selected by the attacker and corresponding ciphertexts can be used. The attacker can control the cryptosystem to be attacked and use pairs of plaintext and ciphertext that is useful for the attack.

The degree of difficulty of attacks varies depending on the information available. The more latter is attack available, the more advantageous the situation becomes for the attacker. It is assumed that the cipher that can be attacked by ciphertext only attack is not secure enough. In the attacks where the plaintexts corresponding to the sufficient amounts of ciphertext are known, if the attacker have unlimited computational power, a secret key can be found by an exhaustive key search without fail. Theoretically, it is judged that the attack is successful if the cost required by the attack is less than that of the exhaustive key search. To be more specific, if a method of attacking a cipher that uses a k-bit secret key is found with the cost less than 2k, it is judged that the cipher is not secure. Considering the present situation shown by DES Challenge III (DES cryptanalysis contest held in January 1999. Discovery of 56-bit user key took 22 .)

87 CRYPTREC 2001

and the high speed of the development of processing techniques, it is estimated that the cost of around 264 can be processed.

There may be a case where an attack may be carried out at a cost lower than 2k (>264) but no practical problems arise. However, with the above situations taken into account, long-term use of this type of cipher is not recommended. Attacks are divided into the following two classes: general attacks that can be applied to ciphers included in the category, and the attacks specialized for certain ciphers. Symmetric-key ciphers include 64-bit block ciphers, 128-bit block ciphers, and stream ciphers. Section 3.2.1 describes the security evaluation of 64-bit block ciphers, 3.2.3 describes that of 128-bit block ciphers, and 3.2.5 describes that of stream ciphers.

3.1.1.2 Block ciphers

The strength of block ciphers against the following general attacks was evaluated this time.

• Differential cryptanalysis • • Higher order differential attack

In addition, was assessed to evaluate the statistical characteristics of the output. n Differential cryptanalysis /Linear cryptanalysis: The differential cryptanalysis was proposed by Biham and Shamir in 1990. It was proposed as an attack against DES, but it can be generally used for block ciphers as a whole. This attack is one of the chosen plaintext attacks that are effective with regard to two pairs of plaintext/ciphertext, if a correlation exists between the difference between each plaintext and the difference between each ciphertext. The linear cryptanalysis was proposed by Matsui of Mitsubishi in 1993. Just as with the differential cryptanalysis, it was proposed as an attack against DES, but it is a general attack applicable to block ciphers as a whole. This attack is one of the known plaintext attacks that can be applicable when there is a correlation between XOR of specific input bits and that of specific output bits. The resistance against these is expressed in terms of the maximum differential/linear probability. If the probability is small enough, the security is assured. However, since it is difficult to calculate the true value of the maximum differential/linear probability, the maximum differential/linear characteristic probability may be used instead.

These can be found by using the following methods.

• To find the upper bound of the probability by evaluating each component. • Computer search

88 CRYPTREC 2001

n Provable security against differential cryptanalysis/linear cryptanalysis: Some cryptographic techniques presented the provable security against differential/linear cryptanalysis in the argument of the submitted reports. Nyberg proved mathematically in 1992 that with regard to a block cipher with Feistel structure, when the maximum differential probability of round function is p, and the number of rounds is 4 or more, the maximum differential probability of the cipher as a whole is 2p2 or less. She then gave the same kind of index to the linear cryptanalysis also, and integrated them into one as the provable security against the differential/linear cryptanalysis. It was then developed by Matsui, Aoki, and others into a more sophisticated argument. It is the argument that can mathematically prove a specific kind of security, but note that it is effective only for differential and linear cryptanalysis. n Higher order differential attack: The higher order differential attack was proposed by Lai in 1994, and in 1997, Knudsen and Jakobsen used it in an attack against KN cipher that is an experimental block cipher. It is one of the chosen plaintext attacks applicable when the higher order differential value of the output becomes a constant that does not rely on the fixed value of the plaintext and the expanded key. KN cipher has the provable security against differential/linear cryptanalysis described above, but since its algebraic degree is low, it was proved that the cipher is vulnerable to attacks by higher order differential attack. The effect of the attack depends on the order used, and the lower the order is, the smaller the cost is. On the other hand, the algebraic degree of the output depends on which bits of the plaintext become the variable, the lowest order required for the attack is determined by the way how they are selected. However, the optimal selection method has not been found yet. In the case of N-bit input/output cipher, even if all the input bits become variables, the algebraic degree of the output does not exceed N. In general, however, it is judged that when the formal algebraic degree of the output block exceeds N, it is secure against the higher order differential attack. n Avalanche effect evaluation: In avalanche effect evaluation, the appearance frequencies of differences per output bit position is assessed with regard to the output difference when a specific difference is given to the input. The behavior per output bit position can be known by the evaluation. In this evaluation, the encryption algorithm is handled like a black box, and by digitizing the evaluated quantity, a unified comparison that is not affected by the difference of structure can be made.

With regard to input/output data of the encryption including the part, key schedule part and round function, the appearance frequencies of differences, diffusion of differences, coefficient of correlation, and effective key quantity were investigated.

It can be said that all the symmetric-key ciphers consist of the following parts. • Round function • Data randomization part • Key schedule part

89 CRYPTREC 2001

Therefore, avalanche effect evaluations were conducted on the following.

• Round function • Data randomization part • Key schedule part • Encryption including the key schedule part

Evaluated items

The following items were evaluated in avalanche effect evaluation. • AVA (Appearance frequencies of differences) The difference between frequency at which the output differences become 1 and that become 0. In the investigation conducted this time, the of input difference DX and key difference DK were evaluated with regard to m = 1, 2. • AVD (Diffusion value of differences) The mean value of the Hamming weight of output differences • CC (Coefficient of correlation in the state where differences have appeared) Coefficient of correlation at i-bit position and j-bit position of output difference values • UKV (Effective key quantity) The percentage of evaluated values of AVA that meet the relative standard value when the key difference of Hamming weight 1 is given.

The target of statistical characteristics investigation of component and of the overall algorithm of symmetric-key cipher are roughly divided into the following two.

• Correlation of the input and the output • Correlation of the key and the output

Statistical verification procedure In order to conduct such statistical verifications, pseudorandom number generation function is required. Moreover, sequence of pseudorandom numbers must be generated using the pseudorandom number generation function.

Collective analysis of the data thus obtained is conducted on the basis of the following conditions.

• It is regarded that there is no statistical bias if the worst deviation rate of AVA is lower than the relative standard value. • The closer AVD is to n/2, the smaller the statistical bias is (n: output data length). • The absolute value of CC is 1 or less, and the closer it is to 0, the higher its degree of independence is. • The closer UKV is to the key length, the better.

90 CRYPTREC 2001

3.1.1.3

The stream cipher generally uses the output from pseudorandom number generator as its key sequence, and its initial value is used as a secret key. To evaluate the statistical characteristics of the output sequence, the following items listed in FIPS 140-1/2 were tested.

• Long periodicity • Linear complexity • Equal 0/1 frequency • Monobit test • Poker test • Runs test • Long runs test

Since the result of these tests shows only the statistical characteristics, even if the result of such statistical characteristics evaluation is good, it cannot be judged that the cipher is secure. Therefore, the resistance against general attacks such as Divide-and-Conquer attack and was also evaluated as in the case of block ciphers.

3.1.1.4 Software implementation evaluation

In addition to the security of ciphers, it is necessary to take their implementability into consideration by assuming the actual use conditions. The requirement for the implementation of ciphers in e-Government is not clear at present. In evaluating the software implementation, the following three environments were assumed: a PC environment that is considered to be popular at the time of evaluation, a server environment that is considered to have most widely spread at present, and a high-end environment that realizes high performance. Since all the cryptographic techniques submitted for evaluation assume the general PC environment, all the submitted techniques were evaluated from this perspective. The other two environments were left to the applicants ’ own choices in deference to the design concept of each cipher. Evaluations should have been made on a low spec environment such as 8-bit CPU, but since the period of evaluation was limited, the evaluations were not carried out this time. The evaluation of software was not carried out with regard to the hash function and the pseudorandom number generator.

The programs were implemented by the applicants, and the measurements were made in the presence of the committee members. The same platforms and measurement programs were used for evaluations, thus ensuring the conditions as fair as possible. Values different from those listed in this report may appear in other documents, which result from the difference of measurement programs and measurement environments. Even if the same platform and measurement programs are used, the evaluation results are influenced greatly by the combination of operating systems and resident programs. Therefore, it should be

91 CRYPTREC 2001

noted that those values cannot always be achieved. This evaluation of software implementation was made to compare the encryption speed of the submitted ciphers. Table 3.1 shows the platform environments used.

Table 3.1: The environments used for software implementation evaluation

PC environment CPU Pentium III (650MHz) OS Windows98 SE Memory capacity 64MB Compiler Visual C++ Ver6.0 SP3 Server environment CPU Ultra SPARC IIi (400MHz) OS Solaris 7 Memory capacity 256MB Compiler Forte C 6 High-end environment CPU Alpha 21264 (463MHz) OS Tru64 UNIX V5.1 Memory capacity 512MB Compiler DEC C

With regard to block ciphers, the following two parts were measured.

• Data randomization part • Key schedule part + Data randomization part

The data randomization part was measured by counting the number of cycles of the CPU (the number of computations not dependent on the operating frequency of the CPU) required for encrypting a 64-bit plaintext to a ciphertext in the case of a 64-bit block cipher. In the case of a 128-bit block cipher, a 128-bit plaintext is encrypted to a 128-bit ciphertext. After a key was set, encryption (decryption) of 1MB plaintext (ciphertext) was made and measurements were taken. Therefore, the number of computations for key setup can be negligible. Encryption (decryption) of 1MB text was made 128 times in one measurement, and the fastest value and the average value were taken. Measurements were taken three times.

In the measurement of the key schedule part and the data randomization part, a key was set up per encryption (decryption) of one block. Other measurement conditions were the same as the data randomization part. Note, however, that the value obtained by subtracting the value of data randomization part from this value cannot always represent the speed of the key schedule part itself, because of the difference of implementation method.

Because there is no key setup in stream ciphers, only the data randomization part was measured. Note that

92 CRYPTREC 2001

since the measurement program that was the same as 64-bit block cipher was used, the implementability of the stream cipher may have been sacrificed. In terms of the purpose of use, stream ciphers are more hardware-oriented than block ciphers, so the evaluation should be focused on the hardware, and not the software. Therefore, the software evaluation of stream ciphers was made in order to check if the cipher has the minimum requirement performance to endure the most severe use conditions, with the software implemented.

3.1.1.5 Hardware implementation evaluation

In order to check the “utilizable condition,” hardware implementation status of symmetric-key cipher was evaluated. The throughput and the resources used (number of cells used for FPGA, and the number of gates used for GA) were evaluated per process used (FPGA, GA). Concerning the targets of hardware evaluation in 2000, those with the application document on which the implementation information (result) was listed were evaluated. The throughput and resource consumption were assessed on the basis of the simulation evaluation result, and the adequacy of information listed on the application document were verified. The “utilizable condition” indicates that the cipher can be implemented not only theoretically but also practically and that it has the function to meet the requirements of the category it was entered for evaluation. n Block cipher evaluation procedure: The target devices for evaluation use ASIC libraries of 0.25 to 0.35 mm design rules, Verilog-HDL hardware description , and a design compiler for circuit synthesis. Triple DES (3-Key) that is considered to be evaluated was also evaluated as an index of a relative evaluation. It should be noted, however, that the throughput and the gate size should be regarded only as references because implemented architecture and the condition of optimization are depended on. Although the result is affected greatly by the experience of the person who does the implementation, the performance of throughput and gate size is expected to be improved (faster speed and smaller size). n Stream cipher evaluation procedure: In hardware implementation evaluation of stream ciphers, circuit coding was made via Verilog-HDL using the C language program on the FPGA by Altera Corporation, and simulation was performed. Since stream ciphers are implemented on hardware in many cases, preference was given to the design condition that put priority to throughput on condition that it has an adequate circuit size. The development environments used for hardware implementation evaluation are as follows.

• ModelSim VHDL/Verilog Version 5.4e (Model Technology) • Synplify (Synplicity Inc.)

93 CRYPTREC 2001

3.2 Overall evaluation

3.2.1 64-bit block ciphers

Four types of block ciphers, CIPHERUNICORN-E, Hierocrypt-L1, MISTY1, and Triple DES - were evaluated. We did not receive new applications for this category in 2001. The ciphers submitted for evaluation in 2000 were CIPHERUNICORN-E, Hierocrypt-L1 and MISTY1, and Triple DES was added for evaluation in 2000 as a cipher considered to be evaluated. The overview of the evaluation is shown below. n Characteristics: The organization that proposed the technique, the year it was announced, its structural characteristics, and the characteristics such as the operations used in the data randomization part were listed. For those techniques that use variable parameters such as number of rounds, the values recommended by the proposing organizations were listed. n Security: Security is discussed from the following three viewpoints: resistance to differential/linear cryptanalysis, resistance to algebraic and other attacks, and avalanche effect characteristics.

• In resistance to differential/linear cryptanalysis, the maximum differential/linear probability or the maximum differential/linear characteristic probability is indicated as the index of strength against differential/linear cryptanalysis, which is a general probability-based attacking method. • In resistance to algebraic and other attacks, resistance to higher order differential attack and , and algebraic methods such as SQUARE attack, as well as the resistance to other attacks such as related-key attack and mod n attack, are described. The evaluation of higher order differential attack and interpolation attack is a method to search for basic weakness of a cipher from the algebraic point of view. If the number of rounds is large, an attack based on this method rarely causes problems. However, the weakness revealed by those attacks may affect the ultimate cipher strength, if other attacks can be combined with it. • Avalanche effect evaluation statistically captures how data is shuffled in each cipher, and although it does not directly lead to cryptanalysis in most instances, it provides a clue to search for weaknesses of the partial function of a cipher. n Software implementation evaluation: The evaluation was made in 2000. A cipher must be considered not only from the standpoint of security but also from the standpoint of implementation by assuming the actual use conditions. Although the requirements for cipher implementation in e-Government have not been made clear, our software implementation evaluation assumed the following three environments: a PC environment that was considered to be popular at the time of evaluation, a server environment that is currently considered to be most widely used, and a high-end environment that has achieved high performance. Measurements were taken in two parts: the data randomization part and the key schedule + data randomization part.

94 CRYPTREC 2001

n Hardware implementation evaluation: The evaluation was made in 2000. The target device for evaluation used ASIC libraries of 0.25 to 0.35 mm design rules, Verilog-HDL hardware description language, and a design compiler for circuit synthesis. Note that the throughput and the gate size should be regarded only as references, because the implementation architecture and condition of optimization are depended on. Although the result is affected greatly by the experience of the person who does the implementatio n, the performance of throughput and gate size is expected to be improved (faster speed and smaller size). n Overall evaluation: Table 3.2 shows the overall evaluation results of security and implementation.

Table 3.2: Overall evaluation

UNI-E Characteristics NEC (1998) Feistel structure, 16 rounds. The round function is complex. Consists of a main stream and a temporary key-generation part to be expected to enhance security. F-function uses S-box as the basic component and consists of T-, K-, and Y-functions. Four types of 8x8 S-boxes. Designed based on inverse operations on GF(28) and has resistance against differential/linear cryptanalysis. Table look up, addition, XOR, AND, and shift operation. Designed with a round function structure to make significant correlation invisible from cipher-evaluation systems. Overall evaluation No security problem has so far been found. Belongs to a group with slow processing speed. HC-L1 Characteristics Toshiba (2000) Recursive SPN structure, six rounds. Each round consists of two parallel XS-functions and a P-layer. XS-function has a structure in which a P-layer is sandwiched between four parallel S-boxes of two layers. One type of 8x8 S-box. Designed based on power multiplication operations on GF(28) and has resistance against differential/linear cryptanalysis. Table look up, XOR, and AND. Achieves both security and computational efficiency using a recursive SPN structure. For the design of the P-layer, the lower bound of the number of active S-boxes is guaranteed by the . Overall evaluation No security problem has so far been found. Belongs to a group with fast processing speed. MISTY1 Characteristics Mitsubishi (1996) Feistel structure, eight rounds. FL-function is inserted for every two rounds. A modified Feistel structure is recursively used in the internal structure of the round function. Two types (7x7 and 9x9) of S-boxes. Designed based on power multiplication operations on the extension field, and has resistance against differential/linear cryptanalysis. Low algebraic degree in consideration for hardware implementation. Table look up, XOR, AND, and OR. Provable security against differential/linear cryptanalysis. The origin of the KASUMI cipher for the next -generation mobile phones. Overall evaluation No security problem has so far been found. Belongs to a group with fast processing speed.

95 CRYPTREC 2001

Triple DES Characteristics (3-Key) IBM (1979) Combination cipher that repeats DES three times. DES was standardized as FIPS in 1977. DES is a Feistel structure with 16 rounds. Eight types of 6x4 S-boxes. Selected from randomly configured S-boxes using a certain evaluation standard. Table look up, XOR, and cyclic shift operation. Hardware-oriented design. DES is a historic cipher with more than 20 years of use, and is the root of modern ciphers. FIPS is expected to be succeeded by AES. Overall evaluation There seems to exist no problems on security as far as it is guaranteed by FIPS or the like.

3.2.2 Overall security evaluation n Resistance against differential/linear cryptanalysis: The resistance against differential/linear - analysis can be expressed by the maximum differential/linear probability. MISTY1 and Hierocrypt-L1 guarantee security in terms of the probability. MISTY1 shows the probability of 2-56 or lower with three rounds, which is considered secure enough against differential/linear cryptanalysis. Hierocrypt-L1 guarantees a probability of 2-48 or lower with two rounds. This guarantee is called provable security against differential/linear cryptanalysis.

Because it is difficult to determine the true value of the maximum differential/linear probability, maximum differential/linear characteristic probability is used as a corresponding index. The following methods are used for evaluating the maximum characteristic probability:

• A method that determines the upper bound of characteristic probability based on the maximum differential/linear probability of the components • A method that determines maximum characteristic probability through computer searches

Hierocrypt-L1 and CIPHERUNICORN-E are considered to offer the upper bound of characteristic probability. The former has been shown not to exceed a differential/linear characteristic probability of 2-90 in two rounds.

CIPHERUNICORN-E cannot be analyzed easily because its round function has a complex structure. In the self-evaluation report, differential/linear characteristic probability is estimated by using the simplified round function. The validity of this simplification was checked and the adequate estimating methods were studied this year. We consigned the evaluation to two domestic and two overseas research organizations and further detailed review was done. It resulted in evaluations of the round function different from those described in the self-evaluation report. However, it was concluded that the specified 16-round CIPHERUNICORN-E has sufficient security against differential/linear cryptanalysis.

The technique that regards it as the proof of security that the characteristic probability of 64-bit block ciphers is 2-64 or lower is called practical security against differential/linear cryptanalysis. As is shown

96 CRYPTREC 2001

above, the resistance against differential/linear cryptanalysis of the 64-bit block ciphers evaluated this time is academically guaranteed. n Resistance against algebraic and other attacks: Higher order differential attack or interpolation attack uses an expansion in Galois field GF(2) or an appropriate extension field of an encryption function. Although this attack cannot easily be applied to a cipher with a large number of rounds basically, it is often relatively effective against a cipher that has been designed with enhanced consciousness given to the resistance against differential/linear cryptanalysis. Resistance against higher order differential attack is given as an algebraic degree of the encryption function. However, this degree and the number vary depending on how input variables are chosen and how the output variables to be focused on are selected. Thus it is computationally impossible to find the minimum value from all possible combinations. CRYPTREC focused on the components of the encryption function, evaluated the nominal algebraic degree of cipher based on the algebraic degree. Also we performed the following two evaluations using a single S-box input as the variable.

• Resistance against higher order differential attack of eighth order or lower, with a single S-box input used as the variable • Resistance against higher order differential attack based on the bijective nature of the S-box (resistance against SQUARE attack ) As a result, it was verified that all of the ciphers had resistance against these attacks at the proposed number of rounds. Hierocrypt-L1 and MISTY1 can be broken to a larger number of rounds by applying higher order differential attack than when differential/linear cryptanalysis is applied. Using 237 plaintext pairs and 2117 computations with 32nd order higher order differential attack (32nd order SQUARE attack), Hierocrypt-L1 can be broken to 3.5 rounds. A modified MISTY1 without FL-function can be broken to six rounds using 211 plaintext pairs and 293 computations with 7th order higher order differential attack. MISTY1 can be broken to five rounds using 222 plaintext pairs and 233 computations.

Resistance against interpolation attack (or linear sum attack, which is a generalized form of interpolation attack) is given as the number of unknown interpolation coefficients, when the encryption function is expressed as an interpolation polynomial. However, this number varies depending on how input variables are chosen and how the output variables to be focused on are selected. Therefore, it is impossible to exhaust all possibilities because of the massive number of computations needed. CRYPTREC divided plaintext into eight small blocks in 8-bit units (64-bit block cipher), and evaluated resistance against linear sum attacks when these small blocks were expressed as polynomial basis of a Galois field GF(28). No attacking method that is more efficient than the exhaustive key search has been discovered for any of the ciphers.

Although Triple DES (3-key) can be theoretically broken with 256 chosen plaintexts and 2108.2 computations, using a meet-in-the middle attack that capitalizes on Triple DES’s being a combination cipher, it is considered secure for all practical purposes.

97 CRYPTREC 2001

No security problems of any of the ciphers have so far been reported from a practical viewpoint for other attacks such as chi-square attack, impossible differential cryptanalysis, , mod n attack, and non-surjective attack. n Avalanche effect evaluation: The evaluation was made in 2000. All algorithms satisfied the expected values in terms of the overall encryption that includes key schedule part. However, for the key schedule part alone, parts that do not satisfy the expected values were detected in Hierocrypt-L1 and MISTY1. Also, for the round function alone, parts that do not satisfy the expected values were detected in Hierocrypt-L1 and MISTY1.

Table 3.3: Avalanche effect evaluation

UNI-E No characteristics could be seen in the round function. In the data randomization part, no characteristics could be seen in the randomization in the fourth round and beyond. No characteristics could be seen in the key schedule part. Hierocrypt-L1 Some parts deviated from the expected values in the round function. In the data randomization part, no characteristics could be seen in the randomization in the second round and beyond. In the key schedule part, there was a major relationship between a secret key and an expanded key. MISTY1 Some parts deviated from the expected values in the round function. In the data randomization part, no characteristics could be seen in the randomization in the fourth round and beyond. In the key schedule part , there was a major relationship between a secret key and an expanded key. n Software implementation evaluation: The evaluation was made in 2000. The values listed are the result of the evaluation of 2000. n Data randomization part: Although the number of cycles was used as the measurement value, we converted it to [Mbps] for ease of understanding. A larger value means faster speed. Because the measurement value is affected significantly by the execution environment, the value might not always be realized. Errors of measurement program and errors by the conversion stated above also resulted. Furthermore, in some cases, the measurement value varied only with the little change (to be described later) that did not alter the gist of the measurement program. Therefore, it is risky to make a final determination solely based on the values in the tables. The values on the second line in each cell (if present) indicate the measurement values obtained after the measurement program was altered by the applicant. A large memory area was allocated to the measurement program to provide the s ame condition to all ciphers under evaluation. “Alteration” in this case means that the memory area was optimized for each cipher. Concerning the alteration, the following two points were taken into consideration, and we decided to include both values in this report.

98 CRYPTREC 2001

• Condition was as close as possible to the actual implementation situation. • The reason why memory area size affects speed is unknown.

1. PC environment

From these results, it can be concluded that in the PC environment, if Triple DES is used as a reference, CIPHERUNICORN-E belongs to a slow group, and the rest belong to a sufficiently fast group. Although there was some speed difference between encryption and decryption in some ciphers, these differences were too insignificant to cause an imp lementation problem. Also, because there is no significant deviation between the average and the fastest value in any of the ciphers, the ciphers under evaluation can be expected to operate stably in the PC environment.

Table 3.4: PC environment

(Encryption: fastest value (average value) / Decryption: fastest value (average value))

64-bit block ciphers Speed [Mbps] CIPHERUNICORN-E 29.0(28.9)/29.3(29.2) Hierocroypt-L1 209.0(207.0)/203.9(202.2) MISTY1 195.3(193.8)/200.0(197.8) Triple DES 48.7(48.6)/48.7(48.6)

2. Server environment

These results show that CPU specification improvements do not directly contribute to the improvement of encryption speed, in some cases. For Hierocrypt-L1, the values obtained after the measurement program was altered by the applicant are shown in the second line in the corresponding cell. Enhancing the efficiency of memory allocation improved the speed by about 10%. Because there is no significant deviation between encryption and decryption or between the average and the fastest value, these ciphers can be expected to operate stably. Note that the evaluation on server environment was an option by each applicant. Although other ciphers not listed in the table can also be implemented in this environment, they may not suit the design philosophy, and therefore the evaluation on this environment was an option to respect applicant’s intentions.

Table 3.5: Server environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

64-bit block ciphers Speed [Mbps] CIPHERUNICORN-E 17.5(17.4)/17.5(17.4) 67.7(67.4)/51.2(50.8) Hierocroypt-L1 77.1(76.2)/84.2(83.2)

99 CRYPTREC 2001

3. High-end environment

Alpha 21264 is a 64-bit CPU and has a giant primary cache. If general-purpose CPUs evolve into such a structure in the future, it is estimated that among the submitted ciphers there is a trend observed from these results. Note that the evaluation on high-end environment was also an option by each applicant. Although other ciphers not listed in the table can also be implemented in this environment, they may not suit the design philosophy, and therefore the evaluation on this environment was an option to respect applicant’s intentions.

Table 3.6: High-end environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

64-bit block ciphers Speed [Mbps] CIPHERUNICORN-E 18.8(18.7)/18.9(18.8) 141.1(138.7)/141.1(139.8) Hierocroypt-L1 165.5(162.8)/165.5(162.8) MISTY1 139.1(138.0)/143.8(142.5)

Key schedule part + Data randomization part

Although the number of clock cycles was used as the measurement value, we converted it to µsec for ease of understanding. A smaller value means faster speed. Because the measurement value is affected significantly by the execution environment, the value might not always be realized. Errors of measurement program and errors by the conversion stated above also resulted. Furthermore, in some cases, the measurement value varied only with the little change (to be described later) that did not alter the gist of the measurement program. Therefore, it is risky to make a final determination solely based on the values in the tables. The large memory area was allocated to the measurement program to provide the same condition to all ciphers under evaluation. “Alteration” in this case means that the memory area was optimized for each cipher. Concerning the alteration, the following two points were taken into consideration, and we decided to include both values in this report.

• Condition was as close as possible to the actual implementation situation. • The reason why memory area size affects speed is unknown.

These values can be used for reference when using a block cipher for authentication, for example. Therefore, it is desirable that the processing is completed in several µsec.

100 CRYPTREC 2001

Table 3.7: PC environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

64-bit block ciphers [µsec] CIPHERUNICORN-E 3.72(3.73)/3.70(3.72) Hierocroypt-L1 0.58(0.58)/0.95(0.95) MISTY1 0.55(0.55)/0.54(0.54) Triple DES 3.02(3.03)/3.03(3.04)

Table 3.8: Server environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

64-bit block ciphers [µsec] CIPHERUNICORN-E 7.21(7.23)/7.34(7.36) 1.80(1.80)/3.01(3.04) Hierocroypt-L1 1.54(1.55)/2.53(2.58)

Table 3.9: High-end environment (Encryption: fastest value (average value) / Decryption: fastest value (average value)) 64-bit block ciphers [µsec] CIPHERUNICORN-E 5.14(5.16)/5.66(5.69) 0.84(0.85)/1.35(1.41) Hierocroypt-L1 0.83(0.84)/1.33(1.40) MISTY1 0.72(0.73)/0.68(0.73)

The above results indicate that the evaluated ciphers are expected to have practical applicability in such implementation environments.

Software implementation performance is being improved daily thanks to the efforts of the applicants toward the development. It is expected that processing speeds faster than those listed in this report have been achieved. We recommend you to contact each applicant for the latest situation. n Hardware implementation evaluation: The evaluation was made in 2000. The values listed are the result of the evaluation of 2000.

Hierocrypt-L1 and MISTY1 were the two ciphers for which hardware implementation was evaluated. Because the application document for CIPHERUNICORN-E only stated that “hardware implementation is also possible” and provided no specific hardware implementation examples (size, etc.), its hardware implementation was not evaluated.

101 CRYPTREC 2001

Concerning the hardware implementation evaluation of block ciphers was made according to two types of architectures exist. In one case, the loop architecture was used, and in the other, the loop architecture was not used. The algorithms evaluated using the loop architecture were MISTY1 and Triple DES, and the algorithms evaluated without using the loop architecture were Hierocrypt-L1 and Triple DES. Comparisons were made by dividing the algorithms into these two groups. Table 3.10 shows the parameters targeted for hardware implementation evaluation.

Table 3.10: Parameters targeted for hardware implementation evaluation

Evaluated cipher Number of iterative rounds Key length (bit) Hierocrypt-L1 6 rounds 128 MISTY1 8 rounds 128 Triple DES (Reference) 48(=16 x 3) rounds 168

Evaluation result

Table 3.11 shows the evaluation results of circuit size, critical-path delay, and throughput.

Table 3.11: Circuit size, critical path delay, and throughput

Circuit size (Unit: Gate) Evaluated cipher Data randomization Key schedule part Control circuit part Primitive as a whole part Hierocrypt-L1 *1 278,130 95,397 - 373,526 19,935 44,773 94 64,809 MISTY1 *2 10,609 28,194 68 38,875 *1 124,888 23,207 - 148,147 Triple DES 4,218 1,333 151 6,496 *2 2,011 1,088 134 5,111

*1: A design with a focus on the throughput of the overall algorithm without optimization was used. No pipeline architecture was used.

*2: The loop architecture was used, while no pipeline architecture was used. A table was used for the substitution table, and optimization was done using a logical synthesis tool. The top and bottom rows indicate evaluated results based on the optimization options of throughput priority and circuit-size priority, respectively.

These evaluation results show that Hierocrypt-L1 has the circuit size approximately 2.5 times as large as that of Triple DES, when the loop architecture is not used (the entire cryptographic algorithm was implemented). On the other hand, when the loop architecture is used, MISTY1 has the circuit size approximately 7.6 to 10 times as large as that of Triple DES.

102 CRYPTREC 2001

Table 3.12 shows the critical-path delay that determines the throughput and the expected throughput based on the critical-path delay.

Table 3.12: Critical-path delay and the expected throughput based on the critical-path delay.

Evaluated cipher Critical path (ns) Throughput (Mbps) Hierocrypt-L1 *1 70.13 912.59 11.86 600 MISTY1 *2 24.70 288 *1 157.09 407.4 Triple DES 4.44 244 *2 7.10 153

*1: A design with a focus on the throughput of the overall algorithm without optimization was used. No pipeline architecture was used.

*2: The loop architecture was used, while no pipeline architecture was used. A table was used for the substitution table, and optimization was done using a logical synthesis tool. The top and bottom rows indicate evaluated results based on the optimization options of throughput priority and circuit-size priority, respectively.

The comparison of the throughput in the group where the loop architecture was not used (the entire cryptographic algorithm was implemented) revealed that Hierocrypt-L1 was approximately 2.25 times faster than Triple DES. On the other hand, the comparison in the group where the loop architecture was used revealed that MISTY1 was approximately 1.9 to 2.5 times faster than Triple DES. n Security margin and speed: With the same cipher, increasing the number of rounds qualitatively enhances security and reduces the encryption speed. Theoretical break means that a cipher can be attacked with the computational complexity that is smaller than the exhaustive key search and with a plaintext required for attack that is less than the total number of plaintexts. For each cipher, the ratio between the number of rounds that can be theoretically broken and the actual number of rounds is indicated as a security margin, and the speed measurement obtained in the evaluation is expressed as a relative speed versus Triple DES. This is summarized in Table 3.13. Note that the speed indicated is the average of the fastest speeds for encryption and decryption.

103 CRYPTREC 2001

Table 3.13: Security margin and speed of each cipher (Pentium III)

Security margin = Speed Speed number of rounds/number of (data randomization part) (includes the key schedule rounds that can be attacked part) UNI-E 16/-* 0.60 0.82 HC-L1 6/3.5 4.25 3.97 MISTY1 8/5 4.07 5.57 Triple DES 48/48 1 1

*The number of rounds that can be theoretically broken is not yet known for CIPHERUNICORN-E.

3.2.3 128-bit block ciphers

The seven evaluated ciphers are Camellia, CIPHERUNICORN-A, Hierocrypt-3, SC2000, RC6 Block Cipher, AES (Rijndael) and SEED. The six ciphers from Camellia to RC6 were submitted for evaluation, and AES were added as a cipher considered to be evaluated in 2001. SEED was evaluated in response to the request from CRYPTREC Advisory Committee. The overview of the evaluation is shown below. n Characteristics: The organization that proposed the technique, the year it was announced, its structural characteristics, and the characteristics such as the operations used in the data randomization part were listed. For those techniques that use variable parameters such as number of rounds, the values recommended by the proposing organizations were listed. n Security: Security is discussed from the following three viewpoints: resistance to differential/linear cryptanalysis, resistance to algebraic and other attacks, and avalanche effect characteristics.

• In resistance to differential/linear cryptanalysis, the maximum differential/linear probability or the maximum differential/linear characteristic probability is indicated as the index of strength against differential/linear cryptanalysis, which is a general probability-based attacking method. • In resistance to algebraic and other attacks, resistance to higher order differential attack and interpolation attack, and algebraic methods such as SQUARE attack, as well as the resistance to other attacks such as related-key attack and mod n attacks, are described. The evaluation of higher order differential attack and interpolation attack is a method to search for basic weakness of a cipher from the algebraic point of view. If the number of rounds is large, an attack based on this method rarely causes problems. However, the weakness revealed by those attacks may affect the ultimate cipher strength, if other attacks can be combined with it. • Avalanche effect evaluation statistically captures how data is shuffled in each cipher, and although it does not directly lead to cryptanalysis in most instances, it provides a clue to search for weaknesses of the partial function of a cipher.

104 CRYPTREC 2001

n Software implementation evaluation: The evaluation was made in 2000. A cipher must be considered not only from the standpoint of security but also from the standpoint of implementation by assuming the actual use conditions. Although the requirements for cipher implementation in e-Government have not been made clear, our software implementation evaluation assumed the following three environments: a PC environment that was considered to be popular at the time of evaluation, a server environment that is currently considered to be most widely used, and a high-end environment that has achieved high performance. Measurements were taken in two parts: the data randomization part and the key schedule + data randomization part. n Hardware implementation evaluation: The evaluation was made in 2000. In principle, no optimization was performed, and a design with a focus on the throughput of the overall algorithm was assumed for evaluation. The target device for evaluation used ASIC library of 0.35 mm, design rules, Verilog-HDL hardware description language, and a design compiler for circuit synthesis. n Overall evaluation: Tables 3.14 to 3.16 show the overall evaluation results of security and implementation.

Table 3.14: Overall evaluation (1/3)

Camelllia Characteristics NTT, Mitsubishi (2000) Feistel structure, 18 rounds (128-bit key), 24 rounds (192/256-bit key), FL/FL-1-function is inserted for every sixth round. Expanded keys XOR as the initial and final processing. The round function has 8 S-boxes and a P-layer of byte-unit operations. One type of 8x8 S-box. Designed based on power multiplication operations on GF(28) and has resistance against differential/linear cryptanalysis. Table look up, XOR, AND, OR, and cyclic shift operation. The design of the P-layer was evaluated based on the concept of the number of active S-boxes. Overall evaluation No security problem has so far been found. Belongs to a group with fast processing speed. UNI-A Characteristics NEC (2000) Feistel structure, 16 rounds. The round function F is complex. Consists of a main stream and a temporary key -generation part to be expected to enhance security. The round function uses S-box as the basic component and consists of T- and A-functions. Four types of 8x8 S-boxes. Designed based on power multiplication operations on GF(28) and has resistance against differential/linear cryptanalysis. Table look up, addition, multiplication, XOR, AND, and cyclic shift operation. Designed with a round function structure to make significant correlation invisible from the cipher-evaluation system. Overall evaluation Although there remains a scientific problem on the security of CIPHERUNICORN-A, no major problems on practical standpoint have not been found. Belongs to a group with slow processing speed.

105 CRYPTREC 2001

Hierocrypt-3 Characteristics Toshiba (2000) Recursive SPN structure, six rounds (128-bit key), seven rounds (192-bit key), and eight rounds (256-bit key). Each round consists of two parallel XS-functions and a P-layer. XS-function has a structure in which a P-layer is sandwiched between four parallel S-boxes of two layers. One type of 8x8 S-box. Designed based on power multiplication operations on GF(28) and has resistance against differential/linear cryptanalysis. Table look up, XOR, and AND. Has a structure similar to that of Hierocrypt-L1. The design of the P-layer was evaluated based on the concept of the number of active S-boxes. Overall evaluation No security problem has so far been found. Belongs to a group with fast processing speed.

Table 3.15: Overall evaluation (2/3)

RC6 Characteristics RSA Security (1998) Modified Feistel structure consisting of four 32-bit blocks, 20 rounds. The round function has a simple structure. 32-bit input and (32+5)-bit output. Two blocks are affected by XOR and data-dependent cyclic shift operation. F-function consists of multiplication, addition, and cyclic shift operation. All operations are done in 32-bit words, i.e., the structure assumes a 32-bit CPU. Variable parameter structure that allows the selection of word length, number of rounds, and key length. Inherits the design concept of RC5. Overall evaluation No security problem has so far been found. Although RC6 provides the fastest encryption speed on Pentium III, software processing speed greatly depends on the platform. SC2000 Characteristics Fujitsu (2000) Combination of Feistel structure and SPN structure. Number of rounds in the data randomization part is 19 rounds (128-bit key) and 22 rounds (192/256-bit key). Uses 4x4 S-box in the SPN structure, and 5x5 and 6x6 S-boxes in the Feistel structure. Designed based on power multiplication operations on an extension field and has resistance against differential/linear cryptanalysis. Immune to algebraic attacks. Table look up, XOR, and AND. Bitslice method, which is a high-speed implementation method, can be applied to the SPN structure. The design of the P-layer was evaluated based on the concept of the number of active S-boxes. Overall evaluation No security problem has so far been found. Belongs to a group with fast processing speed. AES Characteristics NIST of U. S. A. (2000) SPN structure, 10 rounds (128-bit key), 12 rounds (192-bit key), and 14 rounds (256-bit key). One type of 8x8 S-box. Designed based on reciprocal operation on GF(28) and has resistance against differential/linear cryptanalysis. Diffusion layer P is composed of ShiftRow by byte-unit and 4-byte MixColumn via byte processing. Table look up, XOR, and AND. Successor to SQUARE cipher. The design of the P-layer was evaluated based on the concept of the number of active S-boxes. Overall evaluation No security problem has so far been found. Belongs to a group with fast processing speed.

106 CRYPTREC 2001

Table 3.16: Overall evaluation (3/3)

SEED Characteristics Korea KISA (1997) Feistel structure, 16 rounds. The block length and the key length are both 128 bits. Input data is divided into two 64-bit blocks, and one is input to round function F. XOR is operated with the output and the remaining 64 bits, and then the two blocks are swapped. The input of F-function is divided into two 32-bit blocks, and XOR is operated with each of them and 32-bit sub key. Then the right-hand 32-bit block is XORed to the left-hand 32-bit block. 3-round diffusion processing using function G and modulo 232 addition is done. G-function is realized using two 8-bit input and 8-bit output S boxes (S1 and S2). Overall evaluation No security problem has so far been found. Belongs to a group with relatively slow processing speed on PC.

3.2.4. Overall security evaluation n Resistance against differential/linear cryptanalysis: The resistance against differential/linear crypt- analysis can be expressed by the maximum differential/linear probability. None of the techniques submitted for evaluation does not offer the proof of security that this probability is small enough to guarantee the security of 128-bit block cipher.

Because it is difficult to determine the true value of the maximum differential/linear probability, maximum differential/linear characteristic probability is used as a corresponding index. The following methods are used for evaluating the maximum characteristic probability:

• A method that determines the upper bound of characteristic probability based on the maximum differential/linear probability of the components • A method that determines the maximum characteristic probability through computer searches

For Camellia, Hierocrypt-3, AES and SEED, the upper bound of characteristic probability is indicated using the evaluation based on the concept of the number of active S-boxes. It has been shown that Camellia, excluding the FL-function, does not exceed a differential/linear characteristic probability of 2-132 in 12 rounds, and Hierocrypt-3 and AES do not exceed a differential/linear characteristic probability of 2-150 in 2 rounds and 4 rounds respectively. The maximum differential characteristic probability of SEED is estimated to be 2-192 in 13 rounds. Multiple paths are not considered against linear cryptanalysis, but linear characteristics with the probability of 2-128 or larger in 6 rounds or over have not been found.

Round function F of CIPHERUNICORN-A is complex in structure, so it is difficult to analyze it. In the self-evaluation report, 15-round differential characteristic probability of 2-140 and the upper bound of 15-round linear characteristic probability of 2-140.14 are indicted with truncated vector search against simplified round function mF. In 2001, the simplification was investigated and an adequate method of estimation was searched for. Detailed evaluation was made not only by the Committee but also by two

107 CRYPTREC 2001

domestic and two overseas evaluators. The evaluation of simplified round function mF revealed that it was not strong enough to validate the security of CIPHERUNICORN-A. The existence of weak keys was also revealed although it was not serious enough to jeopardize the security. Concern about security has thus not been completely eliminated, and security has not been verified theoretically. However, it was concluded that specified 16-round CIPHERUNICORN-A has security sufficient enough against differential/linear cryptanalysis.

Although its structure is simple, RC6 is based on 32-bit word processing, and thus precise evaluation is difficult. However, the evaluation of its predecessor, RC5, and the research related to the AES application, have shown a 14-round maximum differential characteristic probability of 2-140 and an 18-round maximum linear characteristic probability of 2-155.

A truncated vector search has shown that SC2000 does not exceed a 15-round maximum differential chara cteristic probability of 2-134 and a 15-round maximum linear characteristic probability of 2-142. Furthermore, 11-round differential characteristic probability of 2-117, which is the same differential characteristic mentioned above, has been found by the submitter, reinforcing the reliability of the analysis result described above.

The technique that regards it as the proof of security that the characteristic of 128-bit block ciphers is 2-128 or lower is called the practical security against differential/linear cryptanalysis. All of the ciphers currently have values lower than this value, thus guaranteeing academically resistance against differential/linear cryptanalysis. n Resistance against algebraic and other attacks: Resistance against higher order differential attack and interpolation attack was evaluated in the same way as the 64-bit block ciphers. For all of the cryptographic schemes, no breaking method that was more effective than an exhaustive key search has been found.

Hierocrypt-3 and AES can be attacked to a higher number of rounds than differential/linear cryptanalysis by applying higher order differential attack. Using an attack method that is based on a 32nd order higher order differential attack (32nd order SQUARE attack), Hierocrypt-3 can be broken to three out of six rounds for a 128-bit key and to 3.5 rounds out of eight (or 10) rounds for a 192-bit (or 256-bit) key. By applying a SQUARE attack (32nd order higher order differential attack) and using a partial sum method, AES can also be broken more effectively with an exhaustive key search, to seven rounds out of 10 for a 128-bit key, to eight rounds out of 12 for a 192-bit key, and to eight rounds out of 14 for a 256-bit key. These attacks against AES require 2128-2119 plaintext pairs, which is nearly equal to the 2128 plaintext pairs that can be generated in a 128-bit block cipher.

Camellia can be broken to 8 out of 18 rounds for a 128-bit key, and 10 out of 24 rounds for a 256-bit key by applying a controlled higher order differential attack.

108 CRYPTREC 2001

SEED may be broken to about 6 rounds by applying a SQUARE attack.

A chi-square attack also has been effective against RC6. Using this attack, RC6 can be broken more effectively than with an exhaustive key search, to 12 rounds out of 20 for a 128-bit key, to 14 rounds out of 20 for a 192-bit key, and to 15 rounds out of 20 for a 256-bit key.

Furthermore, we examined resistance to impossible differential cryptanalysis, boomerang attack, mod n attack, and non-bijective attack, but found so far that none of evaluated ciphers has security problems in practice. n Avalanche effect evaluation: The evaluation was made in 2000. All algorithms satisfied the expected values in terms of the overall encryption that includes key schedule part. However, for the key schedule part alone, parts that do not satisfy the expected values were detected in Camellia, Hierocrypt-3, and SC2000. Also, for the round function alone, parts that do not satisfy the expected values were detected in Camellia, Hierocrypt-3, RC6, and SC2000.

Table 3.17: Avalanche effect evaluation

Camellia Some parts of the round function deviated from the expected values. In the data randomization part, no characteristics could be seen in the randomization in the fourth round and beyond. Different characteristics could be seen in the key schedule part, depending on the secret key length. UNI-A No characteristics could be seen in the round function. In the data randomization part, no characteristics could be seen in the randomization in the third round and beyond. No characteristics could be seen in the key schedule part. Hierocrypt-3 Some parts of the round function deviated from the expected values. In the data randomization part, no characteristics could be seen in the randomization in the second round and beyond. In the key schedule part, there was a major relationship between a secret key and an expanded key. RC6 Some parts of the round function deviated from the expected values. In the data randomization part, no characteristics could be seen in the randomization in the fourth round and beyond. No characteristics could be seen in the key schedule part. SC2000 Some parts of the round function deviated from the expected values. In the data randomization part, no characteristics could be seen in the randomization in the fourth round and beyond. In the key schedule part, characteristics could be seen when the secret key was 192 bits and 256 bits. n Software implementation evaluation: The evaluation except for SEED was made in 2000. The values listed are those measured in 2000.

Data randomization part: Although the number of clock cycles was used as the measurement value, we converted it to [Mbps] for ease of understanding. A larger value means faster speed. Because the measurement value is affected greatly by the execution environment, the value might not always be realized. Errors of measurement program and errors by the conversion stated above also resulted. Furthermore, in some cases, the measurement value varied with the change (to be described later) that was not big enough to alter the gist of the measurement program. Therefore, it is risky to make a final determination solely based

109 CRYPTREC 2001

on the values in the tables. The values on the second line in the measurement value columns (if present) indicate the measurement values obtained after the measurement program was altered by the applicant. A large memory area was allocated to the measurement program to provide the same condition to all ciphers under evaluation. “Alteration” in this case means that an ample memory area was optimized for each cipher. Concerning the alteration, the following two points were taken into consideration, and we decided to include both values in this report.

• Condition was as close as possible to the actual implementation situation. • The reason why memory area size affects speed is unkn own.

1. PC environment

Triple DES measurement values are included on the bottom of the table for comparison. Triple DES is a 64-bit block cipher. The results indicate that, in the PC environment, all of the ciphers except for CIPHERUNICORN-A and SEED belong to a sufficiently fast group when compared to Triple DES. Although there was some speed difference between encryption and decryption in some ciphers, these differences were too insignificant to cause an implementation problem. Also, because there is no significant deviation between the average and the fastest value in any of the ciphers, these ciphers under evaluation can be expected to operate stably in the PC environment.

Table 3.18 PC environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

128-bit block ciphers Speed [Mbps] Camellia 255.2(254.4)/255.2(254.2) CIPHERUNICORN-A 53.0(52.9)/52.9(52.7) Hierocrypt-3 205.9(204.9)/195.3(194.4) RC6 322.5(320.4)/317.6(313.6) SC2000 214.4(212.6)/203.9(202.6) SEED 98.3(95.9)/98.3(95.7) Triple DES 48.7(48.6)/48.7(48.6)

2. Server environment

These results show that CPU specification improvements do not directly contribute to the improvement of encryption speed, in some cases. For example, RC6, which is the fastest in the PC environment, instead belongs to a slow group in the server environment. For Hierocrypt-3 and SC2000, the values obtained after the applicant altered the measurement program are shown in the second line in the measurement-value column. More efficient memory allocation improved speed by about 10%. There was a speed difference between encryption and decryption in Hierocrypt-3. This may be caused by the fact that decryption

110 CRYPTREC 2001

processing is not sufficiently optimized because of an asymmetric encryption-decryption structure. Because there is no significant deviation between encryption and decryption or between the average and the fastest value, the other ciphers can be expected to operate stably. Note that the evaluation on server environment was an option by each applicant. Although other ciphers not listed in the table can also be implemented in this environment, they may not suit the design philosophy, and therefore the evaluation on this environment was an option to respect applicant’s intentions.

Table 3.19 Server environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

128-bit block ciphers Speed [Mbps] Camellia 144.2(142.9)/144.2(143.3) CIPHERUNICORN-A 22.5(22.4)/22.2(22.0) Hierocrypt-3 100.4(92.3)/67.6(62.1) 108.7(108.2)/83.7(83.1) RC6 25.0(24.5)/25.3(24.7) SC2000 165.2(163.4)/165.7(164.1) 186.2(184.2)/181.6(179.0)

3. High-end environment

Because the time between proposal and implementation was short for some ciphers, a conclusion should not be reached b ased on these results alone. However, the results so far indicate that the performance of a cipher depends on the implementation environment. For example, SC2000 is the fastest in the server environment, while Camellia is the fastest in the high-end environment. Alpha21264 is a 64-bit CPU and has a giant primary cache. If general-purpose CPUs evolve into such a structure in the future, it is estimated that among the submitted ciphers there is a trend observed from these results. Note that the high-end environment was also an option by each applicant. Although other ciphers not listed in the table can also be implemented in this environment, they may not suit the design philosophy, and therefore the evaluation on this environment was an option to respect applicant’s intentions.

Table 3.20 High-end environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

128-bit block ciphers Speed [Mbps] Camellia 210.2(205.3)/210.2(205.6) CIPHERUNICORN-A 32.4(32.2)/33.5(33.3) Hierocrypt-3 141.1(139.9)/138.8(137.9) 148.5(145.9)/153.5(150.7) SC2000 205.1(200.0)/210.2(203.9) 226.2(214.5)/215.5(205.1)

111 CRYPTREC 2001

Key schedule part + Data randomization part

Although the number of clock cycles was used as the measurement value, we converted it to µsec for ease of understanding. A smaller value means faster speed. Because the measurement value is affected significantly by the execution environment, the value might not always be realized. Errors of measurement program and errors by the conversion stated above also resulted. Furthermore, in some cases, the measurement value varied only with the little change (to be described later) that did not alter the gist of the measurement program. Therefore, it is risky to make a final determination solely based on the values in the tables. The large memory area was allocated to the measurement program to provide the same condition to all ciphers under evaluation. “Alteration” in this case means that the memory area was optimized for each cipher. Concerning the alteration, the following two points were taken into consideration, and we decided to include both values in this report.

• Condition was as close as possible to the actual implementation situation. • The reason why memory area size affects speed is unknown.

These values can be used for reference when using a block cipher for authentication, for example. Therefore, it is desirable that the processing be completed in several µsec.

Table 3.21 PC environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

128-bit block ciphers Speed [msec] Camellia 0.72(0.75)/0.73(0.76) CIPHERUNICORN-A 7.36(7.42)/7.38(7.42) Hierocrypt-3 1.12(1.12)/2.07(2.09) RC6 2.51(2.53)/2.51(2.52) SC2000 1.23(1.24)/1.26(1.26) SEED 1.90(1.93)/1.90(1.93) Triple DES 3.02(3.03)/3.03(3.04)

Table 3.22 Server environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

128-bit block ciphers Speed [msec] Camellia 1.01(1.02)/1.01(1.02) CIPHERUNICORN-A 19.92(20.40)/22.01(22.57) Hierocrypt-3 2.06(2.07)/6.68(6.71) 1.90(2.06)/6.53(6.57) RC6 10.19(10.28)/10.05(10.14) SC2000 1.56(1.57)/1.55(1.56)

112 CRYPTREC 2001

Table 3.23 High-end environment (Encryption: fastest value (average value) / Decryption: fastest value (average value))

128-bit block ciphers Speed [msec] Camellia 0.97(0.98)/0.94(0.95) CIPHERUNICORN-A 9.96(9.99)/10.95(11.01) Hierocrypt-3 1.46(1.47)/2.44(2.47) 1.44(1.45)/2.44(2.47) SC2000 1.24(1.25)/1.27(1.28)

The above results indicate that the evaluated ciphers are exp ected to have practical applicability in such implementation environments.

Software implementation performance is being improved daily thanks to the efforts of the applicants toward the development. It is expected that processing speeds faster than those listed in this report have been achieved. We recommend you to contact each applicant for the latest situation. n Hardware implementation evaluation: The evaluation was made in 2000. The values listed are the result of the evaluation of 2000.

Camellia, CIPHERUNICORN-A, Hierocrypt-3, RC6, and SC2000 were the five ciphers for which hardware implementation was evaluated. Because the application document for CIPHERUNICORN-A and SC2000 only stated that “hardware implementation is also possible” and provided no specific hardware implementation examples (size, etc.), its hardware implementation was not evaluated.

Concerning the hardware implementation evaluation of block ciphers was made according to two types of architectures exist. In one case, the loop architecture was used, and in the other, the loop architecture was not used. The algorithms evaluated using the loop architecture were Hierocrypt-3 and RC6, and the algorithms evaluated without using the loop architecture was Camellia only. Table 3.24 shows the parameters targeted for hardware implementation evaluation.

Table 3.24 Parameters targeted for hardware implementation evaluation

Evaluation target Number of iterative rounds Key length (bit) Camelia 24 rounds 256 CIPHERUNICORN-A 16 rounds 128 Hierocrypt-3 6 rounds 128 RC6 20 rounds 128 SC2000 19 rounds 128 AES (reference) 10 rounds 128

113 CRYPTREC 2001

Evaluation results

Table 3.25 shows the evaluation results of circuit size, critical-path delay, and throughput.

Table 3.25 Circuit size, critical-path delay, and throughput

Circuit size (unit: Gate)

Evaluation target Data Control circuit Primitive as a randomization Key schedule part part whole part Camelia *2 16,327 22,755 266 39,348 9,668 13,304 141 23,125 Hierocrypt-3 *1 538,078 106,302 - 724,380 RC6 *1 77,785 975,391 - 1,753,076 SC2000 (reference) - - - - 62,000 AES (reference) *1 518,508 93,708 - 612,843

*1: A design with a focus on the throughput of the overall algorithm without optimization was assumed. No pipeline architecture was used.

*2: The loop architecture was used, while no pipeline architecture was used. A table was used for the substitution table, and optimization was done using a logical synthesis tool. The top and bottom rows indicate evaluated results based on the optimization options of throughput priority and circuit-size priority, respectively.

These evaluation results show that Hierocrypt-3 and AES have the circuit size approximately 4.8 and 4.1 times, respectively, as large as that of Triple DES when the loop architecture is not used (the entire cryptographic algorithm was implemented), which indicate small circuit sizes. The circuit size of RC6 is 10 times larger than that of Triple DES.

In the group that uses the loop architecture (small architecture), Camellia (256-bit key) has a circuit size approximately 6 times as large as that of Triple DES if priority is given to throughput and approximately 4 times if priority is given to circuit size. Judging from these trends, in terms of hardware implementation size, Camellia (256-bit key), Hierocrypt-3, and AES are relatively small, while RC6 are large in circuit size.

Table 3.26 shows the critical-path delay that determined the throughput and the expected throughput based on the critical-path delay.

114 CRYPTREC 2001

Table 3.26 Critical-path delay and the expected throughput based on the critical-path delay

Critical path (ns) KeySetup (ns) Throughput Evaluation target (Mbps) Camellia *2 5.46 - 837 (256-bit key) 11.51 - 397 Hierocrypt-3 *1 75.55 1,694.24 RC6 *1 698.05 2,112.26 183.36 SC2000 (reference) - - - 914 AES (reference) *1 65.64 57.39 1,950.03

*1: A design with a focus on the throughput of the overall algorithm without optimization was used. No pipeline architecture was used.

*2: The loop architecture was used, while no pipeline architecture was used. A table was used for the substitution table, and optimization was done using a logical synthesis tool. The top and bottom rows indicate evaluated results based on the optimization options of throughput priority and circuit-size priority, respectively.

The comparison of the throughput in the group in which the loop architecture was not used (the entire cryptographic algorithm was implemented) revealed that Hierocrypt-3 and AES exceeded approximately 4 times faster than Triple DES, while RC6 did not exceed the throughput of Triple DES. In the group in which the loop architecture (small architecture) was used, Camellia achieved approximately 2.5 to 3 times faster than Triple DES. Note that the SC2000 data is included for reference, because this information (circuit size and throughput) was reported for hardware implementation (0.25 µm rule CMOS-GA) at the ISEC Technical workshop (September 2000). n Security margin and speed: With the same cipher, increasing the number of rounds qualitatively enhances security and reduces the encryption speed. Theoretical break means that a cipher can be attacked with the computational complexity that is smaller than the exhaustive key search and with a plaintext required for attack that is less than the total number of plaintexts. Three specifications - 128, 192, and 256-bit key length - have been proposed for 128-bit block ciphers. In table 3.27, the ratio between the number of rounds that can be theoretically broken in 256-bit key specification and the actual number of rounds is indicated as a security margin, and the speed measurement obtained in the evaluation is expressed as a relative speed versus Triple DES. Note that the speed indicated is the average of the fastest speed of encryption and decryption of 128-bit key specification. The processing speed of Triple DES of 128-bit data was calculated by the following equation using the measurement values. It is used as a reference for the comparison of processing speed among 128-bit block ciphers.

Data randomization part processing time (128bits) = Data randomization part processing time (64 bits)x2 Processing time including key schedule part (128bits) = Processing time including key schedule part (64 bits) + Data randomization part processing time (64 bits)

115 CRYPTREC 2001

3.2.5 Stream cipher

3.2.5.1 Screening evaluation n Target of evaluation: Screening evaluation was made on the following cryptographic techniques that were submitted for evaluation in 2001.

• C4-1 • FSAngo • MUGI n Details of evaluation: Judgment of whether the technique is worth being evaluated in detail was made based on t he application document submitted. Items for screening evaluation are shown below.

Table 3.27 Security margin and speed of each cipher (Pentium III)

Security margin = Attacks Speed (Data Speed Number of randomization part) (including key rounds/Number of schedule part) rounds that can be attacked AES 14/8 SQUARE attack 2.15 1.23 Note 1 14/9 related-key attack Camellia (w/o FL) 24/10 Higher order 5.24 6.00 differential attack UNI-A 16/* Unclear Note 2 1.02 0.59 Hierocrypt-3 8/3.5 SQUARE attack 4.12 2.73 RC6 20/15 Chi-square attack 6.57 1.73 SC2000 22/13 Differential 4.29 3.49 cryptanalysis SEED 16/7 Differential 2.02 2.29 cryptanalysis (Triple DES) 48/48 Meet-in-the-middle 1 1 attack

Note 1: Reference value Pentium III 600 MHz, C, Reference Lawrence E. Bassham, “Efficiency Testing of ANSI C Implementations of Round 2 Candidate Algorithms for the Advanced Encryption Standard,” AES3 conference, section 5.1, Table 6 (128 Blocks)

Note 2: The number of rounds that can be theoretically broken is not yet known for CIPHERUNICORN-A.

116 CRYPTREC 2001

• Check of the completeness of description and theoretical consistency/self completeness of the descriptive content • Check of apparent defects in the document • Check of specifications of the cryptographic technique and self-evaluation report submitted at the time of application and check of their validity n Evaluation result:

C4-1 Information on algorithm sufficient for the third person to implement it is not described. There is no description on the submitted cryptographic technique in the reference program.

FSAngo There is no reference program and test vector generation program required for evaluation.

MUGI No problem on security has so far been found. Even though this is a modification of presented in 1998, it is not long since it was proposed, thus requiring further evaluation of security and implementability.

3.2.5.2 Continued evaluation

The target of the evaluation was MULTI-S01. n Characteristics: MULTI-S01 consists of pseudorandom number generation, and encryption and decryption by which its mode of operation is realized. The pseudorandom number generator generates a key stream from secret key K (256 bits). A message is encrypted using the key stream. The feature of MULTI-S01 is that message authentication is done together with the concealment of a message. MULTI-S01 uses PANAMA as a pseudorandom number generator.

MULTI-S01 consists of the pseudorandom number generator PANAMA and the mode part. The following evaluation was made with regard to these component parts.

Evaluation 1 [Verification of the security of MULTI-S01] The data randomization part of MULTI-S01 has a structure similar to modes of operation of block ciphers. By using a security evaluation method for modes of operation as seen in Modes of Operation Workshop sponsored by NIST, the security of data randomization part of MULTI-S01 is verified.

Evaluation 2 [Verification of the security of pseudorandom number generator PANAMA] The security of MULTI-S01 is largely attributable to PANAMA. However, its security has not been verified sufficiently. By applying various attacks proposed against pseudorandom number generators for encryption, the security of PANAMA is verified.

117 CRYPTREC 2001

Evaluation 3 [Verification of the statistical characteristics of pseudorandom number generator PANAMA] It is hard to say that the of PANAMA has been sufficiently verified. In 2001, the required minimum evaluation of random numbers for encryption listed in FIPS-140 was conducted. On the other hand, NIST SP 800-21 describes further detailed evaluation methods of random numbers for encryption. By adopting these methods to PANAMA, statistical characteristics are verified.

This evaluation was performed not only by the committee but also by three researchers home and abroad. The following points have been clarified by the evaluation.

• The security of MULTI-S01 can be reduced to PANAMA. • No particular defects were detected by verification of random number of PANAMA. • No fatal problems have been found with the security of PANAMA.

From the above, it is concluded that no problem on security of MULTI-S01 has so far been found, and that it belongs to a group with fast processing speed. n Software implementation evaluation: The evaluation was made in 2000. The values listed are those measured in 2000.

In measuring stream ciphers, only the data randomization was measured, because there is usually no key setup. Although the number of clock cycles was used as the measurement value, we converted it to throughput (Mbps) for ease of understanding. A larger value means faster speed. Because the measurement value is affected significantly by the execution environment, the value might not always be realized. Errors of measurement program and errors by the conversion stated above also resulted. As with block ciphers, it is risky to make a final determination solely based on the values shown in the table. Since stream ciphers are strongly hardware-oriented, many of them are not suitable for software implementation. The measurement was made only in the PC environment, and the measurement program the same as the one used for 64-bit block ciphers was used. Consequently, the actual performance may not have been sufficiently demonstrated. Therefore, we set the purpose of this measurement to the verification whether MULTI-S01 has the performance to withstand the minimum usage conditions.

Table 3.28 PC environment (Fastest value (average value))

Stream ciphers Speed [Mbps] MULTI-S01 237.7(233.7)

An ordinary stream cipher obtains the ciphertext by XORing a plaintext with a random number string (key sequence). Decryption is done in the order reverse to encryption, and the speed is exactly the same for both of them. Therefore, only encryption speed was measured. Because MULTI-S01 does not have an ordinary

118 CRYPTREC 2001

stream cipher structure, a difference of speed between encryption and decryption may arise. Because MULTI-S01 also has MAC functions, the reported results include these as well. Moreover, PANAMA, the pseudorandom number generator used in MULTI-S01, requires initialization. Although this is equivalent to key scheduling in block ciphers, it was not included in the measurement. It is subject to some kind of constraint in the software implementation evaluation, but it is considered that the expected minimum software implementation conditions can be achieved. Software implementation performance is being improved daily thanks to the efforts of the applicants toward the development. It is expected that processing speeds faster than those listed in this report have been achieved. We recommend you to contact each applicant for the latest situation. n Hardware implementation evaluation:

Evaluation method Circuit coding was made via Verilog-HDL using the C language program on the FPGA (Field Programmable Gate Array) by Altera, and simulation was performed. The following development environments were used.

• ModelSim VHDL/Verilog Version 5.4e (Model Technology) • Synplify (Synplicity Inc.)

Evaluation results Note that the throughput estimates in Table 3.29 do not include the setup time for key data.

Table 3.29 HW implementation evaluation

Evaluation Operating frequency Throughput (Gbps) Resource usage FPGA used target (MHz) S01 18.8 1.203 19,811/42,240 EP20K1000E ATOMs(46%)

It was concluded that stream ciphers can achieve Gbps-class throughput with a reasonable circuit size, even when using a general purpose FPGA, if the design condition is throughput priority. Note that the EP20K1000E can achieve a larger circuit size than EP20K600E.

3.3 Evaluation of ciphers targeted for detailed evaluation (individual ciphers)

3.3.1 CIPHERUNICORN-E

3.3.1.1 Technical overview

CIPHERUNICORN-E is a 64-bit block cipher with a block length of 64 bits and a key length of 128 bits, which was developed by NEC Corporation in 1998 [1]. The basic structure of the cipher is a 16-round . The major characteristic of this cipher is its use of an extremely complex round function that

119 CRYPTREC 2001

consists of a main stream and a temporary key generation mechanism. This function is intended to enhance security by making a subkey search of the round function difficult. Unlike the design philosophies behind many ciphers, the main design philosophy of CIPHERUNICORN-E is to design a round function, of which a significant correlation cannot be found out, by using a cipher strength evaluation system [2] that performs the elementary value evaluation by regarding the round function as a black box. As a result, it is reported, by the designer, that no bias of the data shuffling has been detected in any of the items in the elementary statistics value evaluation of the round function. According to the applicant, CIPHERUNICORN-E can be implemented in both software and hardware, and it has been designed to be able to perform high-speed processing, using a 32-bit processor in particular.

3.3.1.2 Technical specifications

CIPHERUNICORN-E is a 64-bit block cipher with a block length of 64 bits, a key length of 128 bits, and has a 16-round Feistel structure. An L-function is inserted for every two rounds. For key scheduling, a 2624-bit subkey is generated by shuffling the secret key. n Data randomization part: The round function is a 32-bit input/output function that uses subkeys (function keys and seed keys) of 32 bits x 4 (a total of 128 bits), and consists of S-boxes, 32-bit arithmetic additions, and shift operations. Note that this function is not a bijective function. Inside the function, 32-bit input data is branched into the main stream and temporary key generation. The function keys and the seed keys are input into the main stream and the temporary key generation, respectively. Furthermore, the temporary key generated in the temporary key generation from the input data and the seed keys is inserted into the main stream, and ultimately 32-bit output data is generated. A part of the main stream is a data-dependent function according to the value of the temporary key. The L-function, which is an auxiliary function, is a 64-bit input/output function that uses two 64-bit subkeys (total of 128 bits). It is a key-dependent linear transformation function that is configured as the logical product of bit units. n Key schedule part: The key schedule part has a Feistel structure that uses an ST-function as the round functions, and outputs either two or four 32-bit subkeys from each ST-function while shuffling the secret key. The ST-function uses the same T-functions as the round function. n Design philosophy: Differential cryptanalysis and linear cryptanalysis estimate key information using the shuffling bias in the round function. Therefore, under the philosophy of building a round function in which shuffling bias cannot be detected, the round function that satisfies the following conditions has been designed by using the cipher strength evaluation system that performs evaluation by regarding the round function as a black box.

• There must not be any relationship between an input bit and an output bit with a high probability.

120 CRYPTREC 2001

• There must not be any relationship between output bits with a high probability. • There must not be any relationship between an input-bit change and an output-bit change with a high probability. • There must not be any relationship between a key-bit change and an output-bit change with a high probability. • There must not be any output bit that becomes 0 or 1 with a high probability.

3.3.1.3 Others

CIPHERUNICORN-A is a 128-bit block cipher designed in the same way by using the cipher strength evaluation system.

3.3.1.4 Evaluation results

The configuration of the round function of CIPHERUNICORN-E is very complex, and therefore it is difficult to accurately evaluate and analyze its security against cryptanalysis techniques, including differential cryptanalysis and linear cryptanalysis. Consequently, it was concluded in CRYPTREC Report 2000 that CIPHERUNICORN-E required further continuous evaluation. In 2001, its security evaluation was conducted from the following viewpoints.

• Security against differential cryptanalysis from the viewpoint of differential characteristic probability • Security against linear cryptanalysis from the viewpoint of linear characteristic probability • Security against other cryptanalysis

In CRYPTREC Report 2000, it is indicated that with a round function model simplified based on generally adequate consideration (mF-function), the upper bound of the maximum differential probability is lower that 2-64 in 12 rounds or over. With regard to linear characteristic probability, it is also indicated that with the simplified model round function (mF*-function), the upper bound becomes 2-70.72 in 8 rounds, which is lower than 2-64. In 2001, with regard to differential characteristic probability and linear characteristic probability, four evaluators (teams) evaluated the round function and overall algorithm according to methods which each evaluator considered to be adequate. The evaluations revealed that the upper bound value was sufficiently lower than 2-64 in the number of rounds smaller than 16 that is the specified number of rounds. These values were calculated according to the modified round function obtained by approximating the round function of CIPHERUNICORN-E in some way. However, since almost the same security evaluation results were obtained despite that many evaluators used different approximation methods, it is expected that CIPHERUNICORN-E has the security against differential cryptanalysis and linear cryptanalysis equivalent to or higher than the evaluation results obtained this time.

With regard to cryptanalysis other than those listed above, no problem has so far been found as is shown in

121 CRYPTREC 2001

CRYPTREC Report 2000. On the other hand, since there is a possibility that the resistance against side channel attacks may not be solid enough due to the structure of the round function, it is desirable to carefully take defensive measures, when using CIPHERUNICORN-E in an environment where side channel attacks may arise.

Taking the results described above together, no specific problem on security of CIPHERUNICORN-E has so far been found. Therefore, it is considered the use of CIPHERUNICORN-E for e-Government presents no security problem.

A) Elementary statistics value evaluation It was verified that the cipher output becomes indistinguishable from a random number in at least the fifth round. Additionally, favorable results have been obtained for all items in the elementary statistics value evaluation of the round function, which indicates excellent elementary statistical properties of randomness. The applicant states that the round function was designed so that a shuffling bias cannot be detected. However, note that this does not mean that a round function thus designed has nearly the same characteristics as a random function. B) Differential cryptanalysis If the configuration of the round function is complex and difficult to evaluate directly, a cipher model with the simplified round function can be conceived based on appropriate assumptions, and security can be discussed on this model. This is because it is generally expected that the original cipher have security equivalent to or higher than that of a model with the round function simplified on appropriate assumptions. In CRYPTREC Report 2000, security evaluation was conducted with a model using an mF-function, which has the round function simp lified based on appropriate considerations, in such ways as (1) replacing arithmetic addition with XOR, and (2) replacing the Y-function with a process that aggregates input bits to the upper 1 byte of the 32-bit data. As a result, it was revealed that the upper bound of the maximum differential characteristic probability was lower than 2-64 in at least 12 rounds or over. In 2001, four evaluators (teams) conducted evaluations, and the following results were obtained. Evaluator 1: He indicated that the upper bound of the maximum differential characteristic probability of the round function was 2-21 and that the upper bound of the maximum differential characteristic probability of 13 rounds was 2-126. This means that the specified 16-round CIPHERUNICORN-E cannot be broken by differential cryptanalysis. Evaluator 2: He indicated that although the upper bound of the maximum differential characteristic probability of the round function was 2-12 that was the same as the value on the self-evaluation report, the upper bound of overall algorithm was 2-72. However, he reached the same conclusion as evaluator 1 that the specified 16-round CIPHERUNICORN-E cannot be broken by differential

122 CRYPTREC 2001

cryptanalysis. Evaluator 3: He indicated that the upper bound of the maximum differential characteristic probability of the round function was 2-14, which means that the upper bound of the maximum differential characteristic probability of 15 rounds is 2-98. He concluded that the specified 16-round CIPHERUNICORN-E cannot be broken by differential cryptanalysis. Evaluator 4: He indicated that the upper bound of the maximum differential characteristic probability of the round function was 2-16, and that if the number of rounds is 10 or more, it is below 2-64. He reached the same conclusion that the specified 16-round CIPHERUNICORN-E cannot be broken by differential cryptanalysis. Judging from the above evaluation results, with regard to any of the different approximation models, the upper bound can be far below 2-64 in the number of rounds smaller than 16 that is the specified number of rounds. Therefore it can be concluded that CIPHERUNICORN-E is expected to be secure against differential cryptanalysis. C) Linear cryptanalysis CRYPTREC Report 2000 indicates that het upper bound of the maximum linear characteristic probability of the round function is 2-17.68 in a model with simplified round function (mF*-function), and that the upper bound becomes 2-70.72 in 8 rounds, which is lower than 2-64. The self-evaluation report indicates that in the model with simplified round function (mF-function), the upper bound of the maximum linear characteristic probability of the round function is 2-63.90. Four evaluators (teams) conducted evaluation in 2001, and the following results were obtained. Evaluator 1: He indicated that the upper bound of the maximum linear characteristic probability of the round function was 2-24.64, and that the upper bound of the maximum differential characteristic probability of 13 rounds was 2-147.84. This means that the specified 16-round CIPHERUNICORN- E cannot be broken by linear cryptanalysis. Evaluator 2: He indicated that the upper bound of the maximum linear characteristic probability of the round function was 2-62 using the mF-function. He reached the same conclusion that the specified 16-round CIPHERUNICORN-E cannot be broken by linear cryptanalysis. Evaluator 3: He indicated that the upper bound of the maximum linear characteristic probability of the round function was 2-27.3 using the mF-function, which means that the upper bound of the maximum linear characteristic probability of 15 rounds is 2-191.2. As a result, he concluded that the specified 16-round CIPHERUNICORN-E cannot be broken by linear cryptanalysis. Evaluator 4: He indicated that the upper bound of the maximum linear characteristic probability of the round function was 2-16, and that in 10 rounds or over, it becomes less than 2-64. He reached the same conclusion that the specified 16-round CIPHERUNICORN-E is secure against linear cryptanalysis. Judging from the above evaluation results, with regard to any of the different approximation models,

123 CRYPTREC 2001

the upper bound can be far below 2-64 in the number of rounds smaller than 16 that is the specified number of rounds. Therefore it can be concluded that CIPHERUNICORN-E is expected to be secure against linear cryptanalysis. D) Higher order differential attack, interpolation attack The security against these attacks has been adequately evaluated in the self-evaluation report, and in detailed evaluations also, no problem has been found. E) Key Because of the configuration of the key schedule part, no key collision is expected to occur. F) Existence of weak keys Depending on the key value, the presence of the L-function prevents the swapping of the left and right data, which is important in a Feistel cipher, and thus may reduce the effective number of rounds. Therefore, it is desirable to check before using a secret key that such a is not generated. n Security against side channel attacks: In the round function of CIPHERUNICORN-E, a) there exists a part whose configuration changes depending on the data, and b) the internal configuration has two processing areas, i.e., the main stream and the temporary key generation, which branches the same input data. Normally, a is considered effective against a data-dependent process, as in a), and a power analysis attack is considered effective when the same data goes through multiple processes, as in b). Therefore, CIPHERUNICORN-E may not be very immune to side channel attacks such as a timing attack and a power analysis attack. Consequently, when using CIPHERUNICORN-E in an environment where a threat of side channel attacks is present, it is desirable to carefully institute defensive measures.

3.3.1.5 Software implementation evaluation n PC implementation: Software implementation was evaluated in the environments listed below. Tables 3.30 and 3.31 show the evaluation results.

Table 3.30 Data randomization part speed measurement results (Unit: cycles/block)

Pentium III (650 MHz) Language ANSI C + assembler Program size 26232 bytes (including encryption/decryption/key scheduling) Compiler option Specify "/O2/Oy-" (execution speed) Encryption (fastest value/average value) Decryption (fastest value/average value) First round 1435/1438 1424/1426 Second round 1434/1444 1422/1425 Third round 1436/1440 1422/1425 UltraSPARC IIi (400 MHz) Language ANSI C Program size 11848 bytes (including encryption/decryption/key scheduling)

124 CRYPTREC 2001

Compiler option Specify "-v -fast" Encryption (fastest value/average value) Decryption (fastest value/average value) First round 1462/1469 1462/1468 Second round 1462/1468 1462/1468 Third round 1462/1469 1462/1468 Alpha 21264 (463 MHz) Language ANSI C Program size 13552 bytes (including encryption/decryption/key scheduling) Compiler option Specify "-O4" Encryption (fastest value/average value) Decryption (fastest value/average value) First round 1575/1583 1566/1579 Second round 1575/1583 1568/1582 Third round 1575/1583 1568/1580

Table 3-31 Key schedule part + data randomization part speed measurement results (Unit: cycles/block)

Pentium III (650 MHz) Language ANSI C + assembler Program size 13552 bytes (including encryption/decryption/key scheduling) Compiler option Specify /O4 Encryption (fastest value/average value) Decryption (fastest value/average value) First round 2421/2426 2406/2453 Second round 2418/2428 2406/2424 Third round 2420/2424 2410/2414 UltraSPARC IIi (400 MHz) Language ANSI C Program size 11848 bytes (including encryption/decryption/key scheduling) Compiler option -v -fast Encryption (fastest value/average value) Decryption (fastest value/average value) First round 2882/2892 2936/2944 Second round 2882/2890 2935/2944 Third round 2883/2890 2935/2944 Alpha 21264 (463 MHz) Language ANSI C Program size 13552 bytes (including encryption/decryption/key scheduling) Compiler option Specify -O4 Encryption (fastest value/average value) Decryption (fastest value/average value) First round 2381/2393 2621/2634 Second round 2381/2390 2619/2635 Third round 2381/2390 2623/2634

3.3.1.6 Hardware implementation evaluation

Although the applicant states that hardware implementation is possible, CIPHERUNICORN-E was not

125 CRYPTREC 2001

included in hardware implementation evaluation because no description or public information related to hardware implementation exists.

References [1] Yukiyasu Tsunoo, Hiroyasu Kubo, Hiroshi Miyauchi, and Katsuhiro Nakamura, Ciphers whose security has been evaluated by statistical methods, 1998 Ciphers and Information Security Symposium SCIS 98, 4.2.B, 1998. [2] Yukiyasu Tsunoo, Ryoji Ota, Horoshi Miyauchi, and Katsuhiro Nakamura, Distributed Cipher-Strength Evaluation System, 2000 Ciphers and Information Security Symposium SCIS2000, A53, 2000.

3.3.2 Advanced Encryption Standard (AES)

3.3.2.1 Technical overview

AES is basically symmetric block cipher Rijndael that was proposed for the AES (Advanced Encryption Standard) in 1998 by J. Daemen (Proton World International) and V. Rijmen (Katholieke Universiteit Leuven) [1]. It can use 128, 192 or 256 bits for both block length and key length. Following a public discussion on AES activity, Rijndael was selected as the AES winner in October 2000 by the NIST (National Institute of Standards and Technology) [2] and was established in FIPS-197 AES (Federal Information Processing Standard-197) as AES (Advanced Encryption Standard) in November 2001. Rijndael has variable parameters, i.e., block length, key length and number of iterative rounds. But they are limited as a specification of AES in FIPS.

3.3.2.2 Technical Specifications

The main design principles behind AES are (1) sufficient resistance to the known attacks, (2) ability to be implemented in various types of platform, and (3) a simple algorithm structure that enables security evaluation easily. AES is an SPN cipher, and data blocks are transformed per 8-bit unit in the round function. The number of rounds in the algorithm depends on the block length and key length. For 128-bit block length, the number of rounds are 10, 12, and 14 for key length of 128, 192, and 256 bits, respectively. The round function consists of three types of transformation areas, and transformation is performed by the linear transformation layers (bit shift, etc.), the non-linear transformation layers (substitution), and the expanded key transformation layers (XOR with expanded keys). The key schedule part generates (r + 1) expanded keys (where r is the number of rounds) with the same length as the block length. The bit shift and substitution in the data randomization part are used for the transformation in the key schedule part.

126 CRYPTREC 2001

3.3.2.3 Other

Rijndael can be considered to be successor to ciphers called SHARK [3] and SQUARE [4], which include the designers of Rijndael as originators.

3.3.2.4 Evaluation results n Security evaluation: The major evaluation results from published reports on the security of the 128-bit block cipher AES can be summarized as follows:

• No attack method has been found that can break full round AES as specified with 128, 192, or 256-bit keys.

• When 128-bit keys are used, attack methods have been found that can break reduced round (6 or 7) out of full round (10). • When 192-bit keys are used, an attack method has been found that can be break reduced round (7) out of full round (12). • When 256-bit keys are used, attack methods have been found that can break reduced round (7,8 or 9) out of full round (14).

Based on these results, NIST has reported in its AES Report that Rijndael has an adequate security margin in terms of security [2] and specified it as FIPS. Additional discussions of this issues follow.

(1) Self-evaluation report by the designers at the time of an AES proposal In their AES proposal, the designers of Rijndeal stated that they had evaluated Rijndeal against differential cryptanalysis, linear cryptanalysis, truncated differential cryptanalysis, SQUARE attack, interpolation attack, weak key attack, and related-key attack, and that an attack method that is more efficient than an exhaustive key search did not exist for any combination of block length and key length [1]. Specifically, the designers claim that Rijndeal is sufficiently secure against differential cryptanalysis and linear cryptanalysis because no path that exceeds a probability of 2-150 in differential characteristic probability or linear characteristic probability exists for Rijndeal with four rounds. Against truncated differentials, they state that an attack method that is more efficient than an exhaustive key search does not exist for Rijndeal with six or more rounds. Furthermore, they show that a SQUARE attack can be applied to Rijndeal with four, five, or six rounds, and state that an attack method that is mo re efficient than an exhaustive key search does not exist for Rijndeal with seven or more rounds [4]. They also state that other attack methods, such as interpolation attack, weak key attack, and related-key attack, are difficult to apply to Rijndeal.

127 CRYPTREC 2001

(2) Security evaluation results following the AES proposal Since Rijndeal was proposed for AES, many researchers have reported the results of their research on Rijndeal’s security. Some of the major ones are described as follows. • It has been reported that, by applying a collision attack to Rijndeal with 192-bit keys and 256-bit keys, up to seven rounds can be broken using 232 chosen plaintexts [5]. • It has been reported that, by applying a SQUARE attack to Rijndeal with 192-bit keys and 256-bit keys, seven rounds can be broken using 232 chosen plaintexts [6]. • An attack method has been reported that applies an improved SQARE attack to Rijndeal with 128- and 256-bit keys, to break up to seven and eight rounds, respectively [7]. However, the number of chosen plaintexts required for this cryptanalysis is 2128-2119, which almost equals all of plaintexts. • It has been reported that up to nine rounds of Rijndeal with 256-bit keys can be broken using a related-key attack [7].

As explained previously, although many security evaluations related to Rijndeal have been taking place in the public domain, no attack method has yet been found that can break the full-specification Rijndeal. Based on these published evaluation reports, NIST reports that Rijndeal has reached an adequate security margin in terms of security [2]. n Software implementation evaluation: The results of software implementation of Rijndeal under several evaluation environments (CPU, language, etc.) has been reported [2]. Implementation evaluation results using a 32-bit CPU, i.e., Pentium III, and the C language are provided as follows [8]. Note that the key setup time that appears in the following evaluation results does not include encryption or decryption time.

Evaluation target (CPU): Pentium III 600 MHz Programming language: Visual C++ Ver. 6.0 Other: 128 MB RAM, Windows 98 4.10.1998

Encryption key setup time 128-bit key 1289 [cycles] 192-bit key 2000 [cycles] 256-bit key 2591 [cycles]

Decryption key setup time 128-bit key 1724 [cycles] 192-bit key 2553 [cycles] 256-bit key 3225 [cycles]

128 CRYPTREC 2001

Encryption (ECB) speed 128-bit key 805 [cycles] 192-bit key 981 [cycles] 256-bit key 1155 [cycles] Decryption (ECB) speed 128-bit key 784 [cycles] 192-bit key 955 [cycles] 256-bit key 1121 [cycles]

The following tables show other major evaluation results [2] that have been reported.

Table 3.32 32-bit process (encryption)

A B C D E (C language) (C language) (C language) (C language) (Java) cycles cycles cycles cycles cycles 128-bit keys 237 1276 805 362 7770 192-bit keys 981 428 256-bit keys 1155 503

A: Pentium II, C, Source: Ref [10], Table 1. B: Linux/GCC-2.7.2.2/Pentium 133MHz MMX, C. Source: Ref. [11], Table 3 C: Intel Pentium III 600MHz, C. Ref [8], 5.1, Table 6 (128 blocks) D: Intel Pentium II/III, C, Source: Ref. [12], Table 1. E: Ultra SPARC-I, W/JDK1.2, JIT, Java. Ref [13], Table 2.

Table 3.33 64-bit processors (encryption: C language + assembly language)

F G H I cycles cycles cycles cycles 128-bit keys 168 125 490 293

F: Hewlett-Packard PA -RISC, ASM. Source: Ref.[14], Appendix A. G: Hewlett-Packard IA-64, C. Source: Ref. [14], Appendix A., Ref. [15] H: Compaq Alpha 21164A 500MHz, C. Source: Ref.[13], Table 1. I: Compaq Alpha 21264, C. Ref.[16], Table 1.

Table 3.34 8-bit processors (encryption: C language + assembly language)

J K cycles cycles 128-bit keys 9464 25494

129 CRYPTREC 2001

J: Motorola 6805 CPU Core, C. Ref.[17], Table 3. K: Z80 CPU+coprocessor. Ref.[18], Table 8.

Table 3.35 32-bit processors (decryption: C language)

B C D cycles cycles cycles 128-bit keys 1276 784 358 192-bit keys 955 421 256-bit keys 1121 492

B: Linux/GCC-2.7.2.2/Pentium 133MHz MMX, C. Source: Ref. [11], Table 3 C: Intel Pentium III 600MHz, C. Ref. [8], 5.1, Table 6 (128blocks) D: Intel Pentium II/III, C. Source: Ref. [12], Table 1.

Table 3.36 64-bit processors (decryption: C language + assembly language)

F G cycles cycles 128-bit keys 168 126

F: Hewlett-Packard PA -RISC, ASM. Source: Ref, [14] Appendix A. G: Hewlett-Packard IA-64, C. Source: Ref. [14], Appendix A., Ref. [15]

Table 3.37 32-bit processors (key setup: C language)

B C D cycles cycles cycles 128-bit keys 17742(18886) 1289(1724) 215(1334) 192-bit keys 2000(2553) 215(1591) 256-bit keys 2591(3255) 288(1913)

B: Linux/GCC-2.7.2.2/Pentium 133MHz MMX, C. Source: Ref. [11], Table 3 C: Intel Pentium III 600MHz, C. Ref. [8], 5.1, Table 6 (128blocks) D: Intel Pentium II/III, C. Source: Ref. [12], Table 1.

Table 3.38 64-bit processors (key setup: C language + assembly language)

F G cycles cycles 128-bit keys 239 148

F: Hewlett-Packard PA -RISC, ASM. Source: Ref. [14], Appendix A. G: Hewlett-Packard IA-64, C. Source: Ref. [14], Appendix A., Ref. [15]

130 CRYPTREC 2001

Table 3.39 8-bit processors (key setup: C language + assembly language)

K cycles 128-bit keys 10318

K: Z80 CPU + coprocessor. Ref. [18], Table 8.

n Hardware implementation evaluation: We did not perform any hardware implementation evaluation in 2001. Fast hardware implementation of Rijndeal on ASIC has been reported by Ichikawa et al [9]. Evaluation target: ASIC (0.35 mm design rule ASIC library made by Mitsubishi Electric) Descryption language: Verilog-HDL Evaluation condition Worst case

Gate size (NAND gate equvalent): Total: 612,843 (gates) (Encryption and decryption part: 518,508, keys schedule part: 93,708) Key setup: 57.39 (ns) Throughput: 1950.03 (Mbps)

Many other implementation examples using FPGAs have also been reported [2].

References [1] J. Daemen and V. Rijmen, AES proposal: Rijndeal, AES algorithm submission, September 3, 1999, http://nist.gov/aes (AES home page). [2] J. Nechvatal, et al., Report on the Development of the Advanced Encryption Standard (AES), National Institute of Standards of Technology, October 2, 2000, http://csrc.nist.gov/encryption/aes/ [3] V. Rijmen, et al., The Cipher SHARK, 3rd Fast Software Encryption, LNCS 1039, pp.99-112, Springer-Verlag, 1996. [4] J. Daemen, L. Knudsen, and V. Rijmen, The Block Cipher SQUARE, 4th Fast Software Encryption, FSE97, LNCS 1267, pp.-28-40, Springer-Verlag, 1997. [5] H. Gilbert and M, Miner, A collision attack on 7 rounds of Rijndeal, in The Third AES Candidate Conference, printed by the National Institute of Standards and Technology, April 13-14, 2000, pp.230-241. [6] S. Lucks, Attacking Seven Rounds of Rijndeal Under 192-bit and 256-bit Keys, in The Third AES

131 CRYPTREC 2001

Candidate Conference, printed by National Institute of Standards and Technology, Gaithersburg, MD, April 13-14, 2000, pp.215-229. [7] N. Ferguson, et al., Improved Cryptanalysis of Rijndeal, in the preproceedings of the Fast Software Encryption Workshop 2000, April 10-12, 2000. [8] L. Bassaham, Efficiency Testing of ANSI C implementations of Round 2 Candidate Algorithms for the Advanced Encryption Standard, in The Third AES Candidate Conference, printed by the National Institute of Standards and Technology, Gaithersburg, MD, April 13-14, 2000, pp.136-148. [9] T. Ichikawa, T. Kasuya, and M. Matsui, Hardware Evaluation of the AES Finalists, in The Third AES Candidate Conference, printed by the National Institute of Standards and Technology, Gaithersburg, MD, April 13-14, 2000, pp.279-285. [10] K. Aoki and H. Lipmaa, Fast Implementations of AES Candidates, in The Third AES Candidate Conference, printed by the National Institute of Standards and Technology, Ga ithersburg, MD, April 13-14, 2000, pp.106-120. [11] E. Biham, A Note on Comparing the AES Candidates, in The Second AES Candidate Conference, printed by the National Institute of Standards and Technology, Gaithersburg, MD, March 22-23, 1999, pp.85-92. [12] B. Gladman, AES Second Round Implementation Experience, AES Round2 public comment, May 15, 2000. [13] O. Baudron, et al., Report on the AES Candidates, in The Second AES Candidate Conference, printed by the National Institute of Standard and Technology, Gaithersburg, MD, March 22-23, 1999, pp.53-67. [14] J. Worley, et al,. AES Finalists on PA -RISK and IA-64: Implementations & Performance, in The Third AES Candidate, Conference, printed by the National Institute of Standards and Technology, Gaithersburg, MD, April 13-14, 2000, pp.57-74. [15] J. Worley, E-mail comments, AES Round 2 public comment, May 15, 2000, available at AES home page. [16] R. Weiss and N. Binkert, A comparison of AES Candidate on the Alpha 21264, in The Third AES Candidate Conference, printed by the National Institute of Standards and Technology, Gaithersburg, MD, April 13-14, 2000, pp.75-81. [17] G. Keating, Performance analysis of AES candidates on the 6805 CPU, AES Round 2 public comment, April 15, 1999, available at AES home page. [18] F. Sano, et al., Performance Evaluation of AES Finalists on the High-End Smart Card, in The Third AES Candidate Conference, printed by the National Institute of Standards and Technology, Gaithersburg, MD, April 13-14, 2000, pp. 82-9.

132 CRYPTREC 2001

3.3.3 CIPHERUNICORN-A

3.3.3.1 Technical overview

CIPHERUNICORN-A is a 128-bit block cipher with a block length of 128 bits and key length of 128, 192, and 256 bits, which was developed by NEC Corporation in 2000 [1]. The basic structure of the cipher is a 16-round Feistel cipher.

The major characteristic of this cipher is its use of an extremely complex round function that consists of a main stream and a temporary key generation mechanism. This function is intended to enhance security by making a subkey search of the round function difficult. Unlike the design philosophies of many ciphers, the main design philosophy behind CIPHERUNICORN-A is to design a round function, of which a significant correlation cannot be found out, by using a cipher strength evaluation system [2] that performs the elementary statistics value evaluation by regarding the round function as a black box.

According to the applicant, no bias of the data shuffling has been detected in any of the items in the elementary statistics value evaluation of the round function. They stated that they designed this cipher so that it can be processed at high speed on a 32-bit processor in the implementation aspect.

3.3.3.2 Technical specifications

CIPHERUNICORN-A is a 128-bit block cipher with a block length of 128 bits, key length of 128, 192 and 256 bits, and has a 16-round Feistel structure. It has an interface identical to that of AES. Its key schedule part generates 2304-bit subkeys (72 32-bit subkeys) by shuffling the secret key. n Round function (data randomization part):

• The round function is a 64-bit input/output function that uses four 32-bit subkeys (two function keys and two seed keys), and consists of combinations of four S-boxes (T-functions), 32-bit arithmetic additions, 32-bit constant arithmetic multiplications and rotation (A3-function). • This is not a bijective function. • 64-bit input data is branched into the main stream and temporary key generation; the function keys are input into the main stream and the seed keys are input into the temporary key generation. • The temporary key is generated in the temporary key generation from the input data and the seed keys. • The generated temporary key is inserted into the main stream, and ultimately 64-bit output data is generated. A part of the composition of the main stream is a data-dependent function according to the value of the temporary key. n Key schedule part:

• The key schedule part has a Feistel structure that uses an MT-function as the round function, and it

133 CRYPTREC 2001

outputs a 32-bit intermediate key from each MT-function. • The MT-function is composed of a combination of the same T0-function in the round function and 32-bit constant arithmetic multiplication. • After generation of 72 intermediate keys, these intermediate keys are re-ordered and used as subkeys in each round. n Design philosophy: Differential cryptanalysis and linear cryptanalysis estimate key information (subkeys) using the data shuffling bias in the round function. Therefore, the substantial design philosophy of CIPHERUNICORN-A is to produce a structure that does not permit detection of data shuffling bias in the round function. The round function is designed so as to satisfy the following conditions with the cipher strength evaluation system that performs evaluation by regarding the round function as a black box.

• There must not be any relationship between an input bit and an output bit with a high probability. • There must not be any relationship between output bits with a high probability. • There must not be any relationship between an input-bit change and an output-bit change with a high probability. • There must not be any relationship between a key-bit change and an output-bit change with a high probability. • There must not be any output bit that becomes 0 or 1 with a high probability.

3.3.3.3. Others

CIPHERRUNICORN-E, which is a 64-bit block cipher, has been designed in the same way with the cipher strength evaluation system.

3.3.3.4 Evaluation results n Security evaluation (general comment): The configuration of CIPHERUNICORN-A round function is very complex, and therefore it is difficult to accurately evaluate and analyze its security against cryptanalysis techniques, including differential cryptanalysis and linear cryptanalysis. Therefore, based on the overall evaluation of CRYPTREC Report 2000 that continuous evaluation of CIPHERUNICORN-A is needed, three-round elimination attack against CIPHERUNICORN-A was assumed, and security evaluation was continuously conducted in the year 2001, from the viewpoint of whether sufficient security is provided in 13 rounds against differential cryptanalysis and linear cryptanalysis.

CRYPTREC Report 2000 indicates that, with a model that uses an mF-function in which the configuration of the round function has been simplified based on generally appropriate considerations, the upper bound of the maximum differential characteristic probability is less than 2-128 in 15 rounds and over, and the upper

134 CRYPTREC 2001

bound of the maximum linear characteristic probability is less than 2-128 in 14 rounds and over. Furthermore, in 2001, the applicant and four evaluators (teams) conducted evaluation of the round function and the entire cipher based on the technique, which they considered appropriate. It was estimated as a result that the upper bound of the maximum differential characteristic probability of 13 rounds is 2-100 or less and the upper bound of the maximum linear characteristic probability of 13 rounds is around 2-128, except for some evaluations. All of these evaluation results were calculated based on modified round functions, to which approximations of some kind was applied, and not the round function itself of CIPHERUNICORN-A. However, since almost identical security evaluation results were obtained by multiple evaluators even if they used approximations by different techniques, it can be expected that the security of CIPHERUNICORN-A against differential cryptanalysis and linear cryptanalysis is at least equivalent to the evaluation results estimated at the present time. Therefore, although it is not theoretically proven that it has the resistance against differential cryptanalysis and linear cryptanalysis, in the case where three-round elimination attack is assumed, it can be estimated that those attacks are almost impossible in .

Furthermore, regarding cryptanalysis other than those stated above, no problems have so far been discovered in particular, as is indicated in CRYPTREC Report 2000. On the other hand, the resistance against side channel attacks may not be high because of the configuration of the round function. Therefore, it is desirable to carefully institute defensive measures if used in an environment in which a side channel attack may occur.

In addition, there was a new indication regarding security that at least one weak key, which is considered to be non trivial, is presented that values of all the subkeys become identical to more significant 32-bits of the secret key (regardless of the length of the secret key). At the present time, however, it was only indicated that one out of 2128 secret keys (case of 128-bit secre t keys) is a weak key, and it is not true that indication alone proposes a serious problem in the security.

When the conclusion stated above is put together, it is unavoidable to say that some problems are left unsolved from an academic viewpoint regarding security of CIPHERUNICORN-A at the present time. However, no major practical problem has so far been found. Therefore, it is considered that no practical problem would arise when this cipher is used for e-Government. n Security evaluation against each theoretical cryptanalysis:

a) Elementary statistics value evaluation It can be judged that randomness is satisfactory in general, as satisfactory results were obtained on all the items of elementary statistics evaluation of the round function. The applicant states that the round function was designed so that a data shuffling bias cannot be detected. However, this does not mean that a round function thus designed has nearly the same characteristics as a random function. For example, although the self-evaluation report states that either the main stream or the temporary key

135 CRYPTREC 2001

generation is fully shuffled, other evaluation is indicated that, depending on values of input data and key, the effect of multiple T-functions cancels to each other at a high probability and sufficient shuffling is not performed with either the main stream or the temporary key generation. b) Differential cryptanalysis If the configuration of the round function is complex and difficult to evaluate directly, a cipher model can be conceived to simplify the round function based on appropriate assumptions, and security can be discussed using this model. This is because the security of the original cipher is generally expected to be at least equivalent to that of a model that has been simplified based on appropriate assumption.

In CRYPTREC Report 2000, security has been evaluated with a model using an mF-function in which simplification was made based on appropriate considerations, such as (1) replacing arithmetic addition with XOR, (2) replacing constant multiplication with a process that aggregates input bits to one more significant byte of the 32-bit data, and (3) replacing the A3-function with rotation processing in truncated vector units. It is indicted as a result that the upper bound of the maximum differential characteristic probability is less than 2-128 in 15 rounds and over.

The evaluation based on the approximation techniques from different viewpoints was conducted in the year 2001 as follows:

Evaluator 1: The evaluator re-evaluated the security with a model using an mF-function, and discovered as a result that approximation processing of constant multiplication was incomplete. Furthermore, he indicated that when this approximation processing is completely conducted, the upper bound of the maximum differential characteristic probability of the mF-function can be indicated only up to 2-7 and the upper bound of the maximum differential characteristic probability in 13 rounds can be indicated only up to 2-56. However, constant multiplication is naturally dependent on input data, exerts influence of some kind to the differential characteristic probability and it can be expected to make contribution to improvement of security. It should be noted that evaluation of security is conducted here assuming that the differential characteristic probability is not affected (evaluation that is disadvantageous to the designer) in the approximation processing of constant multiplication.

Applicant: Since it was recognized that it is necessary to further examine the reports in detail in relation to the new self-evaluation of security announced by the applicant at the lump session of the CRYPTREC Cryptographic Technology Evaluation Workshop, we requested the applicant to submit an additional report. According to this additional report, the degree of influence of constant multiplications over the differential characteristic probability is being experimentally studied (in progress), and it is stated that, with constant multiplication

136 CRYPTREC 2001

in such a case that was pointed by evaluator 1, the influence of at least 2-6 is given to the differential characteristic probability. Furthermore, it is also stated that the upper bound of the maxi mum differential characteristic probability of the mF-function is 2-13 and the upper bound of the maximum differential characteristic probability of 13 rounds is 2-104. The review of the new evaluation result and the fact that evaluator 4 also estimates the effect of constant multiplications to be 2-7 were taken into consideration, and the result was considered to be appropriate.

Evaluator 2: For the model with the round function consisting only of a main stream, security evaluation was conducted by six-round iterative expression (the maximum differential characteristic probability 2-56). It is indicated as a result that the upper bound of the maximum differential characteristic probability of 13 rounds is 2-119.

Evaluator 3: Security evaluation was conducted for the case where the effect of A3-function and constant multiplication is completely excluded. It is indicated as a result that the upper bound of the maximum differential characteristic probability of the round function is 2-14.4 and the upper bound of the maximum differential characteristic probability of 13 rounds is 2-115.2.

Evaluator 4: When the (experimentally studied) effects of arithmetic addition of the main stream and of the A3-function and the effect of constant multiplications of the temporary key generation are added besides the effect with the T-function, the upper bound of the maximum differential characteristic probability of the main stream, temporary key generation and round function is 2-14, 2-7 and 2-21, respectively. Thus, it is indicated that the upper bound of the maximum differential characteristic probability of 13 rounds is 2-126.

When the results of evaluation indicated above are totally judged, it can be estimated that the upper bound of the maximum differential characteristic probability of 13 rounds is 2-100 or less in each of security evaluation with different approximation models. In addition, it can be anticipated that actual CIPHERUNICORN-A provides at least equivalent security. Therefore, although it is not theoretically proven that differential cryptanalysis cannot be applied when three-round elimination attack is assumed, it can be estimated to be practically almost impossible. c) Linear cryptanalysis Each evaluator conducted evaluation based on a model using the mF-function at this time.

137 CRYPTREC 2001

Evaluator 1: The evaluator indicates that the upper bound of the maximum linear characteristic probability of the round function is 2-21.37 and the upper bound of the maximum linear characteristic probability of 13 rounds is 2-128.2.

Evaluator 3: The evaluator indicates that the upper bound of the maximum linear characteristic probability of the round function is 2-21.68 and the upper bound of the maximum linear characteristic probability of 13 rounds is 2-130.1.

Evaluator 4: When it is assumed that evaluation of the maximum linear characteristic probability of the S-boxes by the applicant is correct, the upper bound of the maximum linear characteristic probability of the round function is 2-13.9 and the upper bound of the maximum linear characteristic probability of 13 rounds is 2-83.4. The examination conducted by evaluator 4 produced results that conflict with the applicant’s evaluation, and he does not deny the possib ility where the upper bound of the linear characteristic probability of the round function becomes higher than the evaluation of this time. On the other hand, attention should also be paid to the fact that the influence of the A3-function, constant multiplications and temporary key generation are hardly taken into consideration. He also states that the resistance against linear cryptanalysis is stronger than that against differential cryptanalysis in practice.

When the results of evaluation stated above are totally judged, the resistance against linear cryptanalysis is stronger than that against differential cryptanalysis, and as concrete evaluation, it can be estimated that the upper bound of the maximum differential characteristic probability of 13 rounds is around 2-128 or less. Therefore, it is considered that linear cryptanalysis would be almost impossible when three-round elimination attacks are assumed.

d) Higher order differential attack, interpolation attack, and mod n attack No particular problems on these attacks were not found. n Security of key schedule part:

a) Indication of existence of weak keys Take-out of intermediate keys in the key schedule part is implemented as follows. It is assumed that all the symbols represent 32-bit data and that the input of 128-bit keys is (A, B, C, D), the input of 192-bit keys is (A, B, C, D, E, F) and the input of 256-bit keys is (A, B, C, D, E, F, G, H).

Input: (A, B, C, D,……., y) The following is repeated by the specified number of times.

138 CRYPTREC 2001

(A*, B*) ¬ MT (A, B) A ¬ B*, B ¬ C, C ¬ D, ..., y ¬ A* Intermediate key output at specified place: A

When the input is (A, B, B, B, ..., B) in this key schedule, if (B, A) ¬ MT (A, B) is satisfied, the data being repeated constantly remains as (A, B, B, B, ..., B) (regardless of how many times it is repeated). In other words, the intermediate key is A at any specified point, and it is of the state where the key scheduling for intermediate key generation is not effectively working at all. As a result of calculation of the input that satisfies these conditions, it was found that (B, A) ¬ MT (A, B) is satisfied when A = 0x61db99c8, B = 0x9f3d61c8. In other words, when secret key is (0x61db99c8, 0x9f3d61c8, 0x9f3d61c8, 0x9f3d61c8, …, 0x9f3d61c8), all the intermediate keys are of value 0x61db99c8 that is the same as that of more significant 32 bits of secret keys. Furthermore, since subkeys are generated by changing the order only of intermediate keys, it also means that all the subkeys are of the same value, 0x61db99c8. When estimation is made from the configuration of the key schedule part of CIPHERUNICORN-A as collated with the original role of the key schedule part, it seems natural to consider that secret keys of this type are non trivial weak keys. Only weak keys of this type have been found by this time. b) Related-key attack It is considered to be secure against related-key attack from the configuration of the key schedule part. n Security against side channel attack: In the round function of CIPHERUNICORN-A, a) a part of configuration changes depending on the data, and b) the internal configuration has two processing areas, i.e., the main stream and the temporary key generation, and branches the same input data. Normally, a timing attack is considered effective against a data-dependent process, as in a), and a power analysis attack is considered effective when the same data goes through multiple process, as in b). Therefore, CIPHERUNICORN-A may not be very immune to side channel attacks, such as timing attack and power analysis attack. Consequently, when usin g CIPHERUNICORN-A in an environment in which a threat of side channel attacks is present, it is desirable to carefully institute defensive measures.

3.3.3.5 Software implementation evaluation

Software implementation was evaluated in the environments listed as follows. Tables 3.40 and 3.41 show the evaluation results.

139 CRYPTREC 2001

Table 3.40 Data randomization part speed measurement results (unit: cycles /block)

Pentium III (650MHz) Language ANSI C + assembler Program size 3984 bytes (including encryption/decryption/key scheduling) Compiler option Specify "/O2/Oy-" (execution speed) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 1569 / 1574 1574 / 1578 Second round 1570 / 1574 1574 / 1577 Third round 1570 / 1574 1574 / 1578

UltraSPARC IIi (450MHz) Language ANSI C Program size 5644 bytes (including encryption/decryption/key scheduling) Compiler option -v- fast UltraSPARC IIi (450MHz) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 2273 / 2282 2302 / 2326 Second round 2273 / 2282 2309 / 2327 Third round 2273 / 2282 2310 / 2327 Alpha 21264 (463MHz) Language ANSI C Program size 8472 bytes (including encryption/decryption/key scheduling) Compiler option -O4 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 1834 / 1843 1769 / 1782 Second round 1828 / 1842 1769 / 1782 Third round 1827 / 1842 1769 / 1782

Table 3.41: Key schedule part + data randomization part speed measurement results (unit [cycles/block])

Pentium III (650MHz) Language ANSI C + assembler Program size 4306 bytes (including encryption/decryption/key scheduling) Compiler option /O2/Oy- (execution speed) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 4788 / 4822 4799 / 4931 Second round 4788 / 4814 4798 / 4815 Third round 4787 / 4830 4806 / 4814

UltraSPARC IIi (400MHz) Language ANSI C Program size 5644 bytes (including encryption/decryption/key scheduling) Compiler option -v- fast Encryption (Fastest/Average) Decryption (Fastest/Average) First round 7970 / 8160 8802 / 9025 Second round 7961 / 8164 8817 / 9034 Third round 7900 / 8161 8823 / 9028

140 CRYPTREC 2001

Alpha 21264 (463MHz) Language ANSI C Program size 8552 bytes (including encryption/decryption/key scheduling) Compiler option -O4 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 4610 / 4623 5071 / 5092 Second round 4610 / 4628 5071 / 5100 Third round 4610 / 4624 5071 / 5095

Measurement item 128-bit key 192-bit key 256-bit key Key scheduling 3219 4032 3518 Encryption 1565 1565 1565 Decryption 1559 1559 1559 Key scheduling + encryption 4780 5593 5079 Key scheduling + decryption 4791 5604 5090

For all measurement items in encryption and decryption, including key generation, CIPHERUNICORN-A belongs to the group of the slowest processing speed among the 128-bit block ciphers applied this time. Furthermore, on Pentium III, CIPHERUNICORN-A is equivalent to Triple DES for all measurement items.

As an implementation by the applicant, results of speed evaluation [unit: cycles] by ANSI C (with inline assembly) on Pentium III (866MHz) are shown below, which indicates that the processing speed is almost the same as the values indicated above.

Furthermore, no description or public information exists on software implementation with an 8-bit CPU represented by smart cards.

3.3.3.6 Hardware implementation evaluation

The following self-evaluation results were reported from the applicant.

0.25 mm CMOS ASIC: only 128-bit keys can be used.

• Throughput priority: 170.60Mbps, 325.3Kgates • Circuit-size priority: 86.80Mbps, 290.4Kgates

ALTERA EP20K1500EFC33-1 (FPGA): 128-bit, 192-bit and 256-bit keys can be used.

• 44.33Mbps, 7072 Logic Cell + 66ESB

Reference [1] Yukiyasu Tsunoo, Hiroyasu Kubo, Hiroshi Miyauchi, and Katsuhiro Nakamura, “128-bit Block Cipher CIPHERUNICORN-A” 2000 Ciphers and Information Security Symposium SCIS2000, A18, January 2000

141 CRYPTREC 2001

[2] Yukiyasu Tsunoo, Ryoji Ota, Hiroshi Miyauchi, and Katsuhiro Nakamura, “Distributed Cipher Strength Evaluation Support System” 2000 Ciphers and Information Security Symposium SCIS2000, A53, January 2000

3.3.4 SEED

3.3.4.1 Technical overview

SEED is a cipher algorithm designed by Korea Information Security Agency (KISA) upon decision in 1997 of the Korean Government to develop a standard cipher algorithm [1].

Standardization of SEED is in progress in Korea. It became a TTA (Telecommunications and Technology Association) standard (industrial standard) (TTA KO-12.0004) in 1999, and the work to establish Korean Information Communication Standard (KICS) promoted by the Ministry of Information and Communication (MIC) of Korea is also in progress [2].

3.3.4.2 Technical specifications

SEED is a block cipher having so-called Feistel structure, and the number of iterative rounds of processing is 16. Furthermore, both of the block length and key length of SEED are 128 bits.

The input data is divided into two 64-bit blocks in each round. One block is input to round function F and its output is XORed with the other 64-bit block, and then two blocks are interchanged.

The input of the F-function is divided into two 32-bit blocks and each block is XORed with a 32-bit subkey. Then 32 bits on the right-hand side are XORed with 32 bits on the left-hand side. Furthermore, three-round shuffling processing is executed using function G and the addition modulo 232.

The G-function is constructed with two S-boxes (S1 and S2) having an 8-bit input/output.

3.3.4.3 Evaluation results n Executive Summary: Strength of SEED against differential cryptanalysis, linear cryptanalysis, and higher order differential attack is evaluated. It is also considered whether interpolation attack, SQUARE attack, non-surjective attack, and slide attack are applicable. Our analysis does not show any important flaws nor weaknesses in SEED. The best attack at this point of time is an exhaustive key search.

The software performance of SEED on the PC environment is moderately slow among the 64-bit or 128-bit block ciphers evaluated by CRYPTREC.

142 CRYPTREC 2001

During the evaluation process, it is found that the key schedule part of SEED has a peculiar property described later in this report. This property, however, does not seem to turn to an immediate threat to the security of SEED.

(1) Security of the Data Randomization Part

Differential cryptanalysis In the self-evaluation report, the authors argue that the maximum differential characteristic probability for 6-round reduced SEED is estimated as 2-130. Based on this value, it would be concluded that the differential cryptanalysis be applicable only to 6 rounds. Recently, in [3], a new maximum differential characteristic probability is found to be 2-124. Using this characteristic, 7-round SEED is analyzed with 2-126 chosen plaintext -ciphertext pair and 2-126 computation of F-function. This is the best differential cryptanalysis against SEED ever reported. As an approximation, XOR operations are taken in place of modulo 232 additions in the round function F. In this case, at least four S-boxes are active in every round and we can find a characteristic in which at least two round functions are active in every 3 rounds. Since each S-box has the best characteristic probability 2-6, the maximum differential characteristic probability of 13-round SEED is estimated as 2-192. Here, it is assumed that 8 round functions are active in 13 rounds. It seems difficult, if not impossible, to find the best characteristic probability of original SEED with modular addition operations. However, it seems highly unlikely that one can find differentials with only 3 active S-boxes per round for an r-round differential for large values of r. With a similar discussion to the above approximated case, a differential over 13 rounds will have a probability of at most 2-144. Any of the above discussion shows a differential cryptanalysis is unlikely to be found on SEED with full 16 rounds.

Linear cryptanalysis Self-evaluation report reported that the best-known linear probability becomes less than 2-128 if 6 or more rounds are iterated. Though this value does not take multiple paths into account, this is an evidence that 16-round SEED has sufficient margin against linear cryptanalysis. For a simplified version of SEED whose modulo 232 addition is replaced by XOR, the maximum linear characteristic is estimated to have a probability less than 2-192. Since replacing back modular addition does not seem to increase the probability, it is unlikely to apply a linear cryptanalysis to 16-round SEED.

Higher order differential attack Round function F is composed of 32-bit functions G, which is constructed with S-boxes. The S-boxes have an algebraic degree of seven, which is the maximum degree for such a bijective S-box on 8 bits. All

143 CRYPTREC 2001

output bits of the function G have an algebraic degree of seven. Further, all output bits of the F-function have an algebraic degree of 63, which is the maximum degree achievable since F-function is a bijective on 64 bit. It is, therefore, very likely that for 16-round SEED, the algebraic degree of the ciphertexts as function of plaintexts is high enough to prevent a higher order differential attack from being practical.

Interpolation attack The S-boxes in SEED are constructed from the inverse function in a finite field, which has a simple description. However, the fact that both the inputs and outputs are mixed with affine mappings makes the description much more complex. This together with the mixed use of XORs and modular additions make the interpolation attack very unlikely to be applicable.

SQUARE attack (Integral attack) It is conjectured that reduced versions of SEED with up to six rounds is vulnerable to these attacks, but not versions with more than six rounds.

Non-surjective attack The non-surjective attack is not applicable as the round function is bijective and thus not vulnerable to the attack.

(2) Security of key schedule part Exhaustive key search Exhaustive key search is a trivial attack. This attack is not practical against the specified 128-bit key for SEED.

Slide attack The slide attack applies best to ciphers with very simple key schedules. However, the key schedule of SEED uses both the S-boxe s and different round constants, which are good means to prevent the attack from being effective.

Peculiar property of key schedule part The key schedule of SEED takes a 128-bit user-selected key and returns 16 pairs of round keys each of

two times 32 bits, in total 1024 bits. Let the round keys in round i be denoted ki,0 and ki,1. They are generated as follows. The user-selected key is divided into four pieces, a, b, c, d , each of 32 bits.

• for i:=1 to 16 do • ki, 0 = G (a + c – kci) • ki, 1 = G (b – d + kci) • if i odd do b || a = (b || a) >>8 else do d || c = (d || c)<<8,

144 CRYPTREC 2001

where kci for i = 1, …,16 are round constants derived in a pseudo random fashion. We refer to [1] for the notation used.

At a first glance it appears that there are no related keys for SEED because of the use of the highly nonlinear function G in the key schedule part . However, there are keys whose subkeys are related.

Notice that the generation of ki,0 depends only on the rotated versions of a and c together with the round constant. Thus if it holds for two user-selected keys K and K* that a + c is always a constant, then the subkeys ki,0 for K and the subkeys k*i,0 for K* are equal, i.e., ki,0 = k*i,0 for i = 1, …,16. If a + c is to be constant for all values of i, then it must hold that (b || a) = (b || a)<<8 = (d || c) = (d || c)<<8, which means that if a = a0, a1, a2, a3, where ai are byte valued, and similar for b, c, and d, then it must hold that for some constant e that

• ai + cj = e for all i, j = 0, 1, 2, 3,

• ai + dj = e for all i, j = 0, 1, 2, 3,

• bi + cj = e for all i, j = 0, 1, 2, 3,

• bi + dj = e for all i, j = 0, 1, 2, 3.

Summing up, let the user-selected key be divided into the 32-bit words a, b, c, d. Consider the keys obtained from having a0 = a1 = a2 = a3 = x for some value x, and b = a, c0 = c1 + c2 = c3 = y for some value y, and d = c. Then it holds that the keys for which x + y is a constant will produce the same

16 values for ki,0 for i = 1, …,16. Thus, there are 2 keys which can be divided into 256 classes of each

256 keys, such that in one class all 256 keys produce identical values of the subkeys ki,0 for i = 1, …,16. Table 3.43 lists three keys and the subkeys they generate.

It follows by very similar that there are 216 keys which can be divided into 256 classes of each 256 keys, such that in one class all 256 keys produce identical values of the subkeys ki,1 for i = 1, …,16. Table 3.43 lists three (other) keys and the subkeys they generate.

Despite of these findings the key schedule of SEED does not seem to allow for related-key attacks. First of all, the “related keys” reported above are few, second, the relations between them does not seem to be strong enough to allow for these kinds of attacks.

The above phenomena are not a threat for SEED when used for encryption. If a key is chosen uniformly at random, the probability to pick one of the above keys is very small. Moreover it is not clear for which applications an attacker would be able to exploit the use of such keys. On the other hand, such similarities between the subkeys of different keys do not appear in other modern block ciphers and could probably have been prevented.

145 CRYPTREC 2001

Key = 9b9b9b9b 9b9b9b9b 11111111 11111111 Round key no. 1 4124db1d 3451bd29 2 9a0f9a3a 4b127456 3 79efee8e 273d39c9 4 57215006 b12689b3 5 03c24bbc 5f7092c7 6 c0a53c4c 2b831b79 7 cf3ebb62 d29fac9a 8 2a14ef6c a2c6cfe2 9 7b85aa09 07894284 10 f527f311 9100f2f9 11 4ee60e85 14546a91 12 26d5c935 864101db 13 803e5e92 34e0e2c0 14 c91d482b 2b10ede5 15 0788fd30 2d60d71e 16 f92d78ce 2bd7ef41

Key = 3a3a3a3a 3a3a3a3a 72727272 72727272 Round key no. 1 4124db1d e0ef1874 2 9a0f9a3a 711b066c 3 79efee8e 5c178ff9 4 57215006 0b809197 5 03c24bbc 26afe9b0 6 c0a53c4c 3c1b8a18 7 cf3ebb62 573ddbb6 8 2a14ef6c c0be0d10 9 7b85aa09 75080ba7 10 f527f311 56ab375e 11 4ee60e85 39e99972 12 26d5c935 1591baad 13 803e5e92 0ffc828b 14 c91d482b 2d9680fc 15 0788fd30 8e5a5bd0 16 f92d78ce 5e235141

Key = 2a2a2a2a 2a2a2a2a 82828282 82828282 Round key no. 1 4124db1d 07460ff4 2 9a0f9a3a b82298f4 3 79efee8e 7ee3b13e 4 57215006 46c3d6b0 5 03c24bbc 4af65578 6 c0a53c4c 1bb446d4 7 cf3ebb62 0b5a1d9e 8 2a14ef6c bfaa5324 9 7b85aa09 4c16e012 10 f527f311 1d68f56f 11 4ee60e85 7def7131 12 26d5c935 52eff20b 13 803e5e92 3c3c924e 14 c91d482b e02f858f 15 0788fd30 74fd6be4 16 f92d78ce a9ccd586 Table 3.42: Examples of keys which produce equal first subkeys in every round.

146 CRYPTREC 2001

Key = 9b9b9b9b 9b9b9b9b efefefef efefefef Round key no. 1 68c9edf1 7d28cbaf 2 7e8e4d27 f9c76fad 3 aa37e9ee f59dd258 4 5da694ad 7605924a 5 c61b186a b3c83014 6 45dc4ae5 bfb0fcbe 7 05ce5df3 fd6a1882 8 9ab323b3 6ef967c7 9 a08e3ccc d883dcd7 10 8c92b184 13ddd10c 11 77553f19 af7cecc4 12 24e69b24 e007b43e 13 bca52806 5f7651a0 14 dd2474e9 1e09a2f2 15 0eeecd5b 9c28a623 16 3685e91e bcad5740

Key = 3a3a3a3a 3a3a3a3a 8e8e8e8e 8e8e8e8e Round key no. 1 0d92c044 7d28cbaf 2 de60205a f9c76fad 3 d9258549 f59dd258 4 9d84df1f 7605924a 5 ea0a79a8 b3c83014 6 638fd5fa bfb0fcbe 7 470a077c fd6a1882 8 c252c5d8 6ef967c7 9 a6b5f762 d883dcd7 10 a55b43b7 13ddd10c 11 ca3a056e af7cecc4 12 a678af9c e007b43e 13 4aa21758 5f7651a0 14 a0ab171a 1e09a2f2 15 1d432710 9c28a623 16 ad80bb01 bcad5740

Key = 2a2a2a2a 2a2a2a2a 7e7e7e7e 7e7e7e7e Round key no. 1 f23c7655 7d28cbaf 2 0b5f9dbd f9c76fad 3 656eb6da f59dd258 4 886b8015 7605924a 5 caac1ba9 b3c83014 6 54d62348 bfb0fcbe 7 a9bdeb44 fd6a1882 8 8bb07ddf 6ef967c7 9 661831f3 d883dcd7 10 05090fea 13ddd10c 11 60f094cc af7cecc4 12 3393a0f5 e007b43e 13 770ab190 5f7651a0 14 10702afd 1e09a2f2 15 0ef8e298 9c28a623 16 7c8e917d bcad5740 Table 3.43: Examples of keys which produce equal second subkeys in every round.

147 CRYPTREC 2001

(3) Comments on fixed points of the S-boxes

The designers of SEED argued in [1] that one reason for modifying the outputs of the power polynomials x247 and x251 by affine mappings was to remove the fixed points 0 and 1. However, although these affine mappings remove these two fixed points, it has also the effect that it introduces

three other fixed points, namely 23, 230, for S-box S1 and 28 for S-box S2. Design policy and the design result do not seem to match well with respect to fixed points, though it is unlikely that these new fixed points give rise to new threats.

3.3.4.4 Software implementation evalua tion

Regarding software implementation, the source program submitted by the designers was compiled and executed with a PC by the CRYPTREC secretariat in witness of committee members, and its performance was measured. Tables 3.44 and 3.45 show the results of evaluation.

Table 3.44: Data randomization part speed measurement results ([cycles/block])

Pentium III (650MHz) Language C Program size 45056 bytes (including encryption/decryption/key scheduling) Compiler option VC++6.0 Win32 Release (Default) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 846 / 871 846 / 873 Second round 846 / 867 846 / 867 Third round 846 / 866 846 / 867

Table 3.45: Key schedule part + data randomization part speed measurement results ([cycles/block])

Pentium III (650MHz) Language C Program size 49152 bytes (including encryption/decryption/key scheduling) Compiler option VC++6.0 Win32 Release (Default) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 1233 / 1255 1235 / 1256 Second round 1233 / 1255 1235 / 1257 Third round 1233 / 1255 1235 / 1257

References [1] Korean National Body, “Contribution for Korean Candidates of Encryption Algorithm (SEED)”, related to ISO/IEC JTC1 SC27 N2563, 2000. http://www.kisa.or.kr/seed/data/

148 CRYPTREC 2001

algorithm/seed_english.doc. [2] Korean , http://dosan.skku.ac.kr/~sjkim/kg_std.html. [3] Hitoshi Yanami, Takeshi Shimoyama, “Differential attacks to SEED” Symposium on cipher and information security 2002, January 29 - February 1, 2002

3.3.5 MULTI-S01

3.3.5.1 Technical overview

MULTI-S01 is a cryptographic technique proposed in 2000 by Furuya, Watanabe, and Tagkaragi at the ISEC Research meeting. MULTI-S01 consists of encryption and decryption functions, each of which is composed of a pseudorandom number generator and a data randomization part. The pseudorandom number generator generates key streams A, B, and S (in correspondence to the length of the data to be processed) from the secret key K (256 bits). The encryption process uses message M (n x 64 bits), redundance code R (64 bits), secret key A (¹ 0, 64 bits), secret key Bi ((n + 2) x 64 bits), and select key S (64 bits) as inputs, and outputs ciphertext C ((n + 2) x 64 bits). The decryption process uses ciphertext C (64 x n’ bits), redundance code R (64 bits), secret key A (A ¹ 0, 64 bits), secret key B (64 ´ n’ bits), and secret key S (64 bits) as inputs, and outputs an alteration-detection signal or message M (64 x (n’ - 2) bits). In terms of security, the designers of MUTI-S01 have reportedly tried to simultaneously achieve message secrecy and message authentication, and build a configuration that cannot be realistically attacked (i.e., in which the output of the pseudorandom number generator, which becomes the target for cryptanalysis, cannot be uniquely identified). Security is based on the integrity of the pseudorandom number generator. MULTI-S01 uses PANAMA as its pseudorandom number generator.

3.3.5.2 Technical Specifications

In the encryption process, message M, redundancy R (64 bits), and secret key K (256 bits) are input as byte-string data (M(8)i (i = 1, …, [m/8]), R(8)i (i = 1, …, 8), and K(8)i (i = 1, …, 32), respectively. The output of the encryption process is ciphertext C. The length of C is 64 x ([m/64] + 2)bits, and C is output as a byte string. In the corresponding decryption process, ciphertext C (c bits), redundancy R (64 bits), and secret key K (256 bits) are input as byte-string data (C(8)i (i = 1, …, [c/8])), R(8)i (i = 1, …, 8), and K(8)i (i = 1, …, 32), respectively. The output of the decryption process is either decryption result M’ or an alteration-detection signal, and when a message is to be output, it is output as a byte string. Both the encryption and decryption process are composed of 64-bit block processes, and the number of blocks for the entire process is n = [m/64] + 2. The pseudorandom number generator uses K as the input and outputs A (64 bits), B (64 x (n + 2)bits),and S (64 bits). Therefore, the data randomization part of the decryption process outputs C using M, R, A, B, and S as inputs, and the data randomization part of the decryption process

149 CRYPTREC 2001

outputs either decryption result M’ or and alteration-detection signal using C, R, A, B, and S as inputs. Keys, plaintexts, ciphertexts, redundant data, and initial values are handled as strings in byte units. These strings are transformed into Big-Endian during the transformation into the 64-bit data type.

3.3.5.3 Other

One of the technologies that MULTI-S01 uses as the base is a pseudorandom number generator called PANAMA. PANAMA is a cipher module suggested by J. Daemen and C. Clapp in 1998, and can be used as method of configuring stream ciphers and hash functions. PANAMA has been proposed as a pseudorandom number generator that is secure in terms of complexity, and is said to have been designed based on symmetric cipher technologies, a complexity theory, computer science, algebra, and statistics. MULTI-S01 uses the pseudorandom number generator function of PANAMA only.

3.3.5.4 Results of detail evaluation (fiscal 2000) n Security evaluation

Although strict security evaluation has not yet been performed on MULTI-S01 as a stream cipher in the academic community, MULTI-S01 is secure for the most part. No operational problems should be encountered if careful attention is paid to an alteration-detection function and a key-management function during system design. MULTI-S01 consists of a pseudorandom number generator and a shuffling function. Detailed evaluations have been performed on the long-period characteristics, linear complexity, correlation values, equal 0/1 frequency, series, and uniformity in relation to the random number characteristics of the outputs from the pseudorandom number generator, and no particular problem has been reported. Because the period of the random number series is determined from K and Q, sufficient evaluation has not been performed. However, this does not actively imply that the random number series has a problem. Detailed evaluation has been performed on the correlation between the input from the pseudorandom number generator and the ciphertext output, as well as on the correlation between the message series and the ciphertext output in relation to the characteristics in the input/output of the shuffling function, and no particular problem has been reported. Divide-and-conquer attack, correlation attack, linear cryptanalysis, and differential cryptanalysis were evaluated with MULTI-S01, and no major risk has been reported. It has been reported that differential cryptanalysis has resulted in a successful attack when the same key is used for encrypting messages. However, such a problem can be avoided if the keys are strictly managed. n Software implementation evaluation

Software implementation was evaluated under the following environment. Table 3.46 shows the results of evaluation.

150 CRYPTREC 2001

Table 3.46: Data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language ANSI C Program size 12868 KByte Compiler option /nologo /G6 /ML /W3 /GX /O2 /Ob2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /Fas /Fa"Release/" /Fp"Release/VLIW64_NEW.pch" /YX /Fo"Release/" /Fd"Release/" /FD /GM /c Encryption (Fastest/Average) Decryption (Fastest/Average) First round 176 / 180 — Second round 175 / 177 — Third round 176 / 177 —

Note: Stream ciphers were originally designated for hardware implementation. PANAMA is not based on the applicant’s proprietary implementation. Instead, the fastest program that can be obtained was used. It is a C language program without any special optimization.

Table 3.47 shows the result of the self-evaluation report.

Table 3.47 Evaluation results in self-evaluation report

Memory usage Speed (Mbps) (/byte) Initialization 2.4Kbyte Encryption 3.6Kbyte 270.7Mbps 17.7 Decryption 3.7Kbyte 267.3Mbps 18.0 n Hardware implementation evaluation

A simulation was run on an Altera FPGA (Field Programmable Gate Array) after coding the circuits using Verilog-HDL for a program written in the C language. The following development environments were used:

Language: C Compiler option (DEC cc): Optimization option -tune ev56 -arch ev56 -O6 CPU: Alpha 21164A 600MHz, RAM: 512Mbyte OS: DIGITAL UNIX 4.0E

• ModelSlim VHDL/Verilog Version 5.4e (Model Technology) • Synplify (Synplicity Inc.)

The evaluation results follow.

151 CRYPTREC 2001

Table 3.48 Hardware implementation result

Operating frequency Processing speed (Gbps) Resource usage FPGA used (MHz) 18.8 1.203 19,811/42,240 ATOMs (46%) EP20K1000E

The self-evaluation report shows the following results:

0.35-mm CMOS technology

(1) Throughput priority: 140 Kgates, operating frequency of 140MHz, and throughput of 9.1 Gbps (2) Circuit-size priority: 68 Kgates, operating frequency of 620 (or 200) MHz, and throughput of 620 (or 200) Mbps

n Other evaluation

Under the heading “Usage and precaution on random number string number Q,” the specification documents status, “A pseudorandom number that is new (one that has never been generated by the device) must always be used when encrypting plaintext. This is based on a technical reason related to security.” However, this “technical reason” is not explained. In particular, it is not clear how to determine whether or not the device generates pseudorandom number. If the “technical reason” means that the same random number string must not be used in duplicate, that restriction applies to all stream ciphers in general and is not a problem for MULTI-S01. The determination method is not clear because there has not been any report that shows same random number string will not be generated if random number string number Q is different. Although the statistical evaluation of MULTI-S01 is not necessarily sufficient, no result reports any security problem yet.

3.3.5.5 Results of detail evaluation (fiscal 2001)

The results of the evaluation of MULTI-S01 in CRYPTREC Report 2000 are summarized as follows.

• No problems have been found regarding security as a stream cipher. • Precise evaluation at academic conferences, etc. has not been obtained yet, thus requiring continuous evaluation. • The processing speed in the software belongs to a fast group.

Based on the results of the evaluation stated above, continuous evaluation was made regarding security of MULTI-S01 this year. As the concrete procedure, the pseudorandom number generator (PA NAMA) and the encryption part that materializes the mode of operation were separated, and evaluation was made on each of them, thus allowing more precise evaluation. The contents of each detailed evaluation are as follows. (Inside

152 CRYPTREC 2001

of [ ] is the number of evaluators.)

1. Evaluation regarding MULTI-S01 as a mode of operation [2] 2. Security of PANAMA against theoretical cipher analysis [2] 3. Randomness examination of PANAMA using a computer [1]

Regarding these security evaluations implemented in 2001, the overview and results of each one of them are described below. In the next two sections, the descriptions that follow the symbol “•” are the summary of evaluations by external evaluators, and the descriptions that follow “ü” are the comments of the Committee members for the descriptions marked with “•”.

3.3.5.6 Evaluation of security of MULTI-S01 as a mode of operation

Evaluation is implemented regarding the relation between the method for use of PANAMA, which is a cipher component in the MULTI-S01 system, and security. But since MULTI-S01 uses the pseudorandom number generator function of PANAMA only, this evaluation does not deal with the internal structure of PANAMA. n MULTI-S01 specification

• The specification for MULTI-S01 describes the method of encrypting a message. But it does not clearly describe the method of encrypting multiple messages (evaluator 2). ü Evaluator 2 proposes a method of encrypting multiple messages. The proposed method of encryption is a natural extension of the encryption method stated in MULTI-S01specification. n Definition of security of MULTI-S01

• The definition of security described in the self-evaluation report is an extremely weak definition as compared with standard definition of security. The self-evaluation report proves the security against “enemy who executes ciphertext only attack by single ciphertext ” in relation to , and proves the security against “known plaintext attack composed of a pair of single plaintext and ciphertext ” in relation to authenticity. In this respect, the submitter should prove the security against “enemy who executes adaptive chosen plaintext attack” in relation to both privacy and authenticity (evaluator 1). • The definition of security of authenticated encryption of stream cipher is not known in general. A definition of s ecurity that is appropriate for stream cipher should be given (evaluator 2). ü Both evaluator 1 and evaluator 2 give definitions of security that should be considered by the submitter. The definition of security (indistinguishability from random bits) related to privacy is exactly the same between evaluator 1 and evaluator 2. Regarding authenticity, while evaluator 1 allows only one inquiry to verification oracle, evaluator 2 allows multiple inquiries, and the definition is stronger with evaluator 2.

153 CRYPTREC 2001

n Security of MULTI-S01

• Evaluator 1 gives a guideline and overview of the proof of MULTI-S01 being able to satisfy the definition of security proposed by himself. The proof of evaluator 1 is incomplete and the submitter should complete the proof by himself. • Evaluator 2 indicates that MULTI-S01 satisfies the definition of security proposed by himself. ü The security in computational complexity of MULTI-S01 was indicated by evaluator 2. Furthermore, identical result by the submitter is reported in SCIS2002 [5]. n Method for replacement

• It is possible to generate an authenticated encryption of a stream cipher that is identical to that of MULTI-S01 by combining Vernam cipher and Carter-Wegman MAC, and this configuration is structurally simple, the ciphertext is short and messages of arbitrary lengths can be handled (Evaluator 2). ü Since it is considered that the combination of Vernam cipher and Carter-Wegman MAC and MULTI-S01 have advantages of their own, it is hard to compare them at present. n Conclusion

ü Evaluator 1 and evaluator 2 evaluate computational security of MULTI-S01 from the viewpoint of reducing the security of MULTI-S01 to that of PANAMA. The security of MULTI-S01 was appropriately defined, and as a result of evaluation made under the viewpoint, it was indicated that security of this cipher might be reduced to that of PANAMA.

3.3.5.7 Theoretical cipher analysis of PANAMA

Since security of MULTI-S01 is largely affected by PANAMA, it is necessary to theoretically evaluate the security of PANAMA itself used as a module. Since it was indicated, as a result of the preceding section, that security of MULTI-S01 is reduced to that of PANAMA, the results of this section directly affects the security of MULTI-S01. PANAMA is a cipher algorithm proposed by Daemen and Clapp in 1998, and includes two types, i.e., the hash function and pseudorandom number generator. But MULTI-S01 uses pseudorandom number generator only. Therefore, only the security of the pseudorandom number generator of PANAMA is evaluated here.

The cipher analysis was performed regarding the following five items.

1. Chosen-IV Collision Attacks (Evaluator 1) 2. Chosen-IV Differential Attacks (Evaluator 1) 3. Chosen-IV Related-Key Attacks (Evaluator 1) 4. An Equivalent Representation (Evaluator 2)

154 CRYPTREC 2001

5. Analysis of Simpler Variants of PANAMA (Evaluator 1, evaluator 2)

Analyses 1 to 3 above assume a case where the attacker can freely select a value of 256 bits of PANAMA called deviation parameter. This value is considered to be public information input to PANAMA. Secret key (256 bits) is expressed as K, deviation parameter is expressed as Q, and the key stream output from PANAMA is expressed as PANAMA(K, Q). As the criteria of evaluation of security, it can be indicated that regardless of how the attacker determines Q for all the K values, distinction between PANAMA(K, Q) and binary uniform probability variable is computationally hard. Analysis 4 indicates a certain equivalent expression of PANAMA and indicates mutually independent factors in it. Analysis 5 is a result of cipher analysis conducted on a number of simplified versions against PANAMA. n Chosen-IV Collision Attacks

• If (Q, Q’) (Q ¹ Q’) with which PANAMA(K, Q) = PANAMA(K, Q’) is satisfied is present for a certain K, it is possible to almost accurately judge, by selecting such Q and Q’, whether the secret key is K or not. As a result of search of the structure of PANAMA, however, it was found that such a K does not exist. However, it is not clear in the case where Q has higher bit length, and it may be present even in the case where Q is 512 bits, for example (Evaluator 1). ü Such a K should exist at least when Q can be arbitrarily taken long. Furthermore, when the results of Rijmen et al. [4] are observed, it can be said that a set of such (Q, Q’) can be realistically found in the state where K is given. n Chosen-IV Differential Attacks

• When the internal condition of PANAMA immediately after K and Q were pushed (input into the buffer) is expressed as M and the internal condition of PANAMA immediately before output of key stream after completion of blank pull is expressed as M’, if an expression established at a high probability in relation to the differential of Q, M, M’ (differential equation) does exist, calculation of this expression can be used as a means of an attack. However, no differential equation having a high probability was found as a result of the analysis. However, the results of Rijimen et al. indicate that a differential equation of high probability does exist for the differential of whole input (K, Q) and the differential of M, M’ (Evaluator 1). n Chosen-IV Related-Key Attacks

• There may be an attack under the assumption that Key Stream PANAMA(K ÅD K, Q ÅD Q) at the time of addition of arbitrary differential value to K and Q can be obtained (Evaluator 1). ü This attack is related to collision attacks when Q is 512 bits. Otherwise, it is an attack under non-realistic circumstances.

155 CRYPTREC 2001

n An Equivalent Representation of PANAMA

• k-th (k = 1, ..., 32) bit of j-th (j = 1, ..., 8) word of i-th (i = 0, ..., 31) round of the buffer at point t is i expressed as b j,k (t) . It is assumed to be a vector representation of each when j and k are omitted.

Identically, k-th bit of j-th (j = 0, ...., 17) word of the state at point t is expressed as aj, k(t).

252431 Since the 25th update of the buffer becomes bj(t+1)=Åbjj(t)bt+2mod8 (), when buffer’s

update only is observed, the range of influence of changes in bits can be divided into {b0, b2, b4, b6}

and {b0, b3, b5, b7}. Furthermore, since update is in word units, change to the k-th bit in a certain round does not affect bits other than k-th bit of other rounds. Therefore, the configuration of PANAMA can be represented as divided into the partial structure stated above (Evaluator 2). ü As the buffer can be divided into the partial structure stated above, even when one bit in the buffer is changed in the push mode, its influence is limited to each partial structure. In the pull mode, however, since the input to the buffer is dependent on the state, the influence of one bit in the buffer is exerted over the entire structure. n Analysis of Simpler Variants of PANAMA

As simpler variants of PANAMA, evaluator 1 indicated a case where blank pulls are omitted and evaluator 2 indicated PANAMA-S1, PANAMA-S2 and PANAMA-SM. The case where blank pulls are omitted, which is considered to be most important, as well as PANAMA-S2 and PANAMA-SM are explained here.

(1) Case where blank pulls are omitted in PANAMA

• When blank pulls are omitted, a8, ..., a16, which are a part of the state, out of the internal condition after K and Q were pushed, is equivalent to the first 256 bits of the key stream. But they are determined without depending on Q. When Q is changed, therefore, it is satisfactory if discrimination is made by whether the first 256 bits of the key stream change or not when Q is changed. The same thing may happen when the number of times of blank pulls is smaller than 33, which is normal. When blank pulls are up to 14 times, it is possible to make distinction from a uniform probability variable using an input pair having an appropriate differential vector (Evaluator 1). ü Although this method cannot be very realistic because it is classified in related-key attacks, it is considered to be effective when the distribution of K has low . It is not clear whether such an analysis shown here is also effective when blank pulls are implemented 33 times normally. ü MULTI-S01 does not mention whether blank pulls are implemented or not. Reference Implementation is of no problem because blank pulls are implemented, but when related-key attacks stated above are considered, it is necessary to clearly indicate that blank pulls are implemented.

156 CRYPTREC 2001

(2) PANAMA-S2

• PANAMA-S2 is a version using update function called r = s ¡ p instead of state update function

r = s ¡ q ¡ p ¡ g. For attacking, it becomes possible to calculate the key stream thereafter by estimating the contents of the buffer and state at a certain point when pull is being performed, under 16 the condition where key stream [a j (t)] j=9,t = 1,L,n of length n (word units) is obtained (Evaluator 2). ü The attack algorithm is considered to be logically free of errors, but the calculated value of the attack algorithm is stated as “Proportional to 265.” However, since the number of variables searched for in the algorithm is 24.7 x 225 = 253, it is considered that “Proportional to 258 ” is correct in total.

(3) PANAMA-SM • With PANAMA-SM, which is most similar to PANAMA, the update function of state is expressed as

r = s ¡ q* ¡ p ¡ g*. The conditions that should be satisfied by q* and g* are indicated in concrete in * the report, but the point is, when a j(t) ºq * op o g * (a j (t)) , it is satisfactory if the condition that * * * * * * calculation is feasible with the key stream only for a2(t) , a4(t) , a7(t) , a9(t) , a11(t) , a12(t) , * * a14(t) , a16(t) is satisfied. With this condition, the attack algorithm itself can be executed without any difference from PANAMA-S2 (Evaluator 2). n Conclusion

• It is not concluded that it is secure against the simplest attacks and that other two are of particularly low security. But it is largely due to shortage of time spent for evaluation (Evaluator 1). ü PANAMA-S2 and PANAMA-SM have a character, which is not possessed by PANAMA, that a part of results of intermediate calculation in the update of the state can be definitely determined. Since this character itself makes large contribution to the attack algorithm, it is considered that the attacks shown in the report will not become direct threats. However, as described in “An Equivalent Representation”, they have a character that “the structure of PANAMA can be expressed as divided into 64 partial structures ”, thus raising the possibility that attacks using this character do exist.

ü With actual PANAMA, q op o g (a j(t)) does not always have convenient conditions stated above. Therefore, it cannot be considered that attacks against PANAMA can be made by slightly modifying this attack algorithm itself (increasing the number of variables to be searched for, for example). ü Evaluator 2 states as an improvement plan for PANAMA that provisions should be made so as not to 25 have the character stated above by making update of b j (t) of the buffer more complex. This is a reasonable plan, but there is a possibility that it may simultaneously trigger an implementation problem that the parallel processing of update of the buffer cannot be executed.

157 CRYPTREC 2001

3.3.5.8 Results of statistical examination related to randomness of PANAMA

Analysis is made here regarding statistical character of PANAMA used by MULTI-S01. In other words, PANAMA was seized black-box-wisely as a pseudorandom number generator, without considering its internal structure at all, and evaluation was made on various statistical characters of its output series to check if sufficient performance is provided as a component of stream cipher MULTI-S01. The pseudorandom examination program appended to SP 800-22 of NIST was used as the method for examination of .

It is considered as a result that bias among series of output random numbers caused by bias of input is not observed at all after initial shuffling of 32 times. Furthermore, it is judged that no distinction can be made in many statistical characters between output series and true random number series of PANAMA generation. n Pseudorandom number generator PANAMA: PANAMA is a cipher module proposed by J. Daemen, et al. in 1998, and it is possible to configure a stream cipher and hash function using PANAMA.

Using secret key K of 256 bits and random number string number Q of 256 bits as input, PANAMA outputs a pseudorandom number string of an arbitrary length. PANAMA has three operation modes indicated below.

• reset mode: Reset of the internal conditions • push mode: Input of secret key K and random number string number Q • pull mode: Initial shuffling and generation of pseudorandom number string n What is statistics test tool SP 800-22: The statistics test tool adopted here is SP 800-22 of NIST. SP 800-22 is a statistics test tool of random number and pseudorandom number for cipher applications disclosed by NIST and its documents [6, 7]. In the AES selection, statistics examination with this tool was conducted against candidate ciphers. SP 800-22 permits the use of 16 examination methods, and tests of 189 types can be conducted. A list of statistics examination methods that can be executed with SP 800-22 is indicated below.

• Frequency Test • F-T within a Block • Cusum Test • Runs Test • Test for the Longest Runs of Ones in a Block • Binary Matrix Rank Test • Discrete Fourier Transform (DFT) Test • Non-overlapping Template Matching Test • Overlapping Template Matching Test • Mauer’s Universal Statistical Test

158 CRYPTREC 2001

• Approximate Entropy Test • Random Excursion Test • Random Excursion Variant Test • Serial Test • Lempel-Ziv Compression Test • Linear Complexity Test

On the other hand, the output of SP 800-22 is “examination pass rate” and “distribution”. In each test, in which area of normal distribution or c 2 distribution the pseudorandom number string, which is the object of examination, is located is expressed by a value (0 - 1) called P-value. “Examination pass rate” in output is for 300 series, and it is judged as “pass” when the P-value is 0.01 or higher. “Distribution” in output is used to examine if P-values of 300 series are uniform. P-values of each series are compiled for evaluation in ten sections of 10% each. n Random number examination (results of experiments): Two types of tests were conducted to examine characteristics of cipher algorithms. One is [Partial round test] that permits examination of the shuffling process using a part of the cipher algorithms, and the other is [Full round test] that examines pseudorandomness in the whole cipher algorithm.

[Partial round test]

Partial round test was conducted by regarding PANAMA as a 256-bit block cipher, secret key as key, random number string as plaintext, and initial shuffling of 32 times as a round. With attention paid to the fact that handling of key and plaintext (random number string number) is the same as in PANAMA, key/ciphertext correlation, which observes the correlation with key like plaintext/ciphertext correlation, was added. In this manner, whether there is any bias among output series when there is a bias in the secret key or random number string can be evaluated. By laying the results in the order of rounds, how input keys and random number string numbers are shuffled can be observed.

[Full round test]

Full round test was conducted in the following sequence.

1. Secret keys generated with random numbers and random number string numbers were input for PANAMA, and a pseudorandom number string of 314572800 bits after initial shuffling was generated. 2. The pseudorandom number string generated in step 1 above was regarded as 1048576 x 300, and a statistics test was conducted with SP 800-22. 3. Steps 1 and 2 above are repeated 128 times and “examination pass rate” and “distribution” of SP 800-22 were output.

159 CRYPTREC 2001

The reason why step 3 is repeated 128 times here is to improve the reliability.

It can be judged as a result of statistics test stated above that no defects are found in particular in the pseudorandomness of PANAMA. n Others : In the process of actual conduct of statistics examination of this time, it was found that there is a possibility that heuristic parameters are displaced from those of true random numbers at two points (“distribution” evaluation of each of examination item DFT and Lempel-Ziv) at least in the examination program [7] appended to NIST’s random number examination document SP 800-22. n Conclusion: The statistical character of PANAMA was evaluated using SP 800-22. As a result of evaluation of shuffling property of secret keys and random number string numbers in initial shuffling of PANAMA, it was found that sufficient shuffling is achieved by initial shuffling of around seven times, for all of bias of data in input secret keys and random number string numbers, bias of differential, and correlation with input data. It can be considered that bias among series of output random numbers caused by the bias in the input is not observed at all with initial shuffling of 32 times, with which pseudorandom number strings of PANAMA specification are output, because of this reason.

Furthermore, as a result of evaluation of statistical character in the case where a long pseudorandom number series is output using PANAMA, it can be judged that the subject pseudorandom number series cannot be distinguished from a true random number series in numerous statistical characters. It can be said that the random number examination against PANAMA revealed no defects in particular in relation to pseudorandomness of PANAMA.

3.3.5.9 General comment

It was indicated in the detailed evaluation of the year 2001 that security of MULTI-S01 is reduced to the characters of pseudorandom number generator PANAMA. On the other hand, no fatal defects were found from the results of security analysis and statistical examination related to PANAMA.

Although it is hard to say that the anxiety against security of this cipher has been completely eliminated based on the evaluation of 2001, the number of cases where security as a pseudorandom number generator is theoretically guaranteed is extremely small, and particularly when the pseudorandom number generator is characterized by high speed operations, it is considered to be hard in general to completely guarantee security. For this reason, this situation cannot be considered to be a problem unique to this cipher. It is judged that this cipher is an object of observation in 2002 and subsequent.

160 CRYPTREC 2001

References [1] Soichi Furuya, Masashi Takahashi, Futoshi Watanabe, Kazuo Takaragi “Proposal of symmetric cipher that permits message authentication using pseudorandom number generator” Shingaku Giho ISEC2000-8, 2000. [2] Soichi Furuya, Futoshi Watanabe, Kazuo Takaragi “Consideration of padding and security of MULTI-S01” Shingaku Giho ISEC2000-68, 2000. [3] J. Daemen, C. Clapp. “Fast Hashing and Stream Encryption with Panama,” FSE'98, 1998. [4] V. Rijmen, B. Rompay, B. Preneel, J. Vandewalle. “Producing Collisions for Panama.” FSE’01, 1998. [5] Soichi Furuya “Security in computational complexity of MULTI-S01”, Proceedings of SCIS2002, pp.253-258. 2002. [6] NIST Special Publication 800-22, “A Statistical test suite for random and pseudorandom numb er generators for cryptographic applications,” http://csrc.nist.gov/rng/SP800-22.pdf, http://csrc.nist.gov/rng/errata2.pdf). [7] NIST Special Publication 800-22, “NIST Statistical Test Suite,” http://csrc.nist.gov/rng/ sts-1.4.tar, http://csrc.nist.gov/rng/sts.data.tar).

3.4 Evaluation of Ciphers under Monitoring

3.4.1 Hierocrypt-L1

3.4.1.1 Technical overview

Hierocrypt-L1 is a symmetric block cipher that was proposed by Toshiba on September 8, 2000 at the domestic workshop on (CSEC) of the Information Processing Society of Japan. It consists of a byte-conversion layer (S) in which eight 8-bit S-boxes are arranged in parallel, a byte- layer

8 (MDSL) in which two 4x4 MDS arrays on GF(2 ) are arranged in parallel, a byte-permu tation layer (MDSH) consisting of 2x2 MDS arrays on GF(232), and a key addition layer (K). Each round of the round function begins with K, followed by S, MDSL, K, S, and is terminated with MDSH. The last round begins with K, followed by S, MDSL, K, and S, and is terminated with K. An encryption process repeats the round function 5 times, and then performs one last round.

Technical points: Achievement of both computation efficiency and security through the use of recursive SPN

161 CRYPTREC 2001

3.4.1.2 Technical specificati ons n Input/output key length

• Input/output length: 64 bits • Key length: 128 bits • Number of rounds: 6 • Structure: Recursive SPN n Design philosophy

• The goal is to design a cipher that is sufficiently strong against major symmetric cipher attacks, that runs at high speeds on major platforms, and that can be implemented in a small size. • To achieve both computation efficiency and security, the data randomization part uses a recursive SPN structure. • S-box is optimized for resistance against differential/linear cryptanalysis based on a power multiplication function on a Galois field. Furthermore, application of algebraic attacks is made difficult by sandwiching the power multiplication function between bit permutation and affine transformation. • The diffusion layer is chosen not only so that the lower bound of the active S-boxes is maximi zed, but also taking both the security and the implementation efficiency into consideration. • The key schedule part is based on a 64-bit Feistel structure, and expanded keys are generated by combining intermediate outputs. Around-trip structure is adopted, in which an intermediate key string is reversed in the middle and returns, such that the initial delay of the on-the-fly subkey generation becomes small during decryption as well.

3.4.1.3 Other

Hierocrypt-L1 has nearly the same structure as Hierocrypt-3, which is a 128-bit block cipher. In both of these ciphers, the decryption speed of the data randomization part alone is slightly slower that that of encryption.

3.4.1.4 Evaluation results

Because a SQUARE attack can be applied to seven layers out of the six rounds (that are equivalent to 12 layers), careful attention must be paid, especially to the expansion of SQUARE attacks in the future. Nonetheless, no attack method that can pose a threat has so far been discovered. n Number of rounds that can be broken: By applying Type 1 expansion [3] to Ferguson et al.’s method [2], up to six layers out of the six rounds (12 layers) can be shortcut. The number of chosen plaintext s

162 CRYPTREC 2001

needed for this is 235, and the number of computations is the same as 272 round function computations [5]. Furthermore, detailed evaluation revealed that by estimating the key for one more round, up to seven layers can be attacked. The number of chosen plaintexts needed for this is 237, and the number of computations is the same as 2117 round function computations [5].

Specifically, when a L set in which only the left (or right) 4 bytes are active is given, the input in the fourth layer becomes a L set in which all 8 bytes are active, and the input in the fifth layer becomes balanced. By determining whether or not each byte of the input in the fifth layer, counted backwards from the output in the seventh layer, is balanced, the validity of the keys related to the fifth through seventh layers can be verified. n Basis of security: Two points indicated below were confirmed in the self-evaluation report and detailed evaluation. (1) The maximum differential/linear characteristic probability does not exceed 2-90 in two rounds (4 layers). (2) The maximum differential/linear probability does not exceed 2-48 in two rounds and subsequent. (1) is apparent from the lower bound of the number of active S-boxes, and (2) can be proven using the technique of Hong et al. [4] based on the assumption that the key of each round is independent and uniform. It has not be clarified so far whether or not the maximum differential/linear probability can be smaller than 2-48 in three or more rounds. Note that the maximum differential/linear characteristic probability for three or more rounds determined in the self-evaluation was not an accurate value, as explained in the self-evaluation, and was not numerical value that can be proven. The reason it is not possible to conclude that the upper bound of the maximum differential/linear probability for three or more rounds will always be smaller than 2-48 is as follows. Hierocrypt-L1 with three or more rounds can be considered that (bijective) S-boxes with the maximum differential probabilities of 2-48 are strung in series. Even if multiple S-boxe s with the maximum differential probabilities of 2-48 are strung in series, it cannot be concluded that the maximum differential probability will always be smaller than 2-48.

It has been verified that the truncated differential cannot be differentiated from random permutation in three rounds (five layers) out of six rounds. As for higher order differential attack, the possibility that an effective higher order differential will be discovered is presumed to be extremely low since a) the algebraic degree of the S-box is 7, b) bit permutation is performed on the input side of the S-box to complicate the algebraic structure, and c) an MDS array is used for the diffusion layer, and the number of items in the polynomial expression when this MDS array is combined with the S-box is large enough.

3.4.1.5 Software implementation evaluation

Software implementation was evaluated in the environments listed as follows. Tables 3.49 and 3.50 show the evaluation results.

163 CRYPTREC 2001

Table 3.49 Data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language ANSI C + assembler (486 instructions) Program size 52982 bytes (including encryption/decryption/key scheduling) Compiler option VC++ 6.0speed priority option is used Encryption (Fastest/Average) Decryption (Fastest/Average) First round 199 / 201 204 / 206 Second round 199 / 201 204 / 206 Third round 200 / 201 204 / 205

UltraSPARC IIi (400MHz) Language ANSI C + assembler Program size 24496 bytes (including encryption/decryption/key scheduling) Compiler option cc -native -fast -xarch=v9 -xCC Encryption (Fastest/Average) Decryption (Fastest/Average) First round 378 (332) / 380 (336) 500 (304) / 504 (307) Second round 378 (332) / 380 (336) 500 (304) / 504 (308) Third round 378 (332) / 380 (336) 500 (304) / 504 (308)

Alpha 21264 (463MHz) Language ANSI C Program size 84328 bytes (including encryption/decryption/key scheduling) Compiler option cc -O3 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 210 (179) / 214 (182) 210 (179) / 212 (182) Second round 210 (179) / 214 (182) 210 (179) / 212 (182) Third round 210 (179) / 213 (182) 210 (179) / 212 (182)

Note: In the measurements using UltraSPARC IIi and alpha21264, the values inside the parentheses were obtained after the applicant modified the measurement program. Although a massive buffer area is allocated to the measurement program to maintain general purpose characteristics, the program was modified by the applicant to allocate just enough buffer area. It has been verified that no modifications were made that would affect the speed evaluation results.

The applicant has reported the following self-evaluation results:

CPU: Pentium III 550MHz Primary cache: 32 KB, secondary cache: 512 KB RAM: 256 MB OS: Windows 2000 professional build 2195 Speed

164 CRYPTREC 2001

Key generation: 3.07Mkeys/sec, 179.0 cycles Encryption: 139.13 Mbps, 253.0 cycles Decryption: 67.56Mbps, 512.0 cycles

Table 3.50 Key schedule part + data randomization part speed measurement result (unit: cycles/block)

Pentium III (650MHz) Language ANSI C + assembler (486 instructions) Program size 52982 bytes (including encryption/decryption/key scheduling) Compiler option VC++ 6.0speed priority option is used Encryption (Fastest/Average) Decryption (Fastest/Average) First round 374 / 375 616 / 618 Second round 374 / 377 616 / 617 Third round 374 / 375 616 / 618

UltraSPARC IIi (400MHz) Language ANSI C + assembler Program size 24496 bytes (including encryption/decryption/key scheduling) Compiler option cc -native -fast -xarch=v9 –xCC Encryption (Fastest/Average) Decryption (Fastest/Average) First round 718 (616) / 721 (620) 1203 (1014) / 1215 (1031) Second round 718 (616) / 721 (619) 1203 (1012) / 1215 (1030) Third round 718 (616) / 721 (620) 1203 (1015) / 1215 (1031)

Alpha 21264 (463MHz) Language ANSI C Program size 84328 bytes (including encryption/decryption/key scheduling) Compiler option cc -O3 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 390 (386) / 394 (389) 625 (617) / 654 (648) Second round 390 (386) / 394 (389) 625 (617) / 653 (648) Third round 390 (386) / 394 (389) 625 (617) / 653 (648)

Model: JT6N5 Processor: Z80 (5MHz) ROM: 48 KB RAM: 1KB EEROM: 8KB Coding language: Z80 Assembler

165 CRYPTREC 2001

Memory usage ROM: 26 bytes RAM: 2,447 bytes Speed Encryption: 3.88 ms

3.4.1.6 Hardware implementation evaluation

Hardware implementation evaluation was conducted under the environment indicated below. The results of evaluation are as follows.

Evaluation environment: Mitsubishi 0.35 mm CMOS ASIC library Description language: Verilog-HDL Synthesizer: Design Compiler

Table 3.51: Hardware implementation result

Circuit size (gates) Data randomization part 278,130 Key schedule part 95,397 Control circuit — Entire Primitive 373,526 Circuit path (ns) 70,13 Throughput (Mbps) 912,519

Others: This is the implementation evaluation when the importance is given to the shortening of the critical path (improvement of throughput) irrespective of the circuit size. The critical path does not include key scheduling.

The applicant reported the following in the self-evaluation report.

Design environment: Design Compiler made by SYNOPSYS 1999.10-3 Simulation condition: 1.35 V 70°C (1.5V, 25°C in the standard case) Throughput: 586 Mbps (128.2 MHz, 14clocks, 6 rounds)

Reference [1] Okuma, Sano, Muratani, Motoyama, and Kawamura, About the Security of Block Ciphers Hierocrypt-3 and Hierocrypt-L1, SCIS2001, 2001. [2] N. Ferguson, J. Kelsey, S. Lucks, B. Schneier, M. Stay, D. Wagner, and D. Whiting, Improved Cryptanalysis of Rijndael, available at http://www.counterpane.com/rijndael.html, 2000

166 CRYPTREC 2001

[3] J. Daemen, L.R. Knudsen, and V. Rijmen, The block cipher SQARE, Fast Software Encryption: LNCS 1267, pp.149-165, 1997 [4] S. Hong, S. Lee, J. Lim, J. Sung, and D. Cheon, Provable Security against Differential and Linear Cryptanalysis for the SPN Structure, FSE2000, 2000.4 [5] Muratani, Okuma, Motoyama, and Kawamura, Proposal on 64-bit Hierocrypt, Information Processing Society Research Report CSEC11-9, 2000/09.

3.4.2 MISTY1

3.4.2.1 Technical overview

MISTY1 is a symmetric block cipher with a block length of 64 bits and an encryption key length of 128 bits, developed by Mitsubishi Electric Corporation in 1996 [10, 11]. It was submitted by Mitsubishi Electric as a candidate cipher for the e-Government. MISTY1 uses a Feistel structure and key-dependent linear transformation, and the internal function of the Feistel structure uses a function that recursively combines a modified Feistel structure. It has been shown that this structure gives MISTY1 provable security against differential and linear cryptanalysis [8, 9]. MISTY1 can be implemented in a wide range of cipher applications, from 8-bit processors for smart cards to 64-bit RISC processors. One notable characteristic of MISTY1 is that, with a processor having a particularly large number of registers , it can achieve high-speed processing using software and a Bitslice implementation method (68 cycles/block with the Alpha processor) [12, 13, 14, 15, 16]. Another characteristic is that MISTY1 can be implemented in hardware using an extremely small size of 10 K gates or fewer [1, 2]. It has been five years since this cipher was announced, and there is great deal of solid evidence supporting it.

3.4.2.2 Technical specifications n Overall structure

• A block cipher with a block length of 64 bits and an encryption key length of 128 bits. • Uses a Feistel structure and key-dependent linear transformation (FL-function), and the internal function of the Feistel structure uses a function that recursively combines a modified Feistel structure. • The number of rounds can be varied but must be a multiple of four; the recommended number of rounds is eight. n Design philosophy

• Security must be backed by a numerical basis. Especially, using a theory on provable security against differential and linear cryptanalysis, which are

167 CRYPTREC 2001

powerful general-purpose attacking methods of block ciphers, a large and secure cipher has been designed from small and secure functions, based on a recursive structure. • Practical performance must be achievable using software, regardless of processor type. To create a cipher that can be used in as many applications as possible, instructions that can achieve high-speed processing only on particular processors were not used. Instead, only basic instructions that can achieve appropriate high speed and small size using any processor were used. Furthermore, the working memory size has been designed to be small, with implementation in smart cards in mind. • Sufficiently high speed must be achievable using hardware. Arithmetic operations were not used because they sometimes lead to speed degradation, and the entire algorithm consists of logical operations and table look up only. The table has been designed to be optimized using hardware.

3.4.2.3 Other

One year before the announcement of MISTY1, its developers showed a theory related to the modified Feistel structure to be used in MISTY1 and its security, along with multiple specific examples of block ciphers that use this structure. Although these ciphers have no names, one of these, described as Algorithm 1, is considered to be the basis for MISTY1 [8, 9].

A 64-bit block cipher, MISTY2, which processes provable security against differential and linear cryptanalysis similar to MISTY1, has also been announced [10,11].

KASUMI was developed mainly by 3GPP as an algorithm, created by customizing MISTY1 for mobile phones, and was adopted in March 2000 as the core area of the secrecy and completeness algorithm for next -generation mobile phones (W-CDMA) [21].

3.4.2.4 Result of security evaluation

It has been theoretically proven that MISTY1’s data randomization part achieves a maximum average differential/linear probability of 2-56 or less in three rounds, and therefore MISTY1 can be considered sufficiently secure against differential and linear cryptanalysis. Furthermore, the analysis results of a detailed evaluation indicate that both the data randomization part and the key schedule part are secure against conventional attacks.

Because side channel attacks are in principle applicable to nearly all block ciphers, care must be exercised during implementation for MISTY1 as well. Generally speaking, when implementing a cipher in a smart card, it is better to make sure during software implementation that power analysis attacks are not effective against the FL-function, which is a key-dependent linear function, as well as S-box, for which countermeasures are already known.

168 CRYPTREC 2001

n Data randomization part: When analysis were performed on linear cryptanalysis, truncated differential cryptanalysis, chi-square attack, partitioning attacks, higher order differential attack, interpolation attacks, impossible differential cryptanalysis, mod n attack, non-bijective attack, and Ludy-Rackoff flow randomness, none of these attacks was effective against MISTY1 with the standard specification.

Note that although the recommended number of rounds for MISTY1 is eight, it has been reported that, if the number of rounds is five or fewer (six or fewer if the FL-function is omitted), some of the expanded keys can be revealed. This can be done using an improved higher order differential attack [19, 20] with a number of computations smaller than that required in an exhaustive key search. It is also reported that part of the expanded keys of 5-round MISTY1 (with FL-function) has been derived in one as a result of the cryptanalysis experiment using a computer [4] (see Table 3.52). In addition, the experiment results against impossible differential cryptanalysis [7], (SQARE attacks) [6, 5], and multivariable interpolative polynomial attacks [18, 4] have been reported. But all these are the analytical results for the attacks to MISTY1 with non-standard specifications, e.g., with a smaller number of rounds. At present, there are no known results which may effect the security of MISTY1 of standard specifications.

Table 3.52 Number of rounds attacked and number of computations needed for breaking

Number of rounds MISTY1 MISTY1, excluding FL-function Data volume Number of Data volume Number of computations computations 4 rounds 28.4 285 24 27.2 5 rounds 222 233 210.5 217 6 rounds — — 210.5 293 n Key schedule part: When the key schedule part was analyzed using the exhaustive key search, weak keys/semi-weak keys, related key attacks, and slide attack, none of attack method was found to threaten the security of the entire cipher, though the effectiveness of some of the methods cannot be denied.

Eight key variables K1, K2, …, K8 obtained from partitioning 128 bits into 16-bit units, were arranged according to different orders for individual rounds and used for the key schedule part of MISTY1. Therefore, if K1 = K2 = … = K8 holds true for these 16-bit values, the expanded keys in all rounds become the same.

128 16 Because of this characteristic, out of all 2 secret keys, 2 secret keys that satisfy K1 = K2 = … = K8 may become weak keys against slide attack in a cipher that is obtained by removing the FL-function from MISTY1. However, because it is difficult to apply this attack to a cipher that include the FL-function, and because the number of keys that are considered weak keys is extremely small compared to the whole, such an attack should not be considered a threat to MISTY1’s security.

169 CRYPTREC 2001

n Side channel attacks: Countermeasures against timing attacks are considered either unnecessary or extremely easy in terms of both software and hardware. Power analysis attacks on S-boxes are generally known, and the power used for the FL-function may also vary depending on the expanded keys. Therefore, care must be exercised when implementing MISTY1 in software for smart cards.

3.2.4.5 Software Implementation Evaluation

Software implementation was evaluated in the environments listed as follows. Tables 3.53 and 3.54 show the evaluation results.

Table 3.53 Data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language Assembler Program size 21353 bytes (including encryption/decryption/key scheduling) Compiler option Encryption (Fastest/Average) Decryption (Fastest/Average) First round 213 / 215 208 / 210 Second round 213 / 215 208 / 210 Third round 213 / 214 209 / 211

Alpha 21264 (463MHz) Language Assembler Program size 15632 bytes (including encryption/decryption/key scheduling) Compiler option Encryption (Fastest/Average) Decryption (Fastest/Average) First round 203 / 205 206 / 208 Second round 203 / 206 206 / 208 Third round 203 / 205 206 / 208

Table 3.54 Key schedule part + data randomization part speed measurement result (unit: cycles/block)

Pentium III (650MHz) Language Assembler Program size 17681 bytes (including encryption/decryption/key scheduling) Compiler option Encryption (Fastest/Average) Decryption (Fastest/Average) First round 357 / 358 350 / 351 Second round 357 / 358 350 / 351 Third round 357 / 358 350 / 351

170 CRYPTREC 2001

Alpha 21264 (463MHz) Language Assembler Program size 10088 bytes (including encryption/decryption/key scheduling) Compiler option Encryption (Fastest/Average) Decryption (Fastest/Average) First round 334 / 338 337 / 340 Second round 334 / 338 337 / 340 Third round 334 / 338 337 / 340

Although there was difference of about five cycles between the encryption and decryption, both values were basically the same.

As an indication of processing performance, the applicant has report assembly language-based implementation results on a Pentium III (800 MHz) and Alpha21264 (667 MHz). Speeds of 193 and 192 cycles/block, respectively, have been reported.

n Smart card implementation: As an indication of processing performance on embedded 16-and 8-bit microcomputers, the applicant has reported implementation results on an M16C (20MHz) and H8/300 (3.57 MHz) [16]. Implementation results on an 8-bit processor Z80 (5 MHz) have also been reported by Sano et al [17]. The units for both encryption and decryption are cycles/block.

Processor Encryption / key-scheduling ROM RAM M16C 1877 / 743 3400 byte 64 byte H8/300 6018 / 1240 1900 byte 43 byte Z80 25486 (including key scheduling) 1598 byte 44 byte

3.4.2.6 Hardware Implementation Evaluation Hardware implementation evaluation was made in the environment specified below. The results of the evaluation are as follows.

Descriptive language: VHDL Simulator: ModelSim5.4a Design Library: 0.25m CMOS ASIC Design Library Logic synthesizing tool: Design Compiler .2000.05-1

Results of simulation [1, 2] using a Mitsubishi 0.35-micron CMOS ASIC Design Library and examples of implementation [3] using Vertex Series E and Vertex Series II, which are FPGA produced by Xilinx, are shown as examples of implementations by the applicant.

171 CRYPTREC 2001

Implementation 1: 7.6 Kgates, 72 Mbps Implementation 2: 50 Kgates, 800 Mbps

Data randomization *1 19,935 part *2 10,609 *1 44,773 Key schedule part *2 28,194 Circuit size (gates) *1 94 Control circuit *2 68 *1 64,809 Entire Primitive *2 38,875 *1 11.86 Critical path (ns) *2 24.70 *1 600 Throughput (Mbps) *2 288

*1: Logical synthesis with throughput priority *2: Logical synthesis with circuit-size priority

Reference [1] Tetsuya Ichikawa, Junji Katoh, and Mitsuru Matsui, A method of implementing secret key cipher MISTY1 in Hardware, Proceedings of SCIS98, SCIS98-9.1.A, 1998. [2] Tetsuya Ichikawa, Tooru Tanno, and Mitsuru Matsui, Considerations Related to Hardware Design of Secret Key Ciphers, SCIS97-9.D, 1997. [3] Tetsuya Ichikawa, Tooru Sorimachi, Tomomi Kasuya and Mitsuru Matsui, On Hardware Implementation of Block Ciphers Selected at the NESSIE Project Phase I (1), Proceesings of SCIS2002, SCIS2002-12C-3, 2002. [4] Yasuo Hatano, Hidema Tanaka, Toshinobu Kaneko, Higher Order Differential Attack of MISTY1, Proceedings of SCIS2002, SCIS2002-13A-5, 2002. [5] I. Kim, Y. Yeom, H. Kim, Square Attacks on the Reduced-Round MISTY1, Proceedings of SCIS2002, SCIS2002-13A-2, 2002. [6] L. Knudsen, D. Wagner, Integral Cryptanalysis, Pre -proceedings of the International workshop of Fast Software Encryption 2002, pp.108-122, (to appear in Lecture Notes in Computer Science), 2002. [7] U. Kuehn, Improved cryptanalysis of MISTY1, Pre-proceedings of the International workshop of Fast Software Encryption 2002, pp.56-70, (to appear in Lecture Notes in Computer Science), 2002. [8] Mitsuru Matsui, Tetsuya Ichikawa, Tooru Tanno, Toshio Tokita, and Atsuhiro Yamagishi, Practical block ciphers with provable security against differential and linear cryptanalysis, Proceedings of SCIS 1996 SCIS96-4C, 1996.

172 CRYPTREC 2001

[9] M. Matsui, New Structure of Block Ciphers with Provable Security against Differential and Linear Cryptanalysis, Proceedings of the 3rd international workshop of Fast Software Encryption, Lecture Notes in Computer Science 1039, pp.205-218, Springer Verlag, 1996. [10] Mitsuru Matsui, Block Cipher A lgorithm MISTY1, Shingaku Giho ISEC96-11, 1996. [11] M. Matsui, New Block Encryption Algorithm MISTY, Proceedings of the 4-thinternational workshop of fast software encryption, Lecture Notes in Computer Science 1267, Springer Verlag, pp.54-68, 1997. [12] Junko Nakajima and Mitsuru Matsui, Fast Software Implementation of MISTY (I), Shingaku Giho ISEC97-12, 1997. [13] Junko Nakajima and Mitsuru Matsui, Fast Software Implementation of MISTY (II), Proceedings of SCIS 98, SCIS98-9.1.B, 1998. [14] J. Nakajima, M. Matsui, Fast Software Implementation of MISTY1 on Alpha Processors, IEICE Trans. Funcationals, Vol E82-A, No.1 January 1999. [15] Junko Nakajima and Mitsuru Matsui, Fast Software Implementation of MISTY (III), Shingaku Giho ISEC2000-81, 2000. [16] Junko Nakajima and Mitsuru Matsui, Optimal Software Implementation of Symmetric Cipher MISTY1, Proceedings of SCIS 2001, 13A-3, 2001. [17] F. Sano, M. Koike, S. Kawamura, M. Shiba, Performance Evaluation of AES Finalists on the High-End Smart Card, 3rd AES Conference, New York, 2000. [18] Kyoji Shibutani, Atsushi Kobayashi, Takeshi Shimoyama, Shigeo Tsujii, Polynomial Representation of the Inner Function of MISTY1 and its Application to Cryptanalysis, Proceedings of SCIS2002, SCIS2002-10A-3, 2002. [19] H. Tanaka, M. Hisamatsu, T. Kaneko, Higher Order Differential Attack of MISTY1 without FL functions, JWIS'98, ISEC98-66, pp.143-150, 1998. [20] Hidemoro Tanaka, Shuji Ishii, and Toshinobu Kaneko, Strength Evaluation of KASUMI and MISTY, Proceedings of SCIS 2001 12A-1, pp.647-652. 2001. [21] 3GPP, KASUMI, ETSI/SAGE Specification, 1999. (http://www.etsi.org/dvbandca/3GPP/3gppspecs.htm)

3.4.3 Triple DES

For details, refer to Subsection 6.3.2.

173 CRYPTREC 2001

3.4.4 Camellia

3.4.4.1 Technical overview

Camellia is 128-bit block symmetric cipher jointly developed by NTT and Mitsubishi Electric Corporation. It was announced in 2000 at an academic conference [3]. Three key lengths (128, 192, and 256 bits) are available. Camellia’s basic structure is an 18-round (128-bit key length) or 24-round (192/256-bit key length) Feistel type structure. FL/FL-1-functions are inserted in every six rounds, thus breaking structural uniformity.

Camellia has been designed with a focus on balancing security and implementation, and aims to achieve efficient implementation in both software and hardware implementation in particular. Camellia belongs to the fastest and smallest group in the world at present in terms of encryption/decryption speed (22.0Mbits / (s. Kgates)) and gate size (approximately 10 Kgates).

Because Camellia also has a simple key schedule structure, its keys can be changed quickly. It can be used in a wide range of applications, from high-speed encrypted communication to smart cards which do not have many computation resources.

3.4.4.2 Technical specifications

The basic components of the round function consist of S-boxes and EXOR, while the components of the FL/FL-1-functions consists of logical OR, logical AND, EXOR, and rotation.

Arithmetic operations are not used at all. As a result, long critical paths have been eliminated, and compact circuit size has been achieved. The function for generating expanded keys has been designed to enable on-the-fly subkey generation. n Data randomization part

In case of 128-bit key: The data randomization part consists of an 18-round Feistel structure and FL/FL-1-functions. The F-function, which is a 64-bit output in the Feistel structure, is synthesized from the S-function and P-function, which are also 64-bit outputs. The S-function consists of four 8-bit input/output S-boxes. The P-function consists of eight 8-bit linear images executed in parallel. Two layers of FL/FL-1-functions are provided and inserted immediately following the sixth and twelfth rounds. FL/FL-1-functions, which are 64-bit outputs, use logical OR, logical AND, 1-bit cycle shift, and EXOR. The difference between MISTY and Camellia in terms of FL/FL-1-functions is introduction of the 1-bit cycle shift. Initial and final EXORs are performed immediately before the round and immediately following the last round, respectively. In the key schedule part, 26 64-bit expanded keys are generated from a 128-bit secret key K. (A part of the procedure for generating expanded keys is the same as that used in the data randomization part.)

174 CRYPTREC 2001

In the data randomization part, an EXOR between a plaintext and two joined expanded keys is computed, and the result is halved. Then, the following operations are executed for r = 1 through 18. (Note that r = 6 and 12 are excluded.)

Lr = R r-1 Å F(Lr-1, kr)

Rr = Lr-1

When r = 6 or 12, FL/FL-1-functions are also used, to break structural uniformity. Finally, EXORing with two expanded keys is performed.

In case of 192-and 256-bit keys: The data randomization part consists of a 24-round Feistel structure and FL/FL-1-functions. Three layers of FL/FL-1-functions are provided and inserted immediately following the sixth, twelfth, and eighteenth rounds. EXORing with an expanded key is performed immediately before the first round and immediately following the last round. n Decryption: Decryption of the Camellia cipher is performed in the same manner as encryption, expected by reversing the order of the expanded keys. n Key schedule part: The key schedule part uses two 128-bit data and four 64-bit data. Using these values, two 128-bit data, Ka and Kb, are generated. Note that Kb is used only with a 192- or 256-bit key. An expanded key is either the left or right half of the value obtained by circularly shifting an intermediate key. The key schedule part has simple structure and shares part of the encryption process. Expanded keys can also be dynamically generated, and are generated at about the same efficiency for both encryption and decryption. The amount of memory used for expanded key generation is also small (approximately 32 bytes of RAM for a 128-bit key, and approximately 64 bytes of RAM for 192/256-bit key). n Security design: Camellia’s security has been designed to ensure sufficient resistance against differential cryptanalysis, linear cryptanalysis, and truncated differential cryptanalysis, which are considered the primary attack methods, based on estimated upper bounds of the maximum average differential characteristic probability and the maximum average linear characteristic probability. Resistance to other attacks, such as higher order differential attacks, interpolation attacks, related-key attacks, impossible differential cryptanalysis, and side attacks, has also been taken into account at the design stage.

3.4.4.3 Other

The Camellia cipher [3] has been developed and designed based on several cryptographic techniques, including NTT’s proprietary cryptographic technique [1] and Mitsubishi Electric Corporation’s proprietary cryptographic technique MISTY[2]. For example, the design rationale for the round function (F-function) and the linear transformation function (P-function) is based on the design rationale for the

175 CRYPTREC 2001

F-function and the P-function of E2. The design rationale for the FL/FL-1-functions is based on the design rationale for the FL-function of MISTY. The major change in cipher design is that implementation performance on PCs, Smart cards, and hardware has been improved.

3.4.4.4 Result of security evaluation

Neither the results of the screening evaluation nor the detailed evaluation have identified any serious security problem with this cryptographic technique. Especially against differential and linear cryptanalysis, the actual number of rounds that can be attacked is expected to be about seven or eight. Therefore, Camellia can satisfy security requirements in a practical sense. Note that, by a truncated differential path search, some effective characteristics applied to attack a 7-round variant Camellia cipher without the auxiliary functions FL/FL-1 have shown [4]. In addition, it is shown that 10-round Camellia without the auxiliary function is breakable by controlled higher order differential attacks [9]. Summary of the detailed evaluation results is as follows.

• In a 5-round variant Camellia cipher without the auxiliary functions FL/FL-1, it is sometimes possible to narrow down 1 byte of an expanded key in the fifth round to a single one, using two chosen plaintexts and an analysis based on a byte polynomial. • The 6-round Camellia cipher can be attacked by controlled higher order differential attacks using 217 plaintexts and 222 computations. By the same process, Camellia without the auxiliary functions is breakable in 221 plaintexts and by 2258 computations*1 which are smaller than the number of computations by exhaustive key search. • Because Camellia uses a bijective round function, it should be possible to estimate a key for a 6-round variant Camellia cipher without the auxiliary functions FL/FL-1, using a smaller number of computations than exhaustive key search. • By applying a boomerang attack that uses two differentials, it should be possible to estimate a key for an 8-round variant Camellia cipher without the auxiliary functions FL/FL-1, using a smaller number of computations than exhaustive key search. • In the key schedule part, the case that 1 byte of unknown secret key can be computed from 5 bytes of a secret key and 6 bytes of an intermediate key exists. No security problem has also been discovered from truncated differential and liner cryptanalysis, higher order differential attack, impossible differential cryptanalysis, interpolation attack, linear sum attacks, and slide attack, along with differential cryptanalysis and linear cryptanalysis.

*1 Number of computations of round function

176 CRYPTREC 2001

3.4.4.5 Software Implementation Evaluation software implementation was evaluated in the environments listed as follows. The evaluation results are as listed in Tables 3.55 and 3.56.

Table 3.55 Data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language Assembler Program size 29285bytes (including encryption/decryption/key scheduling) Compiler option /G6 /ML /O2 /Ob2 /Og /Oi /Ot /Ox /Oy /Gr /I Encryption (Fastest/Average) Decryption (Fastest/Average) First round 326 / 327 326 / 328 Second round 326 / 327 326 / 327 Third round 326 / 327 326 / 327

UltraSPARC IIi (400 MHz) Language Assembler Program size 15240 bytes (including encryption/decryption/key scheduling) Compiler option -fast - xtarget=ultra -xarch=v9a Encryption (Fastest/Average) Decryption (Fastest/Average) First round 355 / 360 355 / 357 Second round 355 / 358 355 / 358 Third round 355 / 357 355 / 357

Alpha 21264 (463MHz) Language Assembler Program size 31552 bytes (including encryption/decryption/key scheduling) Compiler option -O -arch ev6 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 282 / 288 282 / 288 Second round 282 / 289 282 / 288 Third round 282 / 288 282 / 289

Table 3.56 Key schedule part + data randomization part speed measurement result (unit: cycles/block)

Pentium III (650MHz) Language Assembler Program size 20110 bytes (including encryption/decryption/key scheduling) Compiler option /G6 /ML /O2 /Ob2 /Og /Oi /Ot /Ox /Oy /Gr /I Encryption (Fastest/Average) Decryption (Fastest/Average) First round 467 / 487 474 / 493 Second round 467 / 487 474 / 494 Third round 467 / 487 474 / 493

177 CRYPTREC 2001

UltraSPARC IIi (400MHz) Language Assembler Program size 23992 byte (including encryption/decryption/key scheduling) Compiler option -fast -xcrossfile -xtarget=ultra -xarch=v9a Encryption (Fastest/Average) Decryption (Fastest/Average) First round 403 / 408 403 / 407 Second round 403 / 407 403 / 407 Third round 403 / 408 403 / 408

Alpha 21264 (463MHz) Language Assembler Program size 25792 byte (including encryption/decryption/key scheduling) Compiler option -O -arch ev6 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 448 / 454 435 / 439 Second round 448 / 454 435 / 439 Third round 448 / 455 435 / 439

According to the applicant’s implementation examples, a result of 24.07 Mbits/s was achieved using Java on a 32-bit PC. In optimized implementation using an assembly language, 276 Mbps and 308 cycles were achieved on a Pentium III (800 MHz) and a Pentium Pro (200 MHz), respectively. n Smart card implementation: Smart card implementation results based on Z80 are shown as follows. (Note: The applicant evaluated the data for the 128-bit key.)

Processing speed Key generations: 5,146 states Encryption: 28,382 states Memory ROM: 1,698 bytes RAM: 62 bytes

3.4.4.6 Hardware Implementation Evaluation

Hardware implementation was evaluated in the following environment. The evaluation results follow. Note that the evaluation was performed on an encryption circuit for 256-bit key. It was designed using Verilog and was synthesized under conditions that focus on throughput priority and circuit-size priority under the same condition.

Coding language: Verilog HDL Simulator: VCS5.1

178 CRYPTREC 2001

Design library: 0.25-mm CMOS ASIC Design Library Logic synthesize tool: Design Compiler, 2000.05-1 Operating conditions: 0°C-70°C, 3.3 V ± 5%

The hardware evaluation results are shown in Table 3.57. These values appear reasonable considering a key length difference. The applicant has evaluated ASIC and FPGA implementation for a 128-bit key. The results follow. Encryption/decryption circuits and a key-generation circuit were implemented using approximately 10 K gates (0.35-mm CMOS ASIC). Throughput is 212.2 Mbits/s .

Table 3.57 Hardware evaluation results

Data randomization *1 16,327 parts *2 9,668 *1 22,755 Key schedule *2 13,304 Circuit size (gates) *1 266 Control circuit *2 141 *1 39,348 Entire Primitive *2 23,124 *1 5.46 Critical path (ns) *2 11.51 *1 837 Throughput (Mbps) *2 397

*1: Logical synthesis with throughput priority *2: Logical synthesis with circuit-size priority

3.4.4.7 Supplementary remark

The review of the implementation technique of Camellia cipher have been made recently by those other than the applicant, and an improvement in circuit-size and processing performance have been achieved [5]. Its security also has continuously been reviewed, thus enhancing the preciseness of the evaluation. However, no particular problems h ave so far been found [6,7,8].

Reference [1] M. Kanda, S. Moriai, K. Aoki, H. Ueda, M. Ohkubo, Y. Takashima, K. Ohta, and T. Matsumoto, A New 128-bit Block Cipher E2, Technical Report ISEC98-12, IEICE, 1998 [2] M. Matsui, New Block Encryption Algorithm MISTY, In E. Biham, editor, Fast Software Encryption — 4th International Workshop, FSE97, Vol.1267, LNCS, pp54-68, 1997

179 CRYPTREC 2001

[3] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, J. Nakjima, and T. Tokita, Camellia: A 128-Bit Block Cipher Suitable for Multiple Platforms, Seventh Annual Workshop on Selected Areas in Cryptography, SAC2000 pp.41-54, 2000 (Japanese version: 128-bit Block Cipher Camellia, Shingaku Giho, ISEC2000-6, May 2000.) [4] Shibuya, Shimoyama, and Tsujii, Truncated Linear Attack on Byte-Oriented Ciphers, SCIS2001,Jan.2001, pp.591-596. [5] Sato, Morioka, and Chou, Compact hardware architecture of 128-bit block cipher, Camellia, SCIS2002, pp.595-598, Jan.2002 [6] Y. Yeom, S. Park, and I. Kim, On the Security of CAMELLIA agaist the Square Attaack, FSE2002, Feb.2002 [7] T. Shirai, S. Kanamaru, and G. Abe, Improved Upper Bound of Differential and Linear Characteristic Probability for Camellia, FSE2002, Feb.2002 [8] Takeda and Kaneko, A Study on controlled higher order differential cryptanalysis against Camellia, SCIS2002, pp.915-919, Jan. 2002 [9] T. Kawabata and T. Kaneko, “A Study on Higher Order Differential Attack of Camellia,” 2nd NESSIE workshop, Sept. 2001

3.4.5 Hierocrypt-3

3.4.5.1 Technical overview

Hierocrypt-3 is a block cipher [1] that was proposed by Toshiba in 2000 at the workshop of the Computer-security Study Group of the Information Processing Society of Japan. It has a block length of 128 bits and supports three key lengths (128, 192, and 256 bits). Hierocrypt-3 has been designed with the objectives of achieving the security level associated to the key lengths and efficient software/hardware implementation. It focuses on fast encryption speed in smart cards and in particular.

3.4.5.2 Technical specifications • The goal is to design a cipher that is sufficiently strong against major cryptanalytic attacks , that runs at high speeds on major platforms, and that can be implemented in a small size in hardware implementation. • To achieve both computational efficiency and cryptographic security, the data randomization part uses a recursive SPN structure. • The recursive SPN structure is extremely simple, and its elemental functions can be designed more or less independently while maintaining sufficient security. Additionally, Hierocrypt-3 can flexibly cope with block-length changes.

180 CRYPTREC 2001

• The S-box is optimized for resistance against differential and linear cryptanalysis based on a power multiplication function on a Galois field. Furthermore, application of algebraic attacks is made difficult by sandwiching the power multiplication function between bit permutation and affine transformation. • For the diffusion layer, a large number of active S-boxes with large lower bounds are generated as candidates using the coding theory, and then these candidates are narrowed down based on security and implementation efficiency. • The key schedule part is based on a 128-bit Feistel structure, and expanded keys are generated by combining intermediate outputs. A round-trip structure has been adopted in which the generation function of intermediate keys is reversed in the middle and returns, such that the initial delay of the on-the fly subkey generation remains short during decryption as well. • The number of rounds depends on key length, and is 6, 7, and 8 for key length of 128, 192, and 256 bits, respectively.

3.4.5.3 Other

Hierocrypt is the name assigned to a family of some block ciphers developed by Toshiba. This family includes Hierocrypt-3, with a 128-bit block length, and Hierocrypt-L1, with a 64-bit block length. Both of these ciphers share a common feature in which the data randomization part is designed using a recursive type of SPN structure.

3.4.5.4 Result of security evaluation

At this point (of March 2002), only limited information is obtained of the security of this cipher because it has not been long time since it was announced. In the limited information obtained so far, no crucial cryptanalysis is found for any key length. But some results of evaluation are going to be published and attention needs to be paid on further results of evaluation to come. In the self-evaluation report by the designer, the security of this cipher against various cryptanalytic attacks is discussed. The evaluation of differential cryptanalysis and linear cryptanalysis, in particular, is highly reliable. For the new evaluation techniques [10, 12], security evaluation results have been continuously updated by means of a newly employed evaluation process or an improved evaluation [13, 9]. For the SQUARE attack, one of the attacks to which the designer of Hierocrypt-3 pays keenest attention, a possibility of the attack against variant Hierocrypt-3 reduced to 3.5 rounds is pointed out [11]. This slightly differs from the initial opinion of the designer that secure against SQUARE attacks with smaller number of rounds (2.5 rounds) than Rijndael (as announced by the designers in SCIS2001). Hierocrypt-3, however, is specified for use with no less than 6 rounds, and there can be no direct menace to its security under this specification. Some linear relations are obtained as “simple dependent relations among expanded keys”, which appears in the description of the

181 CRYPTREC 2001

specifications, reading “the linear combinations should be appropriately chosen so that weak keys do not appear, that is, there are no simple relations between the round keys” (although the meaning of this sentence is somewhat ambiguous) [5]. An avalanche effect indicates the presence of bias in the key schedule part and the round function. Contrary to a part of the design rationale that proclaims “the number of terms in polynomial expressions is the maximum when MDS matrices and S-box are combined”, it is found as a result of an evaluation that the number of terms in polynomial expressions is not maximal. Other new results of evaluations have been announced, including the interpolation attack [8], impossible differential cryptanalysis [6], and experimental random-number examination [15], but none of these evaluations threaten the security of Hierocrypt-3 in its specification. Information covering the evaluation results of security is also available in some documents of the NESSIE project [14,17].

Because Hirrocrypt-3’s elemental technologies, such its SPN structure, S-boxes evaluation, and MDS, have been designed based on recent cryptographic research results, no obvious or fatal defects are expected to occur in the future in any of these elements. Finally, because design rationale and the algorithm are intuitively and theoretically connected to each other, it is very much unlikely to suppose that the designer has intentionally built in any trapdoor.

3.4.5.5. Software Implementation Evaluation

Software implementation was evaluated in the following environments. The evaluation results are listed in Tables 3.58 and 3.59.

Table 3.58 Data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language ANSI C + assembler (MMX instructions) Program size 68832 bytes (including encryption/decryption/key scheduling) Compiler option VC++ 6.0 Win32 Release (Default) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 404 / 406 426 / 428 Second round 404 / 406 426 / 428 Third round 404 / 406 426 / 428

UltraSPARC IIi (400MHz) Language ANSI C Program size 38936 byte (including encryption/decryption/key scheduling) Compiler option cc -native -fast -xarch=v8plusa –xCC (encryption) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 511 (471) / 554 (473) 759 (612) / 826 (616) Second round 510 (471) / 556 (473) 758 (612) / 826 (616) Third round 510 (471) / 555 (473) 757 (612) / 826 (616)

182 CRYPTREC 2001

Alpha 21264 (463MHz) Language ANSI C Program size 58152 byte (including encryption/decryption/key scheduling) Compiler option cc -O3 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 420 (399) / 424 (406) 427 (386) / 429 (393) Second round 420 (399) / 424 (406) 427 (386) / 430 (394) Third round 420 (399) / 423 (407) 427 (386) / 430 (393)

Table 3.59 Key schedule part + data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language ANSI C + assembler (MMX instructions) Program size 68832 bytes (including encryption/decryption/key scheduling) Compiler option VC++6.0 Win32 Release (Default) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 726 / 728 1345 / 1358 Second round 726 / 729 1344 / 1357 Third round 726 / 728 1346 / 1358

UltraSPARC IIi (400MHz) Language ANSI C Program size 38936 byte (including encryption/decryption/key scheduling) Compiler option cc -native -fast -xarch=v8plusa –xCC (encryption) cc -native -fast -xarch=v9 –xCC (decryption) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 823 (761) / 828 (822) 2673 (2612) / 2684 (2627) Second round 823 (761) / 828 (821) 2671 (2611) / 2683 (2627) Third round 824 (761) / 828 (823) 2670 (2610) / 2683 (2627)

Alpha 21264 (463MHz) Language ANCI C Program size 58152 byte (including encryption/decryption/key scheduling) Compiler option cc -O3 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 675 (668) / 679 (672) 1130 (1130) / 1142 (1141) Second round 675 (668) / 678 (673) 1130 (1130) / 1142 (1142) Third round 675 (668) / 679 (672) 1130 (1130) / 1142 (1142) Note: In the measurements using UltraSPARC Iii and Alpha 21264, the values inside the parentheses were obtained after the applicant modified the measurement program. Although a massive buffer area was allocated to the measurement program to maintain general-purpose characteristics, the applicant modified the program to allocate just enough buffer area. It has been verified that not modifications were made that would affect the speed-evaluation results.

183 CRYPTREC 2001

3.4.5.6 Hardware Implementation Evaluation

Hardware implementation evaluation results are shown as follows. These results are based on the assumption that a loop architecture is not used and the entire algorithm is optimized with throughput priority. Therefore, it is possible to reduce the circuit size.

Table 3.60 Hardware evaluation results

Data randomization part 538,078 Key schedule part 106,302 Circuit size (gates) Control circuit — Entire Primitive 724,380 Critical path (ns) 75.55 Throughput (Mbps) 1,694.24

The following four implementation examples using cell libraries or FPGAs have been reported:

0.14-mm CMOS ASIC: 897 Mbps, 81.5 Kgates 0.14-mm CMOS ASIC: 84.6 Mbps, 26.7 Kgates ALTERA Max + plus II: 51.0 Mbps, 11 Kcells (Flex 10K Family) ALTERA Max + plus II: 4.1 Mbps, 6.3 Kcells (Flex 10K Family)

Reference [1] Muratani, Okuma, Sano, Motoyama, and Kawamura, Proposal on 64-bit Hierocrypt, Information Processing Society Research Report CSEC11-9, Sept. 2000. [2] Muratani, Okuma, Sano, Motoyama, and Kawamura, Specification and Assessment of the block cipher Hierocrypt, Electronic Information Communication Society, Research Report IT99-102, ISEC99-141, SST99-150, 2000. [3] K. Ohkuma, H. Muratani, F. Sano, and S. Kawamura, The block cipher Hierocrypt, SAC2000, 2000. [4] Hideo Shimizu, Fumihiko Sano, Masahiko Motoyama, Kenji Ohkuma, and Shinichi Kawamura, “Implementation of SPN-Type block cipher,” Technical Research Report of the Institute of Electronics, Information and Communication Engineers, ISEC2001-55, 2001. [5] S. Furuya and V. Rijmen, “Observations on Hierocrypt-3/L1 Key-scheduling Algorithms,” Proceedings of the second open NESSIE Workshop, 2001. [6] C. MJ. Kim and K. Kim, “Impossible Differential Cryptanalysis of Hierocrypt-3 Reduced to 3 Rounds,” Proceedings of the second open NESSIE Workshop, 2001. [7] F. Sano, K. Ohkuma, H. Shimizu, M. Motoyama, S. Kawamura, “Efficient Implementation of Hierocrypt,” Proceedings of the second open NESSIE Workshop, 2001.

184 CRYPTREC 2001

[8] Soichi Furuya and Koichi Sakurai, "Algebraic approximation of SPN-structure block cipher", The forth computer security symposium (CSS2001), Lecture drafts, CSS2001, 6B-1, 2001. [9] Kenji Ohkuma, Fumihiko Sano, Hideo Shimizu, and Shinichi Kawamura, "Supplementary consideration on provable security of recursive SPN structure, Ciphers and security symposium 2002, SCIS2002 Lecture draft, SCIS2002 5B-2, 2002. [10] L. Keliher, H. Meijer, and S. Tavares, “Improving the Upper Bound on the Maximum Average Linear Hull Probability for Rijndael,” Selected Areas in Cryptography, 8th Annual International Workshop, SAC 2001 Toronto, LNCS 2259, Springer-Verlag, 2001. [11] P. S.L.M. Barreto, V. Rijmen, J. Nakahara Jr., B. Preneel, J. Vandewalle, and H. Y. Kim, “Improved SQUARE Attacks Against Reduced-Round HIEROCRYPT,” Preproceedings of FSE2001, 8th Fast Software Encryption Workshop, Yokohama, 2001. [12] L. Keliher, H. Meijer, S. Tavares, “Dual of New Method for Upper Bounding the Maximum Average Linear Hull Probability for SPNs,” IACR's ePrint archive, 2001/033, available at http://eprint.iacr.org/. [13] K. Ohkuma, H. Shimizu, F. Sano, S. Kawamura, “Security Assessment of Hierocrypt and Rijndael against the Differential and Linear Cryptanalysis (Extended Abstract),” IACR's ePrint archive, 2001/070, available at http://eprint.iacr.org/. [14] B. Van Rompay, V. Rijmen, J. Nakahara Jr., “A first report on CS-Cipher, Hierocrypt, , SAFER++, and SHACAL,” Public reports of NESSIE project, NES/DOC/KUL/WP3/006/1, available at http://www.cosic.esat.kuleuven.ac.be/nessie/reports/. [15] Yan Braziler, “The statistical evaluation of the NESSIE submission Hierocrypt-3,” Public reports of NESSIE project, NES/DOC/TEC/WP3/021/1, available at http://www.cosic.esat. kuleuven.ac.be/nessie/reports/. [16] Yan Braziler, “The statistical evaluation of the NESSIE submission Hierocrypt-L1,” Public reports of NESSIE project, NES/DOC/TEC/WP3/022/1, available at http://www.cosic.esat. kuleuven.ac.be/nessie/reports/. [17] B. Preneel, B. Van Rompay, L. Granboulan, G. Martinet, S. Murphy, R. Shipsey, J. White, M. Dichtl, P. Serf, M. Schafheutle, E. Biham, O. Dunkelman, M. Ciet, J-J. Quisquater, F. Sica, L. Knudsen, H. Raddum, “NESSIE Phase I: Selection of Primitives,” NESSIE deliverables, available at http://www.cosic.esat.kuleuven.ac.be/nessie/deliverables/.

185 CRYPTREC 2001

3.4.6 RC6

3.4.6.1 Technical overview

RC6 is a block cipher with variable block length (128 bits for recommendation), which was invented by R. Rivest et al. in 1998 and has been submitted by RSA security Inc. RC6 inherits the design philosophy of its predecessor, RC5, and aims to achieve fast and efficient implementation, as well as a wide range of evaluation, using a simple structure. Specifically, RC6 has data-dependent rotation and integer addition on round keys to provide security. It also aims to improve security and achieve efficient encryption by increasing the amount of shuffling for data in each round using multiplication operations inside round functions.

3.4.6.2 Technical specifications

RC6 has wide range of parameters and is precisely expressed as “RC6-w/r/b.” The letters w, r, and b indicate word-bit length, number of rounds, and key-byte length, respectively. RC6 has modified Feistel structure in which plaintext blocks are divided into four partitions, and has a plaintext block length that is four times the word -bit length w. In this submission, word-bit length w = 32 bits, key length b = 16, 24, and 32 bytes, and number of round r = 20 are proposed as recommended values. No table is used, and compact software implementation is possible. The main part of RC6 can be implemented using a 176-byte key schedule part and a very small amount of add-on memory. When the word length is 32 bits, all of the operations used in the cryptographic algorithm, i.e., arithmetic addition/subtraction, EXOR, arithmetic multiplication, and left/right circularly shift, are performed in 32-bit word units. That is, the algorithm is designed to efficiently use the operation of a 32-bit CPU. The processing speed of these operations leads to fast implementation.

3.4.6.3 Result of security evaluation

RC6 was evaluated as one of the AES candidate ciphers, and was selected as one of the five finalists to proceed the further detail evaluation. In addition, the CRYPTREC evaluation has not been found any problems in the RC6 (recommendation version). Therefore RC6 can be considered as one of sufficiently usable ciphers for e-Government, in which there should not be any attack method in which the number of plaintexts needed for the attack is less then the total number of plaintexts, and the number of computations necessary for the attack is less than exhaustive key search. Resistance of RC6 against various attack methods is summarized as follows.

Through not based on an argument of provable security, RC6’s resistance to differential and linear cryptanalysis has been evaluated for characteristic probabilities based on appropriate consideration in the self-evaluation document. In an algorithm such as RC6, which uses data-dependent rotation, the differential

186 CRYPTREC 2001

path and linear approximation path vary according to the number of shifts, and therefore it is necessary to consider the sum of characteristic probabilities for each of these paths. This point has been sufficiently considered. As a result, the number of plaintexts necessary for breaking is less than the total number of plaintexts with up to 12 rounds for differential cryptanalysis and with up to 16 rounds for linear cryptanalysis, which means that the required strength is not achieved. However, the needed number for an 18-round variant is more than the total number of plaintexts [2]. In an attack that uses plural linear approximation expressions, the keys of 18-round RC6 can be guessed by 2126.9 plaintexts and 2192.9 computations if the keys are weak keys that exist at the rate of 2 –90.

Among higher order differential attack and other attacks, chi-square attack is the most effective attacking method against RC6. According to this attack, which uses chi-square statistics, keys of 15-round variant can be guessed using 2119 chosen plaintexts, 2215 computations, and 2138 memory [3]. Therefore, the RC6 variant with up to 15 rounds has not reached the required strength. However, the attack cannot be considered realistic because the numbers, such as the number of plaintexts, are in the realm that will not materialize at least for another ten years, even if communication speed and computation capability improve by tenfold every year. Nonetheless, it is necessary to pay attention to advances on statistical strength evaluation, including the evaluation of RC6 weak keys.

Because RC6 uses multiplication and data-dependent rotation, it is usually necessary to take side channel attacks, such as timing attacks and differential power analysis, into consideration. While the self-evaluation document claims that the countermeasures can be easily implemented for RC6, contradicting opinions also exist. Research on defensive measures against these attack methods is still ongoing, and therefore, when implementing RC6, it will be necessary to consider countermeasures for an entire system based on the results of this research.

It has been reported that the required strength is reached in nine rounds against higher order differential attack and in six rounds in avalanche evaluation. Therefore, RC6 can be considered to provide sufficient strength against the attacks so far.

As described above, RC6 has not achieved the required strength with up to 16 rounds against the strongest attack currently known. However, because RC6’s specified number of rounds is 20 (though some say this is too small), there should not be any security problems at present.

3.4.6.4 Software Implementation Evaluation

Software implementation was evaluated in the following environments. The evaluation results are listed in Tables 3.61 and 3.62.

187 CRYPTREC 2001

Table 3.61 Data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language Assembler Program size 1200bytes (including encryption/decryption/key scheduling) Compiler option /O2 (Microsoft C Compiler) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 258 / 260 262 / 266 Second round 258 / 260 262 / 265 Third round 258 / 259 262 / 265

UltraSPARC IIi (400MHz) Language ANSI C Program size 3940 byte (including encryption/decryption/key scheduling) Compiler option xo5 (WS Compiler C/SPARC Optimize 5) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 2048 / 2088 2024 / 2076 Second round 2047 / 2088 2023 / 2074 Third round 2048 / 2089 2026 / 2077

Table 3.62 Key schedule part + data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language Assembler Program size 1200 bytes (for encryption and decryption each), 1500 bytes (key scheduling) Compiler option /o2 (Microsoft C Compiler) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 1631 / 1644 1633 / 1639 Second round 1630 / 1645 1633 / 1643 Third round 1630 / 1642 1633 / 1640

UltraSPARC IIi (400MHz) Language ANSI C Program size 3940 bytes (for encryption and decryption each), 2196 bytes (key scheduling) Compiler option xo5 (WS Compiler C/SPARC, Optimize 5) Encryption (Fastest/Average) Decryption (Fastest/Average) First round 4078 / 4111 4026 / 4054 Second round 4078 / 4111 4024 / 4055 Third round 4075 / 4112 4019 / 4054 Note: According to the specification of software implementation evaluation, the codes measured on Pentium III and on UltraSPARC IIi were derived by modifying commercial products for Microsoft Windows 9X and for SUN Solaris, respectively. The products (BSAFE-Crypto-C5.1) are currently available.

188 CRYPTREC 2001

RC6’s data-processing speed for encryption and decryption on Pentium III is the fastest among the block ciphers submitted for evaluation. However, in terms of speed that includes expanded key generation, RC6 is almost the slowest cipher, even when measured on Pentium III. In terms of the speeds on UltraSPARC IIi, i.e., encryption, decryption, and encryption with expanded key generation, RC6 is almost the slowest. All of the codes offered by the applicant were commercial-version programs and were not optimized for our speed measurement. The former is coded in an assembly language and the latter in the C language. n Evaluation of software implementation evaluation in smart cards , etc.: The self-evaluation document describes the following characteristics related to implementation in Java, smart cards, and DSP, including those implemented by a third party:

Java: Simp licity of cryptographic processing is reflected in code size, performance, and the amount of dynamic RAM in Java. The various investigations performed in the AES evaluation process indicate that RC6 has achieved remarkable performance in the Java environment.

Smart card: In smart cards using the ARM chip and other high-end processors, RC6 has demonstrated excellent cryptographic performance.

DSP: Because RC6 does not need a look-up table that uses extra memory, it can attain sufficient performance in this type of processors.

3.4.6.5 Hardware Implementation Evaluation

The Hardware implementation evaluation results are listed in Table 3.63. These results are based on the assumption that the entire algorithm is optimized with throughput priority using a 0.35-mm CMOS ASIC library.

Table 3.63 Hardware evaluation results

Data randomization part 77,785 Key schedule part 975,391 Circuit size (gates) Control circuit — Entire Primitive 1,753,076 Critical path (ns) 698.05 Key Setup Time (ns) 2,112.26 [1] Throughput (Mbps) 183.36

According to this evaluation result, the circuit size of the data randomization part of RC6 is the smallest among the group that uses the loop architecture. The simplicity of the algorithm is presumed to have contributed to this outcome. The applicant’s evaluation has reported an example of even smaller implementation circuit size.

189 CRYPTREC 2001

Table 3.64 FPGA [5]

Encryption XCV 1000 127 (Mbps) Feedback mode Encryption XCV 1000 2.4 (Gbps) Non-feedback mode

Table 3.65 ASIC[4]

Encryption 0.5 mm 104 (Mbps) Repetitive method Encryption 0.5 mm 2.2 (Gbps) Pipeline method

Reference [1] R.L. Rivest, M.J.B. Robshaw, R. Sidney, and Y.L. Yin, The RC6 Block Cipher. Algorithm specification, August 20, 1998. Available at http://www.rsasecurity.com/rsalabs/ / [2] S. Contini, R.L. Rivest, M.J.B. Robshaw, and Y.L. Yin,The security of the RC6 Block Cipher, ugust 20, 1998. Available at http://www.rsasecurity.com/rsalabs/rc6/ [3] L.R. Knuddsen and W. Meier, Correlations in RC6 with a reduced number of rounds. FSE2000, LNCS 1978, pp.94-108, 2001 [4] T. Shimoyama, M. Takenaka, and T. Koshiba, Multiple Linear Cryptanalysys of a reduced round RC6, SCIS2002, Proceedings of the 2002 Symposium on ryptography and Information Security, pp.931-936, 2002 (also presented at FSE2002) [5] A. Elbirt, W. Yip, B. Chetwynd, and C. Parr, An FPGA implementation and performance evaluation of the AES block cipher candidate algorithm finalists, Proceedings of 3rd AES conference, pp.13-27, (2000) [6] B. , M. Bean, T. Rozylowicz, and C. Ficke, Hardware performance simulations of Round 2 AES algorithms, Proceedings of 3rd AES conference, pp.286-304, (2000)

3.4.7 SC2000

3.4.7.1 Technical overview • This cipher was developed by researchers at Fujitsu and Science University of Tokyo. It was announced at an academic society in 2000, and has been proposed by Fujitsu. SC2000 is a symmetric block cipher with the same interface as AES, a 128-bit data input/output and a 128/192/256-bit key length. • The structure of the entire cipher is a new one that involves the superposition of a Feistel structure and an SPN structure. Using only those components that have been fully verified and are well known to be secure for various cipher components, such as S-boxes, this structure enables the security of the entire cipher to be easily verified.

190 CRYPTREC 2001

• To achieve fast implementation, a structure to which the latest fast implementation method, called a bitslice method, can be applied is used as the SPN structure. SC2000 is also designed to enable fast implementation of non-linear operations depending on the size of the CPU’s primary cache. • For hardware implementation, SC2000 aims to achieve compactness by using only non-linear operation devices with 6-bit or smaller inputs/outputs and logical operations. • Potential applications include next -generation high-speed encrypted between networks, fast encryption of large-capacity , smart card authentication, and transmission/receipt of cipher data.

3.4.7.2 Technical specifications n Data randomization part: This component encrypts 32 bits x 4 input plaintext data using an expanded key table created by the key schedule part, and outputs 32 bits x 4 data as ciphertext. The data randomization part has the I-function, B-function, and R-function, which use 32 bits x 4 input/output, as internal functions. Of these, the I-function is a function for XORing keys, and the B- and R-functions are functions for shuffling data. When the key length is 128 bits, the I-, B-, and R-functions have 14, seven, and 12 rounds, respectively, with the total number of rounds for the data-shuffling functions being 19. When the key length is 192 or 256 bits, the I-, B-, and R-functions have 16, eight, and 14 rounds, respectively, with the total number of rounds for the data-shuffling functions being 22. The individual functions can be connected in one of two ways, through straight (-) connection in which the output of the function in the previous round is input as is into to the next round, or through cross (x) connection in which the output of the function in the previous round is partitioned into two 64-bit data and these two data are swapped before being input into to the next round. This process is repeated by connecting the individual functions as I-B-I-RxR. The number of 32-bit expanded keys to be used is 56 when the key length is 128 bits and 64 when the key length is 192 or 256 bits. n Decryption: This function decrypts 32 bits x 4 input ciphertext data using the expanded key table that is input, and outputs 32 bits x 4 data as decrypted text. The decryption function has the I-function, B-1-function, and R-function, which use 32 bits x 4 input/output, as its internal functions. Of these, the I- and R-functions are the same as in the data randomization pats, while the B-1-function is an inverse function of the B-function. This process is repeated by connecting the individual functions as I-B-1-I-RxR. n Key schedule part: The key schedule part generates 56 32-bit expanded keys (when the key length is 128 bits) or 64 32-bit expanded keys (when the key length is 192 or 256 bits) from user keys. The key schedule part consists of an intermediate key generation function and an expanded key generation function. First, intermediate keys are generated by expanding 32 bits x 4 user keys into 32 bits x 8 using the intermediate key generation function, and then the predetermined number of 32-bit expanded keys is generated using the

191 CRYPTREC 2001

expanded key generation function.

3.4.7.3 Result of security evaluation

We performed the three types of analysis described as follows and found no clear weak points in the suggested configuration.

(1) Resistance of the data randomization part to conventional attacks

A design method is known for evaluating the theoretical upper bounds of differential characteristic probability and linear characteristic deviation to guarantee resistance against differential and linear cryptanalysis [1]. In SC2000, the approximation expressions that have the significant differential characteristic probability and linear characteristics deviation used in the security evaluation of DES, etc., are searched, and the resistance against these attack methods is demonstrated by showing that there are no approximation expressions that have significant probability or deviation [2]. To efficiently derive approximation expressions, a method is used that replaces the search target with the differential propagation pattern of truncated vector [2].

It has been found that, against differential cryptanalysis, the 15-round differential characteristic probability is 2-134 or lower when three-round repetition is used, and 2-150 or lower when two-round repetition is used. In other words, there are no differential characteristic approximation expressions that can be used for differential cryptanalysis. Although whether or not repetition of four or more rounds exists is an open problem, the execution is difficult because the search will require a massive number of computations. Judging from the result of three-round repetition, it seems difficult to apply differential cryptanalysis with a realistic number of computations, even if four-round repetition exists.

Applying the same techniques using a truncated vector is also possible for linear cryptanalysis. It has been found that the 15-round linear characteristic approximation probability is 2-142 or lower when three-round repetition is used, and 2-150 or lower when two -round repetition is used. In other words, there are no linear characteristic approximation expressions that can be used for linear cryptanalysis.

Higher order differential attack is effective against a cipher composed of functions with a small algebraic degree. Because SC2000 uses B- and R-functions with at least the second-order coefficients in 19 rounds for 128-bits keys, it seems that higher order differential attack cannot be applied to SC2000. The maximum number of rounds that can be attacked with higher order differential attack and interpolation attack is eight, using 264 or more plaintext -ciphertext pairs and 2256 or fewer computations. Because the specified number or rounds for SC2000 is 22, it has been confirmed that SC2000 has no problems with higher order differential attack and interpolation attack.

192 CRYPTREC 2001

Because SC2000’s security margin against ordinary differential cryptanalysis is not so large, resistance to truncated differential cryptanalysis must be evaluated in further d etail.

To determine the applicability of chi-square attack and partitioning attacks, we looked for structures that would cause statistical correlation between plaintext and ciphertext partial information, but found none. Further, investigation should be performed in the future using computers.

We examined SC2000’s resistance to impossible differential cryptanalysis, boomerang attack, mod n attack, and non-surjective attack, but found threatening shortcomings.

(2) Security of the key schedule part against conventional attacks

An exhaustive key search is the least effective but reliable cryptanalysis that can be applied to any symmetric cipher. At the existing technical level, an exhaustive key search of 128 bits or more is considered unrealistic. As for weak keys, the self-evaluation document discusses whether or not intermediate key collision exists and the possibility of all intermediate keys matching. The conclusion of the document is reasonable. During the computation of expanded keys in SC2000, the expanded keys were being effectively generated from keys without any overlap. A statistical examination of chi-square characteristics did not reveal any problematic test value.

As explained above, no problematic shortcomings were found in the key schedule part.

(3) Resistance to side channel attacks

A timing attack can be applied to hardware implementation. However, because SC2000 is implemented using small table look up or logic circuits, it is difficult to imagine the existence of process-time differences that are dependent on key data values. Therefore, countermeasures are either unnecessary or can be implemented extremely easily. For the same reason, it is considered unnecessary or easy to take measures against timing attacks on software implementation and smart card implementation. Because SC2000 can be implemented without a branching process, it is highly resistant to timing analysis and simple power analysis. For each configuration element, we examined the applicability of simple power analysis and differential power analysis that compare power-consumption waveforms among multiple data, that are more advanced than ordinary simple power analysis and differential power analysis. We confirmed that countermeasures against these analysis methods can be performed at low cost. As explained above, no security-related faults have so far been found in SC2000. However, very little evaluation of a structure that alternately superposes a two -round Feistel structure and an SPN structure has been done. Note that, in the presentation [3] made at the SCIS2001 in January 2001, the applicant reported that

193 CRYPTREC 2001

three-round differential and linear repetition search had found a differential characteristic that could be established at a probability of 2-33 and a linear characteristic that could be established at a probability 2-34. As a result, 13 out of the total of 19 rounds could be attacked. Further analysis is needed in the future. After January 2001, reports [4, 5, 6, 7] were published.

3.4.7.4 Software Implementa tion Evaluation

An software implementation evaluation was performed in the environment specified below. The evaluation results are as shown in Tables 3.66 and 3.67.

Table 3.66 Data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language ANSI C + assembler Program size 21340 bytes (including encryption/decryption /key scheduling) Compiler option /G6 /O2 /ML /W3 /GX Encryption (Fastest/Average) Decryption (Fastest/Average) First round 389 / 391 408 / 410 Second round 388 / 392 408 / 411 Third round 388 / 391 408 / 411

UltraSPARC IIi (400MHz) Language ANSI C Program size 25548 bytes (including encryption/decryption/key scheduling) Compiler option -xtarget=ultra2 -x05 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 310 (275) / 313 (277) 309 (283) / 312 (286) Second round 310 (276) / 313 (278) 309 (283) / 312 (287) Third round 310 (276) / 314 (279) 309 (282) / 312 (285)

Alpha 21264 (463MHz) Language ANSI C Program size 39845 bytes (including encryption/decryption/key scheduling) Compiler option -fast -arch ev6 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 289 (262) / 297 (276) 282 (275) / 296 (289) Second round 289 (262) / 297 (277) 282 (275) / 288 (289) Third round 289 (262) / 296 (276) 282 (275) / 288 (289)

194 CRYPTREC 2001

Table 3.67 Key schedule part + data randomization part speed measurement results (unit: cycles/block)

Pentium III (650MHz) Language ANSI C + assembler Program size 23700 bytes (including encryption/decryption/key scheduling) Compiler option /G6 /O2 /ML/W3/GX Encryption (Fastest/Average) Decryption (Fastest/Average) First round 800 / 803 818 / 822 Second round 800 / 803 818 / 821 Third round 800 / 803 818 / 819

UltraSPARC IIi (400MHz) Language ANSI C Program size 22524 bytes (including encryption/decryption/key scheduling) Compiler option -xtarget=ultra2 -x05 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 623 / 627 618 / 622 Second round 623 / 627 618 / 622 Third round 623 / 627 618 / 622

Alpha 21264 (463MHz) Language ANSI C Program size 39854 bytes (including encryption/decryption/key scheduling) Compiler option -fast -arch ev6 Encryption (Fastest/Average) Decryption (Fastest/Average) First round 572 / 578 586 / 594 Second round 572 / 578 586 / 595 Third round 572 / 578 586 / 594

Note: In the measurements using UltraSPARC IIi and Alpha 21264, the inside the parentheses were obtained after the applicant modified the measurement program. Although a massive buffer area was allocated to the measurement program to maintain general-purpose characteristics, the applicant modified the program to allocate just enough buffer area. It has been verified that no modifications were made that would affect the speed-evaluation results.

The decryption time is several percentage points longer than the encryption time in Pentium III and Alpha 21264, and is several percentage points shorter in UltraSPARC IIi. However, these differences were not significant enough to cause any problems.

The designers have reported results of implementation in Pentium III and Athlon processor. Both the data randomization part and the key schedule part were optimized to a significant degree.

195 CRYPTREC 2001

n Smart card implementation: The designers have reported results of implementation in an smart card containing an Intel 8051 processor. Codes that can perform both encryption and decryption can be implemented in 1751-byte ROM device. There is some room for encryption speed improvement.

3.4.7.5 Hardware Implementation Evaluation

We did no evaluate any hardware implementation.

Reference [1] Document related to the selection/design/evaluation of a symmetric block cipher, Communication/Broadcasting Mechanism, 2000. [2] T. Shimoyama, H. Yanami, K. Yokoyama, M. Takenaka, K. Itoh, J. Yajima, N. Torii and H. Tanaka, Symmetric Key Block Cipher SC2000, Tech. Rep. of IEICE, ISEC2000-72, 2000. [3] H. Yanami and T. Shimoyama, Differential/linear search of symmetric block cipher SC2000, Proceedings of the SCIS 2001, 2001. [4] T. Shimoyama, H. Yanami, K. Yokoyama, M. Takenaka, K. Itoh, J. Yajima, N. Torii, and H. Tanaka, Block Cipher SC2000, Proceedings of FSE 2001, pp.326-340, 2001. [5] H. Yanami and T. Shimoyama, Differential/Linear Characteristics of the SC2000 Block Cipher (II), Tech. Rep. of IEICE, ISEC2001-10, 2001. [6] J.Yajima, M. Takenaka, T. Koshiba, and N. Torii, Pseudorandomness of SC2000, Tech. Rep. of IEICE, ISEC2001-11, 2001. [7] H. Raddum and L. R. Knudsen, A Differetial Attack on Reduced-Round SC2000, Proceedings of SAC2001, pp.207-215, 2001.

3.5 Evaluation of Ciphers Selected for Screening Evaluation

3.5.1 MUGI

3.5.1.1 Technical overview

MUGI is a pseudorandom number generator for stream ciphers, and has 128-bit secret keys and 128-bit (published) initial vectors as parameters.

The applicant affirms that MUGI is designed with reference to PANAMA proposed by Daemen and Clapp in 1998. PANAMA is not a linear feedback , which is one of pseudorandom number generator designs, but is designed on the same principle of block ciphers. Block cipher design and evaluation techniques are considered, and therefore easily applicable to PANAMA. Simple basic ideas and the easiness of designing variations having a similar structure feature the cipher PANAMA. On the other hand,

196 CRYPTREC 2001

PANAMA is a unique design incomparable to conventional designs, and the analysis of its security is therefore difficult.

For these reasons, the designer affirms that MUGI si designed to have a structure similar to that of PANAMA and to have capabilities permitting easier application of conventional bock cipher analytical techniques and evaluation.

The reusability of existing evaluated cipher techniques is claimed to be a constituent of the design philosophy. Specifically, MUGI uses AES components (such as substitution table S-boxes) that have been fully evaluated.

3.5.1.2 Screening Evaluation Results n Conclusion: No problem on security has so far been found. Although MUGI is an improvement of PANAMA that was announced in 1998, not many years have passed yet since it was announced. Further security and implementation evaluations are considered necessary. n Points of Screening Evaluation: The following two points were presented as problems in the evaluation:

1. Test vector disagreement, and 2. Characteristics compared to the ciphers evaluated in detail in 2000 not sufficiently presented in the self-evaluation report

Thereby, the problems to be further studied were identified as follows:

(1) What is the cause or causes of the test vector disagreement - technical? or editorial? (2) Characteristics relative to the stream ciphers (MULTI-S01 and TOYOCRYPT-HS1) evaluated in detail in 2000, including its comparison with superiority to and differentiation from MULTI-S01 because MUGI uses the random number generation algorithm PANAMA inside, need to be further studied. n Summary of Screening Evaluation: At a cryptographic workshop, there were comments of the applicant on the above-identified two problems (1) and (2). For (1) in particular, he answered that the cause was an editorial misdescription.

At the SCIS2002 workshop, the designers announced additional self-evaluation [1]. The self-evaluation discussed the reapplication to MUGI of synchronized attacks using differential cryptanalysis and linear cryptanalysis, and evaluated mainly the differential and linear characteristics of ? function. The designers themselves suggested the necessity of further evaluation for the purpose of rigidly evaluating the resistance of MUGI to linear cryptanalysis, but no conclusion denoting the existence of security problems were reached in the self-evaluation.

197 CRYPTREC 2001

As we look into the security evaluation by the designers, we learn that MUGI is designed to permit easier application of existing block cipher evaluation methods than PANAMA. This easier applicability is considered to be an important superiority of MUGI in the cipher design evaluation, which constitutes an answer to the problem (2).

A recent paper proposes an analysis method for a certain sort of stream ciphers including MUGI [2]. Although this paper suggests the possibility of attacks to MUGI, it does not contain detailed discussions or actual analysis. n Conclusion of Screening Evaluation: Thus, no security problems of MUGI are found so far. For MUGI, however, further security evaluation against attacks including those mentioned above, as well as implementation evaluation, is considered necessary.

References [1] Watanabe et al., “Security Evaluation of Key Stream Generator MUGI (1)”, Proc. SCIS2002 [2] , , and Charanjit Jutla, “Cryptanalysis of Stream Ciphers with Linear Masking”, ePrint@IACR February 16, 2002, available at http://eprint.iacr.org/

3.5.1 A Comments of Evaluators (Unmodified Excerpts) n Report A: I deem it necessary to evaluate security by further detailed evaluation.

1. Concerning the characteristics of ciphers to be evaluated in detail for the year 2000, “MULTI-S01” from the same proposer (company) is a stream cipher utilizing the same PANAMA as used by this cipher being commented. Comparison (differentiation) between the two is therefore necessary. Comparison of its performance (speed) with that of block ciphers is also necessary because it uses functions corresponding to round functions of block ciphers. Furnished information describes approximate equivalency to AES but no numeric comparison is provided. 2. Although conceivable applications are not clearly shown, (MUGI) may be serviceable to almost all applications requiring secrecy. n Report B: The specifications are described on an implementable level. The design philosophy is also clearly described. The security evaluation is made from various viewpoints covering from general attacks to structurally peculiar attacks. Statistic evaluation performed by customizing FIPS140-1 is also provided. As for implementation evaluation, both the software and the hardware are reasonably examined, and the processing speed, the amount of resources, and the hardware size are considered reasonable. Some omissions and errors probably due to mistyping are seen in the specifications. As a result of our own execution of the reference code in our computer environment, the output of one of the test vectors disagreed

198 CRYPTREC 2001

with that given in the specifications. With respect to the characteristics of the cipher against those evaluated in detail in 2000, nothing is clearly stated in the proposer’s application documents. While MULTI-S01, a cipher evaluated in detail in 2000, also has the structure of PANAMA, it appears to be a characteristic of the technique being commented that it uses in it the functions of AES. n Report C: The system being commented is proposed as a cryptographic system capable of being implemented at fast speed and in light weight on both software and hardware platforms. In spite of its being a stream cipher, it is designed to ensure compatibility of both long-period and high-speed characteristics by the processing of blocks in 64-bit length. If the processing is simply performed in blocks, its long-period characteristics may be questionable, but there seems to be no problem in this respect because it is equipped with a data shuffling part. Sufficient care, however, must be taken in its design. n Report D: The attempted improvement of PANAMA is appreciable, but detailed evaluation is necessary in the discussions of security. For SW and HW implementation, comparison data with PANAMA are destitute, and this should also be discussed in detailed evaluation.

*1 Number of computations of round function

199 CRYPTREC 2001

4 Hash Function Evaluation

4.1 Evaluation Method

4.1.1 How to Evaluate Harsh Functions

Hash functions compress a message of an arbitrary bit length m into a digest of a constant length n. For hash functions, two capabilities “onewayness” and “” are requisite. Onewayness means the characteristic, in which an input cannot be easily calculated from its corresponding output. “Collision” indicates that the same hash values are output from two different inputs. It is impossible that hash functions completely realize collision resistance because they allow larger inputs than the corresponding outputs. By that reason, it is considered that they have the collision resistance if no collision is found within feasible computational complexity. Since no hash function was submitted at this time, the security of well-used hash functions was evaluated by the survey of publications and others.

4.2 General Evaluation

4.2.1 Hash Function Evaluation

4.2.1.1 Detailed evaluation n Evaluated hash functions: In the year 2001, CRYPTREC determined that it was necessary to evaluate the following hash functions in detail and evaluated them.

• draft SHA -256, draft SHA-384, and draft SHA-512 n Details of the evaluation: “Onewayness” and “collision resistance”, which were the requirements to be satisfied by cryptographic hash functions, were discussed. In addition, specific evaluation of the above-mentioned hash functions by new types of attacks, comparison of security to SHA-1 and MD-type hash functions, and the survey of publications of the cryptanalysis result were conducted. n Result: The evaluation work was consigned to three other domestic and overseas researchers than the Committee. From the reports, it is confirmed that no problem of security had been found so far.

4.2.1.2 Continuing evaluation

The RIPEMD-160 and SHA-1 hash functions were continuously evaluated.

200 CRYPTREC 2001

Table 4.1 Characteristics of hash functions

RIPEMD-160 SHA-1 Characteristics Message-digest length 160 bits 160 bits Bit length for each basic process unit 512 bits 512 bits Total processing steps 160 80 Maximum allowable length of input message 264 - 1 bits 264 - 1 bits

n Security: Since no attacking method, which may jeopardize the practical security of RIPEMD-160 and SHA-1, has been reported, these hash functions can be considered to be secure enough to be used in cryptographic applications. Needless to say, the security against exhaustive key search should be ensured. For example, the length of hash value is n bits. In this case, since a may find a collision among the hash values for 2n/2 messages, it needs to make the length of hash value considerably longer. The results from recent research have suggested that n = 160 bits or more are required.

4.3 Detailed Evaluation of Cryptographic techniques (Individual techniques)

4.3.1 draft SHA-256/384/512

4.3.1.1 Technical overview of dra ft SHA-256/384/512

In FIPS-180, NIST proposed 160-bit hash functions SHA in 1992 and its revision SHA-1 in 1994 [1]. In addition to these two types of hash functions, NIST proposed three types of hash functions: 1) 256-bit hash functions SHA-256; 2) 384-bit hash functions SHA -384, and 3) 512-bit hash functions SHA -512, all of which are based on the similar design rationale to SHA-1 but output longer hash value.

Three types of hash functions, SHA-256, SHA-384, and SHA-512, were introduced mainly because the security levels against collision attacks are 128, 192, and 256 bits, requiring to make them correspond to recently standardized three types of block ciphers, AES-128, AES-192, and AES-256.

4.3.1.2 SHA-256 technical specifications

They were designed in the same way as in MD4, MD5, and SHA -1.

(i) Calculate a 512-bit padded message block from a bit string x as follows: (4.1) Where, x is a modulo 232 integer, l = |x|mod 264, and l + 1 + k º 448 mod 512.

201 CRYPTREC 2001

(ii) Divide M into N º 0 mod 16 512-bit message blocks . Where, M(i) consists of 16 32-bit words as follows:

(4.2)

(iii) Initialize buffer variables using initial hash values as follows:

(4.3)

where, the initial hash values (1 £ j £ 8) are as shown below.

(4.4)

(iv) Repeat the following arithmetic operations with a condition 0 £ t £ 63:

(4.5)

Note that + means a modulo 232 addition for each 32-bit word. are the functions defined in the following formulae with 32-bit words for input and output variables.

(4.6)

Sn(x) means rightward cyclic shifting of the 32-bit word x by n-bit. , (0 £ t £ 63) is a

constant (refer to FIPS-180) and an extended message block W t (0 £ t £ 63) can be found using a SHA-256 message schedule function as follows:

(4.7)

where, and are the functions defined in the following formulae with 32-bit words for input and output variables,

202 CRYPTREC 2001

and Rn(x) means rightward shifting of 32-bit word x by n bits. (v) Calculate intermediate hash values as follows:

(4.8)

Assuming that a 256-bit intermediate hash value with eight 32-bit hash values padded is expressed by the formula,

(4.9)

and above steps (iii) - (iv) are expressed by a SHA -256 compression function , the above procedures can be integrated into a recurring formula together as follows:

(4.10)

where, H(N) is the hash value for the message block M.

4.3.1.3 SHA-512 technical specifications

SHA-512 hash functions are SHA -256 hash functions with their word length changed from 32 to 64.

(i) Calculate a 1024-bit padded message block from a bit string x as follows:

(4.11)

w, x is a modulo 264 integer, l = |x|mod 2128, and l + 1 + k º 896 mod 1024. (ii) Divide M into N º 0 mode 16 1024-bit message blocks . where, M(i) consists of 16 64-bit words. (iii) Initialize buffer variables using initial hash values as follows:

(4.12)

where, the initial hash values (1 £ j £ 8) are as shown below.

203 CRYPTREC 2001

(4.13)

(iv) Repeat the following arithmetic operations with a condition 0 £ t £ 79:

(4.14)

Note that + means a modulo 264 addition for each 64-bit word. and are the functions defined in the following formulae with 64-bit word for input and output variables.

(4.15)

Sn(x) means rightward cyclic shifting of the 64-bit word x by n bits. , (0 £ t £ 63) is a

constant (refer to FIPS-180-2) and an extended message block Wt (0 £ t £ 79) can be found using a SHA-512 message schedule function as follows:

(4.16)

where, and are the functions defined in the following formulae with 64-bit words for input and output variables,

and Rn(x) means rightward shifting of 64-bit word x by n bits. (v) Calculate intermediate hash values as follows:

(4.17)

Assuming that a 512-bit intermediate hash value with eight 64-bit hash values padded is expressed by the formula,

204 CRYPTREC 2001

(4.18)

and above steps (iii) - (iv) are expressed by a SHA -512 compression function , the above procedures can be integrated into a recurring formula together as follows:

(4.19)

where, H(N) is the hash value for the message block M.

4.3.1.4 SHA-384 technical specifications

The technical specifications for SHA -384 are almost the same as those for SHA-512 with following two exceptions.

1. The hash values H(0) are changed from those for SHA-256 and SHA-512 as follows:

(4.20)

2. The 384-bit hash value is adopted as the final hash value H(N) which is truncated from the left side of 512-bit hash value of SHA-512.

(4.21)

4.3.1.5 Security evaluation 1. SHA-256 (a) Evaluator 1 Overview of the result: The security of SHA -256 was evaluated as follows: i. It is difficult to apply Dobbertin [2,3,4] and Chabaud-Joux [5] attacks against MD type of hash functions to SHA -256. ii. Compared with SHA-1, SHA-256 appears to have less number of iterative rounds and moreover, it is hard to re-structure the selection criteria of design and the variables only using the specification with few of formal documentation obtained. Nevertheless, the greatest advantage of basic component portion of SHA -256 is that it provides considerably higher strength than those of the existing hash functions. iii. The result from the survey about the differential characteristics of the included compression functions showed that neither possible repetitive characteristics nor the characteristics common to the compression function at each round were identified.

205 CRYPTREC 2001

iv. The modified SHA -256 variant (for more information, refer to (vi)), in which the constants for numbers of iterative rounds take symmetry values when divided by 2, is insecure. Thus, any of known attacks cannot be applied to SHA-256 and moreover, attacks, which may contribute to 2256 or lower complexity of preimage and second preimage calculations, and usual Birthday attacks, which may contribute to 2256/2 = 2128 or lower complexity, have not been found.

Detailed description i. About three fundamental criteria of security evaluation, (i) collision resistance, (ii) preimage resistance*1, onewayness, (iii) second preimage resistance*2, and weak collision resistance, were discussed. The result showed that there was no problem in them. ii. The differences between SHA-1 and SHA -256 algorithms are described below. A. In message schedule calculation, an additive operation (+) was used instead of an exclusive OR operation (Å) to make the calculations more complex. This led to: (i) a higher level of difficulty in analysis because differential patterns cannot by represented by linear codes, (ii) strengthened SHA -1 characteristics, (iii) no rotary invariance in input words, which were found in SHA-0 and SHA -1, and (iv) deterioration in the accuracy of the ratio (the total number of rotation in each compression function calculation) of the lengths between the message schedule and the working register. Any specific method for evaluating the security of this kind of deterioration has not been established. It may lead to deterioration in security of SHA-256.On the other hand, it may be said that the deterioration ratio were compensated considering improved complexity in update of SHA -256 working variables and two register variables being modified at each round.

B. SHA-256, which uses eight 32-bit registers (at, bt, ct, dt, et, ft, gt, and ht) in calculating the status register update function, is similar to SHA-0 and SHA -1, which use five 32-bit

registers (at, bt, ct,, dt, and et) with following exceptions. (i) The round function is made more complex and has powerful and fast diffusivity. This

*1 Resistance incidental to calculation of M’ satisfying h(M)=h(M’) when a hash value h(M) is given. *2 Resistance incidental to calculation of M’ satisfying h(M)=h(M’) when the message M and its hash value h(M) are given

206 CRYPTREC 2001

means that at each round, both of non-linear functions, e.g., majority function Maj( ) and preference function CH( ), are applied and two register variables have been updated. (ii) The poor uniformity of the status register update functions found in SHA-0 and SHA-1 is much more deteriorated. This may improve the security of these functions.

C. Non-linear functions such as majority and preference functions, sigma functions s0( ),

s1( ), S0( ), S1( ), and a constant Kt have been properly designed. iii. Existing attacks against hash functions: The results against two searching methods, (i) Dobbertin collision search and (ii) Chaubaud & Joux collision search by differential attacks, showed that any of attacks could not be applied because the message extension process was made more complex, thus revealing that the design modification brought improvement of security. iv. Differential attacks: The result on the differential characteristics of compression function proved that the probability of differential characteristics covering four rounds is 2-8 or less and that covering all the 64 rounds is 2(-8) x 16 = 2-128. It can be concluded that any differential attacks cannot be applied to the compression function because these probabilities of differential characteristics are as low as the collision probability for 256-bit hash functions. v. The result on the repetitive differential attacks made it clear that they cannot be applied to SHA-256. vi. With respect to the modified SHA-256, in which extremely symmetric initial hash values and constants are used and an additive operation (+) has been changed to an EXOR operation (Å), security is compromised because collision

resistance is eliminated from it. Note that W32 indicates a set of symmetric 32-bit words defined as follows: (4.22) (b) Evaluator 2 Overview of the result i. The SHA-256 and SHA -512 algorithms are different from that of SHA -1 from the following standpoints. (i) More complex message processing helps to improve security. (ii) Since two variables may be updated in one step, it is difficult to apply any existing attacks. ii. A reference is made to the public comments on Draft FIPS180-2 (Jonsson’s and Kelsey’s comments). iii. At present, not only any fatal defect but also suspected poor security has not been found in SHA-256. Since it is not long after being proposed, further discussion about its security is

207 CRYPTREC 2001

needed. iv. It was verified that the modifications to SHA-1 in design were useful in improving the security against some attacks. v. As known from Jonsson’s comment, it is desirable that NIST make the results on security evaluation of SHA-256, 384, and 512, as well as the reason for modification to SHA-1, open to public. Thus, at present, not only any fatal defect but also suspected poor security has not been found in SHA-256. Since it is not long after SHA-256 was proposed and its in-depth review has not been conducted, further discussion about its security is needed. Detailed description: i. Four security evaluation criteria: (i) randomness; (ii) Birthday Paradox attack; (iii) collision resistance; and (iv) onewayness, were discussed, and no problem was found in them. ii. The result on security evaluation from the standpoint of speed-up using parallel processing showed that there existed no problem. This means that in SHA-256/-383/-512 the design of SHA-1 was modified so that the possibility of deterioration in security due to the Birthday Paradox attack might be decreased. iii. The existing attacks against hash functions: Three collision searches , (i) Dobbertin’s collision search; (ii) collision search by the Chaubaud & Joux differential attack; (iii) the collision search of modified (1-round) hash functions, were discussed. The result showed that since message extension was made more complex and any attacks could not be applied, the modification in design was useful in improving security. iv. It was suggested that, to apply hash functions to message authentication, the construction of keyed hash function, which was proposed by Bellare, Canetti, and Krawczyk, which is efficient and shows provable security, should be used until the security of Kelsey method for resolving the extension property problem is demonstrated.

2. SHA-384 and SHA-512 (a) Evaluator 1 Overview of the result: The security of SHA -384 and SHA-512 was evaluated as follows: i. It is difficult to apply any Dobbertin [2,3,4] and Chabaud-Joux [5] attacks against MD type of hash functions to SHA -384 and SHA -512. ii. Compared with SHA -1, SHA-384 and SHA -512 appear to have less number of iterative rounds and moreover, it is hard to re-structure the selection criteria of design and the variables only using the specifications with few of formal documentation obtained. Nevertheless, the greatest advantages of basic component portion of SHA -384 and SHA -512

208 CRYPTREC 2001

are that they provide considerably higher strength than those for the existing hash functions. iii. The result from the survey about the differential characteristics of the included compression functions showed that neither possible differential characteristics nor the characteristics common to the compression function at each round were identified. iv. The modified SHA-384/-512 variant (for more information, refer to (vi)), in which the constants for numbers of iterative rounds take symmetry values when divided by 2, are insecure. Thus, any of known attacks cannot be applied to SHA-384 and SHA -512 and moreover, attacks, which may contribute to 2384 and 2512or lower complexity of preimage and second preimage calculations, and usual Birthday attacks, which may contribute to 2384/2 = 2192 and 2512/2 = 2256 or lower complexity, have not been found.

Detailed description: i. About three fundamental criteria of security evaluation, (i) collision resistance, (ii) preimage resistance, onewayness, (iii) second preimage resistance, and weak collision resistance, were discussed. The result showed that there was no problem in them. ii. The differences between the SHA -1 and SHA -384 and SHA -512 algorithms are described below. A. In message schedule calculation, an additive operation (+) was used instead of an exclusive OR operation (Å) to make the calculations more complex. This led to: (i) a higher level of difficulty in analysis because differential patterns cannot by represented by linear codes, (ii) strengthened SHA -1 characteristics, (iii) no rotary invariance in input words, which were found in SHA-0 and SHA -1, and (iv) deterioration in the accuracy of the ratio (the total number of rotation in each compression function calculation) of the lengths between the message schedule and the working register. Any s pecific method for evaluating the security of this kind of deterioration has not been established. It may lead to deterioration in security of SHA -384 and SHA -512. On the other hand, it may be said that the deterioration ratio were compensated considering improved complexity in update of working variables of SHA-384 and SHA -512 and two register variables being modified at each round.

209 CRYPTREC 2001

B. SHA-384 and SHA -512, which use eight 64-bit registers (at, bt, ct, dt, et, ft, gt, and ht) in calculating the status register update function, is similar to SHA-0 and SHA-1, which use

five 32-bit registers (at, bt, ct, dt, and et,) with following exceptions. (i) The round function is made more complex and has powerful and fast diffusivity. This means that at each round, both of non-linear functions, e.g., majority function Maj ( ) and

preference function CH ( ), are applied and two register variables T1t and T2t have been updated.

(ii) The poor uniformity of the status register update function TEMPt found in SHA-0 and SHA-1 is much more deteriorated. This may improve the security of these functions. C. Non-linear functions such as majority function Maj ( ) and preference functions CH ( ),

sigma function , and a constant Kt have been properly designed. iii. Existing attacks against hash functions: The result against two searching methods, (i) Dobbertin collision search and (ii) Chaubaud & Joux collision search by differential attacks, showed that any of attacks could not be applied because the message extension process was made more complex, thus revealing that the design modification brought improvement of security. iv. Differential attacks: The result on the differential characteristics of compression function proved that the probability of differential characteristics covering four rounds is 2-8 or less and that covering all the 80 rounds is 2(-8) x 20 = 2-160. These characteristic probabilities are not so low compared with collision probabilities for 512- and 384-bit hash functions, however it may not be possible that the same low weight characteristics are combined together to form the total differential characteristics approaching the bounds. Considering that differential characteristics allow only pseudo-collisions to be detected at the first step while multiple collisions should actually be detected, it can be concluded that any differential attacks cannot be applied to the SHA-384 and SHA-512 compression functions. v. The result on the repetitive differential attacks made it clear that they cannot be applied to SHA-384 and SHA-512. vi. With respect to the modified SHA-512, in which extremely symmetric initial hash values and constants are used and an additive operation (+) has been changed to an EXOR operation (Å), security is compromised because collision

resistance is eliminated from it. Note that W64 indicates a set of symmetric 64-bit words defined as follows:

(4.23)

210 CRYPTREC 2001

(b) Evaluator 2 Summary of evaluation results: The security of SHA-384 and SHA -512 was evaluated from the following standpoints. i Since SHA-384 is materially similar to SHA-512, the focus is placed on SHA-512 only. ii The same evaluation is conducted based on comments identical to those on SHA-256.

4.3.1.6 Comprehensive evaluation results of SHA-256/-384/-512 1. SHA-256: It has not been reported that the security of commonly used SHA -1, which outputs 160-bit hash values, is compromised. In addition, with respect to SHA-256, a modified version of SHA-1, for which an alteration in design was made in expectation of long-term use and future improvement in computer performance, the message extension process has been made more complex and any existing attacks against hash functions may not be applied, although its design criteria are not clear. Because it is not long since SHA -256 was proposed, further discussion about its security is needed. Nevertheless, it can be concluded that SHA-256 is secure at the present time. 2. SHA-384/-512: It has not been reported that the security of commonly used SHA -1, which outputs 160-bit hash values, is compromised. In addition, with respect to SHA-384/-512, modified versions of SHA-1, for which alterations in design were made in expectation of long-term use and future improvement in computer performance, the message extension process has been made more complex and any existing attacks against hash functions may not be applied, although theirs design criteria are not clear. Because it is not long since SHA-384/-512 was proposed, further discussion about its security is needed. Nevertheless, it can be concluded that SHA-384/-512 are secure at the present time.

References [1] SHA-1: National Institute of Standards and Technology (NIST) draft FIPS 180-1: Secure Hash Standards, April 1994. [2] H. Dobbertin, Cryptanalysis of MD4, in Journal of Cryptology, 11-4, Autumn, 1998. [3] H. Dobbertin, Cryptanalysis of MD5 Compress, Presented at the rump session of Eurocrypt'96, May 14, 1996. [4] H. Dobbertin, The status of MD5 after a recent attack, CryptBytes, 2-2, 1996, pp3-6. [5] F. Chaubaud and A. Joux, Differential Collisions in SHA-0, extended abstract, in CRYPTO'98, LNCS 1462, pp.56-71, 1998. 4.4 Monitoring Process Evaluation

211 CRYPTREC 2001

4.4.1 RIPEMD-160

4.4.1.1 Technical overview

RIPEMD-160, a hash function proposed by Dobbertin, Bosselaers, and Preneel, is one of the results of the Race Integrity Primitive Evaluation (RIPE) project in Europe. It has been included in the International Standards by the International Organization for Standardizations (ISO) along with SHA-1 and RIPEMD-128 [1]. RIPEMD-160 outputs a 160-bit hash value corresponding to its input, which is an arbitrary message padded so that the bit length is a multiple of 512.

4.4.1.2 Technical specifications

RIPEMD-160 has been deigned to improve MD4 and MD5. In addition, like MD4, it has been structured using 32-bit addition, logical operation, and cyclic-shift instructions as main operations to achieve fast processing in the 32-bit computer. RIPEMD-160 consists of the three parts: input, compression, and output. RIPEMD-160 runs two functions with almost the same pattern in parallel to output a 160-bit hash value from a message of arbitrary length. These two functions are called a right line and a left line, each consisting of five rounds, that is, 80 steps. For detailed specifications of RIPEMD-160, refer to [1].

(1) Input An input message is converted into a 32-bit integer using little-endian ordering and divided into 512-bit blocks. 16 32-bit inputs X[0],…,X[15] are input to the right and left lines in a given order. (2) Compression function In calculating the compression function, five chaining variables (A, B, C, D, and E) are used. Besides the initial values for A, B, C, and D, which are the same as in MD5, the initial value for additional E

has been defined. The initial values IV = (h1, h2, h3, h4, h5) for (A, B, C, D, and E) are shown below.

These initial values are commonly used in both of the right and left lines. In addition, the following five types of Boolean functions are used in calculating the compressio n function.

Where, a symbol Ù is bitwise AND, Ú is bitwise inclusive-OR, Å is bitwise exclusive-OR, and

212 CRYPTREC 2001

indicates bitwise complement of x. The step functions making up the RIPEMD-160 compression function are listed below. Where, a subscript R indicates that the variables with it are in the right line while L indicates that the variables with it are in the left line. RIPEMD-160 runs the steps in the right and left lines in parallel for hashing. The constants KL[j] and KR[j] used in calculating the step functions are as follows:

The number of bit positions for left cyclic shift sL[j] and sR[j] in the step functions are predefined. The step functions in PRIEMD-160 are shown below. Note that it is assumed that in this example, a symbol X<

Round 2 (17 £ j £ 32)

Round 3 (33 £ j £ 48)

Round 4 (49 £ j £ 64)

Round 5

213 CRYPTREC 2001

(3) Output Basically like MD5, the chaining values obtained in the last step are updated by adding the initial values and then the five variables (A, B, C, D, and E) are concatenated to output a hash value. Since the two lines are used, they are calculated as follows:

4.4.1.3 Others

Since possible attacks were found against RIPEMD, which had been proposed in the RIPE project in 1995, RIPEMD-160 was proposed as the refined version of it [2]. RIPEMD-160 is one of MD4-based hash functions.

4.4.1.4 Evaluation Results n Security: The security of hash functions can be evaluated mainly from the following two viewpoints: One is the computational cost required for finding an input corresponding to a given output, that is (1) the cost required for searching for preimage. The other is the computational cost required for finding different inputs which hash to the same output, that is (2) the cost required for detecting a collision. RIPEMD-160 is sufficiently resistant to (1) and (2). Supplementary explanations are given below. n RIPEMD-160 specific attacks: It has been reported that with respect to RIPEMD, a predecessor of RIPEMD-160, a collision can be detected in 231 or less computations if the first or last round was omitted [3]. To address this problem, the number of rounds has been extended to five in RIPEMD-160, achieving higher independency between the right and left parallel lines, which in turn, contributes to enhanced security. No attacks jeopardizing RIPEMD can be applied to RIPEMD-160 and no RIPEMD-160 specific attacks have been reported. n Computational cost searching for input value: At most 2n patterns of hash values can be output by a hash function in which the bit length of a hash value is n. Therefore, the preimage of any given output can be found by preparing 2n inputs which hash to all the 2n possible outputs. Since n = 160 in RIPEMD-160,

214 CRYPTREC 2001

2160 input patterns are required if this method is applied. It is considered that 2160 input patterns are too many to prepare using the existing techniques. n Computational cost finding any collision: Assuming that the length of a hash value is n bits, if 2n/2 input values have been prepared, a collision can be found with relatively high possibility. This is known as a Birthday attack, a commonly used analytical method. The hash values must have a sufficiently long length to avoid this problem. Since n = 160 in RIPEMD-160, a Birthday attack can be applied if approx. 280 messages are prepared. It is considered, however, that the preparation of such many input values is impractical at the present time.

4.4.1.5 Software Implementation Evaluation

CRYPTREC has not evaluated implementation. However, the following evaluation result is [4].

Platform: Celeron (850[MHz]) OS and language: Windows 2000 SP1, C++ Processing performance: 30.725[Mbyte/sec]

4.4.1.6 Hardware Implementation Evaluation

The throughput and circuit size in hardware implementation have not been evaluated.

References [1] ISO/IEC 10118-3, Information technology - Security techniques - Hash-functions - Part3: Dedicated hash-functions [2] H. Dobbertin, A. Bosselaers, B.Preneel, RIPEMD-160: A strengthened version of RIPEMD, Fast Software Encryption - Cambridge Workshop, LNCS vol.1039, Springer-Verlag, pp.71-82, 1996. [3] H. Dobbertin, RIPEMD with two-round compress function is not collision-free, Journal of Cryptology 10 (1): pp.51-70, 1997. [4] http://www.eskimo.com/~weidai/benchmarks.html

215 CRYPTREC 2001

4.4.2 SHA-1

4.4.2.1 Technical overview

SHA-1 is a hash function, which is the refined version of Secure Hash Algorithm (SHA) proposed by National Institute of Standards and Technology (NIST). The advantage of SHA-1 is that input messages are used like keys in block ciphers. This means that the input message is used to create a new message at each step, which is inputted to the step function. The generation of new messages seems to give resistance to attacks based on message manipulation. SHA-1 performs 4 rounds, that is 80 steps, of arithmetic operations on each message block and outputs a 160-bit hash value.

4.4.2.2 Technical specifications

SHA-1 outputs a 160-bit hash value corresponding to an input message of arbitrary length. The input data is processed as a 512-bit block. The process flow consists of the following five steps.

Step 1: Addition of padding bits

Like MD5, the input message is extended so that its bit length is 448 mod 512. In this case, even if the message length satisfies 448 mod 512, padding bits must be added. The padding bits, of which only the first bit is “1 (one)” and others are “0 (zero)”, are added after the message.

Step 2: Addition of length information

Like MD5, 64-bit data of information on the bit length of the original message (not yet padded) is added after the padding bits.

At this point, the original message has been converted into the extended message with bit length

of a multiple of 512. That is, it can be expressed as a 512-bit block series Y0, Y1, … ,YL-1, and its length is L x 512 bits.

Step 3: Buffer initialization

The buffers (chaining variables), in which hash values are stored, are expressed as (A, B, C, D, and E) using five 32-bit registers. These 160-bit registers store the intermediate values for hash values, which are used as inputs to the compression functions, or store the last results. Before the first compression function acts, the values are stored in these registers as follows :

216 CRYPTREC 2001

These values are the same as in RIPEMD-160. The first four values are the same as in MD5.

Step 4: Compression processing

The main functions of SHA -1 are the compression functions consisting of four rounds, each of which has 20 steps. These rounds have the similar structure, although they perform compression processing using different logical operation functions, f1, f2, f3, and f4. Each round uses a

512-bit block Yq, which is being processed, and a 160-bit buffer value as an input, and updates the values in the 160-bit buffers A, B, C, D, and E with an output from the round.

th The output from the fourth round (80 step) is added to the input (CVq) to the first round for the

compression function into CVq+1, which is used in performing the next compression function. This mod232 addition is calculated independently in each of five buffers.

Step 5: Output of message digest

After processing all the L 512-bit blocks using the compression functions, SHA-1 outputs the hash values from the 160-bit buffers.

4.4.2.3 Security evaluation result

As shown in the SHA-1 algorithm, to evaluate SHA-1, not only the compression function but also the extended procedure of input message must be analyzed. SHA, the predecessor of SHA -1, has the extended procedure of input message consisting of EXOR operations only. Thereby, collision against the compression function could be found by analyzing the procedure. On the other hand, it has been reported that the attacks against SHA cannot be applied to SHA -1 which performs the 1-bit left cyclic shift operation in the extended procedure. At present, since no practical attacks against SHA-1 have been reported, it seems to be secure to use SHA -1 in cryptographic applications. The security, nevertheless, must be ensured against exhaustive key search. Assuming that the length of a hash value is n bits, since collision can be found among the hash values for 2n messages by the Birthday attack, a sufficiently longer length must be assigned to the hash values. With respect to SHA-1, since its hash length is 160 bits, collision can be found among 280 hash values. Thus, it cannot be assured that SHA -1 will remain secure in future.

217 CRYPTREC 2001

5 Evaluation of Pseudo-random Number Generators

5.1 Evaluation Method

5.1.1 Method for Evaluating Pseudo-random Number Generators

Pseudo-random number generators described here are intended to generate random numbers to be used in creating encryption keys or key seeds, unlike generating key streams for stream ciphers. They are required to have the characteristics which are similar to that for generating true random numbers, and to provide cryptographic security. To evaluate its security, FIPS140-1/2, which is the evaluation method for pseudo-random number generator for stream ciphers, was applied to the output random numbers.

• Long-period characteristics • Linear complexity • Equal 0/1 frequency • Monobit test • Poker test • Run test • Long-run test

Since the pseudo-random number generator is intended to use in cryptographic applications, it is required that the outputs be not predicted and the input be larger than the output space.

5.2 Overall Evaluation

5.2.1 Pseudo-random Number Generators

5.2.1.1 Screening evaluation n Target evaluated: Screening evaluations of the following cryptographic techniques submitted for evaluation in 2001 were conducted.

• Creation of intrinsic random numbers with Clutter Box • FSRansu • High security u ltra mini random number generator • TAO TIME Cognition Algorithm

n Target evaluated: It was determined whether the cryptographic techniques listed above were worth being evaluated in detail in reference to the documents submitted. The screening evaluation terms are described below.

218 CRYPTREC 2001

• Confirmation of essential descriptions, logical consistency and self-contained of descriptive argument • Checking for any faults, which can be readily found on the document • Inspection and validation of the cryptographic technique specifications and self-evaluation descriptions submitted n Results:

Creation of intrinsic random numbers with Clutter Box: This algorithm requires special hardware and involves difficulty in evaluation based on the submitted documents. No sufficient information on the random number generation algorithm is provided.

FSRansu: No reference program and test vector generation program, both of which are essential for evaluation, have been submitted.

High security ultra mini ransom number generator: This algorithm requires special hardware and involves difficulty in evaluation. The reference program exclusively observes random number sequences, and the submitted documents accompanying it do not satisfy the conditions for evaluation.

TAO TIME Cognition Algorithm: This algorithm cannot be considered to be eligible for the pseudo-random number generator requested by CRYPTREC.

5.2.1.2 Continued evaluation

Pseudo-Random Number Generator based on SHA-1 was continuously evaluated. n Feature: This is the pseudo-random number generator based on Secure Hash Algorithm (SHA-1) defined in FIPS180-1. n Result: Since, with respect to SHA -1, a collision may occur against 280 hash values, the length of these values should be adequately long. At present, Pseudo-Random Number Generator based on SHA-1 seems to be securely used in e-Government applications without any problems. However, special attention should be paid when it is used for a long period. It is preferable that pseudo-random number generators based on any of the next -generation SHAs (SHA-256, SHA-384, and SHA-512), which output hash values with length of 160 bits or more and which will be standardized in 2002 or later as FIPS, is employed.

219 CRYPTREC 2001

5.3 Evaluation of the Ciphers under Monitoring

5.3.1 PRNG Based on SHA-1

(FIPS186-2: DSS Appendix 3. Random number Generator for the DSA)

5.3.1.1 Technical overview

Digital Signature Algorithm (DSA) requires a user secret key x for a message M, as well as another secret key k for each message signature, and r and s as shown in the following formula.

(5.1)

Where, p, q, and g are public parameters, (kk-1) mod q = 1 (0 < k-1 < q), and SHA -1(M) is an 160-bit output value from SHA defined in FIPS 180-1.

Digital Signature Standard (DSS), which is specified as FIPS186 (May 1994) (revised into FIPS186-2 in January 2000), recommends three types of pseudo-random number generation methods for generating x, r, and s as described below (the detailed information of each method can be found in sections I, II, III, or IV).

(1) The method using an 160-bit one-wayness function G(t, c) specified in ANSI X9.17 Appendix C “Financial Institution Key Management (Wholesale)”. (t is 160-bit length and c is b-bit length. When G( ) is based on SHA-1, 160 £ b £ 512 holds, while when G( ) is based on Data Encryption Algorithm (DEA) (DES is used in ANSI X9.17 Appendix C), b = 160 is fixed.) (2) The method for generating m-types of x specified in FIPS186-2 Appendix 3.1. (The 160-bit one-wayness function G(t, c) is based on SHA -1 or DES.) (3) The method for generating k and r with no assumption that m-types of messages to be signed should be known, which is specified in FIPS186-2 Appendix 3.2. (The 160-bit one-wayness function G(t, c) is based on SHA-1 or DES.)

FIPS 186 recommended to use Secure Hashing Algorithm (SHA) which is FIPS180 standard. Then, in April 1995, Secure Hash Standard (SHS) has been defined in FIPS180-1 standard (May 11, 1993), which specifies the specifications of Secure Hash Algorithm (SHA-1) as the only recommended version of SHS for generating a 160-bit message digest.

NIST publishes Random Number Generation and Testing at its Web site, which is useful in making various statistic tests more complete for verifying randomness in binary series used in cryptographic applications, in publishing each test software implementation, and in applying these tests in the actual fields.

220 CRYPTREC 2001

5.3.1.2 Technical specifications (I) (I) Technical specifications for generating m-type of x specified in FIPS186-2 Appendix 3.1.

(1) Select a new secret number wxkey.

(2) The 512-bit initial value H0||H1||...||H4 for the SHS hash function is set as follows:

(5.2)

(3) Repeat the following steps (a) to (d) assuming that 0 £ j £ m-1 holds.

(a) Select wj (user optional). b (b) cj = (wxkey + wj) mod 2 , 160 £ b £ 512

(c) xj = G(t, cj) mod q b (d) wxkey = (1 + wxkey + xj) mod 2 (II) Technical specifications for generating m-type of r and k specified in FIPS186-2 Appendix 3.2.

(1) Select a new secret number wxkey. (2) Select the 512-bit initial value t for the SHS hash function, shifted from (5.3) to (5.4). (3) Repeat the following steps (a) to (d) assuming that 0 £ j £ m-1 holds.

(a) k = G(t, wkkey) mod q (b)

k (c) rj = (g mod p) mod q b (d) wkkey = (1 + wkkey + k) mod 2

(4) Repeat the following steps (a) to (c) assuming that m messages are M0, M1,…, Mm-1, and that 0 £ j £ m-1 holds.

(a) h = SHA-1 (Mj), where SHA-1( ) indicates a one-wayness function based on SHA-1. (b) Calculate

(c) Specify (rj, sj) as a signature for Mj. (5) Set t = h. (6) Return to step (3). (III)Technical specifications for a one-wayness function G(t, c) based on SHA-1 specified in FIPS186-2 Appendix 3.3. G(t, c) can be obtained by following the steps (a) to (e) of (III-II) specified in Section 7, or the steps

221 CRYPTREC 2001

(a) to (d) of (III-III) specified in Section 8 of the SHS technical specification (FIPS180-1, April 11,

1995). Prior to these executions, initialization of {Hj} and padding of an input message c must be done as follows:

(III-I) Initialization of {Hj} and padding of an input message c (i) Assume that

(5.5)

dividing 160-bit t into 32-bit patterns (t = t0||t1||…||t4). 512-b (ii) M1 = c||0 (III-II) Steps specified in Section 7 of SHS technical specifications A message X padded as mentioned above consists of 16 x n words (1 word = 32 bits). These n blocks

(1 block = 16 words, 512 bits) are referred to as M1, M2,…,Mn, respectively. The first block M1 contains the first several bits of the input message c. The 512-bit initial hash value is set as follows for the first buffer group of A, B, C, D, and E (each of five buffers contains 32-bit word), the second buffer group of H0, H1,…, H4, and a 80 word group of

W0, W1,…, W79:

(5.6)

To process Mi, execute the following steps (a) to (e):

(a) Divide Mi into 16 words as follows: (5.7) (b) Calculate the message schedule function as follows: (5.8) Note that a symbol Å indicates an EXOR operation and Sn(X) indicates the n-bit (0 £ n £ 32) left cyclic shift function, Sn(X) = (X << n) È (X>> 32 - n), of word X. (c) Initialize five buffers as follows:

(5.9)

Note that is an initial hash value as shown below:

222 CRYPTREC 2001

(5.10)

(d) Calculate the following formula assuming that the condition 0 £ t £ 79 holds. Padding must be performed into any bit string x with bit length of 264 bits or less (l £ 264 - 1) before inputting it to SHA -1 as follows: (5.11) Note that m + l + 1 = 448 mod 512. (5.12)

(5.13)

where, f(B, C, D) is a function defined below:

(5.14)

indicate a complement logical operation, AND, and OR, respectively. Kt is a constant defined below:

(5.15)

(e)

(5.16)

After the final message Mn has b een processed, a 160-bit message digest is output as follows: (5.17) (III-III) Steps specified in Section 8 of SHS technical specifications

80 word group of W0, W1,…,W79 used in the steps specified in Section 7 can be simplified (for memory saving) as follows. MASK is assumed to be 0000000F. To process Mi, execute the following steps (a) to (d).

223 CRYPTREC 2001

(a) Divide Mi into 16 words as follows: (5.18) (b) Initialize five buffers as follows:

(5.19)

(c) Calculate the following formulae assuming that the condition 0 £ t £ 79 holds: (5.20)

(5.21)

(5.22)

(5.23)

(d)

(5.24)

*1 After the last message Mn has been processed, a 160-bit message digest is output as follows :

(5.25)

(IV)Technical specifications of one-wayness function G(t, c) based on DES in FIPS186-2 Appendix 3.4.

It is assumed that a1, a2, b1, and b2 are 32-bit strings and is the lower 32 bits of b1. Under conditions

(5.26)

a symbol DESK(A) is defined as follows: (5.27)

where DESK(A) indicates a ciphertext by the ordinary DES encryption using a 56-bit key K for an 64-bit block A. Calculate the one-wayness function G(t, c) for 160-bit t and c by following the steps:

*1 The message digest obtained from Section 7 is the same as that from Section 8 with an exception that the latter can save memory at the sacrifice of computing time.

224 CRYPTREC 2001

(a) Divide t and c into 32-bit patterns, respectively, as follows:

(5.28)

(b) Calculate the following formula assuming that the condition 0 £ i £ 5 holds. (5.29) (c) Calculate the following formulae assuming that the condition 0 £ i £ 5 holds.

(5.30)

Note that y1 and y2 are 32-bit strings. (d) Calculate the following formula assuming that the condition 0 £ i £ 5 holds. (5.31) (e) A message digest is output as follows: (5.32)

5.3.1.3 Others 1. CMV Program The NIST Cryptographic Module Validation (CMV) Program uses Digital Signature Validation System (DSSVS) v2.3 to evaluate DSA, RSA, and SHA-1 aiming at the establishment of Digital Signature Standard (DSS) and Secure Hash Standard (SHS). The 2001 FIPS draft of three next -generation SHAs, which are to be used in the next -revisions of DSA and AES to output longer message digests, was proposed. 2. DSA flaw On February 6, 2001, the news of DSA flaw that Daniel Bleichenbaner, a researcher of Bell Communications Research, detected a bias in the random number of DSA was broadcast. On the other hand, it was also reported that the DSA flaw might not be caused by SHA -1. Through discussion in the ANSI X9F1 conference (responsible for X9.30 DSA standardization), NIST made the following formal opinions regarding the DSA flaw open to public. • No problem may occur if the number of signatures is less than 2,000,000. • If DSA is SW-fixed, it is required to use ECDSA to produce k of at least twice the hash length. • To calculate k, 32 or more additional bits are needed. That is, 192 or more random bits are required for 160-bit k.

225 CRYPTREC 2001

3. Cryptographic Toolkit With respect to Cryptographic Toolkit, the random number generation methods are largely grouped into Random Number Generators (“true” randomizers generally referred to as non-deterministic generator) and Pseudo-Random Number Generators (PRNGs) (generally referred to as deterministic generation methods). The former was derived from certain types of physical quantities including noise in electric circuitry, timing such as user key-stroking on a computer keyboard and mouse movement, and quantum effect of semiconductors. In these methods, the output from the RNG is used as a random number or an input to the PRNG. The latter generates more than one “pseudo-random number” (the output is a function for the seed) by using one or more inputs derived from a seed obtained from the RNG output. At present, however, no FIPS Standards have been established for the latter. It is known that, compared with RNGs derived from any physical source, PRNGs generate a sequence of numbers at a higher speed and often provide good values for statistical verification of “randomness.” NIST makes efforts in bringing various types of Cryptographic Toolkits into more complete state including Encryption, Modes of Operation, Digital Signatures, Secure Hashing, Key Management, Random Number Generation, Message Authentication, Entity Authentication, and Usage and Generation. It aims to give the comprehensive standards for standardization, recommendation, and formulation of guidelines to assist the U.S. Government and other organizations in selecting any of cryptographic security techniques. 4. RNG Testing NIST Special Publication (SP) 800-22 “A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications (revised in December 2000)” provides information such as various statistical random number verification methods, directions for use, interpretation of the results from the verification, and other pseudo-random number generation methods.

5.3.1.4 Security evaluation n Overview: It is considered that the e-Government can use the FIPS standard of pseudo-random number generators with SHA -1 without problems. Note that, if this type of SHA-1 based pseudo-random numbers is used in the selected encryption scheme (electronic signature) as implementation of Random Oracle, the assumption for theoretical proof does not hold.

Nevertheless, though depending on applications of pseudo-random usage, it is permissibly said that no problem occurs even if SHA-1 based pseudo-random generators are used because of limited implementation environment. Note that if SHA-1 itself is used as the hash function in electronic-signature applications,

226 CRYPTREC 2001

Birthday attack may compromise them by 280 computation complexity, which is the lowest level of security at present. It is preferable to use any of the next -generation SHAs expected to be standardized within one or two years which provide longer outputs. If the implementation environment is limited, the SHA-1-based (or DES-based) FIPS-186 pseudo-random number generators may be securely used assuming a proper length of pseudo-random and a proper number of its generation.

References [1] CNN.com.SCI-TECH, Cryptologists sees digital signature flaw, fix: http://www.cnn.com/2001/TECH/internet/02/06/DSA.flaw.idg/index.html [2] Cryptographic Toolkit: http://csrc.nist.gov/encryption/ [3] Secure Hashing: http://csrc.nist.gov/encryption/tkhash.html [4] Random Number Generation: http://csrc.nist.gov/encryption/tkrng.html [5] New hashing algorithms (SHA -256, SHA-384, and SHA-512): Descrptions of SHA -256, SHA-384, and SHA-512 [6] FIPS Pub 186-2, Digital Signature Standard (DSS) (revised on January 27, 2000) Appendix3: Random Number Generation for the DSA [7] NIST Special Pubilication 800-22 (revised in Dec. 2000) A Statistical Test Suite for Random and Pseudorandom Numbetr Generators for Cryptographic Applications [8] FIPS140-1, Security Requirements for Cryptographic Modules, Cryptographic Module Validation (CMV) Program: http://csrc.nist.gov/cryptval/cmvp.html

5.4 Evaluation of Ciphers to be Screening-Evaluated

5.4.1 TAO TIME

5.4.1.1 Technical descriptions

According to the specification submitted by the applicant, the TAO TIME recognition algorithm allows the client (accessing computer) and the server (accessed computer) deployed at different points on the network to “recognize” one another. On the other hand, according to the reference program specifications, the TAO TIME recognition algorithm is intended to generate pseudo-random numbers. Only one function referenced by means of the terminology “random number” in the former specifications is a(n), and the function a(n) is defined in the latter. This means that the function, which may be eligible for the requested pseudo-random number generation scheme, is a(n) only among those submitted.

The client uses the numerical values derived from a(n) and data previously received from the server to calculate data to be sent to the server next using a recurring formula and then sends the result. The server

227 CRYPTREC 2001

uses data previously received from the client to calculate data to be sent to the client next using a recurring formula and then sends the result. It is assumed that the server and the client recognize each other through the consecutive data exchanges.

The TAO TIME s pecification describes that the term “recognition” does not mean the term “authentication”. However, no clear line was drawn between them. It is not clarified whether recognition can be implemented through data exchange between the server and the client along with “authentication” commonly used in information security applications or “recognition”, which is something else supposed by the applicant himself/herself, may be implemented independently of “authentication.”

5.4.1.2 Screening-evaluation result

Data transferred between the server and the client is open on the network because it is calculated by the recurring formula, for example, a client identification C(n), server identification S(n), and scramble value X(n). Then, data not open on the network can be easily calculated from data open on the network, including a(n) inversely using the recurring formula. This means that when C(n), S(n), X(n), and a(n), as well as other data, which appear in the recurring formula, are used as random numbers, of which confidentiality must be ensured in generating secret keys, security problems will occur. Thus, this method, which outputs such data, is too less secure to use as a pseudo-random number generator in e-Government applications.

In addition, focusing on a(n) only, when a(n) - a(n-1) is decimally expressed, five lower digits always indicate the physical time. This suggests that this method is too less secure to be employed as the required pseudo-random number generators.

Or, if client-server “recognition” is used as something different from “authentication” commonly used in information security applications, CRYPTREC has no comment.

Nevertheless, in the cryptographic scheme for e-Government, a terminal-authentication tool must ensure security. In the submitted method, data not open on the network can be easily known later in the recurring formula. Since data with confidentiality is not found, the submitted method does not seem to provide sufficient security with no modification made to the specifications.

228 CRYPTREC 2001

6 Evaluation of SSL-protocol cryptographic techniques

6.1 Overall evaluation

6.1.1 Purpose

SSL (Secure Socket Layer) is the security protocol that is most commonly used in the Internet. SSL, which implements encryption processing and the authentication function on Web, is widely used in e-commerce over the Internet. Another protocol, TLS (), which has almost the same specifications as that of SSL, is under discussion about whether it should be employed as an Internet Standards.

This investigation is intended to examine and evaluate security of SSL/TLS protocols and ciphers used in them. We expect that the result from the investigation will help the procurement authorities, designers, and users of e-Government security scheme understand the security of ciphers and protocols used in SSL/TLS correctly, achieving proper use of them.

To verify the security of SSL/TLS, the SSL specifications and commonly used implemented software are checked for any security hole. Security evaluation of cryptographic techniques used in SSL is performed at the same level as those for any other candidate ciphers for e-Government as possible to enable comparison between them.

Finally, the considerations in operating SSL in e-Government are summarized.

6.1.2 Target and scope of the investigation

SSL is a protocol (communications procedure) positioned in the session layer in the OSI reference model and achieves universal security independent of applications such as Web browsing and file transfer. SSL3.0[15] is the protocol defined by U.S. Netscape Communications. TLS (Transport Layer Security) Ver1.0[7], a successor of SSL3.0, has been defined as RFC2246 by IETF (Internet Task Force), which makes efforts in standardizing Intern et technologies. The differences between SSL3.0 and TLS1.0 and the ongoing effort for extending TLS in IETF are also examined.

The Cryptographic Advisory Committee has requested us to evaluate the security of the following ciphers in the SSL application environment.

Symmetric-key cryptosystem RC2(40 or 128 bits), RC4(40 or 128 bits), DES(40, 56, or 168 bits) Public-key cryptosystem RSA ciphers

RC4 has been excluded from this report because of being under evaluation.

229 CRYPTREC 2001

6.1.3 Method

Cipher evaluation was entrusted to internal and external cipher researchers (organizations) and the CRYPTREC Evaluation Committee made up the result. The researchers participating in cipher evaluation included one (organization) for DES, two (organizations) for RC2, and five (organizations) for RSA. The evaluation period was from October 2001 to February 2002.

6.1.4 Result

6.1.4.1 Investigation on SSL/TLS protocol vulnerability

With respect to the SSL/TLS protocols, the security of their encryption schemes, of protocols themselves, of implementation, and of operation were investigated and the following results were obtained. n Security of encryption schemes : Such a problem was reported that the random numbers used in DSA signatures for SSL were not uniform and a bias was detected. The implementation specifications, PKCS#1, are applied to encryption by the RSA public key cryptosystem. Since it has been pointed out that an adaptive chosen message attack against PKCS#1V1.5 exits, it is recommended that PKCS#1V2.0, an improved version of PKCS#1V1.5, is used. Another security hole was detected in PKCS#1V2.0 and fixed in V2.1. n Security of protocols: SSL provides three types of authentication modes, Mutual, Server Only, and Anonymous. In the anonymous mode, a man-in-the-middle attack was detected, which means that an offender intervenes between two parties communicating one another. Since attacks such as data or alteration may be made, it is not recommended that this specification is used. In addition, a version rollback attack was detected, in which an offender forces the server and client compatible with SSL3.0 to communicate using SSL2.0 or lower. n Security of implementation: With respect to the authentication schemes using SSL/TLS public key certificates, undesirable cases have been reported: 1) no certificate detection mechanism has been implemented, 2) no alarm is issued against illegal certificates, and 3) such an attack that the authentication process is bypassed can be made. Another attack has been reported, which exposes the internal information in the pseudo-random number generator used in building a session key. Any security holes in implementation can be avoided using the latest version of protocols or modified programs of which bugs were fixed. n Security of operation: SSL/TLS provide several parameters to be set on the server and client sides, respectively at the initiation of operation. These parameters include files for storing keys and certificates, life times for session keys, random number generation method, encryption algorithm used, and enable/disable warning message display. For that reason, the meanings of these parameters must be well understood before they can be correctly set. Any careless settings may form security holes.

230 CRYPTREC 2001

n SSL/TLS comparison: Generally, compared with SSL, TLS has higher security in that the rationale for the security of keys, initial values, and MAC generation was demonstrated and its signature structure has been slightly modified. It, however, is considered that SSL is also at the secure level with no problem.

6.1.4.2 Evaluation of ciphers used in SSL/TLS

The following result was obtained from security evaluation of ciphers used in SSL/TLS. n DES (refer to 6.3.2.4) (security evaluation of ciphers itself)

DES with key length of 40 bits can be broken within a practical time by exhaustive key search. DES with key length of 56 bits also may be broken in the near future. 3-key Triple DES with key length of 168 bits can be securely used with no problem for the time being.

(security evaluation in SSL/TLS) DES with either key length is used for concealment of data. The CBC mode is used for block encryption mode of operation. Note that encryption of 232 blocks or more with the same session key may cause one bit of plaintext to leak. n RC2 (refer to 6.3.3.3) (security evaluation of ciphers itself)

RC2 with key length of 40 bits can be broken within a practical time by exhaustive key search. RC2 with key length of 128 bits may also be broken in the near future. Adoption of the latest cryptanalysis allows a cryptanalysis more effective than exhaustive key search to be conceived. Cryptanalysis is theoretically possible.

(security evaluation in SSL/TLS) Either 40 bits or 128 bits can be selected for the key length in SSL2.0 and 40 bits only in SSL3.0. With a 40-bit key, exhaustive key search can be done within just several hours in the practical computing environment. Note that encryption of 232 blocks or more with the same session key may cause one bit of plaintext to leak as in DES. n RSA (refer to 2.3.1, 2.4.4, and 6.3.1.2) (security evaluation of ciphers itself)

The 512-bit modulus can be practically factorized and is not secure. As of 2001, it is considered that the use of a 1024-bit or higher modulus ensures security.

(security evaluation in SSL/TLS) The security of the basic key sharing and electronic signature schemes using RSA ciphers in SSL and TLS were investigated. The result showed that little room for inherent security holes has been left because these encryption protocols employed simple schemes based on a set of simplest techniques .

231 CRYPTREC 2001

6.1.5 SSL/TLS application and considerations of actual use

To make secure use of SSL/TLS, they must be adequately operated. Information on how to operate SSL/TLS and the considerations of actual use of them are given below. n SSL/TLS protocols (refer to 6.2)

• When SSL3.0 is used, it is required that known security holes be well recognized and then implemented with special care, for example, SSL2.0 including inherent security holes is not used. • When commercially available SSL software is used, the latest version, in which patches have been assigned to the security holes, should be selected. • Wire respect to commercially available Internet Explore and , management of Revocation List (CRL) is not provided. For that reason, such attacks may occur that an offender erases the desired entry from the CRL with malicious intent and then uses the illegal certificate to deceive the authentication mechanism. To avoid this problem, the files containing the certificates should be managed in accordance with any strict access-controlled procedure. • Since information may be subject to eavesdropping or alteration, it is not recommended that the anonymous authentication mode be used. • With respect to SSL3.0, only a fixed encryption schemes are available. On the other hand, with respect to TLS1.0, new cryptographic techniques can be incorporated. This enables the TLS1.0 to address the problem, if any, in the existing cryptographic technique. • At present, TLS is under enhancement aiming at addition of new features. Since any new security holes may be detected as the enhancement work proceeds, it is required that special attention be paid to the fu ture TLS standardization activity and its security be continuously investigated and discussed. n Ciphers used in SSL/TLS (refer to 2.3.1, 2.4.4, 6.3.1.2, 6.3.2.4, and 6.3.3.3)

• Whether RC2 or DES is employed, any ciphers with key length of 40 bits should not be used in a secure system because of their being able to be cryptanalysed within a practical time period by exhaustive key search. • DES with key length of 56 bits has been able to practically cryptanalysed. If it is used, this fact should be carefully taken into account. Triple DES with key length of 168 bits seems to have no special problem in security for the foreseeable future. Note that it is preferable that Triple DES is replaced with another set of ciphers with higher security, if any. • If RC2 or Triple DES, which are sets of 64-bit block ciphers, is used, session key update must be performed with special care because one bit of plaintext may leak if 232 blocks or more are encrypted with the same session key. • For RC2 with key length of 128 bits, cryptanalysis with more efficient than that of exhaustive key

232 CRYPTREC 2001

search exists. For that reason, it is not recommended that RC2 with key length of 128 bits is employed in a newly built e-Government system. • Schemes with a 512-bit modulus is insecure because of its being able to be actually factorized. As of 2001, the use of schemes with 1024 bits or more modulus is considered to be secure.

6.2 Implementation of SSL/TLS protocol and evaluation of operation

SSL (Secure Socket Layer) is a security protocol most frequently used for the Internet. It is mainly used for encryption and authentication on the Web. On-line credit card payment using SSL is a key technology in electronic business transactions. However, it is also a fact that there is a that the use of SSL always assures the security. Objective investigation and evaluation of to what extent SSL assures safety have rarely been carried out. Therefore, it is recommended that the user of SSL acquire good knowledge on security before using it.

This report summarizes the results of SSL/TLS security investigation conducted from various viewpoints including the investigation of TLS (Transport Layer Security) that has the same specifications with SSL. To be specific, from the viewpoints of (1) security of cryptosystem, (2) security as a protocol (mechanism), (3) security on implementation, and (4) security in operation, security holes that had been reported were investigated, and additional considerations were given to them. With regard to security of cryptosystem in (1) and security as a protocol in (2), security holes may be created due to the problem of specifications. Of those, the ones that are associated solely with cryptosystems are classified in (1), and the problems on protocol procedure associated with both entities of end-end are classified in (2). (3) includes problems that may occur during implementation, which is mainly considered to be bugs. (4) includes problems associated with operations and configuration information that can be specified when operating SSL/TLS.

This report then clarifies the difference between SSL and TLS. In addition, investigation on security of expansion of TLS, which is under review by IETF, was carried out. The outline of investigation result is shown below. Note that the latest version of SSL is 3.0, and that of TLS is 1.0. Unless otherwise stated, SSL indicates SSL3.0[15], and TLS indicates TLS1.0[7].

6.2.1 Security associated with cryptosystem

Cryptosystem is the base of security protocol. SSL/TLS uses the signature scheme, public key cryptosystem, symmetric-key cryptosystem, and keyed hash processing. Of those, the problem of biased random number generation (Bleichenbacher attack) and the possibility of adaptive chosen cyphertext attack for encryption using RSA public key cryptosystem (Million Message attack and attack by Manger) have been pointed out. However, since improved methods have been proposed for those problems, the use of the latest version software can eliminate the possibility of occurrence of those problems.

233 CRYPTREC 2001

6.2.2 Security associated with protocol mechanism

Some typical attacks against protocols have been carried out not only against SSL/TLS but also against other protocols. Specific examples are: Man-in-the-middle Attack, by which the attacker intervenes between the communication between the two like a gateway, Replay Attack, by which communications are intercepted and by re-transmitting the whole or a part of the intercepted data, the attacker passes himself off as a legitimate communicator, Version Rollback Attack, by which an older version having security problem is intentionally fallen back, and Attack, by which IP addresses and URL are guessed by analyzing the transmitted data. With regard to SSL/TLS, countermeasures have been taken for various attacks described above. Even though attention should be paid to security mechanisms of some attacks (such as Key-exchange algorithm rollback attack and Dropping the change cipher spec message attack), those attacks can be avoided by improving implementation and operation practice. Therefore, SSL/TLS can be considered to be s ecurity protocols having enough resistance against various existing attacks.

6.2.3 Security on implementation

Various problems may occur because problems on implementation are due to so-called bugs. Since SSL/TLS performs authentication by using a public key certificate, there are some cases where complexity of mechanism and insufficient comprehension of those who implement the system can be the cause of bugs. Because the session key is generated on the basis of random numbers, the attacks aimed at the imperfection of pseudorandom number generation program have been reported. With regard to the security holes associated with implementation, attacks can be avoided by using the latest version software with improved provision for bugs and modified programs (patch).

6.2.4 Security in operation

With regard to SSL/TLS, parameters set at the time of operation reside in the server and the client side. As objects of investigation, mod_ssl was used as the server, and Web browser (Netscape Navigator 4.6x, 5.5) was used as the client. The investigation revealed that the files to store keys and certificates, lifetime of the session key, random number generation, algorithm of used cipher, and the display status of alarm messages are settable. Therefore, it is required to fully understand the meaning of those parameters, thus setting them properly. Otherwise security holes may be created. To be specific, the files to store keys and certificates should be administered under a strict access control, the lifetime of the session key should be short enough not to allow the targeted ciphertext samples to be collected, random number generation should be made using the method with high random ratio, a safe cipher adopting the algorithm with the key long enough (128 bits or longer) should be used, and alarm messages should be set to be displayed to the greatest extent possible. Operators or users are responsible for proper setting of those

234 CRYPTREC 2001

parameters. In particular, since SSL/TLS is used for Web browser, it must be noted that the targets are general users with insufficient knowledge on security. By properly setting those parameters, creation of security holes in operation can be avoided.

6.2.5 Comparison of SSL/TLS

A major difference between SSL and TLS is that they have different keys or default value generation methods, different calculation methods of MAC to verify data integrity, and different cipher algorithms to be supported. With regard to keys, default values, and MAC calculation, whereas unique keyed hash processing is used in SSL, HMAC specified in RFC2014 is used in TLS. It is not that the calculation method of SSL has a problem, but that in TLS, basis of security is more clearly defined by using standard HMAC where security equivalent to the hash function is used. As for cipher algorithms (schemes), SSL uses Fortezza unique to Netscape, while TLS does not support it. In addition, in TLS alert messages have been detailed, thus allowing easy identification of the cause of troubles. Security of the signature structure was questioned in SSL, whereas in TLS the signature structure was slightly modified. In addition, while SSL adopts over-spec signature processing, TLS adopts standard light-weighted signature scheme.

TLS clarified the basis of security with regard to keys, default values, and MAC generation, and made slight modification to the signature structure, which may present slight differences in security with SSL. However, SSL can also be considered to maintain a sufficient security level.

6.2.6 Expansi on work of TLS

SSL has not been revised since 1997, whereas expansion work by IETF has been carried out with TLS. The details of the work are roughly classified into A) compliance with wireless/mobile environment, B) addition of new cipher algorithms, C) addition of variation of authentication/ method, and D) expansion of protocols. The major purpose of these efforts is not to improve the security of TLS maintained at present, but to add the functions (improvement) on the assumption that it may be used in various environments. Specifications of TLS are to be submitted to IESG as Draft Standard in June 2002.

6.2.7 General descriptions

Considering the results from the investigation mentioned above, it is permissibly said that the cryptographic schemes of SSL/TLS protocols are resistant to existing attacks. Although minor care is required to employ and make good use of them, their security can be ensured by taking appropriate actions, for example, the latest software, which existing bugs have been fixed, is used and appropriate parameters are set. At present, TLS is under enhancement aiming at addition of new features. Since any new security holes may be detected

235 CRYPTREC 2001

as the enhancement work proceeds, it is required that special attention be paid to the future TLS trend and its security be continuously investigated and discussed. For more information, refer to SSL Investigation Report on CD-ROM supplied with this publication.

6.3 Evaluation of cryptographic technique used in SSL/TLS

6.3.1 Investigation on vulnerability in key sharing and electronic signature schemes using RSA (1024 and 2048)

In this section, the evaluation results of the security of the key sharing and electronic signature schemes used in SSL and TLS are described. Security evaluation was performed focusing on the abstracted expression of the key sharing and electronic signature schemes. In this protocol expression, no data expression (for example, what do the bits followed by a header indicate) is included. In the evaluation process, it was mainly discussed whether the use of the protocol might induce fraudulent activities, for example, causing information to leak or electronic signature to be forged without decryption. The result demonstrated that no problem was found in the evaluated protocols.

In Section 6.3.1.1, the key sharing and electronic signature schemes using RSA ciphers in SSL 3.0[15] and TLS, which are commonly used protocols, are described. In Section 6.3.1.2, it is described whether the use of these schemes in protocols is secure or not. Finally, Section 6.3.1.3 summarizes the conclusion of evaluation.

6.3.1.1 Key-sharing and electronic signature schemes using RSA ciphers

This section outlines the key sharing and electronic signature schemes using RSA for each of SSL3.0 and TLS1.0. Secret information called “pre-master secret” is shared based on the key-sharing scheme in the protocol to generate:

• Secret key for common key cipher used in communication path encryption (SSL3.0, TLS1.0) • Key for MAC generation and verification to ensure data integrity (TLS1.0) n Key sharing scheme using RSA: The same key-sharing scheme has been implemented in SSL3.0 and TLS1.0 protocols. The protocols are described below.

1. Server ® client The server sends the public key for encryption of an RSA cipher and its certificate to the client. They are sent by either of two methods. (a) The key for signature verification and its certificate are sent (in the Certificate message) and then the public key for encryption of an RSA cipher and the signature attached to the key information

236 CRYPTREC 2001

(the certificated key is used in the signature) are sent (in the ServerKeyExchange message). (b) The public key for encryption of an RSA cipher and its certificate are sent (in the Certificate message). In this case, the signature attached to the key information includes: The arrangement of; • number of random numbers generated by the client, • number of random numbers generated by the server, and • public key for RSA (number of modulus n and multiplier e) multiplied by the MD5 or SHA-1 function and followed by the signature. 2. Client In either case, the client uses the public key certificate (and the server signature) to validate the public key for encryption of the signature attached to the key information. 3. Client ® server If the client passes the key validation, combines the protocol version (two bytes, 0x30 for SSL3.0, 0x31 for TLS1.0) with the 46-byte random number generated by itself to form a 48-byte premaster secret. It uses an RSA cipher to encrypt the formed secret with a server public key and then sends it to the server (in the ClientKeyExchange message). 4. Server The server decrypts the encrypted message sent to obtain the premaster secret.

In the way mentioned above, the server and the client share the same premaster secret. n Signature using RSA: The RSA signature scheme is used in SSL3.0 and TLS1.0 under various situations, although no difference in scheme is found between two protocols as follows:

1. Certificate of public key for signature verification (for the server by a CA()) • Certificate message (server ® client) • RSA signature by a CA for authenticating the public key for server signature verification - The client verifies a CA signature with the CA’s (or CAs’) public key. - If verification is passed, the public key for server signature verification is authenticated. 2. Certificate of public key for encryption (for the server by a CA) • Certificate message (server ® client) • RSA signature by a CA for authenticating the public key for encryption - The client verifies a CA signature with the CA’s (or CAs’) public key. - If verification is passed, the public key for encryption is authenticated. 3. Certificate of public key for encryption (by a server) • ServerKeyExchange message (server ® client)

237 CRYPTREC 2001

• RSA signature by the server for authenticating the public key for encryption Underscored signature data is shown in the previous section 1. - The client verifies the signature (certified by a CA (CAs) in advance) with the public key for server signature verification - If verification is passed, the public key for encryption is authenticated. 4. Certificate of public key for signature verification (for the client by a CA) • Certificate message (client ® server, the message is scarcely sent) • RSA signature by a CA for authenticating the public key for client signature verification - The server verifies a CA signature with the CA’s (or CAs’) public key. - If verification is passed, the public key for client signature verification is authenticated. 5. Signature message for client authentication (by the client) • Certificate Verify message (client ® server, the message is scarcely sent) • RSA signature by the client for authenticating the client Data, to which the signature is attached, is the combination of the transferred data multiplied by the MD5 or SHA-1 function - The server verifies the signature with the public key for client signature verification (certified by a CA (or CAs) in advance). - If verification is passed, the client is authenticated.

6.3.1.2 Security of key sharing and electronic signature schemes using RSA ciphers

This section describes the security of the key sharing and electronic signature schemes used in SSL3.0 and TLS1.0. n Security of the key sharing scheme using RSA ciphers: As known from the previous section, the key-sharing scheme itself is the encryption communications scheme for SSA ciphers. For that reason, the security of the scheme depends on that of RSA ciphers. This topic is not evaluated in the report because of being not requested.

Assuming that encryption communications using RSA ciphers is secure, if correctly used, the factors, which may compromise the security in protocols, are:

1. Forgeability of public key certificate for signature verification An offender may pass oneself off as the owner of the public key, which has been authenticated in the certificate 2. Forgeability of public key certificate for encryption An offender may pass oneself off as the owner of the public key, which has been authenticated in the certificate 3. Possible guess of the secret key corresponding to the public key (for encryption and signature

238 CRYPTREC 2001

verification) certificated by the certificate An offender may pass oneself off as the owner of the public key authenticated by the certificate 4. Signature forgeability (in the ServerKeyExchange or CertificateVerify message) An offender may pass oneself off as the owner of the secret key for signature generation 5. Forgeability of foreseeability of data used for the premaster secret An offender may obtain the information on future communications.

Each of the cases listed above are described in detail below.

1. Forgeability of public key certificate for signature verification The public key certificate consists of a simple sequence of CA signatures (up to Root CA). If all the sequence of CA signatures cannot be forged, the same may apply to the certificate. The possibility of forging depends on the signature scheme used and the stability of the key used by the CA in appending its signature. Most of CAs use the DSA(DSS) or RSA signature scheme. Since it was assumed that these signature schemes were secure in this evaluation, all we needed to consider was the possibility of signature forging due to a revealed key. Note that it was also assumed that no secret key could be guessed from the public key or signature (the same applies to the following sentences .) For an offender to forge signatures under this assumption through the revealed key, he/she must obtain the CA’s secret key. The CA’s secret key used in writing the signature could not be known by others in the protocol (and the PKI system used by it) when the system is operated correctly. In addition, information containing the secret key (encrypted information using any ciphers) is not open to public on the communication path. For this reason, the CA’s secret key could not be revealed. Thus, the public key certificate for signature verification may not be forged.

2. Forgeability of public key certificate for encryption The same mentioned above applies to the public key certificate for encryption.

3. Possible guess of the secret key corresponding to the public key (for encryption and signature verification) authenticated by the certificate In this evaluation, it was assumed that the server or client created a pair of encryption keys correctly. The server’s or client’s secret key could not be known by others in the protocol when the system is operated correctly. In addition, information containing the secret key (encrypted information using any ciphers) is not open to public on the communications path. According to the assumption, the secret key could not be revealed based on a pair of the public key and signature or a pair of the public key and encrypted sentence. Thus, the secret key corresponding to the public key to be certificated may not be forged.

4. Signature forgeability (in the ServerKeyExchange or CertificateVerify message)

239 CRYPTREC 2001

Even if the signature can be forged, no correct answer is given to the subsequent communications without obtaining the premaster secret. This means that disguise is revealed. It is preferable that such types of illicit acts are not achieved to prevent communications from being disturbed. According to the assumptions mentioned above, if the master secret and the secret key of the signature cannot be obtained, no signature is forged. In this case, an offender may not also obtain the secret key of the signature.

5. Forgeability or foreseeability of data used for the premaster secret In this evaluation, it was assumed that the cryptographic techniques used are secure and data used as the premaster secret is of random type. In addition, since all information containing the premaster secret (when the DH scheme is used as the key sharing scheme, information on how to build it) is encrypted in the protocol, it may not be guessed. According to the assumption, the information cannot be obtained from encrypted data as well. Thus, data used as the master secret may not be fo rged or foreseen. n Security of the signature scheme using RSA ciphers: As known from the previous section, the whole signature scheme corresponds to the encryption scheme of RSA ciphers. This means that the security of the signature scheme depends on that of RSA ciphers. This topic is not described because it is excluded from our request.

In this evaluation, it was assumed that the correct use of RSA ciphers for the signature scheme ensured its security. As described in 6.3.1.1, the RSA signature scheme may be used in:

1. Public key certificate for signature verification (for the server by a CA) 2. Public key certificate for encryption (for the server by a CA) 3. Public key certificate for encryption (by the server) 4. Public key certificate for encryption (for the client by a CA) 5. Signature message for client authentication (by the client)

All we need is to consider the forgeability of signatures. According to the description in the previous section (the signature scheme and the security of the secret key), no signature can be forged for the certificates and message listed in 1-5.

6.3.1.3 Conclusi on

Since the key sharing and signature schemes using RSA ciphers in SSL3.0 and TLS1.0 have employed a combination of simple techniques and the simplest notions, no room for inherent security holes may be left in them. On the other hand, several chances for these security holes have been unsolved, for example, in what data format should be used at implementation, how to generate random numbers, and how to return error messages by the server. In particular, entities (for example, CAs) other than the server, who participate

240 CRYPTREC 2001

in the system, should be selected carefully (based on their techniques used).

6.3.2 DES (40-/56-bit key DES, 168-bit key Triple DES)

6.3.2.1 Technical overview

DES (Data Encryption Standard) is a symmetric-key block cipher authorized as Federal Information Processing Standards (FIPS) in 1977 [14]. Triple DES [19] is a combination of DES proposed by Tuchman of IBM in 1979, in which the strength has been enhanced by repeating DES three times. At present, Triple DES is defined with seven modes of operation as Triple Data Encryption Algorithm (TDEA) in U.S. American National Standards Institute (ANSI) X9.52 and its incorporation into FIPS (FIPS46-3) has done.

6.3.2.2 Technical specifications

Since Triple DES has such a structure that DES, a Feistel type of cipher, is repeated three times, it can be classified into the same category of symmetric-key block cipher of 64-bit block length as DES. Assuming that a plaintext is P, a ciphertext is C, a key is K, and encryption and decryption using the key K are EK and

DK, the encryption and decryption processes can be expressed as follows, respectively:

Encryption C = EK3 (DK2(EK1(P)))

Decryption P = DK1(EK2(DK3(C)))

Where, depending on how to combine the keys K1, K2, and K3, any of three options is selected [1]:

(1) K1, K2, and K3 are independent

(2) K1 and K2 are independent and K1 = K3

(3) K1 = K2 = K3

Specifically, in the option (3), the use of three same keys ensures compatibility with “Single DES”. Generally, the option (1) is referred to as “3-key Triple DES” and the option (2) as “2-key Triple DES”. Since the key length of DES is 56 bits, the lengths of the keys in the options (1) - (3) are 168 bits, 112 bits, and 56 bits, respectively.

241 CRYPTREC 2001

The Triple DES mode of operation includes seven operation modes defined in ANSI X 9.52: the four operation modes (TECB, TCBC, TCFB, and TOFB) extended based on 64-bit block cipher modes (ECB, CBC, CFB, and OFB) defined in ISO 8372, and others (TCBC-I, TCFB-P, and TOFB-I) [1].

6.3.2.3 Others

Initially, there was fear that the key length of DES, 56 bits, was too short to ensure the security against exhaustive key search [21]. To resolve this problem, an attempt that key length was extended using cascade-connected DESs resulted in Triple DES. To avoid meet-in-the-middle attacks [4], DES was repeated three times but not two times. Actually, after 20 years when DES was proposed, DES was successfully broken for the first time at DES Challenge-I in 1997, hosted by RSA Laboratories, and was broken in about 22 hours at DES Challenge-III [22]. In U.S.A., Triple DES has been incorporated into FIPS and it is expected that not only the U.S. Government agencies but also the general DES users are increasingly migrating to Triple DES.

6.3.2.4 Evaluation results n Security: The main results from security evaluation on Triple DES ((1) 3-key triple DES, (2) 2-key Triple DES, and (3) Single DES) are shown in Table 6.1. It has been reported that Single DES can be efficiently broken (in the meaning of theoretical) compare d with the exhaustive key search by differential cryptanalysis and linear cryptanalysis which are typical short cut methods. 256 computational complexity required to break Single DES by exhaustive key search could be broken in about 22 hours at DES Challenge-III [22] and it is permissibly considered that it could be practically broken. Although 2-key and 3-key Triple DES may be secure against differential cryptanalysis and linear cryptanalysis which are typical short cut methods, it has been reported that they can be more efficiently broken by the meet-in-the-middle attack, which is aware that they were combination of ciphers, than by exhaustive key search (in the meaning of theoretical). In particular, 2-key Triple DES can be theoretically broken in 257 computational complexity (with 256 chosen plaintexts). Thus, it is permissibly said that 2-key Triple DES can be practically broken because the number of calculation complexity is two times that of the exhaustive key search.

242 CRYPTREC 2001

Table 6.1 Principal evaluation results of Triple DES (computational complexity required for attacks (1))

Single DES Triple DES (2-key) Triple DES (3-key) · Brute Force Method Exhaustive key search 256 2112 2168 Merkle-Hellman 257 2112 Meet-in-the middle attack (Chosen plaintexts 256) (Chosen plaintexts 256) [Attack by Lucks] [---] [2108.2] Oorshot-Wiener --- 2120-log2N --- Known plaintext attack Known plaintexts N · Short Cut Method Differential cryptanalysis 237 Maximum differential (the same as the left) (Chosen plaintexts 247) characteristics probability 2-162.3 or lower (2) Linear cryptanalysis 242 Maximum linear (the same as the left) (Chosen plaintexts 243) characteristics probability 2-134.7 or lower (3) Related-key attacks (4) ------256 to 272 (Chosen plaintext 1) (Chosen key pair 1)

(1) Number of Triple DES (or DES) encryption or decryption required for attacks (2) Assuming that triple DES is 48-round DES, the upper bound obtained from the maximum differential characteristics probability 2-54.1 of 16-round DES (3) Assuming that triple DES is 48-round DES, the upper bound obtained from the maximum linear characteristics probability 2-44.9 of 16-round DES (4) It is considered that related-key attacks may practically give no threat because the conditions, under which an attack can be established, are stringently restricted.

On the other hand, 3-key Triple DES can be theoretically broken in about 2108.2 computational complexity (with 256 chosen plaintexts). It, however, may be considered that 3-key Triple DES will be practically secure for the time being from the standpoint of current performance of computers. Therefore, it is concluded that 3-key Triple DES can be used in e-Government applications with no problem for the time being.

These topics are described below in detail.

(1) Security against Brute Force Method It is considered that Triple DES (2-key Triple DES and 3-key Triple DES) is secure enough against the exhaust key search at present. It has been reported that 56-bit key (Single) DES was successfully broken for the first time at DES Challenge-I in 1997, hosted by RSA Laboratories, and was broken in about 22 hours at DES Challenge-III in 1999 [22]. Thus, at present, it is permissibly considered that DES is secure no longer. On the other hand, it has been pointed out that, under a certain condition, the security level is not effectively enhanced regardless of extension in the key length because Triple DES is a combination of ciphers.

As a typical example, with respect to the chosen plaintext attack proposed by Merkle and Hellman, a

243 CRYPTREC 2001

large amount of computational complexity can be reduced compared to that by exhaustive key search; the number of computational complexity can be reduced to 257 for 2-key Triple DES (2112 by exhaustive key search) and 2112 for 3-key Triple DES (2168 by exhaustive key search) [13]. Note that 255 chosen plaintexts are needed in this attack with 50 % of success probability and 4.03 x 1010 Gbits of external storage is required for storing pairs of plaintexts and keys. Besides, it is difficult to obtain necessary information via telecommunications lines. Thus, at present, this attack has lower possibility of giving a threat [10]. Lucks proposed the improved attack, in which the number of computational complexity by chosen plaintext attack proposed by Merkle and Hellman is reduced, and reported that 3-key Triple DES could be broken in approximately 2108 computational complexity. Note that this Lucks’ attack may also contribute less to attack of Triple DES because of its requirement of a large amount of computational complexity and storage.

Oorschot and Wiener proposed known plaintext attack against 2-key Triple DES, which is extended from chosen plaintext attacks proposed by Merkle and Hellman. According to them, 2-key Triple DES can be broken in 2120-log2N computational complexity if 120-N bit of storage for the number of known plaintexts N is installed [20]. Note that it is predicted that it will take several decades until the attack method gives a practical threat [11].

(2) Security against short cut methods Typical short cut methods are the differential cryptanalysis and linear cryptanalysis. It is pointed out that DES can be broken by the differential cryptanalysis in 237 computational complexity with 247 chosen plaintexts [3]. And, by linear cryptanalysis, DES can be broken in 242 computational complexity with 243 known plaintexts [12]. For the reasons, assuming that Triple DES is 48-round DES, the maximum differential characteristics probability and the maximum linear characteristics probability of Triple DES estimated from those of DES (2-54.1 and 2-44.9 with 16 rounds, respectively), which have already been obtained, are considerably small. This means that since a huge amount of chosen/known plaintexts are required to make successful attacks, the candidate keys cannot be effectively identified even if all of 264 pairs of plaintexts and ciphertexts are created for 64-bit block ciphers.

It has also been reported that 3-key Triple DES can be broken by related-key attacks in less computational complexity than those for chosen plaintext attacks by Merkle and Hellman [8]. Concretely, using one pair of chosen plaintext and ciphertext and one key pair between which a certain relationship is established, DES can be broken in 256 to 272 computational complexity. Note that this kind of attacks cannot be applied to 2-key triple DES, and the environment, which the attacks can target, is very limited, and resulting in less possibility of threat. n Software Implementation Evaluation:

244 CRYPTREC 2001

The evaluation results of Triple DES software implementation by CRYPTREC 2000 are shown in Tables 6.2 and 6.3. As known from these tables, the processing speed of the Triple DES data randomization part achieves up to 854 cycles/block in the PC environment (Pentium III). After that, it has been reported that it was improved up to 763 cycles/block in the almost same PC environment (Pentium III) as that in CRYPTREC2000 by taking various speed-up techniques at SCIS2002 [2].

Table 6.2 Data randomization part speed measurement results (unit: cycles /block)

Pentium III (650MHz) Language Assembler Program size 44385 bytes (including encryption/decryption/key scheduling) Compiler option Encryption (Fastest speed/Average) Decryption (Fastest speed/Average) First round 854 / 856 854 / 856 Second round 854 / 857 854 / 856 Third round 854 / 856 854 / 857

Table 6.3 Key schedule part + data randomization part speed measurement results (unit: cycles /block)

Pentium III (650MHz) Language Assembler Program size 44679 bytes (including encryption/decryption/key scheduling) Compiler option Encryption (Fastest speed/Average) Decryption (Fastest speed/Average) First round 1963 / 1967 1971 / 1975 Second round 1967 / 1971 1971 / 1975 Third round 1963 / 1967 1971 / 1975 n Hardware Implementation Evaluation:

As for the hardware implementations, Ichikawa et al. has reported the evaluation results of ASIC high-speed implementation of Triple DES [6]. The results are shown below.

Hardware: ASIC (from Mitsubishi, 0.35 mm rule ASIC library) Language: Verilog-HDL Condition: Worst case

Gate size (converted into NAND gate): 148147 gates (Encryption/decipher parts: 124888 / key schedule

245 CRYPTREC 2001

part: 23207) Throughput: 407.4 [Mbps]

n Security of DES in SSL/TLS : With respect to SSL/TLS, three types DES, 40-bit key (Single) DES, 56-bit key (Single) DES, and 168-bit key Triple DES (3-key Triple DES), are used for data concealment. Note that 40-bit key (Single) DES has been developed based on 56-bit key (Single) DES by reducing the key length. Both of them use the CBC mode for block cipher operation mode.

First, at present, it cannot be said that Single DES is sufficiently secure against exhaustive key search as described in 6.3.2. For this reason, with respect to SSL/TLS, 40-bit key (Single) DES and 56-bitkey (Single) DES should not be used from the standpoint of security.

Second, in selecting triple DES for bulk encryption in SSL/TLS, special care should be taken when 232 or more blocks are encrypted with the same session key. In SSL/TLS, since Triple DES is used in the CBC mode and thus the possibility becomes higher that one bit of plaintext information may be guessed from the ciphertext by ciphertext matching attack when 232 or more blocks are encrypted with the same session key. To avoid this problem, session keys should be appropriately updated before encrypting 232 blocks. Note that 232 blocks of 64-bit block is around 32G bytes.

As described in 6.3.2, 168-bit key (3-key) Triple DES can be theoretically broken using 256 pairs of chosen plaintexts and ciphertexts. For this reason, special attention should be paid when 256 or more blocks are encrypted with the same session key. Note that this kind of attacks must perform a large amount of computational complexity (2108 computational complexity) and the 256 blocks of 64-bit block length is 512 Pbytes, a huge amount of data. Thus, this kind of attacks may be neglected.

6.3.3 RC2 (40,128)

6.3.3.1 Technical overview

RC2 is a set of symmetric-key block ciphers with message length of 64 bits designed by of RSA Data Security, Inc.,*1 in 1989.

6.3.3.2 Technical specifications

The RC2 specifications were published as Internet Draft [18] in 1997. The algorithm consists of encryption and decryption processes, each comprising the key schedule part and the data randomization part.

*1 The current RSA Security, Inc.

246 CRYPTREC 2001

The key schedule part uses a secret key with any length of 128 bytes or less*2 as an input to output 64 16-bit partial keys. The data randomization part uses the expanded key output from the key schedule part and a 64-bit plaintext as its inputs to output 64-bit ciphertexts. The data randomization part consists of two types of round functions, MIX and MASH, and the process proceeds in the order of five rounds of MIX, one round of MASH, six rounds of MIX, one round of MASH, and five rounds of MIX. 64 partial keys are used in each of MIX rounds in a group of four keys.

6.3.3.3 Result n Security: Against RC2, there exists an attack method using differential cryptanalysis, which is more efficient than exhaustive key search if the key is longer than 60 bits [16]. With respect to [9], differential characteristic paths with probability 2-58 were found in 15 rounds of MIX and two rounds of MASH, and it is estimated from [16] that its differential probability is 2-56.7. To make the successful attack, the required number of chosen plaintext/ciphertext pairs is 260 and the required number of computation complexity is around 260 RC2 encryption or decryption process.

With respect to linear cryptanalysis, linear characteristic paths with probability 2-15 were found in 3 rounds of MIX, and it is estimated from [16] that its linear probability is 210.3. However, it has not led to break full round RC2 yet, and it is considered that linear cryptanalysis cannot be easily applied to RC2 since cyclic shift operations and arithmetic additive operations effectively work in RC2 [16, 17].

With respect to higher order differential attack, the algebraic degree of output of r rounds was examined under the condition that three blocks out of a 64-bit plaintext (which consists of 4 blocks of 16 bits) are fixed to a constant and the remaining one block is a variable [16]. The result showed that the algebraic degree of each of output bits reaches 16, which is the largest algebraic degree of 16-variable function, in three or more rounds of MIX. In addition, RC2 consists of 16 rounds of MIX and two rounds of MASH. Thus, it seems difficult to apply higher order differential attack to RC2.

Although RC2 has resistance to higher order differential attack and linear cryptanalysis, it is theoretically vulnerable against differential cryptanalysis. For this vulnerability, it is not recommended that RC2 be employed in e-Government cryptographic applications requiring sufficient strength in any use. n RC2 security in SSL/TLS: RC2 is used in SSL/TLS for data concealment. It is used in the CBC block encryption mode. In SSL ver.2, either 40 bits or 128 bits can be selected for the key length, while in SSL ver.3 and TLS ver.1, only 40 bits can be selected.

Special attention should be paid that, when RC2 is selected in SSL/TLS bulk encryption, a 40-bit key must

*2 In SSL ver. 2, either 40-bit key or 128-bit key can be selected, while in TLS ver.1, only 40-bit key can be selected.

247 CRYPTREC 2001

not be used. This means that RC2 should not be selected in SSL ver.3 and TLS ver.1. The selection of 40-bit key should not be recommended with respect of security, since 40-bit key RC2 can be broken by exhaustive key search within several hours even in the practical computation environment.

Next, care should be taken when 232 or more blocks are encrypted with the same session key. Since RC2, with 64-bit block length, is used in the CBC mode in SSL and TLS, one bit information of plaintext may be revealed from the ciphertexts by the ciphertext matching attack with high probability. To avoid this problem, session keys should be appropriately updated before encrypting 232 blocks. Note that 232 blocks of 64-bit block is around 32G bytes.

Further, attention should also be paid when 260 or more blocks are encrypted with the same session key. As described in the section “Security”, all the expansion keys of RC2 can be revealed from 260 chosen plaintext/ciphertext pairs by using differential cryptanalysis. For this reason, if 260 or more blocks are encrypted with the same session key, differential cryptanalysis may be applied. This problem can be solved with appropriate update of the session keys, since 260 blocks of 64-bit block is around 8E bytes.

Finally, in SSL ver.3 and TLS ver.1, RC2 may be left only for ensuring compatibility with RC2 with key length of 40 bits, which was excluded from export restrictions, in SSL ver.2. As described in the section “Security”, since there exists an attack method against 128-bit RC2, which is more efficient than exhaustive key search, it cannot be said RC2 is an ideal cipher. Since RC2 with key length of 128 bits is only available in SSL ver.2 and it is theoretically vulnerable against differential cryptanalysis, there is little reason to recommend it to e-Government applications strongly.

6.3.4 RC4 (40, 128) and Arcfour (128)

At present, RC4 is under discussion by the CRYPTREC Evaluation Committee.

References [1] American National Standards Institute, Triple Data Encryption Algorithm Modes of Operation (X9.52-1998)}, 1998. [2] K. Aoki, Implementation optimization of Triple DES on Pentium III, 2002 Cipher and Information Security , SCIS2002, 12C-2, 2002. [3] E. Biham and A. Shamir, Differential cryptanalysis of the full 16-round DES, In Advances in Cryptology -Proceedings of CRYPTO92, Vol. 740 of LNCS, pp. 487-496. Springer-Verlag, 1993. [4] W. Diffie and M. E. Hellman, Exhaustive cryptanalysis of the NBS data encryption standard, Computer, Vol. 10, No. 6, pp. 74-84, June 1977. [5] S. Fluhrer, I. Mantin, and A. Shamir, Weaknesses in the key scheduling algorithm of, In Selected Areas in Cryptography 8th Annual International Workshop, SAC 2001, Vol. 2259 of Lecture Notes in

248 CRYPTREC 2001

Computer Science, pp. 1-24. Springer-Verlag, 2001. [6] T. Ichikawa, T. Kasuya, and M. Matsui, Hardware evaluation of the AES finalists, In The Third AES Candidate Conference, pp. 279-285. the National Institute of Standards and Techonlogy, Gaithersburg, MD, April 13-14 2000. [7] IETF, The TLS Protocol Version 1.0, RFC2246, 1999. http://www.ietf.org/rfc/rfc2246.txt. [8] J. Kelsey, B. Schneier, and D. Wagner, Key-schedule cryptanalysis of IDEA, G-DES, GOST, SAFER, and triple DES, In Advances in Cryptology CRYPTO96, Vol. 1109 of LNCS, pp. 237-251. Springer-Verlag, 1996. [9] L. R. Knudsen, V. Rijmen, R. L. Rivest, and M. J. B. Robshaw, On the design and security of , In Fast Software Encryption, 5th International Workshop (FSE '98), Vol. 1372 of LNCS, pp. 206-221. Springer-Verlag, 1998. [10] K. Kusuda and T. Matsumoto, A Strength Evaluation of the Data Encryption Standard, No. 97-E-5 in IMES Discussion Paper. Institute for Monetary and Economic Studies, Bank of Japan, 1997. [11] S. Lucks, Attacking triple DES, In proceedings of Fast Software Encryption '98, Vol. 1372 of LNCS, pp. 239-253, 1998. [12] M. Matsui, Linear cryptanalysis method for DES cipher, In Advances in Cryptology -Proceedings of EUROCRYPT'93, Vol. 765 of LNCS, pp. 386-397. Springer-Verlag, 1994. [13] R. C. Merkle and M. Hellman, On the security of multiple encryption, Communications of the ACM, Vol. 24, No. 7, pp. 465-467, 1981. [14] National Institute of Standards and Technology, Data Encryption Standard (Federal Information Processing Standards Publication 46-3), 1999. [15] Netscape Communications, SSL 3.0 SPECIFICATION, 1996. http://home.netscape.com/ eng/ssl3/draft302.txt. [16] RC2 External evaluator 1, Analysis of RC2, CRYPTREC Evaluation Committee 2001, External evaluation report, 2002. [17] RC2 External evaluator 2, Report on detailed evaluation of RC2, CRYPTREC Evaluation Committee 2001 External evaluation report, 2002. [18] R. L. Rivest, A description of the RC2 TM encryption algorithm, RFC 2268, 1997. [19] W. Tuchman, Hellman presents no shortcut solutions to DES, IEEE Spectrum, Vol. 16, No. 7, pp. 40-41, 1979. [20] P. C. van Oorschot and M. J. Wiener, A known plaintext attack on two-key triple encryption, In Advanced in Cryptology -Proceedings of EUROCRYPT'90, Vol. 473 of LNCS, pp. 318-325. Springer-Verlag, 1990. [21] Taniguchi, Ohta, and Okubo, Recent trend toward standardization surrounding Triple DES, Financial Research Vol. 18, No. 1, Japan Banking Financial Research Institute, 1999.

249 CRYPTREC 2001

[22] Une and Ohta, Current status and issues surrounding symmetric cipher — from DES to AES, Financial Research Vol. 18, No. 2, Japan Banking Financial Research Institute, 1999.

250 CRYPTREC 2001

7 Intellectual Property Information, Licensing Policy and Reference List of Cryptosystem Scheduled to be Evaluated in 2002

In the contents of this chapter, the offered cryptosystems are all excerpts from the application documents submitted by the applicants as of October, 2001 except for those whose correction was requested by applicant and accepted. Therefore, the personnel in charge of receiving inquiry, etc. may have changed.

In addition, for the cryptographic technique that needs to be evaluated, the information possibly helpful for acquisition of cryptographic specification, etc. is covered.

If it is written with no special description, the following patents and trade marks are to be submitted to the Patent Office in Japan.

7.1 Cryptosystem in Monitoring State

7.1.1 Asymmetric Key Cryptographic Techniques

7.1.1.1 DSA

Specification As stipulated in ANSI X9.30 Part 1 (obtainable via http://www.x9.org/) Reference URL http://csrc.nist.gov/encryption/tkdigsigs.html

7.1.1.2 ECDSA (ANSI X9.62)

Specification As stipulated in ANSI X9.62 (obtainable via http://www.x9.org/)

7.1.1.3 ECDSA (Elliptic Curve Digital Signature Algorithm) in SEC1

URL for submitted cryptographic technique

Japanese text http://www.labs.fujitsu.com/theme/crypto/ public_key2001.html English text http://www.labs.fujitsu.com/theme/crypto/ public_key2001_e.html

Date and the name of the conference where the submission was publicized

SECG (Standards for Efficient Cryptography Group), "SECG standards" open on Web page via http://www.secg.org/ as of September 20, 2000

251 CRYPTREC 2001

Contact person for supply

Name Tatsuji Shimoe Division/assignment Director, Enterprise Management Products Div. Development Dept. II Affiliation Fujitsu Ltd. Address TECH Bldg. 3-9-18, Shin-Yokohama, Kohoku-ku, Yokohama-shi, Kanagawa 222-0033, Japan TEL +81-45-474-1925 FAX +81-45-474-1953 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

See SECG member patent letters (accessible at the following address). http://www.secg.org/collateral/certicom_secg_patent.pdf

Copyright

License to copy the document is granted provided it is identified as "Standards for Efficient Cryptography (SEC)", in all material mentioning or referencing it.

All related patents

Please refer to SECG Patent Policy : http://www.secg.org/patent_policy.htm

License policy of usage for the electronic government in Japan

Fujitsu Limited has filed patent applications on the technique used in this application. Fujitsu Limited will license any resulting patent on reasonable and non-discriminatory terms and conditions.

7.1.1.4 RSA-PKCS#1 v1.5

Specification PKCS#1 RSA Cryptography Standard (Ver.2.0) Reference URL http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/ index.html

7.1.1.5 RSA Public-Key Cryptosystem with Probabilistic Signature Scheme (RSA-PSS)

URL for submitted cryptographic technique

252 CRYPTREC 2001

Japanese text http://www.rsasecurity.com/rsalabs/submissions/index.html English text http://www.rsasecurity.com/rsalabs/submissions/index.html

Date and the name of the conference where the submission was publicized

Phillip Rogaway, "PSS/PSS-R (an encoding method for RSA or RW signatures)", IEEE P1363 Working Group, August 1998

Contact person for supply

Name Eiji Arai Division/assignment Senior Manager, Developer Sales Dept. Affiliation RSA Security Japan, Ltd. Address Tokyo Ginko Kyokai Bldg. 13F, 1-3-1 Marunouchi, Chiyoda-ku, Tokyo 100-0005, Japan TEL +81-3-5222-5210 FAX +81-3-5222-5270 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

Copyright RSA Security owns copyright on sample codes in this submission.

All related patents License policy of usage for the electronic government in Japan

RSA Security have no patent right on RSA-PSS.

7.1.1.6 RSA Public-Key Cryptosystem with Optimal Asymmetric Encryption Padding (RSA-OAEP)

URL for submitted cryptographic technique

Japanese text http://www.rsasecurity.com/rsalabs/submissions/index.html English text http://www.rsasecurity.com/rsalabs/submissions/index.html

Date and the name of the conference where the submission was publicized

M. Bellare and P. Rogaway, "Optimal asymmetric encryption – How to encrypt with RSA" Eurocrypt94, August, 1994

253 CRYPTREC 2001

Contact person for supply

Name Eiji Arai Division/assignment Senior Manager, Developer Sales Dept. Affiliation RSA Security Japan, Ltd. Address Tokyo Ginko Kyokai Bldg. 13F, 1-3-1 Marunouchi, Chiyoda-ku, Tokyo 100-0005, Japan TEL +81-3-5222-5210 FAX +81-3-5222-5270 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

Copyright RSA Security owns copyright on sample codes in this submission.

All related patents License policy of usage for the electronic government in Japan

RSA Security have no patent right on RSA-OAEP.

7.1.1.7 DH

Specification As described in the following literature. W. Diffie and M. E. Hellman, "New Directions in Cryptography," IEEE Transactions on Information Theory, vol. IT-22, pp. 644-654, Nov. 1976, Or refer to 2.5.3.

7.1.1.8 ECDH (Elliptic Curve Diffie-Hellman Scheme) in SEC1

URL for submitted cryptographic technique

Japanese text http://www.labs.fujitsu.com/theme/crypto/ public_key2001.html English text http://www.labs.fujitsu.com/theme/crypto/ public_key2001_e.html

Date and the name of the conference where the submission was publicized

SECG (Standards for Efficient Cryptography Group), "SECG standards" open on Web page via http://www.secg.org/ as of September 20, 2000

254 CRYPTREC 2001

Contact person for supply

Name Tatsuji Shimoe Division/assignment Director, Enterprise Management Products Div. Development Dept. II Affiliation Fujitsu Ltd. Address TECH Bldg. 3-9-18, Shin-Yokohama, Kohoku-ku, Yokohama-shi, Kanagawa 222-0033, Japan TEL +81-45-474-1925 FAX +81-45-474-1953 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

Please refer to SECG member patent letters below. http://www.secg.org/collateral/certicom_secg_patent.pdf

Copyright License to copy the document is granted provided it is identified as "Standards for Efficient Cryptography (SEC)", in all material mentioning or referencing it.

All related patents

Please refer to SECG Patent Policy : http://www.secg.org/patent_policy.htm

License policy of usage for the electronic government in Japan

Fujitsu Limited has filed patent applications on the technique used in this application. Fujitsu Limited will license any resulting patent on reasonable and non-discriminatory terms and conditions.

7.1.2 Symmetric Key Cryptographic Techniques

7.1.2.1 CIPHERUNICORN-E

URL for submitted cryptographic technique

Japanese text http://www.hnes.co.jp/products/security/index.html English text http://www.hnes.co.jp/products/security/index-e.html

255 CRYPTREC 2001

Date and the name of the conference where the submission was publicized

NEC Corporation, "Registration number: 19, registration date: July 6, 1998, Algorithm Registration", ISO/IEC 9979 Data cryptographic techniques - Procedures for the registration of cryptographic algorithms, July 6, 1998 NEC Corporation, "A Secure Cipher Evaluated by Statistical Methods", SCIS'98-4.2.B(in Japanese), 1998 Symposium on Cryptography and Information Security, January 29, 1998

Contact person for supply

Name Security Technology Center Division/assignment Internet Software Division Affiliation NEC Corporation Address 2-11-5, Shibaura, Minato-ku, Tokyo 108-8557, Japan TEL +81-3-5476-1913 FAX +81-3-6576-1678 e-mail sec@isd..co.jp

Intellectual property and license All patents and intellectual properties regarding the submission

Application number H9-213-274 Title A recording medium that can be read by cryptographic equipment or by a computer storing a program for achieving cryptographic equipment (in Japanese) Date of application August 7, 1997 Copyrighted material CIPHERUNICORN-E program Trademark Registration number: 4221077

All related patents At this point in time, no prior related patents from other companies have been found in the official patent gazette.

License policy of usage for the electronic government in Japan

Free of charge except when purpose of use is for profit by private business or the like.

256 CRYPTREC 2001

7.1.2.2 Hierocrypt-L1

URL for submitted cryptographic technique

Japanese text http://www.toshiba.co.jp/rdc/security/hierocrypt English text http://www.toshiba.co.jp/rdc/security/hierocrypt

Date and the name of the conference where the submission was publicized

Kenji Ohkuma, "Security and Performance Evaluations for the block ciphers Hierocrypt-3 and Hierocrypt-L1" Technical report of IEICE ISEC2000-71 pp.71-100, September 29, 2000

Contact person for supply

Name Kenji Ohkuma Division/assignment Senior Research Scientist, Systems Laboratory, Corporate Research & Development Center Affiliation Toshiba Corporation Address 1, Komukai, Toshiba-cho, Saiwai-ku, Kawasaki-shi 212-8582, Japan TEL +81-44-549-2156 FAX +81-44-520-1841 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

1. Application number 2000-210484 Title Titled in Japanese Date of application March 6, 2001

2. Application number 2000-211686 Title Titled in Japanese Date of application July 12, 2000

3. Application number 2000-212175 Title Titled in Japanese Date of application July 13, 2000

4. Application number 2001-68742 Title Titled in Japanese

257 CRYPTREC 2001

Date of application June 30, 2001 copyright

All related patents

License condition is permitting no exclusive use or looser.

License policy of usage for the electronic government in Japan

License condition is permitting no exclusive use or looser.

7.1.2.3 MISTY1

URL for submitted cryptographic technique

Japanese text http://www.security.melco.co.jp/misty English text http://www.security.melco.co.jp/misty

Date and the name of the conference where the submission was publicized

Mitsuru Matsui, "Block Encryption Algorithm MISTY", ISEC Technical report of IEICE, July 22, 1996

Contact person for supply

Name Binji Komatsuda Division/assignment Deputy Manager, Information Security Consulting & Supporting Center, Information Systems and Group Affiliation Mitsubishi Electric Corporation Address Mitsubishi Electric Building, 2-2-3, Marunouchi, Chiyoda-ku, Tokyo 100-8310, Japan TEL +81-3-3218-3221 FAX +81-3-3218-3638 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

Patent number 3035358 Title Data transformation apparatus and data transformation method Date of registration February 18. 2000 This patent is also applied to PCT/JP96/01254 (date: July 31, 1996). Copyright Mitsubishi Electric Corporation reserves the copyright on the all submitted documents.

258 CRYPTREC 2001

All related patents

We believe that other entities do not have any related patents.

License policy of usage for the electronic government in Japan

We are prepared to grant, on the basis of reciprocity and non-discriminatory, a royalty-free license under above patents to an unrestricted number of applicants to manufacture, use and/or sell implementations of MISTY1.

7.1.2.4 Triple DES

Reference URL http://csrc.nist.gov/encryption/tkencryption.html

7.1.2.5 Camellia

URL for submitted cryptographic technique

Japanese text http://info.isl.ntt.co.jp/camellia/ English text http://info.isl.ntt.co.jp/camellia/

Date and the name of the conference where the submission was publicized

Masayuki Kanda, "Camellia - A 128-bit Block Cipher", ISEC Technical report for IEICE, May 25, 2000

Contact person for supply

Name Masayoshi Nakao Division/assignment Group Leader, NTT Information Sharing Platform Laboratories, Information Security Project Affiliation Nippon Telegraph and Telephone Corporation Address 1-1-609A, Hikarino'oka Yokosuka-shi, Kanagawa 238-0847, Japan TEL +81-468-59-3334 FAX +81-468-59-3365 e-mail [email protected]

Name Atsushi Toshima Division/assignment General Manager, NTT Projects Division, First Department Affiliation Mitsubishi Electric Address Office Tower Z 13F, 1-8-12 Harumi, Chuo-ku, Tokyo, 104-6212, Japan

259 CRYPTREC 2001

TEL +81-3-6221-2634 FAX +81-3-6221-2770 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

Patent number 2000-064614 Title Titled in Japanese Date of application March 9, 2000 This patent is also applied to PCT/JP01/01796 (date: March 8, 2001) and Taiwan (No.90105464, date: March 8, 2001).

Copyright Nippon Telegraph and Telephone Corporation and Mitsubishi Electric Corporation reserve the copyright on the following documents; (2) Specifications in 2001, (3) Self Evaluation Report in 2001, and (7) Presentation file for CRYPTREC submission explanation meeting. Mitsubishi also holds the copyright on the documents "(5) Reference code/its specification, and test vector generation program/its specification."

All related patents

We believe that other entities do not have any related patents.

License policy of usage for the electronic government in Japan

We are prepared to grant, on the basis of reciprocity and non-discriminatory, a royalty-free license under above patents to an unrestricted number of applicants to manufacture, use and/or sell implementations of Camellia.

7.1.2.6 CIPHERUNICORN-A

URL for submitted cryptographic technique

Japanese text http://www.hnes.co.jp/products/security/index.html English text http://www.hnes.co.jp/products/security/index-e.html

Date and the name of the conference where the submission was publicized

NEC Corporation, "A New 128-bit Block Cipher CIPHERUNICORN-A", Vol. 100, No.76, pp23-46, ISEC2000-5, ISEC(Information Security Technical), Group of IEICE of Japan, May 26, 2000

260 CRYPTREC 2001

Contact person for supply

Name Security Technology Center Division/assignment Internet Software Division Affiliation NEC Corporation Address 2-11-5, Shibaura, Minato-ku, Tokyo 108-8557, Japan TEL +81-3-5476-1913 FAX +81-3-6576-1678 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

Application number H9-213274 Title A recording medium that can be read by cryptographic equipment or by a computer storing a program for achieving cryptographic equipment (in Japanese) Date of application August 7, 1997 Copyrighted material CIPHERUNICORN-A program Trademark Registration number: 4221077

All related patents

At this point in time, no prior related patents from other companies have been found in the official patent gazette.

License policy of usage for the electronic government in Japan

Free of charge except when purpose of use is for profit by private business or the like.

7.1.2.7 Hierocrypt-3

URL for submitted cryptographic technique

Japanese text http://www.toshiba.co.jp/rdc/security/hierocrypt English text http://www.toshiba.co.jp/rdc/security/hierocrypt

261 CRYPTREC 2001

Date and the name of the conference where the submission was publicized

Kenji Ohkuma, "Security and Performance Evaluations for the block ciphers Hierocrypt-3 and Hierocrypt-L1", Technical report of IEICE ISEC2000-71 pp.71-100, September 29, 2000

Contact person for supply

Name Kenji Ohkuma Division/assignment Senior Research Scientist, Computer Network Systems Laboratory, Corporate Research & Development Center Affiliation Toshiba Corporation Address 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 212-8582, Japan TEL +81-44-549-2156 FAX +81-44-520-1841 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

1. Application number 2000-210484 Title Titled in Japanese Date of application March 6, 2001

2. Application number 2000-211686 Title Titled in Japanese Date of application July 12, 2000

3. Application number 2000-212175 Title Titled in Japanese Date of application July 13, 2000

4. Application number 2001-68742 Title Titled in Japanese Date of application June 30, 2001

All related patents

License condition is permitting no exclusive use or looser.

262 CRYPTREC 2001

License policy of usage for the electronic government in Japan

License condition is permitting no exclusive use or looser.

7.1.2.8 RC6 Block Cipher

URL for submitted cryptographic technique

Japanese text http://www.rsasecurity.com/rsalabs/submissions/index.html English text http://www.rsasecurity.com/rsalabs/submissions/index.html

Date and the name of the conference where the submission was publicized

Ron Rivest, "The RC6 Block Cipher, algorithm specification", The First AES Candidate Conference (AES1), August 1998

Contact person for supply

Name Eiji Arai Division/assignment Senior Manager, Developer Sales Dept. Affiliation RSA Security Japan, Ltd. Address Tokyo Ginko Kyokai Bldg. 13F, 1-3-1 Marunouchi, Chiyoda-ku, Tokyo 100-0005, Japan TEL +81-3-5222-5210 FAX +81-3-5222-5270 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

1. Patent number (US ) 5,724,428 Title Block Encryption Algorithm with Data-Dependent Rotations Date of application November 1, 1995

2. Patent number (US ) 5,835,600 Title Block Encryption Algorithm with Data-Dependent Rotations Date of application April 21, 1997

3. (US ) 09/094,649 Title Enhanced Block Encryption Algorithm with Data-Dependent Rotations

263 CRYPTREC 2001

Date of application June 15, 1998

4. Serial number PCT/US99/13358 Title Enhanced Block Encryption Algorithm with Data-Dependent Rotations Date of application June 15, 1999

5. Application number 2000-555387 Title Block Encryption Algorithm with Data-Dependent Rotations and Integer Multiplication Date of application

Copyright RSA Security owns copyright on sample codes in this submission.

All related patents License policy of usage for the electronic government in Japan

RSA Security will not charge any patent license fee for the use of RC6 algorithm for applications used in the electronic government in Japan.

7.1.2.9 SC2000

URL for submitted cryptographic technique

Japanese text http://www.labs.fujitsu.com/theme/crypto/sc2000.html English text http://www.labs.fujitsu.com/theme/crypto/sc2000.html

Date and the name of the conference where the submission was publicized

Takeshi Shimoyama, "Symmetric Key Block Cipher SC2000" , IECIC, ESS society, Technical Group on Information Security, September 29, 2000

Contact person for supply

Name Tatsuji Shimoe Division/assignment Director, Enterprise Management Products Div. Development Dept. II Affiliation Fujitsu Ltd. Address TECH Bldg. 3-9-18, Shin-Yokohama, Kohoku-ku, Yokohama-shi, Kanagawa 222-0033, Japan TEL +81-45-474-1925 FAX +81-45-474-1953 e-mail [email protected]

264 CRYPTREC 2001

Intellectual property and license All patents and intellectual properties regarding the submission

1. Application number 2001-018016 Title Apparatus, program, and recording media for encryption and encryption design Date of application January 26, 2000

2. Application number 2000-212813 Title Method and apparatus for including SPN structure in F-function Date of application July 13, 2000

3. Application number 2000-212814 Title Method and apparatus for combining Feistel structure and SPN structure Date of application July 13, 2000

4. Application number 2000-212482 Title Apparatus and recording media for extension key generation Date of application July 13, 2000

Copyright Fujitsu Ltd.

All related patents

None

License policy of usage for the electronic government in Japan

Fujitsu Limited has filed patent applications on the technique used in this application. Fujitsu Limited will license any resulting patent on reasonable and non-discriminatory terms and conditions.

7.1.2.10 SEED

Reference URL http://www.kisa.or.kr/seed/index.html

7.1.2.11 MULTI-S01

URL for submitted cryptographic technique

Japanese text http://www.sdl.hitachi.co.jp/crypto/s01/index-j.html English text http://www.sdl.hitachi.co.jp/crypto/s01/index.html

265 CRYPTREC 2001

Date and the name of the conference where the submission was publicized.

Soichi Furuya, "On Paddings of MULTI-S01 and Their Security Evaluation(in Japanese)", Regular Workshop of ISEC Group, IEICE, September 29, 2000

Contact person for supply

Name Shinichiro Harano Division/assignment Director IPR & Cryptographic Technology Affiliation Network SoftwareSoftware Division, Hitachi, Ltd. Address 5030 Totsuka-cho, Totsuka-ku,Yokohama 244-8555 Japan TEL +81-45-866-8140 FAX +81-45-865-9036 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

1. Application number (Publication number) 2000-108334 (2001-007800) Title "Encryption device and method" Date of application April 10, 2000

2. Application number 2000-070994 Title "Common-key encryption device and method" Date of application March 9, 2000

3. Application number 2000-210690 Title "Common-key encryption device and method" Date of application July 6, 2000

Copyright

All documentations as program codes related to the submission of MULTI-S01 are copyrighted material, protected by relevant Japanese laws and international conventions.

All related patents

Hitachi, Ltd. considers that the patent applications specified above will relate to MULTI-S01. In the case that MULTI-S01 is adopted in response to this submission, Hitachi, Ltd. is prepared to grant on the basis of reciprocity licenses on non-discriminately and reasonable terms, under the relevant patents .

266 CRYPTREC 2001

License policy of usage for the electronic government in Japan

The same policy to the general is applied as well to the electronic government in Japan.

7.1.2.12 RIPEND-160

Reference URL http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html

7.1.2.13 SHA-1

Reference URL http://csrc.nist.gov/encryption/tkhash.html

7.1.2.14 draft SHA-256/384/512

Reference URL http://csrc.nist.gov/encryption/tkhash.html

7.1.2.15 PRNG based on SHA-1

Reference URL http://csrc.nist.gov/encryption/tkrng.html

7.2 Candidates of Cryptosystems to be Evaluated in Detail in 2002

7.2.1 Public Key Cryptographic Techniques

7.2.1.1 ESIGN (Guideline on the Electronic Signature Law)

URL for submitted cryptographic technique

Japanese text http://info.isl.ntt.co.jp/ English text http://info.isl.ntt.co.jp/

Date and the name of the conference where the submission was publicized.

Tatsuaki Okamoto, "Provable Secure Digital Signature TSH-ESIGN and EC Okamoto-Schnorr", NTT R&D, October 1999

Contact person for supply

Name Masayoshi Nakao Division/assignment Senior Research Engineer, Supervisor, NTT Information Sharing Platform Laboratories

267 CRYPTREC 2001

Affiliation Nippon Te legraph and Telephone Corporation(NTT) Address 1-1-609A Hikarinooka Yokosuka-Shi Kanagawa 239-0847 Japan TEL +81-468-59-3334 FAX +81-468-59-3365 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

1. Application number S60-42052 Title Titled in Japanese Date of application March 4, 1985

2. Application number S59-052696 Title Titled in Japanese Date of application March 19, 1984

US 4625076 (March 11, 1985), Canada 1255784 (March 14, 1985), EP 0157258 (March 15, 1985) Signed Document Transmission System

Copyright Nippon Telegraph and Telephone Corporation reserve the copyright on the following documents; (2) Specifications in 2001, (3) Self Evaluation Report in 2001, (5) Reference code/its specification and test vector generation program/its specification, and (7) Presentation file for CRYPTREC submission explanation meeting.

All related patents

We believe that other entities do not have any related patents.

License policy of usage for the electronic government in Japan

We are prepared to grant, on the basis of reciprocity and non-discriminatory, a royalty-free license under above patents to an unrestricted number of applicants to manufacture, use and/or sell implementations of ESIGN.

7.2.1.2 ECIES (Elliptic Curve Integrated Encryption Scheme) in SEC1

URL for submitted cryptographic technique

Japanese text http://www.labs.fujitsu.com/theme/crypto/public_key2001. html

268 CRYPTREC 2001

English text http://www.labs.fujitsu.com/theme/crypto/ public_key2001_e.html

Date and the name of the conference where the submission was publicized

SECG (Standards for Efficient Cryptography Group), "SECG standards" open on Web page via http://www.secg.org/ as of September 20, 2000

Contact person for supply

Name Tatsuji Shimoe Division/assignment Director Enterprise Management Products Div. Development Dept. II Affiliation Fujitsu Ltd. Address TECH Bldg. 3-9-18, Shin-Yokohama, Kohoku-ku, Yokohama-shi, Kanagawa 222-0033, Japan TEL +81-45-474-1925 FAX +81-45-474-1953 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

Please refer to SECG member patent letters below. http://www.secg.org/collateral/certicom_secg_patent.pdf

Copyright License to copy the document is granted provided it is identified as "Standards for Efficient Cryptography (SEC)", in all material mentioning or referencing it.

All related patents

Please refer to SECG Patent Policy : http://www.secg.org/patent_policy.htm

License policy of usage for the electronic government in Japan

Fujitsu Limited has filed patent applications on the technique used in this application. Fujitsu Limited will license any resulting patent on reasonable and non-discriminatory terms and conditions.

269 CRYPTREC 2001

7.2.1.3 HIME(R) (High Performance Modular Squaring Based Public Key Encryption (Revised version))

URL for submitted cryptographic technique

Japanese text http://www.sdl.hitachi.co.jp/crypto/ English text http://www.sdl.hitachi.co.jp/crypto/

Date and the name of the conference where the submission was publicized

Hisayoshi Sato, "Efficient and Provably Secure Public-Key Cryptosysytem HIME(R) (in Japanese)", Regular Workshop of ISEC Group, IEICE, May 18, 2001

Contact person

Name Chisato Konno Division/assignment Chief Manager, Network Business Development Center Affiliation Business Planning DivisionInformation & Computer Group Hitachi, Ltd. Address Hitachi Omori 2nd Bldg., 27-18, Minami Oi 6-chome, Shinagawa-ku, Tokyo, 140-8572 Japan TEL +81-3-5471-8922 FAX +81-3-5471-2565 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

Application number 2001-284363

Title N=p^dq wo houtosuru jouyokannjouno bekijoukonkeisanhouhou oyobi koukaikagiangouhouhou oyobi souti

Date of application September 19, 2001

Copyright

All documentations as program codes related to the submission of HIME(R) are copyrighted material, protected by relevant Japanese laws and international conventions.

270 CRYPTREC 2001

All related patents

Hitachi, Ltd. considers that the patent applications specified above will relate to HIME(R). In the case that HIME(R) is adopted in response to this submission, Hitachi, Ltd. is prepared to grant on the basis of reciprocity licenses on non-discriminately and reasonable terms, under the relevant patents.

License policy of usage for the electronic government in Japan

The same policy to the general is applied as well to the electronic government in Japan.

7.2.1.4 PSEC-KEM Key agreement

URL for submitted cryptographic technique

Japanese text http://info.isl.ntt.co.jp/ English text http://info.isl.ntt.co.jp/

Date and the name of the conference where the submission was publicized

Tatsuaki Okamoto, "Public Key Cryptography EPOC and PSEC", ISEC Technical report of IEICE, May 25, 2000

Contact person for supply

Name Masayoshi Nakao Division/assignment Senior Research Engineer, Supervisor, NTT Information Sharing Platform Laboratories Affiliation Nippon Telegraph and Telephone Corporation (NTT) Address 1-1-609A, Hikarinooka, Yokosuka-shi, Kanagawa 238-0847, Japan TEL +81-468-59-3334 FAX +81-468-59-3365 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

1. Application number H10-320172 Title Titled in Japanese Date of application November 11, 1998

271 CRYPTREC 2001

2. Application number 2000-32461 Title Titled in Japanese Date of application February 9, 2000

Copyright Nippon Telegraph and Telephone Corporation reserves the copyright on the following documents; (2) Specifications in 2001, (3) Self Evaluation Report in 2001, (5) Reference code/its specification and test vector generation program/its specification, and (7) Presentation file for CRYPTREC submission explanation meeting.

All related patents

We believe that other entities do not have any related patents.

License policy of usage for the electronic government in Japan

We are prepared to grant, on the basis of reciprocity and non-discriminatory, a royalty-free license under above patents to an unrestricted number of applicants to manufacture, use and/or sell implementations of PSEC-KEM.

7.2.2 Common Key Cryptographic Techniques

7.2.2.1 MUGI

URL for submitted cryptographic technique

Japanese text http://www.sdl.hitachi.co.jp/crypto/mugi/ English text http://www.sdl.hitachi.co.jp/crypto/mugi/index-e.html

Date and the name of the conference where the submission was publicized

Dai Watanabe, "The correlation of the output sequence generated by the PANAMA-like generator (in Japanese)", Regular Workshop of ISEC Group, IEICE, September 17, 2001.

Contact person for supply

Name Shinichiro Harano Division/assignment Director IPR & Cryptographic Technology Affiliation Network Software, Software Division, Hitachi, Ltd. Address 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa 244-8555, Japan

272 CRYPTREC 2001

TEL +81-45-862-8715 FAX +81-45-865-9010 e-mail [email protected]

Intellectual property and license All patents and intellectual properties regarding the submission

All patents application shown in this paper are applied to Japan.

1. Application number 2001-013959 Title Titled in Japanese Date of application January 23, 2001

2. Application number 2001-145783 Title Titled in Japanese Date of application May 16, 2001

3. Application number 2001-274433 Title Titled in Japanese Date of application September 11, 2001

Copyright All documentations as program codes related to the submission of MUGI are copyrighted material, protected by relevant Japanese laws and international conventions.

All related patents

Hitachi, Ltd. considers that the patent applications specified above will relate to MUGI. In the case that MUGI is adopted in response to this submission, Hitachi, Ltd. is prepared to grant on the basis of reciprocity licenses on non-discriminately and reasonable terms, under the relevant patents.

License policy of usage for the electronic government in Japan

The same policy to the general is applied as well to the electronic government in Japan.

7.2.2.2 RC4

Contact RSA Security (http://www.rsasecurity.co.jp/)

Specifications As described in the following literature.

S. Fluhrer, I. Mantin, and A. Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4," Lecture Notes I Computer Science 2259, pp 1-24, Springer-Verlag, 2001

273 CRYPTREC 2001

8 Cryptographic Techniques Evaluated

The abbreviated name of each cipher submitted is described in brackets [ ].

1. Public-key ciphers

(a) Signature i. DSA A cipher evaluated in 2000. This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail. See Chapter 2 of this report for the evaluation results. ii. ECDSA (ANSI X9.62) This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail. See Chapter 2 of this report for the evaluation results. iii. ECDSA (Elliptic Curve Digital Signature Algorithm) in SEC1 [ECDSA] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail. See Chapter 2 of this report for the evaluation results. iv. ESIGN signature [ESIGN] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail. See Chapter 2 of this report for the evaluation results. v. OK-ECDSA [OK-ECDSA] This cipher was submitted in 2001 and subjected to screening. See Chapter 2 of this report for the evaluation results. vi. RSA signature (PKCS#1 v1.5*1) This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail. See Chapter 2 of this report for the evaluation results. vii. RSA Public-Key Cryptosystem with Probabilistic Signature Scheme (RSA-PSS) [RSA-PSS] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail. See Chapter 2 of this report for the evaluation results.

*1 This cipher is stipulated in the standard, RSA PKCS# 1v1.5 and also contained in the standard, RSA PKCS# 1v2.0 onward. Therefore, it is abbreviated as RSA-PKCS#1v1.5 in this report for convenience.

274 CRYPTREC 2001

(b) Confidentiality i. ECIES (Elliptic Curve Integrated Encryption Scheme) in SEC1 [ECIES] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail as the one under monitoring. See Chapter 2 of this report for the evaluation results. ii. EPOC-2 encryption [EPOC-2] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail. See Chapter 2 of this report for the evaluation results. iii. HIME(R) (High Performance Modular Squaring Based Public Key Encryption (Revised version)) [HIME(R)] This cipher was submitted in 2001 and screened. See Chapter 2 of this report for the evaluation results. iv NTRU public key cryptosystem [NTRU] This cipher was submitted in 2001 and screened. See Chapter 2 of this report for the evaluation results. v. RSA Public-Key Cryptosystem with Optimal Asymmetric Encryption Padding (RSA-OAEP) [RSA-OAEP] A cipher evaluated in 2000. This cipher was offered in 2001 and evaluated in detail. See Chapter 2 of this report for the evaluation results. (c) Key sharing i. Common private Complex Key System [Cock system] This cipher was submitted in 2001 and screened. However, implementation on various platforms and realization of compatibility were difficult. In addition, it was judged that the key sharing function was not achieved on security. So the evaluation was terminated for the following reasons. • Since a real number is handled, an infinite bit length is required for expressing data. • From open information and on-channel information, confidential information can be easily identified and the shared key can be found. ii. DH A cipher evaluated in 2000. This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail as the one under monitoring. See Chapter 2 of this report for the evaluation results. iii. ECDH (Elliptic Curve Deffie-Hellman Scheme) in SEC1 [ECDH] A cipher evaluated in 2000. This cipher was offered in 2001 and evaluated in detail as the one under monitoring. See Chapter 2 of this report for the evaluation results.

275 CRYPTREC 2001

iv. OK-ECDH [OK-ECDH] This cipher was submitted in 2001 and screened. See Chapter 2 of this report for the evaluation results. v. PSEC-KEM Key agreement [PSEC-KEM] A cipher evaluated in 2000. This cipher was submitted in 2001 and screened. See Chapter 2 of this report for the evaluation results.

2. Symmetric ciphers

(a) 64-bit block cipher i. CIPHERUNICORN-N [UNI-E] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail as the one under monitoring. See Chapter 3 of this report for the evaluation results. ii. Hierocrypt-L1 [HC-L1] A cipher evaluated in 2000. This cipher was offered in 2001 and evaluated in detail as the one under monitoring. See Chapter 3 of this report for the evaluation results. iii MISTY1 [MISTY1] A cipher evaluated in 2000. This cipher was offered in 2001 and evaluated in detail as the one under monitoring. See Chapter 3 of this report for the evaluation results. iv. RC2 This is a cipher whose evaluation was requested by the year 2001’s CRYPTREC Advisory Committee and it was evaluated in detail. See Chapter 6 of this report for the evaluation results. v. Triple DES A cipher evaluated in 2000. This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail as the one under monitoring. See Chapter 3 of this report for the evaluation results. (b) 128-bit block cipher i. Advanced Encryption Standard (AES) A cipher evaluated in 2000. This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail as the one under monitoring. See Chapter 3 of this report for the evaluation results. ii. Camellia [Camellia] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail as the one under monitoring. See Chapter 3 of this report for the evaluation results.

276 CRYPTREC 2001

iii. CIPHERUNICORN-A [UNI-A] A cipher evaluated in 2000. This cipher was offered in 2001 and evaluated in detail. See Chapter 3 of this report for the evaluation results. iv. Hierocrypt-3 [HC-3] A cipher evaluated in 2000. This cipher was offered in 2001 and evaluated in detail as the one under monitoring. See Chapter 3 of this report for the evaluation results. v. RC6 Block Cipher [RC6] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail as the one under monitoring. See Chapter 3 of this report for the evaluation results. vi. SC2000 [SC2000] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail as the one under monitoring. See Chapter 3 of this report for the evaluation results. vii. SEED This is a cipher whose evaluation was requested by the year 2001’s CRYPTREC Advisory Committee and it was evaluated in detail. See Chapter 3 of this report for the evaluation results. (c) Stream cipher i. C4-1 [C4-1] This cipher was submitted in 2001 and screened. However, the evaluation was terminated for the following reasons. • The submitted document does not contain sufficient algorithm information for a third party to implement this cipher. • Since the body of the submitted cipher is not described in the reference program, an adequate document for evaluation is not available. ii. FSAngo [FSAngo] This cipher was submitted in 2001 and screened. However, the evaluation was terminated for the following reasons. • The submitted document does not contain the reference program for text file (source program) nor test vector generation program. iii. MUGI This cipher was submitted in 2001 and screened. See Chapter 3 of this report for the evaluation results. iv. MULTI-S01 [S01] A cipher evaluated in 2000. This cipher was submitted in 2001 and evaluated in detail. See Chapter 3 of this report for the evaluation results.

277 CRYPTREC 2001

v. RC4 This is a cipher whose evaluation was requested by the year 2001’s CRYPTREC Advisory Committee and it is under detailed evaluation.

3. Hash functions

(a) RIPEMD-160 A cipher evaluated in 2000. This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail as the one under monitoring. See Chapter 4 of this report for the evaluation results. (b) SHA-1 A cipher evaluated in 2000. This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail as the one under monitoring. See Chapter 4 of this report for the evaluation results. (c) draft SHA -256, 384, 512 This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail. See Chapter 4 of this report for the evaluation results.

4. Pseudorandom number generators

(a) Creation of intrinsic random numbers with Clutter Box [Clutter Box] This cipher was submitted in 2001 and screened. However, the evaluation was terminated for the following reasons. • Because the system requires special hardware, it is difficult to evaluate it based on the submitted document. • The submitted document does not contain adequate information about the algorithm of random number generation. (b) FSRansu [FSRansu] This cipher was submitted in 2001 and screened. However, the evaluation was terminated for the following reasons. • The submitted document does not contain the reference program for text file (source program) nor test vector generation program. (c) High security ultra mini random number generator [RNE] This cipher was submitted in 2001 and screened. However, the evaluation was terminated for the following reasons. • Because the system requires special hardware, it is difficult to evaluate it based on the submitted document.

278 CRYPTREC 2001

• Because the reference program is intended for observing random-number series, the submitted document does not satisfy the condition for evaluation. (d) PRNG based on SHA -1 A cipher evaluated in 2000. This is a cipher whose evaluation was judged to be necessary in the year 2001’s CRYPTREC Evaluation Committee and it was evaluated in detail as the one under monitoring. See Chapter 5 of this report for the evaluation results. (e) TAO TIME Cognition Algorithm [TAO TIME] This cipher was submitted in 2001 and screened. See Chapter 5 of this report for the evaluation results.

5. Others

(a) The Security System for Information Telecommunication using the unconditional secrecy technology [CVCRT] This cipher was submitted in 2001 and screened. However, the evaluation was terminated for the following reasons. • Contents of the submitted document are merely a development plan for the required specifications and lacks detailed technical information. Therefore, its evaluation is basically impossible. • Random compression appears to be “one-wayness” simply because the information for returning from an image to its reverse image is eliminated. For example, there is no reason for insisting superiority to the hash function that is strong in collision resistance. Also, there is no rational reason why a 24 x 24 matrix is suitable. • An algorithm for efficiently composing a disturbance signal is not indicated clearly. Nor is there a reason why disturbance is effective. (b) Security-up for Kana Kanji System Using Squares [MKS] This cipher was submitted in 2001 and screened. However, the evaluation was terminated for the following reasons. • Contents of the submitted document are explanation of the functions and operating environment of the submitted p rogram. The principle and algorithm of those functions are not described. So, its evaluation is basically impossible. • The basis of security, that is described in the submitted document, is not rational. • The proposed contents cannot be recognized as a public-key cipher.

279 CRYPTREC 2001

Index

A3 function, 139, 142 elementary statistics value evaluation, 124, 127, active attack, 27, 55, 78, 86 139, 142 adaptive chosen ciphertext attack, 70, 75, 85, 89 ElGamal cipher, 48, 50, 88 adaptive chosen message attack, 47, 50, 54, 59, elliptic curve method, 29, 32, 85 244 elliptic curve parameter, 38, 45, 49, 74, 77, 89 adjacent vector problem, 84 e-th root approximation problem, 20, 25, 50, 53, 58 AER assumption, 53 existential, 20, 47, 48, 50, 54 AER problem, 53 exponential function time, 30 anomalous binary curve, 24, 48 Anomalous curve method, 39 FIPS 186-2, 24, 43 anonymous authentication mode, 246 FIPS-180, 212, 214 ANSI X9.62, 17, 22, 24, 45, 49, 50, 80, 265, 291 FIPS186-2, 20, 24, 43, 49, 233, 238 ANSI X9.63, 86 FIPS186-2 change notice, 43, 49 attack is successful, 91 FL function, 100, 102, 175, 181, 184 authenticated encryption, 160 Fortezza, 249 avalanche effect evaluation, 93, 98, 102 forward-secrecy, 78 Frobenius mapping, 48 B function, 201 Fujisaki-Okamoto conversion, 28, 84 Baby-Step/Giant-Step method, 34, 38 function field sieve method, 34 Bitslice implementation method, 175 Brent's prediction equation, 35 G function, 112, 149, 150 Gap-Diffie-Hellman problem, 76 CA, 251 general number field sieve method, 29, 32, 35 Carter-Wegman MAC, 161 generic DSA, 46, 47 CBC mode, 245, 260, 262 generic group model, 20, 46, 48, 81 chosen plaintext attack, 91, 160, 257 generic group oracle, 47 cipher-strength evaluation system, 124 generic model, 46, 50, 81 ciphertext matching attack, 262 GNFS, 29 ciphertext only attack, 91, 160 CM method, 46 higher order differential attack, 92, 93, 101, 113, CMA, 54, 55, 56 144, 149, 171, 176, 180, 184, 197, cofactor, 30, 81, 87 203, 261 collision, 37, 41, 47, 49, 129, 133, 138, 163, 203, hybrid cipher, 88 211, 217, 226, 230, 232, 296 collision resistance, 217, 220, 296 I function, 201, 202 controlled higher order differential, 113, 184, 189 IETF, 243, 247, 249, 263 Convolution Modular Lattice, 84 IND-CCA2, 28, 59, 70, 72, 76, 84, 85, 89 CRL, 246 IND-CPA, 28, 73, 84 CRT, 85 index calculus method, 34, 36 Integral Cryptanalysis, 180 DDH problem, 76 interpolating attack, 98, 109, 113, 129, 133, 144, Decisional Diffie-Hellman problem, 79 149, 151, 176, 184, 190, 203 DES, 13, 36, 40, 43, 92, 97, 100, 102, 114, 117, 147, 182, 202, 233, 238, 240, 243, KASUMI, 100, 176, 181 255, 274, 293 Key collision attack, 129 DES Challenge, 92, 256, 257 key derivation function, 27, 77, 79 deviation parameter, 162 key encapsulation mechanism, 23, 28, 88 differential cryptanalysis, 92, 125, 133, 140, 144, known plaintext attack, 91 160, 257, 264 149, 157, 180, 185, 190, 202, 208, Koblitz curve, 20, 24, 27, 39, 46, 48, 75, 78 256, DPA attack, 81, 86 lattice basis contraction algorithm, 53 lattice method, 30, 32 ECC challenge, 39 lattice reduction technique, 44 ECM, 29 Lenstra-Verheul, 36

CRYPTREC 2001

LFM, 30, 32 RSA-FDH, 59 linear cryptanalysis, 92, 98, 109, 125, 133, 140, RSA-OAEP, 17, 20, 26, 28, 59, 66, 85, 268, 292 144, 149, 157, 169, 181, 184, 189, RSA-PSS, 17, 20, 25, 59, 62, 267, 291 202, 208, 256, 261, 263 LLL algorithm, 53, 84 S function, 182 man-in-the-middle attack, 244 scientific break, 108, 120 MASH, 261 SECG, 45, 74, 76, 89, 265, 269, 285 maximum differential characteristic probability, security hole, 21, 243, 250, 255 112, 127, 141, 149 security margin, 108, 120, 133, 150, 203 maximum linear characteristic probability, 112, security model, 89 128, 141, 144, 150 security protocol, 243, 247 meet-in-the-middle attack, 121, 256 seed key, 125, 139, 140 message schedule function, 214, 235 shortest vector problem of lattice, 84 MIX, 261 side-channel attack, 81, 82, 86, 197 mode of operation, 73, 256 signature oracle, 48, 54 Montgomery, 27, 33, 81, 86 Single-Occurrence adaptive Montgomery elliptic curve, 27, 28, 81, 86 chosen message attack, 54 Moore's law, 31 SO-CMA, 54 MT function, 140 SP 800-22, 165 multiplication by scalars, 81, 86 SPA attack, 81, 86 special number field sieve method, 35 n=p2q type factorization problem, 53 square root calculation, 85 N=pdq type factorization problem, 85 squarefree, 32 number field sieve method, 29, 34, 85 squarefree part, 32 SSL, 13, 21, 243, 260 OAEP, 26, 55, 59, 66, 85, 86, 292 strong resistance, 59 one-wayness, 211, 217, 219, 233, 238, 296 T function, 125, 139, 142 P function, 182, 184 T0 function, 140 PANAMA, 122, 156, 207, 288 temporary key generation part, 139, 140 parallel collision search method, 49 timing attack, 81, 86, 129, 146, 177, 197, 203 passive attack, 27, 55, 78, 86 TLS, 13, 21, 243, 260 PKCS #1 v1.5, 59 Traffice Analysis Attack, 248 Pohling-Hellman method, 38 trap door, 49 Pollard method, 34, 38 Vernam cipher, 161 polynomial time, 30, 32 version rollback attack, 244 poweranalysis attack, 82, 87, 129, 146, 176, 178 weak key, 129, 133, 141, 145, 177, 196, 203 preimage resistance, 217, 220 Weierstrass elliptic curve, 81, 87 premaster secret, 251, 253, 254 Weil descent methold, 39 public key certificate, 244, 248, 251 Weil method, 46 quantum computer, 32, 36 Weil/Tate Pairing, 39 quasi-exponential function time, 29

R function, 201, 202, 203 Rabin-OAEP, 84 Rabin-SAEP, 85 random oracle model, 25, 44, 46, 48, 50, 54, 66, 70, 76, 81, 85, 89 randomized projection coordinate, 81, 86 recognition algorithm, 241 recursive SPN structure, 100, 110 Replay Attack, 248 revised e-th root approximation problem, 56 RIPE project, 226 RIPEMD, 212, 223, 226, 229, 295 RSA primitive, 25, 59, 65 RSA signature, 17, 20, 22, 25, 57, 66, 68, 251, 291

CRYPTREC 2001

About the supplied CD-ROM*1

The supplied CD-ROM includes the following:

(a) Technical information on the cryptographic techniques submitted for evaluation (b) SSL investigation report

(1) The CD-ROM supplies detailed technical information on the cryptographic techniques entered for evaluation in 2001 for your reference.

(2) The intellectual property rights of the technical information included in this CD-ROM are the property of the applicants.

(3) The self-evaluation reports included in this CD-ROM are the original documents submitted by the applicants. Therefore, in some cases, they may differ from the viewpoint of CRYPTREC Evaluation Committee. Refer to CRYPTREC Report 2001 main text for the result of evaluations by CRYPTREC Evaluation Committee.

(4) The technical materials included in this CD-ROM are the original materials submitted by the applicants during the application period in 2001. Revisions and corrections of clerical errors after the submittal of the materials are to be placed in the CRYPTREC homepage.

Refer to readme.text for details of the CD-ROM.

*1 Not supplied with the PDF version.