CRYPTREC Report 2000 (Provisional Translation)

CRYPTREC 2000

March 2001 Information Technology Promotion Agency, Japan The Security Center

CRYPTREC 2000

Index

Introduction ...... 1 On the CRYPTREC Evaluation Committee Report...... 3 Information for Readers of This Report...... 6 1. Overview of Cryptographic Technique Evaluation...... 7 2. Solicited Cryptographic Techniques ...... 14 2.1 Categories of Solicited Cryptographic Technique...... 14 2.2 Public-key cryptography...... 16 2.2.1 Public-Key Cryptosystem for Confidentiality ...... 16 2.2.2 Public-Key Cryptosystem implementing Signature Function...... 18 2.2.3 Public-Key Cryptosystem Implementing Authentication Function ...... 19 2.2.4 Public-Key Cryptosystem Implementing Key Sharing Function ...... 21 2.3 Symmetric Cipher Technology ...... 23 2.3.1 Block Ciphers...... 23 2.3.2 Stream Ciphers ...... 25 2.4 Hash Functions...... 26 2.5 Pseudo-random Number Generating Scheme...... 26 3. Overview of Cryptographic Technique Evaluation...... 27 3.1 Purpose of the Evaluation...... 27 3.2 Screening Evaluation and Detailed Evaluation ...... 28 3.3 Evaluation Criteria for Asymmetric Cryptographic Schemes...... 29 3.3.1 Security Evaluation Criteria...... 29 3.3.2 Evaluation of Software Implementation...... 30 3.4 Evaluation Criteria for Symmetric Cryptographic Schemes ...... 31 3.4.1 Security Evaluation Criteria...... 31 3.4.2 Evaluation of Software Implementation...... 36 3.4.3 Evaluation of Hardware Implementation ...... 38 3.5 Evaluation Method of Hash Functions ...... 38 3.6 Evaluation Method of Pseudo-random Number Generating Techniques...... 39

4. Evaluation of Public Key Cryptography...... 40 4.1 General Comments...... …….. 40 4.1.1 List of Public Key Cryptographic Techniques as Targets of Detailed Evaluation...... 40 4.1.2 General Comments on Public Key Cryptographic Techniques...... 41

4.2 Evaluation Classified by Function...... 48 4.2.1 Signature...... …48

i CRYPTREC 2000

4.2.2 Confidentiality...... 51 4.2.3 Key Sharing...... 61 4.3 Evaluation Based on Security Evidence...... 67 4.3.1 Integer Factoring Problem...... 67 4.3.2 Discrete Logarithm Problem...... …...... 73 4.3.3 Elliptic Curve Discrete Logarithm Problem...... …...... 82 4.4 Evaluation of Individual Cryptosystems...... …...... 88 4.4.1 ACE Sign...... …...... 88 4.4.2 ESIGN-Signature...... …...... ….91 4.4.3 RSA-PSS...... 98 4.4.4 DSA...... 102 4.4.5 ECDSA in SEC1...... 104 4.4.6 MY-ELLTY ECMR-160/192/OEF-h...... 112

4.4.7 EPOC-1...... 123 4.4.8 EPOC-2...... 130 4.4.9 EPOC-3...... …..136 4.4.10 HIME-1...... 142 4.4.11 HIME-2...... 154 4.4.12 RSA-OAEP...... 166 4.4.13 ACE Encrypt...... 172 4.4.14 ECAES in SEC1...... 176 4.4.15 PSEC-1...... 185 4.4.16 PSEC-2...... 191 4.4.17 PSEC-3...... 196 4.4.18 DH...... 202 4.4.19 ECDHS in SEC1...... 205 4.4.20 ECMQVS in SEC1...... 212 4.4.21 HDEF-ECDH...... 220 5. Evaluation of Symmetric Ciphers...... 229 5.1 Evaluation by Encryption Type...... 229 5.1.1 64-bit Block Ciphers...... 229 5.1.2 128-bit Block Ciphers...... 241 5.1.3 Stream Ciphers...... 254 5.2 Individual Cipher Evaluation...... 257

5.2.1 CIPHERUNICORN-E...... 257 5.2.2 FEAL-NX...... 265

ii CRYPTREC 2000

5.2.3 Hierocrypt-L1...... 273 5.2.4 MISTY1...... 280 5.2.5 Tripe DES...... 287 5.2.6 Camellia...... 294 5.2.7 CIPHERUNICORN-A...... 301 5.2.8 Hierocrypt-3...... 309 5.2.9 MARS...... 315 5.2.10 RC6...... 318 5.2.11 SC2000...... 324 5.2.12 Rijndael...... 331 5.2.13 MULTI-SOl...... 339 5.2.14 TOYOCRYPT-HS1...... 344 6. Hash-Function Evaluation...... 350

6.1 Evaluation by Type...... 350 6.2 Individual Evaluation...... 351 6.2.1 MD5...... 351 6.2.2 RIPEMD-160...... 354 6.2.3 SHA-1...... 359 7. Evaluation of Pseudorandom Number Generation Methods...... 361 7.1 Evaluation by Type...... 361 7.2 Individual Evaluation...... …362 7.2.1 TOYOCRYPT-HR1...... 362 7.2.2 PRNG based on SHA-1...... 367 8. Other...... …...... 375 8.1 Cryptographic Techniques Evaluated...... …...... 375 8.2 Trend Toward Cipher Standardization...... …...... 381 8.2.1 About DES/AES...... …...... 381 8.2.2 About the NESSIE Project...... …...... 384 8.2.3 About ISO/IEC JTC1/SC27/WG2...... …...... 387 8.2.4 About IEEE...... …...... 389 8.2.5 About IETF...... …...... 389

iii CRYPTREC 2000

Introduction

Japan's e-Government, a millennium project destined to make the nation's administrative infrastructure the world's most electronically advanced, is set for inauguration by fiscal year 2003. Its goal is the computerization of the nation's administrative procedures such as applications, notifications and government procurements with an aim toward establishing more efficient and cost-saving government systems. In order to build the e-Government's functions correctly, the use of cryptographic techniques will be required in various aspects. Today, the majority of cryptographic techniques, which algorithms are open to public, depend upon computational intractability. Because of this, the security margin of current cryptographic techniques decrease unavoidably year by year as increase in computing power. Additionally, new methods and techniques to attack cryptographic schemes may appear unexpectedly. These new methods may make it appear that the indecipherability of a particular cryptography could not be as reliable as was believed to be. Furthermore, when observed from a practical point of view, those items that should be taken into consideration when selecting reliable cryptographic schemes include all aspects of cryptographic programming -- including processing speed and total program size, as well as security. Unfortunately, Japan's experience in making a systematic evaluation of various cryptographic techniques is quite limited. Because of this, the Ministry of Economy, Trade and Industry (formerly the Ministry of International Trade and Industry), being expected to play role of a leader ministry in constructing the e-Government, decided that a list of cryptographic techniques available for use by the e-Government should be prepared. The task of evaluating existing cryptographic techniques has been entrusted to the Information Technology Promotion Agency, Japan (IPA). In order to carry out the Japanese first cryptography evaluation project with our nations best and brightest cryptographic technique researchers, IPA organized the CRYPTREC Evaluation Committee (CRYPTREC), which is consisted of Japanese top specialists in cryptography and cryptographic security techniques. The CRYPTREC chaired by Professor Hideki Imai of Tokyo University, conducted an intensive evaluation program for a period of near twelve months. The Committee involved representatives of Ministries and they attended as observers: The Ministry of Economy, Trade and Industry; the Ministry of Public Management; Home Affairs; Posts and Telecommunications (formerly the Management and Coordination Agency and the Ministry of Posts and Telecommunications) and the Defense Agency were involved from the onset; later the Cabinet Secretariat; the National Police Agency; the Ministry of Justice; and the Department of Treasury joined. The project have become almost the government wide effort. Turning our eyes to advancements in the world of cryptographic techniques We can find the Advanced

iv CRYPTREC 2000

Encryption Standard (AES) program which will replace the Data Encryption Standard (DES) algorithm as the United State's next-generation federal standard. In Europe, a similar work, the New European Schemes for Signature, Integrity and Encryption (NESSIE) project, is underway. Additionally ISO/IEC set about to establish international standard criteria for cryptgraphic technology. Because of the world conditions described above, our systematic evaluation of various cryptographic techniques was epoch-making in its own right, and I believe that because of our efforts, Japan has made a considerable contribution to the advancement of cryptographic techniques. I expect, with great satisfaction, that this report will provide a helpful guideline toward ensuring that our forthcoming e-Government rests on a strong and solid foundation and truly hope that this report has provided sufficient policy and information on which we can base the successful management of future electronic commerce. In conclusion, I wish to express my deepest thanks and gratitude to Professor Hideki Imai, Committee Chairman, for his unceasing and untiring efforts and dedication to the furtherance of the CRYPTREC Evaluation Committee’s (CRYPTREC’s) efforts over the past 12 months. I would also like to express my sincere thanks to Professor Shigeo Tsujii, Committee’s Senior Advisor, for stating his opinions from a higher and broader viewpoint. Sincere thanks are also extended to subcommittee chairmen Professor Toshinobu Kaneko and Professor Tsutomu Matsumoto for their diligent efforts and unceasing enthusiasm. To all other committee members and government participants, please accept my most sincere gratitude for your positive and informative contributions.

March 2001 Masahiko Kobayashi General Manager The Security Center Information Technology Promotion Agency, Japan

2 CRYPTREC 2000

On the CRYPTREC Evaluation Committee Report

This report contains the results of the activities of the CRYPTREC Evaluation Committee (CRYPTREC) obtained over a 12-month period. 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 future development of Japan's 21st century networking capability -- the project achieved great success and made history 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 Group on Information Security Standard (Criteria) for Government Procurement” (proposed by Mr. Atsuhiro Yamagishi) via the Information Technology Promotion Agency, Japan (IPA), and “Study Group on Promotion and Advancement of Cryptographic Communications” (chaired by Professor Shigeo Tsujii of Chuo University) via the Ministry of 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, 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. 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-government and that cryptographic techniques will form the framework for this technology. Accordingly, one of the most essential tasks aimed at the furtherance of

3 CRYPTREC 2000

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 algorithms 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 established to share this duty of the government organizations is extremely heavy. However, the technological levels available for cryptography evaluation at this present 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 “verifiable security”. At the current technological levels, verifiable security implies a security level approved based on a certain assumption. It is certainly one important property to be considered when security is assessed. Even if, however, verifiable 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 on the first 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 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 safer 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 best possible evaluation results of cryptographic techniques available for the e-government at this present time, and therefore, I believe, will play an indispensable role in the implementation of the e-government in the future. However, this is only the beginning. This cryptographic technique evaluation project, which followed the example of the United States AES Project in evaluating proposed/submitted cryptographic techniques in accordance with evaluation criteria, was the first one aiming to define standard cryptographic algorithms for use within the Japanese government. Everything that has been learned from the fruitful results of this project indicates that there is still a great deal of work to be done. The project was carried out in a single year, which is an exceptionally short period for evaluation -- even if it is based on currently existing evaluation techniques. Therefore, most probably there

4 CRYPTREC 2000

are some shortcomings in this evaluation report. Correcting those shortcomings is one of the prime imperatives of the committee for the coming future, as well as striving hard to keep abreast of advancements in the rapidly evolving world of cryptographic technology. 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 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 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 Science 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 advantage of the researchers' network. Included among the committee and the subcommittee members were the designers of the cryptographic algorithms under evaluation. This was an unavoidable situation when choosing members with talents considered indispensable to this project from the extremely limited number of cryptography researchers in our country. 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 2001

Hideki Imai

Chairperson The CRYPTREC Evaluation Committee

5 CRYPTREC 2000

Information for Readers of This Report

This information contained in this report assumes that readers will possess basic and general knowledge of information security. Concerning e-Governance, for instance, it is assumed that readers will be engaged in business activities related to cipher, specifically as is used in such systems for electronic governance, including digital signatures and GPKI. However, as regards to the description of individual cryptography evaluation results, It is desirable that it be read by persons who possess a solid fundamental amount of knowledge of cryptographic techniques. Chapters 1 through 3 provide an overview of this cryptography evaluation project and the evaluation criteria used for cryptographic techniques. Chapters 4 through 7 briefly summarize the evaluation results of each cryptographic technique. Chapter 4 describes public-key cryptography. Chapter 5 describes symmetric ciphers of block ciphers and stream ciphers. Chapter 6 describes Hash functions, and Chapter 7 describes pseudo-random number generators. Chapter 8 briefly describes a worldwide trend towards cryptography standardization and is provided as reference information.

This cryptography evaluation is product of efforts by the CRYPTREC Evaluation Committee, which is composed of Japan's foremost cryptography experts. However, due to the rapidly evolving nature of cryptographic techniques, it cannot be assumed that this conclusions of this security evaluation will remain valid. Thus, it is indispensable that such evaluations continue for a meaningful period of time into the future. This cryptography evaluation was conducted in accordance with evaluation criteria submitted in response to a call for submissions for cryptographic techniques in June 2000. Therefore, it is probable that some of the cryptographic techniques will differ from those utilized for the same named product versions or from those proposed to other organizations, including ISO/IEC. For this cryptography evaluation, the scope of proposals was limited to cryptographic techniques whose specifications had been disclosed to the public, thus allowing contributors to obtain information concerning the specifications of cryptographic techniques under evaluation from applicants’ Web sites. Please be informed that this Committee is by no means responsible for any inadequacies, incompleteness etc., of the information provided. In implementing cryptographic techniques submitted for this cryptography evaluation, the recommended and utilized methodology was 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. Any opinions and/or comments are welcome. Fax: +81-3-5978-7510E-mail: crypt [email protected]

6 CRYPTREC 2000

1. Overview of Cryptographic Technique Evaluation For the creation of an e-Government, the infrastructure of which is to be prepared and built by the fiscal year 2003, it is important to secure a common base for security. Especially, cryptographic techniques, a set of IT security measures deemed indispensable to digital authentication as well as to securing stealth and preventing falsification of digitized information, are vital to the infrastructure and security of the e-Government. This report was prepared through a technical and professional evaluation of such functions of cryptographic techniques as security and implementation, which were assumed to be available for application to and use by the e-Government of Japan, and for promoting the appropriate use of cryptographic techniques. It is expected that this report will be fully taken advantage of, as a reference material for electronic governance-related procurement actions, electric signature laws and GPKI (Government Public Key Infrastructure) activities. Among important new activities in the world of cryptographic techniques, are a work plan of ISO/IEC to develop international standard criteria for cryptographic algorithms, the New European Schemes for Signature, Integrity and Encryption (NESSIE) project in Europe, and the Advanced Encryption Standard (AES) program to replace the Data Encryption Standard (DES) algorithm as the standard cryptographic algorithm. This project, conducted under the auspices of the Ministry of Economy, Trade and Industry, is an important part of the “Information Security Policy Promotion Program. This program is the Ministry of Economy, Trade and Industry’s contribution toward Secured Infrastructure of e-Government,” which was adopted by the Ministry of Economy, Trade and Industry In April 2000. For fiscal year 2000, the evaluation of cryptographic techniques was conducted by the “CRYPTREC Evaluation Committee (CRYPTREC)," a body consisting of Japan's top specialists in cryptography and cryptographic technology, and organized for the evaluation of cryptographic techniques. The results of this evaluation is based on discussions and examinations held in the committee. A call was issued for submissions for cryptographic techniques that could be applied in building systems within the e-Government, the infrastructure of which is scheduled to be created by fiscal year 2003. Valid cryptographic techniques that should be evaluated by the Committee were listed. This report contains the results of the detailed evaluation of 35 cryptographic techniques (27 submitted and 8 non-submitted). Submissions for proposed cryptographic techniques were open from June 13, 2000 through July 14, 2000, under the categories of public-key cryptosystems, symmetric ciphers, Hash functions and pseudo-random number generators. A total of forty-eight (48) cryptographic techniques were submitted. An evaluation subcommittee of the CRYPTREC Evaluation Committee was organized to discuss and examine methods of, and criteria for, evaluation. Two other evaluation subcommittees, the Public-Key Cryptography Subcommittee and the Symmetric-Key Cryptography Subcommittee were organized as

7 CRYPTREC 2000

well. The former discussed and examined the methods and results of evaluation of public-key cryptosystems, and the latter discussed and examined the methods and results of an evaluation of symmetric ciphers, Hash functions, and pseudo-random number generators. These Subcommittees relied on advice and guidance from the CRYPTREC Evaluation Committee. The cryptography evaluation was conducted in two phases -- screening and detailed. The screening evaluation was conducted from July through September 2000. The detailed evaluation was conducted from October through March 2001.

Table 1 Schedule for Evaluation Year 2000 Year 2001 June July August Sep-te Octo- No-ve De-ce Janu-a Feb-r March April mber ber m-ber m-ber ry uary Submitting proposals for cryptographic techniques Screening evaluation Detailed evaluation Announcement of ☆ evaluation results

The result of the cryptographic techniques evaluated in the detailed evaluation period was summarized into this Evaluation Report and is based on the results of external evaluations by external evaluators, domestic and foreign academic journals and software implementation evaluations. As a PR event, a cryptographic technique symposium was held on October 20, 2000, to ensure that the activities of this cryptographic technique evaluation process could be fully understood by both domestic and international cryptography engineers and users In addition, along with the publication of this report, a debrief session, the Cryptography Evaluation Meeting (tentative), will be held to ascertain the effectiveness of the evaluation of cryptographic techniques discuss future improvements.

8 CRYPTREC 2000

CRYPTREC Evaluation Committee Committee members (titles, etc. as of the end of March 2001)

Chairman Hideki Imai Professor, Institute of Industrial Science, University of Tokyo Committee Naoyuki Iwashita Manager, Research DivisionⅡ, Institute for Monetary and member Economic Studies, Bank of Japan Committee Eiji Okamoto Professor, Department of Information Science, Faculty of member Science, Toho University Committee Tatsuaki Okamoto Fellow, NTT Information Sharing Platform Laboratories, member Nippon Telegraph and Telephone Corporation Committee Toshinobu Kaneko Professor, Department of Electrical Engineering Faculty of member Science and Technology, Science University of Tokyo Committee Kouichi Sakurai Assistant Professor, Kyushu University , Faculty of Information member Science and Electrical Engineering Committee Ryoichi Sasaki Senior Chief Researcher, Systems Development Laboratory, member Hitachi, Ltd. Committee Shigeo TSUJII Professor, Dep. of Information Systems Engineering, Faclty of member Science and Engineering,Chuo University Committee Kenji Naemura Professor, Politics Media Graduate Course, Keio University member Graduate School Committee Mitsuru Matsui Team leader, Information Security Department, Information member Technology R&D Center, Mitsubishi Electric Corporation Committee Tsutomu Matsumoto Professor, Faculty of Engineering, Yokohama National member University

(Observers) Kazuo Sunaga Cabinet Counselor, Information Security Measures Promotion Office, Cabinet Secretariat Kazuyuki Takeichi Section Chief, Technological Measures Section, Info-Communications Bureau, National Police Agency Akihiko Nakajima Section Chief, Command Communications Division, Operations Bureau, Japan Defense Agency Kuniomi Takamori Director for Planning, Government Information Planning Division, Administrative Management Bureau, Ministry of Public Management, Home Affairs, Post and Telecommunications Taku Kiyasu Director of Standardization Division, Information and Communications Policy Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications Shingo Omori Director-General, Communications System Department, Communications Research Laboratory, Ministry of Public Management, Home Affairs, Posts and Telecommunications Hiroshi Goto Section Chief, Commercial Affairs Section, Civil Affairs Bureau, Ministry of Justice Satoru Nakada General Manager, Councilors’ Office, Minister's Secretariat, Ministry of Finance Yoshitaka Toui Director, Office of IT Security Policy, Business Affairs and Information Policy Bureau, Ministry of Economy, Trade and Industry

9 CRYPTREC 2000

Isao Hatta General Manager, General Manager, Information Electricity Standards Promotion Office, Industrial Technology Environment Bureau, Ministry of Economy, Trade and Industry Kazuhito Omaki Director, Computer Science Division, Electrotechnical Laboratory, National Institute of Advanced Industrial Science and Technology, Ministry of Economy, Trade and Industry

10 CRYPTREC 2000

Committee members of the Public-Key Cryptography Subcommittee (titles, etc. as of the end of March 2001)

Chairman Tsutomu Matsumoto Professor, Faculty of Engineering, Yokohama National University Committee Seigo Arita Assistant Manager, Security Technology Group, Internet member Systems Research Laboratories, NEC Corporation Committee Jun Kogure Senior Researcher, Secure Computing Lab., Computer Systems member Laboratories, FUJITSU LABORATORIES LTD. Committee Yasuyuki Sakai Information Security Department, Information Technology member R&D Center, Mitsubishi Electric Corporation Committee Hiroki Shizuya Professor, Education Center for Information Processing, member Tohoku University Committee Atsushi Shimbo Research Scientist, Computer and Network Systems member Laboratory, Corporate Research and Development Center, Toshiba Corporation Committee Masashi Takahashi Security Systems Research Center, Hitachi, Ltd., Systems member Development Laboratory Committee JinHui Chao Professor, Dept. of Electrical, Electronic and Communication member Engineering, Faculty of Science and Engineering, Chuo University Committee Atsushi Fujioka Senior Research Scientist, Information Security Project, NTT member Information Sharing Laboratories, Nippon Telegraph and Telephone Corporation Committee Natsume Matsuzaki Multimedia Development Center, Matsushita Electric Industrial member Co., Ltd. Committee Atsuko Miyaji Associate Professor, School of Information Science, Japan member Advanced Institute of Science and Technology

Committee members of the Symmetric-Key Cryptography Subcommittee (titles, etc. as of the end of March 2001)

Chairman Toshinobu Kaneko Professor, Department of Electrical Engineering Faculty of Science and Technology, Science University of Tokyo Committee Kiyomichi Araki Professor, Department of Electrical and Electronics member Engineering, Science and Engineering Graduate School, Tokyo Institute of Technology Committee Toru Koda Professor, Kyushu University , Faculty of Information Science member and Electrical Engineering Committee Shinichi Kawamura Senior Research Scientist, Computer & Network Systems member Laboratory, Corporate Research and Development Center, Toshiba Corporation Committee Masayuki Kanda Research Engeneer, Information Security Project, NTT member Information Sharing Platform Laboratories, Nippon Telegraph and Telephone Corporation Committee Kazukuni Kobara Research Associate, Institute of Industrial Science, University member of Tokyo

11 CRYPTREC 2000

Committee Kouichi Sakurai Assistant Professor, Kyushu University , Faculty of member Information Science and Electrical Engineering Committee Takeshi Shimoyama Secure Computing Lab., Computer Systems Laboratories, member FUJITSU LABORATORIES LTD. Committee Kazuo Takaragi Chief Researcher & Manager, Security Systems Research member Center, Systems Development Research Laboratory, Hitachi, Ltd. Committee Makoto Tatebayashi Chief Engineer, Multimedia Development Center, Matsushita member Electric Industrial Co., Ltd. Committee Yukiyasu Tsunoo Principal Researcher, Security Technology Group, Internet member Systems Research Laboratories, NEC Corporation Committee Toshio Tokita Information Security Department, Information Technology R member & D Center, Mitsubishi Electric Corporation Committee Masakatsu Morii Professor, Intelligence Information Engineering Division, member Engineering Department, University of Tokushima

12 CRYPTREC 2000

Observers of the Public-Key Cryptography Subcommittee and the Symmetric-Key Cryptography Subcommittee (titles, etc. as of the end of March 2001)

Masahiro Masuga Command Communications Division, Operations Bureau, Japan Defense Agency Noriyasu Matsui Command Communications Division, Operations Bureau, Japan Defense Agency Hidetaka Imazumi Government Information Systems Planning Division, Administrative Management Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications Takeshi Tandai Standardization Division, Information and Communications Policy Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications Kiyoharu Imai Standardization Division, Information and Communications Policy Bureau, Ministry of Public Management, Home Affairs, Posts and Telecommunications Akihiro Yamamura Emergency Traffic Research Office, Communications System Division, Communications Research Laboratory, Ministry of Public Management, Home Affairs, Posts and Telecommunications Atsushi Kuwabara Information Security Policy Planning Office, Information-technology Promotion Division, Information Industries Bureau, Ministry of International Trade and Industry Mondo Yamamoto Office of IT Security Policy, Business Affairs Policy Planning Bureau, Ministry of Economy, Trade and Industry Yuji Tanabe Office of IT Security Policy, Business Affairs Policy Planning Bureau, Ministry of Economy, Trade and Industry Shinji Ishii Office of IT Security Policy, Business Affairs Policy Planning Bureau, Ministry of Economy, Trade and Industry Yoshiyuki Hirano Information Electricity Standardization Promotion Office, Standardization Division, Industries Engineering Environment Bureau, Ministry of Economy, Trade and Industry Hajime Watanabe Computer Science Division, Electrotechnical Laboratory, National Institute of Advanced Industrial Science and Technology, Ministry of Economy, Trade and Industry Kazumaro Aoki Research Planning Division, Research Planning Administration Department, Telecommunications Advancement Organization of Japan

(Secretariat) Cryptographic Techniques Research Office Security Center Information Technology Promotion Agency, Japan

13 CRYPTREC 2000

2. Solicited Cryptographic Techniques 2.1 Categories of Solicited Cryptographic Technique Cryptographic technology has a long history. In terms of cipher used in e-Government, it refers to modern cryptographic techniques whose research activities expanded rapidly in the latter half of 1970's. One of the most distinctive features of modern cryptographic techniques is that procedures for encryption and decryption are widely available to the public. Modern cryptographic techniques are broadly classed as symmetric ciphers, represented by DES (Data Encryption Standard) which was opened to the public in 1976, and public-key cryptosystems, represented by the RSA cipher scheme proposed by Rivest-Shamir-Adleman. These two types of ciphers support three security functions: confidentiality, signature, and authentication. Symmetric ciphers are mainly used for confidentiality while public-key cryptosystems are chiefly used for signature and authentication. Both of these ciphers are usually used in a system so that their features can be each be the complementary half of an integral whole. For instance, when both the transmitter and the receiver share a secret key (symmetric-key) in symmetric cipher, the key sharing function of public-key cryptography is used. When a digital signature is created in public-key cryptography, the digital signature created after the plaintext is processed with cryptographic Hash function(s). A pseudo-random number generating scheme is required for generating key pairs of public-key cryptography (public- private key pairs), secret keys (symmetric-keys), or key seeds. This pseudo-random number generating scheme is required for many public-key cryptographys as a random number source when functions of confidentiality and signature require implementation. Symmetric ciphers are divided into block ciphers and stream ciphers based on their data processing structure. Block ciphers process data one block at a time, while stream ciphers process data bit by bit in a stream. Figure 2.1.1 shows a classification of solicited cryptographic techniques.

14 CRYPTREC 2000

Confidentiality

Signature Public-Key Systems rporpi Techniques Cryptographic Authentication

Key Sharing

Block Ciphers Symmetric Ciphers Stream Ciphers

Hash Functions

Pseudo-Random Number Generating Schemes

Figure 2.1.1 Classification of Solicited Cryptographic Techniques

15 CRYPTREC 2000

2.2 Public-key cryptography When evaluated from the viewpoint of information security, public-key cryptographys are broadly classed as integer factoring problems, discrete logarithm problems and discrete logarithm problems on elliptic curves. In terms of function, they are classed as signature, confidentiality, key sharing, and authentication. In this cryptography evaluation, solicited cryptographic techniques, classed by function (a combination of a cryptographic scheme and primitive/ auxiliary function), were evaluated. Here, a cryptographic scheme refers to an algorithm used to stimulate its functions using cryptographic primitives and auxiliary functions (cipher auxiliary functions). It consists of requirements for cryptographic primitives, requirements for auxiliary functions, and a description of the algorithm. A cryptographic primitive refers to a cryptographic primitive algorithm that offers security based on security proof, including integer factoring problems, discrete logarithm problems, and discrete logarithm problems on elliptic curves. An auxiliary function refers to a factor, including Hash functions, random numbers (pseudo-random numbers) required, besides the cryptographic primitive, for a cryptographic scheme to perform its function.

2.2.1 Public-Key Cryptosystem for Confidentiality The Confidentiality function helps the transmitter and the receiver to share arbitrary information between them in secrecy. Confidentiality for a huge amount of data is usually implemented by using symmetric ciphers. Public-key cryptography is occasionally used for the cryptographic communication of small amounts of information. The procedure is shown below.

［Transmitter A］［Receiver B］

B’s "public-key" B’s "secret key"

Communications channel

Public-key Public-key Information cryptography cryptography Information (encryption) (decryption)

Figure 2.2.1 Example of Confidentiality Function Using Public-Key Cryptography

16 CRYPTREC 2000

Step 1: The receiver B generates a public-private key pair and discloses the public key. Step 2: The transmitter A obtains the receiver B’s public-key, encrypts information (plaintext) to be transmitted using B’s public-key, and transmits it to the receiver B. Step 3: The receiver B receives information (plaintext) by decrypting the received ciphertext using his private key.

17 CRYPTREC 2000

2.2.2 Public-Key Cryptosystem Implementing Signature Function The signature function helps to confirm the validity of digital information. Validity of digital information refers both to the function used to confirm who has created the signature and to the function used to confirm whether or not there has been tampering with the digital information itself. The outline of the procedure is shown below.

［Signature sighed by A］［Signature verified by B］ Communications channel

Digital Verification Generation Verification document result

Verification and decryption key (A’s "public-key")

Signature generation key (A’s "secret key") Decryption Digital document

Figure 2.2.2 Example of Signature Function Using Public-Key Cryptography Techniques

Step 1: A generates a public-private key pair and discloses the public key. Step 2: A prepares a digital document with a signature using a private key. Step 3: A transmits the digital document with a signature to B. Step 4: B decrypts the digital document and obtains the verification result by processing the digital document with a signature using A’s public key.

18 CRYPTREC 2000

2.2.3 Public-Key Cryptosystem Implementing Authentication Function The authentication function is used to confirm the validity of the other party to be authenticated. This function can be implemented using symmetric ciphers, but public-key cryptosystem are occasionally used to avoid complexity of the key control. Authentication of the other party using a public-key cryptosystem refers to use of a technology that helps to prove the presence of a secret key (private key) corresponding to a public key by transmitting and receiving information between the party to authenticated and the party performing validation. This is done in accordance with a pre-defined procedure (authentication protocol), utilizing public-key signature function cryptosystem technology or public-key confidentiality function cryptosystem technology, and by utilizing the secret key held secretly by the other party to be and the public-key used for verification. An authentication function sample using public-key cryptography techniques is shown in Figure 2.2.3.

［Party performing validation］［The party to be authenticated］

Randomly generated data

" Secret-key" of the party to be authenticated Communications channel

Public-Key Public-Key Matching Cryptosystem Cryptosystem

OK/NG "Public-key" of the

party to be authenticated Figure 2.2.3 Example of Authentication Function Using Public-Key Cryptosystem (2-move type)

Step 1: The party to be authenticated generates a public-private key pair, and the public key is exposed to the public. Step 2: The party performing validation transmits arbitrary information generated by a random number generator to the other party to be authenticated. Step 3: The other party to be authenticated generates the ciphertext of the transmitted information (signature) by using the secret key of the party to be authenticated. Step 4: The ciphertext is transmitted to the party performing validation.

19 CRYPTREC 2000

Step 5: The party performing validation obtains the plaintext by decrypting the transmitted ciphertext using the public-key of the other party to be authenticated. Step 6: The received plaintext and the generated digest are compared for authentication purposes. If they match, the party to be authenticated is considered to be “valid." If not, the party to be authenticated is considered to be "invalid."

20 CRYPTREC 2000

2.2.4 Public-Key Cryptosystem Implementing Key Sharing Function Key sharing/distribution refers to a scheme under which “key” information is shared/distributed between the transmitter and the receiver at the time symmetric cipher technology is used. Public-key cryptosystem technology is mainly used for large-scale systems multiple users. Key sharing based on public-key cryptosystem technology is also implemented using public-key cryptosystem with the confidentiality function described above. The following is a procedure used for the D/H key sharing key sharing mechanism, proposed by Diffie and Hellman.

［User A］［User B］

Random number XA is generated. Random number XB is generated. Communications channel

User B’s public-key information User A’s public-key information

is operated, and the result Y is is operated, and the result Y is A B transmitted to User B. transmitted to User A.

Key information is generated Key information is generated

(shared), using Y and X (shared), using Y and X B A. A B.

Figure 2.2.4: Example of the Key Sharing Mechanism Using Public-Key Cryptography (DH type)

Step 1: Information for public distribution to be shared by the whole system is generated and distributed to each user. (In the D/H key sharing mechanism, prime number p and primitive root α are disclosed to each user.)

Step 2: User A generates a random number XA. (XA is specified as User's A’ secret key.)

Step 3: User A’s public-key YA is generated from the random number XA and the disclosed information shared by the system.

X A (In the D/H key sharing mechanism, YA = α mod p is generated as User A's public key.) Step 4: User B generates a random number XB. (XB is specified as User's B’ secret key.)

Step 5: User A's public-key YB is generated from the random number XB and the disclosed information shared by the system.

X B (In the D/H key sharing mechanism, YB = α mod p is generated as User B's public

21 CRYPTREC 2000

key.) Step 6: User A and user B exchange public-key YA and public-key YB between the two. Step 7: Shared key K is generated from the secret keys and received public-keys. (In the D/H key sharing mechanism, User A and user B calculate

X A X A X B X B X B X A K = ()YB mod p = α mod p and K = (YA ) mod p = α mod p

respectively, and the result K is specified as the shared key.)

22 CRYPTREC 2000

2.3 Symmetric Cipher Technology 2.3.1 Block Ciphers A block cipher breaks the plaintext into blocks of the same size for encryption. For many block ciphers, the block size is 64 bits or 128 bits. A 64 bit block cipher is divided into blocks with a size of 64 bits. A 128 bit block cipher is divided into blocks with a size of 128 bits. A block cipher consists of a data randomizing part and key scheduling part (See Figure 2.3.1).

Plaintext (64 bit or 128 bit)

Key scheduling part

Extended Data randomizing key part Secret-key

Ciphertext (64 bit or 128 bit)

Figure 2.3.1 Simplified Diagram of a Block Cipher

As seen in the result of the DES-Challenge Ⅲ contest, the current state of processing performance and the speed of computer evolution had to be taken into consideration. Block ciphers with secret keys of 128 bits or longer were solicited for the year 2000 evaluation. The key scheduling part generates an expansion key from the secret key used in data randomizing part. Plaintext is converted into ciphertext based on the expansion key, which is input into the data randomizing part. In decryption, ciphertext is transformed into plaintext by using the same key as used in encryption. Feistel Structure and SPN Structure are typical of data randomizing part (See Figure 2.3.2).

23 CRYPTREC 2000

S layer F

function P layer

S layer

F Extended key P layer function

F S layer function

Round function

(i) Feistel Structure (ii) SPN Structure

Figure 2.3.2 Typical Structures of Data Randomizing Part

In Feistel Structure the input is divided into two parts. One part, which is input into F function, repeats the structure influencing the other part. This F Function is composed of non-linear functions, including S-box. In SPN Structure the input is not divided. It repeats round functions composed of S Layer (non-linear) and P Layer (linear). The number of this repetition inside F functions or round functions is called “number of rounds.” In addition, Feistel Structure is extended into various types, as shown in Figure 2.3.3 (i) and Figure 2.3.3 (ii). Here, just for convenience, these are named transformed Feistel structures. Block ciphers have some modes of operation. The one shown in Figure 2.3.1 is called ECB Mode.

24 CRYPTREC 2000

F F F function function function

F F function function

F function

F F function function F function

(i) (ii) Figure 2.3.3 Sample of Transformed Feistel Structures

2.3.2 Stream Ciphers A stream cipher, unlike a block cipher which operates on blocks of data, operates on plaintext sequences, usually bits. (An encryption method that works with continuous streams of input rather than fixed blocks.) Ciphertext sequences are obtained by logically adding key sequences exclusively to plaintext sequences (Figure 2.3.4).

Secret-key

Key sequence generator

Key sequence

Plaintext sequence Ciphertext sequence

Figure 2.3.4 Sample of Stream Cipher Structures

25 CRYPTREC 2000

Various structures are available for Stream, and therefore, unlike block ciphers, stream ciphers have no such typical structure. During the decryption process, plaintext sequences are obtained by logically adding key sequences exclusively to ciphertext sequences. Various structures are available for Stream, and therefore, unlike block ciphers, stream ciphers have no such typical structure. During the decryption process, plaintext sequences are obtained by logically adding key sequences exclusively to ciphertext sequences.

2.4 Hash Functions Hash functions for cipher were also solicited for the year 2000 evaluation, with the assumption that password authentication, digital signature, and message authentication were used. Therefore, the performance required of cryptographic Hash functions are unidirectionality and no collision. Unidirectionality refers to a property that makes it impossible for input to be computed from output. Collision refers to a property that outputs the same hash value against two different inputs. Due to the same factors as taken into consideration for block ciphers, stream ciphers with hash values of 128 bits or longer were solicited for the year 2000 evaluation.

2.5 Pseudo-random Number Generating Scheme A pseudo-random number generating scheme is assumed to be used for generating cryptographic keys and key seeds. A pseudo-random number generating scheme, although it is similar to true number generating scheme in terms of property, provides such poor uniformity that sufficiently large random numbers cannot be expected for this type of usage, when it uses, for instance, the user's keyboard input interval time. Pseudo-random number generating schemes, solicited for the year 2000 evaluation, were expected to produce a sufficient amount of random numbers required to meet the above-mentioned needs, with a sufficiently low probability of generating specific numbers, and with a uniform distribution of random numbers. In addition, since it is required for cipher usage, it requires the ability to generate high quality random numbers that will make it almost impossible to forecast through quantitative calculation. Lastly, any physical random numbers that require use of special equipment was disqualified from submitting a proposal for cryptographic techniques.

26 CRYPTREC 2000

3. Overview of Cryptographic Technique Evaluation 3.1 Purpose of the Evaluation The proposed cryptographic technologies were evaluated from security and implementation aspects. Evaluation on implementation was addressed from software (SW) implementation and hardware (HW) implementation viewpoints. Evaluation of proposed cryptographic schemes was based on the results of evaluation conducted at two different stages. The first stage of design evaluation contained verification of security attestation and validity of assumption. The second stage of implementation evaluation contained an evaluation of countermeasures against various attacks that might be expected after designing work. Unfortunately, for both stages of the security evaluation, design evaluation and attack evaluation, statistical and quantitative evaluation is insufficient. That is, evaluation from a viewpoint of cryptographic analysis technology is indispensable as well. Analysis and design of a cryptographic scheme are the two sides of the same coin. In other words, in the evaluation of cryptographic strength, some conditions for decipherment (use environment, attacker’s calculation etc.) are assumed. Under this assumption, the calculational loads required to identify an employed cryptographic key by utilizing the information quantity required (the amount of plaintext or ciphertext required to be collected) and the information actually collected, is shown by decrypting through an adequate decrypting technique. Cryptographic strength is typically evaluated by utilizing information quantity and information actually collected. As a matter of fact, the number of cryptographic analysis applied for evaluation should not be limited to a single technique; that is, evaluation utilizing more than one cryptographic analysis techniques is indispensable. Evaluation standards vary in accordance with environments in which the cryptographic techniques are used and conditions under which cryptographic techniques are applied. Therefore, a security evaluation should be performed based on more than one decrypting technique. When using the evaluated cryptographic techniques, an "overall judgment" should be made, taking into consideration various factors, such as the system’s information security policy, environments in which cryptographic techniques are used, and conditions under which cryptographic techniques are to be applied. Figure 3.1 shows how cryptographic analysis techniques, cryptographic design technique and safe ciphers are related to each other.

Secure cryptographic systems

Cryptographic Cryptanalytic design methodology techniques

Figure 3.1 Safe ciphers and Design/Analysis Techniques

27 CRYPTREC 2000

In addition, in terms of security evaluation, a systematic evaluation of security should also be included with the evaluation results shown in this report. Systematic evaluations are to be performed based on the ISO/IEC 15408 Common Evaluation Criteria (CC=Common Criteria), etc. In addition, cryptographic techniques implemented on a real system need further evaluation. Furthermore, in terms of evaluation on implementation viewpoints, implementation characteristics should be taken into account, based on the security policy of the applied system.

3.2 Screening Evaluation and Detailed Evaluation Evaluation was conducted in two phases: screening and detailed. (i) Screening Evaluation During the screening evaluation, a decision was made the proposed cryptographic techniques met the criteria indicating the need for more detailed evaluation, based on the submitted documents. The items examined in the screening evaluation were as follows: ・ A check was performed to confirm that each required item of information needed for the detailed evaluation (presence of description, logical consistency/self-sufficiency in submitted documents) had been provided. ・ An examination was performed to determine if there were any shortcomings (of decipherment techniques, etc.) that could easily found in the submitted documents. ・ The proposed cryptographic technique specifications were examined to confirm whether the Self-Evaluation information was sufficient and valid (whether or not it was adequate). (ii) Detailed Evaluation Detailed evaluation included evaluation of security and of implementation (software implementation and hardware implementation). The security evaluation performed had two phases; a integrated evaluation of existing cryptographic analysis techniques (attack methods), which was conducted by external cipher experts both in Japan and abroad, and a check for the existence of shortcomings (of decipherment methods) peculiar to the proposed cryptographic techniques. In the software implementation evaluation, speed was evaluated utilizing sample codes implemented by submitters on a unified platform. For hardware evaluation, cipher implementation researchers in Japan were asked to estimate the number of gates and the processing speed on the assumption that hardware was to be implemented in the process of FPGA1 or GA2.

1 FPGA: an abbreviation of Field Programmable Gate Array 2 GA: an abbreviation of Gate Array For the platform used in this Project, GA of nearly 0.3μm was assumed.

28 CRYPTREC 2000

3.3 Evaluation Criteria for Asymmetric Cryptographic Schemes 3.3.1 Security Evaluation Criteria Submitted cryptographic schemes, in a broader definition of the expression (hereinafter named Cryptographic Scheme3), included procedures (cipher protocol) which could be used to implement one for confidentiality, authentication, signature, or key sharing. It was then evaluated in terms of security, based on the assumption that a basic cryptographic algorithm meeting the requirements for specified cryptographic scheme (hereinafter named Cryptographic Primitive4) and its auxiliary function(s) existed. The cryptographic primitive(s) and auxiliary function(s) used in the proposed sample implementation were evaluated to determine if they were appropriate and valid for the specified requirements. In addition, recommended parameters and primitives were evaluated to determine whether they were vulnerable to the most likely forms of attack. (a) Security evaluation items for cryptographic schemes The most likely forms of attack against the proposed cryptographic scheme were selected, and the behavior of the cryptographic scheme when varying the methods and goals of the attacks against it was evaluated in terms of security. For each combination of the methods and attack goals, the security of the scheme was evaluated from aspects such as, if it had a proof of security, if it could be considered to be heuristically secure, and so on. Attack methods used included active attacks, passive attacks, and other attacks Goals of attacks: influence on the security function to be implemented (confidentiality, authentication, signature, or key sharing) (b) Security evaluation items for cryptographic primitives For each cryptographic primitive, the security against well-known attacks, based on integer factoring problems, discrete logarithm problems, elliptic curve discrete logarithm problems as security proof, was evaluated. (i) Evaluation items for primitive cipher based on integer factoring problems Computational strength against well-known attacks and other attacks particular to the primitive (ii) Evaluation items for cryptographic primitives based on discrete logarithm problems on finite fields Computational resistance against well-known attacks and other attacks particular to the primitive (iii) Evaluation items for cryptographic primitives based on discrete logarithm problems on elliptic curves Computational resistance against well-known attacks and other forms of attack particular to the primitive

3 Cryptographic scheme: a cryptographic scheme in a broader definition of the scheme, which includes a procedure (cipher protocol) used to implement such function as signature, key sharing and so forth. 4 Cryptographic Primitive: a basic cryptographic algorithm that provides information security functions

29 CRYPTREC 2000

(iv) Evaluation items for cryptographic primitives based on other security proofs Well-known attacks against security proofs and other forms of attack particular to the primitive

3.3.2 Evaluation of Software Implementation For the year 2000, software implementation evaluation was performed, based on the actual code(s) prepared by applicants to confirm whether or not the main program for implementation was valid . In terms of security, evaluation was conducted based on the strength of RSA (cipher based on integer factoring problems) 1024 bits or longer. Software evaluation items were as follows: ・ Submitted cryptographic techniques specifications (In order to determine whether the proposed technological information was accurate and sufficient enough for third parties to implement the software) ・ Executability evaluation on the specified platform (No special hardware or huge amounts of memory should be required) ・ Evaluation of resource use quantity, including processing speed and memory, on the specified platform

Platform Specified: CPU : PentiumIII (650MHz) OS : Windows98 SE Memory installed : 64MB Compiler : Visual C++ Ver.6.0 SP3

30 CRYPTREC 2000

3.4 Evaluation Criteria for Symmetric Cryptographic Schemes 3.4.1 Security Evaluation Criteria The security evaluation criteria consists of security in information quantity and security in computational complexity. Information security based on the information theory was developed by Shannon. The amount of a key should be more than that of a plaintext in order to satisfy the requirements. This is not realistic in an operational sense. Security of symmetric ciphers is shown in terms of computational security, not in terms of information theory. Computational security refers to the degree of computational difficulty of “guessing correctly” what the secret key is. However, there is no such absolute evaluation method by which computational security is explicitly shown. Accordingly, actual attacks are attempted, and security is evaluated in terms of cost (amounts of calculation required, of data, and of memory), which is required for the attacks. Since actual attacks should be performed, it should be assumed that cryptographic algorithms are publicly known and available to the public. Under the conditions available to attackers, attack methods are generally classified as follows: ・Ciphertext only attacks Attacks where only ciphertext is available ・Known plaintext attacks Attacks where ciphertext corresponding plaintext is available Attackers attempt penetration using plaintext-ciphertext pairs somehow. ・Chosen-plaintext attacks Attacks where plaintext arbitrarily selected by attackers and ciphertext corresponding to it are available Plaintext ciphertext pairs propitious for attackers are available, since attackers may have access to cipher generators Difficulty varied in attacks, though it depends on the information available to attackers. Chosen-plaintext attacks are the most advantageous, known plaintext attacks the second most advantageous, and ciphertext only attacks the least advantageous to attackers. If a cryptographic scheme can be attacked by ciphertext only attacks, nobody will believe that the scheme provides sufficient security. The attacks described above have a condition that plaintext corresponding to a sufficient amount of ciphertext is well-known. If attackers have an infinite comptation time, an exhaustive search will eventually yield the secret key. From an academic viewpoint, it is assumed that an attack will be successful if the cost required for the attack is less than that required for exhaustive search. To put it concretely, if an attack method by which a cipher using k bits can be attacked at less cost, the cipher is insufficiently secure. Taking into account present day trends, such as DES-Challenge Ⅲ (a DES code-breaking contest held in January 1999; in which the user key (56 bits) was decrypted in about 22 hours) and rapid advancements in processing speed, it is estimated that the cost of nearly 264 is allowed.

31 CRYPTREC 2000

Therefore, even no problems exist for practical purposes even if it is possible to attempt an attack with a

k 64 cost of less than 2 (> 2 ), the situation as described above suggests that it should not be relied upon for a long period of time. Roughly speaking, attack methods can be broken down into two types -- general-purpose attacks applicable to ciphers included in the same category and specific attacks aimed at individual ciphers. For proposed ciphers belonging to the same category, two different evaluations were conducted: lateral and individual. In the lateral evaluation, general-purpose attacks were applied and attempted by the same evaluator against ciphers belonging to the category. In the individual evaluation, attacks were attempted to locate weak points peculiar to each proposed cipher. The results of these evaluations were briefly summarized into an inclusive report. Symmetric ciphers provide 64 bit block ciphers, 128 bit block ciphers, and stream ciphers. Refer to Section 5.1.1 for detailed information on 64 bit block ciphers. Refer to Section 5.1.2 for detailed information on evaluation of security concerning 128 bit block ciphers. Refer to Section 5.1.3 for detailed information on evaluation of security concerning stream ciphers.

(1) Block ciphers In evaluation of block ciphers for the year 2000, strength against general-purpose attacks was evaluated on the following items: ・Differential cryptanalysis ・Linear cryptanalysis ・Higher order differential cryptanalysis In addition, avalanche evaluation, where statistical properties of output were evaluated, was conducted.

Differential cryptanalysis and linear cryptanalysis Differential cryptanalysis was proposed by Biham and Shamir in 1990. Differential cryptanalysis, the first attack on DES, is a general-purpose attack technique that is applicable to the whole block cipher. It is one of the chosen-plaintext attacks applicable to two pairs of plaintexts and ciphertext when there is a correlation between the difference in the plaintexts and that in the ciphertexts. Linear cryptanalysis was proposed by Matsui of Mitsubishi Electric Corporation in 1993. Linear cryptanalysis, proposed as an attack on DES like differential cryptanalysis, is a general-purpose attack technique that is applicable to the whole block cipher. It is one of the most well-known plaintext attacks, and is applicable when there is a correlation between exclusive-OR of specific input bits and that of output bits. Resistance against these attacks is given in maximum differential probability and maximum linear probability. Security is assured when these probabilities remain small. It is difficult, however, to obtain true values of maximum differential probability and maximum linear probability. Thus, in their place,

32 CRYPTREC 2000

maximum differential characteristics probability and maximum linear differential characteristics probability are sometimes used. These values are estimated by the following: 1. By obtaining the upper bound of probability through evaluation of each component 2. By obtaining probability through computer search

Provable security against differential cryptanalysis and linear cryptanalysis attacks Some of the submitted cryptographic schemes attempted to show that they had a provable security against differential cryptanalysis and linear cryptanalysis attacks. In 1992 Nyberg mathematically proved that when F function’s maximum differential probability against a block cipher of Feistel structure is p, the maximum differential probability of the entire block cipher is 2p2 or less, if a minimum of four rounds is provided. Later, Nyberg’s mathematical proof was unified as a provable security measure against differential cryptanalysis and the linear cryptanalysis attacks, with a similar index as that given to linear attacks. Nyberg’s mathematical proof was developed by Matsui and Aoki into a higher level of discussion and is now a technique in which security can be mathematically proved. It should be noted, however, that this is a provable security that is only valid for differential cryptanalysis and linear cryptanalysis attacks.

Higher order differential cryptanalysis attack A Higher order differential attack, proposed by Lai in 1994, was employed by Knudsen and Jakobsen in an attack against the KN cryptographic scheme of experimental block ciphers. The higher order differential value of output is one of applicable chosen-plaintext attacks when it is to be a constant independent from plaintext fixed values and expanded keys. The KN cryptographic scheme has a provable security against the above-mentioned differential/linear cryptanalysis attacks. It has been proposed that it is possible to attack the KN cryptographic scheme by using higher order differential cryptanalysis, since the algebraic degree of its F function is small. The effect of an attack depends on the number of rounds used. The smaller the number is, the less the cost. On the other hand, the algebraic degree of output depends on what bit of plaintext is to be selected as variable. Thus, the minimum number of rounds required for an attack depends on how the variable bit is selected. At this date, however, there is no best selection method. For a cryptographic scheme of N bit I/O, the algebraic degree of output does not exceed N even if all input bits are to be variables. In general, however, It is assured that a cryptographic scheme has a proof of security when a formal algebraic degree of output block larger than N.

Evaluation of avalanche property Evaluation of avalanche property refers to an evaluation used to check how often differentials appear by output bit location when specific differential values are given to output; thus, describing the behavior at each output bit position. This evaluation method not only treats a cryptographic algorithm as a black

33 CRYPTREC 2000

box, but also digitizes the evaluation, thus enabling an integrated comparison of cryptographic algorithms. Targeted items of the evaluation of avalanche property were encryption processing including key scheduling part, and input/output in a single key scheduling part and a single round function. Appearance frequencies of differentials, diffusion of differentials, correlation coefficients where differentials appear, items of effective key size were examined. In general it may be said that all symmetric ciphers are composed of the following: ・Round function ・Data randomizing part ・Key scheduling part Accordingly, the following items were evaluated in the evaluation of avalanche property: (1) Single round function (2) Data randomizing part (3) Single key scheduling part The following items were evaluated, based on these evaluation results: (4) The entire encryption processing including the key scheduling part

Evaluation items The following items of Avalanche evaluation were examined and evaluated: (1) AVA : Difference in frequencies whose output differential values are to (appearance frequency of be 0 and 1. In the year 2000 evaluation, input differential was differentials) ⊿X. Hamming weights of key differential ⊿K, m=1, 2 were also evaluated and examined. (2) AVD : Average value of Hamming weights of output differential (diffusion value of differentials) values (3) CC : Correlation coefficient of output differential values at ith bit (correlation coefficient where position and jth bit position differentials appear) (4) UKV (effective key quantity) : Ratio of evaluation values, which satisfy relative standard values, to AVA, where key differential value of Hamming weight 1 is given

Constituent elements of symmetric ciphers and targeted statistical properties of the whole system are broadly classed as follows: ・Correlation of input and output ・Correlation of key and output

Techniques for statistical authorization The pseudo-random number generating function must be implemented for such statistical data

34 CRYPTREC 2000

authorization. In addition, it is necessary to generate random number series by using the pseudo-random number generating function. Authorization is conducted after these obtained data are collected and analyzed. ・It is assumed that there is no statistical bias if the worst deflection rate of AVA is below the relative standard value ・The closer to AVD n/2 is, the less the statistical bias is (output data length n). ・The absolute value of CC is 1 or less, where it is assumed that the closer to 0 it is, the stronger its independence is. ・Key data lengths closer to UKV are preferable.

(2) Stream Ciphers A stream cipher, in general, specifies output from a pseudo-random number generator as a key sequence, the initial value of which is then specified as a secret key. In this report, the following items of evaluation, described in FIPS-140-1/2, were chosen and employed in order to evaluate statistical properties of output sequences: ・Long periodicity ・Linear complexity ・Frequency of 0/1, etc. ・Monobit test ・Poker test ・Runs test ・Long run test These items were evaluated solely for further examination and scrutiny of statistical properties. High marks of evaluation on statistical properties do not necessarily mean that the actual cryptographic scheme is sufficiently secure. Thus, resistance against general purpose attacks, including Divide-and-Conquer Attack and Correlation Attack, were evaluated, using the same general criteria that Individual evaluations were performed for block ciphers.

35 CRYPTREC 2000

3.4.2 Evaluation of Software Implementation Cryptographic schemes should be evaluated, not only in terms of security, but also in terms of implementation, taking into account how they are actually to be employed. Requirements for the implementation of cryptographic schemes in the designed e-Government are still unknown at this point in time. For software implementation evaluation, the following three environments have been assumed: the PC environment that is seemingly most commonly used at the time of evaluation, a server environment which is the most widespread present, and a high-end environment in which high performance is actually implemented. All submitted cryptographic schemes were evaluated taking into consideration the most commonly used PC environment at present, because it can be assumed that it will be the environment in which any one selected cryptographic scheme will be implemented. To further demonstrate the capability of each cryptographic scheme design, one of the other two environments was selected by the applicant as a location for further evaluation. Taking a realistic point of view, we are fully aware that evaluation of the submitted cryptographic schemes in low-specification environment should also have been done. However, the extremely limited period of time available time for evaluation forced us defer this evaluation technique. In addition, Hash functions and pseudo-random number generating schemes were not examined in the software evaluation. A proposed cryptographic scheme program was applied to a real system or an application by the applicant. The evaluation was carried out in the presence of the committee member(s). Evaluation was performed, using the same hardware and evaluation programs, under the most impartial conditions possible. Moreover, there may be minor variations in evaluation values according to documents you refer to. Some of the evaluation values may be different from those provided in this report, depending on the actual evaluation program(s) and/or evaluation environment(s) employed. It is also possible that, even if the same hardware and evaluation program are used, evaluation results may greatly vary depending on the operating system and resident programs. Accordingly, please note that the numerical values shown in this Report may not be achieved in subsequent reevaluations. Additionally, please note that this evaluation of software implementation also aimed at comparing trends in processing speed implemented by the submitted cryptographic schemes. The hardware environment used for this evaluation of software implementation was as follows:

1. PC environment CPU : Pentium III (650MHz) OS : Windows98 SE Memory installed : 64MB Compiler : Visual C++ Ver6.0 SP3

2. Server environment

36 CRYPTREC 2000

CPU : Ultra SPARC Ⅱi (400MHz) OS : Solaris 7 Memory installed : 256MB Compiler : Forte C 6

3. High-end environment CPU : Alpha21264 (463MHz) OS : Tru64 UNIX V5.1 Memory installed : 512MB Compiler : DEC C

Concerning block ciphers, the following two items were evaluated: 1. Data randomizing part 2. Key scheduling part plus data randomizing part The data randomizing part was evaluated, based on the complexity which is independent from an operational frequency of the CPU (for 64 bit block ciphers, for instance, by counting the cycle of the CPU required to convert 64 plaintexts into ciphertexts). For 128 bit block ciphers, it was evaluated by counting the cycle of the CPU required to convert 128 bit plaintexts into ciphertexts. This evaluation was done by specifying keys to 1MB plaintexts (ciphertexts) to be encrypted (decrypted). Therefore, the amount of calculation required for the setup of keys could be ignored. For one evaluation event, 1MB encryption (decryption) was repeated 128 times, through which the maximum speed and the average values were collected. Each evaluation was repeated three times. For evaluation of the key scheduling part plus the data randomizing part, keys were set up each time a block cipher was encrypted (decrypted). The other evaluation conditions were the same as those for the evaluation of the data randomizing part. However, the value obtained by subtracting from this value the value specified in the data randomizing part described above may sometimes be different from the one specified in the key scheduling part, depending on the implementation method. For evaluation of stream ciphers, evaluation was only performed on the data randomizing part, assuming that no key setup is required. We are aware that, in terms of software implementation, some stream ciphers were not evaluated sufficiently, due to the use of the same evaluation program(s) as employed for 64 bit block ciphers. In terms of usage, stream ciphers are more software-oriented than block ciphers. Therefore, evaluation of stream ciphers should be performed primarily from software implementation point of view, rather than from hardware implementation point of view. Thus, the evaluation of software implementation for stream ciphers aimed to confirming whether performance meeting the minimum requirements of usage could be achieved under the targeted software implementation.

37 CRYPTREC 2000

3.4.3 Evaluation of hardware implementation In this project, evaluation of hardware implementation was performed for the submitted symmetric ciphers, with a view to confirming their “usability. Depending on the process employed (Field Programmable Gate-Array, Gate Array), evaluation items were varied, including processing speed and resource use quantity (the amount of use cell in the case of Field Programmable Gate-Array, the number of used gates in the case of Gate Array, etc.). In this project, the evaluation of hardware implementation was performed, based on the hardware implementation information (results) described in the documents submitted by the applicant. Only verification for information validity regarding processing speed and resource consumption described in the submitted documents was conducted, based on the submitted simulation evaluation results. Here, “usability” refers to a state of condition where a submitted cryptographic technique is not merely a theory, but it can actually be implemented, with functions being available for implementation, in accordance with the applied categories.

［Evaluation method of block ciphers］ Targeted devices for evaluation of block ciphers included ASIC library of 0.25 – 0.35μm, Verilog-HDL as design description language, and Design Compile for circuit synthesis. In this project, moreover, for the evaluation of hardware implementation, Triple DES (3-Key), a cryptographic technique that needs further evaluation, was examined as an indicator of relative evaluation. However, it should be limited to use as a guideline pertaining to running speed, gate size, etc, due to differences in implementation architectures and optimized conditions. In addition, while its utility depends largely on the person’s experience in implementation, in almost all cases, some improvement in performance (processing speed, miniaturization) can be expected during actual implementation. ［Evaluation method of stream ciphers］ Hardware implementation of stream ciphers was evaluated on Altera Corp’s FPGA Compiler, in a simulation of programs prepared in C Programming Language describing the circuit by a Verilog-HDL simulator. Evaluation was conducted giving a higher priority to processing-speed-oriented design conditions, under which an appropriate scale of circuit was implemented. The development environment used for the evaluation of hardware implementation is shown below: ・ModelSim VHDL/Verilog Version 5.4e (Model Technology) ・Synplify (Synplicity Inc.) 3.5 Evaluation Method of Hash Functions A hash function is a function taking an n-bit input and producing an m-bit output (n>m). Functions required of a hash function are “onewayness” and “no collision.” Onewayness refers to a property that makes it impossible for inputs to be computed from an output. Collision refers to a property that outputs

38 CRYPTREC 2000

the same hash value against two different inputs. A hash function takes an n-bit input and produces an m-bit output, where n is larger than m. Thus, theoretically, no collision is impossible. The input is larger than the output. Complete collisionlessness is impossible. Accordingly, if no collision is found in an actual calculation of a hash function, it is assumed that the function has no collision. There was no hash function proposed for the year 2000 evaluation project. Techniques that are currently in widespread use were evaluated in terms of security, based on documents currently available.

3.6 Evaluation Method of Pseudo-random Number Generating Techniques The usage of pseudo-random number generating schemes described here is different from that of stream ciphers. A pseudo-random number generating scheme is used to generate random numbers utilized for generating cryptographic keys or key seeds. Cryptographic strength is required of a pseudo-random number, the nature of which is similar to that of a true random number. During the security evaluation, the evaluation items of FIPS-140-1/2 etc., employed for the evaluation of the above-mentioned pseudo-random number generator for stream ciphers, were also employed here to evaluate random numbers which had been output. ・Long periodicity ・Linear complexity ・Frequency of 0/1, etc. ・Monobit test ・Poker test ・Runs test ・Long run test A pseudo-random number generator is used for generating ciphers, and it is impossible to forecast what will be output. Therefore, it must have input space sufficiently larger than the output space.

4. Evaluation of Public Key Cryptography

4.1 General Comments

4.1.1 List of Public Key Cryptographic Techniques as Targets of Detailed Evaluation

39 CRYPTREC 2000

By function and security, the public key cryptographic techniques for which a detailed evaluation was performed can be classified as shown below.

Function Security Signature Confidentiality Key Sharing Basis Integer Factoring ACE Sign EPOC-1 ;Notes3 ESIGN-signature EPOC-2 ;Notes3 RSA-PSS EPOC-3 ;Notes3 HIME-1 ;Notes4 HIME-2 RSA-OAEP Discrete Logarithm DSA ACE Encrypt DH

Elliptic Curve ECDSA in SEC1 ECAES in SEC1 ECDHS in SEC1 Discrete Logarithm MY-ELLTY ECMR-160/192/OEF-h PSEC-1 ;Notes3 ECMQVS in SEC1 PSEC-2 ;Notes3 HDEF-ECDH PSEC-3 ;Notes3

Notes:

(1) Although a scheme named "ESIGN-identification" was entered in the "Authentication" function category, it had no description as an authentication protocol. Moreover, since it was the same, except for its name, as ESIGN-signature, which was entered in the "Signature" function category, the Committee merged it into ESIGN-signatures.

(2) MY-ELLTY ECMR-160/192/OEF-h was entered as three different items: MY-ELLTY ECMR-160-h, MY-ELLTY ECMR-192-h, and MY-ELLTY ECMR-OEF-h. However, since the three were considered one and the same as a signature scheme, only using different fields, the Committee evaluated them as a single entry.

(3) EPOC-1, EPOC-2, and EPOC-3 were entered as a cryptographic group named EPOC, and PSEC-1 PSEC-2, and PSEC-3 as a cryptographic group named PSEC. However, since they were mutually different techniques, the Committee divided them as mentioned above.

(4) HIME-1 was entered in the "Key Sharing" function category. Its cryptographic scheme is for one entity to send the other entity a key to be shared after encrypting it by a public key cryptographic technique. Since this use can be applied to all cryptographic schemes classified into the "Key Sharing" function category, the Committee shifted HIME-1 to the "Confidentiality" function category. That is, only the part in which both entities are involved for key generation was left in the "Key Sharing" function category.

This report describes individual public key cryptographic schemes in the following order (see the above table): signature - integer factoring, signature - discrete logarithm, signature - elliptic curve discrete logarithm, confidentiality - integer factoring, confidentiality - discrete logarithm,

40 CRYPTREC 2000

confidentiality - elliptic curve discrete logarithm, key sharing - discrete logarithm, and key sharing - elliptic curve discrete logarithm. In each section, they are arranged in alphabetical order.

4.1.2 General Comments on Public Key Cryptographic Techniques Software implementability evaluation has confirmed that all the public key cryptographic techniques evaluated in detail in this project have generally acceptable processing performance with respect to implementability. This section summarizes the results of evaluation, with emphasis on security, of the individual cryptographic techniques in this project, describing the results separately with respect to the signature, confidentiality, and key sharing functions. In cases where security issues contrary to the arguments made by the proposers of cryptographic techniques were pointed out, if no final conclusion was reached in this project, it is clearly mentioned to that effect. As for such matters, it is desirable to continue to evaluate them in subsequent projects or elsewhere. A basic feature required of the cryptographic technologies used for Electronic Government would be that a specifically defined cryptosystem, including the method of specifying parameters, can widely achieve a consensus that it is secure at the present time and that the risk of becoming immediately unsecure is small. Such a consensus would be based partly on the empirical knowledge that the cryptosystem has been used widely without any significant security problems. At the same time, using the concept of "provable security" would be effective in minimizing ambiguities in security evaluation. It should be noted, however, that this concept does not mean that a particular cryptosystem has been proven to be secure. In this section, the expression "provable security under a set of assumptions" refers to the following situation: That is, the expression that a certain public key cryptosystem has provable security means that if there should be a method of attacking the cryptosystem or its idealized cryptosystem, thus threatening the security that the cryptosystem is intended to provide, it can be strictly proved that under a certain assumption, a method of solving another mathematical problem with less complexity can be derived. An idealized cryptosystem of a cryptosystem is a virtual cryptosystem identical to the original cryptosystem, except that an auxiliary function (such as a hash function) used in the cryptographic scheme is replaced by a virtual one (such as a random function). The expression "under a set of assumptions" is used to mean that the reliability of the security of a cryptosystem varies depending on differences in the target of attack (whether the cryptosystem itself or an idealized cryptosystem), the type of mathematical problem, the degree of computational complexity, the type of security in question, the type of attacking method, preconditions, and so forth. As long as the proof of provable security is correct, the fact that the cryptosystem has provable security cannot be reversed later. However, since the estimated computational complexity of a mathematical problem can vary depending on theoretical progress or changes in the technical environment, a cryptosystem that has provable security under a set of assumptions that holds at the

41 CRYPTREC 2000

present time can become an unsecure cryptosystem in the future. Besides, it may be discovered in the future that there is a significant security gap between the cryptosystem and its idealized cryptosystem. Meanwhile, the fact that it is not proved at the present time that a cryptosystem has provable security does not mean that the cryptosystem is not secure. The reason is that there can be cases in which the security of a cryptosystem that has been widely used without any significant security problems cannot be proved in terms of provable security with proving techniques available at the present time. It is considered that methods for building cryptosystems achieving provable security are being established for signature and confidentiality cryptography, but not for key sharing cryptographic techniques. Schemes for Signatures (1)ACE Sign Particular problems on security of ACE Sign have not been pointed out. ACE Sign has certain provable security under a set of assumptions. A little bit stronger mathematical assumption is required, the proof of the provable security of the scheme does not need any idealized auxiliary function, while other digital signature schemes require an idealized function. Moreover, the sizes of a prime factor p and modulus n should satisfy the following conditions: 1024 ≤ |n| ≤ 16384, and |p| ≥ 512. Furthermore, the form of the prime factor is restricted. And yet, its specification only uses MARS for a symmetric key cipher employed as an auxiliary function. Note that this submitter announced a digital signature algorithm whose name is the same of this submission and differs from this submission. (2)ESIGN-signature Serious problems on security of firstly proposed ESIGN using small exponents have been dispelled. ESIGN-signature has certain provable security under a set of assumptions. To satisfy the assumptions, it is important to select appropriate parameters carefully. Since the form of the modulus is different from those in textbook RSA signature and RSA-PSS schemes, it is not clear whether or not this scheme achieves the same security when one selects the size recommended in those schemes for the modulus. The security of this scheme depends on the difficulty of the approximate e-th root assumption. In this assumption, the sizes of n and e are essential for difficulty. Since there exists a difference of condition for these sizes in submitted documents: e ≥ 5 (conditions in Specification), e ≥ 8, |p| = |q| ≥ 320, |n| ≥ 960 (recommended sizes in Specification), e ≥ 1024, |p| = |q| = 384, |n| = 1152 (adopted sizes in Software Implementation), e ≥ 8, |n| ≥ 1024 (recommended sizes in the Draft Guidelines for Authorizing Special Certification Businesses based on the Law of Electronic Signatures and Certification Businesses), it is necessary to select those sizes after due consideration. (3)RSA-PSS Particular problems on security of RSA-PSS have not been pointed out. RSA-PSS has certain provable security under a set of assumptions whereas the textbook RSA signature scheme is not known to have.

42 CRYPTREC 2000

To ensure the assumptions, the user is advised to select appropriate parameters. (4)DSA For DSA defined in FIPS 186-2, particular problems on security have not been pointed out. The user is advised to select appropriate parameters to make the underlying discrete logarithm problem hard. We should note that its security is bounded above because the size of number of modulus is restricted between 512 and 1024. It has not been verified that DSA attains certain provable security. It is reported that the method of generating random numbers described in FIPS 186-2 Appendix 3 is unreliable. More analyses are desirable. (5)ECDSA in SEC1 Particular problems on security of ECDSA in SEC1 have not been pointed out. It is guaranteed that no known attack is effective against the curves, given in SEC2, recommended for the use in ECDSA in SEC1. The Koblitz curves are included in SEC2 because fast group operation can be implemented. However, the class of Koblitz curves is restricted and so a specific attack against them may appear. It has not been verified that ECDSA in SEC1 attains some level of provable security, however, it has been reported that ECDSA in SEC1 is provably secure under a set of assumptions in a certain recent paper. We did not come to an agreement on the validity of the paper and the practical effectiveness of the proof method, and hence, more analyses are desirable. (6)MY-ELLTY ECMR-160/192/OEF-h MY-ELLTY ECMR-160/192/OEF-h is existentially forgeable spending 2^40 (or 2^48) complexity by the attack based on the birthday paradox, because the size of the hash value used in it is too short. We cannot say that it has no problems on security. Thus, we cannot recommend it for a digital signature algorithm if the signatures produced by it are required to be alive for long term. Moreover, we do not confirm at present that it has a provable security, since its proof for a provable security in this submission document has an error. Schemes for Confidentiality (7)EPOC-1 Except for the following issues of EPOC-1 no problems on security have been pointed out. EPOC-1 has certain provable security under a set of assumptions. To satisfy the assumptions, it is important to select appropriate parameters carefully. Since the form of the modulus is different from that in RSA scheme, it is not clear whether or not this scheme achieves the same security when one selects the size recommended in RSA scheme for the modulus. It is also pointed out that more conditions for parameters are needed to achieve the enough security. But that appropriateness has not been confirmed in the committee. Hence more consideration is needed to clear the condition for selecting parameters. (8)EPOC-2 Except for the following issues of EPOC-2 no problems on security have been pointed out. EPOC-2 has certain provable security under a set of assumptions. To satisfy the assumptions, it is important to

43 CRYPTREC 2000

select appropriate parameters carefully. Since the form of the modulus is different from that in RSA scheme, it is not clear whether or not this scheme achieves the same security when one selects the size recommended in RSA scheme for the modulus. It is also pointed out that the recommended sizes for parameters the applicant asserted are not sufficient and more conditions are needed to achieve the enough security. But that appropriateness has not been confirmed in the committee. Hence more consideration is needed to clear the condition for selecting parameters. (9)EPOC-3 Except for the following issues of EPOC-3 no problems on security have been pointed out. EPOC-3 has certain provable security under a set of assumptions. To satisfy the assumptions, it is important to select appropriate parameters carefully. Since the form of the modulus is different from that in RSA scheme, it is not clear whether or not this scheme achieves the same security when one selects the size recommended in RSA scheme for the modulus. It is also pointed out that the recommended sizes for parameters the applicant asserted are not sufficient and more conditions are needed to achieve the enough security. Furthermore, it is pointed out that the gap-factoring assumption on which the security of this scheme depends is relatively new notion and the difficulty of this problem is not clear. But that appropriateness has not been confirmed in the committee. Hence more consideration is needed to clear the condition for selecting parameters. (10)HIME-1 The description of Specification is ambiguous. For this reason, it is impossible to implement this scheme properly. It has not been confirmed that this scheme has provable security since there are some mistakes in the proof of security. Since the form of the modulus is different from that in RSA scheme, it is not clear whether or not this scheme achieves the same security when one selects the size recommended in RSA scheme for the modulus. It is necessary to take care of Elliptic Curve Method (ECM) since there are some cases in selecting parameters that it is more effective for cryptanalysis than Number Field Sieve Method (NFS). (11)HIME-2 The description of Specification is ambiguous. For this reason, it is impossible to implement this scheme properly. It has not been confirmed that this scheme has provable security since there are some mistakes in the proof of security. Since the form of the modulus is different from that in RSA scheme, it is not clear whether or not this scheme achieves the same security when one selects the size recommended in RSA scheme for the modulus. It is necessary to take care of Elliptic Curve Method (ECM) since there are some cases in selecting parameters that it is more effective for cryptanalysis than Number Field Sieve Method (NFS). (12)RSA-OAEP Particular problems on security of RSA-OAEP have not been pointed out. RSA-OAEP has certain provable security under a set of assumptions. To ensure the assumptions, the user is advised to select appropriate parameters. It is reported that RSA-OAEP is semantic secure (equivalently

44 CRYPTREC 2000

non-malleable) against an adaptive chosen ciphertext attack under a set of assumptions. (13)ACE Encrypt Particular problems on security of ACE Encrypt have not been pointed out. ACE Encrypt has certain provable security under a set of assumptions. A little bit stronger mathematical assumption is required, but it can be proved that has provable security condition without replacing an auxiliary function with an ideal one, while other encryption algorithm requires an ideal function. Moreover, the sizes of modulus p and parameter q should satisfy the following conditions: 1024 ≤ |n| ≤ 16384, and |q| = 256. Furthermore, the form of the prime factor is restricted. And yet, its specification only uses MARS for a symmetric key cipher employed as an auxiliary function. Note that this submitter announced a digital signature algorithm whose name is the same of this submission and differs from this submission. (14)ECAES in SEC1 Particular problems on security of ECAES in SEC1 have not been pointed out. ECAES in SEC1 has certain provable security under a set of assumptions. It is guaranteed that no known attack is effective against the curves given in SEC2. The Koblitz curves are included in SEC2 because fast group operation can be implemented. However, the class of Koblitz curves is restricted and so a specific attack against them may appear. (15)PSEC-1 It is pointed out that there exist some problems in primitive encryption function and the provable security of this scheme has not been confirmed. And it is also pointed out that different conditions from those the applicant asserted are needed to prove the security. If these are correct, the size of message for an encryption is markedly restricted. But that appropriateness has not been confirmed in the committee. Hence more consideration is needed to clear the condition for selecting parameters. (16)PSEC-2 Except for the following issues of PSEC-2 no problems on security have been pointed out. PSEC-2 has certain provable security under a set of assumptions. It is pointed out that the recommended sizes for parameters the applicant asserted are not sufficient and different conditions are needed to achieve the enough security. But that appropriateness has not been confirmed in the committee. Hence more consideration is needed to clear the condition for selecting parameters. (17)PSEC-3 Except for the following issues of PSEC-3 no problems on security have been pointed out. PSEC-3 has certain provable security under a set of assumptions. It is pointed out that the recommended sizes for parameters the applicant asserted are not sufficient and more consideration for sizes of parameters is needed to achieve the enough security. It is also pointed out that more operation must be added to decryption algorithm. Furthermore, it is pointed out that the elliptic curve gap-DH assumption on which the security of this scheme depends is relatively new notion and the difficulty of this problem is not clear. But that appropriateness has not been confirmed in the committee. Hence more

45 CRYPTREC 2000

consideration is needed to clear the condition for selecting parameters. Schemes for Key Sharing (18)DH There are numerous variations to the Diffie-Hellman scheme, and hence, each protocol (e.g. RFC2631, ISO/IS11770-3, Oakley, PGP) has to be evaluated respectively. However this year we evaluated only the basic primitive of DH. Particular problems on security of DH with respect to passive attacks, where adversaries do not affect the protocol, have not been pointed out. However, the user is advised to ensure at least the followings against active attacks (adversaries affect the protocol). A. Employ a method to authenticate the relationship between the entities and their keys. B. A public key should be discarded after each communication when DH is employed as a session key agreement scheme. C. A key derivation function should be used to make the established key indistinguishable from a random number. (19)ECDHS in SEC1 Particular problems on security of ECDHS in SEC1with respect to passive attacks, where adversaries do not affect the protocol, have not been pointed out. However, the user is advised to ensure at least the followings against active attacks (adversaries affect the protocol). A. Employ a method to authenticate the relationship between the entities and their keys. B. A public key should be discarded after each communication when ECDHS in SEC1 is employed as a session key agreement scheme. It is guaranteed that no known attack is effective against the curves given in SEC2. The Koblitz curves are included in SEC2 because fast group operation can be implemented. However, the class of Koblitz curves is restricted and so a specific attack against them may appear. (20)ECMQVS in SEC1 Particular problems on security of ECMQVS in SEC1with respect to passive attacks, where adversaries do not affect the protocol, have not been pointed out. However, the user is advised to ensure at least the followings against active attacks (adversaries affect the protocol). A. Employ a method to authenticate the relationship between the entities and their keys. B. A public key should be discarded after each communication when ECMQVS in SEC1 is employed as a session key agreement scheme. It is guaranteed that no known attack is effective against the curves given in SEC2. The Koblitz curves are included in SEC2 because fast group operation can be implemented. However, the class of Koblitz curves is restricted and so a specific attack against them may appear. (21)HDEF-ECDH The proposal consists of the basic elliptic curve DH scheme (each entity uses the same elliptic curve) and a variant (each entity uses a distinct elliptic curve). The proposal puts emphasis on the method of generating elliptic curve parameters.

46 CRYPTREC 2000

The evaluation on the basic scheme is same as that on (18) DH. Particular problems on security of HDEF-ECDH with respect to passive attacks, where adversaries do not affect the protocol, have not been pointed out. However, the user is advised to ensure at least the followings against active attacks (adversaries affect the protocol). A. Employ a method to authenticate the relationship between the entities and their keys. B. A public key should be discarded after each communication when HEDF-ECDH is employed as a session key agreement scheme. C. A key derivation function should be used to make the established key indistinguishable from a random number. We did not come to an agreement whether or not the variant is more secure than the basic scheme as the submitter claims. More analyses are desirable. It is guaranteed that no known attack is effective against the curves employed in HDEF-ECDH, however, the class of the elliptic curves is restricted and so a specific attack against them may appear.

47 CRYPTREC 2000

4.2 Evaluation Classified by Function

4.2.1 Signature

【Results of Software Implementation of Public Key Cryptosystems for Signature Use】 Of those public key cryptographic techniques for signature use that were evaluated in detail, the following three entries were evaluated for software implementability: (1) ESIGN-signature

(2) ECDSA in SEC1

(3) MY-ELLTY ECMR-160/192/OEF-h

With respect to RSA-PSS and DSA, which are two public key cryptographic techniques for signature use that were submitted for detailed evaluation, the Committee judged that it was not necessary to evaluate them for software implementability partly because they should be evaluated in other respects and partly because they had already been implemented widely. With respect to ACE Sign, its specifications were modified after it was entered for evaluation. Therefore, the Committee did not evaluate the software implementability corresponding to the techniques described in the initially submitted documents. The above three schemes whose software implementability was evaluated are considered to be at implementable levels. The proposers of these three schemes were requested to select implementation parameters in such a way that security is equal to or higher than that of a 1,024-bit RSA cryptosystem. Approximate execution speeds (measured) of key generation, signature generation, and signature verification, are shown below together with estimated code sizes.

48 CRYPTREC 2000

[Characteristics and Measurement Parameters]

Implementation Parameter Scheme Measured Security Evidence Other and Character ESIGN-signature Integer factoring problem Composite number size: Security parameter of ESIGN is 10 bits. (IF) 384 bits × 3 = 1,152 bits It is programmed in C as described in its specification. Nothing special is done to increase speed or save memory. MY-ELLTY ECDLP 192-bit prime Equivalent to RSA 1,536 Security has been verified against the ECMR-192-h field bits MOV reduction, FR reduction, and SSSA attacks (criteria cleared). MY-ELLTY OEF Equivalent to RSA 1,024 Fixed parameter. Binary incorporation. ECMR-OEF-h bits Binary incorporation of preliminary MY-ELLTY 160-bit prime Equivalent to RSA 1,024 computing results. Refer to table. ECMR-160-h field bits ECDSA in SEC1 160-bit prime Equivalent to RSA 1,024 • Since the two coefficients of an field bits elliptic curve are related to each other by the output of SHA-1 (which 163-bit field cannot be controlled), free selection is with randomly verifiable. characteristi • As required by the X9.62 c 2 specification, the SHA-1 input value is also described as part of the parameter.

[Key Pair Generation Speed (Approximate)]

Scheme Measured Average Remarks Execution Time ESIGN-signature Prime number generation and random number generation are not 50.8 ms included. The length of composite numbers is 384 bits × 3 = 1,152. Measured value, including random number generation and prime 452.8 ms number generation. MY-ELLTY ECMR -192-h 0.8 ms Random number generation is included. Actual use requires replacement of the random number generation MY-ELLTY ECMR -OEF-h 0.7 ms mechanism, hence a change in the time. MY-ELLTY ECMR -160-h 0.7 ms ECDSA in ECDSA 1.9 ms Key pair generation. SEC1 160-bit prime Key pair verification. The verification is not required when the key field 5.8 ms pair has been generated by the user. ECDSA 3.2 ms Key pair generation. 163-bit field Key pair verification. The verification is not required when the key with 8.0 ms characteristic 2 pair has been generated by the user.

49 CRYPTREC 2000

[Signature Generation Speed (Approximate)]

Average Auxiliary Scheme Measured Remarks Execution Time Function ESIGN-Signature 9.2 ms SHA-1 Size of data to be signed: 31 KB 49.1 ms Size of data to be signed: 178 KB MY-ELLTY ECMR-192-h 2.0 ms SHA-1 Size of data to be signed: 31 KB Random number generation is 9.2 ms Size of data to be signed: 178 KB included. SHA-1 MY-ELLTY ECMR-OEF-h 1.9 ms Size of data to be signed: 31 KB is used as an auxiliary function. 9.6 ms Size of data to be signed: 178 KB SHA-1 processing time increases in MY-ELLTY ECMR-160-h 1.9 ms Size of data to be signed: 31 KB proportion to file 9.7 ms Size of data to be signed: 178 KB length. ECDSA ECDSA 3.7 ms SHA-1 Size of data to be signed: 31 KB in SEC1 160-bit prime field 11.1 ms Size of data to be signed: 178 KB ECDSA 5.0 ms Size of data to be signed: 31 KB 163-bit field with characteristic 2 13.1 ms Size of data to be signed: 178 KB

[Signature Verification Speed (Approximate)]

Scheme Measured Average Execution Time Remarks ESIGN-Signature 6.6 ms Size of data to be signed: 31 KB 44.3 ms Size of data to be signed: 178 KB MY-ELLTY ECMR-192-h 5.4 ms Size of data to be signed: 31 KB Although it is designed in such a 12.8 ms Size of data to be signed: 178 KB way that the MY-ELLTY ECMR-OEF-h 4.4 ms Size of data to be signed: 31 KB validity of verification will 11.9 ms Size of data to be signed: 178 KB be checked, the result is not output MY-ELLTY ECMR-160-h 4.3 ms Size of data to be signed: 31 KB in the 11.9 ms Size of data to be signed: 178 KB implementation this time. ECDSA 160-bit prime field 9.7 ms Size of data to be signed: 31 KB in SEC1 17.2 ms Size of data to be signed: 178 KB 163-bit field with 13.6 ms Size of data to be signed: 31 KB characteristic 2 21.4 ms Size of data to be signed: 178 KB

50 CRYPTREC 2000

4.2.2 Confidentiality

In the category of confidentiality, seven entries were submitted for evaluation: EPOC, HIME-1, HIME-2, RSA-OAEP, ACE Encrypt, ECAES in SEC1, and PSEC. However, since EPOC and PSEC are cryptographic groups, each of which have three schemes, 11 schemes were actually evaluated. The table on the following page summarizes the characteristics and security of each scheme. Characteristics • The functions of the schemes were classified from the viewpoint mentioned below. The schemes can be classified into three categories: those in which the length of plaintext that can be encrypted in a single scheme operation is limited (L1), those in which there is no such limitation (L2), and a subclass of L2 where key distribution phase and encrypted communication phase can be divided (L3). In L1, the schemes are primarily designed with consideration for the distribution of secret keys used for symmetric cryptosystems and MAC functions. The schemes in L2 and L3 are hybrids between public key cryptography and symmetric cryptography. These schemes are designed with consideration for general encrypted communication (with message authentication functions) as well.

• With respect to effective plaintext length, ciphertext length, public key length, and secret key length, the table lists the typical parameter sizes, based on those recommended in the specifications, that are considered to provide the strength equivalent to that of RSA 1,024 bits. For those schemes with no parameter sizes expressly recommended, the parameter sizes used in the descriptions of implementability in their specifications were regarded as recommended values. In addition, the following points were considered for as unified comparison as possible:

In the case of the schemes in which parameter sizes are variable, the parameters required to specify those parameter sizes were excluded from effective lengths. The parameters to specify functions, such as function IDs, were also excluded.

In L2 or L3 schemes, the symmetric ciphers and MAC functions are based on the functions recommended in the submitted specifications. In the case of the schemes in which Vernam ciphers are recommended as symmetric ciphers, Vernam ciphers on a byte basis are considered.

Elliptic curves are based on the curves defined over prime fields. The cofactor is 1. Security • The table lists the cryptographic primitive in each scheme and the security assumptions on which they are based.

• The security of the confidentiality function of each scheme is discussed in terms of the combination of an assumed attacking method and a security target. If a scheme is semantically secure against an adaptive chosen ciphertext attack, the strongest possible attack in cryptographic theory, the scheme is considered to realize the highest security level for the purpose of confidentiality. (This property is

51 CRYPTREC 2000

described as "IND-CCA2" in simplified form.) Attempts are being made to prove that the individual schemes are IND-CCA2 by assuming the randomness of the functions used and the difficulty of number-theoretic problems concerning parameter sizes. The table lists number-theoretic problems based on the assumption of randomness.

52 CRYPTREC 2000

EPOC-1 PSEC-1 ACE ECAES in Scheme EPOC-2 HIME-1 HIME-2 RSA-OAEP PSEC-2 Encrypt SEC1 EPOC-3 PSEC-3 EPOC-1/2/3 L1 L1 L1 L2 L2 EPOC-1/2/3 are are L1/L2/L3, L1/L2/L3, respectively. respectively. Functional Functional Classification

[EPOC-1] 510 bits 768 bits 688 bits Arbitrary Arbitrary [PSEC-1] 128 bits length length 128 bits L (M) byte L (M) byte [EPOC-2] [PSEC-2] Arbitrary Arbitrary length length L (M) byte L (M) byte [EPOC-3] [PSEC-3] Arbitrary Arbitrary length length Effective Plaintext Length L (M) byte L (M) byte [EPOC-1] 1,024 bits C:1,024 bits 1,024 bits s:128 bits R:320 bits [PSEC-1] 1,152 bits a:2 bits u1:1,024 bits EM:L (M) C1:320 bits u2:1,024 bits byte c2:160 bits [EPOC-2] v:1,024 bits D:160 bits C1:1,152 bits e:L (M) + [PSEC-2] C2:L (M) 16* (L (M) / C1:320 bits byte 1,024) byte c2:160 bits c3:L (M) [EPOC-3] byte C1:1,152 bits C2:L (M) [PSEC-3]

Characteristic Characteristic byte C1:320 bits C3:128 bits c2:160 bits Effective Ciphertext Length Length Ciphertext Effective c3:L (M) byte c4:128 bits

n:1,152 bits n:1,024 bits n:1,024 bits n:1,024 bits P:1,024 bits Qv:320 bits W:320 bits g:1,152 bits e:17 bits q:256 bits Elliptic Elliptic h:1,152 bits g1:1,024 bits curve curve g2:1,024 bits parameter: parameter: c:1,024 bits 160 bits × 6 160 bits × 6 Length Length d:1,024 bits h1:1,024 bits

Effective Public Key Key Public Effective h2:1,024 bits

p:384 bits p:256 bits p1:256 bits p:512 bits w:256 bits Dv:160 bits s:160 bits g :768 bits q:256 bits p p2:256 bits q:512 bits x:256 bits α:256 bits p :256 bits dP:512 bits y:256 bits β:256 bits 3 z:256 bits p4:256 bits dQ:512 bits z1:256 bits Length Length z1:256 bits qInv:512 bits z2:256 bits

z2:256 bits Effective Secret Key z3:256 bits

53 CRYPTREC 2000

EPOC-1 PSEC-1 ACE ECAES in Scheme EPOC-2 HIME-1 HIME-2 RSA-OAEP PSEC-2 Encrypt SEC1 EPOC-3 PSEC-3 Basic Basic Basic Basic Basic Basic Basic function: function: function: function: function: function: El function: El Okamoto-Uc Rabin Rabin RSA Cramer-Sho Gamal Gamal hiyama function. function. function. up function function on function on function. Based on the Based on the Based on the (a modified elliptic elliptic Based on the security of security of security of El Gamal curves. curves. security of integer integer integer function). Based on the Based on the integer factoring factoring factoring (pq Based on the security of security of factoring (pkq type). d type). security of elliptic curve elliptic curve (P2q type). ( ∏ pi type). discrete discrete discrete Cryptographic Primitive Primitive Cryptographic i=1 logarithm logarithm logarithm problems. problems. problems. IND-CCA2 Provable Provable IND-CCA2 IND-CCA2 IND-CCA2 IND-CCA2 subject to security is security is subject to subject to subject to subject to the not verified not verified the the the the difficulty of because of because of difficulty of difficulty of difficulty of difficulty of the inadequaci inadequaci the RSA decision adaptive the following es in the es in the function DH hash DH following problems. specificatio specificatio inverse problem. in-depende problems. (Random n and proof n and proof transform (Assumptio nce (Random oracle problems. problems. problem. n of problem on oracle model) (Random universal elliptic model) [EPOC-1] oracle one-way curves. [PSEC-1] p-subgroup model) hash (Assumptio Elliptic problem function n of the curve [EPOC-2] and randomnes partial Security Integer assumptio s of decision factoring n of symmetric DH problem pseudo-ran ciphers problem [EPOC-3] domness of and MAC (ECPDDH) GAP symmetric functions) [PSEC-2] integer cipher) Under the DH factoring random problem on problem oracle elliptic

Cryptographic Scheme model, the curves following is (ECDH) pointed [PSEC-3] out: GAP DH IND-CCA2 problem on subject to elliptic the curves difficulty of (EC-GAP- GAP DH DH) problem on elliptic curves. (Random oracle model)

54 CRYPTREC 2000

【Results of Software Implementation of Public Key Cryptosystems for Confidentiality Use】 Of those public key cryptographic techniques for confidentiality use that were evaluated in detail, the following five entries were evaluated for software implementability: (1) RSA-OAEP

(2) EPOC-1, EPOC-2, and EPOC-3

(3) HIME-1 and HIME-2

(4) ECAES in SEC1

(5) PSEC-1, PSEC-2, and PSEC-3 With respect to ACE Encrypt, the software implementability corresponding to the submitted scheme was not evaluated. One reason was that its specifications were modified after it was entered for evaluation. The above five schemes whose software implementability was evaluated are considered to be at implementable levels. When the software implementability of HIME-1 and HIME-2 was evaluated, information required for the implementation, including primarity test conditions, was presented. This newly added information is not described in the Cryptographic Techniques Specifications. As for the maturity of the software implementation, RSA-OAEP and ECAES in SEC1 were found to be equivalent or close to the degree of perfection of product versions. The proposers of these five schemes were requested to select implementation parameters in such a way that security is equal to or higher than that of a 1,024-bit RSA cryptosystem. The key generation, encryption, and decryption speeds (measured) are shown below together with code sizes.

55 CRYPTREC 2000

[Characteristics and Measurement Parameters (1/2)]

Scheme Implementation Parameter Security Evidence Other Measured and Character RSA-OAEP Integer factoring Public key modulus Chinese Remainder Theorem (CRT) is used to problem (IF) length: 1,024 bits increase speed. Public exponent: 65537 EPOC-1 EPOC composite number Data size of EPOC for evaluation is 128 bits. length: 384 bits × 3 = Primarity test uses the Miller-Rabin method. EPOC-2 1,152 bits EPOC-3 HIME-1 Modulus N is of the N = The p ± 1 method is considered in the selection of p p3q (d = 3), where p and q and q. are 256 bits each. There are three kinds of public key in the RSA encryption in which specification (N, k, d). However, it was fixed at d = 3 N = 1,024 bits (strength in the implementability evaluation this time. greater than Exponential operations used Montgomery's confidentiality) multiplication and the 4-array method. HIME-2 Modulus N is of the N = • The p ± 1 method is considered in the selection of p1p2p3p4 (d = 4), where p1, p1, p2, p3, and p4. p2, p3, p4 are 256 bits • The Cryptographic Techniques Specifications do each. not require that the bit length of n be 1023 bits or RSA encryption in which over or that p1, p2, p3, and p4 all differ from each N = 1,024 bits (strength other. Because problems could arise, conditions greater than were added in the implementation this time. confidentiality) • Exponential operations used Montgomery's multiplication and the 4-array method.

56 CRYPTREC 2000

[Characteristics and Measurement Parameters (2/2)]

Implementation Security Scheme Measured Parameter and Other Evidence Character ECAES in 160-bit prime ECDLP Equivalent to RSA • One of the recommended parameters to the SEC1 SEC1 field 1,024 bits specifications. Based on the ANSI X9.62 specifications. • Since the two coefficients of an elliptic curve are related to each other by the output of SHA-1 (which cannot be controlled), it is verified that the 163-bit field Equivalent to RSA curve was selected randomly. with 1,024 bits • As required by the X9.62 specification, the SHA-1 characteristic 2 input value is also described as part of the parameter. • It has been verified that special attacks are not effective. • Optimization could further increase speed. • A high-speed method applicable to any parameter is used. • Implementation is not dependent on parameters. PSEC-1 Each parameter of Data size of PSEC for evaluation is 128 bits. PSEC: 160 bits Elliptic curve parameters are necessary. Regarding PSEC-2 Equivalent to RSA the results of calculations by other methods, the 1,024 bits elliptic curve parameters made public by the NIST (National Institute of Standards and Technology), etc. are given to the main program. PSEC-3 The free multiple-precision integer arithmetic library GNU MP 3.1.1 is used.

57 CRYPTREC 2000

[Key Generation Speeds (Approximate)]

Average Scheme Measured Remarks Execution Time RSA-OAEP 2946.5 ms e = 17 3405.5 ms e = 65537

EPOC-1 73.9 ms Not including random number generation. Measured value, including random number and prime number 417.6 ms generation. EPOC-2 73.9 ms Not including random number generation. Measured value, including random number and prime number 577.0 ms generation. EPOC-3 73.9 ms Not including random number generation. Measured value, including random number and prime number 743.3 ms generation. HIME-1 Including prime number generation. 934.0 ms Composite number size: 256 × 4 = 1,024 bits For each prime number, only the test by the p±1 method is 785.0 ms implemented. HIME-2 Including prime number generation. 2845.0 ms Composite number size: 256 × 4 = 1,024 bits For each prime number, only the test by the p±1 method is 1829.0 ms implemented. ECAES in 160-bit prime field 1.9 ms Key pair generation. SEC1 Key pair verification, which is not necessary if the keys are 5.8 ms generated by the user. 163-bit field with 3.2 ms Key pair generation. characteristic 2 Key pair verification, which is not necessary if the keys are 8.0 ms generated by the user. PSEC-1 11.3 ms None PSEC-2 11.8 ms None PSEC-3 11.5 ms None

[Encryption Speed (Approximate)]

Average Scheme Measured Remarks Execution Time RSA-OAEP 4.2 ms e = 17 EPOC-1 13.9 ms None EPOC-2 10.9 ms None EPOC-3 11.0 ms None HIME-1 140.6 ms HIME-1 data size: 256 bits HIME-2 0.4 ms HIME-2 data size: 256 bits ECAES in 160-bit prime field 8.5 ms None SEC1 163-bit field with 12.5 ms None characteristic 2

58 CRYPTREC 2000

PSEC-1 24.0 ms None PSEC-2 24.2 ms None PSEC-3 22.9 ms None

59 CRYPTREC 2000

[Decryption Speeds (Approximate)]

Average Scheme Measured Remarks Execution Time RSA-OAEP 84.2 ms e = 17 EPOC-1 21.9 ms None EPOC-2 18.9 ms None EPOC-3 8.3 ms None HIME-1 24.7 ms HIME-1 data size: 256 bits HIME-2 15.3 ms HIME-2 data size: 256 bits ECAES in 160-bit prime field 5.4 ms None SEC1 163-bit field with 8.7 ms None characteristic 2 PSEC-1 24.1 ms None PSEC-2 24.6 ms None PSEC-3 12.0 ms None

[Code Sizes (Reference Values)]

Scheme Measured Code Size Remarks RSA-OAEP 62,413 byte Size of executable test program for performance measurement EPOC-1 177,058 byte EPOC-2 187,662 byte C language (Intel C/ C++) source code sizes EPOC-3 186,851 byte HIME-1 2,631 step C language (Intel C/ C++) HIME-2 2,666 step ECAES in SEC1 356,352 byte Size of executable test program for performance measurement PSEC-1 189,334 byte PSEC-2 202,333 byte C language (Intel C/ C++) source code sizes PSEC-3 196,986 byte

60 CRYPTREC 2000

4.2.3 Key Sharing

In the key sharing category, four cryptographic schemes were submitted for evaluation: DH, ECDHS in SEC1, ECMQVS in SEC1, and HDEF-ECDH. This section describes outlines of these four cryptosystems belonging to the key sharing category. The security of DH is based on the discrete logarithm problem, and that of ECDHS in SEC1, ECMQVS in SEC1, and HDEF-ECDH is based on the elliptic curve discrete logarithm problem (ECDLP). These are summarized in the table below. Table of Public Key Cryptosystems (Key Sharing) DH ECDHS in SEC1 ECMQVS in SEC1 HDEF-ECDH Multiplicative An elliptic curve An elliptic curve Elliptic curves having * group Z p is used. selected at random selected at random trace 3 over prime or one called a or one called a fields and a CM field Koblitz curve is Koblitz curve is with a small used. used. discriminant are used. Recommended Recommended elliptic curve elliptic curve Parameters parameters are parameters are used specified concretely. specified concretely. However, this key However, this key sharing scheme also sharing scheme also works on elliptic works on elliptic curves based on curves based on parameters other parameters other Characteristic than those than those recommended. recommended. 1,024 bits or over is Elliptic curve Elliptic curve Specific elliptic recommended. parameters of 112 to parameters of 112 to curves are not 512 bits in a prime 512 bits in a prime mentioned, except for Recommended field and 113 to 571 field and 113 to 571 the condition of trace parameter sizes bits in a field with bits in a field with three, but 160 bits or characteristic 2 are characteristic 2 are over is specifically listed. specifically listed. recommended. Security is based on Security is based on Security is based on Security is based on the difficulty of the the difficulty of the the difficulty of the the difficulty of the Diffie-Hellman elliptic curve elliptic curve elliptic curve problem. Diffie-Hellman Diffie-Hellman Diffie-Hellman Cryptographic Secure against problem. problem. problem. primitive known attacking Secure against Secure against Secure against known Security Security methods if known attacking known attacking attacking methods. appropriate methods. methods. parameters are selected.

61 CRYPTREC 2000

DH ECDHS in SEC1 ECMQVS in SEC1 HDEF-ECDH Since the DH Secure against Secure against Secure against scheme has many passive attacks. passive attacks. passive attacks, but variations, it is With the existing With the existing not necessarily necessary to specifications, specifications, against active attacks. evaluate the security however, security however, security In order to ensure of each of these against active against active security against variations. Use of attacks is not attacks is not active attacks and to the most basic proved. Forward proved. Forward satisfy forward scheme provides secrecy is not secrecy is not secrecy, it is security against satisfied, either. In satisfied, either. In necessary to modify passive attacks, but order to ensure order to ensure the specifications in not necessarily security against security against such a way as to against active active attacks and to active attacks and to combine the scheme attacks. In order to satisfy forward satisfy forward with digital ensure security secrecy, it is secrecy, it is signatures. At against active necessary to modify necessary to modify present, there are no attacks and to the specifications in the specifications in security problems satisfy forward such a way as to such a way as to about using elliptic secrecy, it is combine the scheme combine the scheme curves having trace 3 Cryptographic necessary to modify with digital with digital and a CM field with a scheme the specifications in signatures. signatures. small discriminant. such a way as to The Koblitz curve The Koblitz curve However, since this combine the scheme features high speed. features high speed. curve is of a limited with digital Use of this curve Use of this curve class, it should be signatures. poses no security poses no security noted that an problems. However, problems. However, attacking method since this curve is of since this curve is of against this particular a limited class, it a limited class, it class could appear. should be noted that should be noted that There are two an attacking method an attacking method schemes, one of them against this against this using the same particular class particular class elliptic curve for all could appear. could appear. users and the other using a different elliptic curve for each user. The scheme using a different curve for each user requires further study of security.

62 CRYPTREC 2000

DH ECDHS in SEC1 ECMQVS in SEC1 HDEF-ECDH When only It is mandated to It is mandated to When only cryptographic use the "Key use the "Key cryptographic primitives are used, Derivation Derivation primitives are used, the sharable key Function" described Function" described the sharable key size size depends on the in ANSI X9.63 as a in ANSI X9.63 as a depends on the size size of the group key derivation key derivation of the elliptic curve used (i.e., size of function. This key function. This key parameters used. For prime number p). derivation function derivation function example, when an For example, when uses a hash uses a hash elliptic curve of 160 prime number p of function. If the function. If the bits is used, a key of 1,024 bits is used, a output of the hash output of the hash up to 160 bits can be key of up to 1,024 function is hashlen function is hashlen shared. bits can be shared. bits, a key of less bits, a key of less To share a key whose To share a key than hashlen × than hashlen × size exceeds the size Sharable key size whose size exceeds (232−1) bits can be (232−1) bits can be of the elliptic curve the size of the group shared. shared. parameter used, it is parameter used, it is SHA-1 is pointed SHA-1 is pointed necessary to use such necessary to use out as a out as a a key derivation such a key recommendable recommendable function as is derivation function hash function. hash function. described in ANSI as is described in When SHA-1 is When SHA-1 is X9.63, etc. in the ANSI X9.63, etc. in used, a key of less used, a key of less cryptographic the cryptographic than 160 × (232−1) than 160 × (232−1) scheme. scheme. bits can be shared. bits can be shared. Even if any other Even if any other hash function is hash function is used, this key used, this key sharing scheme sharing scheme works. works.

【Results of Software Implementation of Public Key Cryptosystems for Key Sharing Use】

Of those public key cryptographic techniques for key sharing use that were evaluated in detail, the following three entries were evaluated for software implementability:

(1) ECDHS in SEC1

(2) ECMQVS in SEC1

(3) HDEF-ECDH

With respect to DH, cryptographic techniques for key sharing use that were submitted for detailed evaluation, the Committee judged that it was not necessary to evaluate it for software implementability partly because it should be evaluated in other respects and partly because it had already been implemented widely.

The above three schemes whose software implementability was evaluated are considered to be at implementable levels. The proposers of these three schemes were requested to select implementation parameters in such a way that security is equal to or higher than that of a 1,024-bit RSA cryptosystem.

Approximate key generation, encryption, and decryption speeds (measured) are shown below together with estimated

63 CRYPTREC 2000

code sizes.

64 CRYPTREC 2000

[Characteristics and Measurement Parameters]

Security Implementation Parameter and Scheme Measured Other Evidence Character ECDHS in 160-bit prime field ECDLP Strength equal to or greater than One of the recommended parameters SEC1 that of RSA encryption in which to the SEC1 specifications. N = 1,024 bits (confidentiality) Based on the ANSI X9.62 specifications. 163-bit field with Strength equal to or greater than Free selection is randomly verifiable. characteristic 2 that of RSA encryption in which As required by the X9.62 N = 1,024 bits (confidentiality) specification, the SHA-1 input value ECMQVS 160-bit prime field Strength equal to or greater than is also described as part of the in SEC1 that of RSA encryption in which parameter. N = 1,024 bits (confidentiality) It has been verified that special attacks are not effective. 163-bit field with Strength equal to or greater than High-speed implementation not characteristic 2 that of RSA encryption in which dependent on parameters is effected. N = 1,024 bits (confidentiality) HDEF-EC Parameter size: Strength equal to or greater than It has been verified that the elliptic DH 160 bits that of RSA encryption in which curve parameters used are secure N = 1,024 bits (confidentiality) against MOV (FR) reduction attacks and SSSA attacks. The base point is fixed for evaluation codes. A power method operation algorithm similar to arbitrary-point power method operations (combination of coded binary notation and the window method) is used. Higher speeds can be expected from the use of a fixed-point algorithm. Multiplication remainder operations in a defined field (160 × 160 → 160 bits) are described in Assembler. Measurement in basic form. Use of an arbitrary-point power method algorithm. Multiplication remainder operations in Assembler.

65 CRYPTREC 2000

[Key Pair Generation]

Average Scheme Measured Remarks Execution Time ECDHS in 160-bit prime field 1.9 ms Key pair generation. SEC1 Key pair verification, which is not necessary if the keys are 5.8 ms generated by the user. 163-bit field with 3.2 ms Key pair generation. characteristic 2 Key pair verification, which is not necessary if the keys are 8.0 ms generated by the user. ECMQVS 160-bit prime field 1.9 ms Key pair generation. in SEC1 Key pair verification, which is not necessary if the keys are 5.8 ms generated by the user. 163-bit field with 3.2 ms Key pair generation. characteristic 2 Key pair verification, which is not necessary if the keys are 8.0 ms generated by the user. HDEF-ECDH 1.5 ms One-side processing. Key size: 160 bits

[Key Sharing Processing (One Side)]

Average Scheme Measured Remarks Execution Time ECDHS in 160-bit prime field 6.6 ms SEC1 163-bit field with 8.8 ms characteristic 2 ECMQVS 160-bit prime field 13.2 ms in SEC1 163-bit field with 16.9 ms characteristic 2 HDEF-ECDH 1.8 ms Key size: 160 bits

[Code Sizes (Reference Values)]

Scheme Measured Code Size Remarks ECDHS in SEC1 356,352 byte Size of executable test program for performance measurement ECMQVS in SEC1 356,352 byte HDEF-ECDH Multiplication remainder operations in a defined field (160 × 73,758 byte 160 → 160 bits) are described in Assembler. The rest is described in C.

66 CRYPTREC 2000

4.3 Evaluation Based on Security Evidence

4.3.1 Integer Factoring Problem

The public key cryptographic schemes shown below claim the security of cryptographic primitives based on the difficulty of prime factoring n by using the remainder ring of integer n in the base algebraic system. This section evaluates these schemes from the viewpoint of integer factoring problem. • Confidentiality: RSA-OAEP, EPOC-1, EPOC-2, EPOC-3, HIME-1, and HIME-2 • Key sharing: None • Authentication: None • Signature: RSA-PSS, ESIGN-signature, and ACE Sign

(1) Security of Cryptographic Primitives

The cryptographic primitives in the cryptographic schemes evaluated in this section have the same characteristic of ceasing to be secure if modulus n in the base algebraic system Zn: =Z/nZ is factored into its prime components. The form of modulus n in each cryptographic scheme is shown below. Function Confidentiality Signature EPOC-1 Cryptographic ESIGN-sign RSA-OAEP EPOC-2 HIME-1 HIME-2 RSA-PSS ACE Sign Scheme ature EPOC-3

d 2 k 2 pq p q p q ∏ pi pq p q pq n = i=1

(p, q, p1, ..., pd are odd prime numbers.)

(a) Evaluation Based on Complexity of Problems

The prime factorization of each n certainly results in a general integer factoring problem. However, the form of n in each scheme has unique characteristics, and a detailed scrutiny reveals subtle differences in the complexity of the problem of factoring n among the individual schemes.

To demonstrate this point, the following six problems (partial functions) are defined:

IntegerFactoring:

The input n (>1) causes the output of {(p1, e1), ..., (pk, ek)}(pi: prime number, ei ≥ 1) in which

e1 ek n = p1 L pk .

Divisor: The input n (>1) causes the output of {a, b}(1 < a, b < n) in which n = ab if n is a composite number and causes the output of n if n is a prime number.

SquarefreePart:

67 CRYPTREC 2000

The input n (>1) causes the output of {r, s} in which n = r2s and s is squarefree.

Factorpq: The input n (>1) causes the output of the combination of prime numbers {p, q} in which n = pq.

Factorpkq (k: constant > 1): The input n (>1) causes the output of the combination of prime numbers {p, q} in which n = pkq.

Factorp1 ... pd (d: constant > 2):

The input n (>1) causes the output of the d-term combination of prime numbers {p1, ... pd} in which n = p1 ... pd.

Now the concept of "reduction" is introduced in order to compare the degrees of difficulty of these

P P functions. A ≤ α B means function A is reducible to function B in the sense of ≤ α reduction. Here α ∈ {m, l − tt, T} (l: constant that is a positive integer), and although the mode of reduction varies with α, this

P can be read, instinctively without regard to α, as follows: " A ≤ α B means that if function B can be

P P P computed, then function A can also be computed." More strictly, A ≤→ m B A ≤ l−tt B → A ≤ T B . When

P P P with respect to a certain α, A ≤ α B and B ≤ α A , it is written A ≡ α B .

It is easy to draw from this the following reduction relations of these functions:

P P Factorpq ≤ m Divisor ≡ T IntegerFactoring

P P Factorp1 ... pd ≤ T Divisor ≡ T IntegerFactoring k P P P Factorp q ≤ β SquarefreePart ≤ T Divisor ≡ T IntegerFactoring (β is m when k = 2 and 1 - tt when k > 2.)

That is, if there is an algorithm to compute IntegerFactoring in polynomial time, all those mentioned above can be computed in polynomial time. However, it is not known whether IntegerFactoring and

Divisor home in on SquarefreePart. It is not known, either, whether Factorpq and Factorp1 ... pd home in on SquarefreePart. At present, therefore, if an algorithm is found to compute SquarefreePart in polynomial time, Factorpkq will be computed in polynomial time, but theoretically it is possible that

IntegerFactoring, DivisionFactorpq, Factorp1 ... pd, etc. all remain as difficult problems.

(b) Evaluation Based on Integer Factoring Algorithms

Under the number field sieve method (NFS), execution time depends on the size of input n, and under the elliptic curve method (ECM), it depends on the size of the smallest prime factor of input n. Therefore, if the size of modulus n is the same in all schemes to be evaluated here, then factoring by the NFS theoretically produces no differences, but the application of the ECM produces a difference between the 2 schemes using modulus n = p q or n = p1 ... pd and those using n = pq. This difference occurs from a

68 CRYPTREC 2000

difference in the size of the smallest prime factor. At least for the purpose of obtaining a single prime factor, the ECM assures shorter execution time in some cases. Generally, where n = pq or n = pkq (k: constant > 1), if one prime factor is known, the rest can be easily factored completely. Where the size of modulus n is expressed as |n| bits and the size of the smallest prime factor as |n|/d bits (d ≥ 2), if the execution time by ECM ≤ the execution time by NFS, then the following inequality using average execution time approximately holds:

1/ 2 1/ 2   n log 2    n log 2     e    e   exp(1.414 + o(1)) log e    d    d         

1/ 3 2 / 3 ≤ exp((1.901+ o(1))( n log e 2) (loge ( n log e 2)) )

The evaluation of these average execution times is not strict by nature. In the above equality, strict evaluation is even more difficult because o(1) (a term that becomes 0 as n → ∞) remains. Some combinations of |n| and d require attention. LFM (Lattice Factoring Method) is a prime factorization k method specifically for composite numbers in the form of n = p q (k: constant > 1). If k = cloge p (c: constant), the average execution time by LFM becomes polynomial time. When k is small (for example, k = 2), the average execution time is estimated to be exponential function time, and it is not a fact that LFM is effective in the factoring of n = p2q.

(2) Security of Schemes

(a) Cryptosystems for Confidentiality

With respect to cryptosystems whose function is to ensure confidentiality, a scheme security model is defined using a combination of goal (GOAL) and attacking method (ATK).

There are three goals: one-way (OW), indistinguishability (IND), and non-malleability (NM). One-way refers to the fact that an attacker given ciphertext y cannot get whole plaintext x by decrypting y. Indistinguishability means that an attacker given two plaintexts x and x' and ciphertext y corresponding to either of the plaintexts cannot determine whether y corresponds to x or x'. Meanwhile, semantical security means that an attacker given ciphertext y cannot acquire an arbitrary part of plaintext x. Non-malleability means that an attacker given ciphertext y cannot acquire ciphertext y' corresponding to plaintext x' that has a certain relation with plaintext x. It is known that against adaptive chosen ciphertext attacks (described later), indistinguishability is equivalent to semantical security and non-malleability.

Meanwhile, there are three types of attack: chosen plaintext attack (CPA), non-adaptive chosen ciphertext attack (CCA1), and adaptive chosen ciphertext attack (CCA2). A chosen plaintext attack is made in a situation in which an attacker is only given a public key. Using the public key, the attacker conducts an attack while getting the ciphertext corresponding to plaintext he or she has freely chosen. Chosen

69 CRYPTREC 2000

plaintext attacks are unavoidable in public key cryptosystems in principle. In a non-adaptive chosen ciphertext attack, the attacker is given a public key and is also allowed to access a decryption oracle until getting ciphertext to be decrypted. In an adaptive chosen ciphertext attack, the attacker is given a public key and is also allowed to access a decryption oracle before and after getting ciphertext to be decrypted. However, it is prohibited to request a decryption oracle to decrypt the ciphertext itself to be decrypted.

The nine combinations of the above GOAL ∈ (OW, IND, NM) and ATK ∈ (CPA, CCA1, CCA2) express the security of cryptographic schemes in terms of the sign GOAL-ATK). This means that a particular scheme attains a goal (GOAL) against an attack (ATK). It needs to be logically proved whether this is true. It is known that if the property IND-CCA2 (semantically secure against adaptive chosen ciphertext attacks) is proved, all the other (eight) combinations are secure. In this sense, IND-CCA2 provides the highest degree of security. However, security is generally proved in this form: "In a model in which random numbers with a certain property can be used (random function assumption), if it is difficult to solve a certain number theoretic problem, then the security is GOAL-ATL." A random number assumption is expressed in a form such as "truly random numbers can be used." A number theoretic problem is expressed in a form such as "if a certain problem is difficult." Concrete problems differ from one cryptographic scheme to another.

An expression such as "strong" and "weak" assumptions is basically an expression of comparative relations of assumptions. For example, the assumption of a model in which truly random numbers can be used (random oracle model) is a stronger assumption than a model in which pseudo-random numbers suffice (pseudo-random function model). In the case of number theorem problem assumptions, when problem A results in problem B (A ≤ B), the assumption that B is difficult is a comparatively weaker than the assumption that A is difficult. Meanwhile, the degree of assumption is expressed not as comparative relations but as general quality. For example, the expression "weak assumption" may be used when it is widely recognized that a certain number theorem problem is difficult or when a conjecture that everyone believes to hold in the field of cryptography (such as the presence of a one-way function or P ≠ NP) is assumed.

From the above, it follows that when the security of cryptographic schemes is to be proved, it produces the strongest results to prove that IND-CCA2 holds under the weakest possible assumption. With respect to the cryptographic schemes with confidentiality functions discussed in this section, what has been proved about their security is expressed below in terms of the sign mentioned above. (In parentheses are random function assumptions.)

RSA-OAEP: IND-CCA2 under the assumption that the RSA encryption function is one-way permutable (difficult to calculate the inverse function) (random oracle model)

70 CRYPTREC 2000

EPOC-1: IND-CCA2 under the assumption that the p- subgroup problem is difficult (random oracle model)

EPOC-2: IND-CCA2 under the assumption that it is difficult to prime factorize n = p2q (random oracle model)

EPOC-3: IND-CCA2 under the assumption that the GAP-integer factoring problem of the type n = p2q is difficult (random oracle model)

HIME-1: Although the self-evaluation report claims IND-CCA2 under the assumption that it is difficult to prime factorize the composite number (1 < k < min {p, q}) of the n = pkq type (random oracle model), it cannot be verified. (It has been found that OAEP transformation alone is not enough for IND-CCA2 to hold.)

HIME-2: Although the self-evaluation report claims IND-CCA2 under the assumption that it is

difficult to prime factorize composite numbers of the n = p1 ... pd type (random oracle model), it cannot be verified. (It has been found that OAEP transformation alone is not enough for IND-CCA2 to hold.)

Each of the above number theorem problem assumptions is a stronger assumption than the difficulty of IntegerFactoring. The assumption of the difficulty of the p- subgroup problem or the GAP integer factoring problem is a stronger assumption than the difficulty of Factorpkq. However, no efficient solution has been found to any of the above number theorem problems.

(b) Cryptosystems for Signature

As regards the security of cryptographic schemes with signature functions, the combinations of GOAL and ATK are as follows: There are three goals: general unforgeability, chosen unforgeability, and existential unforgeability. General unforgeability means that there is a document on which a signature cannot be forged. Chosen unforgeability means that signatures cannot be forged on documents other than certain ones. Existential unforgeability means that signatures cannot be forged on any documents.

The types of attacks are passive attack, general chosen message attack, and adaptive chosen message attack. A passive attack is an attack in which a signature is forged using only a public key. A general chosen message attack is an attack in which after a document chosen by an attacker is signed by a genuine signer, the attacker forges, using the information obtained from it, a signature on another document. An adaptive chosen message attack is an attack in which after a document chosen by an attacker is signed by a genuine signer, the attacker repeats the same thing on adaptively chosen documents and finally forges a signature on another document, using the information thus obtained. Evidently, the property of being

71 CRYPTREC 2000

existentially unforgeable against adaptive chosen message attacks provides the highest security. With respect to the security of cryptographic schemes with signature functions, the following facts are pointed out:

RSA-PSS: Existentially unforgeable against adaptive chosen message attacks under the assumption that the RSA encryption function is one-way permutable (random oracle model)

ESIGN-signature: Existentially unforgeable against adaptive chosen message attacks under the assumption that the e-th root approximation problem (AER) against moduli of the n = p2q is difficult (random oracle model)

ACE Sign: Existentially unforgeable against adaptive chosen message attacks under the assumption of a strong RSA assumption (pseudo-random function model)

The assumption in ACE Sign is weak in that its security is proved in a practical model not using true random numbers. However, the number theorem problem assumption is the strong RSA assumption. The

* strong RSA assumption is an assumption that when RSA modulus n and y ∈ Z n are given, it is difficult

* r to find x ∈ Z n and r > 1 making y ≡ x (mod n). This assumption is stronger than the assumption of one-way permutation of the RSA encryption function. These assumptions, including the strong RSA assumption, are stronger than the assumption that IntegerFactoring is difficult, but no efficient solutions have been found to any of the problems.

72 CRYPTREC 2000

4.3.2 Discrete Logarithm Problem

Using the prime field Fp as the base algebraic system, this section evaluates cryptographic schemes based on the difficulty of discrete logarithm problems on Fp in terms of a common discrete logarithm problem. The following schemes are evaluated:

• Confidentiality: ACE Encrypt • Key sharing: DH • Signature: DSA

(1) Base Problems for the Schemes

The security relation of each of these schemes with a problem can be discussed under certain assumptions. The schemes discussed in this section are all based on the discrete logarithm problem (DLP). Therefore, if an efficient solution to the DLP is proposed, all the schemes will cease to be secure. However, the opposite is not necessarily true. For the clear description of the security of each scheme, the base problems are defined here.

* x * DLP: The problem of finding x ∈ Z p−1 making y = g (mod p) when g ∈ Fp and y ∈ F p are given, where p is a prime number.

ab * CDH: The problem of finding K = g (mod p) when g ∈ Fp and yA, yB ∈ F p are given, where p is a prime a b number. Here, yA = g (mod p), yB = g (mod p).

DDH: The problem of outputting 1 if C = gab (mod p) and 0 in other cases when A = ga, B = gb, and C ∈

* F p are given, where p is a prime number.

(2) Relations between Functions

For explanation of the difficulty of solving the problems mentioned above, these problems are defined as functions, and the degrees of complexity of the functions are compared using the concept of inter-function reduction.

Generally, when function F can be calculated using a subroutine (oracle) to calculate function G, it is said that function F homes in on function G. The concept of reduction is described below in the form corresponding to the contents of this section. A more general, strict definition of reduction is described in [10] or elsewhere.

Definition 1 (Polynomial time Turing reduction) With respect to functions F and G, if F(x) becomes

j−1 h j ()o i=0 (G o hi ) (x) by using function hi, (1 ≤ i ≤ j − 1) that can be calculated by polynomials and

73 CRYPTREC 2000

subroutines of up to the number of times (j times here) of |x| for any x, then F is said to home in on G in

FP polynomial time Turing reduction. This is written: F ≤ T G.

The following relations hold between the functions DLP, CDH, and DDH that express the difficulty of the schemes.

FP FP Theorem 1 ([17]) DDH ≤ T CDH ≤ T DLP

(3) Security of the Schemes

The security of each scheme is discussed. It is discussed whether cryptographic schemes for confidentiality are semantically secure against adaptive chosen ciphertext attacks and whether cryptographic schemes for signature are existentially unforgeable against adaptive chosen message attacks. That is, security against active attacks as well as passive attacks is usually discussed. However, since no active attacks can be considered in the case of non-interactive DH, it meets the implicit secrecy requirement under the assumption that a public key is correct.

Theorem 2 ([6]) ACE Encrypt is IND-CCA2 under the assumption that a hash function is a universal one-way function and that CDH is difficult. Here, a general one-way hash function is a function in which it is difficult to find z in h(x) = h(z) when function h and x in its domain are given.

Lastly, the reduction relation between DSA and the discrete logarithm problem is shown.

Theorem 3 ([11]) Under the assumption that a hash function is a random function and the DLP is difficult, DSA in which the hash function is modified is existentially unforgeable against adaptive chosen message attacks.

Here, random function [2] is an ideal hash function that outputs truly random data in response to input data. (4) Algorithms to Solve the Discrete Logarithm Problem

This section describes algorithms to solve the DLP. It was mentioned in the previous section that although the schemes use the DLP, the security of some of them is less than the DLP. However, the only realistic solution is a DLP solution. In this sense, it is advisable to set parameters in such a way as to be secure against DLP solutions.

Algorithms to solve the discrete logarithm problem can be broadly divided into the following two types:

1. Algorithm that obtains logg y dependent on the order l of H when H = ⊆ G. Its calculation time is the execution time of the exponential time order O( l ) of the size of the largest prime number of l.

74 CRYPTREC 2000

2. Algorithm that obtains logg y by a method called the "index calculus method" on the condition that G

* k = F q (q = p ). Its calculation time is the execution time of the subexponential time order of the size of a finite field Fq.

Algorithms belonging to the first type include those of Shanks [15], Pohlig-Hellman [12], and Pollard [13]. Algorithms belonging to the second type include those of Adleman [1], Coppersmith [3], El Gamal [5], Pomerance [14], Coppersmith-Odlyzko-Schroeppel [4], and Gordon [8], [9].

(a) Algorithms dependent on order

Shanks' algorithm:

G ∋ g, the order of H = ⊆ G is l, m = |l1/2|, 0 ≤ r, and q ≤ m.

Assume that for H, there is monomorphism represented by f:H → {1, ..., n} and that it can be calculated within the low order polynomial time of logl.

Step 1: Calculate the following groups, L1 and L2: i L1 = {(i, f (yg ))|0 ≤ i ≤ m}, mi L2 = {(i, f (g ))|0 ≤ i ≤ m}

Step 2: Sort the elements of L1 and L2 for the second component.

Step 3: Search for the second components of the elements of L1 that agree with those of L2. Express these as follows: r mq (r, f (yg ) ∈ L1, (q, f (g )) ∈ L2

At this time, the equation y = gmq−r holds because ygr = gmq.

Therefore, by obtaining r and q, the equation logg y = mq − r is obtained.

The total calculation time in this algorithm is O( l ). A memory area to store O( l ) elements is required.

75 CRYPTREC 2000

Pohlig-Hellman's algorithm:

The order of H = ⊆ G is l.

Step 1: Assume that l is factorized as follows:

k ei l = ∏ pi , p1 < ... < pk (pi: different prime number) i=1

Step 2: Determine logg y at each Z e . pi i

Step 3: Determine logg y ∈ Zl by compositing the values obtained in step 2 based on the Chinese remainder theorem:

Zl ≅ Z e × ... × Z e pi i pk k

k The execution time of this algorithm, which depends on step 2, is O (∑i=1 ei (logl + pi )) . Therefore, it is the exponential function order of the size of the largest prime number pk of l. However when l is O(logl)-smooth, O( log l ) is obtained. That is, this algorithm is effective when p − 1 is a product of small prime numbers.

(b) Index Calculus Method

The index calculus method is similar to efficient integer factoring algorithms in many respects. A general exponential calculation algorithm consists of two steps. In step 1, the discrete logarithms of subgroups (factor bases) selected appropriately from H = ⊆ G are obtained and are stored in a database. In step

2, logg y is actually obtained using this database. This general algorithm is described below.

General algorithm of the index calculus method

Step 1: Let the order of H = ⊆ G, H be l. As a factor base, β = {p1, ... pm} ⊆ H is determined, and bi that can be decomposed as follows is sought:

m bi aij g = ∏ p j j=1

The logarithms of the two sides are:

m bi ≡ ∑ aij log g p j (mod l) j=1

This can be regarded as an equation in which logg pj is an unknown. With respect to bi, assume

that #{bi} ≥ #β. At this time, if the order of the matrix A = (aij) on Zl is m (= #β), then the linear

76 CRYPTREC 2000

equation concerning logg pj (1 ≤ j ≤ m) has a unique solution, and the discrete logarithm of each element of β is learned.

Step 2: r is selected at random. The selection is continued until ygr is decomposed as follows:

m r e j yg = ∏ p j j=1

The logarithms of the two sides are:

m logg y = ∑e j log g p j − r j=1

Thus logg y can be obtained.

Adleman's algorithm:

This is an algorithm applying the idea of integer factoring by the continued fraction method. Against the

* discrete logarithm problem of G = H = Z p , this algorithm sets a set of prime numbers of up to u = Lp [1/2,

0] with the factor base being β. That is, in step 1 of this algorithm, bi is selected at random, and only the bi that makes g bi -smooth is sieved. Although selecting β this way brings some assumptions into the

bi evaluation of the probability of g becoming smooth, the algorithm execution time becomes Lp [1/2, c](c ≈ 1).

Pomerance's algorithm:

An improved version of Adleman's algorithm, Pomerance's algorithm evaluates strict execution time without assumptions. The speed is Lp [1/2, 2 ], nearly equal to that of Adleman's algorithm.

Gordon's algorithm:

This algorithm applies the concept of integer factoring by the number field sieve method. There are two types: one based on a general number field sieve method and the other based on a special number field sieve method. The algorithm of the former type is applicable to p in general. The execution time is Lp [1/3, 2/3 3 ] = Lp [1/3, 2.08008]. The algorithm of the latter type is applicable to p having a particular property.

The execution time is Lp [2/5, 1.00475]. The particular property is a property that enables the selection of an integral coefficient irreducible monic polynomial f that meets the following requirements:

1. The coefficient of f ∈ Zp [X] is adequately small.

2. There are integers x and y that are both of the sizes of about p1/k and that meet the requirement: yk f (x/y) ≡ 0 (mod p).

3. Ok = Z [α] is a unique factorization domain.

77 CRYPTREC 2000

The table below summarizes the effective algorithms known at present together with their computational complexity and the conditions for making algorithm effective.

Prime Number Conditions to Algorithm Complexity Make Algorithm Effective

Shanks' algorithm O( l ) + + storage area O( l ) General (all prime numbers)

k Pohlig-Hellman's algorithm O(∑i=1 ei (logl + pi )) p − 1 is a product of small prime numbers.

Adleman's algorithm L p []1/ 2,c General (all prime numbers)

Pomerance's algorithm Lp [1/ 2, 2] General (all prime numbers)

2/ 3 Gordon's algorithm Lp [1/3,3 ] General (all prime numbers)

Therefore, a cryptosystem whose security is based on the difficulty of the discrete logarithm problem, it is necessary to set a parameter (prime number p) that makes the above algorithms difficult.

(d) Difficulty of the DLP with selected prime numbers

The security of each scheme is generally discussed under the assumption that the DLP is difficult. That is, in these discussions, the selection of a specific group to be used in the DLP is not discussed. In other words, it is not discussed what is to be used as a finite field Fp. However, when actual security is discussed, the selection of a finite field is important, especially in the case of DLP-based schemes because they often use a fixed finite field Fp in all systems. This section discusses the security of the DLP in the finite fields recommended by the proposed schemes.

Of the three proposed schemes, DSA and ACE Encrypt present recommended finite fields. Their conditions are shown below.

78 CRYPTREC 2000

Prime Number Conditions Size DSA 2L−1 < p < 2L L is a multiple of 64. 512 ≤ L ≤ 1,024 ACE Encrypt None 1,024 bits or over

From the viewpoint of processing speed, DSA sets the size of prime numbers to be taken on a 64-bit basis. No effective algorithms to solve the DLP using such prime numbers have been proposed to date. However, with respect to the limitation of the DSA size to 1,024 bits or under, it would be necessary to increase the key size to over 1024 bits depending on future developments in solution algorithms and computer performance. As regards ACE Encrypt, there seems to be no particular problem at present about the way of taking prime numbers.

(6) Summary

The table summarizes the basic problems and assumptions of each scheme.

Table 4.2.1 Summary of DLP-Based Schemes

Function Confidentiality Key Sharing Signature Scheme ACE Encrypt DH (Modified) DSA Security Evidence DDH CDH DLP Assumption Universal one-way hash function implicit secrecy Random hash function

79 CRYPTREC 2000

References [1] L.M. Adleman, "A subexponential Algorithm for the Discrete Logarithm Problem with Applications to Cryptography," Proc. of FOCS, pp. 50-60 (1979).

[2] M. Bellare and P. Rogaway, "Random oracles are practical: A paradigm for designing efficient protocols," 1st ACM Conf. on Computer and Communications Security, pp. 62-73, 1993.

[3] D. Coppersmith, "Fast Evaluation of Logarithms in Fields of Characteristic Two," IEEE Trans. Inform. Theory, IT-30, pp. 587-594 (1984).

[4] D. Coppersmith, A.M. Odlyzko and R. Schroeppel, "Discrete Logarithms in GF (p)," Algorithmica Vol. 1, pp. 472-492 (1986).

[5] T. ElGamal, "A subexponential-Time Algorithm for Computing Discrete Logarithms over GF (p2)," IEEE Trans. Inform. Theory, IT-31, pp. 473-481 (1985).

[6] R. Cramer and V. Shoup, "A practical public key cryptosystem provably secure against adaptive chosen ciphertext attack," In Advances in Cryptology Crypto '98, pp. 13-25, 1998.

[7] W. Diffie and M.E. Hellman, "New directions in cryptography," IEEE Trans. Information Theory, Vol. IT-22, pp. 644-654, 1976.

[8] D.M. Gordon, "Discrete Logarithm in GF (p) Using the Number Field Sieve," to appear in SIAM Journal on Discrete Math

[9] D.M. Gordon, "Designing and Detecting Trapdoors for Discrete Log Cryptosystems," Proc. of CRYPTO '92, LNCS 740, pp. 66-75 (1992).

[10] H. Sakurai and H. Shizuya, "A Structual Comparison of the Computational Difficulty of Breaking Discrete Log Cryptosystems," In Journal of Cryptology, 11: 29-43, Springer-Verlag, 1998.

[11] D. Pointcheval and J. Stern, "Security Proofs for Signature Schemes," In Advances in Cryptology –EUROCRYPT '96, pp. 387-398, 1996.

[12] S. Pohlig and M. Hellman, "An Improved Algorithm for Computing Logarithms over GF (p) and Its Cryptographic Significance," IEEE Trans. Information Theory, 24, pp. 106-110 (1978).

[13] J.M. Pollard, "Monte Carlo Methods for Index Computation mod p," Math. Comp. 32, pp. 918-924 (1978).

[14] C. Pomerance, "Fast, Rigorous Factorization and Discrete Logarithm Algorithm, Discrete

80 CRYPTREC 2000

Algo-rithms and Complexity," Proc. of the Japan-U.S. Joint Seminar, Academic Press, pp. 119-143 (1987).

[15] D. Shanks, "Class Number, a Theory of Factorization," and Genera, Proc. Symposium Pure Math-ematics, AMS (1972).

[16] National Institute of Standards and Technology (NIST), FIPS Publication 186: Digital Signature Standard May 19, 1994.

[17] H. Woll, "Reductions among number theoric problems," In Information and Computation vol. 72, pp. 167-179, 1987.

81 CRYPTREC 2000

4.3.3 Elliptic Curve Discrete Logarithm Problem

This section evaluates cryptographic schemes whose security is based on the difficulty of an elliptic curve discrete logarithm problem (ECDLP) defined in a finite field. The schemes evaluated are as follows:

• Confidentiality: ECAES in SEC1, PSEC-1, PSEC-2, and PSEC-3 • Key sharing: ECDHS in SEC1, ECMQVS in SEC1, and HDEF-ECDH • Signature: ECDSA in SEC1, MY-ELLTY ECMR-160/192/OEF-h

(1) ECDLP and Related Problems

The security of the schemes mentioned above is fundamentally based on the elliptic curve discrete logo problem and problems derived from it.

ECDLP: The problem of find a ∈ z satisfying P = aG when G ∈ E (Fp) and P ∈ are

given, where E/Fq is an elliptic curve defined over Fq.

EC-CDH (EC-DH): The problem of find R = abG when G ∈ E (Fq), P = aG, and Q = bG ∈ E (Fq) (a, b ∈ z) are given.

EC-DDH: The problem of output 1 if R = abG ∈ E (Fq) and 0 otherwise when 4 (G, P, Q, R) ∈ E (Fq) , P = aG, and Q = bG are given.

EC-GAP-DH: The problem to solve EC-CDH by assuming an EC-DDH oracle when 4 (G, P, Q, R) ∈ E (Fq) is given.

The following relations are known between the difficulties of these problems:

FP FP EC-DDH ≤ T EC-CDH ≤ T EC-DL

Problems related with discrete logarithms on elliptic curves can be considered as extensions of the problems related with discrete logarithms on finite fields. However, their mutual relations have not been fully clarified yet except in special cases.

(2) Elliptic Curve Cryptosystems

Subexponential time or polynomial time attacks have been found against ECDLP over special elliptic curves. However, all attacks known at present against cryptosystems based on discrete logarithms on general elliptic curves are of exponential time.

82 CRYPTREC 2000

(a) Pollard's rho method

The most powerful attack against elliptic curve cryptosystems at present is parallel Pollard's rho method.

Pollard's rho method: When P, Q ∈ E (Fq) and xP = Q, to find the discrete logarithm x.

Step 1: Select a random function: f:

→

;

• Starting with Q0: = Q ∈

, find collision Qi+1 = f (Qi). In particular, starting with

Q0 = [a0] P + [b0] R and a0, b0 ∈ Z, calculate the sequence of points

Qi+1 = f (Qi), Qi = [ai] P + [bi] R

until Qi equals Qj ;

−1 • If bi ≠ bj, then calculate R = (bi − bj) (ai − aj) from [ai − aj] P + [bi − bj] R = O;

• Output discrete logarithm −1 logp Q = a0 − (bi − bj) (ai − aj) b0

The computational complexity of Pollard's rho method is an exponential function of the key length,

O( pmax ), where pmax is the maximal prime factor of the order of the group of rational points of the

elliptic curve E (Fq) . Comparing with Shanks’ BSGS method, the Pollard’s rho method is almost memory-free and easy for parallel implementation. The computational complexity of a parallel Pollard’s

rho method with n CPUs is O( pmax / n ).

Therefore, the ECDLP of an elliptic curve with an order containing a large prime factor is regarded as more difficult than the DLP on finite fields which are threaten by subexponential time attacks.

The records to break elliptic curve cryptosystems to date include breaking a Koblitz curve of a key length of 97 bits over a prime field and a Koblitz curve of a key length of 109 bits over a finite field of characteristic two. These attacks required group operations of 4 × 105 MIPS·Years, 50 times as much as in breaking 512-bit RSA.

Presently, primitives for cryptosystems based on 160-bit and 210-bit ECDLP are considered to have the same level of security as that of 1,024-bit and 2,048-bit IF and DLP.

83 CRYPTREC 2000

(b) Attacks by the Weil pairing and the Tate pairing

MOV attack and Frey-Ruck attack (FR attack) are proposed against elliptic curves with special structures. In these attacks, the ECDLP is transformed to the DLP on the multiplicative group of the ground field or its extension by using the Weil pairing (MOV reduction) and the Tate pairing(FR attack).

For an elliptic curve E /Fq where p = char Fq, the Weil pairing is defined, when gcd (m, p) = 1, as a mapping from the m-torsion group E (Fq)m, to an extension field F of the defined field Fq, which qk contains µm, the group of the m-th roots of 1:

em: E (Fq)m × E (Fq)m → µm (F ) qk

This mapping can be calculated by using Miller's probabilistic polynomial time algorithm.

In addition, the FR attack used the Tate pairing:

tm: E (Fq)m × E (Fq) / mE (Fq) → µm (F ) qk

This mapping can be calculated by using a probabilistic polynomial time algorithm, an expanded version of Miller's algorithm.

Generally, definitions of these mappings require that the m-torsion group E (Fq)m is contained in E (F ) qk

or µl, the l-th root of 1is contained in F so that the ECDLP over E (Fq) is transformed to the DLP over qk

F . qk

In the case of a supersingular elliptic curve whose trace t := q + 1 − #E (Fq) ≡ 0 mod p, the extension degree k of the defined field is less or equal to six. Therefore, the ECDLP can be attacked in subexponential time.

In the case of an elliptic curve E of trace two or t ≡ 2 mod m, the ECDLP on E (Fq)m can be transformed

× into the DLP on F q in probabilistic polynomial time. Therefore, the ECDLP on an elliptic curve of trace two is vulnerable to subexponential time attacks. However, in order to define an injective mapping of a subgroup of general elliptic curves into the multiplicative group of an extension field of the defined field,

84 CRYPTREC 2000

the extension degree k is an exponential function of log q. Therefore these attacks are generally not of subexponential time.

An elliptic curve E is called a p-divisible elliptic curve if its order can be divided by a power of the characteristic p = char Fq of the defined field Fq. In the SSSA attack proposed by Semaev, Smart, and Sato-Araki, logarithmic differentiation is used to build a map of the p-torsion group of such an elliptic curve to the additive group of the definition field Fq in polynomial time:

+ E (Fq)p → F q

In particular, a p-divisible elliptic curve over a prime field Fp is an elliptic curve of trace 1. Such an elliptic curve E/Fq is sometime called an anomalous elliptic curve. Anomalous elliptic curves over prime fields are subject to the SSSA attack.

(d) Attack using the Weil descent

In an attack using the Weil descent, the discrete logarithm problem on an elliptic curve defined over certain extension field of a finite field is transformed into the discrete logarithm problem over a hyperelliptic curve. The class of elliptic curves subjected to such attack, computational complexity and implementation details of this attack have not been fully analyzed yet. Applying Gaudry’s fast variation of the attack by Adleman-DeMarrais-Huang on hyperelliptic curve cryptosystems with large genera, this attack could be faster than Pollard's rho method if it is possible to construct by Weil restriction a hyperelliptic curve of a genus larger than 4.

(e) Attack using an automorphism group

A large automorphism group of an elliptic curve can be used to speed up Pollard's rho method. When an elliptic curve has an automorphism group of order m, the rho method will be m -time faster. General elliptic curves only have trivial automorphism groups. However, when an elliptic curve E is defined over an extension field F and its equation is defined on the subfield Fq, the order m of its automorphism qk group is a multiple of k. Therefore, care should generally be taken to use such curves.

(3) Difficulty of the ECDLP on a selected elliptic curve

The security of each proposed scheme is generally discussed under the assumption that the ECDLP is difficult. In particular, selection of specific groups to be used in the ECDLP is not discussed. In other

85 CRYPTREC 2000

words, it is not discussed that what kind of elliptic curve E/Fq is to be used. However, when actual security is concerned, the selection of elliptic curves is important, especially in the case of ECDLP-based schemes because they often use a fixed elliptic curve E/Fq in all systems. This section discusses the security of the ECDLP using the elliptic curves recommended by the proposed schemes.

It is considered that all the submitted cryptosystems are secure against attacks such as those by parallel Pollard's rho method, which is the most powerful method against general curves, because they use elliptic curves with orders containing prime factors no less than 160 bits. These cryptosystems also avoid special curves that are vulnerable to MOV, FR, SSSA, and other attacks in which the rational point group on an elliptic curve is mapped to a finite field. In many cases, the strategy of selecting elliptic curves from a wide range of classes of curves is adopted from the viewpoint of security. In some cases, however, elliptic curves are selected from a special class of curves due to their merits in implementation, etc.. ECAES in SEC1, ECDSA in SEC1, ECDHS in SEC1, and ECMQVS in SEC1 include the Koblitz curves, which is suitable for high speed processing, in the curves they recommend. The Koblitz curve is an elliptic curve of trace one on E/F , that is, an anomalous curve, lifted to the extension field F . The Koblitz curve is 2 2r also called an anomalous binary curve. Meanwhile, HDEF-ECDH uses a curve of a peculiar class (elliptic curve E/Fq of trace 3). (a) Security of schemes

• Confidentiality

Each of the ECDLP-based confidentiality schemes has security measures against adaptive chosen ciphertext attacks.

Table 4.2.2 Security of ECDLP-Based Confidentiality Schemes against IND-CCA2

Scheme ECAES in SEC1 PSEC-1 PSEC-2 PESC-3 Security EC-adaptive-hash-DH EC-Subdecision-DH EC-DH problem EC-GAP-DH problem Evidence problem problem Assumption Common key and MAC Random oracle Random oracle Random oracle

In particular, ECAES in SEC1 proved security against adaptive chosen ciphertext attacks under the assumption which is a variation of the EC-DDH. A possible proof based on EC-GAP DH problem is also pointed out using a random oracle model.

• Key sharing

The key sharing schemes are considered secure against passive attacks, but their security against active attacks needs to be examined.

86 CRYPTREC 2000

With respect to ECDHS and ECMQVS in SEC1, it is pointed out that their combination with signatures provides security against active attacks and forward secrecy.

Table 4.2.3 Security of ECDLP-Based Key Sharing Schemes against Passive Attacks

Scheme ECDHS in SEC1 ECMQVS in SEC1 HDEF-ECDH Security Evidence DH problem on elliptic curves DH problem on elliptic curves DH problem on elliptic curves

• Signatures

ECDSA in SEC1 is considered secure against passive attacks, but its security against active attacks needs to be examined.

With respect to MY-ELLTY ECMR-160/192/OEP-h, problems are pointed out about the realization of a random oracle by an 80-bit hash function.

Table 4.2.4 Security of ECDLP-Based Signature Schemes against Passive Attacks

Scheme ECDHS in SEC1 MY-ELLTY ECMR-160/192/OEP-h Security Evidence ECDLP ECDLP Assumption Random oracle Random oracle

87 CRYPTREC 2000

4.4 Evaluation of Individual Cryptosystems

4.4.1 ACE Sign

1. Cryptography

1.1 Technical Overview

ACE Sign is a special transformation of the signature scheme proposed by Ronald Cramer and Victor Shoup in 1999 at the 1999 ACM Conference on Computer and Communication Security. It was announced as a manuscript by Thomas Schweinberger and Victor Shoup at the Zurich institute of IBM in 2000 and was proposed by IBM Japan, Ltd. ACE Sign is a public key system that realizes signatures based on the difficulty of integer factoring (IF) (of pq type where (p − 1)/2, (q − 1)/2 are also the prime number).

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

The intellectual property rights concerning ACE Sign are held by IBM. Ronald Cramer, Victor Shoup, "Practical non-malleable public-key cryptosystem" filed February 16, 1999. IBM declared that if ACE Sign was adopted (by ISO), it would license it without discrimination and under appropriate fee conditions.

1.2 Technical Specifications

Outlines of signature generation and signature verification functions are shown below.

[Private Key]

( p −1) (q −1) Two prime numbers p, q (where p'= , q'= are also prime numbers.) 2 2

[Public Key] n (= pq) e': prime number |e| = 160 a, b: ∈ QRn

[Hash functions]

160 H1: {0, 1}* → {0, 1}

88 CRYPTREC 2000

160 H2: {0, 1}* → {0, 1}

【Signature Generation】

Signature s on plaintext m is obtained as shown below. (Unless otherwise specified, operations are performed under mod n.)

1. k: Random number

2. h1 ← H1 (k, m)

3. y' ∈ QRn 4. x' ← (y')e' a h1 5. e: prime with certificate; e ≠ e', |e| = 160

6. h2 ← H2 (k, x') 7. d ← 1/e mod p'q' 8. y ← (x/ar)d 9. s ← e||y||y'||k

In the above, e is generated using the sum/counter mode of MARS and is given with the parameters used there as evidence.

【Signature Verification】

The signature s on plaintext m is verified as shown below. (Unless otherwise specified, operations are performed under mod n.)

1. e||y||y'||k ← s

2. It is checked whether e is a prime with evidence and whether e ≠ e'. If any of these conditions is not satisfied, the operation ends with the output of "reject."

3. x' ← (y')e' h H1(k ,m)

4. It is checked whether b = ye a H2 (k,x′) . If the condition is satisfied, the operation ends with the output of "accept." Otherwise, the operation ends with the output of "reject." In the above, e is generated using the sum/counter mode of MARS and is given with the parameter used there as evidence.

This cryptosystem is designed as to achieve a good balance between security and efficiency. This cryptosystem is suitable for applications that require high degrees of security while tolerating the performance of this cryptosystem with the use of digital signatures.

This cryptosystem is based on a method recently discovered by Cramer and Shoup. Based on a strong

89 CRYPTREC 2000

RSA assumption, it can be proved that this cryptosystem is existentially secure (existentially unforgeable) against adaptive chosen message attacks. In this proof, no arguments are based on a random oracle model. However, if arguments are based on a random oracle model, the security of this cryptosystem can be proved under the usual RSA assumption.

2. Evaluation Results

2.1 Evaluation of Security

(a) Security of primitives

No effective attacks have been confirmed to date.

The security of primitives is based on the difficulty of finding the e-th root under mod n. Since special prime factors are used, the difficulty of finding the e-th root is unknown. It is required that the hash function used have general onewayness (more precisely, the second pre-image collision resistance) and that the symmetric cryptosystem have pseudo-randomness when used in a sum/counter mode.

The random numbers used for signature generation need to be fully random.

(b) Security of parameters

( p −1) (q −1) The security of parameters is based on the difficulty of integer factoring of the pq ( , being 2 2 prime numbers as well). Since special prime factors are used, the difficulty of integer factoring is unknown. The key generation specifications should be modified to make the parameters resistant against the p + 1 method (an integer factoring method) as well.

The security of this scheme has been proved on a standard model (under circumstances close to actual ones). The security is based on the strong RSA problem, an assumption concerning a general hash function (the second pre-image collision resistance of SHA-1), and an assumption concerning the pseudo-randomness of symmetric cryptography (the pseudo-randomness of the MARS in the sum/counter mode). (It should be noted that the strong RSA problem is a more special assumption than the RSA problem or the integer factoring problem.)

In this scheme, a general one-way hash function is made from the hash function SHA-1 and evidence is given to prime numbers generated by using the symmetric cryptosystem MARS in the cumulative/counter mode. Hence the need for the assumption concerning the second pre-image collision resistance of SHA-1

90 CRYPTREC 2000

and the assumption concerning the pseudo-randomness of the MARS in the sum/counter mode.

As evaluated on a random oracle model, the security of this scheme depends on the RSA problem.

2.2 Software Implementation Evaluation

With respect to ACE Sign, its specifications were modified after it was entered for evaluation. Therefore, the Committee did not evaluate the software implementability corresponding to the techniques described in the initially submitted documents.

2.3 Other

This scheme is so tactfully built that it lacks flexibility. For example, if the hash function is replaced by the simple SHA-1, it impairs the security of the scheme. Furthermore, when the symmetric cryptographic primitive (MARS) is changed, it is not clear whether it is possible to give evidence to the prime numbers generated.

4.4.2 ESIGN-signature

1. Cryptography

1.1 Technical Overview

ESIGN-signature is an electronic signature method (using public key cryptography) based on e-th root approximation functions. It was proposed by NTT. It is based on a basic ESIGN signature function [OS], [O], transforming it using a cryptographic scheme [IFM] in which a hash function is used as an auxiliary function.

[OS] Okamoto, T. and Shiraishi, A.: A Fast Signature Scheme Based on Quadratic Inequalities, Proc. of the ACM Symposium on Security and Privacy, ACM Press (1985).

[O] Okamoto, T.: A Fast Signature Scheme Based on Congruential Polynomial Operations, IEEE Trans. on Inform. Theory, IT-36, 1, pp. 47-53 (1990).

[OFM] Okamoto, T., Fujisaki, E. and Morita, H.: TSH-ESIGN: Efficient Digital Signature Scheme Using Trisection Size Hash, submission to P1363a (1998).

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

91 CRYPTREC 2000

• There are two registered Japanese national patents and one USP/CANADA/EP: (1) Registration No. 1875643, Application No. 60-42052: Signed Document Transmission System (2) Registration No. 1708995, Application No. 59-052696: Signed Document Transmission System (3) US 4625076 Canada 255784 EP 0157258: Signed Document Transmission System NTT says it will license the patents nonexclusively and under appropriate conditions.

(Related patents)

• The entry says that no related patents will be lodged by other companies. Web address at which the technical specifications of the entry are available: http://info.isl.ntt.co.jp/

92 CRYPTREC 2000

1.2 Technical Specifications

【Key Generation】

Input: Security parameter k Output: Public key (n, e, HID, pLEN) and secret key (p, q)

(1) Two prime numbers, p and q, are generated, followed by the calculation of n = p2q. (2) Integer e > 4 is selected. (3) pLEN = k is determined.

The ID of the hash function used is HID.

【Signature Generation】

Input: Message m, public key (n, e, HID, pLEN), and secret key (p, q) Output: Signature s

(1) r is selected at random. (2) z = (0||H(m)||0), α = (z−re) mod n

 α  (3) w0 =   , w1 = w0·pq − α  pq 

w0 (4) t = mod p, s = (r + tpq) mod n e re−1 (5) s is outputted as a signature of m.

【Signature Verification】

Input: Signature s, message m, public key (n, e, HID, pLEN) Output: Verification results

(1) If se mod n = 0||H(m) is satisfied, "valid" is outputted. If not, "invalid" is outputted.

1.3 Other

This cryptographic scheme is described in ISO/IEC 14888-3 (Digital Signature Algorithms with Appendix) annex b.

This cryptographic scheme is described in IEEE P1363a/D4 (Draft Version 4), May 22, 2000.

93 CRYPTREC 2000

2. Evaluation Results

2.1 Evaluation of Security

(a) Security of primitives

Not much research is being conducted on this problem. At present, it is considered that if e ≥ 5, there will be no particular security problem. The signature system initially proposed as ESIGN adopted e = 2, and after a weakness was pointed out, the value of e was increased. It is not necessarily clear how large a security margin needs to be taken for use over a long time. For example, it is desirable to clarify how parameters should be set in order to attain the same degree of security as the 1,024-bit textbook RSA signature system. In this respect, sufficient scrutiny is required for some uses because conditions and examples of parameter settings mentioned at various parts of the proposer's specification vary as shown below.

• Conditions in the proposer's specification: e ≥ 5

Parameters recommended by the proposer: e ≥ 8, |p| = |q| ≥ 320, |n| ≥ 960

Parameters adopted by the proposer at the time of software implementation evaluation: e = 210, |p| = |q| = 384, |n| = 1,152

Conditions in the Draft Guidelines for Authorizing Special Certification Businesses under the Law of Electronic Signatures and Certification Businesses: e ≥ 8, |n| ≥ 1,024

Some committee members say that parameters should be set with some margin (e > 230, for example) in order to cope with extended attacks by B. Vallee and others.

The form of integer factoring of a composite number that is a modulus is different from that of the RSA signature system (textbook RSA signature system and RSA-PSS). Therefore, it is necessary to note that even if the modulus is of the same size as in the RSA signature system, the degree of security is not necessarily the same. (Refer to 4.3.1.) That is, it is not known whether the integer factoring of n = p2q is simpler than that of n = pq.

94 CRYPTREC 2000

(b) Security of the scheme

It is considered that there is no problem in the proposer's proof that in a random oracle model and subject to the conditions that the e-th root approximation assumption is correct, this scheme is existentially unforgeable against adaptive chosen message attacks. The probability of successful cryptanalysis is q_H times (the number of times of inquiring of the random oracle) the probability of successful cryptanalysis of the e-th root approximation problem. Some committee members say there is a slight difference.

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• In order to secure the strength equivalent to that of the RSA cryptosystem with a composite number length of 1,024 bits, the length of the composite number of ESIGN is: 384 bits × 3 = 1,152 bits. • The security parameter of ESIGN is 10 bits, or the tenth power of 2 (1,024). (2) Parameter setting method

• Random number seeds are read as a file.

(3) Verification of the parameters used

• Primarity tests are performed using the GNU MP 3.1.1 function mpz_probab_prime_p (mpz_t n, int reps). The primarity test algorithm used in this function is the Miller-Rabin method. The larger the value of the second argument, reps, the lower the probability of testing error. However, since correspondingly more time is required, a value between 5 and 10 is considered practically appropriate. In this implementation, the value of reps was set at 5.

[Techniques Used in the Implementation]

• The free multiple length arithmetic library GNU MP 3.1.1 was used. • The programming was done in C as described in the specification. Nothing special was done to increase speed or to save memory.

[Features and Measurement Parameters]

Object of Security Implementation Parameter Other Measurement Evidence and Property

95 CRYPTREC 2000

ESIGN Signature Integer factoring Composite number length: The security parameter of ESIGN is 10 bits, the problem 384 bits × 3 = 1,152 bits tenth power of 2 (1,024). The programming was done in C as described in the specification. Nothing special was done to increase speed or to save memory.

[System Parameter Generation]

• Since system parameter generation had been completed in advance, it was performed in this evaluation.

[Key Pair Generation]

• Primarity testing conditions: Primarity tests were performed using the GNU MP 3.1.1 function mpz_probab_prime_p (mpz_t n, int reps). • Random number generation method: Random state variables were initialized by the GNU MP 3.1.1 function gmp_randinit (gmp_randstate_t state, gmp_randalg_t alg, ...). The default algorithm of GNU MP (GMP_RAND_ALG_DEFAULT) was specified as the random number generation algorithm. Next, the function gmp_randseed (gmp_randstate_t state, mpz_t seed) was used to set the seeds read from an external file in the random state variables. Next, random numbers were generated using the function mpz_urandomb (mpz_t rop, gmp_randstate_t state, unsigned long int n).

[Key Pair Generation Speed]

Object of Average Execution Remarks Measurement Time ESIGN Signature 50.8 ms Prime number generation and random number generation are not included. The length of composite numbers is 384 bits × 3 = 1,152. 452.8 ms Measured value, including random number generation and prime number generation.

96 CRYPTREC 2000

[Signature Generation]

• Padding: Not necessary • Hash function: SHA-1 was used. • Measurement results:

[Signature Generation Speed]

Object of Average Execution Auxiliary Remarks Measurement Time Function ESIGN Signature 9.2 ms SHA-1 Size of data to be signed: 31 KB 49.1 ms Size of data to be signed: 178 KB

[Signature Verification]

(1) Verification confirmation routine

• Implemented

(2) Measurement results

[Signature Verification Speed]

Object of Average Execution Remarks Measurement Time ESIGN Signature 6.6 ms Size of data to be signed: 31 KB 44.3 ms Size of data to be signed: 178 KB

[Code Size]

Object of Evaluation Source Code Size Remarks ESIGN Signature 178,762 Bytes C language (Intel C/C++) Part of the multiple length arithmetic routine GMP is included.

97 CRYPTREC 2000

4.4.3 RSA-PSS

1. Cryptography

1.1 Technical Overview

RSA-PSS is a signature technology based on the integer factoring problem (IF). It is a combination of the RSA signature scheme proposed by Ronald L. Rivest, Adi Shamir, and Leonard M. Adleman in 1977 and the Probabilistic Signature Scheme (PSS) proposed by Mihir Bellare and Phillip Rogaway in 1996.

(2) Year of Announcement of PSS: 1996 M. Bellare and P. Rogaway. The Exact Security of Digital Signatures--How to Sign with RSA and Rabin. In Advances in Cryptology-Eurocrypt '96, pp. 399-416, Springer-Verlag, 1996.

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

California State College of the United States claims it has patents pending on the PSS signature scheme. In a letter sent to IEEE P1363, the college also says, "If the PSS is adopted as an IEEE standard, we will authorize the implementation and use of the signature scheme for free as a technology to realize attachment type signatures."

The written approval of RSA Security Inc. is required for the use of the PSS on commercial and non-commercial products. The "use" includes the use of a registered trademark in Japan. "RSA" is a registered trademark of RSA Security Inc. in Japan.

Web address at which the technical specifications of the entry are available: http://www.rsasecurity.com/rsalabs/rsa_algorithm/

1.2 Technical Specifications

【Key Generation】

Output: Public key (e, n), secret key d

98 CRYPTREC 2000

1. Prime numbers p and q are generated. 2. n = pq, λ (n) = LCM (p − 1, q − 1) are calculated.

3. e ∈ Zλ(n) (GCD (e, λ (n)) = 1) are set appropriately. 4. d = 1/e mod λ (n) is calculated. 5. The public key (e, n) and the secret key d are outputted.

It is assumed that the following three random functions are set in the system:

* k1 H1: {0, 1} → {0, 1} k1 k0 H2: {0, 1} → {0, 1} k1 k−k0−k1−1 H3: {0, 1} → {0, 1}

99 CRYPTREC 2000

【Signature Generation】

Input: Message m ∈ {0, 1}n and secret key d Output: Signature s

1. Random numbers r ∈ {0, 1}k0 are generated.

2. It is so set that w = H1(m||r).

3. It is so set that R = H2(w) ⊕ r.

4. It is so set that y = 0||w||R||H3(w). 5. s = yd mod n is outputted.

【Signature Verification】

Input: Signature s, message m, publish key (n, e) Output: 1 (successful verification), 0 (failed verification)

1. It is so set that y = se mod n. 2. y is divided into b||w||R||γ.

3. It is so set that r = R ⊕ H2(w).

4. It is verified whether H1(m||r) = w, H3(w) = γ, and b = 0 all hold. 5. If they hold, 1 is outputted. Otherwise, 0 is outputted.

1.3 Other

This scheme is described in IEEE P1363 [1], PKCS #1 V2.1 [2], ISO/IEC 9796-2, and others.

[1] IEEE P1363a: Standard Specifications for Public Key Cryptography: Additional Techniques. Draft D4, May 22, 2000. Available from http://grouper.ieee.org/groups/1363/.

[2] RSA Laboratories. PKCS #1 v2.1: RSA Cryptography Standard. Draft 1, September 17, 1999. Available from http://www.rsasecurity.com/rsalabs/pkcs/.

[3] ISO/IEC 9796-2. Information Technology - Security Techniques - Digital Signature Schemes Giving Message Recovery--Part 2: Mechanisms Using a Hash Function. Working draft, July 2000.

2. EvaluationResults

2.1 Evaluation of Security

Under the assumption of the onewayness of the RSA encryption function and a random oracle model, it has been proved that this scheme is potentially unforgeable against adaptive chosen message attacks. Since the security of RSA-PSS depends largely on the security of RSA itself and the difficulty of the

100 CRYPTREC 2000

integer factoring problem, it is necessary to continue to pay full attention to algorithms to solve these problems and to the performance of computers. Meanwhile, it should be noted that textbook RSA signatures do not have provable security.

2.2 Software Implementation Evaluation

RSA-PSS is a cryptosystem judged requiring other evaluation. The committee judged that it was not necessary to evaluate its software implementability, since it had already been implemented widely.

101 CRYPTREC 2000

4.4.4 DSA

1. Cryptography

1.1 Technical Overview

DSA is a signature scheme based on the assumption that the discrete logarithm problem is difficult.

National Institute of Standards and Technology (NIST). FIPS Publication 186-2: Digital Signature Standard

Intellectual property rights

(Proposers' patents and their handling)

DSA signature patent (U.S. Patent Number 5,231,668 (application date: July 26, 1991; effective date: July 27, 1993)

1.2 Technical Specifications

(1) The public key is generated.

p: Prime number p is generated so that 2L−1 < p < 2L, 512 ≤ L ≤ 1,024, where L is a multiple of 64. q: Prime factor of p − 1, 2159 < q < 2160 g = h(p−1)/q mod p, provided that 1 < h < p − 1, h(p−1)/q mod p > 1 (The order of g mod p is q.) x: Random number 0 < x < q is taken as the secret key. y = gx mod p: Used as the public key.

(2) Signature processing

k: Random number 0 < k < q is taken. k needs to be changed for each signature. r = (gk mod p) mod q s = (k−1 (SHA-1(m) + xr)) mod q (r, s) is the signature.

(3) Signature verification

w = (s)−1 mod q u1 = ((SHA - 1(m))w) mod q u2 = (rw) mod q

102 CRYPTREC 2000

v = ((gu1 yu2) mod p) mod q If v = r, the verification is successful.

2. Evaluation Results

2.1 Evaluation of Security

(a) The security of the scheme described in the processing section has not been proved. However, by replacing SHA-1(m) by SHA-1(m, r), it can be proved that this scheme is existentially unforgeable against adaptive chosen message attacks under the assumption that SHA-1 realizes a random oracle model and the discrete logarithm problem is difficult.

(b) Parameters need to be carefully selected in such a way that the discrete logarithm problem will not become weak against existing attacks (such as Shanks, Pohlig-Hellman, Adleman, Pomerance, and Gordon).

(c) Prime number p is reported to satisfy the conditions of 2L−1 < p < 2L, 512 ≤ L ≤ 1,024, where L is a multiple of 64. Security problems may occur with such a small size as 512 bits. It should be noted that since the size cannot be increased to over 1,024 bits, there are limits to the degree of security that can be attained.

(d) The effectiveness of the random number generation method described in FIPS186-2Appendix3 has recently been suspected and needs to be further studied.

(e) DSA has been widely used as a standard, and it is considered that there are no major threats to its security at present. However, the factors mentioned above should be taken into consideration in the future.

2.2 Software Implementation Evaluation

DSA is a cryptosystem judged requiring other evaluation. The committee judged that it was not necessary to evaluate its software implementability, since it had already been implemented widely.

103 CRYPTREC 2000

4.4.5 ECDSA in SEC1

1. Cryptography

1.1 Technical Overview

ECDSA in SEC1 is a public key cryptosystem devised by the SECG (Standards for Efficient Cryptography Group) in 1999. It is a signature system using elliptic curves. Reference site: http://www.secg.org/

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

• 4,745,568: Computational method and apparatus for finite field multiplication, issued May 17, 1988. This patent includes methods for efficient implementation of finite field arithmetic using a normal basis representation.

• 5,761,305: Key Agreement and Transport Protocol with Implicit Signatures, issued June 2, 1998. This patent includes versions of the MQV protocols.

• 5,787,028: Multiple Bit Multiplier, issued July 28, 1998.

• 5,889,865: Key Agreement and Transport Protocol with Implicit Signatures, issued March 30, 1999. This patent includes versions of the MQV protocols.

• 5,896,455: Key Agreement and Transport Protocol with Implicit Signatures, issued April 20, 1999. This patent includes versions of the MQV protocols.

The above proposers' patents and copyrights are licensed by the proposers without discrimination of licensees under reasonable conditions.

For details, visit the Web sites of the patentees and the SECG's Web site (www.secg.org). http://www.secg.org/patent_policy.htm http://www.secg.org/collateral/certicom_secg_patent.pdf

It should be checked whether the patentees have already submitted to the SECG documents agreeing to license the patented technologies to applicants under proper conditions without discriminatory treatment.

Web address at which the technical specifications of the entry are available: http://www.labs.fujitsu.com/theme/crypto/public_key.html http://www.secg.org/drafts.htm

104 CRYPTREC 2000

1.2 Technical Specifications

Signature generation and signature verification functions are outlined below.

Elliptic curve parameter (p, a, b, G, l ) This shows that there is a rational point G of prime order l on the elliptic curve y2 = x3 + ax + b

over the prime field Fp.

Elliptic curve parameter (k, f, a, b, G, l) This shows that there is a rational point G of prime order l on the elliptic curve y2 + xy = x3 + ax2 + k b over the k-th degree extension field F2 of characteristic two defined by the irreducible polynomial f.

Public key Elliptic curve parameter (p, a, b, G, l) or (k, f, a, b, G, l), and a point U that is a multiple of the point G

Secret key Integer d satisfying U = d · G

【Signature Generation】

Input: Plaintext m

Output: Signed text (s1, s2)

1. r ← a random number not less than 1 and not greater than l-1, R ← r · G

2. s1 ← x(R) mod l 3. e ← Hash(m) −1 4. s2 ← r (e + s1d) mod l

【Signature Verification】

Input: Plaintext m, signed text (s1, s2) Output: "valid" or "invalid"

1. Verify that s1 and s2 are both not less than 1 and not greater than l-1. 2. e ← Hash(m) −1 −1 3. u1 ← e s2 , u2 ← s1 s2

4. R ← u1 G + u2 U, v ← x(R)

5. If v = s1, output "valid". If not, output "invalid".

105 CRYPTREC 2000

In the above, x(P) denotes the x coordinate of a point P on an elliptic curve.

1.3 Other

ECDSA in SEC1 is described in IEEE P1363 and American National Standard X9.62.

2. Evaluation Results

2.1 Evaluation of Security

2.1.1 Security of cryptographic primitives

The basic security of ECDSA in SEC1 is based on the difficulty of the discrete logarithm problem on elliptic curves.

Various attacks are known against the discrete logarithm problem on elliptic curves. In the case of ECDSA in SEC1, elliptic curve parameters in various sizes, to which no known attack can be applied, are explicitly given in SEC2 documents. (These are recommended parameters, not prohibited to use other parameters.) These elliptic curves consist of elliptic curves randomly selected in a verifiable manner and elliptic curves called Koblitz curves. Koblitz curves are included because of their high performance and their traditional use. However, since they are within a very limited class, it should be noted that a new attack against them could appear.

2.2 Security of the Scheme

It is desirable that a signature scheme is proved to be existentially unforgeable against adaptive chosen message attacks by active attackers under reasonable assumptions. ECDSA in SEC1 has not been given any such proof under ordinary assumptions. However, a paper argues that the existential unforgeability of ECDSA in SEC1 can be proved under the assumption that the attackers do not use the group structure at all. In this evaluation, no conclusion has been reached on the propriety of this argument or actual effects of the proof method.

ECDSA in SEC1 has been widely used and is described in American National Standard X9.62. It is considered that there is no particular security problem about ECDSA in SEC1 as a signature scheme.

Note: For the purpose of preventing ECDSA in SEC1 from having the DSKS (Duplicate-Signature Key Selection) property (the property in which a pair of plaintext and signed text becomes a valid pair of plaintext and signed text against another pair of public key and secret key), it is desirable to fix the elliptic curve parameters among all users.

106 CRYPTREC 2000

2.3 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• The following two types of curves were used: secp160r1: Elliptic curve parameter in a 160-bit prime field sect163r2: Elliptic curve parameter in a 163-bit field of characteristic 2 • Both are among the parameters recommended in the SEC1 specifications. They are based on the ANSI X9.62 specifications.

(2) Parameter setting method

• Elliptic curve parameters are read from a file for use. • The software is implemented in a way not dependent on parameters.

(3) Verification of the parameters used

• Since the two coefficients of an elliptic curve are related by (uncontrollable) SHA-1 outputs, it is randomly verifiable that the parameters have been selected freely. • As in the X9.62 specifications, SHA-1 inputs are also described as part of the parameters. • It has been verified that special attacks are ineffective.

(4) Parameter size variations

• Not only fixed parameters but also arbitrary elliptic curve parameters can be used. • Bit lengths that can be handled in parameters of elliptic curves in a prime field are as follows: 112, 128, 160, 192, 224, 256, 384, 521 • Bit lengths that can be handled in parameters of elliptic curves in a field of characteristic two are as follows: 113, 131, 163, 193, 233, 239, 283, 409, 571

[Techniques Used in the Implementation]

• No high-speed techniques limited to special parameters such as a = 0 and a = −3 are used in the library. • High-speed techniques applicable to any parameters are used. • The software is implemented in a way not dependent on parameters.

[Characteristics and Measurement Parameters]

107 CRYPTREC 2000

Security Implementation Scheme Measured Other Evidence Parameter and Character ECDSA in SEC1 ECDLP Equivalent to • Since the two coefficients of an elliptic curve are 160-bit prime field RSA 1,024 bits related by (uncontrollable) SHA-1 outputs, it is randomly verifiable that the parameters have been ECDSA in SEC1 selected freely. 163-bit field of • As in the X9.62 specifications, SHA-1 inputs are characteristic 2 also described as part of the parameters. • It has been verified that special attacks are ineffective.

[System Parameter Generation]

• Since the generation of elliptic curve parameters is based on a probabilistic algorithm, it is difficult to determine a precise anticipated processing time.

Measurement results

Average Execution Scheme Measured Remarks Time ECDSA in SEC1 Three elliptic curve parameters were generated in 18 minutes. 6.0 min 160-bit prime field

[Initialization/Termination]

Measurement results

Scheme Measured Average Execution Time Remarks ECDSA in SEC1 PC/PF 0.004 ms None 160-bit prime field PI 13.525 ms None PV 60.438 ms None WC/WF 0.032 ms None ECDSA in SEC1 PC/PF 0.004 ms None 163-bit field of characteristic 2 PI 15.283 ms None PV 43.917 ms None WC/WF 0.032 ms None

PC/PF: An elliptic curve parameter area is acquired/released.

PI: The parameters read from a file are set in the area.

PV: Parameter verification, which is required only at the first time the parameters are given. Validity is checked: Whether the source of generation is a point on a curve, whether the point multiplied by the order becomes a point at infinity, etc.

WC/WF: The work area is acquired/released.

[Key Pair Generation]

108 CRYPTREC 2000

(1) Primarity test conditions

• No test is necessary for system reasons.

(2) Random number generation method

• Fujitsu's original pseudo-random number generation algorithm. DES/SHA-1, etc. are used.

109 CRYPTREC 2000

(3) Measurement results

[Key pair generation speed]

Average Execution Scheme Measured Remarks Time ECDSA in SEC1 1.9 ms Key pair generation. 160-bit prime field Key pair verification, which is not necessary if the keys are 5.8 ms generated by the user. ECDSA in SEC1 3.2 ms Key pair generation. 163-bit field of characteristic 2 Key pair verification, which is not necessary if the keys are 8.0 ms generated by the user.

• Key pair verification is not necessary if the keys are generated by the user.

[Signature Verification]

(1) Padding

• Not used.

(2) Hash function

• SHA-1 is used.

(3) Measurement results

[Signature generation speed]

Average Execution Auxiliary Scheme Measured Remarks Time Function ECDSA in SEC1 3.7 ms SHA-1 Size of data to be signed: 31 KB 160-bit prime field 11.1 ms Size of data to be signed: 178 KB ECDSA in SEC1 5.0 ms Size of data to be signed: 31 KB 163-bit field of characteristic 2 13.1 ms Size of data to be signed: 178 KB

[Signature Verification]

(1) Verification confirmation routine

• If verification fails, an error message is outputted.

110 CRYPTREC 2000

(2) Measurement results

[Signature verification speed]

Average Execution Scheme Measured Remarks Time ECDSA in SEC1 9.7 ms Size of data to be signed: 31 KB 160-bit prime field 17.2 ms Size of data to be signed: 178 KB ECDSA in SEC1 13.6 ms Size of data to be signed: 31 KB 163-bit field of characteristic 2 21.4 ms Size of data to be signed: 178 KB

[Code Size]

Scheme Measured Code Size Remarks ECDSA in SEC1 356,352 byte Executable test program for performance measurement

111 CRYPTREC 2000

4.4.6 MY-ELLTY ECMR-160/192/OEF-h

1. Cryptography

1.1 Technical Overview

MY-ELLTY ECMR-160/192/OEF-h is a cryptosystem proposed by Atsuko Miyaji (at that time) of Matsushita Electric Industrial Co., Ltd. at SCIS '96 held in 1996. It is a signature scheme whose security is based on ECDLP.

MY-ELLTY ECMR-160/192/OEF-h was entered as three different items. However, they are considered the same as a signature scheme, only using different fields and are therefore evaluated as a single entry. Intellectual property rights on this cryptosystem, such as patents and copyrights acquired or pending, are described below.

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

[1] Patent Publication H06-110386 (Patent Application H04-257800), "Signature, Verification, and Secret Communication Systems Using Elliptic Curves," taking a basic point of a small absolute value.

[2] Patent Publication H06-295154 (Patent Application H05-082978), "Signature, Verification, and Secret Communication Systems Using Elliptic Curves," using an elliptic curve defined in GF(p) where p = 2n − α is a prime number.

[3] Patent Publication H09-034357 (Patent Application H07-178483), "Signature System," message recovery signatures using elliptic curves by the proposed method.

[4] Patent Publication H09-160492 (Patent Application H07-324908), "Signature System," message recovery signatures using elliptic curves by the proposed method.

[5] Patent Publication H11-316542 (Patent Application H11-056592), "Elliptic Curve Transformation Device," an elliptic curve of a = −3.

[6] Patent Publication H11-102158 (Patent Application H10-200725), "Elliptic Curve Arithmetic Device," Elliptic Curve Arithmetic Device," Method for Scalar Multiplication of Points on Elliptic Curves"

(Related patents)

No patents or copyrights of other companies directly related to this entry are identified.

112 CRYPTREC 2000

Web address at which the technical specifications of the entry are available: http://www.panasonic.co.jp/mdc/crypt/

1.2 Technical Specifications

The technical specifications of MY-ELLTY ECMR-160-h are described here. The description of those of MY-ELLTY ECMR-192/OEF-h is omitted because they are considered the same as MY-ELLTY ECMR-160-h, only using different fields.

Message recovery signature generation scheme

1. Message m of an arbitrary length over 79 bits is divided into mre of the first 80 bits and mnr of the subsequent bits. 2. The signer's secret key x is selected. 3. Hash value h of 80 bits is obtained by entering m into the hash function.

4. Value d of 80 bits is obtained by combining mre and h. (d = mre||h) 5. The signature (r, s) corresponding to message d is calculated in response to a signature generation primitive.

6. Signed text r||s||mnr is outputted by combining the calculated signature (r, s) and part (mnr) of the message.

Signature generation primitive:

1. Random number k satisfying the condition 0 < k < q is generated.

2. The point (affine coordinates) (x1, y1) = kG on an elliptic curve is calculated.

3. r = d ⊕ x1 is calculated. 4. r' = r (mod q) is calculated. If r' = 0, the generation of random number k is performed again. 5. s = (r' k−r' −1)/(x + 1) (mod q) is calculated. If s = 0, the generation of random number k is performed again. 6. As a signature, (r, s) is outputted.

Message recovery signature verification scheme

1. The signer's public key y corresponding to the signer's secret key is obtained.

2. The signed text is divided into the signature (r, s) of 320 bits and mnr of the subsequent bits. 3. Message d is recovered by entering (r, s) and public key y into the signature verification primitive. Alternatively, "failed verification" is acquired. In the case of "failed verification," a message to that effect is outputted, terminating the operation.

4. The first 80 bits of d is represented by mre, and the subsequent bits by h.

113 CRYPTREC 2000

5. mre and mnr are combined into m. (m = mre||mnr) 6. Hash value h' of 80 bits is obtained by entering m into the hash function. 7. If h and h' do not agree with each other, a message to the effect that the verification failed is outputted. If they agree with each other, m is outputted as a recovered message.

Signature verification primitive:

1. r' = r (mod q) is calculated. 2. The conditions r' ≠ 0 and 0 < s < q are checked. If these conditions are not satisfied, "failed verification" is outputted.

3. The point (affine coordinates) (x2, y2) = ((1 + r' + s)/r')G + (s/r')Y on an elliptic curve is calculated.

4. d = r ⊕ x2 is calculated. 5. As a recovered message, d is outputted.

Recommended parameters:

For each of the schemes (160/192/OEF), only one recommended parameter is written.

♦ Elliptic parameter in a prime field of 160 bits

p = 2160 − 33689 = 1461 50163 73309 02918 20368 48327 16283 01965 59325 09287

= [ fffffff fffffff fffffff fffffff ffff7c67 ]16

Elliptic curve E(GF(p)): y2 = x3 + ax + b

a = −3

= [ fffffff fffffff fffffff fffffff ffff7c64 ]16 b = 221 26390 04360 85830 53354 00546 97282 39214 54692 45783

= [ 26c1d102 82415e10 a4995e19 80b59224 d7120957 ]16

Base point G = (gx, gy), order q

gx = 1

gy = 199 11984 96906 58063 76419 67878 55655 25945 56232 98470

= [ 22e0d7c6 1eb0627b 334456c7 a50b77fd a9007da6 ]16 q = 2160 − 2678 34839 33601 50259 78183 = 1461 50163 73309 02918 20368 45648 81443 68364 09065 64793

= [ fffffff fffffff ffffc748 a4eea1b0 dc8744b9 ]16

114 CRYPTREC 2000

♦ Elliptic parameter in a prime field of 192 bits

p = 2192 − 34757 = 627 71017 35386 68076 38357 89423 20766 64161 02355 44446 40344 78139

= [ fffffff fffffff fffffff fffffff fffffff ffff783b ]16

Elliptic curve E(GF(p)): y2 = x3 + ax + b

a = −3

= [ fffffff fffffff fffffff fffffff fffffff ffff7838 ]16 b = 570 48185 89025 54558 85102 23460 41752 70002 25150 94686 47895 98136

= [ e8a915cd 5ea5560c dca0ee33 8c0b6377 7101fc2b 25a22fb8 ]16

Base point G = (gx, gy), order q

gx = 2

gy = 121 87592 69632 40567 43864 47414 41820 27280 76148 35976 18105 14187

= [ 31b470c4 16b0d2cc 78fbd092 c0e2c5ea b94a91ce f85d610b ]16 q = 2192 − 1005 28889 60154 04021 58223 05019 = 627 71017 35386 68076 38357 89423 19761 35271 42201 40424 82122 07877

= [ fffffff fffffff fffffff df8471f5 7b763287 b0c97905 ]16

♦ Elliptic parameter in a extension field of 32 bits x 5th order

32 p = 2 − 185 = 42949 67111 = [ ffffff47 ]16 f(ξ) = ξ5 - 2

Elliptic curve E(GF(p5)): y2 = x3 + ax + b

a = −3 = (0, 0, 0, 0, −3) = (0, 0, 0, 0, [ ffffff44 ]16) b = 969768922 × α4 + 4095377333 × α3 + 1216762277 × α2 + 3814912639 × α + 3024742656 = (969768922, 4095377333, 1216762277, 3814912639, 3024742656)

= ([39cd7fda]16, [f41a7fb5]16, [488651a5]16, [e362f27f]16, [b449e900]16)

Base point G = (gx, gy), order q

gx = (0, 0, 0, 0, 2)

gy = (2319840967, 2197013598, 3799084265, 643252031, 3306181529)

= ([8a45f6c7]16, [82f3c45e]16, [e2716ce9]16, [26573f3f]16, [c5105399]16) q = 1461 50132 25697 40632 17306 09208 36062 44677 38509 59223

115 CRYPTREC 2000

= [ fffffc63 000538e9 fc3bbe32 da01dc69 c2516d77 ]16

116 CRYPTREC 2000

2. Evaluation Results

2.1 Evaluation of Security

MY-ELLTY ECMR-160/192/OEF-h was entered as three different items. However, since the three were considered one and the same as a signature scheme, only using different fields, the Committee evaluated the security of the three as a single entry.

(a) It is considered that there is a security problem with this scheme because it is possible to existentially forge signatures in chosen message attacks. Since the output of the hash function used is as short as 80 bits (160/OEF) or 96 bits (192), a collision of hash values is expected, and hence the existential forgery of signatures, at the computational complexity of the order of 240(ECMR - 160/OEF) or 248(ECMR - 192) in birthday attacks.

(b) If the bit length of hash values is increased for the sake of security, the message length recovered becomes shorter accordingly, meaning the loss of the advantage (a short signature text length) the entry intends to emphasize.

(c) Although the proposer presents the proof that in a random oracle model, security against no message attacks results in the ECDLP, the proof is wrong. For correct proof, it is necessary to modify the scheme in such way as to enter not only message m but also kG into the hash function. For the proposed scheme, therefore, the security mentioned above is not proved.

(d) The description of the method of selecting the elliptic curve parameters used is inadequate. The grounds on which the curve was selected are not clear enough.

(e) On the following two points, specifications are unclear: − Which 80/96 bits of SHA-1 are used as a hash value? − When a message length is less than 80/96 bits, how is it extended to 80/96 bits? However, it should be noted that even if these points are not clarified, it does not affect the evaluation of security described above.

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• RSA cryptosystem of N = 1,024 bits (strength equal to or greater than signatures)

117 CRYPTREC 2000

(2) Parameter setting method

• Parameters are generated in advance and are fixed. They are buried into binary codes. • The software is implemented on the premise that the elliptic parameters are fixed. Therefore, the scheme has no codes for generating or reading system parameters.

(3) Verification of the parameters used

• The elliptic parameters used are generated pseudo-randomly. Security has been verified (criteria cleared) against MOV, FR reduction attacks, and SSSA attacks.

(4) Parameter size variations

• Three parameter sizes were measured: 160 bits, OEF extension version of the 5th order of 32 bits, and 192 bits. The security of the 160 bits and the OEF extension version of the 5th order of 32 bits is equivalent to RSA 1,024 bits. The security of 192 bits is equivalent to RSA 1,536 bits.

(5) Other

• Random numbers are required at the time of generating key pairs and signatures. • Highly secure pseudo-random number routines should be used when this scheme is applied to actual systems.

[Techniques Used in the Implementation]

• Preliminary calculations are performed in advance and are incorporated into binary codes. • A table reference method speeds up elliptic arithmetic. No setup operations such as table initialization are required.

[System Parameter Generation]

• Since system parameters were generated in advance, this was not measured this time.

[Characteristics and Measurement Parameters]

Implementation Parameter Scheme Measured Security Evidence Other and Character MY-ELLTY ECMR-192-h ECDLP 192 Equivalent to RSA 1,536 • Security against MOV, FR bits reduction attacks, and SSSA MY-ELLTY ECMR-OEF-h OEF Equivalent to RSA 1,024 attacks has been verified (criteria bits cleared). • Parameters are fixed and are Equivalent to RSA 1,024 incorporated into binary codes.

118 CRYPTREC 2000

MY-ELLTY ECMR-160-h 160 bits incorporated into binary codes. • Preliminary calculation results are incorporated into binary codes. • Table reference.

[Key Pair Generation]

(1) Criteria

• Inside a function, a random number of the bit size equal to the bit size of the order of a base point is generated. Against this random number, a modulo is taken using the order of the base point as modulus and is used as a secret key. • A public key is generated by the scalar multiplication of the base point using the secret key.

(2) Random Number Generation Method

• A rand function in C language is used. • There is a comment that a more secure means of generating random numbers is necessary for actual use.

(3) Measurement Results

[Key Pair Generation Speed]

Scheme Measured Average Execution Speed Remarks MY-ELLTY ECMR-192-h 0.8 ms Random number generation is included. The random number generator needs to be replaced at the time of actual use. This naturally changes the time. MY-ELLTY ECMR-OEF-h 0.7 ms MY-ELLTY ECMR-160-h 0.7 ms

119 CRYPTREC 2000

[Signature Generation]

(1) Padding

• Output of SHA-1 (80 bits) is used.

(2) Hash function

• SHA-1 is used. • The hash size is 80 bits. • The hashing result is not outputted in an intermediate processing file.

(3) Measurement Results

[Signature Generation Speed]

Average Auxiliary Scheme Measured Remarks Execution Time Function MY-ELLTY 2.0 ms SHA-1 Size of data to be signed: 31 KB Random number ECMR-192-h generation is included. 9.2 ms Size of data to be signed: 178 SHA-1 is used as KB auxiliary function. SHA-1 MY-ELLTY 1.9 ms Size of data to be signed: 31 KB processing time increases ECMR-OEF-h in proportion to file 9.6 ms Size of data to be signed: 178 KB length. MY-ELLTY 1.9 ms Size of data to be signed: 31 KB ECMR-160-h 9.7 ms Size of data to be signed: 178 KB

[Signature Verification]

(1) Verification confirmation routine

• Although a verification result judging mechanism is incorporated, there is no means of confirmation (such as file output).

(2) Measurement results

[Signature verification speed]

Average Execution Scheme Measured Remarks Time MY-ELLTY ECMR-192-h 5.4 ms Size of data to be signed: 31 KB Although the correctness of verification is to be 12.8 ms Size of data to be signed: 178 KB checked, the result was MY-ELLTY ECMR-OEF-h 4.4 ms Size of data to be signed: 31 KB not outputted in this 11.9 ms Size of data to be signed: 178 KB implementation. 4.3 ms Size of data to be signed: 31 KB

120 CRYPTREC 2000

MY-ELLTY ECMR-160-ｈ 4.3 ms Size of data to be signed: 31 KB MY-ELLTY ECMR-160-ｈ 11.9 ms Size of data to be signed: 178 KB [Code Size]

Scheme Evaluated Object Size (Reported) Remarks MY-ELLTY ECMR-160-h 226,306 Bytes MY-ELLTY ECMR-192-h 230,626 Bytes MY-ELLTY ECMR-OEF-h 256,640 Bytes

121 CRYPTREC 2000

References

[1] A. Miyaji, "Enhanced message recovery signature," (Japanese) SCIENCES '96, 2C, (1996)

[2] A. Miyaji, "Another countermeasure to forgeries over message recovery signature," Trans. IEICE, Fundamentals. Vol. E80-A, No. 11 (1997)

122 CRYPTREC 2000

4.4.7 EPOC-1

1. Cryptography

1.1 Technical Overview

EPOC-1 is a public key cryptosystem for confidentiality purposes proposed by Tatsuaki Okamoto, Seiken Uchiyama, and Eiichiro Fujisaki (NTT). Based on the integer factoring problem (IF), EPOC-1 uses the OU (Okamoto-Uchiyama) cryptographic function (basic cryptographic primitive) transformed by the F0-1 method.

(1) Year of announcement of EPOC basic cryptographic system: 1998 Okamoto, T. and Uchiyama, S.: A New Public-Key Cryptosystem as Secure as Factoring, Proc. of Eurocrypt '98, LNCS 1403, Springer-Verlag, pp. 308-318 (1998).

(2) Year of announcement of the transformation system: 1999 Fujisaki, E. and Okamoto, T.: How to Enhance the Security of Public-Key Encryption at Minimum Cost, Proc. of PKC '99, Springer-Verlag, LNCS 1560, pp. 53-68 (1999).

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

Application number (publication number) 10-320172 Title of the invention: Encryption and Decryption Devices for Public Key Cryptosystems Using Random Functions

Application number (publication number) 2000-32461 Title of the invention: Storage Medium Storing Encryption Device and Method, Decryption Device and Method, and Cryptographic System and Programs

Application number (publication number) EP 98123917.1 (EP 924895) (Canada 2256179) Title of the invention: Encryption and Decryption Device for Public-Key Cryptosystems and Recording Medium with Their Processing Programs Recorded Thereon

• The patents will be licensed to others under exclusive, appropriate conditions. • No related patents are being sought by other companies.

Web address at which the technical specifications of the entry are available: http://info.isl.ntt.co.jp/

123 CRYPTREC 2000

1.2 Technical Specifications

【Key Generation】

Input: Security parameter k, a positive integer Output: Public key (n, g, h, HID, pLen, mLen, hLen, rLen)

Secret key (p, gp)

1. Two prime numbers, p and q (2k−1 ≤ p, q ≤ 2k − 1), are selected, followed by the calculation of n = p2q. * p−1 2 2. g ∈ Zn is selected at random. At this time, the order of gp = g mod p is made p. * n 3. h0 ∈ Z n is selected at random and independently of g, followed by the calculation of h = h0 mod n. 4. Let pLen = k. mLen and rLen are set in such a way that they meet the condition mLen + rLen ≤ pLen − 1. 5. Hash function H: {0, 1}mLen + rLen → {0, 1}hLen is determined, and it is given identification number HID.

124 CRYPTREC 2000

【Encryption】

Input: Plaintext m ∈ {0, 1}rLen, public key (n, g, h, HID, pLen, mLen, hLen, rLen) Output: Ciphertext c

1. R ∈ {0, 1}rLen is selected uniformly at random, and r = H(m||R) is calculated. 2. C = g(m||R) hr is calculated to produce ciphertext.

【Decryption】

Input: Ciphertext c Public key (n, g, h, HID, pLen, mLen, hLen, rLen)

Secret key (p, gp) Output: Plaintext m ∈ {0, 1}mLen or no output Let L(x) := (x − 1)/p.

p − 1 2 1. Cp = C mod p is calculated.

2. X = L(Cp)/L(gp) mod p is calculated. 3. It is verified whether the following two equations hold: X ≤ 2mLen + rLen −1, C = gXhH(X) mod n. 4. If they hold, the first mLen bits of X are outputted as plaintext. If they do not hold, there is no output.

(1) Parameter values recommended in the Cryptographic Techniques Specifications of the entry

• k: 320 bits or over (n: 960 bits or over) • hLen: 128 bits or over

(2) Typical parameters in "Performance Evaluation" in the Cryptographic Techniques Specifications of the entry

Case 1 (Under the assumption of strong security) Size of n: 1,152 bits, mLen = 128, rLen = 80, hLen = 208 Case 2 (Under the assumption of weak security) Size of n: 1,152 bits, mLen = 128, rLen = 80, hLen = 832

1.3 Other

This cryptographic scheme is described in IEEE P1363a/D4 (Draft Version 4), May 22, 2000.

125 CRYPTREC 2000

2. Evaluation Results

2.1 Evaluation of Security

Under the assumptions of the difficulty of the p subgroup problem and the presence of random functions, times cryptosystem has provable security of being semantically secure against adaptive chosen ciphertext attacks. Appropriate parameters must be selected carefully in order to satisfy these assumptions. It is necessary to note that even if the size is the same as in the RSA system, the degree of security is not necessarily the same partly because the form of the integer factoring of a composite number that is a modulus is different from that of the RSA system. A committee member points out that the order of h must be large in order to prove sufficient security. However, since no conclusion has been reached on the propriety of these arguments in this evaluation, parameter selection needs to be studied further.

126 CRYPTREC 2000

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• In order to secure the strength equivalent to that of the RSA cryptosystem with a composite number length of 1,024 bits, the length of the composite number of EPOC-1 is: 384 bits × 3 = 1,152 bits. • The data size of EPOC-1 is 128 bits.

(2) Parameter setting method

• Random number seeds are read as a file.

(3) Verification of the parameters used

(4) Parameter size variations

• Distribution of the key (256 bits at most) in symmetric cryptography • Secure transmission of short data (256 bits at most)

[Techniques Used in the Implementation]

[Features and Measurement Parameters]

Object of Security Implementation Parameter Other Measurement Evidence and Property EPOC-1 Integer factoring Composite number length in The data size in EPOC-1 for evaluation is 128 bits. problem EPOC-1: The Miller-Rabin method is used for primarity test. 384 bits × 3 = 1,152 bits

[System Parameter Generation]

127 CRYPTREC 2000

• Since system parameter generation had been completed in advance, it was not performed in this evaluation.

[Key Pair Generation]

(1) Primarity testing conditions

• Primarity tests were performed using the GNU MP 3.1.1 function mpz_probab_prime_p (mpz_t n, int reps).

(2) Random number generation method

• First, random state variables were initialized by the GNU MP 3.1.1 function gmp_randinit (gmp_randstate_t state, gmp_randalg_t alg, ...). The default algorithm of GNU MP (GMP_RAND_ALG_DEFAULT) was specified as the random number generation algorithm. Next, the function gmp_randseed (gmp_randstate_t state, mpz_t seed) was used to set the seeds read from an external file in the random state variables. Next, random numbers were generated using the function mpz_urandomb (mpz_t rop, gmp_randstate_t state, unsigned long int n).

(3) Measurement results

[Key pair generation speed]

Object of Measurement Average Execution Speed Other EPOC-1 73.9 ms Not including random number generation. 417.6 ms Measured value, including random number generation and prime number generation.

[Encryption]

(1) Padding

• Not necessary because hashes are generated by the method described in the specification.

(2) Hash function

• SHA-1 was used as hash function.

(3) Measurement results

[Encryption speed]

128 CRYPTREC 2000

Object of Measurement Average Execution Speed Other EPOC-1 13.9 ms None

[Decryption]

(1) Measurement results

[Decryption speed]

Object of Measurement Average Execution Speed Other EPOC-1 21.9 ms None

[Code size (reference value)]

Object of Measurement Code Size Other EPOC-1 177,058 byte C language (Intel C/C++) source code size

129 CRYPTREC 2000

4.4.8 EPOC-2

1. Cryptography

1.1 Technical Overview

EPOC-2 is a public key cryptosystem for confidentiality purposes proposed by Tatsuaki Okamoto, Seiken Uchiyama, and Eiichiro Fujisaki (NTT). Based on the integer factoring problem (IF), EPOC-2 uses the OU (Okamoto-Uchiyama) cryptographic function (basic cryptographic primitive) transformed by the F0-2 method.

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

Refer to EPOC-1.

Web address at which the technical specifications of the entry are available: http://info.isl.ntt.co.jp/

1.2 Technical Specifications

【Key Generation】

Input: Security parameter k, a positive integer Output: Pair of the public key (n, g, h, H1ID, H2ID, SEID, pLen, hLen, gLen, rLen) ∈ Z10 and the

secret key (p, gp)

1. Two prime numbers, p and q (2k−1 ≤ p, q ≤ 2k − 1), are selected, followed by the calculation of n = p2q. * p−1 2 2. g ∈ Zn is selected at random. At this time, the order of gp = g mod p is made p. * n 3. h0 ∈ Zn is selected at random and independently of g, followed by the calculation of h = h0 mod n. 4. Let pLen = k. mLen and rLen are set in such a way that they meet the condition rLen ≤ pLen − 1.

130 CRYPTREC 2000

mLen + rLen hLen rLen gLen 5. Two hash functions, H1: {0, 1} → {0, 1} and H2: {0, 1} → {0, 1} , are determined, and they are given identification numbers H1ID and H2ID, respectively. 6. Symmetric cryptosystem SymE is determined and is given identification number SEID. Here, SymE = (SymEnc, SymDec) is a pair of symmetric encryption and decryption algorithms having a common key of gLnen bits. In response to the input of key K and plaintext m, the encryption algorithm SymEnc outputs ciphertext SymEnc (K, m). In response to the input of key K and ciphertext c, the decryption algorithm SymDec outputs plaintext SymDec (K, c).

【Encryption】

Input: Plaintext m ∈ {0, 1}mLen Public key (n, g, h, H1ID, H2ID, SEID, pLen, hLen, gLen, rLen)

Output: Ciphertext c = (C1, C2)

rLen 1. R ∈ {0, 1} is selected uniformly at random, and H2(R) and r = H1(m||R) are calculated. R r 2. C1 = g h is calculated.

3. C2 = SymEnc (H2(R), m) is calculated.

4. C = (C1, C2) is outputted as ciphertext.

【Decryption】

Input: Ciphertext c = (C1, C2) Public key (n, g, h, H1ID, H2ID, SEID, pLen, hLen, gLen, rLen)

Secret key (p, gp) Output: Plaintext m ∈ {0, 1}mLen or no output Let L(x) := (x − 1)/p.

p−1 2 1. Cp = C1 mod p is calculated.

2. R' = L(Cp)/L(gp) mod p is calculated. 3. It is verified whether the following equation holds: R' ≤ 2rLen −1

If the equation holds, m' = SymDec (H2(R), C2) is calculated. If it does not hold, there is no output as decryption result.

4. r' = H1(m'||R') is calculated. R' r' 5. It is verified whether C1 = g h mod n holds. If it holds, m' is outputted as plaintext. If it does not hold, there is no output.

131 CRYPTREC 2000

(1) Parameter values recommended in the Cryptographic Techniques Specifications of the entry

• k: 320 bits or over (n: 960 bits or over) • hLen: 128 bits or over

(2) Typical parameters in "Performance Evaluation" in the Cryptographic Techniques Specifications of the entry (Vernum cipher used)

Case 1 (Under the assumption of strong security) Size of n: 1,152 bits, rLen = 128, gLen = 128, hLen = 128 Case 2 (Under the assumption of weak security) Size of n: 1,152 bits, rLen = 128, gLen = 128, hLen = 832

1.3 Other

Refer to EPOC-1.

2. Evaluation Results

2.1 Evaluation of Security

Under the assumptions of the difficulty of the integer factoring problem of the n = p2q type and the presence of random functions, times cryptosystem has provable security of being semantically secure against adaptive chosen ciphertext attacks. Appropriate parameters must be selected carefully in order to satisfy these assumptions. It is necessary to note that even if the size is the same as in the RSA system, the degree of security is not necessarily the same partly because the form of the integer factoring of a composite number that is a modulus is different from that of the RSA system. A committee member points out that rLen must be sufficiently close to k − 1 and the order of h must be large in order to prove sufficient security with the parameters recommended by the proposer, k = 384 bits and rLen = 128 bits. However, since no conclusion has been reached on the propriety of these arguments in this evaluation, parameter selection needs to be studied further.

132 CRYPTREC 2000

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• In order to secure the strength equivalent to that of the RSA cryptosystem with a composite number length of 1,024 bits, the length of the composite number of EPOC-2 is: 384 bits × 3 = 1,152 bits. • The data size of EPOC-2 is 128 bits.

(2) Parameter setting method

• Random number seeds are read as a file.

(3) Verification of the parameters used

(4) Parameter size variations

• Distribution of the key of arbitrary length in symmetric cryptography • Secure transmission of long plaintext by the joint use with a proper symmetric cryptosystem, especially a capsule-like method of use (that is, the form of use in which key distribution and data distribution are synchronized)

[Features and Measurement Parameters]

Object of Security Implementation Parameter Other Measurement Evidence and Property EPOC-2 Integer factoring Composite number length in The data size in EPOC-2 for evaluation is 128 bits. problem EPOC-2: The Miller-Rabin method is used for primarity test. 384 bits × 3 = 1,152 bits

[Techniques Used in the Implementation]

• The free multiple length arithmetic library GNU MP 3.1.1 was used.

133 CRYPTREC 2000

• The programming was done in C as described in the specification. Nothing special was done to increase speed or to save memory.

[System Parameter Generation]

• Since system parameter generation had been completed in advance, it was not performed in this evaluation.

[Key Pair Generation]

(1) Primarity testing conditions

• Primarity tests were performed using the GNU MP 3.1.1 function mpz_probab_prime_p (mpz_t n, int reps).

(2) Random number generation method

(3) Measurement results

[Key pair generation speed]

Object of Measurement Average Execution Speed Other EPOC-2 73.9 ms Not including random number generation. 577.0 ms Measured value, including random number generation and prime number generation.

[Encryption]

(1) Padding

• Not necessary because hashes are generated by the method described in the specification.

(2) Hash function

• SHA-1 was used as hash function.

134 CRYPTREC 2000

(3) Measurement results

[Encryption speed]

Object of Measurement Average Execution Speed Other EPOC-2 10.9 ms None

[Decryption]

(1) Measurement results

[Decryption speed]

Object of Measurement Average Execution Speed Other EPOC-2 18.9 ms None

[Code size (reference value)]

Object of Measurement Code Size Other EPOC-2 187,662 byte C language (Intel C/C++) source code size

135 CRYPTREC 2000

4.4.9 EPOC-3

1. Cryptography

1.1 Technical Overview

EPOC-3 is a public key cryptosystem for confidentiality purposes proposed by Tatsuaki Okamoto, Seiken Uchiyama (NTT), and Pointcheval, D. (ENS). Based on the integer factoring problem (IF), EPOC-3 uses the OU (Okamoto-Uchiyama) cryptographic function (basic cryptographic primitive) transformed by the OP method.

(2) Year of announcement of the transformation system: 2000 Okamoto, T. and Pointcheval, D.: OCAC: an Optimal Conversion for Asymmetric Cryptosystems, manuscript (2000)

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

Refer to EPOC-1.

Web address at which the technical specifications of the entry are available: http://info.isl.ntt.co.jp/

1.2 Technical Specifications

【Key Generation】

Input: Security parameter k, a positive integer Output: Public key (n, g, h, H1ID, H2ID, SEID, pLen, hLen, gLen, RLen, rLen)

Secret key (p, gp)

136 CRYPTREC 2000

4. Let pLen = k. mLen and RLen are set in such a way that they meet the condition RLen ≤ pLen − 1. 3k + kLen + RLen +mLen hLen RLen gLen 5. Two hash functions, H1: {0, 1} → {0, 1} and H2: {0, 1} → {0, 1} , are determined, and they are given identification numbers H1ID and H2ID, respectively. 6. Symmetric cryptosystem SymE is determined and is given identification number SEID. Here, SymE = (SymEnc, SymDec) is a pair of symmetric encryption and decryption algorithms having a common key of gLnen bits. In response to the input of key K and plaintext m, the encryption algorithm SymEnc outputs ciphertext SymEnc (K, m). In response to the input of key K and ciphertext c, the decryption algorithm SymDec outputs plaintext SymDec (K, c).

【Encryption】

Input: Plaintext m ∈ {0, 1}mLen Public key (n, g, h, H1ID, H2ID, SEID, pLen, hLen, gLen, RLen, rLen)

Output: Ciphertext c = (C1, C2, C3)

rLen RLen 1. r ∈ {0, 1} and R ∈ {0, 1} are selected uniformly at random, and H2(R) is calculated. R r 2. C1 = g h is calculated.

3. C2 = SymEnc (H2(R), m) is calculated.

4. C3 = H1(C1||C2||C3||R||m) is calculated.

5. C = (C1, C2, C3) is outputted as ciphertext.

【Decryption】

Input: Ciphertext c = (C1, C2, C3) Public key (n, g, h, H1ID, H2ID, SEID, pLen, hLen, gLen, RLen, rLen)

Secret key (p, gp) Output: Plaintext m ∈ {0, 1}mLen or no output Let L(x) := (x − 1)/p.

p−1 2 1. Cp = C1 mod p is calculated.

2. R' = L(Cp)/L(gp) mod p is calculated. 3. It is verified whether the following equation holds: R' ≤ 2rLen − 1

If the equation holds, m' = SymDec (H2 (R'), C2) is calculated. If it does not hold, there is no output as decryption result.

4. r' = H1(m'||R') is calculated.

5. It is verified whether C3 = H1(C1||C2||C3||R||m) holds. If it holds, m' is outputted as plaintext. If it does not hold, there is no output.

137 CRYPTREC 2000

(1) Parameter values recommended in the Cryptographic Techniques Specifications of the entry

• k: 320 bits or over (n: 960 bits or over) • hLen: 128 bits or over

(2) Typical parameters in "Performance Evaluation" in the Cryptographic Techniques Specifications of the entry (Vernum cipher used)

Case 1 (Under the assumption of strong security) Size of n: 1,152 bits, RLen = 128, gLen = 128, rLen = hLen = 128 Case 2 (Under the assumption of weak security) Size of n: 1,152 bits, RLen = 128, gLen = 128, rLen = 832, hLen = 128

1.3 Other

Refer to EPOC-1.

2. Evaluation Results

2.1 Evaluation of Security

Under the assumptions of the difficulty of the GAP-integer factoring problem of the n = p2q type and the presence of random functions, times cryptosystem has provable security of being semantically secure against adaptive chosen ciphertext attacks. Appropriate parameters must be selected carefully in order to satisfy these assumptions. It is necessary to note that even if the size is the same as in the RSA system, the degree of security is not necessarily the same partly because the form of the integer factoring of a composite number that is a modulus is different from that of the RSA system. A committee member points out that RLen must be sufficiently close to k − 1 and the order of h must be large in order to prove sufficient security with the parameters recommended by the proposer, k = 384 bits and RLen = 128 bits. However, since no conclusion has been reached on the propriety of these arguments in this evaluation, parameter selection needs to be studied further.

138 CRYPTREC 2000

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• In order to secure the strength equivalent to that of the RSA cryptosystem with a composite number length of 1,024 bits, the length of the composite number of EPOC-3 is: 384 bits × 3 = 1,152 bits. • The data size of EPOC-3 is 128 bits.

(2) Parameter setting method

• Random number seeds are read as a file.

(3) Verification of the parameters used

(4) Parameter size variations

• Distribution of the key of arbitrary length in symmetric cryptography • Secure transmission of long plaintext by the joint use with a proper symmetric cryptosytem, especially a capsule-like method of use (that is the key distribution synchronize with the data distribution). • Secure transmission of long plaintext by the joint use with a proper symmetric cryptosystem, especially a session-like method of use (that is, the key distribution when a session is opened and several times of data encryption later in the session)

[Features and Measurement Parameters]

Object of Security Implementation Parameter Other Measurement Evidence and Property EPOC-3 Integer factoring Composite number length in The data size in EPOC-3 for evaluation is 128 bits. problem EPOC-3: The Miller-Rabin method is used for primarity test. 384 bits × 3 = 1,152 bits

[Techniques Used in the Implementation]

139 CRYPTREC 2000

[System Parameter Generation]

• Since system parameter generation had been completed in advance, it was not performed in this evaluation.

[Key Pair Generation]

(1) Primarity testing conditions

• Primarity tests were performed using the GNU MP 3.1.1 function mpz_probab_prime_p (mpz_t n, int reps).

(2) Random number generation method

(3) Measurement results

[Key pair generation speed]

Object of Measurement Average Execution Speed Other EPOC-3 73.9 ms Not including random number generation. 743.3 ms Measured value, including random number generation and prime number generation.

[Encryption]

(1) Padding

• Not necessary because hashes are generated by the method described in the specification.

140 CRYPTREC 2000

(2) Hash function

• SHA-1 was used as hash function.

(3) Measurement results

[Encryption speed]

Object of Measurement Average Execution Speed Other EPOC-3 11.0 ms None

[Decryption]

(1) Measurement results

[Decryption speed]

Object of Measurement Average Execution Speed Other EPOC-3 8.3 ms None

[Code size (reference value)]

Object of Measurement Code Size Other EPOC-3 186,851 byte C language (Intel C/C++) source code size

141 CRYPTREC 2000

4.4.10 HIME-1

1. Cryptography

1.1 Technical Overview

HIME-1 is a combination of the basic system based on modular square functions that was devised by Genji Nishioka and Yoichi Seto in 2000 and the OAEP system proposed by Mihir Bellare and Phillip Rogaway in 1994. HIME-1 was announced by Genji Nishioka, Naonobu Sato, and Yoichi Seto of Hitachi Ltd. in 2000.

HIME-1 is a public key cryptosystem for confidentiality purposes based on the difficulty of the integer factoring problem (IF) (of the pdq type where d is an odd prime number). (Note: The scheme was initially submitted to the key sharing category.)

Intellectual property rights (as stated in the entry documents)

Intellectual property rights on HIME-1 are held by Hitachi Ltd. U.S. patent No. 5,103,479, "Encipher Method and Decipher Method" Patent application 2000-208237, "Public Key Cryptography and Communication Systems Using Public Key Cryptosystems"

It is declared that if the patent is granted, it will be licensed without discrimination and under appropriate fee conditions.

Web address at which the technical specifications of the entry are available: http://www.sdl.hitachi.co.jp/crypto/

1.2 Technical Specifications

Outlines of encryption and decryption functions are shown below.

[Secret key]

Two prime numbers p and q (p ≡ 3 (mod 4), q ≡ 3 (mod 4))

[Public key] n (= pdq, |pq| = k, d ≥ 3 (d: odd prime number))

[Hash function]

142 CRYPTREC 2000

k0 k −k0 −2 H1: {0, 1} → {0, 1}

k −k0 −2 k0 H2: {0, 1} → {0, 1}

【Decryption】

Ciphertext c is obtained by encrypting plaintext m (m ∈ {0, 1} k−k0 −k1−2 ) as shown below.

1. r: random number (r ∈ {0, 1} k0 ) k1 k1 2. z ← (((m||0 ) ⊕ H1 (r))||(r ⊕ H2 ((m||0 ) ⊕ H1 (r)))) 3. c ← z2n mod n

 z  4. a ←    n 

143 CRYPTREC 2000

【Decryption】

Plaintext m is obtained by decrypting ciphertext c as shown below.

( p +1)q −1 1. z ← c mod p p 4

( p +1)q −d 2. z ← c mod q q 4

2n 3. From zp and zq, z'j satisfying the condition c ≡ z mod n is calculated using the Chinese remainder

 z' j  k−2 theorem, and z'j satisfying the conditions a =   and z'j < 2 is computed.  n 

k −k0 −2 k0 4. For z'j = aj||bj(aj ∈ {0,1} , bj ∈ {0,1} ), m is outputted as

k−k0 −k1−2 k1 m = [z'j] if [H1 (H2 (aj) ⊕ bj) ⊕ aj] k1 = 0 . "reject" otherwise k In the above, [a] and [a]k represent the k high-order bits and the k low-order bits of a, respectively.

2. Evaluation Results

2.1 Evaluation of Security

The scheme cannot be uniquely identified and its security cannot be evaluated because its specifications are very ambiguous, lacking in clarity. In the detailed evaluation, ambiguous parts were modified as considered proper. It should be noted, however, that it is not guaranteed whether the modifications are really proper.

The following is the evaluation of the scheme as classified into the confidentiality category.

(a) Security of primitives

No effective attacks have been confirmed to date.

The security of primitives is based on the difficulty of finding the square root under mod n (more precisely the 2n-th root) .

It is required that the random numbers used for OAEP be fully random and that the output of a hash function be also random. The hash function to be used is not specified. The output length of H2 (H1 in the Specification) is set at 128 bits, and it should be noted that it will become comparatively easy to calculate its collision in the near future.

144 CRYPTREC 2000

(b) Security of parameters

The security of parameters is based on the difficulty of the integer factoring of the pdq (d: odd prime number) type. Since special prime factors are used, the difficulty of the integer factoring is unknown.

Although the Specification does not recommend any particular value of the key size parameter, the use of a 1,024-bit key is considered to provide sufficient resistance at present. It should be noted that there is no guaranteeing security in 15 or 20 years. The specifications should be modified to make the parameter variable.

Since the reasons for specifying individual parameters are not clear enough, their validity cannot be verified.

(d) Security of the scheme

The Specification claims security (semantical security against adaptive chosen ciphertext attacks: IND-CCA2) by using OAEP under a random oracle model. In order to make OAEP applicable, it is required that the primitive be one-way permutable. Although the primitive seems to have onewayness, attention should be paid to the fact that a special prime factor is used as a modulus. The permutation requirement is satisfied, though in a special form (realized by limiting the plaintext and jointly using Jacobi's symbols).

In addition, since it has become clear that OAEP alone cannot prove IND-CCA2, the security of this scheme cannot be guaranteed at present. (A committee member says it will become provable.)

2.2 Software Implementation Evaluation

This Specification has an ambiguity: The proposers show that the number field sieve method should be considered with respect to the method of implementation of the key generator, setting the size of composite number n at around 1,024 bits, and that the p ± 1 method should be considered in the selection of prime factors p and q of n. Key generation requires the generation of 256-bit prime numbers p and q. In order to avoid attacks based on integer factoring by the (p ± 1) method and on periodicity, it is desirable that p and q meet the following conditions:

1) p + 1 and p − 1 have sufficiently large prime numbers p1 and p2, respectively, as factors. (The same for q) 2) p1 + 1 and p1 − 1 have sufficiently large prime numbers s1 and r1, respectively, as factors. p2 + 1 and p2 − 1 have sufficiently large prime numbers s2 and r2, respectively, as factors. (The same for q)

145 CRYPTREC 2000

The addition of this specification has made software implementation evaluation possible.

[Implementation specifications]

(1) Properties of the parameters used

A) RSA encryption in which N = 1,024 bits (strength greater than confidentiality) B) More specifically, modulus N is of the N = p3q (d = 3) format, and p and q are 256 bits each. C) The p ± 1 method is considered in the selection of p and q. D) The Specification shows three types of public keys (N, k, d). In this implementation evaluation, the public key was fixed at d = 3.

(2) Parameter setting method

• Among the public keys, only d was incorporated for implementation.

(3) Verification of the parameters used

• There is no need for verification.

(4) Parameter size variations

• In this implementation, d was fixed to ‘3’. The size is variable according to the Specification.

(5) Compiler settings

1. -O2: Speed was optimized, giving priority to the execution speed. 2. -QxK: The processor to execute the instruction code was limited to Pentium III (SIMD support). (Together with the G6 option, the target processor was limited to Pentium III.) 3. -Zp16: The border adjustment of the structure was set at the 16-byte border.

[Techniques used in implementation]

A) Montgomery's multiplication and the 4-array method were used in exponential operations.

[System parameter generation]

B) The system parameter generation time was not measured this time.

[Features and Measurement Parameters]

Scheme Security Implementation Parameter and Other Measured Evidence Character

146 CRYPTREC 2000

HIME-1 Integer factoring Modulus N is of the N = p3q (d • The p ± 1 method is considered in the selection of problem = 3) format, and p and q are p1, p2, p3, and p4. 256 bits each. RSA encryption • The Cryptographic Techniques Specifications did in which N = 1,024 bits not require that the bit length of n be 1,023 bits or (strength greater than over or that p1, p2, p3, and p4 all differ from each confidentiality) other. However, since problems might occur, conditions were added in implementation this time. • Montgomery's multiplication and the 4-array method were used in exponential operations.

[Key Pair Generation]

【Algorithm 1: Key generation】

Output: Public key (n, k), secret key (p, q, α, β, z)

Step 1: Prime number p meeting the conditions p ≡ 3 (mod 4), |p| = 256 is selected. Step 2: Prime number q meeting the conditions q ≡ 3 (mod 4), |Q| = 256, p ≠ q is selected. Step 3: k = |pq| is calculated. Step 4: n = p3q is calculated. Step 5: k = |pq| is calculated. Step 6: α = q−1 (mod p − 1) is calculated. Step 7: β = p−1 (mod q − 1) is calculated. Step 8: z = q−1 (mod p) is calculated. Step 9: Public keys (n, k) and secret keys (p, q, α, β, z) are outputted.

(1) Primarity test conditions

Key generation requires the generation of 256-bit prime numbers p and q. In order to avoid attacks based on integer factoring by the (p ± 1) method and on periodicity, it is desirable that p and q meet the following conditions:

In the HIME-1 implementation, prime numbers meeting the above conditions were realized by the following method: p1 + 1 has prime number s1 as a factor. ⇔ p1 ≡ −1 (mod s1)...... (1) p2 + 1 has prime number r1 as a factor. ⇔ p1 ≡ 1 (mod r1)...... (2)

147 CRYPTREC 2000

Since s1 and r1 are prime numbers:

There exists g that makes s1 · g ≡ 1 (mod r1). g = s1−1 (mod r1) ...... (3)

At this time: p_1 = 1 + 2 · s1 · g (mod s1 · r1) meets the conditions (1) and (2)...... (4) If p_1 becomes an even number, another condition is added: p_1 = p_1 + s1 · r1...... (4)'

Prime numbers s1 and r1 are first generated, are applied to (3), (4), and (4)' to obtain a prime number candidate: A = p_1 + 2 · k · r1 · s1...... (5) (k: positive integer) The next candidate is A = A + 2 · k · r1 · s1. The above is summarized into an algorithm as shown below.

【Algorithm 2: Generation of Prime Numbers Secure against p ± 1 Method】

Input: Prime numbers s1 and r1 Output: Prime number p1

Step 1: In accordance with (3), (4), (4)', and (5), prime number candidate A is generated from prime numbers s1 and r1. Step 2: A table consisting of up to the 3000th prime numbers (2, 3, 5, 7, ... prime [3000]) is generated. In this implementation, a prime number table had been prepared in advance. Step 3: Remainder tables m[k] and m'[k] from k = 1 to k = 3000 are generated. m[k] ← A (mod prime [k]) m'[k] ← 2 · r1 · s1 (mod prime [k]) Step 4: A ← A + 2 · r1 · s1 Step 5: Remainder table m[k] from k = 1 to k = 3000 is renewed. m[k] ← (m[k] + m'[k] (mod prime[k]) Step 6: If any of all m[k]'s is 0, the operation returns to step 4. If not, the operation goes to step 7. Step 7: If it is judged that A is not a prime number by using algorithm 5, the operation returns to step 4. If it is judged that A is a prime number, the operation goes to step 8. Step 8: p1 ← A

For the generation of prime number(s) p (and q), the above algorithm is used to generate p1 from prime numbers s1 and r1 and to generate p2 from s2 and r2, and then algorithm 2 is applied to prime numbers p1 and p2.

【Algorithm 3: Generation of 256-Bit Prime Numbers Secure against p ± 1 Method】

148 CRYPTREC 2000

Output: 256-bit prime number p

Step 1: A 55-bit prime number, s1, is generated. Step 2: A 55-bit prime number, r1, is generated. Step 3: A 120-bit prime number, p1, is generated from s1 and r1 using algorithm 2. Step 4: A 55-bit prime number, s2, is generated. Step 5: A 55-bit prime number, r2, is generated. Step 6: A 120-bit prime number, p2, is generated from s2 and r2 using algorithm 2. Step 7: A 256-bit prime number, p, is generated from p1 and p2 using algorithm 2, and p is outputted.

In algorithm 3, it is necessary to generate a 55-bit prime number. In this implementation, algorithm 4, shown below, was used to generate a 55-bit prime number.

【Algorithm 4: Generation of a 55-Bit Prime Number】

Output: 55-bit prime number r

Step 1: A 55-bit prime number, r, is generated at random. Step 2: r is divided by the prime numbers up to the 3000th (referring to the table). If r has a prime number as a factor, the operation returns to step 1. Otherwise, the operation goes to step 3. Step 3: If it is judged by using algorithm 5 that r is not a prime number, the operation returns to step 1. If r is judged a prime number, the operation goes to step 4. Step 4: Prime number r is outputted.

Concerning primarity tests, the Cryptographic Techniques Specifications shows the Miller-Rabin method as an example. However, the Solovay-Strassen method was used in this implementation.

149 CRYPTREC 2000

【Algorithm 5: Primarity Tests (Solovay-Strassen Method)】

Input: Prime number candidate n Output: If n is a prime number, 1 is outputted. Otherwise, 0 is outputted.

Step 1: It is set that a[1] = 2, a[2] = 3, a[3] = 5, and a[4] = 7. Step 2: The following operations are performed from i = 1 to i = 4. Step 2.1: r = a[i] (n − 1)/2 mod n is calculated. Step 2.1: If r = 2, the operation ends, returning 0. Step 2.2: Jacobi's symbol s = J(a, n) is calculated. Step 2.3: If r ≠ s mod n, the operation ends, returning 0. Step 3: The operation ends, returning 1.

(2) Random number generation method

• Random numbers are generated using a rand function in C language.

(3) Measurement results

[Key pair generation speed]

Object of Measurement Average Execution Speed Other

HIME-1 934.0 ms Random number generation is included. Composite number size: 256 × 4 = 1,024 bits Prime numbers are implemented only for tests by the p ± 1 785.0 ms method.

[Encryption]

(1) Padding

• None

(2) Hash function

• SHA-1 was used.

(3) Measurement results

[Encryption speed]

Object of Measurement Average Execution Speed Other HIME-1 140.6 ms HIME-1 data size: 256 bits

150 CRYPTREC 2000

(4) Other

• The first 256 bits of a data file prepared by the Secretariat were used as the key information to be shared.

151 CRYPTREC 2000

[Decryption]

(1) Parameters used

• None

(2) Measurement results

[Decryption speed]

Object of Measurement Average Execution Speed Other HIME-1 24.7 ms HIME-1 data size: 256 bits

[Code size (reference value)]

Object of Measurement Code Size Other HIME-1 2,631 step C language (Intel C/C++)

2.3 Other

The Specification has many inadequacies, typographical errors, and tacit assumptions, leaving a number of ambiguous points about this scheme.

(The notations used below are those used in the Specification.)

(a) Specification details are not described.

(1) Hash functions (G1, H1: Section 3.2.6 of the Specification)

While these hash functions (G1, H1) is composed by using constants C, C1, ..., C3, it is not

prescribed how to select the constants C and Ci. If these constants are set inappropriately, there will be a deviation in the output of functions. The domain of the hash functions should be {0, 1}*, not {0, 1}∞. 382 896 The domain of H1 should be {0, 1} , not {0, 1} .

(b) There are inconsistencies in the description of specifications.

(1) Key generation (Section 3.2.1 of the Specification) While n-bit lengths are entered, p and q are generated being fixed at 256 bits.

(1) Prime number generation (Section 3.3.3 of the Specification) Prime numbers cannot be generated by using the Miller-Rabin function.

152 CRYPTREC 2000

The specifications of input value t are unclear.

(2) Jacobi's symbol (Section 3.3.5 of the Specification) In step 3, JACOBI (a/2, n) · (−1) n2−1/ 8 is an error for JACOBI (a/2, n) · (−1) (n2 −1) / 8 .

(d) Other

(1) The product of 256-bit prime numbers, (pdq), does not necessarily guarantee 1,024 bits.

(2) The meanings of p−1 and q−1 in decryption are unclear. Judging from subsequent descriptions, it seems that they should properly be p−1 mod q and q−1 mod p.

(3) In the description of implementation, it seems that 0 < m < 2k−2 should properly be 0 < m < 2 k −k0 −k1−2 .

(4) The description of implementation includes the statement that when m' ≥ 2k−2, m' ← pq − m'. It should be noted that this condition alone is not sufficient for the decryption of m from m'.

(5) The correlations shown in Figure 1 are wrong.

(6) The performance claimed is open to question as compared with systems based on elliptic curves and the Rabin method.

References

Technical Research Report of the Institute of Electronics, Information and Communication Engineers: ISEC2000-65 (2000-09)

153 CRYPTREC 2000

4.4.11 HIME-2

1. Cryptography

1.1 Technical Overview

HIME-2 is a transformation of the system combining the Rabin method proposed by Michael O. Rabin in 1979 and the OAEP system proposed by Mihir Bellare and Phillip Rogaway in 1994. HIME-2 was proposed by Genji Nishioka, Naonobu Sato, and Yoichi Seto of Hitachi Ltd. at an ISEC research conference in 2000.

HIME-2 is a public key cryptosystem for confidentiality purposes designed on the basis of the difficulty of the integer factoring problem (IF) (of the p1 ... pd type where d ≥ 4) .

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

Intellectual property rights on HIME-2 are held by Hitachi Ltd. U.S. patent No. 5,103,479, "Encipher Method and Decipher Method" Patent application 2000-208237, "Public Key Cryptography and Communication Systems Using Public Key Cryptosystems"

It is declared that if the patent is granted, it will be licensed without discrimination and under appropriate fee conditions.

Web address at which the technical specifications of the entry are available: http://www.sdl.hitachi.co.jp/crypto/

1.2 Technical Specifications

Outlines of encryption and decryption functions are shown below.

[Secret key]

d prime numbers pi

[Public key]

d When n(= ∏i =1 pi , n = k), n ≥ 1,024, n = 1,024 , d = 4 to 6 is recommended.

154 CRYPTREC 2000

Parameter sizes when |n| = 1,024 are shown below.

[Hash function]

k0 k −k0 H1: {0, 1} → {0, 1} , k0 = 128

k −k0 k0 H2: {0, 1} → {0, 1}

[Decryption]

k −k0 −k1 Ciphertext c is obtained by encrypting plaintext m (m ∈ {0, 1} , k1= 128) as shown below.

1. r: random number (r ∈ {0, 1} k0 )

k1 k1 2. z ← (((m||0 ) ⊗ H1 (r))||(r ⊗ H2 ((m||0 ) ⊗ H1 (r))) 3. c ← z2 mod n

155 CRYPTREC 2000

【Decryption】

Plaintext m is obtained by decrypting ciphertext C as shown below.

( p +1) 1. z ← c i mod p (i = 1, ..., d) i 4 i

2 2. From zi (i = 1, ..., d), all (2d) z'j satisfying c ≡ z mod n is calculated using the Chinese remainder theorem.

k−k0 k0 d 3. For z'j = aj||bj(aj ∈ {0,1} , bj ∈ {0,1} , j = 1, ..., 2 ), m is outputted as

k −k0 −k1 k1 m = [z'j] if [H1 (H2 (aj) ⊕ bj) ⊕ aj] k1 = 0 , "reject" otherwise k In the above, [a] and [a]k represent the k high-order bits and the k low-order bits of a, respectively.

2. Evaluation Results

The specifications have ambiguities, and the scheme cannot be uniquely identified. Therefore, third parties cannot implement it. Although the proposer claims provable security, it cannot be verified whether the claim is correct.

2.1 Evaluation of Security

The specifications have ambiguities, and the scheme cannot be uniquely identified. In the detailed evaluation, ambiguous parts were modified as considered proper. It should be noted, however, that strictly, it is not guaranteed whether the modifications are really proper.

(a) Security of primitives

No effective attacks have been confirmed to date.

The security of primitives is based on the difficulty of finding the square root under mod n.

It is required that the random numbers used for OAEP be fully random and that the output of a hash function be also random. The hash function to be used is not specified. The output length of H2 is set at 128 bits, and it should be noted that it will become comparatively easy to calculate its collision in the near future.

(b) Security of parameters

The security of parameters is based on the difficulty of the integer factoring of the p1 ... pd(d ≥ 4) type.

Since the modulus of HIME-2 differs from that of RSA in form, it is necessary, in determining the size of

156 CRYPTREC 2000

modulus, to consider the integer factoring method using an elliptic curve (ECM) in which execution time depends on the size of the least prime factor.

This will lead to a larger number of secret keys. A committee member suspects the inevitability of increasing processing speed by reducing the sizes of individual prime factors.

Except when the modulus size that is a key is 1,024 bits, the Specification does not recommend any particular values of other parameters (d, k0, k1). Although the use of a 1,024-bit key is considered to provide sufficient resistance at present, it is open to question whether it will continue to be secure 15 or 20 years later. The specifications should be modified to make the parameter variable.

Since the reasons for specifying individual parameters sizes with 1,024-bit keys are not clear enough, their validity cannot be verified.

A committee member says there is a security problem in using the product of small prime numbers.

(d) Security of the scheme

The Specification claims security (semantical security against adaptive chosen ciphertext attacks: IND-CCA2) by using OAEP under a random oracle model.

In order to make OAEP applicable, it is required that the primitive be one-way permutable. Although the primitive seems to have onewayness, the Specification does not clearly state to that effect. The permutation requirement is clearly not satisfied. Although it is possible to narrow down decryption results by using auxiliary information, this cannot be performed before unique decryption. Even if checking is done by the OAEP part, there is a possibility, however slim, that different plaintext might be obtained.

In addition, since it has become clear that OAEP alone cannot prove IND-CCA2, the security of this scheme cannot be guaranteed at present. (A committee member says it will become provable.)

2.2 Software Implementation Evaluation

The proposer shows that the number field sieve method should be considered with respect to the method of implementation of the key generator, setting the size of composite number n at around 1,024 bits, and that the p ± 1 method should be considered in the selection of prime factors p and q of n. Key generation requires the generation of 256-bit prime numbers p and q. In order to avoid attacks based on integer factoring by the (p ± 1) method and on periodicity, it is desirable that p and q meet the following conditions:

157 CRYPTREC 2000

The addition of this specification has made software implementation evaluation possible.

[Implementation specifications]

(1) Properties of the parameters used

A) RSA encryption in which N = 1,024 bits (strength greater than confidentiality)

B) More specifically, modulus N is of the N = p1p2p3p4 (d = 3) format, and p1, p2, p3, and p4 are 256 bits each.

C) The p ± 1 method is considered in the selection of p1, p2, p3, and p4. D) The Cryptographic Techniques Specifications did not require that the bit length of n be 1,023

bits or over or that p1, p2, p3, and p4 all differ from each other. However, since problems might occur, conditions were added in implementation this time.

(2) Parameter setting method

• None

(3) Verification of the parameters used

• There is no need for verification.

(4) Parameter size variations

• In this implementation, the size of n was set at 1,023 or 1,024 bits.

(5) Compiler settings

A) Montgomery's multiplication and the 4-array method were used in exponential operations.

158 CRYPTREC 2000

[Features and Measurement Parameters ]

Scheme Security Implementation Parameter and Other Measured Evidence Character HIME-2 Integer factoring Modulus N is of the N = • The p ± 1 method is considered in the selection of problem p1p2p3p4 (d = 3) format, and p1, p1, p2, p3, and p4. p2, p3, and p4 are 256 bits each. • The Cryptographic Techniques Specifications did RSA encryption in which N = not require that the bit length of n be 1,023 bits or 1,024 bits (strength greater than over or that p1, p2, p3, and p4 all differ from each confidentiality) other. However, since problems might occur, conditions were added in implementation this time. • Montgomery's multiplication and the 4-array method were used in exponential operations.

[System parameter generation]

• The system parameter generation time was not measured this time.

[Key Pair Generation]

【Algorithm 1: Key generation】

Output: Public key (n, k), secret key (p, q, α, β, z)

(1) Primarity test conditions

159 CRYPTREC 2000

p2 − 1 have sufficiently large prime numbers s2 and r2, respectively, as factors. (The same for q)

Since s1 and r1 are prime numbers:

There exists g that makes s1 · g ≡ 1 (mod r1). g = s1−1 (mod r1) ...... (3) At this time: p_1 = 1 + 2 · s1 · g (mod s1 · r1) meets the conditions (1) and (2)...... (4) If p_1 becomes an even number, another condition is added: p_1 = p_1 + s1 · r1...... (4)'

The above is summarized into an algorithm as shown below.

【Algorithm 2: Generation of Prime Numbers Secure against p ± 1 Method】

Input: Prime numbers s1 and r1 Output: Prime number p1

160 CRYPTREC 2000

Step 8: p1 ← A

【Algorithm 3: Generation of 256-Bit Prime Numbers Secure against p ± 1 Method】

Output: 256-bit prime number p

In algorithm 3, it is necessary to generate a 55-bit prime number. In this implementation, algorithm 4, shown below, was used to generate a 55-bit prime number.

【Algorithm 4: Generation of a 55-Bit Prime Number】

Output: 55-bit prime number r

【Algorithm 5: Primarity Tests (Solovay-Strassen Method)】

Input: Prime number candidate n Output: If n is a prime number, 1 is outputted. Otherwise, 0 is outputted.

Step 1: It is set that a[1] = 2, a[2] = 3, a[3] = 5, and a[4] = 7.

161 CRYPTREC 2000

Step 2: The following operations are performed from i = 1 to i = 4. Step 2.1: r = a[i] (n − 1)/2 mod n is calculated. Step 2.1: If r = 2, the operation ends, returning 0. Step 2.2: Jacobi's symbol s = J(a, n) is calculated. Step 2.3: If r ≠ s mod n, the operation ends, returning 0. Step 3: The operation ends, returning 1.

(2) Random number generation method

• Random numbers are generated using a rand function in C language.

(3) Measurement results

[Key pair generation speed]

Object of Measurement Average Execution Speed Other

HIME-2 2,845.0 ms Random number generation is included. Composite number size: 256 × 4 = 1,024 bits Prime numbers are implemented only for tests by the p ± 1 1,829.0 ms method.

[Encryption]

(1) Padding

• None

(2) Hash function

• SHA-1 was used.

(3) Measurement results

[Encryption speed] Object of Measurement Average Execution Speed Other HIME-2 0.4 ms HIME-2 data size: 256 bits

(4) Other

• The first 256 bits of a data file prepared by the Secretariat were used as the key information to be shared.

162 CRYPTREC 2000

[Decryption]

(1) Parameters used

• None

(2) Measurement results

[Decryption speed]

Object of Measurement Average Execution Speed Other HIME-2 15.3 ms HIME-2 data size: 256 bits

[Parameters used]

• As p and q, prime numbers were generated at the time of key generation.

[Code size (reference value)]

Object of Measurement Code Size Other HIME-2 2,666 step C language (Intel C/C++)

2.3 Other

There are various problems in the specifications of this cryptographic scheme. They will have to be modified for actual use.

(The notations used below are those used in the Specification.)

(a) Specification details are not described.

(1) Hash functions (G2, H2: Section 3.2.6 of the Specification)

While these hash functions (G2, H2) is composed by using constants C, C1, ..., C7, it is not

In H2, the bit lengths of variables x1, ..., x7 are not specified.

(2) Convert (Section 3.2.4 of the Specification) The bit expression method for m is not clear.

163 CRYPTREC 2000

(b) Although detailed specifications are described, some of them are meaningless.

(1) Decryption algorithm (Section 2.2.3 of the Specification) While ϕ has d inputs, it is described as 2 inputs. It makes no sense.

It is considered that "edxi" is a typographical error for "edxd." The conditions for continuing loops are not clear. It is not clear what processing is performed if multiple m's are obtained.

(2) Details of the decryption algorithm (Section 3.2.3 of the Specification) There is no output of "reject." There is a possibility of falling into an infinite loop.

(1) Explanation of signs (Section 3.1 of the Specification) The description of ϕ is not consistent. Limitations to w (w ≡ x mod n, w ≡ y mod m) are wrong. (It is considered that w ≡ x mod m, w ≡ y mod n are correct.)

(2) Details of algorithms (Section 3.2 of the Specification) The description of ϕ is not consistent.

(3) Key generation (Section 3.2.1 of the Specification)

While n-bit lengths are entered, pi are generated being fixed at 256 bits. The usage of the term "random prime" is not proper.

(4) Encryption (Section 3.2.2 of the Specification) Input value R to convert is not prescribed. Convert is a three-input function (while it is a two-input function according to the Specification).

(d) There are some (mathematical) errors in the description of algorithms, etc.

(1) Prime number generation (Section 3.3.3 of the Specification) Prime numbers cannot be generated by using the Miller-Rabin function. The specifications of input value t are unclear.

(2) Jacobi's symbol (Section 3.3.5 of the Specification)

2−1 / 8 In step 3, JACOBI (a/2, n) · (−1) n should correctly be JACOBI (a/2, n) · (−1) (n2 −1) / 8 .

(3) Ring isomorphism by the Chinese remainder theorem (Section 3.3.6 of the Specification) z =m−1 mod n is an error for z = n−1 mod m.

164 CRYPTREC 2000

(e) The objectives of some descriptions are unclear.

(1) Remarks (Section 2.2.4 of the Specification) Since no specifications are prescribed for the size of n or the value of d, their dependence on algorithms is unknown. Search methods using auxiliary information w and a are unknown.

(f) Typographical errors

(1) Greatest common divisors and inverses (Section 3.3.4 of the Specification) It is considered that BINARY-EUCLID (a, n) should be BINARY-EUCLID (x, y).

(2) Security of HIME-2 (Section 1.1 of the Specification)

The specification of Ds,k is unknown.

(g) Other

(1) It is not described whether the limitation (pi ≡ 3 (mod 4)) to prime numbers is essential in the scheme. Descriptions about implementation include this limitation, and this limitation is assumed in some descriptions.

(2) The product of four 256-bit prime numbers does not necessarily guarantee 1,024 bits.

(3) Intermediate variable z may become equal to or larger than n. In such cases, decryption results become even more complex.

(4) It is a problem that k0 and k1 are user-dependent as public keys.

(5) It is not clear whether this scheme is so useful as the RSA system or the Rabin method.

References

Technical Research Report of the Institute Electronics, Information and Communication Engineers: ISEC2000-65 (2000-09)

165 CRYPTREC 2000

4.4.12 RSA-OAEP

1. Cryptography

1.1 Technical Overview

RSA-OAEP is a public key cryptosystem for confidentiality purposes based on the integer factoring problem (IF). It is a combination of the RSA cryptosystem proposed by Ronald L. Rivest, Adi Shamir, Leonard M. Adleman in 1977 and the Optimal Asymmetric Encryption Padding (OAEP) proposed by Mihir Bellare and Phillip Rogaway in 1994.

(1) Year of announcement of RSA: 1977 R. Rivest, A. Shamir, and L. Adleman. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, 21 (2), pp. 120-126, February 1978. (2) Year of announcement of OAEP: 1994 M. Bellare and P. Rogaway. Optimal Asymmetric Encryption--How to Encrypt with RSA. In Advances in Cryptology-Eurocrypt '94, pp. 92-111, Springer-Verlag, 1994.

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

• There are no related patents.

Web address at which the technical specifications of the entry are available: http://www.rsasecurity.com/rsalabs/rsa_alogorithm/

1.2 Technical Specifications

【Key Generation】

Output: Public key (e, n), secret key d

1. Prime numbers p and q are generated. 2. n = pq and λ (n) = LCM (p−1, q−1) are calculated.

3. e ∈ Zλ (n) and (GCD (e, λ (n)) = 1) are determined appropriately. 4. d = 1/e mod λ (n) is calculated. 5. The public key (e, n) and the secret key d are outputted.

166 CRYPTREC 2000

The following two random functions are determined by the system:

k0 n+k1 H1: {0, 1} → {0, 1}

n+k1 k0 H2: {0, 1} → {0, 1}

【Encryption】

Input: Plaintext m ∈ {0, 1}n, public key (e, n) Output: Ciphertext c

1. Random numbers r ∈ {0,1} k0 are generated.

k1 2. Let s = (m||0 ) ⊕ H1 (r)

3. Let t = r ⊕ H2 (s) 4. Let w = s||t 5. Ciphertext c = we is outputted.

【Decryption】

Input: Ciphertext c, secret key d Output: Plaintext m

1. w = cd is calculated. 2. Let s be n + k1 high-order bits of w. 3. Let t be the k0 low-order bits of w.

4. Let r = t ⊕ H2 (s)

5. Let z = H1 (r) ⊕ s 6. If the k1 low-order bits of z are 0 k1 , the n high-order bits of z are outputted as plaintext m. Otherwise, "decryption error" is outputted.

1.3 Other

This scheme is described in IEEE P1363[1], PKCS #1 V2.0[2], or soon-to-be-established ANSI X9.44 [3]. A related, though not compatible, mechanism is described in the Secure Electronic Transactions (SET) Protocol.

[1] IEEE Std 1363-2000: Standard Specifications for Public Key Cryptography. IEEE, to appear. [2] RSA Laboratories. PKCS #1: RSA Cryptosystem Standard. Version 2.0, October 1, 1998. Available from http://www.rsasecurity.com/rsalabs/pkcs/. (Republished as IETF RFC 2437, available at ftp://ftp.isi.edu/in-notes/rfc2437.txt.) [3] ANSI X9.44: Key Establishment Using Factoring-Based Public Key Cryptography for the Financial

167 CRYPTREC 2000

Services Industry. Working draft, June 2000.

2. Evaluation Results

2.1 Evaluation of Security

Under the assumptions of the onewayness of the RSA encryption function and a random oracle model, this cryptographic scheme is shown to be semantically secure against adaptive chosen ciphertext attacks. However, appropriate parameter settings are required for the RSA encryption function to show onewayness. Meanwhile, common OAEP transformation was not enough to provide the property of being semantically secure against adaptive chosen message attacks. With respect to RSA-OAEP, however, it has recently been verified that the scheme is semantically secure against adaptive chosen message attacks under the assumption of partial onewayness of the RSA encryption function (in the case of the RSA encryption function, partial onewayness is equivalent to onewayness).

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• The present mainstream modulus length is 1,024 bits. • Modulo value length of the public key: 1,024 bits. • Public index F4 (65537)

(2) Parameter setting method

• The value of modulo N (= publish key) and a secret key are generated from prime numbers. • Changes in the modulo length can be specified within the range from 1,024 bits to 2,048 bits. In the evaluation program, the length is directly specified on the source just before calling the function to generate keys.

(3) Verification of the parameters used

• The evaluation program uses Miller-Rabin's probabilistic primarity testing method to test the prime numbers used for key generation. The "strength" of prime numbers is not checked. That is, it is not checked whether generated numbers are really strong from the viewpoint of probability.

168 CRYPTREC 2000

(4) Parameter size variations

• The length of the modulo value N can be specified within the range from 1,024 bits to 2,048 bits. • Either 17 or 65537 can be specified as public index e. • Both are directly described on the source. (Either 1 (e = 65537) or 0 (e = 17) is specified as the parameter for the public index.)

[Techniques Used in the Implementation]

• The speed of modulo arithmetic was increased by using the Chinese remainder theorem (CRT).

[Characteristics and Measurement Parameters]

Scheme Security Implementation Parameter and Other Measured Evidence Character RSA-OAEP Integer factoring Modulo value length of public Speed is increased by using the Chinese remainder problem key: 1,024 bits theorem (CRT). Public index: 65537

[System Parameter Generation]

(1) Measurement results

Object of Measurement Result of Measurement Other RSA-OAEP 1.104 ms e = 17 1.107 ms e = 65537

[Key Pair Generation]

(1) Primarity test conditions

The evaluation program uses Miller-Rabin's probabilistic primarity testing method to test the prime numbers used for key generation. The "strength" of prime numbers is not checked. That is, it is not checked whether generated numbers are really strong from the viewpoint of probability.

(2) Random number generation method

Random number seeds are directly specified by the main routine for measurement. SHA-1 is used to generate random numbers from which prime numbers are generated. Other algorithms are not supported.

169 CRYPTREC 2000

(3) Measurement results

[Key pair generation speed]

Object of Measurement Average Execution Speed Other RSA-OAEP 2,946.5 ms e = 17 3,405.5 ms e = 65537

(4) Other

When random number seeds are generated by software for actual use, a certain length of time and multiple tests should be combined for the purpose of security.

[Encryption]

(1) Padding

• EME-OAEP padding

(2) Hash function

• SHA-1

(3) Measurement results

[Encryption speed]

Object of Measurement Average Execution Speed Other RSA-OAEP 4.2 ms e = 17 4.2 ms e = 65537

[Decryption]

(1) Measurement results

[Decryption speed]

Object of Measurement Average Execution Speed Other RSA-OAEP 84.2 ms e = 17 84.2 ms e = 65537

[Parameters used]]

• Public index F4 (65537)

170 CRYPTREC 2000

[Code size (reference value)]

Object of Measurement Code Size Other RSA-OAEP 62,413 byte Size of executable test program for performance measurement

171 CRYPTREC 2000

4.4.13 ACE Encrypt

1. Cryptography

1.1 Technical Overview

ACE Encrypt is a special transformation of the cryptosystem proposed by Ronald Cramer and Victor Shoup at Crypto '98 in 1998. It was announced as a manuscript by Thomas Schweinberger and Victor Shoup at the Zurich institute of IBM in 2000 and was proposed by IBM Japan, Ltd. It is a public key system that realizes confidentiality based on the difficulty of the discrete logarithm problem (DLP) (in a prime field).

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

The intellectual property rights concerning ACE Encrypt are held by IBM. Ronald Cramer, Victor Shoup, "Practical non-malleable public-key cryptosystem" filed February 16, 1999. IBM declared that if ACE Encrypt was adopted (by ISO), it would license it without discrimination and under appropriate fee conditions.

1.2 Technical Specifications

Outlines of signature encryption and decryption functions are shown below.

[Secret Key]

x, x1, x2, x3, x4 ∈ Zq

[Publish Key]

p, q, g1, g2, y1, y2, y3, y4 q: Prime number (|q| = 256) p: Prime number (p ≡ 1 (mod q))

q * g1: (g 1 ≡ 1 (mod p), g1 ∈ Z p , g1 ≠1) x g2: (g2 = g 1 mod p)

x1 y1: (y1 = g 1 mod p)

x2 y2: (y2 = g 1 mod p)

x3 y3: (y3 = g 1 mod p)

x4 y4: (y4 = g 1 mod p)

172 CRYPTREC 2000

[Hash Functions]

* 160 H1: {0,1} → {0,1} * 256 H2: {0,1} → {0,1}

【Encryption】

Ciphertext c is obtained by encrypting plaintext m as shown below. (Unless otherwise specified, operations are performed under mod p.)

128 1. r': random number (r ∈ {0,1} ), r: random number (r ∈ Zq) r r 2. u1 ← g1 , u2 ← g 2

3. h ← H1 (r', u1, u2) r hr 4. v ← y1 y2 ~ r ~ ~ r 5. y3 ← y3 , y4 ← y4 ~ ~ 6. k ←H2 (r', u1, y3 , y4 ) 7. z ←E (k, m)

8. c ← r'||u1||u2||v||z

In the above, E (k, m) represents encryption and MAC generation by key k to message m using the sum/counter mode of MARS.

【Decryption】

Plaintext m is obtained by decrypting ciphertext c as shown below.

1. r'||u1||u2||v||z ← c

2. h ← H1 (r', u1, u2)

x1+hx2 3. If v ≠ u1 , the operation ends, outputting "reject."

~ x3 ~ x4 4. y3 ← u1 , y4 ← u2 ~ ~ 5. k ← H2 (r', u1, y3 , y4 ) 6. m ← D (k, z)

In the above, D (k, z) represents decryption and MAC verification by key k to ciphertext z using the sum/counter mode of MARS.

173 CRYPTREC 2000

2. Evaluation Results

2.1 Evaluation of Security

(a) Security of primitives

No effective attacks have been confirmed to date.

The security of primitives is based on the difficulty of the discrete logarithm problem under mod p.

It is required that the hash function used have general onewayness (more precisely, the second pre-image collision resistance) and that the symmetric cryptosystem have pseudo-randomness when used in a sum/counter mode. The random numbers used for encryption need to be fully random.

(b) Security of parameters

The security of parameters is based on the difficulty of the discrete logarithm problem in a prime field. Although it is not described in the specifications, it should be avoided to use special types (prime numbers to which the Gordon method is applicable) as keys.

The security of this scheme has been proved on a standard model (under circumstances close to actual ones). The security is based on the decision DH problem (DDH), the assumption concerning generally one-way hash functions (the second pre-image collision resistance of SHA-1), and the assumption concerning the pseudo-randomness of symmetric cryptography (the pseudo-randomness of the MARS in the sum/counter mode). (It should be noted that the decision DH problem (DDH) is a more special assumption than the calculation DH problem and the discrete logarithm problem.)

In this scheme, a general one-way hash function is made from the hash function SHA-1. Symmetric cryptographic primitives are realized by using SHA-1 and the symmetric cryptosystem MARS in the sum/counter mode. Hence the need for the assumption concerning the second pre-image collision resistance of SHA-1 and the assumption concerning the pseudo-randomness of the MARS in the sum/counter mode.

As evaluated on a random oracle model, the security of this scheme depends on the computational DH problem.

2.2 Software Implementation Evaluation

With respect to ACE Encrypt, its specifications were modified after it was entered for evaluation.

174 CRYPTREC 2000

Therefore, the Committee did not evaluate the software implementability corresponding to the techniques described in the initially submitted documents.

2.3 Other

This scheme is so tactfully built that it lacks in flexibility. For example, if the hash function is replaced by the simple SHA-1, it impairs the security of the scheme. Furthermore, although it is possible to change the symmetric cryptographic primitive (MARS) (though the resulting security is unclear), the deletion of the message authentication code part impairs security.

It should be noted that the Specification uses m in two senses: the bit length of p and the block length (in bytes) of symmetric ciphers.

The parameters entered into the hash function H2 to generate keys for symmetric ciphers differ between the Specification (two variables, h1 and h2) and the source paper (one variable, h). This is an important change for key randomness, and the use of only one variable will cause an inadequacy in the proof of security.

It would be possible to realize this scheme on elliptic curves, though there will be disadvantages in key size and computational complexity.

175 CRYPTREC 2000

4.4.14 ECAES in SEC1

1. Cryptography

1.1 Technical Overview

ECAES in SEC1 is a public key cryptosystem formulated by SECG (Standards for Efficient Cryptography Group) in 1999. It is an encryption system using elliptic curves.

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

• 5,761,305: Key Agreement and Transport Protocol with Implicit Signatures, issued June 2, 1998. This patent includes versions of the MQV protocols.

• 5,787,028: Multiple Bit Multiplier, issued July 28, 1998.

• 5,889,865: Key Agreement and Transport Protocol with Implicit Signatures, issued March 30, 1999. This patent includes versions of the MQV protocols.

• 5,896,455: Key Agreement and Transport Protocol with Implicit Signatures, issued April 20, 1999. This patent includes versions of the MQV protocols.

The above proposers' patents and copyrights are licensed by the proposers without discrimination of licensees under reasonable conditions.

For details, visit the Web sites of the patentees and the SECG's Web site (www.secg.org). http://www.secg.org/patent_policy.htm http://www.secg.org/collateral/certicom_secg_patent.pdf

Web address at which the technical specifications of the entry are available: http://www.labs.fujitsu.com/theme/crypto/public_key.html http://www.secg.org/drafts.htm

176 CRYPTREC 2000

1.2 Technical Specifications

Elliptic curve parameter (p, a, b, G, l) This shows that there is a rational point G of prime order l on the elliptic curve y2 = x3 + ax + b

over the prime field Fp.

[Public key]

Elliptic curve parameter (p, a, b, G, l) or (k, f, a, b, G, l), and a point U that is a multiple of the point G

[Secret key]

Integer d satisfying U = d · G

【Encryption】

A ciphertext c is obtained by encrypting a plaintext m as shown below.

1. r ← a random number not less than 1 and not greater than l-1, R ← r · G 2. z ← x (r · U) 3. K = EK||MK ← Hash (z) 4. Plaintext m is encrypted with the key EK by a symmetric cipher E: em ← E (EK, m) 5. Authentication code D for the ciphertext em is generated with the key MK by the authentication code generation function MAC.Gen: D ← MAC. Gen (MK, em) 6. c ← R||em||D

【Decryption】

Plaintext m is obtained by decrypting ciphertext c as shown below.

1. R||em||D ← c 2. z ← x (d · R) 3. K = EK||MK ← Hash (z) 4. Authentication code D is verified with the key MK by the authentication code verification function

177 CRYPTREC 2000

MAC.Ver: v ← MAC. Ver (MK, em, D) 5. If v is 'invalid,' the operation stops, outputting 'invalid.' If v is 'valid,' em is decrypted with the key EK by the symmetric cipher E: m ← E (EK, em)

In the above, x (P) denotes the x coordinate of a point P on an elliptic curve.

1.3 Other

ECAES in SEC1 is described in IEEE P1363.

2. Evaluation Results

2.1 Evaluation of Security

2.1.1 Security of cryptographic primitive

ECAES in SEC1 is a public key cryptosystem based on the difficulty of the DH problem on elliptic curves. Generally, it is strongly believed that the DH problem cannot be solved unless the discrete logarithm problem is solved. Therefore, the security of ECAES in SEC1 as a cryptographic primitive is practically equal to the security of the discrete logarithm problem on elliptic curves.

Various attacks are known against the discrete logarithm problem on elliptic curves. In the case of ECAES in SEC1, elliptic curve parameters in various sizes, to which no known attack can be applied, are explicitly given in SEC2 documents. (These are recommended parameters, not prohibited to use other parameters.) These elliptic curves consist of elliptic curves randomly selected in a verifiable manner and elliptic curves called Koblitz curves. Koblitz curves are included because of their high performance and their traditional use. However, since they are within a very limited class, it should be noted that a new attack against them could appear.

2.1.2 Security of the Scheme

It has been proved that ECAES in SEC1 is secure against adaptive chosen ciphertext attacks by active attackers under Assumption 1 shown below.

Assumption 1: Under the notations in Technical Overview, let DH (U, R) denote the solution to the DH problem about U and R. The oracle that returns x (DH (U, R')) for (G, U, R') is called a DH oracle. Then, the assumption is that no attackers can practically distinguish, even if they are allowed to make queries to the DH oracle, the distribution {(G, U, R, z) | z = Hash (x coordinate of DH (U, R)) from the distribution

178 CRYPTREC 2000

{(G, U, R, r) | r: random number}.

Assumption 1 is an assumption of the form that "there are no such-and-such attackers.", too easy for the proof of security. In fact, many experts in cryptography bring questions on the validity of Assumption 1. There is an opinion that the proof under the Assumption 1 has no meaning for the proof of the security of public key cryptosystems.

However, a detailed evaluator has shown that under a random oracle model, the security of ECAES in SEC1 can be reduced to the difficulty of the GAP DH problem on elliptic curves. (The GAP DH problem is a problem of solving a DH problem using an algorithm solving a DDH problem.) Therefore, it is considered that ECAES in SEC1 is secure as a cryptographic scheme. However, since the GAP DH problem is a comparatively new problem, continuous security evaluation is necessary.

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

(2) Parameter setting method

• Elliptic curve parameters are read from a file for use. • The software is implemented in a way not dependent on parameters.

(3) Verification of the parameters used

(4) Parameter size variations

• Not only fixed parameters but also arbitrary elliptic curve parameters can be used. • Bit lengths that can be handled in parameters of elliptic curves in a prime field are as follows:

179 CRYPTREC 2000

112, 128, 160, 192, 224, 256, 384, 521 • Bit lengths that can be handled in parameters of elliptic curves in a field of characteristic two are as follows: 113, 131, 163, 193, 233, 239, 283, 409, 571

[Techniques Used in the Implementation]

• No high-speed techniques limited to special parameters such as a = 0 and a = 3 are used in the library. • High-speed techniques applicable to any parameters are used. • The software is implemented in a way not dependent on parameters.

180 CRYPTREC 2000

[Characteristics and Measurement Parameters]

Implementation Scheme Measured Security Evidence Parameter and Other Character ECAES in SEC1 Discrete logarithm Equivalent to • One of the parameters recommended in the SEC1 160-bit prime field problem on elliptic RSA 1,024 bits specifications. Based on the ANSI X9.62 curves specifications. ECAES in SEC1 Equivalent to • Since the two coefficients of an elliptic curve are 163-bit field of RSA 1,024 bits related by (uncontrollable) SHA-1 outputs, it is characteristic 2 randomly verifiable that the parameters have been selected freely. • As in the X9.62 specifications, SHA-1 inputs are also described as part of the parameters. • It has been verified that special attacks are ineffective. • High-speed techniques applicable to any parameters are used. • The software is implemented in a way not dependent on parameters.

[System Parameter Generation]

• Since the generation of elliptic curve parameters is based on a probabilistic algorithm, it is difficult to determine a precise anticipated processing time. • According to the entry's experiment, the processing time in the case of a 160-bit elliptic curve is within 10 minutes on the average with the 700 MHz Pentium III.

Measurement results

Scheme Measured Average Execution Time Remarks ECAES 160-bit prime field 6.0 min Three elliptic curve parameters were generated in 18 minutes.

[Initialization/Termination]

Measurement results

Scheme Measured Average Execution Time Remarks ECAES PC/PF 0.004 ms None 160-bit prime PI 13.525 ms None field PV 60.438 ms None WC/WF 0.032 ms None ECAES PC/PF 0.004 ms None 163-bit field of PI 15.283 ms None characteristic 2 PV 43.917 ms None WC/WF 0.032 ms None

PC/PF: An elliptic curve parameter area is acquired/released.

181 CRYPTREC 2000

PI: The parameters read from a file are set in the area.

WC/WF: The work area is acquired/released.

182 CRYPTREC 2000

[Key Pair Generation]

(1) Primarity test conditions

• No test is necessary for system reasons.

(2) Random number generation method

• Fujitsu's original pseudo-random number generation algorithm. DES/SHA-1, etc. are used.

(3) Measurement results

Scheme Measured Average Execution Time Remarks ECAES 1.932 ms Key pair generation 160-bit prime field 5.820 ms Key pair verification ECAES 3.150 ms Key pair generation 163-bit field of characteristic 2 8.010 ms Key pair verification

• Key pair verification is not necessary if the keys are generated by the user.

[Key pair generation speed]

Scheme Measured Average Execution Time Remarks ECAES in SEC1 1.9 ms Key pair generation 160-bit prime field 5.8 ms Key pair verification, which is not necessary if the keys are generated by the user. ECAES in SEC1 3.2 ms Key pair generation 163-bit field of characteristic 2 8.0 ms Key pair verification, which is not necessary if the keys are generated by the user.

[Encryption]

(1) Padding

• Not used.

(2) Hash function

• Not used.

(3) Measurement results

[Encryption speed]

Scheme Measured Average Execution Time Remarks

183 CRYPTREC 2000

ECAES in SEC1 8.5 min None 160-bit prime field ECAES in SEC1 12.5 min None 163-bit field of characteristic 2

(4) Other

KDF: ANSI-X9.63-KDF with SHA-1 MAC: HMAC-SHA-1-160 with 20 octet or 160 bit keys ENC: XOR encryption scheme Key sharing primitive: standard elliptic curve Diffie-Hellman primitive [Decryption]

(1) Measurement results

[Decryption speed]

Scheme Measured Average Execution Time Remarks ECAES in SEC1 5.4 min None 160-bit prime field ECAES in SEC1 8.7 min None 163-bit field of characteristic 2

[Code size (reference value)]

Scheme Measured Code Size Remarks ECAES in SEC1 356,352 byte Size of executable test program for performance measurement

184 CRYPTREC 2000

4.4.15 PSEC-1

1. Cryptography

1.1 Technical Overview

PSEC-1 is a public key cryptosystem for confidentiality purposes based on the elliptic curve discrete logarithm problem (ECDLP). Proposed by NTT, PSEC-1 is a scheme in which the elliptic curve El Gamal cryptosystem as a primitive is transformed by the method described in Reference [F01].

Reference [F01] Fujisaki, E. and Okamoto, T.: How to Enhance the Security of Public-Key Encryption at Minimum Cost, Proc. of PKC '99, Springer-Verlag, LNCS 1560, pp. 53-68 (1999).

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

For PSEC-1, PSEC-2, and PSEC-3, the following two patents applications have been filed by the entry:

(1) Application number: 10-320172 Encryption and Decryption Devices for Public Key Cryptosystems Using Random Functions (2) Application number: 2000-32461 Storage Medium Storing Encryption Device and Method, Decryption Device and Method, and Cryptographic System and Programs

The patents will be licensed to others under exclusive, appropriate conditions. The entry says no related patents are being sought by other companies.

Web address at which the technical specifications of the entry are available: http://info.isl.ntt.co.jp/

1.2 Technical Specifications

An outline of the technical specifications of PSEC-1 is described below.

PSEC-1 built in a prime field is explained here, though the scheme can be built in an extension field as well.

【Key Generation】

Input: Security parameter k

Output: The elliptic curves that constitute a pair of the public key {Fp, a, b, l, G, U, HID, lLEN, mLEN, rLEN, pLEN} and the secret key d are determined. The security parameter is the bit number of

185 CRYPTREC 2000

order l of base point G. The secret key and the public key are obtained as follows: U = dG The ID of the hash function used is HID.

【Encryption】

Input: Message m of length mLEN, public key {Fp, a, b, l, G, U, HID, lLEN, mLEN, rLEN, pLEN} Output: Ciphertexts c1 and c2

1. Random number r of rLEN length is generated. 2. h = H (m||r) 3. Q = hU, c1 = hG 4. c2 = (m||r) ⊕ B [xQ] m||r is given the padding described in IEEE1363.

186 CRYPTREC 2000

【Decryption】

Input: Ciphertexts c1 and c2, public key {Fp, a, b, l, G, U, HID, lLEN, mLEN, rLEN, pLEN} and secret key d Output: Message m of mLEN length

1. Q' = dc1 2. Supposing u = c2 ⊕ B [xQ'], u' is the low-order mLEN + rLEN bits of u. 3. Supposing h' = H (u'), it is checked whether c1 = h'G. 4. If it holds, the high-order mLEN bits of u' are outputted as message m.

2. Evaluation Results

2.1 Evaluation of Security

The security of primitives ultimately depends on the ECDLP. The method of determining elliptic curves and concrete parameters are not described in detail; only IEEE1363 is referred to.

The criteria for elliptic curve generation methods described in IEEE1363 are now inadequate.

The criteria for elliptic curve generation methods described in IEEE1363 are only that "the order of elliptic curves must be almost prime" to be secure against the Pollard ρ algorithm and the Pohlig-Hellman algorithm. Therefore, no judgments are made about the conditions against MOV or FR reduction attacks, against SSSA attacks, and against Weil Decent attacks in the case of elliptic curves in extension fields of characteristic two, and so forth.

A committee member says that PSEC-1 concerns a primitive encryption function and does not have provable security. Another committee member points out that in order that the scheme has provable security with the recommended parameters: k = |p| = 160, mLEN = 128, rLEN = 32 the condition: rLEN ≥ 140 is required. If this is right, mLEN + rLEN ≤ k

187 CRYPTREC 2000

mLEN ≤ 20 because

This means that the length of plaintext that can be handled securely in one cryptographic operation is extremely limited. Since no conclusion has been reached on the propriety of this argument in this evaluation, parameter selection needs to be studied further.

The reason is shown below.

When ε' represents the probability that the elliptic curve Diffie-Hellman sub-decision problem is broken, the probability that PSEC-1 is broken, ε, can be approximated as follows:

2 ⋅ q ε ≈ ε' + H 2rLEN

In order that ε ≈ ε' ≈ 2−80 or so using a 160-bit elliptic curve, rLEN needs to be 80 bits or over even if the number of times the hash function is used, qH, is on the order of polynomial time. Although it is mentioned that rLEN needs to be about 140, further study is necessary to determine whether this is true. 2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• In order to secure the strength equivalent to that of the RSA cryptosystem with a composite number length of 1,024 bits, each parameter PSEC-1 is 160 bits. • The data size of ESEC-1 is 128 bits. • One block of data to be encrypted is set at 128 bits (16 bytes) and is prepared in advance as a file. • If the size of the file prepared is larger than 16 bytes, the first one block is cut off from the top of the file for encryption.

(2) Parameter setting method

• Random number seeds are read as a file.

(3) Verification of the parameters used

188 CRYPTREC 2000

(National Institute of Standards and Technology of the United States) were given to the main program in the file format described later.

[Techniques Used in the Implementation]

[Characteristics and Measurement Parameters]

Scheme Implementation Security Evidence Other Measured Parameter and Character PSEC-1 Elliptic curve discrete Each PSEC-1 parameter The data size in PSEC-1 for evaluation is 128 bits. logarithm problem is 160 bits. Elliptic curve parameters are required. Results of Equivalent to RSA 1024 calculations by other methods or elliptic curve bits. parameters, etc. made public by the NIST (National Institute of Standards and Technology of the U.S.) were given to the main program. The free multiple length arithmetic library GNU MP 3.1.1 was used.

[System Parameter Generation]

• Since system parameters were generated in advance, this was not measured this time.

[Key Pair Generation]

• Random number generation method: First, random state variables were initialized by the GNU MP 3.1.1 function gmp_randinit (gmp_randstate_t state, gmp_randalg_t alg, ...). The default algorithm of GNU MP (GMP_RAND_ALG_DEFAULT) was specified as the random number generation algorithm. Next, the function gmp_randseed (gmp_randstate_t state, mpz_t seed) was used to set the seeds read from an external file in the random state variables. Next, random numbers were generated using the function mpz_urandomb (mpz_t rop, gmp_randstate_t state, unsigned long int n).

[Key pair generation speed]

Scheme Measured Average Execution Speed Remarks PSEC-1 11.3 ms None

[Encryption]

• Padding: Not necessary

189 CRYPTREC 2000

• Hash function: SHA-1 was used.

[Encryption speed]

Scheme Measured Average Execution Speed Remarks PSEC-1 24.0 ms None

[Decryption speed]

Scheme Measured Average Execution Speed Remarks PSEC-1 24.1 ms None

[Code size (reference value)]

Scheme Measured Code Size Remarks PSEC-1 189,334 byte C language (Intel C/C++) source code size

190 CRYPTREC 2000

4.4.16 PSEC-2

1. Cryptography

1.1 Technical Overview

PSEC-2 is a public key cryptosystem for confidentiality purposes based on the elliptic curve discrete logarithm problem (ECDLP). Proposed by NTT, PSEC-2 is a scheme in which the elliptic curve El Gamal cryptosystem as a primitive is transformed by the method described in Reference [F02].

Reference [F02] Fujisaki, E. and Okamoto, T.: Secure Integration of Asymmetric and Symmetric Encryption Schemes, Proc. of Crypto '99, Springer-Verlag, LNCS 1666, pp. 535-554 (1999).

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

For PSEC-1, PSEC-2, and PSEC-3, the two patents applications shown below have been filed by the entry. The patents will be licensed to others under exclusive, appropriate conditions.

The entry says no related patents are being sought by other companies.

Web address at which the technical specifications of the entry are available: http://info.isl.ntt.co.jp/

1.2 Technical Specifications

An outline of the technical specifications of PSEC-2 is described below. PSEC-2 built in a prime field is explained here, though the scheme can be built in an extension field as well.

【Encryption】

Input: Message m of length mLEN, public key {Fp, a, b, l, G, U, HID, lLEN, mLEN, rLEN, pLEN} Output: Ciphertexts c1, c2, and c3

1. Random number r of rLEN length is generated.

191 CRYPTREC 2000

2. h1 = H1 (r||m), h2 = H2 (r) 3. Q = h1U, c1 = h1G 4. c2 = r ⊕ B [xQ] 5. c3 = SymEnc (h2, m)

【Decryption】

Input: Ciphertexts c1, c2, and c3, public key {Fp, a, b, l, G, U, HID, lLEN, mLEN, rLEN, pLEN}, and secret key d Output: Message m of mLEN length

1. Q' = dc1 2. Supposing u = c2 ⊕ B [xQ'], r' is the low-order rLEN bits of u.

3. Supposing h1' = H1 (r'||m) and h2' = H2 (r'), it is checked whether c1 = h1'G. 4. If it holds, SymDec (h2', c3) is outputted as a decrypted message.

2. Evaluation Results

2.1 Evaluation of Security

Primitives are the same as those of PSEC-1, and so is the security.

Assuming the computational complexity of the elliptic curve Diffie-Hellman problem and using symmetric ciphers secure against passive attacks, PSEC-2 has the provable security of being semantically secure against adaptive chosen ciphertext attacks under the random oracle model. However, it is pointed out that in order to draw sufficient security from the proof, the following conditions need to be satisfied: hLEN must not be far less than k − 1. rLEN must be sufficiently close to qLEN.

The proposer's Specification only prescribes the following: hLEN ≤ k, rLEN ≤ qLEN

Since no conclusion has been reached on the propriety of this argument in this evaluation, parameter selection needs to be studied further.

192 CRYPTREC 2000

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• In order to secure the strength equivalent to that of the RSA cryptosystem with a composite number length of 1,024 bits, each parameter PSEC-2 is 160 bits. • The data size of ESEC-2 is 128 bits. • One block of data to be encrypted is set at 128 bits (16 bytes) and is prepared in advance as a file. • If the size of the file prepared is larger than 16 bytes, the first one block is cut off from the top of the file for encryption.

(2) Parameter setting method

• Random number seeds are read as a file.

(3) Verification of the parameters used

• This cryptosystem requires elliptic curve parameters as system parameters (non-key parameters required for scheme processing). No such parameters were generated. Instead, results of calculations by other methods or elliptic curve parameters, etc. made public by the NIST (National Institute of Standards and Technology of the United States) were given to the main program in the file format described later.

[Techniques Used in the Implementation]

193 CRYPTREC 2000

[Characteristics and Measurement Parameters]

Scheme Implementation Security Evidence Other Measured Parameter and Character PSEC-2 Elliptic curve discrete Each PSEC-2 parameter The data size in PSEC-2 for evaluation is 128 bits. logarithm problem is 160 bits. Elliptic curve parameters are required. Results of Equivalent to RSA 1024 calculations by other methods or elliptic curve bits. parameters, etc. made public by the NIST (National Institute of Standards and Technology of the U.S.) were given to the main program. The free multiple length arithmetic library GNU MP 3.1.1 was used.

[System Parameter Generation]

• Since system parameters were generated in advance, this was not measured this time.

[Key Pair Generation]

[Key pair generation speed]

Scheme Measured Average Execution Speed Remarks PSEC-2 11.8 ms None

[Encryption]

• Padding: Not necessary • Hash function: SHA-1 was used.

[Encryption speed]

Scheme Measured Average Execution Speed Remarks PSEC-2 24.2 ms None

[Decryption speed]

Scheme Measured Average Execution Speed Remarks PSEC-2 24.6 ms None

194 CRYPTREC 2000

[Code size (reference value)]

Scheme Measured Code Size Remarks PSEC-2 202,333 byte C language (Intel C/C++) source code size

195 CRYPTREC 2000

4.4.17 PSEC-3

1. Cryptography

1.1 Technical Overview

PSEC-3 is a public key cryptosystem for confidentiality purposes based on the elliptic curve discrete logarithm problem (ECDLP). Proposed by NTT, PSEC-3 is a scheme in which the elliptic curve El Gamal cryptosystem as a primitive is transformed by the method described in Reference [OP].

Reference [OP] Okamoto, T. and Pointcheval, D.: OCAC: an Optimal Conversion for Asymmetric Cryptosystems, manuscript (2000)

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

For PSEC-1, PSEC-2, and PSEC-3, the two patents applications shown below have been filed by the entry. The patents will be licensed to others under exclusive, appropriate conditions.

The entry says no related patents are being sought by other companies. Web address at which the technical specifications of the entry are available: http://info.isl.ntt.co.jp/

1.2 Technical Specifications

An outline of the technical specifications of PSEC-3 is described below.

PSEC-3 built in a prime field is explained here, though the scheme can be built in an extension field as well.

【Key Generation】

Input: Security parameter k

Output: The elliptic curves that constitute a pair of the public key {Fp, a, b, l, G, U, H1ID, H2ID, SEID, lLEN, H1LEN, H2LEN, rLEN, pLEN} and the secret key d are determined. The security

196 CRYPTREC 2000

parameter is the bit number of order l of base point G. The secret key and the public key are obtained as follows: U = dG The ID of hash function H1 is H1ID, that of hash function H2 is H2ID, and that of secret key ciphers SymEnc is SEID.

【Encryption】

Input: Message m of length mLEN, public key {Fp, a, b, l, G, U, H1ID, H2ID, SEID, lLEN, H1LEN, H2LEN, rLEN, pLEN} Output: Ciphertexts c1, c2, c3, and c4

1. Random numbers u and r of pLEN lengths are generated. 2. Q = rU, c1 = rG 3. c2 = u ⊕ B [xQ] 4. c3 = SymEnc (H2 (u), m) 5. c4 = H1 (xc1||yc1||c2||c3||u||m)

197 CRYPTREC 2000

【Decryption】

Input: Ciphertexts c1, c2, c3, and c4, public key {Fp, a, b, l, G, U, H1ID, H2ID, SEID, lLEN, H1LEN, H2LEN, rLEN, pLEN}, and secret key d Output: Message m of mLEN length

1. Q' = dc1 2. u' = c2 ⊕ B [xQ] 3. m' = SymEnc (H2 (u'), c3) 4. It is checked whether c4 = H1 (xc1||yc1||c2||c3||u'||m') holds. 5. If it holds, m' is outputted as a decrypted message.

2. Evaluation Results

2.1 Evaluation of Security

Primitives are the same as those of PSEC-1, and so is the security.

Assuming the computational complexity of the elliptic curve Gap-Diffie-Hellman problem and using symmetric ciphers secure against passive attacks, PSEC-3 has the provable security of being semantically secure against adaptive chosen ciphertext attacks under the random oracle model. However, since the elliptic curve Gap-Diffie-Hellman problem has not proposed only recently, this security needs to be studied further.

It is also said that in order to draw sufficient security from the proof, it is necessary to clearly specify the bit sizes of parameters u and r. Since no conclusion has been reached on the propriety of this argument in this evaluation, parameter selection needs to be studied further.

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• In order to secure the strength equivalent to that of the RSA cryptosystem with a composite number length of 1,024 bits, each parameter PSEC-3 is 160 bits. • The data size of ESEC-3 is 128 bits.

198 CRYPTREC 2000

• One block of data to be encrypted is set at 128 bits (16 bytes) and is prepared in advance as a file. • If the size of the file prepared is larger than 16 bytes, the first one block is cut off from the top of the file for encryption.

(2) Parameter setting method

• Random number seeds are read as a file.

(3) Verification of the parameters used

199 CRYPTREC 2000

[Techniques Used in the Implementation]

[Characteristics and Measurement Parameters]

Scheme Implementation Security Evidence Other Measured Parameter and Character PSEC-3 Elliptic curve discrete Each PSEC-3 parameter The data size in PSEC-3 for evaluation is 128 bits. logarithm problem is 160 bits. Elliptic curve parameters are required. Results of Equivalent to RSA 1024 calculations by other methods or elliptic curve bits. parameters, etc. made public by the NIST (National Institute of Standards and Technology of the U.S.) were given to the main program. The free multiple length arithmetic library GNU MP 3.1.1 was used.

[System Parameter Generation]

• Since system parameters were generated in advance, this was not measured this time.

[Key Pair Generation]

[Key pair generation speed]

Scheme Measured Average Execution Speed Remarks PSEC-3 11.5 ms None

[Encryption]

• Padding: Not necessary • Hash function: SHA-1 was used.

[Encryption speed]

200 CRYPTREC 2000

Scheme Measured Average Execution Speed Remarks PSEC-3 22.9 ms None

[Decryption speed]

Scheme Measured Average Execution Speed Remarks PSEC-3 12.0 ms None

[Code size (reference value)]

Scheme Measured Code Size Remarks PSEC-3 196,986 byte C language (Intel C/C++) source code size

201 CRYPTREC 2000

4.4.18 DH

1. Cryptography

1.1 Technical Overview

DH is a public key cryptosystem to realize a key sharing function. It was proposed by W. Diffie and M. E. Hellman in 1976.

Paper published in 1976: "New directions in cryptography," IEEE Trans. Information Theory, vol. IT-22, pp. 644-654, 1976.

Intellectual property rights

(Proposers' patents and their handling)

Diffie-Hellman patent (U.S. Patent Number 4,200,770)

1.2 Technical Specifications

(1) Common system parameters are set.

p: A prime number is generated.

* g ∈ Z p : A primitive element is sought. The order of g is l. (p, l, g) are common system parameters.

(2) Initialization by user A

xA (0 < xA < l): The result of random selection is used as a secret key.

xA yA = g (mod p) is calculated to obtain a public key.

(3) Initialization by user B

xB (0 < xB < l): The result of random selection is used as a secret key.

xB yB = g (mod p) is calculated, and yB is used as a public key.

(4) Key sharing

xA xBxA Processing by A: K = yB (mod p) = g (mod p)

xB xAxB Processing by B: K = yA (mod p) = g (mod p)

Thus K is shared.

202 CRYPTREC 2000

2. Evaluation Results

2.1 Evaluation of Security

(a) The scheme described in the processing section is a very simple basic type. Since the Diffie-Hellman scheme has many variations of protocol, it is necessary to evaluate each variation separately. (Reference: Protocols in actual use include RFC2631, ISO/IS11770-3, Oakley, and PGP.) Only the basic scheme was submitted for evaluation this year.

(b) When only passive attacks are assumed, the basic part of the secret sharing protocol results in the Diffie-Hellman problem. However, in the sense of being indistinguishable from a random bit string, the basic part results in the decision Diffie-Hellman problem if, for example, the range is limited. A key derivation function that is indistinguishable form a random bit string should most properly be used.

(c) Various factors affect the security of schemes in which shared secrets are used as session keys. Since there are an enormous number of combinations of these factors, it is difficult to make a comprehensive evaluation of each of the combinations. The following factors will have to be considered, for example:

1) Whether a key pair is fixed or temporary (static or ephemeral)? 2) Whether the correspondence between the public key and an entity is guaranteed (nocert or cert)? Whether it is guaranteed that an entity has a corresponding secret key (strongcert)? 3) Whether the public key is signed at the time of exchange (unsigned or signed)?

(d) There are problems, such as those mentioned in the next paragraph, in using in the form described in the preceding section a scheme in which shared secrets are used as session keys. For actual use, therefore, it is at least required to provide a means of guaranteeing a link between a key and an entity and to make ephemeral a public key if it is used as a session key.

(e) Problematic combinations and concrete examples of attacks are described below.

1) Cases in which both parties' keys are fixed (static): Fixed-session-key attack: The session key is fixed. Therefore, when it is used in counter mode, the same Vernam pad is used in every session, thus leading to the disclosure of secrets.

2) Cases in which the link between the secret key and the public key is not guaranteed (not strongcert): Unknown key-share attacks: The attacker pretends that a user's public key is his own public key, thus communicating with another user as if the first user is communicating.

203 CRYPTREC 2000

3) Other cases:

− Captured session key attacks: If when at least either key is a fixed key, a session key leaks, the same key will be used continuously. − Key-translate attacks: In the case of nocert/unsigned, the multiplication of a key by any number causes different keys to be shared. − Reveal $ attacks: If a secret coin (information that needs to be kept confidential) leaks in operations of a public workstation or the like, it will affect other secret information as well (absence of forward secrecy). − Attacks intrinsic 2-flow AKEs (Authenticated Key-Exchange protocols): If there are only two flows and if the second flow is independent of the first one, it is a strong-corruption model, which has such problems as the absence of forward secrecy and the absence of A-to-B/B-to-A authentication.

(f) Some problems can be solved by adding improvements such as using a signature to the public key in combination.

2.2 Software Implementation Evaluation

With respect to DH, the Committee judged that it was not necessary to evaluate it for software implementability partly because it should be evaluated in other respects and partly because it had already been implemented widely.

204 CRYPTREC 2000

4.4.19 ECDHS in SEC1

1. Cryptography

1.1 Technical Overview

ECDHS in SEC1 is a public key cryptosystem formulated by the SECG (Standards for Efficient Cryptography Group) in 1999. It is a key sharing scheme using elliptic curves.

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

• 5,761,305: Key Agreement and Transport Protocol with Implicit Signatures, issued June 2, 1998. This patent includes versions of the MQV protocols.

• 5,787,028: Multiple Bit Multiplier, issued July 28, 1998.

• 5,889,865: Key Agreement and Transport Protocol with Implicit Signatures, issued March 30, 1999. This patent includes versions of the MQV protocols.

• 5,896,455: Key Agreement and Transport Protocol with Implicit Signatures, issued April 20, 1999. This patent includes versions of the MQV protocols.

The above proposers' patents and copyrights are licensed by the proposers without discrimination of licensees under reasonable conditions.

For details, visit the Web sites of the patentees and the SECG's Web site (www.secg.org). http://www.secg.org/patent_policy.htm http://www.secg.org/collateral/certicom_secg_patent.pdf

Web address at which the technical specifications of the entry are available: http://www.labs.fujitsu.com/theme/crypto/public_key.html http://www.secg.org/drafts.htm

205 CRYPTREC 2000

1.2 Technical Specifications

The key sharing scheme is outlined below.

Elliptic curve parameter (p, a, b, G, l) This shows that there is a rational point G of prime order l on the elliptic curve y2 = x3 + ax + b

over the prime field Fp.

【Initialization】

1. Users U and V generate an elliptic curve parameter (p, a, b, G, l) or (k, f, a, b, G, l).

2. Users U and V generate a pair of secret key d and public key Q belonging to the above elliptic curve parameter, respectively.

User U: dU ← an integer l not less than 1 and not greater than l-1, QU ← dU · G

User V: dV ← an integer l not less than 1 and not greater than l-1, QV ← dV · G

【Key Sharing】

Users U and V share secret information K as follows:

User U: z ← x (dU · QV), K ← Hash (z||SharedInfo)

User V: z ← x (dV · QU), K ← Hash (z||SharedInfo)

In the above, x (Q) denotes the x coordinate of a point Q on an elliptic curve. ShareInfo is an option.

1.3 Other

ECDHS in SEC1 is also described in IEEE P1363.

2. Evaluation Results

2.1 Evaluation of Security

2.1.1 Security of cryptographic primitives

The basic security of ECDHS in SEC1 is based on the difficulty of the discrete logarithm problem on elliptic curves.

206 CRYPTREC 2000

Various attacks are known against the discrete logarithm problem on elliptic curves. In the case of ECDHS in SEC1, elliptic curve parameters in various sizes, to which no known attack can be applied, are explicitly given in SEC2 documents. (These are recommended parameters, not prohibited to use other parameters.) These elliptic curves consist of elliptic curves randomly selected in a verifiable manner and elliptic curves called Koblitz curves. Koblitz curves are included because of its high performance and its traditional use. However, since they are within a very limited class, it should be noted that a new attack against them could appear.

2.1.2 Security of the Scheme

ECDHS in SEC1 is a Diffie-Hellman key sharing scheme using elliptic curves. It is the most basic key sharing scheme. No major problems are pointed out against passive attacks. Against active attacks, however, it is not secure and does not satisfy forward-secrecy, either. In particular, care should be taken when fixed keys are used as a pair of secret key d and public key Q.

When a key sharing scheme is actually used, it is necessary to think of active attackers. Therefore, a combination of this scheme and a digital signature or the like should be considered. In fact, by combining ECDHS primitive in SEC1 and a digital signature, several researchers have proposed key sharing scheme with provable security against active attackers and with a forward-secrecy.

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

(2) Parameter setting method

• Elliptic curve parameters are read from a file for use. • The software is implemented in a way not dependent on parameters.

(3) Verification of the parameters used

• Since the two coefficients of an elliptic curve are related by (uncontrollable) SHA-1 outputs, it

207 CRYPTREC 2000

is randomly verifiable that the parameters have been selected freely. • As in the X9.62 specifications, SHA-1 inputs are also described as part of the parameters. • It has been verified that special attacks are ineffective.

(4) Parameter size variations

[Techniques Used in the Implementation]

[Characteristics and Measurement Parameters]

Security Implementation Scheme Measured Other Evidence Parameter and Character ECDHS in SEC1 ECDLP Equivalent to One of the parameters recommended in the SEC1 160-bit prime field RSA 1,024 bits specifications. Based on the ANSI X9.62 specifications. It is randomly verifiable that the parameters have been ECDHS in SEC1 Equivalent to selected freely. 163-bit field of RSA 1,024 bits As in the X9.62 specifications, SHA-1 inputs are also characteristic 2 described as part of the parameters. It has been verified that special attacks are ineffective. High-speed techniques applicable to any parameters are used. The software is implemented in a way not dependent on parameters.

[System Parameter Generation]

• Since the generation of elliptic curve parameters is based on a probabilistic algorithm, it is difficult to determine a precise anticipated processing time. • According to an advance experiment, the processing time in the case of a 160-bit elliptic curve is within 10 minutes on the average with the 700 MHz Pentium III.

Measurement results

208 CRYPTREC 2000

Scheme Measured Average Execution Speed Remarks ECDHS 160-bit prime field 6.0 min Three elliptic curve parameters were generated in 18 minutes.

[Initialization/Termination]

Measurement results

Scheme Measured Average Execution Time Remarks ECDHS in SEC1 PC/PF 0.004 ms None 160-bit prime field PI 13.525 ms None PV 60.438 ms None WC/WF 0.032 ms None ECDHS in SEC1 PC/PF 0.004 ms None 163-bit field of characteristic 2 PI 15.283 ms None PV 43.917 ms None WC/WF 0.032 ms None

PC/PF: An elliptic curve parameter area is acquired/released.

PI: The parameters read from a file are set in the area.

WC/WF: The work area is acquired/released.

[Key Pair Generation]

(1) Primarity test conditions

• No test is necessary for system reasons.

(2) Random number generation method

• Fujitsu's original pseudo-random number generation algorithm. DES/SHA-1, etc. are used.

(3) Measurement results

• Key pair verification is not necessary if the keys are generated by the user.

[Key pair generation speed]

209 CRYPTREC 2000

Average Execution Scheme Measured Remarks Time ECDHS in SEC1 1.9 ms Key pair generation. 160-bit prime field Key pair verification, which is not necessary if the keys are 5.8 ms generated by the user. ECDHS in SEC1 3.2 ms Key pair generation. 163-bit field of characteristic 2 Key pair verification, which is not necessary if the keys are 8.0 ms generated by the user.

210 CRYPTREC 2000

[Key sharing]

(1) Padding

• Not used.

(2) Hash function

• Not used.

(3) Measurement results

[Key sharing (one side)]

Scheme Measured Average Execution Time Remarks ECDHS in SEC1 6.6 ms None 160-bit prime field ECDHS in SEC1 8.8 ms None 163-bit field of characteristic 2

(4) Other

• KDF: ANSI-X9.63-KDF with SHA-1 • Key sharing primitive: standard elliptic curve Diffie-Hellman primitive

[Code size (reference value)]

Scheme Measured Code Size Remarks ECDHS in SEC1 356,352 byte Size of executable test program for performance measurement

211 CRYPTREC 2000

4.4.20 ECMQVS in SEC1

1. Cryptography

1.1 Technical Overview

ECMQVS in SEC1 is a public key cryptosystem formulated by the SECG (Standards for Efficient Cryptography Group) in 1999. It is a key sharing scheme using elliptic curves.

Intellectual property rights (as stated in the entry documents)

(Proposers' patents and their handling)

• 5,761,305: Key Agreement and Transport Protocol with Implicit Signatures, issued June 2, 1998. This patent includes versions of the MQV protocols.

• 5,787,028: Multiple Bit Multiplier, issued July 28, 1998.

• 5,889,865: Key Agreement and Transport Protocol with Implicit Signatures, issued March 30, 1999. This patent includes versions of the MQV protocols.

• 5,896,455: Key Agreement and Transport Protocol with Implicit Signatures, issued April 20, 1999. This patent includes versions of the MQV protocols.

The above proposers' patents and copyrights are licensed by the proposers without discrimination of licensees under reasonable conditions.

For details, visit the Web sites of the patentees and the SECG's Web site (www.secg.org). http://www.secg.org/patent_policy.htm http://www.secg.org/collateral/certicom_secg_patent.pdf

Web address at which the technical specifications of the entry are available: http://www.labs.fujitsu.com/theme/crypto/public_key.html http://www.secg.org/drafts.htm

212 CRYPTREC 2000

1.2 Technical Specifications

The key sharing scheme is outlined below.

Elliptic curve parameter (p, a, b, G, l) This shows that there is a rational point G of prime order l on the elliptic curve y2 = x3 + ax + b

over the prime field Fp.

213 CRYPTREC 2000

【Initialization】

1. Users U and V generate an elliptic curve parameter (p, a, b, G, l) or (k, f, a, b, G, l).

2. Users U and V generate two pairs of secret key d and public key Q belonging to the above elliptic curve parameter, respectively.

User U: d1,U ← an integer l not less than 1 and not greater than l-1, Q1,U ← d1,U · G

d2,U ← an integer l not less than 1 and not greater than l-1, Q2,U ← d2,U · G

User V: d1,V ← an integer l not less than 1 and not greater than l-1, Q1,V ← d1,V · G

d2,V ← an integer l not less than 1 and not greater than l-1, Q2,V ← d2,V · G

【Key Sharing】

Users U and V share secret information K as follows:

User U:

1. s ← d2,U + h (Q2,U) · d1,U (mod l)

2. P ← s × (Q2,V + h (Q2,V) · Q1,V), z ← x (P) 3. K ← Hash (z||SharedInfo)

User V:

1. s' ← d2,V + h(Q2,V) · d1,V (mod l)

2. P ← s' × (Q2,U + h (Q2,U) · Q1,U), z ← x (P) 3. K ← Hash (z||SharedInfo)

In the above, x (Q) denotes the x coordinate of a point Q on an elliptic curve, and h (Q) is an integer calculated as follows:

1. x' ← x (Q) (mod 2Ceiling ((log l)/2)) 2. h (Q) ← x' + 2Ceiling ((log l)/2)

Here, Ceiling (m) represents the smallest integer equal to or larger than m. ShareInfo is an option.

214 CRYPTREC 2000

1.3 Other

ECMQVS in SEC1 is also described in IEEE P1363.

2. Evaluation Results

2.1 Evaluation of Security

2.1.1 Security of cryptographic primitives

The basic security of ECMQVS in SEC1 is based on the difficulty of the discrete logarithm problem on elliptic curves.

Various attacks are known against the discrete logarithm problem on elliptic curves. In the case of ECMQVS in SEC1, elliptic curve parameters in various sizes, to which no known attack can be applied, are explicitly given in SEC2 documents. (These are recommended parameters, not prohibited to use other parameters.) These elliptic curves consist of elliptic curves randomly selected in a verifiable manner and elliptic curves called Koblitz curves. Koblitz curves are included because of their high performance and their traditional use. However, since they are within a very limited class, it should be noted that a new attack against them could appear.

2.1.2 Security of the Scheme

No major problem is pointed out against passive attacks. However, there are problems in its security against active attacks. ECMQVS in SEC1 uses two pairs of secret key and public key. It is apparently assumed that fixed keys are used in one of the pairs and temporary keys in the other.(Note) Although this assumption apparently increases the security of the scheme as compared with ECDHS in SEC1, its security against active attacks is not proved at this point in time. In fact, while an assumption called an "LDH assumption" is required (not known whether it is sufficient) in order to prove the security of ECMQVS in SEC1, some experts claims the validity of the LDH assumption is not clear.

When a key sharing scheme is actually used, it is necessary to think of active attackers. Therefore, a combination of this scheme and a digital signature or the like should be considered. In fact, by combining ECMQVS primitive in SEC1 and a digital signature, several researchers have proposed key sharing scheme with provable security against active attackers and with a forward-secrecy.

Note: However, the Specification has no such description. Care should be taken not to use fixed keys in both pairs.

215 CRYPTREC 2000

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

(2) Parameter setting method

• Elliptic curve parameters are read from a file for use. • The software is implemented in a way not dependent on parameters.

(3) Verification of the parameters used

(4) Parameter size variations

[Techniques Used in the Implementation]

216 CRYPTREC 2000

[Characteristics and Measurement Parameters]

Security Implementation Scheme Measured Other Evidence Parameter and Character ECMQVS in SEC1 ECDLP Equivalent to One of the parameters recommended in the SEC1 160-bit prime field RSA 1,024 bits specifications. Based on the ANSI X9.62 specifications. It is randomly verifiable that the parameters have been ECMQVS in SEC1 Equivalent to selected freely. 163-bit field of RSA 1,024 bits As in the X9.62 specifications, SHA-1 inputs are also characteristic 2 described as part of the parameters. It has been verified that special attacks are ineffective. Optimization can further increase speed. High-speed techniques applicable to any parameters are used. The software is implemented in a way not dependent on parameters.

[System Parameter Generation]

Measurement results

Scheme Measured Average Execution Speed Remarks ECMQVS 160-bit prime field 6.0 min Three elliptic curve parameters were generated in 18 minutes.

[Initialization/Termination]

Measurement results

Scheme Measured Average Execution Time Remarks ECMQVS in SEC1 PC/PF 0.004 ms None 160-bit prime field PI 13.525 ms None PV 60.438 ms None WC/WF 0.032 ms None ECDHS in SEC1 PC/PF 0.004 ms None 163-bit field of characteristic 2 PI 15.283 ms None PV 43.917 ms None WC/WF 0.032 ms None

PC/PF: An elliptic curve parameter area is acquired/released.

PI: The parameters read from a file are set in the area.

217 CRYPTREC 2000

by the order becomes a point at infinity, etc.

WC/WF: The work area is acquired/released.

[Key Pair Generation]

(1) Primarity test conditions

• No test is necessary for system reasons.

(2) Random number generation method

• Fujitsu's original pseudo-random number generation algorithm. DES/SHA-1, etc. are used.

(3) Measurement results

• Key pair verification is not necessary if the keys are generated by the user.

[Key pair generation speed]

Average Execution Scheme Measured Remarks Time ECMQVS in SEC1 1.9 ms Key pair generation. 160-bit prime field Key pair verification, which is not necessary if the keys are 5.8 ms generated by the user. ECMQVS in SEC1 3.2 ms Key pair generation. 163-bit field of characteristic 2 Key pair verification, which is not necessary if the keys are 8.0 ms generated by the user.

[Key sharing]

(1) Padding

• Not used.

(2) Hash function

• Not used.

(3) Measurement results

[Key sharing (one side)]

Scheme Measured Average Execution Time Remarks ECMQVS in SEC1 13.2 ms None

218 CRYPTREC 2000

160-bit prime field ECMQVS in SEC1 16.9 ms None 163-bit field of characteristic 2

(4) Other

• KDF: ANSI-X9.63-KDF with SHA-1

[Code size (reference value)]

Scheme Measured Code Size Remarks ECMQVS in SEC1 356,352 byte Size of executable test program for performance measurement

219 CRYPTREC 2000

4.4.21 HDEF-ECDH

1. Cryptography

1.1 Technical Overview

HDEF-ECDH is a cryptosystem proposed by A. Miyaji and others at a meeting of the Information Security Research Group of the Institute of Electronics, Information, and Communication in 1999. It is an integrated cryptosystem realizing key sharing based on the security evidence of the ECDLP.

References

A. Miyaji and H. Shizuya, "Integration of DLP-based cryptosystems," IEICE Japan Technical. Rep., bf ISEC99-48 (1999-09), 73-80.

(Proposers' patents and their handling)(as stated in the entry documents)

On elliptic curves, the following patent applications have been filed:

(1) Patent Application 2000-126692 Title of the invention: Integration device, details (filing date: March 23, 2000) (2) Patent Application 2000-243434 Title of the invention: Elliptic curve generator, details (filing date: July 6, 2000)

(Related patents)

The patent on the DH key sharing method used has run out. It is considered that there is no possibility of infringing on other companies' patents.

• Related patents held by the proposer

Web address at which the technical specifications of the entry are available: http://grampus.jaist.ac.jp:8080/miyaji-lab/IPA/index.html

1.2 Technical Specifications

(1) Elliptic curve parameter generation specifications

1. An integer meeting the condition d ≡ 19 (mod 24) is selected.

2 d + 9 2. Against integer l, it is assumed that p = dl + dl + . 4

3. If either p or p − 2 is a composite number, the operation returns to step 1.

220 CRYPTREC 2000

4. Class polynomial Pd (x) that is determined by d is sought.

5. Solution j0 to Pd (x) ≡ 0 (mod p) is sought.

6. Elliptic curve { E j0 } on Fp in where j0 is j-invariant is composed. Here, E j0 represents the following elliptic curve: 2 3 E j0 : y = x + a j0 x + b j0

3 j0 2 j0 a j0 = (mod p), b j0 = (mod p) 1728 − j0 1728 − j0

{ E j0 } represents a group of elliptic curves of the same type. 2 3 7. For E: y = x + ax + b ∈ { E j0 }, take #E (Fp) = p − 2 and a = −3 or smaller. − An algorithm when d is fixed at 403 is described. − Recommended bit lengths of p are 160 or over, especially 160, 192, or 224. − The recommended prime number type is p = 2u − c (c: small integer).

(2) Key sharing scheme

1) Initialization by user A

EA/FPA : Elliptic curve with prime order

GA ∈ EA (FPA ): A generation source is selected at random.

dA (0 < dA < PA − 2): The result of random selection is used as a secret key.

UA = dAGA is calculated.

(EA/FPA , UA, GA): This is used as a public key.

2) Initialization by user B

Likewise,

(EB/FPB, UB, GB): This is used as a public key.

3) When the same curve is used:

Processing by A: K = dAUB = dAdBG

Processing by B: K = dBUA = dBdAG Thus K is shared.

4) When different curves are used:

Processing by A:

rA (0 < rA < pB − 2): The result of random selection is used as a secret key.

RA = rAGB is calculated.

RA is sent to user B.

221 CRYPTREC 2000

Processing by B:

rB (0 < rB < pA − 2): The result of random selection is used as a secret key.

RB = rBGA is calculated.

RB is sent to user A.

Processing by A: KA = dARB = dArBGA, KB = rAUB = rAdBGB

Processing by B: KB = dBRA = dBrAGB, KA = rBUA = rBdAGA

Thus KA and KB are shared.

Actual shared keys may be values that can be calculated from KA and KB. An example is an exclusive OR of their x coordinates.

2. Evaluation Results

2.1 Evaluation of Security

(1) Security of the parameters proposed a) No known efficient attacking methods are effective. b) These are elliptic curves of a very limited class in which trace is 3 and the discriminant has a small CM field. There are no efficient attacking methods at present. However, since these elliptic curves are of a limited class, it should be noted that an attacking method against this particular class can appear. c) As a reason for generating a very limited class of elliptic curves, the proposer says, "If it becomes possible to generate elliptic curves easily, it will enable each user to generate different elliptic curves." The time required for generation is estimated at 406,582 × primarity testing time. No concrete experimental values are shown, and no software implementation evaluation was conducted, either. No actual verification data is presented to show how it is easy to generate elliptic curves. d) The proposer argues that from the viewpoint of security, it is desirable that each user use different elliptic curves but does not clearly state the reason. Unless this reason is clarified, it is not clear what significance there is in using a very limited class of elliptic curves at the risk mentioned in (b) above. A further study is required for the propriety of the proposal.

(2) Security of the key sharing scheme a) The proposer has not made a detailed evaluation of the key sharing scheme. b) The proposed scheme has two versions: a basic version in which all users use the same elliptic curve

222 CRYPTREC 2000

and a modified version in which each user uses a different elliptic curve. Since the ECDH protocol has many variations of protocol, it is necessary to evaluate each variation separately. With respect to the modified version, the proposer argues that from the viewpoint of security, it is desirable that each user use different elliptic curves but does not clearly state the reason. A further study is required for the propriety of the proposal of the modified version. c) If only passive attacks are assumed, the basic version of the secret sharing protocol results in the Diffie-Hellman problem. However, when the x coordinate of a shared point is used, it is limited to the x for which x3 + ax + b mod p becomes a quadratic residue. Therefore, in the sense of being indistinguishable from a random |p| bit string, this results in the decision Diffie-Hellman problem in which x is limited to the above range. A key derivation function that is indistinguishable form a random bit string should most properly be used. d) Various factors affect the security of schemes in which shared secrets are used as session keys. In this scheme, these factors are not clearly mentioned. Since there are an enormous number of combinations of these factors, it is difficult to make a comprehensive evaluation of each of the combinations. The following factors will have to be considered, for example:

1) Whether a key pair is fixed or temporary (static or ephemeral)?

2) Whether the correspondence between the public key and an entity is guaranteed (nocert or cert)? Whether it is guaranteed that an entity has a corresponding secret key (strongcert)?

3) Whether the public key is signed at the time of exchange (unsigned or signed)? e) There are problems, such as those mentioned in the next paragraph, in using the scheme in which shared secrets are used as session keys in the form as described in the proposal. For actual use, therefore, it is at least required to provide a means of guaranteeing a link between a key and an entity and to make ephemeral a public key if it is used as a session key.

(f) 【In the case of the same curve parameters】 Problematic combinations and concrete examples of attacks are described below.

223 CRYPTREC 2000

3) Other cases: − Captured session key attacks: If when at least either key is a fixed key, a session key leaks, the same key will be used continuously. − Key-translate attacks: In the case of nocert/unsigned, the multiplication of a key by any number causes different keys to be shared. − Reveal attacks: If a secret coin (information that needs to be kept confidential) leaks in operations of a public workstation or the like, it with affect other secret information as well (absence of forward secrecy). − Attacks intrinsic 2-flow AKEs (Authenticated Key-Exchange protocols): If there are only two flows and if the second flow is independent of the first one, it is a strong-corruption model, which has such problems as the absence of forward secrecy and the absence of A-to-B/B-to-A authentication.

(g) 【In the case of different curve parameters】

1) In the case of the basic protocol: − Security against passive attacks results in the ECDDH (as a result of a modification of the key derivation function). − Nothing can be said about security against active attacks. − Forward secrecy has not been attained.

2) In the case of one-time keys (ephemeral): − Improvements can be made as in the case of the same parameters. − It is necessary to add a key confirmation flow in order to achieve mutual authentication.

(h) Some problems can be solved by adding improvements such as using a signature to the public key in combination.

2.2 Software Implementation Evaluation

[Implementation Specifications]

(1) Properties of the parameters used

• RSA cryptosystem of N = 1,024 bits (strength equal to or greater than signatures)

(2) Parameter setting method

• In the implementation of this object code, it is assumed that the key-sharing users use the same

224 CRYPTREC 2000

elliptic curve parameters. (That is, users A and B are supposed to select the same elliptic curve with prime order and the same base point.) • The scheme does not have codes to generate or read system parameters.

(3) Verification of the parameters used

• It has been verified that the elliptic curve parameters used are secure against MOV (FR) reduction attacks and SSSA attacks. For details, refer to the Self-Evaluation Report on HDEF-ECDH.

(4) Parameter size variations

• Only one type of parameter sizes, 160 bits, was actually measured.

(5) Parameter setting method

• The elliptic parameters defined in Chapter 3 of this Specification are held, and no setup operations, such as table initialization, are required.

(6) Verification of the parameters used

• Described in the Cryptographic Techniques Specifications.

(7) Parameter size variations

• Described in the Cryptographic Techniques Specifications.

225 CRYPTREC 2000

[Techniques Used in the Implementation]

• The base point is fixed in this object code, but a power method operation algorithm similar to arbitrary-point power method operations (combination of coded binary notation and the window method) is used. That is, even higher speeds can be expected in actual use because a fixed-point algorithm can be used. • Multiplication remainder operations in a defined field (160 × 160 -> 160 bits) are described in Assembler.

[Characteristics and Measurement Parameters]

Scheme Implementation Security Evidence Other Measured Parameter and Character HDEF-ECDH Elliptic curve discrete For equivalents of RSA It has been verified that the elliptic curve logarithm problem 1,024 bits or over, the parameters used are secure against MOV (FR) parameter size is 160 bits. reduction attacks and SSSA attacks. The base point is fixed in the evaluation code. A power method operation algorithm similar to arbitrary-point power method operations (combination of coded binary notation and the window method) is used. Multiplication remainder operations in a defined field (160 × 160 → 160 bits) are described in Assembler. Measurements were taken of the basic version. An arbitrary-point power method algorithm is used. Multiplication remainder operation assembler.

[System Parameter Generation]

• Since system parameter generation had been completed in advance, it was not performed in this evaluation.

[Key Pair Generation]

(1) Primarity testing conditions

• A random number 1 bit smaller than the bit size of the defined field was generated and was used as a secret key. • A public key was generated by multiplying the base point by a scalar value.

(2) Random number generation method

• Random numbers are required for key pair generation. • At this time, it is desirable to use random numbers that are highly precise and hard to predict. • This object code does not have its own pseudo-random number generation routine. Therefore,

226 CRYPTREC 2000

this object code uses rand (), a C standard function, to generate random numbers. • Highly secure pseudo-random number routines should be used when this scheme is applied to actual systems.

(3) Measurement results

[Key pair generation]

Scheme Measured Average Execution Speed Remarks HDEF-ECDH 1.5 ms One-side processing. Key size: 160 bits

227 CRYPTREC 2000

[Key sharing side processing]

(1) Padding

• Not used.

(2) Hash function

• SHA-1 is used.

(3) Measurement results

[Key sharing (one side)]

Scheme Measured Average Execution Speed Remarks HDEF-ECDH 1.8 ms Key size: 160 bits

[Parameters Used] p = 730 75081 86654 51459 52396 17144 99640 83306 20843 44321 Elliptic curve E (F(p)): y2 = x3 + ax + b a = −3 b = 145 65097 62508 47204 31616 18686 75773 20971 18776 24364

Base point G = (gx, gy), order q gx = 0 gy = 524 69857 95054 95094 28091 57543 77106 79925 14989 32020 q = 730 75081 86654 51459 52396 17144 99640 83306 20843 44319

[Code size (reference value)]

Scheme Measured Code Size Remarks HDEF-ECDH 73,758 byte Multiplication remainder operations in a defined field (160 × 160 → 160 bits) are described in Assembler. Others are described in C language.

228 CRYPTREC 2000

5. Evaluation of Symmetric Ciphers

Cryptographic techniques for symmetric ciphers were classified into three categories: 64-bit block cipher, 128-bit block cipher, and stream cipher and evaluated. The following table shows the cryptographic techniques evaluated. Section 5.1 briefly compares the cryptographic techniques within each category in terms of their characteristics, security, and performance of implementation. Section 5.2 describes these aspects of the individual ciphers in further detail. Note that the ciphers are listed in the alphabetical order.

Table 5.1 Symmetric cipher names

64-bit block ciphers CIPHERUNICORN-E, FEAL-NX, Hierocrypt-L1, MISTY1, Triple DES 128-bit block ciphers Camellia, CIPHERUNICORN-A, Hierocrypt-3, MARS, RC6, SC2000, Rijndael Stream ciphers MULTI-S01, TOYOCRYPT-HS1

5.1 Evaluation by Encryption Type

5.1.1 64-bit block ciphers

Five types — CIPHERUNICORN-E, FEAL-NX, Hierocrypt-L1, MISTY1, and Triple DES — were evaluated. We received evaluation applications for all the ciphers except Triple DES, which we added for evaluation. An evaluation overview, including Table 5.1.1, is included in this report, starting on the following page. The following parameters were evaluated.

Characteristics

This parameter includes the organization that is proposing the technique, the year it was announced, its structural characteristics, and characteristics such as the operations used in the data-randomization part. Note that for those techniques that use variable parameters, such as number of rounds, we have included the values recommended by the proposing organizations.

Security

229 CRYPTREC 2000

interpolation attacks, and algebraic methods such as SQUARE attack, as well as resistance against other attacks, such as related key attacks and mod n attacks, are described. The evaluation method for higher order differential and interpolation attacks looks for basic weaknesses of a cryptosystem from the algebraic viewpoint. When the number of rounds is large, an attack based on this method rarely causes a problem. However, the weaknesses uncovered here, if challenged with other attack methods, may affect the ultimate cipher strength. • Avalanche evaluation statistically captures how data is shuffled in each cryptosystem, and although it normally does not directly lead to cryptanalysis, it does provide a clue in looking for weaknesses in the partial function of a cipher.

Software (SW)-implementation evaluation

A cipher must be evaluated from both a security and an implementation standpoint by assuming how it will be used. Although e-Government’s requirements for encryption implementation are not yet clear, our SW-implementation evaluation assumed three types of environments: a PC environment that was considered 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 parts and the key schedule + data randomization parts. Hardware (HW)-implementation evaluation

The target device for evaluation was an ASIC library of 0.25- to 0.35-µm design rules, the hardware description language is Verilog-HDL, and a design compiler was used for circuit synthesis. Note that execution speed and gate size were merely estimated because the implementation architectures and optimization conditions were different. Therefore, although actual results will be affected greatly by the experience level of the person doing the implementation, execution speed and gate size can generally be expected to be improved (faster speed and smaller size).

Overall evaluation

The following table shows the overall evaluation results, which are summarized based on the security and implementation evaluation.

230 CRYPTREC 2000

Table 5.1.1 Overall evaluation results of symmetric ciphers (64-bit block ciphers)

Name Characteristics Overall evaluation CIPHERUNICORN-E NEC (1998) No security problem has so far been Feistel type, 16 rounds. The round function is complex. found. Consists of a main stream and a temporary key-generation Complex structure part to be expected to enhance security. makes accurate F function uses S-box as the basic component and consists evaluation difficult, of T, K, and Y functions. and thus continued Four types of 8x8 S-boxes. Designed based on inverse evaluation is needed. operations on GF(28) and has resistance against Belongs to a group differential/linear cryptanalysis. with slow processing Table look up, addition, EXOR, AND, and shift operation. speed. Designed with a round function structure to make significant correlation invisible from cipher-evaluation systems. FEAL-NX NTT (1990) FEAL-32X can be scientifically broken Feistel type, N rounds where N is an even number of 32 or and thus cannot be greater. Expanded keys EXOR as the initial and final recommended for processing. long-term use. Round function consists of four S functions.S function is Suitable for SW based on 8-bit operations. implementation for Addition, EXOR, cyclic shift operation. an 8-bit CPU. Suitable for SW implementation in an 8-bit CPU. Highly effective data shuffling structure is chosen, based on statistical evaluation. Key scheduling area of FEAL-N has been generalized. This cipher is at least 10 years old. Number of rounds has been increased in response to security evaluation. Hierocrypt-L1 Toshiba (2000) No security problem has so far been Recursive SPN structure, six rounds. Each round consists found. of two parallel XS functions and a P layer. Belongs to a group XS function has a structure in which a P layer is with fast processing sandwiched between four parallel S-boxes of two layers. speed. 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, EXOR, and AND. Achieves both security and computational efficiency using a recursive SPN structure. For the design of the P layer, the lower limit of the number of active S-boxes is guaranteed by the coding theory.

231 CRYPTREC 2000

Name Characteristics Overall evaluation MISTY1 Mitsubishi (1996) No security problem has so far been Feistel structure, eight rounds. FL function is inserted for found. every two rounds. Belongs to a group A modified Feistel structure is recursively used in the with fast processing internal structure of the round function. speed. Two types (7x7 and 9x9) of S-boxes. Designed based on power multiplication operations, and has resistance against differential/linear cryptanalysis. Low algebraic degree in consideration for HW implementation. Table look up, EXOR, AND, and OR. Provable security against differential/linear attacks. The origin of the KASUMI cipher for the next-generation mobile phones. Triple DES IBM (1979) There should not be (3-Key) any security problem Combination cipher that repeats DES three times. DES as long as a was standardized as FIPS in 1977. guarantee is provided DES is a Feistel type with 16 rounds. by FIPS (or an Eight types of 6x4 S-boxes.Selected from randomly equivalent). configured S-boxes using a certain evaluation standard. Table look up, EXOR, and cyclic shift operation. HW-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 security evaluation

Linear/differential attack resistance

Resistance against linear/differential attacks can be expressed as maximal linear/differential probability. MISTY1 and Hierocrypt-L1 guarantee security at this probability. MISTY1’s probability is 2-56 or lower with three rounds, which is considered sufficiently secure against linear and differential attacks. Hierocrypt-L1 guarantees a probability of 2-48 or less with two rounds, and this guarantee is called provable security against linear/differential attacks. Because it is difficult to determine the true value of the maximal linear/differential probability, maximal linear/differential characteristics probability is used as a corresponding index. The following methods are used for evaluating maximal characteristics probability: • A method that determines characteristics probability based on the maximal linear/differential probability of the components • A method that determines maximal characteristics probability through computer searches. Hierocrypt-L1 and CIPHERUNICORN-E are considered to offer the upper limit in characteristics probability. The former has been shown not to exceed a differential/linear characteristics probability of 2-90 in two rounds. The latter is difficult to analyze because its round function has a complex structure. Also, the upper limit of 12-round differential characteristics probability and 8-round linear characteristics

232 CRYPTREC 2000

probability has been shown to be lower than 2-64 when a truncated vector search is used for simplified round functions. The method that considers these characteristics probabilities of 64-bit block ciphers are 2-64 or lower to be the proof of security is called the practical security guarantee against linear/differential attacks. The ciphers for which maximal characteristics probability has been evaluated as a result of computer searches are DES and FEAL-NX. DES offers a differential characteristics probability of 2-54.1 and a linear characteristics probability of 2-44.9. Double DES, in which DES is repeated twice or more, is considered secure against linear/differential attacks. FEAL-NX offers a 31-round differential characteristics probability of 2-62 and a 25-round linear characteristics probability of 2-62.3. When under the attack, FEAL-32X can be scientifically broken with 299 computations. As explained previously, scientific linear/differential attack resistance is guaranteed, except for FEAL-32X. However, at present, even FEAL-32X can be considered secure for all practical purposes, given the number of computations required and the data needed.

Algebraic and other attack resistance

A higher order differential attack or interpolation attack uses an expanded expression in an encryption function's Galois field GF(2) or an appropriate extension field. Although usually difficult to launch against a cipher with a large number of rounds, this attack is often relatively effective against a cipher that has been designed with resistance against differential/linear attacks in mind. Resistance against a 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 focus on are selected. Thus, it is impossible to determine their minimum values for all possibilities because of the massive number of computations needed. For CRYPTREC, we focused on the components of the encryption function, evaluated the nominal algebraic degree based on the algebraic degree, and performed the following two evaluations using a single S-box input as the variable: • Higher order differential attack resistance for eighth or fewer order when the input of a single S-box was used as the variable • Higher order differential attack resistance based on the bijective nature of the S-box (SQUARE-attack resistance). As a result, we verified that all of the cipher methods had resistance against these attacks at the proposed number of rounds. By applying a higher order differential attack, we could break Hierocrypt-L1 and MISTY1 to a larger number of rounds than possible with differential/linear attacks. Using 237 plaintext pairs and 2117 computations with a 32nd order higher order differential attack (32nd order

233 CRYPTREC 2000

SQUARE attack), Hierocrypt-L1 can be broken to 3.5 rounds.5 A modified MISTY1 without FL function can be broken to six rounds using 211 plaintext pairs and 293 computations with a 7th order higher order differential attack. MISTY1 can be broken to five rounds using 237 plaintext pairs and 275 computations. Resistance against an interpolation attack (or a linear sum attack, which is a generalized form of an 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 focus on are selected. Thus, it is impossible to exhaust all possibilities because of the massive number of computations needed. For CRYPTREC, we divided plaintext into eight small blocks (64-bit block cipher) or 16 blocks (128-bit block cipher) in 8-bit units, and evaluated resistance against linear sum attacks when these small blocks were expressed as polynomial basis of a Galois field GF(28). No cryptanalysis method that is more efficient than an exhaustive search has been discovered for any of the ciphers. There has been a report of successful cryptanalysis for DES in approximately 22 hours using an exhaustive key search, and therefore, for all practical purposes, DES can be broken. Although Triple DES (3-key) can be scientifically broken with 256 chosen plaintexts and 2108.2 computations, using a meet-in-the-middle attack that capitalizes on its being a combination cipher, it can be considered secure for all practical purposes. No security problems have so far been reported from a practical viewpoint for any of the ciphers as the result of other attacks, such as chi-square attacks, impossible differential attacks, boomerang attacks, mod n attacks, and non-bijective attacks.

Avalanche

All algorithms satisfied the expected values in terms of the overall encryption that includes a key schedule. However, for the key schedule alone, parts that do not satisfy the expected values were detected in FEAL-NX, Hierocrypt-L1, and MISTY1. Also, for the round function alone, parts that do not satisfy the expected values were detected in FEAL-NX, Hierocrypt-L1, and MISTY1.

Name Evaluation of Avalanche Effect CIPHERUNICORN-E No characteristics could be seen in the round function. In the data randomization part, no characteristics could be seen in the shuffling in the fourth round and beyond. No characteristics could be seen in the key schedule. Some parts deviated from the expected values in the round function. In the data-randomization part, no characteristics FEAL-NX could be seen in the shuffling in the fifth round and beyond. In the key schedule, there was a major relationship between a secret key and an expanded key.

5 Okuma, Sano, Muratani, Motoyama, and Kawamura, On Security of Block Ciphers Hierocrypt-3 and Hierocrypt-L1, SCIS2001, 11A-4, (2001)

234 CRYPTREC 2000

Name Evaluation of Avalanche Effect Some parts deviated from the expected values in the round function. In the data-randomization part, no characteristics Hierocrypt-L1 could be seen in the shuffling in the second round and beyond. In the key schedule, there was a major relationship between a secret key and an expanded key. Some parts deviated from the expected values in the round function. In the data-randomization part, no characteristics MISTY1 could be seen in the shuffling in the fourth round and beyond. In the key schedule, there was a major relationship between a secret key and an expanded key.

Software (SW)-implementation evaluation

Data-randomization part

Although 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 significantly affected by the execution environment, the value might not always have been realized. Errors also were caused by errors in the measurement programs, and the clock-cycle conversion. Furthermore, in some cases, the measurement value varied with the addition of a change (to be described later) that did not alter the gist of the measurement program. Therefore, making a final determination solely based on the values in the tables is dangerous. The second line of values in the measurement-value column (if present) indicates 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. "Modification" in this case meant an ample memory area was optimized for each cipher. This modification takes the following two points 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.

1. PC environment

64-bit block ciphers Speed [Mbps] CIPHERUNICORN-E 29.0 (28.9) / 29.3 (29.2) FEAL-NX 117.8 (113.9) / 117.2 (111.8) Hierocrypt-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) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

From these results, in the PC environment, if Triple DES is used as the reference, CIPHERUNICORN-E belongs to a slow group, and the rest can be said to belong to a sufficiently fast

235 CRYPTREC 2000

group. 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.

2. Server environment

64-bit block ciphers Speed [Mbps] CIPHERUNICORN-E 17.5 (17.4) / 17.5 (17.4) Hierocrypt-L1 67.7 (67.4) / 51.2 (50.8) 77.1 (76.2) / 84.2 (83.2) Encryption: Fastest speed (average) / Decryption: Fastest speed (average) These results show that CPU specification improvements do not directly translate into cipher processing speed, in some cases. For Hierocrypt-L1, the values obtained after the measurement program were altered by the applicant are shown in the second line in the measurement-value column. More efficient memory allocation improved 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 server environment was selected 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 environments selected by the applicants were used to respect their wishes.

3. High-end environment

64-bit block ciphers Speed [Mbps] CIPHERUNICORN-E 18.8 (18.7) / 18.9 (18.8) Hierocrypt-L1 141.1 (138.7) / 141.1 (139.8) 165.5 (162.8) / 165.5 (162.8) MISTY1 139.1 (138.0) / 143.8 (142.5) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

Alpha21264 is a 64-bit CPU and has a giant primary cache. If general-purpose CPUs evolve into such a structure in the future, the trend that can be observed among the applicant ciphers from these results can be expected. Note that the high-end environment was also selected 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 environments selected by the applicants were used to respect their wishes.

Key schedule + data-randomization part

236 CRYPTREC 2000

affected by the execution environment, the value might not always have been realized. Errors also were caused by errors in the measurement programs, and the clock-cycle conversion. Furthermore, in some cases, the measurement value varied significantly with the addition of a change (to be described later) that did not alter the gist of the measurement program. Therefore, making a final determination solely based on the values in the tables is dangerous. A large memory area was allocated to the measurement program to provide the same condition to all ciphers under evaluation. "Modification" in this case meant an ample memory area was optimized for each cipher. This modification took the following two points 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 would be desirable if processing is completed in several µs.

1. PC environment

64-bit block ciphers Speed [µs] CIPHERUNICORN-E 3.72 (3.73) / 3.70 (3.72) FEAL-NX 1.23 (1.27) / 1.24 (1.27) Hierocrypt-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) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

2. Server environment

64-bit block ciphers Speed [µs] CIPHERUNICORN-E 7.21 (7.23) / 7.34 (7.36) Hierocrypt-L1 1.80 (1.80) / 3.01 (3.04) 1.54 (1.55) / 2.53 (2.58) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

3. High-end environment

64-bit block ciphers Speed [µs] CIPHERUNICORN-E 5.14 (5.16) / 5.66 (5.69) Hierocrypt-L1 0.84 (0.85) / 1.35 (1.41) 0.83 (0.84) / 1.33 (1.40) MISTY1 0.72 (0.73) / 0.68 (0.73) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

237 CRYPTREC 2000

Implementation speeds faster than those listed in this report can be expected. For the latest result, please contact each applicant.

Hardware (HW)-implementation evaluation

FEAL-NX, Hierocrypt-L1, and MISTY1 were the three cryptographic schemes for which HW implementation was evaluated. Because the application document for CIPHERUNICORN-E only stated "HW implementation is also possible" and provided no specific HW-implementation example (size, etc.), its HW implementation was not evaluated. The HW-implementation evaluation of block ciphers can be classified according to two architectures. That is, the loop architecture was used for one category and is not used for the other. The algorithms evaluated using the loop architecture were MISTY1 and Triple DES, and the algorithms evaluated without the loop architecture were FEAL-NX and Hierocrypt-L1. Comparisons were made by dividing the algorithms into these two groups. The following table shows the HW evaluation target parameters of these methods.

Key length Evaluation target Number of repeated rounds (bit) FEAL-NX 32 rounds 128 Hierocrypt-L1 6 rounds 128 MISTY1 8 rounds 128 Triple DES (reference) 48 (=16x3) rounds 168

Evaluation results

The following table shows the evaluation results for circuit size, critical-path delay, and processing speed.

Circuit size (unit: Gate) Data Control Primitive as a Evaluation target Key schedule randomization circuit whole FEAL-NX *1 34,830 34,840 － 69,970 Hierocrypt-L1 *1 278,130 95,397 － 373,526 MISTY1 19,935 44,773 94 64,809 *2 10,609 28,194 68 38,875 Triple DES *1 124,888 23,207 － 148,147 (reference) 4,218 1,333 151 6,496 *2 2,011 1,088 134 5,111

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

*2: The loop architecture was used, but no pipeline architecture was used. A table was used for the substitution table, and

238 CRYPTREC 2000

optimization was done using a logical synthesis tool. The top and bottom rows indicate speed priority and circuit-size priority, respectively.

These evaluation results show that FEAL-NX is approximately half the circuit size of Triple DES, while Hierocrypt-L1 is approximately 2.5 times the circuit size of Triple DES, when the loop architecture is not used (the entire cryptographic algorithm was implemented). Meanwhile, when the loop architecture was used, MISTY1 is approximately 7.6 to 10 times the circuit size of Triple DES. Next, the following table shows the critical-path delay that determined the processing speed and the processing speed that was inferred from the critical-path delay.

Processing speed Evaluation target Critical path (ns) (Mbps) FEAL-NX *1 227.2 281.69 Hierocrypt-L1 *1 70.13 912.59 11.86 600 MISTY1 *2 24.70 288 Triple DES *1 157.09 407.4 (reference) 4.44 244 *2 7.10 153 *1: Assumed a design with a focus on the speed of the overall algorithm and without optimization. No pipeline architecture was used.

*2: The loop architecture was used, but 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 speed priority and circuit-size priority, respectively.

First, when processing speed was compared in the group in which the loop architecture was not used (the entire cryptographic algorithm was implemented), FEAL-NX was approximately 0.7 times Triple DES, while Hierocrypt-L1 is approximately 2.25 times that of Triple DES. Meanwhile, when processing speed was compared in the group in which the loop architecture was used, MISTY1 was approximately 1.9 to 2.5 times that of Triple DES.

Security margin and speed

For the same cipher, increasing the number of rounds qualitatively increases security and reduces the encryption speed. Here, scientific break means decoding of a cipher with a decoding-computation volume that is smaller than an exhaustive search and with a plaintext required for breaking that is less than the total number of plaintexts. For each cipher for which scientific break is known, the ratio between the number of rounds that can be 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 vis-a-vis Triple

239 CRYPTREC 2000

DES. This is summarized in the following table. Note that the speed indicated is the average of the fastest speeds for encryption and decryption.

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

Security margin = number of rounds / Speed Speed number of rounds (data-randomization part) (includes the key schedule) that can be attacked CIPHERUNICORN- 16 / -* 0.60 0.82 E FEAL-NX 32 / 32 2.41 2.45 Hierocrypt-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 scientifically broken is not yet known for CIPHERUNICORN-E.

240 CRYPTREC 2000

5.1.2 128-bit block ciphers

Seven types — Camellia, CIPHERUNICORN-A, Hierocrypt-3, MARS, SC2000, RC6, and Rijndael — were evaluated. We received submissions for Camellia through RC6. CRYPTREC added Rijndael evaluation. An evaluation overview is shown in Table 5.1.3.

Characteristics

This parameter includes the organization that is proposing the technique, the year it was announced, structural characteristics, and characteristics such as the operations used in the data-randomization part. Note that for those techniques that use variable parameters, such as number of rounds, we have included the values recommended by the proposing organizations.

Security

Security is discussed from three viewpoints — linear/differential attack resistance, algebraic and other attack resistance, and avalanche characteristics. • In linear/differential attack resistance, maximal differential/linear probability or maximal differential/linear characteristics probability is indicated as the index of strength against linear/differential cryptanalysis, which is a general-purpose probability-based attack method. • In algebraic and other attack resistance, resistance against higher order differential and interpolation attacks, and algebraic methods such as SQUARE attack, as well as resistance against other attacks, such as related key attacks and mod n attacks are described. The evaluation method for higher order differential and interpolation attacks looks for basic weaknesses of a cryptosystem from the algebraic viewpoint. When the number of rounds is large, an attack based on this method rarely causes a problem. However, the weaknesses uncovered here, if combinable with other attack methods, may affect the ultimate cipher strength. • Avalanche evaluation statistically captures how data is shuffled in each cryptosystem, and although it normally does not directly lead to cryptanalysis, in some cases it provides a clue in looking for weaknesses in the partial function of a cipher.

Software (SW)-implementation evaluation

241 CRYPTREC 2000

performance. Measurements were taken in two parts: the data-randomization parts and the key schedule + data-randomization parts.

Hardware (HW)-implementation evaluation

In principle, no algorithm optimization was performed, and a design with a focus on the speed of the overall algorithm was assumed for evaluation. The target device for evaluation was an ASIC library of 0.35-µm design rules, and the hardware description language was Verilog-HDL, and a design compiler was used for circuit synthesis.

Overall evaluation

The following table shows the overall evaluation results, which are summarized based on the security and implementation evaluation.

Table 5.1.3 Overall evaluation results of symmetric ciphers (128-bit block ciphers)

Name Characteristics Overall evaluation Camellia NTT, Mitsubishi (2000) No security Feistel type, 18 rounds (128-bit key), 24 rounds (192/256-bit key), problem has so far FL/FL-1 function for every sixth round. Expanded keys EXOR as the been found. initial and final processing. Belongs to a group The round function has 8 S-boxes and a P layer of byte-unit with fast operations. processing speed. 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, EXOR, 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. CIPHER NEC (2000) No security UNICORN- Feistel type, 16 rounds. The round function F is complex. Consists of problem has so far A a main stream and a temporary key scheduler that is expected to been found. enhance security. Accurate The round function uses S-box as the basic component and consists evaluation is of T and A functions. difficult because of Four types of 8x8 S-boxes. a complex round Designed based on power multiplication operations on GF (28) and function; continued has resistance against differential/linear cryptanalysis. evaluation is Table look up, addition, multiplication, EXOR, AND, and needed. Belongs to cyclic-shift operation. a group with slow Designed with a round function structure to make significant processing speed. correlation invisible from the cipher-evaluation system.

242 CRYPTREC 2000

Name Characteristics Overall evaluation Toshiba (2000) No security Recursive SPN structure, six rounds (128-bit key), seven rounds problem has so far (192-bit key), eight rounds (256-bit key). Each round consists of two been found. parallel XS functions and a P layer. Belongs to a group Each round consists of four parallel XS functions and a P layer. with fast XS function has a structure in which a P layer is sandwiched between processing speed. Hierocrypt- four parallel S-boxes of two layers. 3 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, EXOR, 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. IBM (1998) No security Data-randomization part consists of the forward mixing, a cipher problem has so far core, and the backward mixing. Key length is between 128 and 448 been found. bits. Because there is no Cipher core is a modified Feistel, 16 rounds, consisting of four 32-bit plan for product MARS blocks. commercialization, Non-linear function E in the core uses 32-bit input and 96-bit output. software-processin E function consists of 9x32 S-box, key multiplication, key addition, g speed was not cyclic shift, and EXOR. evaluated. S-boxes are randomly created and selected based on a standard that takes linear probability, and differential probability, into account. Fujitsu (2000) No security Superposition of Feistel structure and SPN structure. problem has so far Number of rounds in the data-randomization part is 19 rounds been found. (128-bit key) and 22 rounds (192/256-bit key). Belongs to a group Uses 4x4 S-box in the SPN structure, and 5x5 and 6x6 S-boxes in the with fast Feistel structure. Designed based on power-multiplication functions processing speed. SC2000 on an extension field and has resistance against differential/linear cryptanalysis. Immune to algebraic attacks. Table look up, EXOR, 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. RSA Security (1998) No security Modified Feistel 20 rounds consisting of four 32-bit blocks. The problem has so far round function has a simple structure. been found. 32-bit input, 32 + 5 bit output. Two blocks are affected by EXOR Although this and data-dependent cyclic shift. technique provides F function consists of multiplication, addition, and cyclic shift. the fastest RC6 All operations are done in 32-bit words, i.e., the structure assumes a encryption speed 32-bit CPU. on Pentium III, Variable parameter structure that allows the selection of word length, software number of rounds, and key length. processing speed Inherits the design concept of RC5. greatly depends on the platform.

243 CRYPTREC 2000

Name Characteristics Overall evaluation J. Daemen and V. Rijmen (1998) Because this is an SPN structure 10 rounds (128-bit key), 12 rounds (192-bit key), and AES cipher, it can 14 rounds (256-bit key). be considered One type of 8x8 S-box. Designed based on the inverse operation on reliable. GF (28) and has resistance against differential/linear cryptanalysis. e-Government Rijndael Diffusion layer P consists of diffusion within 4 bytes (Mix column) recommends use based on shifts in byte units (shift row) and byte processing. after a reevaluation Table look up, EXOR, and AND. of the FIPS A follow-on to the SQUARE cipher. version. The design of the P layer was evaluated based on the concept of the number of active S-boxes.

244 CRYPTREC 2000

Overall security evaluation

Linear/differential attack resistance

Resistance against linear/differential attacks can be expressed as maximal linear/differential probability. None of the techniques submitted for evaluation offered any guarantee that this probability is small enough to guarantee security of a 128-bit block cipher. Because it is difficult to determine the true value of the maximal linear/differential probability, maximal linear/differential characteristics probability is used as a corresponding index. The following methods are available for evaluating maximal characteristics probability: • A method that determines characteristics probability based on the maximal linear/differential probability of the components • A method that determines maximal characteristics probability through computer searches For Camellia, Hierocrypt-3, and Rijndael, the upper limit of characteristics probability is indicated using active S-boxes count evaluation. It has been shown that Camellia, excluding the FL-function, does not exceed a differential/linear characteristics probability of 2-132 in 12 rounds, and that Hierocrypt-3 in 2 rounds and Rijndael in 4 rounds do not to exceed a differential/linear characteristics probability of 2-150. Because its round function F has a complex structure, CIPHERUNICORN-A is difficult to analyze. Therefore, the upper limits of 15-round differential characteristics probability and linear characteristics probability have been shown to be 2-140 and 2-140.14, respectively, when a truncated vector search is used for the simplified round function mF. However, deeper evaluation of the round function F is desired. MARS also has a complex structure, and accurate analysis is difficult. However, since the application to AES, many researchers have evaluated MARS and the designers have shown that the 16-round encryption core offers a maximal differential characteristics probability of 2-156 and a maximal linear characteristics probability of 2-120. Note that because the proposing organization has indicated that it has no plan to commercialize MARS, its evaluation by CRYPTREC is now finished. Although its structure is simple, RC6 is based on 32-bit word processing, and thus strict evaluation is difficult. However, the evaluation of its predecessor, RC5, and the research related to the AES application, have shown a 14-round maximal differential characteristics probability of 2-140 and an 18-round maximal linear characteristics probability of 2-155. A truncated vector search has shown that SC2000 does not exceed a 15-round maximal differential characteristics probability of 2-134 and a 15-round maximal linear characteristics probability of 2-142. Furthermore, the proposing organization has developed a version with the same structure that offers an 11-round differential characteristics probability of 2-117, reinforcing the reliability of the aforementioned analysis result. The method that considers these characteristics probabilities of 128-bit block ciphers are 2-128 or lower to be the proof of security is called the practical security guarantee against linear/differential

245 CRYPTREC 2000

attacks. All of the ciphers currently have values lower than this value, thus guaranteeing scientific linear/differential attack resistance.

Algebraic and other attack resistance

Resistance against higher order differential attacks and interpolation attacks was evaluated in the same way as the 64-bit block ciphers (see Section 5.1.1). For all of the cryptographic schemes, no breaking method that was more effective than an exhaustive search has been found. Hierocrypt-3 and Rijndael can be attacked to a higher number of rounds than differential/linear attacks by applying a higher order differential. 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) key6. By applying a SQUARE attack (32nd order higher order differential attack) and using a partial sum method, Rijndael can also be broken more effectively with an exhaustive 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 8 rounds out of 14 for a 256-bit key. These attack methods against Rijndael require between 2128 and 2119 plaintext combinations, which is nearly equal to the 2128 plaintext combinations that can be generated in a 128-bit block cipher. The 256-bit key can be broken more effectively than with an exhaustive search, to nine rounds out of 14 using a related key attack7. A chi-square attack also has been effective against RC6. Using this attack, RC6 can be broken more effectively than with an exhaustive 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 key8. No security problems have so far been reported from a practical viewpoint for any of the ciphers as the result of other attacks, such as impossible differential attacks, boomerang attacks, mod n attacks, and non-surjective attacks.

Avalanche

All algorithms satisfied the expected values in terms of the overall encryption that includes a key schedule. However, for the key schedule alone, parts that do not satisfy the expected values were detected in Camellia, Hierocrypt-3, MARS, and SC2000. Also, for the round function alone, parts that do not satisfy the expected values were detected in Camellia, Hierocrypt-3, MARS, RC6, and SC2000.

6 Okuma, Sano, Muratani, Motoyama, and Kawamura, About the Security of Block Ciphers Hierocrypt-3 and Hierocrypt-L1, SCIS2001, 11A-4, 2001 7 N. Ferguson,et al., Improved Cryptanalysis of Rijndael, in the preproceedings of the Fast Software Encryption Workshop 2000, April 10-12, 2000. 8 L. R. Knudsen and W. Meier，Correlations in RC6 with a reduced number of rounds, Fast Software Encryption Workshop, 2000

246 CRYPTREC 2000

Name Avalanche Some parts of the round function deviated from the expected values. In the data-randomization part, no characteristics could be seen in the shuffling in the Camellia fourth round and beyond. Different characteristics could be seen in the key schedule, depending on the secret key length. No characteristics could be seen in the round function. In the CIPHER data-randomization part, no characteristics could be seen in the shuffling in the UNICORN-A third round and beyond. No characteristics could be seen in the key schedule. Some parts of the round function deviated from the expected values. In the data-randomization part, no characteristics could be seen in the shuffling in the Hierocrypt-3 second round and beyond. In the key schedule, there was a major relationship between a secret key and an expanded key. Some parts of the round function deviated from the expected values. No characteristics could be seen in the data-randomization part. In the key MARS schedule, characteristics could be seen in the expanded key used for multiplication. Some parts of the round function deviated from the expected values. In the RC6 data-randomization part, no characteristics could be seen in the shuffling in the fourth round and beyond. No characteristics could be seen in the key schedule. Some parts of the round function deviated from the expected values. In the data-randomization part, no characteristics could be seen in the shuffling in the SC2000 fourth round and beyond. In the key schedule, characteristics could be seen when the secret key was 192 bits and 256 bits.

Software (SW)-implementation evaluation

Data-randomization part

Although 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 significantly affected by the execution environment, the value might not always have been realized. Errors also were caused by errors in the measurement programs, and the clock-cycle conversion. Furthermore, in some cases, the measurement value varied with the addition of a change (to be described later) that did not alter the gist of the measurement program. Therefore, making a final determination solely based on the values in the tables is dangerous. The second line of values in the measurement-value column (if present) indicates the measurement values obtained after the measurement program was altered by the applicant. A large memory area was allocated to the measurement program in order to provide the same condition to all ciphers under evaluation. "Modification" in this case meant an ample memory area was optimized for each cipher. This modification takes the following two points 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.

247 CRYPTREC 2000

1. PC environment

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) Triple DES 48.7 (48.6) / 48.7 (48.6) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

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 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 judged to be 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.

2. Server environment

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) Encryption: Fastest speed (average) / Decryption: Fastest speed (average) These results show that CPU specification improvements do not directly translate into cipher processing 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, 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-side 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 server environment was selected 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 environments selected by the applicants were used to respect their wishes.

248 CRYPTREC 2000

3. High-end environment

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) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

Because the time between proposal and development is short for some ciphers, a conclusion should not be reached based on these results alone. 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, the trend that can be observed among the applicant ciphers from these results can be expected. Note that the high-end environment was also selected 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 environments selected by the applicants were used to respect their wishes.

Key schedule + data-randomization part

Although number of clock cycles was used as the measurement value, we converted it into µs for ease of understanding. A smaller value means faster speed. Because the measurement value is significantly affected by the execution environment, the value might not always have been realized. Errors also were caused by errors in the measurement programs, and the clock-cycle conversion. Furthermore, in some cases, the measurement value varied significantly with the addition of a change (to be described later) that did not alter the gist of the measurement program. Therefore, making a final determination solely based on the values in the tables is dangerous. A large memory area was allocated to the measurement program to provide the same condition to all ciphers under evaluation. "Modification" in this case meant an ample memory area was optimized for each cipher. This modification took the following two points 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 would be desirable if processing is completed in several µs.

249 CRYPTREC 2000

1. PC environment

128-bit block ciphers Speed [µs] 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) Triple DES 3.02 (3.03) / 3.03 (3.04) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

2. Server environment

128-bit block ciphers Speed [µs] 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) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

3. High-end environment

128-bit block ciphers Speed [µs] 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) Encryption: Fastest speed (average) / Decryption: Fastest speed (average)

These results clearly show that operations that can sufficiently withstand actual usage can be expected in these environments. SW-implementation performance is being improved daily through developments by the applicants. Implementation speeds faster than those listed in this report can be expected. For the latest result, please contact each applicant.

Hardware (HW)-implementation evaluation

Camellia, CIPHERUNICORN-A, Hierocrypt-3, MARS, RC6, and SC2000 were the six cryptographic schemes for which HW implementation was evaluated. The parameters for HW evaluation are described as follows. Because the application document for CIPHERUNICORN-A only stated "HW implementation is also possible" and provided no specific HW-implementation example (size, etc.), its HW

250 CRYPTREC 2000

implementation was not evaluated. The HW-implementation evaluation of block ciphers can be classified according to architecture. That is, the loop architecture was used for one category and was not used for the other. The algorithms belonging to the group that did not use the loop architecture were Hierocrypt-3, MARS, and RC6, and the only algorithm that used the loop architecture was Camellia. The following table shows the HW evaluation target parameters of these methods.

Number of Key length Evaluation target repeated rounds (bit) Camellia 24 rounds 256 CIPHERUNICORN- 16 rounds 128 A Hierocrypt-3 6 rounds 128 MARS 32 rounds 128 RC6 20 rounds 128 SC2000 19 rounds 128 Rijndael (reference) 10 rounds 128

Evaluation results

The following table shows the evaluation results for circuit size, critical-path delay, and processing speed.

Circuit size (unit: Gate) Evaluation target Data randomization Key schedule Control-cir Primitive as a cuit area whole Camellia 16,327 22,755 266 39,348 *2 9,668 13,304 141 23,124 RC6 *1 77,785 975,391 － 1,753,076 SC2000 (reference) －－－－ 62,000 [2] MARS *1 739,069 2,316,846 － 3,055,914 Hierocrypt-3 *1 538,078 106,302 － 724,380 Rijndael (reference) *1 518,508 93,708 － 612,843 *1: Assumed a design with a focus on the speed of the overall algorithm and without optimization. No pipeline architecture was used.

These evaluation results show that Hierocrypt-3 is approximately 4.8 times the circuit size of Triple DES, while Rijndael is approximately 4.1 times the circuit size of Triple DES when the loop architecture

251 CRYPTREC 2000

is not used (the entire cryptographic algorithm was implemented), which indicate small circuit sizes. The circuit sizes of RC6 and MARS exceed 10 times that of Triple DES. In the group that uses the loop architecture (small architecture), Camellia (256-bit key) is approximately 6 times the circuit size of Triple DES if priority is given to speed and approximately 4 times the size if priority is given to area. Based on these trends, in terms of HW-implementation size, Camellia (256-bit key), Hierocrypt-3, and Rijndael are relatively small in circuit size, while RC6 and MARS are large in circuit size.

The following table shows the critical-path delay that determined the processing speed and the processing speed that was inferred from the critical-path delay.

Evaluation target Critical path (ns) Key Setup Time (ns) Processing speed (Mbps) Camellia (256-bit key) *2 5.46 － 837 11.51 － 397 RC6 *1 698.05 2,112.26 183.36 SC2000 (reference) －－－ 914 MARS *1 612.64 1,740.99 208.93 Hierocrypt-3 *1 75.55 1,694.24 Rijndael (reference) *1 65.64 57.39 1,950.03 *1: Assumed a design with a focus on the speed of the overall algorithm and without optimization. No pipeline architecture was used.

First, when processing speed was compared in the group in which the loop architecture was not used (the entire cryptographic algorithm was implemented), Hierocrypt-3 and Rijndael exceed approximately 4 times the speed of Triple DES, while neither RC6 nor MARS exceeded 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 the throughput of Triple DES. Note that the SC2000 data is included for reference, because this information (circuit size and throughput) was reported for HW implementation (0.25-µm rule CMOS-GA) at the ISEC Technical Group Meeting (September 2000).9

Security margin and speed

For the same cipher, increasing the number of repeated rounds qualitatively increases security and

9 Shimoyama, Yanami, Yokoyama, et al., Symmetric Block Cipher SC2000, Technical report of ISEC2000-72, (2000-9).

252 CRYPTREC 2000

reduces the encryption speed. Here, scientific break means decoding of a cipher with a decoding-computation volume that is smaller than an exhaustive search and with a plaintext required for breaking that is less than the total number of plaintext. Three key length specifications — 128, 192, and 256 — have been proposed for 128-bit block ciphers. The scientifically breakable number of rounds are shown as follows for the 256-bit key specification.

Camellia (without FL function) 7 rounds out of 24 Truncated differential attack (differentiated from random permutation)10 Hierocrypt-3 3.5 rounds out of 8 Higher order differential attack (SQUARE attack)11 MARS (Core only) 11 rounds out of 16 Truncated differential attack12 RC6 15 rounds out of 20 Chi-square attack13 SC2000 13 rounds out of 22 Differential attack14 Rijndael 8 rounds out of 14 Higher order differential attack 9 rounds Related key attack (SQUARE attack)15

CIPHERUNICORN-A is unknown. These numbers of rounds that can be attacked are based on published information as of March 31, 2001, and detailed evaluation by CRYPTREC. In Camellia, there was a relatively large difference between the specified number of rounds and the currently known number of rounds that can be attacked. This is a difference between the upper limit of the number of rounds that can be attacked, which is assumed by the proposing organization, and the currently available attack techniques. It does not mean the specified number of rounds can be reduced. Many of the 128-bit block ciphers have recently been proposed, and more research is expected in the future. Because we believe that it is not appropriate to indicate a security margin based on the currently available data, which contains major deviations, we did not create a security margin vs. speed table.

10 Shibuya, Shimoyama, and Tsujii, Truncated Linear Attack on Byte-Oriented Ciphers, SCIS2001, 11A-3, 2001. 11 Okuma, Sano, Muratani, Motoyama, and Kawamura, About the Security of Block Ciphers Hierocrypt-3 and Hierocrypt-L1, SCIS2001, 11A-4, 2001. 12 J.Kelsey and B.Schneier，MARS Attacks! Preliminary Cryptanalysis of Reduced-Round MARS Variants, 3rd AES conf.(2000), http://csrc.nist.gov/encryption/aes/round2/conf3/aes3papers.html 13 L. R. Knudsen and W. Meier，Correlations in RC6 with a reduced number of rounds, Fast Software Encryption Workshop, 2000 14 Yanami and Shimoyama, Differential/Linear Search of Symmetric Block Cipher SC2000, SCIS2001, 12A-2, 2001. 15 N. Ferguson, et al., Improved Cryptanalysis of Rijndael, in the proceedings of the Far East Encryption Workshop 2000, April 10-12, 2000.

253 CRYPTREC 2000

5.1.3 Stream ciphers

The following table shows the results of an overall security and implementation evaluation.

List of stream ciphers Name Characteristics Security Overall evaluation MULTI-S01 MULTI-S01 consists of Basically secure, even No problem has so pseudorandom number though security as a far been found in generation as well as encryption stream cipher has not terms of security as a and decryption processes that yet strictly been stream cipher. implement the modes for using evaluated by academic No strict evaluation the cipher. societies. has so far been Pseudorandom number performed by generator generates a key stream academic societies, from secret key K (256 bits). and continued Messages are encrypted using evaluation is needed. this key stream. Belongs to a group Performs both message hiding with fast and message authentication SW-processing simultaneously. speed. MULTI-S01 uses PANAMA as the pseudorandom number generator. TOYOCRYPT- This is a synchronous key Improvements must be Improvements must HS1 stream cipher, and implements made to the proposed be made to the encryption by EXORing bit by algorithm before it can proposed algorithm bit the pseudorandom number be applied to an actual before it can be system generated by a key system. Key length applied to an actual stream generation algorithm and actually decreases system. Suitable to a plaintext system. drastically to 96 bits at HW implementation. The key stream generation the most from the algorithm is classified as a nominal 128 bits if the non-linear filter generator. fixed key is known. Generates random numbers bit Although this is within by bit by outputting the output the secure range given of a linear feedback shift current computation register via a non-linear capability, future transformation function. security must be The non-linear transformation evaluated by the user. function does not use arithmetic operations to keep the hardware size small, and uses logical operations as the basic operations.

Software (SW)-implementation evaluation

In measuring stream ciphers, only the data randomization was measured, because there is usually no key setup. However, because we used the same measurement program as that used for 64-bit block ciphers, we may have sacrificed the implementation possibility of stream ciphers, in some cases. Based on how they are used, stream ciphers have stronger HW orientation than block ciphers, and thus a major

254 CRYPTREC 2000

focus should be placed on HW evaluation rather than SW evaluation. Therefore, the purpose of the SW evaluation of stream ciphers was to verify whether or not performance that can withstand the minimum usage conditions was achieved. Although 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 significantly affected by the execution environment, the value might not always have been realized. Errors also were caused by errors in the measurement programs, and the clock-cycle conversion. As with block ciphers, making a final determination solely based on the values in the tables is dangerous. Stream ciphers have strong HW orientation. Therefore, many of them are not suitable for SW implementation. The measurement was done only in the PC environment, and the same measurement program as that used for 64-bit block ciphers was used. Consequently, the actual performance may not have been sufficiently demonstrated. Therefore, the purpose of the measurement was to verify whether or not performance that can withstand the minimum usage conditions was achieved.

PC environment

Stream ciphers Speed [Mbps] MULTI-S01 237.7 (233.7) TOYOCRYPT-HS1 3.0 (3.0) Fastest speed (average)

An ordinary stream cipher obtains an encrypted text by EXORing a plaintext with a random number string (key system). Decryption is done in the reverse order, and the speed is exactly the same for both encryption and decryption. Therefore, only encryption was measured. Because MULTI-S01 does not have an ordinary stream cipher structure, a speed difference may actually arise between encryption and decryption. Furthermore, 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 schedule in block ciphers, it was not included in the measurement. TOYOCRYPT-HS1 was serially implemented to match the measurement-program interface. Because it is supposed to be implemented in parallel, the proposing organization insists that implementation can be expected that achieves approximately 80% faster performance than the value shown. Although some sort of restrictions were placed on both ciphers in the SW-implementation evaluation, it should be possible to achieve the minimum condition of the expected SW implementation. Note that details must be obtained based on specific evaluations. However, simple speed comparison of MULTI-S01 and TOYOCRYPT-HS1 based on the measurements provided is meaningless because both their design philosophies and functions are different.

255 CRYPTREC 2000

SW-implementation performance is improving daily through developments by the applicants. Implementation speeds faster than those listed in this report can be expected. For the latest details, please contact each applicant.

Hardware (HW)-implementation evaluation

Evaluation method

A simulation was run after coding the circuits using Verilog HDL for a program created in the C language on Altera's FPGA (Field Programmable Gate Array). The following development environments were used: • ModelSlim VHDL/Verilog Version 5.4e (Model Technology) • Synplify (Synplicity Inc.)

Evaluation results

Note that the execution-speed estimates in the following table do not include the setup time for key data.

Operating Processing Evaluation target frequency speed Resource usage FPGA used (MHz) (Gbps) 18.8 1.203 19,811/42,240 EP20K1000E MULTI-S01 ATOMs (46%) Priority on 58.1 0.052 11,883/24,320 LCs EP20K600E circuit size TOYOCRYPT- Priority on 45.2 1.446 16,144/24,320 LCs EP20K600E HS1 processing speed

We determined that stream ciphers can achieve Gbps-class processing speed with a reasonable circuit size, even when using a general-purpose FPGA, if processing speed is given the design priority. Note that the EP20K1000E can achieve a larger circuit size than EP20K600E. If the FPGAs used are taken into consideration, MULTI-S01 results in a larger circuit size than TOYOCRYPT-HS1.

Reference [1] ICHIKAWA, KASUYA, MATSUI, Hardware Evaluation of the AES Finalists, The Third Advanced Encryption Standard Candidate Conference, April 13-14, 2000

256 CRYPTREC 2000

5.2 Individual Cipher Evaluation

5.2.1 CIPHERUNICORN-E

1 Cryptographic Technique

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 proposed and developed by NEC Corporation in 1998. The basic structure of the cipher is a 16-round Feistel cipher [1]. The major characteristic of this cipher is its use of an extremely complex round function that consists of a main stream and a temporary keygeneration mechanism. This function is intended to enhance security by making an expanded keys search of the round function difficult. Unlike the design philosophies of many ciphers, the main design philosophy behind CIPHERUNICORN-E is to design a round function, of which a significant correlation cannot be found out, with a cipher strength evaluation system [2] that performs the elementary statistical evaluation by regarding the round function as a black box. As a result, it has been reported that no data-shuffling bias was detected in any of the items in the elementary statistical evaluation of the round function. CIPHERUNICORN-E can be implemented in both software and hardware, and it has reportedly been designed to be able to perform high-speed processing, using a 32-bit processor in particular.

Intellectual property rights (based on the application document) (Proposing organization's patents) Patent: Application No. H9-213274

Public web address for technical specifications: http://www.mesh.ne.jp/hnes/products/security/angou.html

1.2 Technical Specifications

This cipher uses 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 expanded key is generated by shuffling the secret key.

(Data randomization) The round function is a 32-bit input/output function that uses expanded keys (function keys and seed keys) of 32 bits x 4 (a total of 128 bits), and consists of an S-box, 32-bit arithmetic

257 CRYPTREC 2000

addition, and shift operation. 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, ultimately producing 32-bit output data. 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 expanded keys of 64 bits x 2 (a total of 128 bits). It is a key-dependent linear transformation function that is configured as the logical product of bit units.

(Key schedule) The key schedule has a Feistel structure that uses ST functions as the round functions, and outputs either two or four 32-bit expanded keys from each ST function while shuffling the secret key. The ST functions use the same T function as the round function.

(Design philosophy) Differential cryptanalysis and linear cryptanalysis estimate key information using the shuffling bias in the round function. Therefore, a design philosophy is to build a round function in which shuffling bias cannot be detected. The round function that satisfies the following conditions has been designed with a 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.

1.3 Other

CIPHERUNICORN-A, which is a 128-bit block cipher, has been designed in the same way with the cipher strength evaluation system.

258 CRYPTREC 2000

2 Evaluation Results

2.1 Security evaluation

The configuration of CIPHERUNICORN-E's 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. Furthermore, despite the fact that three years have passed since it was initially proposed, no third party evaluation results have been available in academic societies. Therefore, strict theoretical evaluation of security has not been performed. Consequently, the minimum number of rounds required for achieving the expected strength, the security margin, etc., have not been accurately assessed. Nevertheless, a model that uses an mF function in which the configuration of the round function has been simplified based on appropriate considerations has been shown to achieve an upper bound of the maximal differential characteristics probability of 2-64 or less in 12 or more rounds. In a model that uses an mF* function that eliminates the effect of multiplying the linear characteristics probabilities of an S-box that an independent expanded key has not been inserted, the linear characteristics probability of the mF* function of 2-17.68 exists. If this probability is assumed to be the maximal linear characteristics probability of the mF* function, the upper bound of the maximal linear characteristics probability in eight rounds becomes 2-70.72. To obtain an accurate strength of the original cipher, it is necessary to replace the mF function and mF* function with the original round function for more detailed evaluation. However, it is expected that roughly the same level of security as that of a model that has been simplified based on appropriate assumptions would be achieved. Therefore, when the fact that the specified number of rounds is 16 is collectively taken into consideration, it seems impossible to break CIPHERUNICORN-E using the state-of-the-art cryptanalysis techniques. Therefore, CIPHERUNICORN-E can be considered a secure cipher for the e-Government. However, the resistance to side channel attacks may not be very high because of the configuration of the round function. Therefore, it is desirable to carefully institute defensive measures if CIPHERUNICORN-E is to be used in an environment in which a side channel attack may occur.

A) Elementary statistical evaluation It was verified that the cipher output become indistinguishable from a random function in at least the fifth round. Additionally, favorable results have been obtained for all items in the elementary statistical evaluation of the round function, which indicates excellent elementary statistical properties of randomness. Note that the applicant states that the round function was designed such that a shuffling

259 CRYPTREC 2000

bias cannot be detected. However, 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 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 assumptions. For CIPHERUNICORN-E as well, the self-evaluation document states that security has been evaluated using an mF function in which the round function has been simplified based on appropriate considerations, such as (1) replacing arithmetic addition with EXOR, and (2) replacing the Y function with a process that aggregates input bits to the upper 1 byte of the 32-bit data. When a truncated vector search for this model is used, the upper bound of the maximal differential characteristics probability in 15 rounds has been evaluated as 2-84. From this evaluation, the upper bound of the maximal differential characteristics probability in 12 rounds can also be determined to be 2-72. For the same model, another estimation shows that the maximal differential characteristics probability in 10 rounds is 2-70 or less. Based on these results, the existence of a differential path in 12 rounds or more cannot be expected in a model that uses an mF function. Therefore, considering that CIPHERUNICORN-E's number of rounds is 16, this cipher can be assumed secure against differential cryptanalysis. Furthermore, by performing a more detailed evaluation after replacing the mF function with the original round function, more accurate strength can be obtained. Note that although an L function is inserted in the middle, since the basic operations are based on bit units, the probability that the L function will reduce the differential characteristics probability is small as long as the hamming weight of the input differential value is small. We presume that the number of rounds that can be attacked is not affected very much (especially when the number of rounds is small).

C) Linear cryptanalysis As with differential cryptanalysis, the self-evaluation document states that the maximal linear characteristics probability of the mF function has been evaluated as 2-63.90 and the upper bound of the maximal linear characteristics probability in 15 rounds as 2-447.30 when a truncated vector search is applied to a model that uses an mF function. Here, for the maximal linear characteristics probability of the mF function, a model is

260 CRYPTREC 2000

considered that uses an mF* function that completely eliminates the effect of multiplying the linear characteristics probabilities of an S-box that an independent expanded key has not been inserted. To do this, the effect of the characteristics probability of the S-box in both the temporary key generation and data-dependent function of the mF function is completely removed, which means the linear characteristics probability of "1". In this case, the linear characteristics probability of the mF* function in the same linear path as that used in the self-evaluation is 2-17.68. If this is assumed to be the maximal linear characteristics probability of the mF* function, the upper bound of the maximal linear characteristics probability in eight rounds is 2-70.72. These results indicate thatlinear paths in eight rounds or more are expected to seldom occur in the model that uses the mF* function. Therefore, CIPHERUNICORN-E can be considered secure against linear cryptanalysis, considering that its number of rounds is 16. Note that, by performing a more detailed evaluation after replacing the mF* function with the original round function, more accurate strength probably can be obtained.

D) Higher order differential attack, interpolation attack Security against these cryptanalyses has been evaluated based on appropriate considerations in the self-evaluation document. Particular problems were neither found out in a detailed evaluation.

E) Key collision attack Because of the configuration of the key schedule, 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 use a secret key after verifying that such a weak key does not occur.

(Security against side channel attack) In CIPHERUNICORN-E's round function, 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 poweranalysis attack is considered effective when the same data goes through multiple processes, as in b). Therefore, CIPHERUNICORN-E may not be very immune to

261 CRYPTREC 2000

side channel attacks, such as timing attack and power-analysis attack. Consequently, when using CIPHERUNICORN-E in an environment in which a threat of side channel attacks is present, it is desirable to carefully institute defensive measures..

2.2 Software (SW)-implementation evaluation

(PC implementation) SW implementation was evaluated in the environments listed as follows. The following tables show the evaluation results. Data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler Program size 26232 bytes (including encryption/decryption/key schedule) Compiler option Specify "/O2/Oy-" (execution speed) First round Second round Third round 1435 / 1438 1434 / 1444 1436 / 1440 1424 / 1426 1422 / 1425 1422 / 1425

Ultra SPARC IIi (400MHz) Language ANSI C Program size 11848 bytes (including encryption/decryption/key schedule) Compiler option Specify "-v -fast" First round Second round Third round 1462 / 1469 1462 / 1468 1462 / 1469 1462 / 1468 1462 / 1468 1462 / 1468

Alpha21264 (463MHz) Language ANSI C Program size 13552 bytes (including encryption/decryption/key schedule) Compiler option Specify "-O4" First round Second round Third round 1575 / 1583 1575 / 1583 1575 / 1583 1566 / 1579 1568 / 1582 1568 / 1580

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

262 CRYPTREC 2000

Key schedule + data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler Program size 26232 bytes (including encryption/decryption/key schedule) Compiler option Specify "/O2/Oy-" (execution speed) First round Second round Third round 2421 / 2426 2418 / 2428 2420 / 2424 2406 / 2453 2406 / 2424 2410 / 2414

Ultra SPARC IIi (400MHz) Language ANSI C Program size 11848 bytes (including encryption/decryption/key schedule) Compiler option Specify "-v -fast" First round Second round Third round 2882 / 2892 2882 / 2890 2883 / 2890 2936 / 2944 2935 / 2944 2935 / 2944

Alpha21264 (463MHz) Language ANSI C Program size 13552 bytes (including encryption/decryption/key schedule) Compiler option Specify "-O4" First round Second round Third round 2381 / 2393 2381 / 2390 2381 / 2390 2621 / 2634 2619 / 2635 2623 / 2634

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

For all measurement items in encryption and decryption, including key generation, CIPHERUNICORN-E belongs to the group with the slowest processing speed among the 64-bit block ciphers submitted for evaluation, regardless of the measurement platform. Especially on Pentium III, CIPHERUNICORN-E is slower than Triple DES in all measurement items. In encryption/decryption, CIPHERUNICORN-E's processing speed is approximately 60% of Triple DES, and is approximately 80% in key generation + encryption/decryption. There is no description or public information related to software implementation on 8-bit CPUs, as represented by IC cards.

263 CRYPTREC 2000

2.3 Hardware (HW)-implementation evaluation

Although the applicant states that hardware implementation is possible, CIPHERUNICORN-E was not included in hardware-implementation evaluation because no description or public information related to hardware implementation exists.

References [1] Yukiyasu Kadoo, 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 Kadoo, Ryoji Ota, Hiroshi Miyauchi, and Katsuhiro Nakamura, Distributed Cipher-Strength Evaluation System, 2000 Ciphers and Information Security Symposium SCIS 2000, A53, 2000.

264 CRYPTREC 2000

5.2.2 FEAL-NX

1. Cryptographic Technique

1.1 Technical overview

One basic portion of FEAL-NX was announced in 1987 by Shimizu et al. (NTT) at EUROCRYPT. FEAL-NX, a Feistel symmetric block cipher with a block length of 64 bits and a key length of 128 bits, was announced in 1990 by Miyaguchi et al. (NTT) [19], and was submitted as a cipher for the Digital Government this time. FEAL-NX is designed with 8-bit microprocessor codes in mind, and is intended to fit limited-resource situations such as small processors and small memory sizes. It is a cipher with more than 10 years of history since its announcement, and the many analyses that have been performed so far have proven its security and processing performance.

Intellectual property rights (based on the application document) (Proposing organization's patents and their handling) The status of the applicant's patents related to the cryptographic technique being proposed is as follows: Application No. Registration No. No (Disclosure No.) (Publication No.) Title of the Invention Applicant 1 60-250398 (62-109083) 2028919 (7-060292) Data random number NTT, NTT Data processing method 2 60-252650 (62-113191) 1992651 (3-033269) Data-diffusion device NTT, NTT Data 3 62-037231 (63-204289) 1991129 (6-090597) Data-diffusion device NTT, NTT Data 4 62-232957 (1-074582) 2834450 Cryptographic device NTT 5 01-340384 (3-129384) 2825205 Cryptographic device NTT 6 EP 86115279.1 US 4,850,019 EP 221538 Data randomization NTT equipment

Note that the applicant has stated that it is willing to license the following patents to others on a non-exclusive basis and under reasonable conditions.

Public web address for the specifications of the cryptographic technique being proposed: http://info.isl.ntt.co.jp/

1.2 Technical Specifications

(Overall structure) • A Feistel symmetric block cipher with a block length of 64 bits and an encryption key length of 128 bits. • The F function, which is an internal function of the Feistel structure, divides the 32 input bits into

265 CRYPTREC 2000

four 8-bit variables, and outputs 32 bits by performing a shuffling process using these variable as inputs.

(Design philosophy) • A structure that has a statistically high data-shuffling effect is used as the internal function. • The internal function of the Feistel structure performs shuffling using arithmetic operations and logical operations on a byte basis. • The expanded key generation function consists of an S-box composed of an 8-bit arithmetic operation and logical operations. • The recommended number of rounds is an even number that is at least 32.

1.3 Other

FEAL-4, a block cipher with a bit length of 64 and a 4-round Feistel structure, was developed by NTT in 1987. Then, FEAL-N was created by increasing the number of rounds to 32 or more. This FEAL-N is the basis for FEAL-NX [19, 20, 26, 27]. The encryption portion of FEAL-NX is the same as that of FEAL-N, and the secret key length was expanded from 64 to 128 bits by improving the expanded key generation of FEAL-N. More than 10 years have passed since the basic structure of this cipher was proposed. During this period, new attack methods against block ciphers and high-speed implementation methods have been developed. Some of them have been tried on FEAL-N, often making it the touchstone for symmetric block ciphers. In other words, FEAL-N occupies an important position in the history of symmetric block ciphers [1, 5, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 25, 28, 29, 30].

2. Evaluation Results

The recommended number of rounds for FEAL-NX is described as an even number of at least 32, and the number of rounds is not uniquely defined. All ciphers submitted for evaluation are required to have all of their parameters related to cryptographic algorithms, including the number of rounds, fixed. Therefore, the Evaluation Committee decided to use 32 rounds, the minimum recommended number, for FEAL-NX to perform various evaluations.

2.1 Security evaluation

The data-randomization part of FEAL-NX has exactly the same structure as FEAL-N. The only difference is that, while FEAL-N has a 64-bit key length, the key length of FEAL-NX has been expanded to 128 bits, with improvements in the key schedule. By applying the differential cryptanalysis for FEAL, announced by Biham, Shamir, et al. in 1991, we

266 CRYPTREC 2000

estimated the expanded key of 31-round FEAL-N at a better-than-significant probability using 264 combinations of chosen plaintext ciphers (data volume of 263) and 263 computations. By applying this FEAL-N breaking method to the first 31 rounds of 128-bit key, 32-round FEAL-NX, and by attacking the 32-bit expanded key for the last round with all possible combinations, we estimated the expanded key of FEAL-NX using 263 data and 299 computations. If this cipher is used in the Digital Government, the number of computations necessary for breaking is unrealistic in the actual application, and it is currently unthinkable that the attack will succeed and cause problems. Nonetheless, the number of computations necessary for this attack is smaller than 2128, which is the number of computations necessary for attacking a key with all possible combinations and is one of the goals of cipher researchers when attacking a symmetric block cipher. Therefore, from a scientific viewpoint, it is a stretch to conclude that FEAL-NX has sufficient security against differential cryptanalysis. As for the key schedule used in FEAL-NX, it has been reported that the same expanded key is repeated every six rounds for 232 keys out of the 2128 key space. Because a slide attack can be applied to these keys, they may become weak keys. However, whether or not the cipher key can be actually estimated from such an attack remains to be studied. Furthermore, because the key set of 232 is sufficiently smaller than the entire key space of 2128, it is unlikely that any actual problems will be encountered when FEAL-NX is used as a cipher for the Digital Government. Yet, from a scientific viewpoint, it is difficult to conclude that the security of the key schedule has no problems. – Attack on the data-randomization part In a differential attack on FEAL-NX, a method is available that can estimate the cipher key using a number of computations that is smaller than that required in an exhaustive search. FEAL-NX is expected to have no security problems with other attacks, linear attacks, higher order differential attacks, or mod n attacks. The following table summarizes the most effective attack at each round. Note that attacks on the number of rounds exceeding 32 have not been evaluated.

Number of Data Number of Technique, originator, year [references] rounds volume computations needed 4 4 16 2 Known plaintext, Kurita and Kaneko, 1993 [15] 33 8 12 2 Differential linear cryptanalysis, Aoki et al., 1995 [1] 63 63 31 2 2 Differential cryptanalysis, Biham and Shamir, 1991 [7] 63 99 32 2 2 Differential cryptanalysis (improved version of [7]) Number of rounds attacked in FEAL-NX and the number of computations needed

– Attack on the key schedule 232 keys out of the 2128 key space may become weak keys against a slide attack, and therefore security

267 CRYPTREC 2000

must be evaluated. FEAL-NX is expected to have no security problems with related key attacks or meet-in-the-middle attacks.

– Attack in implementation During implementation, care must be exercised concerning timing attacks, power-differential attacks, and faulty-based attacks.

2.2 Software (SW)-implementation evaluation

(PC implementation) SW implementation was evaluated in the environments listed as follows. The following tables show the evaluation results.

Data-randomization part speed-measurement results

Pentium III (650MHz) Language Assembler Program size 16779 bytes (including encryption/decryption/key schedule) Compiler option /G6 /Gr /Zp16 /MLd /W1 /GX- /Ogx /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS"¥ /Fp"$(INTDIR)¥ipafeal.pch" /YX /Fo"$(INTDIR)¥¥" /Fd"$(INTDIR)¥¥" /FD /c¥ /I"C:¥Program Files¥Microsoft Visual Studio¥VC98¥Include" First round Second round Third round 354 / 365 353 / 365 353 / 366 356 / 372 355 / 372 355 / 372

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

268 CRYPTREC 2000

Key schedule + data-randomization part speed-measurement results

Pentium III (650MHz) Language Assembler Program size 11953 bytes (including encryption/decryption/key schedule) Compiler option /G6 /Gr /Zp16 /MLd /W1 /GX- /Ogx /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS"¥ /Fp"$(INTDIR)¥enck.pch" /YX /Fo"$(INTDIR)¥¥" /Fd"$(INTDIR)¥¥" /FD /c¥ /I"C:¥Program Files¥Microsoft Visual Studio¥VC98¥Include" First round Second round Third round 802 / 823 802 / 823 802 / 823 803 / 824 804 / 824 803 / 824

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

Although there was a difference of about 1 cycle between the encryption time and decryption time, both values were basically the same.

As an indication of the processing-performance value on a 32-bit processor, the applicant has reported implementation results on Pentium III (1 GHz). Speeds of 128 Mbps have been reported for a 32-round FEAL-NX. The speed of the key schedule has been reported as 1.375 µs, with a qualifying statement that implementation optimization had not been performed. When our evaluation result was converted to a Pentium III (1 GHz) equivalent, the average and maximum speeds were 172 and 180 Mbps, respectively, indicating that further speed enhancement has been achieved since the time of application. Conversion of the processing speed of the key schedule at the time of application results in 727 clock cycles/block. Adding to this value only the encryption speed measured during the evaluation produces an average of 1,099 cycles and the maximum speed of 1,082 cycles, indicating that further speed enhancement has been achieved since the time of application.

(Evaluation of implementation in smart cards) The applicant has reported implementation results on an 8-bit processor, 8-MHz Z80H, and a 16-bit processor, Intel's 10-MHz i80286. The speeds on Z80H and i80286 have been reported as 18.2 and 220 kbps, respectively.

2.3 Hardware (HW)-implementation evaluation

HW implementation was evaluated in the environments listed as follows. The results are shown as follows.

269 CRYPTREC 2000

Target device: 0.35-µm ASIC library Design coding language: Verilog-HDL Circuit synthesis: Design Compiler

Data-randomization 34,830 part Circuit size (gates) Key schedule 34,840 Entire primitive 69,970 Critical path (ns) 227.2 Processing speed (Mbps) 281.69

The applicant has reported the results of implementing an 8-round FEAL-N in a 1.5-µm CMOS gate array and a 32-round FEAL-N in a 0.8-µm CMOS gate array. Based on these results, the processing speeds of FEAL-NX have been estimated as follows: Technology Processing speed Number of clock cycles Number of gates 1.5 µm 24 Mb/s 12 MHz 3.9 KGate 0.8 µm 23 Mb/s 12.5 MHz ---

Although it is difficult to make a simple comparison of hardware-evaluation values, we wonder why the results reported by the applicant indicate that the processing speeds have declined in spite of advancements in technology and larger number of clock cycles. However, this situation may be unavoidable given that the values obtained are estimated based on implementation in the past.

References [1] K.Aoki, K.Ohta, Differential-linear cryptanalysis of FEAL-8, IEICE Transactions Fundamentals of Electronics, Communications and Computer Sciences Japan, Vol. E79-A, No.1, pp. 20--27, 1996. [2] K.Aoki, K.Kobayashi, S.Moriai, The best differential characteristic search of FEAL. IEICE Transactions Fundamentals of Electronics, Communications and Computer Sciences Japan, Vol. E81- A, No.1, pp.98--104, 1998. (Japanese preliminary version was presented at ISEC96-31). [3] K. Aoki, K. Ohta, S. Moriai, and M. Matsui, Linear cryptanalysis of FEAL, IEICE Transactions Fundamentals of Electronics, Communications and Computer Science, Vol.E81-A, No.1, pp.88--97, 1998. [4] Kazumaro Aoki, Kazuo Ohta, and Shiho Moriai, Security evaluation of symmetric cipher FEAL, NTT R&D, Vol. 48, No. 10, pp.734-739, Oct. 1999. [5] B. Den Boer, Cryptanalysis of F.E.A.L., Advanced in Cryptology EUROCRYPT'88, LNCS 330, pp.293--299, 1988. [6] E.Biham, A.Shamir, Differential Cryptanalysis of DES-like Cryptosystems (extended abstract),

270 CRYPTREC 2000

CRYPTO'90, 1990. [7] E. Biham and A. Shamir, Differential cryptanalysis of Feal and N-hash, Advances in Cryptology EUROCRYPT'91, LNCS 547, pp.1--16, 1991. [8] H. Gilbert and G. Chasse, A statistical attack of the FEAL-8 cryptsystem, Advances in Cryptology Crypto'90, LNCS 537, pp.22--33, 1991. [9] B. S. Kaliski Jr. and M. J. B. Robshaw, Linear cryptanalysis using multiple approximations and FEAL, Fast Software Encryption, Second International Workshop, LNCS 1008, pp.249--264, 1995. [10] Walter Fumy, Siemens AG, On the F-function of FEAL, CRYPTO'87, 1987. [11] H.Gilbert, G.Chasse, A Statistical Attack Of The FEAL-8 Cryptosystem, CRYPTO'90, 1990. [12] Toshinobu Kaneko, Decoding of FEAL-4 Using a Known Plaintext Attack, ISEC91-25, 1991. [13] T.Kaneko, A known-plaintext attack of FEAL-4 based on the system of linear equations on difference, IEICE Transactions Fundamentals of Electronics, Communications and Computer Science, Vol.E76-A, No.5, pp.781--786, 1993. [14] Dai Kurita and Toshinobu Kaneko, Plaintext Attack of FEAL-6 Using Differential Equations, Shingakukai Fall Convention A-190, 1992. [15] M. Kurita, T. Kaneko, A known plaintext attack of FEAL-4, SCIS93-3B, 1993. [16] Takashi Masuda and Toshinobu Kaneko, Relationship between the Matsui Method and Differential Equation in Decoding the FEAL Cipher, SCIS 94, 1994. [17] M. Matsui and A. Yamagishi, A new method for known plaintext attack of FEAL cipher, IEICE Transactions Fundamentals of Electronics, Communications and Computer Science Vol. E77-A, No.1, pp.2--7, 1994. [18] Mitsuru Matsui, On correlation between the order of S-boxes and the strength of DES, Advances in Cryptology EUROCRYPT'94, volume 950 of Lecture Notes in Computer Science, pp.366--375. Springer-Verlag, 1995. [19] Shoji Miyaguchi, Masahiko Banda, and Kazuo Ohta, FEAL Specification Expansion, Proceedings of SCIS 90, SCIS90-14E, 1990. [20] S.Miyaguchi, The FEAL Cipher Family，CRYPTO'90, 1990. [21] Shoji Miyaguchi, Hikaru Morita, and Tooru Fujioka, FEAL cipher and its applications, Journal of the Electronic Information Communication Society, Symposium on the Security and Reliability of Communication Networks in Information Society, pp. 29-34, Aug. 1991. [22] S.Moriai, K.Aoki, K.Ohta, The best linear expression search of FEAL, IEICE Transactions Fundamentals of Electronics, Communications and Computer Sciences (Japan), Vol. E79-A, No.1, pp.2-11, 1996. [23] Hikaru Morita and Shoji Miyaguchi, FEAL-LSI and its applications, NTT R&D, Vol. 40, No. 10, pp.1371-1380, Oct. 1991. [24] Hikaru Morita, Kazuo Ohta, and Shoji Miyaguchi, Results of switching- closure- test on feal,

271 CRYPTREC 2000

ASIACRYPT'91, volume 739 of Lecture Notes in Computer Science, pp.247-252, 1993. [25] S. Muphy, “The cryptanalysis of FEAL-4 with 20 chosen plaintexts,” Journal of Cryptology, Vol.2, No.3, pp.145--154, 1990. [26] Akihiro Shimizu and Shoji Miyaguchi, High-speed cipher algorithm FEAL, Journal of the Electronic Information Communication Society, Vol. J70-D, No. 7, pp.1413-1423, July 1987. [27] A.Shimizu, S.Miyaguchi, Fast Data Encipherment Algorithm FEAL, Advances in Cryptology EUROCRYPT'87, volume 304 of Lecture Notes in Computer Science, pp.267--278. Springer Verlag, Berlin, 1988. [28] A.Tardy-Corfdir and H. Gilbert, A known plaintext attack of FEAL-4 and FEAL-6, Advances in Cryptology Crypto'91, LNCS576, pp.172--182, 1992. [29] Yukiyasu Kadoo, Eiji Okamoto, and Hiroshi Doi, Analytical Attack of FEAL-4 Using Known Plaintext and FEAL-4 Improvements, SCIS 93, 3A, 1993. [30] Y.Tsunoo, E.Okamoto, T.Uematsu, Ciphertext Only Attack for One-way function of the MAP using One Ciphertext, CRYPTO'94, 1994.

272 CRYPTREC 2000

5.2.3 Hierocrypt-L1

1 Cryptographic Technique

1.1 Technical overview

Hierocrypt-L1 is a symmetric block cipher that was proposed by Toshiba on September 8, 2000 at the Computer Security Study Group of the Information Processing Society. It consists of a byte-conversion layer (S) in which eight 8-bit S-boxes are arranged in parallel, a byte-permutation layer (MDSL) in which 8 two 4x4 MDS arrays on GF(2 ) are arranged in parallel, a byte-permutation layer (MDSH) consisting of 2x2 MDS arrays on GF(232), and a key addition layer (K). Each round of the round function begins with S, followed by MDSL, K, S, and MDSH, and is terminated with K. The last round begins with S, followed by

MDSL, K, and S, and is terminated with K. An encryption process begins with K, and the processing on the last round is performed after the round function has been repeated for five rounds.

Technical point: Achievement of both computation efficiency and security through the use of recursive SPN

Intellectual property rights (based on the application document) (Proposing organization's patents and their handling) Patent application 2000-060482 "Encryption device and decryption method, decryption device and decryption method, as well as computation device" (Application date: 3/06/2000) Patent application 2000-198478 "Encryption device and decryption method, decryption device and decryption method, as well as recording medium" (Application date: 6/30/2000) Patent application 210484 "Encryption device and decryption method, decryption device and decryption method, as well as computation device" (Application date: 7/11/2000) Patent application 2000-211686 "Encryption device, decryption device, and expanded key generation device; expanded key generation method and recording medium" (Application date: 7/12/2000) Patent application 2000-212175 "Parameter-determination device, parameter-determination method, encryption device, and decryption device" (Application date: 7/13/2000) The proposing organization plans to license Hierocrypt-L1 to other companies on a non-exclusive basis and under reasonable conditions.

273 CRYPTREC 2000

Public web address for the specifications of the cryptographic technique being proposed: http://www.toshiba.co.jp/rdc/security/hierocrypt/

1.2 Technical Specifications

(Input/output key size) Input/output size: 64 bits Key size: 128 bits Number of rounds: 6 Structure: Recursive SPN

(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 smallsize. ・ 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. ・ For the diffusion layer, a large number of active S-boxes with large lower limits are generated as candidates using the coding theory, and then these candidates are narrowed down based on security and implementation efficiency. ・ The key schedule is based on a 64-bit Feistel structure, and expanded keys are generated by combining intermediate outputs. A round-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 key setting becomes small during decryption as well.

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 than that of encryption.

274 CRYPTREC 2000

2. Evaluation Results

2.1 Security

Because a SQUARE attack can be applied to seven layers out of six rounds (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.

(Number of rounds that can be broken) By applying Type 1 expansion [3] to Ferguson et al.'s method 1 [2], up to six layers out of the six rounds (12 layers) can be shortcut. The number of chosen plaintexts needed for this is 235, and the number of computations is the same as 272 round function computations [5]. Furthermore, 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 Λ set in which only the left (or right) 4 bytes are active is given, the input in the fourth layer becomes a Λ 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.

(Basis for security) Both the self-evaluation document and detailed evaluation have shown that the maximal differential/linear characteristics probability does not exceed 2-90 in two rounds (four layers) from the lower limit of the number of active S-boxes. Based on an assumption that the keys in individual rounds are independent and identical, using Hong et al.’s method [4], the maximal differential/linear characteristics probability has been proven not to exceed 2-48 in two or more rounds. In three or more rounds as well, the upper limit that has so far been proven is 2-48. Note that the maximal differential/linear characteristics 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 a numerical value that can be proven. The reason it is not possible to conclude that the upper limit of the maximal differential/linear characteristics 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 to have (bijective) S-boxes with the maximal differential probabilities of 2-48 strung in series. Even if multiple S-boxes with the maximal differential probabilities of 2-48 are strung in series, it cannot be concluded that the maximal 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 attacks, the possibility that an

275 CRYPTREC 2000

effective higher order differential will be discovered is presumed to be extremely low given 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 maximized.

2.2 Software (SW)-implementation evaluation

SW implementation was evaluated in the environments listed as follows. The following tables show the evaluation results.

Data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler (486 instructions) Program size 52982 bytes (including encryption/decryption/key schedule) Compiler option VC++6.0 speed priority option is used First round Second round Third round 199 / 201 199 / 201 200 / 201 204 / 206 204 / 206 204 / 205

Ultra SPARC IIi (400MHz) Language ANSI C + assembler Program size 24496 bytes (including encryption/decryption/key schedule) Compiler option cc -native -fast –xarch=v9 –xCC First round Second round Third round 378 (332) / 380 (336) 378 (332) / 380 (336) 378 (332) / 380 (336) 500 (304) / 504 (307) 500 (304) / 504 (308) 500 (304) / 504 (308)

Alpha21264 (463MHz) Language ANSI C Program size 84328 bytes (including encryption/decryption/key schedule) Compiler option cc -O3 First round Second round Third round 210 (179) / 214 (182) 210 (179) / 214 (182) 210 (179) / 213 (182) 210 (179) / 212 (182) 210 (179) / 212 (182) 210 (179) / 212 (182)

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

276 CRYPTREC 2000

Key schedule + data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler (486 instructions) Program size 52982 bytes (including encryption/decryption/key schedule) Compiler option VC++6.0 speed priority option is used First round Second round Third round 374 / 375 374 / 377 374 / 375 616 / 618 616 / 617 616 / 618

Ultra SPARC IIi (400MHz) Language ANSI C + assembler Program size 24496 bytes (including encryption/decryption/key schedule) Compiler option cc -native -fast -xarch=v9 –xCC First round Second round Third round 718 (616) / 721 (620) 718 (616) / 721 (619) 718 (616) / 721 (620) 1203 (1014) / 1215 (1031) 1203 (1012) / 1215 (1030) 1203 (1015) / 1215 (1031)

Alpha21264 (463MHz) Language ANSI C Program size 84328 bytes (including encryption/decryption/key schedule) Compiler option cc -O3 First round Second round Third round 390 (386) / 394 (389) 390 (386) / 394 (389) 390 (386) / 394 (389) 625 (617) / 654 (648) 625 (617) / 653 (648) 625 (617) / 653 (648)

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

Note: In the measurements using Ultra SPARC 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

277 CRYPTREC 2000

Primary cache: 32 KB, secondary cache: 512 KB RAM: 256MB OS: Windows 2000 Professional build 2195 Speed Key generation: 3.07 Mkeys/sec, 179.0 cycles Encryption: 139.13 Mbps, 253.0 cycles Decryption: 67.56 Mbps, 521.0 cycles

Model: JT6N5 Processor: Z80 (5MHz) ROM: 48KB RAM: 1KB EEPROM 8KB Coding language: Z80 Assembler

Memory usage ROM: 26 bytes RAM: 2,447 bytes Speed Encryption: 3.88 ms

2.3 Hardware (HW)-implementation evaluation

HW implementation was evaluated in the environments listed as follows. The results are shown as follows.

Evaluation environment: Mitsubishi 0.35-µm CMOS ASIC library Circuit coding: Verilog-HDL Synthesizer：Design Compiler

Data-randomization 278,130 part Circuit size (gates) Key schedule 95,397 Control circuit ― Entire Primitive 373,526 Critical path (ns) 70.13 Processing speed (Mbps) 912.59

Other: These implementation results reflect a case in which the highest priority is placed on shortening

278 CRYPTREC 2000

the critical path, even if the circuit size increases as a result.

The applicant has reported the following self-evaluation result:

Design environment: Design Compiler made by SYNOPSYS 1999.10-3 Simulation condition: 1.35V 70ºC (1.5 V, 25ºC in the standard case) Throughput: 586 Mbps (128.2MHz, 14 clocks, 6 rounds)

References [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 from http://www.counterpane.com/rijndael.html 2000 [3] J. Daemen, L.R. Knudsen and V. Rijmen, The block cipher SQUARE, 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.

279 CRYPTREC 2000

5.2.4 MISTY1

1. Cryptographic Technique

1.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 [5, 6]. It was submitted by Mitsubishi Electric as a candidate cipher for the Digital 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/linear attacks [3, 4]. MISTY1 can be implemented in a wide range of cipher applications, from 8-bit processors for IC 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) [7, 8, 9, 10, 11]. 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.

Intellectual property rights (based on the application document) (Proposing organization's patent and its handling) Patent No. JP2025358, Data-transformation device and data-transformation method The applicant licenses this patent free of charge to any party that signs the agreement specified by the applicant. The free licensing conditions are described at the following URL, and the public web address for the specification of the cryptographic technique being proposed is: http//www.security.melco.co.jp

1.2 Technical Specifications

(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.

280 CRYPTREC 2000

(Design philosophy) • Security must be backed by a numerical basis. Especially, using a theory on provable security against differential attacks and linear attacks, which are powerful general-purpose breaking 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 IC 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.

1.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 [3, 4]. A 64-bit block cipher, MISTY2, which possesses provable security against differential/linear attacks similar to MISTY1, has also been announced [5, 6]. 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) [15].

2. Evaluation Results

2.1 Security evaluation

It has been theoretically proven that MISTY1's data-randomization part achieves a maximal average differential/linear probability of 2-56 or less in three rounds, and therefore MISTY1 can be considered sufficiently secure against differential and linear attacks. Furthermore, the analysis results of a detailed evaluation indicate that both the data-randomization part and the key schedule are secure against conventional attacks.

281 CRYPTREC 2000

Because implementation-type 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 an IC 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.

– Data-randomization part When analyses were performed on linear attacks, differential attacks, truncated differential attacks, chi-square attacks, partitioning attacks, higher order differential attacks, interpolation attacks, impossible differential attacks, mod n attacks, non-bijective attacks, and Luby-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 estimated. This can be done using an improved higher order differential attack [13, 14] with a number of computations smaller than that required in an exhaustive key search. However, based on these reports, security of MISTY1 itself is not likely to be affected.

Number of rounds attacked and number of computations needed for breaking MISTY1 MISTY1, excluding FL Number of function rounds Data volume Number of Data volume Number of computations computations 8.4 85 5 6.5 4 rounds 2 2 2 2 38.4 116 10.5 17 5 rounds 2 2 2 2 10.5 93 6 rounds - - 2 2

– Key schedule

When the key schedule was analyzed using the exhaustive search method, weak keys/semi-weak keys, related key cryptanalysis, and slide cryptanalysis, none of the attack methods was found to threaten the security of the entire cipher, though the effectiveness of some of the cryptanalysis 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 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 a 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 includes the FL function,

282 CRYPTREC 2000

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.

– Implementation-related 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. 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 IC cards.

2.2 Software (SW)-implementation evaluation

(PC implementation) SW implementation was evaluated in the environments listed as follows. The following tables show the evaluation results. Data-randomization part speed-measurement results

Pentium III (650Mhz) Language Assembler Program size 21353 bytes (including encryption/decryption/key schedule) Compiler option First round Second round Third round 213 / 215 213 / 215 213 / 214 208 / 210 208 / 210 209 / 211

Alpha21264 (463Mhz) Language Assembler Program size 15632 bytes (including encryption/decryption/key schedule) Compiler option First round Second round Third round 203 / 205 203 / 206 203 / 205 206 / 208 206 / 208 206 / 208

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

283 CRYPTREC 2000

Key schedule + data-randomization part speed-measurement results

Pentium III (650Mhz) Language Assembler Program size 17681 bytes (including encryption/decryption/key schedule) Compiler option First round Second round Third round 357 / 358 357 / 358 357 / 358 350 / 351 350 / 351 350 / 351

Alpha21264 (463Mhz) Language Assembler Program size 10088 bytes (including encryption/decryption/key schedule) Compiler option First round Second round Third round 334 / 338 337 / 338 334 / 338 337 / 340 337 / 340 337 / 340

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

Although there was a difference of about five cycles between the encryption time and decryption time, both values were basically the same. As an indication of processing performance, the applicant has reported 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.

(IC card implementation) As an indication of processing performance on embedded 16- and 8-bit microcomputers, the applicant has reported implementation results on an M16C (20 MHz) and H8/300 (3.57 MHz) [11]. Implementation results on an 8-bit processor Z80 (5 MHz) have also been reported by Sano et al [12]. The units for both encryption and decryption are cycles/block.

Processor Encryption and key-schedule ROM RAM speed M16C 1877,743 3400 byte 64 byte H8/300 6018,1240 1900 byte 43 byte Z80 25486 (including key schedule) 1598 byte 44 byte

284 CRYPTREC 2000

2.3 Hardware (HW)-implementation evaluation

HW implementation was evaluated in the environment described as follows. The results are shown as follows.

Coding language: VHDL; simulator: ModelSim5.4a; design library: 0.25-µm CMOS ASIC Design Library; logical synthesis tool: Design Compiler. 2000.05-1 Data-randomization *1 19,935 part *2 10,609 *1 44,773 Key schedule *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 Processing speed (Mbps) *2 288 *1: Logical synthesis with speed priority

*2: Logical synthesis with size priority

The applicant has reported simulation results using Mitsubishi 0.35-µm CMOS ASIC Design Library [1, 2]. Implementation 1: 7.6 gates, 72 Mbps Implementation 2: 50 gates, 800 Mbps

References [1] Tetsuya Ichikawa, Junji Katoh, and Mitsuru Matsui, A method of implementing secret key cipher MISTY1 in Hardware, Proceedings of SCIS 98, 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] 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. [4] Matsui, M., 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. [5] Mitsuru Matsui, Block Cipher Algorithm MISTY1, Shingaku Giho ISEC96-11, 1996. [6] Matsui, M., 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.

285 CRYPTREC 2000

[7] Junko Nakajima and Mitsuru Matsui, Fast Software Implementation of MISTY (I), Shingaku Giho ISEC97-12, 1997. [8] Junko Nakajima and Mitsuru Matsui, Fast Software Implementation of MISTY (II), Proceedings of SCIS 98, SCIS98-9.1.B, 1998. [9] Junko Nakajima, Mitsuru Matsui, Fast Software Implementation of MISTY1 on Alpha Processors, IEICE Trans. Funcationals, Vol E82-A, No.1 January 1999. [10] Junko Nakajima and Mitsuru Matsui, Fast Software Implementation of MISTY (III), Shingaku Giho ISEC2000-81, 2000. [11] Junko Nakajima and Mitsuru Matsui, Optimal Software Implementation of Symmetric Cipher MISTY1, Proceedings of SCIS 2001, 13A-3, 2001. [12] 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. [13] Tanaka, H., Hisamatsu,M., Kaneko,T., Higher Order Differential Attack of MISTY1 without FL functions, JWIS’98, ISEC98-66, pp.143-150, 1998. [14] Hidemaro Tanaka, Shuji Ishii, and Toshinobu Kaneko, Strength Evaluation of KASUMI and MISTY, Proceedings of SCIS 2001, 12A-1, pp. 647-652, 2001. [15] 3GPP, KASUMI, ETSI/SAGE Specification, 1999. (http://www.etsi.org/dvbandca/3GPP/3gppspecs.htm) [15] 3GPP, KASUMI, ETSI/SAGE Specification, 1999. (http://www.etsi.org/dvbandca/3GPP/3gppspecs.htm)

286 CRYPTREC 2000

5.2.5 Triple DES

1. Cryptographic Technique

1.1 Technical overview

DES is a symmetric block cipher that was proposed by Tuchman in 1979 [1]. Triple DES is a combination cipher based on DES (Data Encryption Standard) that was approved as a FIPS (Federal Information Processing Standard) cipher by the U.S. government in 1977, and its strength is enhanced by repeating DES three times. At present, Triple DES is specified as a Triple Data Encryption Algorithm (TDEA) in ANSI (American National Standards Institute) X9.52, along with seven usage modes, and efforts to establish it as FIPS (FIPS46-3) are also underway [2, 3].

Intellectual property rights (Proposing organization's patents and their handling) Although patents related to DES were granted in both the U.S. and Japan, they all have expired. U.S.: Patent Number 3,962,529 (Application date: February 24, 1975, Effective date: June 8, 1976, Expiration date: June 8, 1993) Japan: Disclosure number S59-45269 (Application date: February 18, 1976, Formal notice date: November 5, 1984, Expiration date: February 18, 1996)

1.2 Technical Specifications

Because Triple DES has a structure in which DES, a Feistel cipher, is repeated three times, it is classified as a symmetric block cipher with a 64-bit input/output size, just as DES is. If P denotes a plaintext, C denotes a ciphertext, and EK and DK denote encryption and decryption using key K, encryption and decryption can be expressed as follows:

Encryption: C = EK3(DK2(EK1(P)))

Decryption: P = DK1(EK2(DK3(C)))

During this process, the following three options are available, depending on how keys K1, K2, and K3 are chosen [2].

① K 1 , K 2 , and K 3 are independent.

② K 1 and K 2 are independent, K 1 = K 3

③ K 1 = K 2 = K 3 Especially in ③, by making all three keys the same, compatibility with normal DES is maintained. Generally, ① and ② are called Triple DES (3-Key) and Triple DES (2-Key), respectively. Because the

287 CRYPTREC 2000

effective key size of DES is 56 bits, the keys sizes in ①, ②, and ③ are 168, 112, and 56 bits, respectively. Seven usage modes are specified for Triple DES in ANSI X9.52. These are expanded usage modes (TECB, TCBC, TCFB, and TOFB), which are the extensions of 64-bit block cipher usage modes (ECB, CBC, CFB, and OFB) specified in ISO8372, and others (TCBC-I, TCFB-P, and TOFB-I) [2].

1.3 Other

Ever since DES was announced, there has been a concern about its resistance to an attack with all possible key combinations because of its short key length of 56 bits [5]. As a result, discussions took place about increasing its key length by cascading DES, leading to the creation of Triple DES. DES is repeated three times, and not twice, to avoid meet-in-the-middle attacks [4]. In 1997, 20 years after its introduction, DES was successfully broken in a breaking contest (DES Challenge-I) held by RSA Corporation of the U.S. More recently, it has also been reported that DES was broken in approximately 22 hours in the DES Challenge-III (1999) [6]. In the U.S., Triple DES has been completely established as a FIPS cipher, and therefore, U.S. governmental institutions as well as ordinary DES users are expected to increasingly migrate to Triple DES.

2. Evaluation Results

2.1 Security

Table 5-1 shows the major security evaluation results that have been reported on Triple DES (① 3-key Triple DES, ② 2-key Triple DES, and ③ DES). It has been reported that DES can be more effectively broken (i.e., is decodable in a scientific sense) with differential and linear cryptanalysis methods, which are typical short-cut methods, than with an exhaustive key search. The number of computations necessary for an exhaustive search (256) of DES has already approached a decodable level in a practical sense, because there has been a report that DES was successfully broken in approximately 22 hours in a breaking contest (DES Challenge-III) [6]. Both Triple DES (2-key) and Triple DES (3-key) can be considered secure against differential and linear cryptanalysis methods, which are typical short-cut methods. However, it has been reported that these ciphers can be more effectively broken (i.e., broken in a scientific sense) with a meet-in-the-middle attack, which focuses on the fact that Triple DES is a combination cipher, than with an exhaustive key search. Especially, Triple DES (2-key) can be broken in a scientific sense with about 257 computations (256 chosen plaintexts). This is about twice the number of computations needed in an exhaustive search of DES, and therefore Triple DES (2-key) is already approaching a decodable level in a practical sense. On the other hand, Triple DES (3-key) can be broken in a scientific sense with about 2108.2 computations

288 CRYPTREC 2000

(256 chosen plaintexts). This is a secure level in a practical sense for the time being, considering the computational capability of the present computers. In summarizing these results, use of Triple DES for the Digital Government should not pose any problems for a while, as long as its is Triple DES (3-key).

Table 5-1 Major security evaluation results of Triple DES (number of computations necessary for breaking*1） Single-DES Triple DES (2-key) Triple DES (3-key) Brute Force Method

56 112 168 Exhaustive search 2 2 2

Merkle-Hellman 57 112 2 2 Meet-in-the-middle 56 56 attack (2 chosen plaintexts) (2 chosen plaintexts) 108.2 Lucks attack － 2 120−log N Oorshot-Wiener 2 2 －－ Known plaintext attack (Ｎknown plaintexts) Short Cut Method

37 Differential 2 *2 42

*2: Upper limit value determined from the maximal differential characteristics probability of 2-54.1 for 16-round DES by

considering Triple DES as a 48-round DES.

*3: Upper limit value determined from the maximal linear characteristics probability of 2-44.9 for 16-round DES by

considering Triple DES as a 48-round DES.

*4: A related key attack is not considered to pose an actual threat because the conditions for the attack to become valid

are extremely limited.

These issues are explained in more detail as follows.

(1) Resistance to Brute Force Methods

Triple DES (2-key and 3-key) is currently considered secure enough against an exhaustive key search. The 56-bit key of DES was successfully broken in a breaking contest (DES Challenge-I) held by RSA Corporation of the U.S. in 1997, and more recently, it has also been reported that DES was broken in approximately 22 hours in the DES Challenge-III (1999) [6]. Therefore, it is no longer possible to consider DES to be sufficiently secure.

289 CRYPTREC 2000

On the other hand, because Triple DES is a combination cipher, it has been demonstrated that, under certain conditions, its actual security does not improve much as its key length is expanded. As a representative example, in the chosen-plaintext attack proposed by Merkle and Hellman, it has been demonstrated that the number of computations can be significantly reduced from an exhaustive search, i.e., to 257 (2112 with an exhaustive search) for Triple DES (2-key) and to 2112 (2168 with an exhaustive search) for Triple DES (3-key) [7]. Note that with this cryptanalysis, the number of chosen plaintexts necessary is 255 when the breaking success rate is set at 50%. Consequently, the size of the external storage medium necessary for storing the plaintext-key pairs is a massive 4.03 x 1010 Gbits, and it is also difficult to obtain the necessary information through a communication network. Therefore, the possibility of this breaking method becoming a realistic threat is considered small at present [8]. Note that Lucks has proposed a breaking method that reduces the number of processes needed in the chosen-plaintext attack of Merkle and Hellman, and has reported that Triple DES (3-key) can be broken with about 2108 computations [9]. However, the possibility of Lucks' breaking method becoming a realistic threat is also considered small at present because of the size of the storage medium required. As for Triple DES (2-key), Oorschot and Wiener have proposed a known-plaintext attack by expanding the chosen-plaintext attack of Merkle and Hellman, and pointed out that it is possible to break Triple DES 120-log N (2-key) with 2 2 computations if 120 - N bit recording medium is allocated for N known plaintexts [10]. However, it is also expected that several decades will be required before this breaking method becomes a realistic threat [8].

(2) Resistance to Short Cut Methods

Typical short-cut methods include differential cryptanalysis and linear cryptanalysis. It has been demonstrated that DES can be broken with differential cryptanalysis using 247 chosen plaintexts and 237 computations [11]. It has also been demonstrated that DES can be broken with linear cryptanalysis using 243 known plaintexts and 242 computations [12]. Therefore, if Triple DES is considered a 48-round DES, Triple DES' maximal differential characteristics probability and maximal linear characteristics probability estimated from DES' maximal differential characteristics probability (2-54.1 in 16 rounds) and maximal linear characteristics probability (2-44.9 in 16 rounds), which have already been identified, are sufficiently small, so that the number of chosen/known plaintexts necessary for an attack becomes huge. Therefore, even if all 264 plaintext- ciphertext pairs that can be theoretically created under a 64-bit block length are used, it is considered impossible to effectively narrow down key candidates. A research result has been reported showing that Triple DES (3-key) can be broken using a number of computations that is smaller than that used in the chosen-plaintext attack of Merkle and Hellman [13]. Specifically, it has been demonstrated that Triple DES (3-key) can be broken with between 256 and 272 computations using one pair of keys possessing a certain relationship with one pair of chosen plaintexts

290 CRYPTREC 2000

and ciphertexts. However, because this attack method cannot be applied to Triple DES (2-key) and the environments that can be attacked are extremely limited, it is not likely to become an actual threat.

2.2 Software (SW) implementation evaluation

SW implementation was evaluated in the environments described as follows. The following tables show the evaluation results.

Data-randomization part speed-measurement results

Pentium III (650Mhz) Language Assembler Program size 44385 bytes (including encryption/decryption/key schedule) Compiler option First round Second round Third round 854 / 856 854 / 857 854 / 856 854 / 856 854 / 856 854 / 857 Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

Key schedule + data-randomization part speed-measurement results

Pentium III (650Mhz) Language Assembler Program size 44679 bytes (including encryption/decryption/key schedule) Compiler option First round Second round Third round 1963 / 1967 1967 / 1971 1963 / 1967 1971 / 1975 1971 / 1975 1971 / 1975 Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

2.3 Hardware (HW)-implementation evaluation

For HW implementation of Triple DES, fast implementation results of Triple DES using an ASIC have been reported by Ichikawa et al. [14]. These results are shown as follows.

– Evaluation target: ASIC (0.35-µm rule ASIC library by Mitsubishi Electric)

291 CRYPTREC 2000

– Coding language: Verilog-HDL – Evaluation condition: Worst case

• Gate size (NAND gate equivalent): Total: 148147 gates (encryption and decryption areas: 124888, key schedule: 23207) • Throughput: 407.4 Mbps

292 CRYPTREC 2000

References [1] W.Tuchman, Hellman Presents No Shortcut Solutions to DES, IEEE Spectrum, 16(7), pp.40-41, 1979. [2] American National Standards Institute, X9.52-1998, Triple Data Encryption Algorithm Modes of Operation, 1998. [3] National Institute of Standards and Technology, Data Encryption Standard, Federal Information Processing Standards Publication 46-3, 1999. [4] W.Diffie and M.E.Hellman, Exhaustive cryptanalysis of the NBS data encryption standard, Computer, 10, 6, pp.74-84, June 1977. [5] Taniguchi, Ohta, and Okubo, Recent trend toward standardization surrounding Triple DES, Financial Research Vol. 18, No. 1, Japan Banking Financial Research Institute, 1999. [6] Une and Ohta, Current status and issues surrounding symmetric ciphers — from DES to AES, Financial Research Vol. 18, No. 2, Japan Banking Financial Research Institute, 1999. [7] R.C.Merkle and M.Hellman, On the Security of Multiple Encryption, Communications of the ACM, Vol.24, No.7, 1981, pp.465-467. [8] K.Kusuda and T.Matsumoto, A Strength Evaluation of the Data Encryption Standard, IMES Discussion Paper, No.97-E-5, Institute for Monetary and Economic Studies, Bank of Japan, 1997. [9] S.Lucks, Attacking Triple DES, proceedings of Fast Software Encryption'98, LNCS, Vol.1372, 1998, pp.239-253. [10] P.C.van Oorschot and M.J.Wiener, A known plaintext attack on two-key triple encryption, Advances in Cryptology — Proceedings of EUROCRYPTO90, LNCS, Vol.473, Springer-Verlag, 1990, pp.318-325. [11] E.Biham and A.Shamir, Differential Cryptanalysis of the Full 16-round DES, Advances in Cryptology — Proceedings of CRYPTO92, LNCS, Vol.740, Springer-Verlag, 1993, pp.487-496. [12] M.Matsui, Linear Cryptanalysis Method for DES Cipher, Advances in Cryptology Proceedings of EUROCRYPT93, LNCS, Vol.765, Springer-Verlag, 1994, pp.386-397. [13] J.Kelsey, B.Schneier, and D.Wagner, Key-Schedule Cryptanalysis of IDEA, G-DES, GOST, SAFER, and Triple DES, Advances in Cryptology CRYPT96, LNCS, Vol.1109, pp.237-251, Springer-Verlag, 1996. [14] 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.

293 CRYPTREC 2000

5.2.6 Camellia

1． Cryptographic Technique

1.1 Technical overview

Camellia is a 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 SW and HW. In HW implementation in particular, Camellia belongs to the smallest group in the world at present in terms of encryption/decryption speed, 22.0 Mbps (/Kgates) and gate count (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. Keywords: Compact HW implementation, inverse function, 8-bit S-box + logical operation, 1-round SPN

Intellectual property rights (based on the application document) (Proposing organization's patent and its handling) ・ Application number (2000-064614) ・ Application date: March 9, 2000 ・ Title of the invention: Data-transformation device, data-transformation method, and computer-readable recording medium in which a program for making a computer execute the data-transformation method is recorded ・ Applicants: NTT and Mitsubishi Electric Corporation The applicants intend to license this patent to others on a non-exclusive basis and under reasonable conditions. (Related patents of other companies) None

The public web address for the specification of the cryptographic technique being proposed is: http//info.isl.ntt.co.jp/camellia/index-j.html

294 CRYPTREC 2000

1.2 Technical Specifications

The basic portion of the round function components consists of S-boxes and EXOR, while the components of the FL/FL-1 functions consist 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 key generation.

(Data-randomization part and decryption function) (Data-randomization part) • 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 cyclic shift, and EXOR. The difference between MISTY and Camellia in terms of FL/FL-1 functions is the introduction of the 1-bit cyclic shift. Initial and final EXORs are performed immediately before the first round and immediately following the last round, respectively. In the key schedule, 26 64-bit expanded keys are generated from a 128-bit secret key K. (Part of the procedure for generating expanded keys is the same as that used in the data-randomization part.) 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,k r )

R = L r r−1

When r = 6 or 12, FL/FL-1 functions are used in some parts, to break structural uniformity. Finally, EXORing with two expanded keys is performed. ・ 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.

(Decryption function) Decryption of the Camellia cipher is performed in the same manner as encryption, except by

295 CRYPTREC 2000

reversing the order of the expanded keys.

(Key schedule) The key schedule uses two 128-bit and four 64-bit data items. Using these values, two 128-bit data elements, 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 has a 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 a 192/256-bit key).

(Security design) Camellia's security has been designed to ensure sufficient resistance against differential attacks, linear attacks, and truncated differential attacks, which are considered the main attack methods, based on estimated upper limits of the maximal average differential characteristics probability and the maximal average linear characteristics probability. Resistance to other attacks, such as higher order differential attacks, interpolation attacks, related key attacks, impossible differential attacks, and slide attacks, has also been taken into account at the design stage.

1.3 Other

The Camellia cipher [3] has been developed and designed based on several cryptographic techniques, including NTT's proprietary cryptographic technique E2 [1] and Mitsubishi Electric Corporation's proprietary cryptographic technique MISTY [2]. For example, the design guideline for the round function (F function) and the linear transformation function (P function) is based on the design guideline for the F function and the P function of E2. The design guideline for the FL/FL-1 functions is based on the design guideline for the FL function of MISTY. The major change in cipher design is as follows. • Implementation performance on PCs, IC cards (Smart Cards), and HW has been improved.

2. Evaluation Results

2．1 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

296 CRYPTREC 2000

that a truncated differential route search applied to a 7-round modified Camellia cipher without the auxiliary functions FL/FL-1 has shown some effective attacking characteristics [4]. An overview of the detailed evaluation results follows. • In a 5-round modified 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. • Because Camellia uses a bijective round function, it should be possible to estimate a key for a 6-round modified Camellia cipher without the auxiliary functions FL/FL-1, using a smaller number of computations than all possible combinations of secret keys. • By applying a boomerang attack that uses two differentials, it should be possible to estimate a key for an 8-round modified Camellia cipher without the auxiliary functions FL/FL-1, using a smaller number of computations than all possible combinations of secret keys. A boomerang attack also is considered to be the most effective analysis method against the Camellia cipher. • In some cases of the key scheduler, it was possible to compute 1 byte of an unknown secret key from 5 bytes of a secret key and 6 bytes of an intermediate key. No security problem has been discovered from truncated differential/linear cryptanalysis, high order cryptanalysis, cryptanalysis with impossible differential attack, interpolation cryptanalysis, linear sum cryptanalysis, and slide cryptanalysis, along with differential cryptanalysis and linear cryptanalysis.

2．2 Software (SW)-implementation evaluation

(PC implementation) SW implementation was evaluated in the environments listed as follows. The following tables show the evaluation results.

Data-randomization part speed-measurement results

Pentium III (650MHz)

297 CRYPTREC 2000

Language Assembler Program size 29285 bytes (including encryption/decryption/key schedule) Compiler option /G6 /ML /O2 /Ob2 /Og /Oi /Ot /Ox /Oy /Gr /I "C:¥Program Files¥Microsoft Visual Studio¥VC98¥Include" First round Second round Third round 326 / 327 326 / 327 326 / 327 326 / 328 326 / 327 326 / 327

Ultra SPARC IIi (400MHz) Language Assembler Program size 15240 bytes (including encryption/decryption/key schedule) Compiler option -fast –xtarget=ultra -xarch=v9a First round Second round Third round 355 / 360 355 / 358 355 / 357 355 / 357 355 / 358 355 / 357

Alpha21264 (463MHz) Language Assembler Program size 31552 bytes (including encryption/decryption/key schedule) Compiler option -O -arch ev6 First round Second round Third round 282 / 288 282 / 289 282 / 288 282 / 288 282 / 288 282 / 289

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

Key schedule + data-randomization part speed-measurement results

Pentium III (650MHz) Language Assembler Program size 20110 bytes (including encryption/decryption/key schedule) 20236 bytes (including encryption/decryption/key schedule) Compiler option /G6 /ML /O2 /Ob2 /Og /Oi /Ot /Ox /Oy /Gr /I "C:¥Program Files¥Microsoft Visual Studio¥VC98¥Include First round Second round Third round 467 / 487 467 / 487 467 / 487 474 / 493 474 / 494 474 / 493

298 CRYPTREC 2000

Ultra SPARC IIi (400MHz) Language Assembler Program size 23992 bytes (including encryption/decryption/key schedule) Compiler option -fast –xcrossfile -xtarget=ultra –xarch=v9a First round Second round Third round 403 / 408 403 / 407 403 / 408 403 / 407 403 / 407 403 / 408

Alpha21264 (463MHz) Language Assembler Program size 25792 bytes (including encryption/decryption/key schedule) Compiler option -O -arch ev6 First round Second round Third round 448 / 454 448 / 454 448 / 455 435 / 439 435 / 439 435 / 439

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

According to the applicant's implementation examples, a result of 24.07 Mbps was achieved using Java on a 32-bit PC. In optimized implementation using an assembler language, 276 Mbps and 308 cycles were achieved on a Pentium III (800 MHz) and a Pentium Pro (200 MHz), respectively.

(IC-card implementation) IC card implementation results based on Z80 are shown as follows. (Note: The proposing organization evaluated the data for the 128-bit key.) • Processing speed Key generation: 5,146 states Encryption: 28,382 states • Memory ROM: 1,698 bytes RAM: 62 bytes

2．3 Hardware (HW)-implementation evaluation

HW implementation was evaluated in the following environment. The evaluation results follow. Note that the evaluation was performed on a 256-bit key encryption circuit, which was designed using Verilog and was synthesized under conditions that focus on speed and area under the same coding condition. Coding language: Verilog-HDL

299 CRYPTREC 2000

Simulator: VCS5.1 Design library: 0.25-µm CMOS ASIC Design Library Logic synthesis tool: Design Compiler, 2000.05-1 Operating conditions: 0°C - 70°C, 3.3 V ± 5%

The following table shows the hardware-evaluation results.

Data-randomization *1 16,327 part *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 Processing speed (Mbps) *2 397 *1 Logical synthesis with speed priority

*2 Logical synthesis with size priority

These values appear reasonable considering a key-length difference.

The proposing organization 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 Kgates (0.35-µm CMOS ASIC). Throughput: 212.2 Mbps

References [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, LNC, pp54-68, 1997 [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, SAC2000pp.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.

300 CRYPTREC 2000

5.2.7 CIPHERUNICORN-A

1. Cryptographic Technique

1.1 Technical overview

CIPHERUNICORN-A is a 128-bit block cipher with a block length of 128 bits and key lengths of 128, 192, and 256 bits. It was developed by NEC Corporation in 2000 [1], and has been proposed by NEC. The basic structure 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 an expanded-keys 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, with a cipher strength evaluation system [2] that performs the elementary statistical evaluation by regarding the round function as a black box. As a result, it has been reported that no data-shuffling bias was detected in any of the items in the elementary statistical evaluation of the round function. CIPHERUNICORN-A can be implemented in both software and hardware, and it has reportedly been designed to perform high-speed processing using a 32-bit processor in particular.

Intellectual property rights (based on the application document) (Proposing organization's patent and its handling) Patent: Application No. H9-213274 Trademark: Registration No. 4221077 Document: CIPHERUNICORN-A Program NEC will grant, free of charge, the use of the patent, documents and trademarks, and their reproduction and distribution, as necessary for evaluating the cipher. The public web address for the specification of the cryptographic technique being proposed is: http://www.mesh.ne.jp/hnes/products/security/angou.html

1.2 Technical Specifications

This cipher uses a block length of 128 bits and key lengths of 128, 192, and 256 bits, which are the same interface as AES, and has a 16-round Feistel structure. For key scheduling, a 2304-bit expanded key is generated by shuffling the secret key.

301 CRYPTREC 2000

(Data-randomization part) The round function is a 64-bit input/output function that uses expanded keys (function keys and seed keys) of 32 bits x 4 (a total of 128 bits), and consists of an S-box, 32-bit arithmetic addition, 32-bit constant arithmetic multiplication, and rotation. Note that this function is not a bijective function. Inside the function, 64-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, ultimately producing 64-bit output data. Part of the main stream is a data-dependent function according to the value of the temporary key.

(Key schedule) The key schedule has an extended Feistel structure that uses MT functions as the round functions, and outputs 32-bit intermediate keys from each MT function while shuffling the secret key. The MT functions use the same T0 function as the round function, and 32-bit constant arithmetic multiplication. After 72 intermediate keys have been generated, their orders are rearranged and used as the expanded keys for the individual rounds.

(Design philosophy) Differential cryptanalysis and linear cryptanalysis estimate key information using the shuffling bias in the round function. Therefore, a design philosophy is to build a round function in which shuffling bias cannot be detected. The round function that satisfies the following conditions has been designed with a 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.

302 CRYPTREC 2000

1.3 Other

CIPHERUNICORN-E, which is a 64-bit block cipher, also has been designed with the cipher strength evaluation system.

2 Evaluation Results

2.1 Security evaluation

(Overall evaluation) The configuration of CIPHERUNICORN-A's 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. Consequently, the minimum number of rounds required for achieving the expected strength, and the security margin, have not been accurately assessed. Nevertheless, a model that uses an mF function in which the configuration of the round function has been simplified based on appropriate considerations has been shown to achieve an upper bound of the maximal differential characteristics probability of 2-128 or less in 15 or more rounds, and an upper bound of the maximal linear characteristics probability of 2-128 or less in 14 or more rounds. To obtain accurate strength of the original cipher, it is necessary to replace the mF function with the original round function for more detailed evaluation. However, it is expected that roughly the same level of security as that of a model that has been simplified based on appropriate assumptions would be achieved. Additionally, when the fact that the specified number of rounds is 16 is collectively taken into consideration, it seems impossible to break CIPHERUNICORN-A using the state-of-the-art cryptanalysis techniques. Therefore, CIPHERUNICORN-A can be considered a secure cipher for the e-Government. However, 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 CIPHERUNICORN-A is to be used in an environment in which a side channel attack may occur.

(Security evaluation against each type of theoretical cryptanalysis) a) Elementary statistical evaluation Favorable results have been obtained for all items in the elementary statistical evaluation of the round function, which indicates excellent elementary statistical properties of randomness.

303 CRYPTREC 2000

Note that the applicant states that the round function was designed such that a 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, the self-evaluation document states that sufficient shuffling is being performed, even in the main stream or the temporary key generation mechanizm alone. However, it has been pointed out that shuffling may not be sufficient in one of these areas alone, because the effects of multiple T functions may cancel each other with a high probability depending on the input data and key value.

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. Security can be discussed using this model. This is because it is generally expected that the security of the original cipher is at least equivalent to that of a model that has been simplified based on appropriate assumptions. For CIPHERUNICORN-A as well, the self-evaluation document states that security has been evaluated using an mF function in which the round function has been simplified based on appropriate considerations. These considerations include (1) replacing arithmetic addition with EXOR, (2) replacing constant multiplication with a process that aggregates input bits to the upper 1 byte of the 32-bit data, and (3) replacing the A3 function with a rotation process for each truncated vector. Using a truncated vector search for this model, the upper bound of the maximal differential characteristics probability in 15 rounds has been evaluated to be 2-120. For the same model, another estimation shows that the upper bound of the maximal differential characteristics probability in 15 rounds is 2-140. Based on these results, the existence of a differential path to 14 rounds at the most can be expected in a model that uses an mF function. Therefore, considering that CIPHERUNICORN-A's number of rounds is 16, the application of differential cryptanalysis is nearly impossible, and CIPHERUNICORN-A can be considered secure against differential cryptanalysis. Furthermore, it can be expected that by performing a more detailed evaluation after replacing the mF function with the original round function, more accurate strength can be obtained.

c) Linear cryptanalysis As with the differential cryptanalysis, the self-evaluation document states that the maximal linear characteristics probability of the mF function has been evaluated to be 2-22.47, and the upper bound of the maximal linear characteristics probability in 15 rounds

304 CRYPTREC 2000

has been evaluated to be 2-157.29 when a truncated vector search is applied to a model that uses an mF function. For the same model, another estimation shows that the maximal linear characteristics probability of the mF function and the upper bound of the maximal linear characteristics probability in 14 rounds are 2-20.08 and 2-140.56, respectively. Based on these results, because the existence of a linear path to 13 rounds at the most can be expected in a model that uses an mF function, the application of linear cryptanalysis is nearly impossible. CIPHERUNICORN-A can be considered secure against linear cryptanalysis, considering that its number of rounds is 16. Note that it can be expected that by performing a more detailed evaluation after replacing the mF function with the original round function, more accurate strength can be obtained.

d) Higher order differential attack, interpolation attack, slide attack, and mod n attack No particular problems were found out with respect to these attacks.

e) Related key attack Because of the configuration of the key schedule, CIPHERUNICORN-A can be considered resistant to related key attacks.

(Resistance to side channel attack) CIPHERUNICORN-A's round function has a part of configuration which changes depending on the data. The internal configuration has two processing areas, 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, and a power analysis attack is considered effective when the same data goes through multiple processes. Therefore, CIPHERUNICORN-A may not be very resistant to side channel attacks, such as timing attack and power analysis attack. Consequently, when using CIPHERUNICORN-A in an environment in which a threat of side channel attacks is present, it is desirable to carefully institute defensive measures.

2.2 Software (SW)-implementation evaluation

SW implementation was evaluated in the following environments. The following tables show the evaluation results.

305 CRYPTREC 2000

Data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler Program size 3984 bytes (including encryption/decryption/key schedule) Compiler option Specify "/O2/Oy-" (execution speed) First round Second round Third round 1569 / 1574 1570 / 1574 1570 / 1574 1574 / 1578 1574 / 1577 1574 / 1578

Ultra SPARC IIi (400MHz) Language ANSI C Program size 5644 bytes (including encryption/decryption/key schedule) Compiler option Specify "-v -fast" First round Second round Third round 2273 / 2282 2273 / 2282 2273 / 2282 2302 / 2326 2309 / 2327 2310 / 2327

Alpha21264 (463MHz) Language ANSI C Program size 8472 bytes (including encryption/decryption/key schedule) Compiler option Specify "-O4" First round Second round Third round 1834 / 1843 1828 / 1842 1828 / 1842 1769 / 1782 1769 / 1782 1769 / 1782

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

Key schedule + data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler Program size 4306 bytes (including encryption/decryption/key schedule) Compiler option Specify "/O2/Oy-" (execution speed) First round Second round Third round 4788 / 4822 4788 / 4814 4787 / 4830 4799 / 4931 4798 / 4815 4806 / 4814

306 CRYPTREC 2000

Ultra SPARC IIi (400MHz) Language ANSI C Program size 5644 bytes (including encryption/decryption/key schedule) Compiler option Specify "-v -fast" First round Second round Third round 7970 / 8160 7961 / 8164 7900 / 8161 8802 / 9025 8817 / 9034 8823 / 9028

Alpha21264 (463MHz) Language ANSI C Program size 8552 bytes (including encryption/decryption/key schedule) Compiler option Specify "-O4" First round Second round Third round 4610 / 4623 4610 / 4628 4610 / 4624 5071 / 5092 5071 / 5100 5071 / 5095

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

For all measurement items in encryption and decryption, including key generation, CIPHERUNICORN-A belongs to the group with the slowest processing speed among the 128-bit block ciphers submitted for evaluation, regardless of the measurement platform. On Pentium III, CIPHERUNICORN-A is about the same as Triple DES in all measurement items.

There is no description or public information related to software implementation on 8-bit CPUs, as represented by IC cards.

2.3 Hardware (HW)-implementation evaluation

Although the applicant states that hardware implementation is possible, CIPHERUNICORN-A was not included in hardware-implementation evaluation because there is no description or public information related to hardware implementation.

References [1] Yukiyasu Kadoo, Hiroyasu Kubo, Hiroshi Miyauchi, and Katsuhiro Nakamura, 128-bit Block Cipher CIPHERUNICORN-A, 2000 Ciphers and Information Security Symposium SCIS2000, A18, 2000.

307 CRYPTREC 2000

[2] Yukiyasu Kadoo, Ryoji Ota, Hiroshi Miyauchi, and Katsuhiro Nakamura, Distributed Cipher-Strength Evaluation System, 2000 Ciphers and Information Security Symposium SCIS2000, A53, 2000.

308 CRYPTREC 2000

5.2.8 Hierocrypt-3

1. Cryptographic Technique

1.1 Technical overview

Hierocrypt-3 is a symmetric block cipher [1] that was proposed by Toshiba in 2000 at the Computer Security Study Group of the Information Processing Society. It has a block length of 128 bits and supports three key lengths (128, 192, and 256 bits). Hierocrypt-3 is a cipher algorithm that has been designed with the objectives of achieving the level of security expected of key lengths and efficient software/hardware implementation. It focuses on fast encryption speed in smart cards and middleware in particular.

Intellectual property rights (based on the application document) (Proposing organization's patents and their handling) • Patent application 2000-060482 "Encryption device and decryption method, decryption device and decryption method, as well as computation device" (Application date: 3/06/2000) • Patent application 2000-198478 "Encryption device and decryption method, decryption device and decryption method, as well as recording medium" Application date: 6/30/2000 • Patent application 2000-210484 "Encryption device and decryption method, decryption device and decryption method, as well as computation device" (Application date: 7/11/2000) • Patent application 2000-211686 "Encryption device, decryption device and expanded key generation device; expanded key generation method and recording medium" (Application date: 7/12/2000) • Patent application 2000-212175 "Parameter-determination device, parameter-determination method, encryption device, and decryption device" (Application date: 7/13/2000) The proposing organization plans to license Hierocrypt-3 to other companies on a non-exclusive basis and under reasonable conditions. The public web address for the specification of the cryptographic technique being proposed is: http://www.toshiba.co.jp/rdc/security/hierocrypt/

1.2 Technical Specifications

• The goal is to design a cipher that is sufficiently strong against major symmetric cipher attacks, that

309 CRYPTREC 2000

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. • The recursive SPN structure is extremely simple, and configuration elements can be designed more or less independently while maintaining sufficient security. Additionally, Hierocrypt-3 can flexibly cope with block-length changes. • The 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. • For the diffusion layer, a large number of active S-boxes with large lower limits are generated as candidates using the coding theory, and then these candidates are narrowed down based on security and implementation efficiency. • The key schedule 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 an intermediate key string is reversed in the middle and returns, such that the initial delay of the on-the-fly key setting remains short during decryption as well. • The number of rounds depends on key length, and is 6, 7, and 8 for key lengths of 128, 192, and 256 bits, respectively.

1.3 Other

Hierocrypt is the name assigned to a family of symmetric 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.

2. Evaluation Results

2.1 Security evaluation

Only a limited amount of information on security evaluation is currently available (as of January 2000), because Hierocrypt-3 was announced relatively recently. Nonetheless, this available information has not uncovered any fatal flaws for any of the key lengths. Although some analysis results are available, it is necessary to pay close attention to additional analysis results that will become available in the future. The designer provided a self-evaluation document that includes the results of security evaluation against various symmetric block cipher attack methods. The results indicate that Hierocrypt-3 is highly reliable against differential cryptanalysis and linear

310 CRYPTREC 2000

cryptanalysis, and show some new information about resistance to a square attack, one of the attack methods in which the designer of Hierocrypt-3 is most interested (decodability in 3.5 rounds). This is slightly different from the initial conclusion by the designer, i.e., "Hierocrypt-3 is resistant to a square attack at a smaller number of rounds (2.5 rounds) than Rijndael" (an announcement made at SCIS2001 by the applicant). However, this information does not directly threaten the security of Hierocrypt-3 in its specified format because the cipher is supposed to be used in six rounds or more. The specification document contains the following reference (though its meaning is ambiguous): "In terms of security, the objective is to prevent the search range based on an exhaustive key search from becoming practically narrow because of a simple dependence relationship among expanded keys." However, several linear relational expressions have been obtained for this "simple dependence relationship among expanded keys." Avalanche verification has also shown the presence of bias in the key schedule and the round function. However, none of these findings threatens the security of Hierocrypt-3 in its specified format. Because Hierocrypt-3's elemental technologies, such its SPN structure, S-box evaluation, and MDS, have been designed based on cryptographic research results, no obvious or fatal defects are expected to occur in the future in any of these elements. Nonetheless, because the key schedule itself that has been adopted in Hierocrypt-3 is new, it will be necessary to stay abreast of future security-evaluation results. Last, because a design guideline and an algorithm are intuitively and theoretically connected to each other, it is hard to imagine that the designer has intentionally built in any trapdoor.

2.2 Software (SW)-implementation evaluation

SW implementation was evaluated in the following environments. The following tables show the evaluation results. Data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler (MMX instructions) Program size 68832 bytes (including encryption/decryption/key schedule) Compiler option VC++6.0 Win32 Release (Default) First round Second round Third round 404 / 406 404 / 406 404 / 406 426 / 428 426 / 428 426 / 428

311 CRYPTREC 2000

Ultra SPARC IIi (400MHz) Language ANSI C Program size 38936 bytes (including encryption/decryption/key schedule) Compiler option cc -native -fast -xarch=v8plusa -xCC (encryption) cc -native -fast -xarch=v9 -xCC (decryption) First round Second round Third round 511 (471) / 554 (473) 510 (471) / 556 (473) 510 (471) / 555 (473) 759 (612) / 826 (616) 758 (612) / 826 (616) 757 (612) / 826 (616)

Alpha21264 (463MHz) Language ANSI C Program size 58152 bytes (including encryption/decryption/key schedule) Compiler option cc -O3 First round Second round Third round 420 (399) / 424 (406) 420 (399) / 424 (406) 420 (399) / 423 (407) 427 (386) / 429 (393) 427 (386) / 430 (394) 427 (386) / 430 (393)

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

Key schedule + data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler (MMX instructions) Program size 68832 bytes (including encryption/decryption/key schedule) Compiler option VC++6.0 Win32 Release (Default) First round Second round Third round 726 / 728 726 / 729 726 / 728 1345 / 1358 1344 / 1357 1346 / 1358

Ultra SPARC IIi (400MHz) Language ANSI C Program size 38936 bytes (including encryption/decryption/key schedule) Compiler option cc -native -fast -xarch=v8plusa -xCC (encryption) cc -native -fast -xarch=v9 -xCC (decryption) First round Second round Third round 823 (761) / 828 (822) 823 (761) / 828 (821) 824 (761) / 828 (823) 2673 (2612) / 2684 (2627) 2671 (2611) / 2683 (2627) 2670 (2610) / 2683 (2627)

312 CRYPTREC 2000

Alpha21264 (463MHz) Language ANSI C Program size 58152 bytes (including encryption/decryption/key schedule) Compiler option cc -O3 First round Second round Third round 675 (668) / 679 (672) 675 (668) / 678 (673) 675 (668) / 679 (672) 1130 (1130) / 1142 (1141) 1130 (1130) / 1142 (1142) 1130 (1130) / 1142 (1142)

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

Note: In the measurements using Ultra SPARC IIi and Alpha21264, 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 no modifications were made that would affect the speed-evaluation results.

2.3 Hardware (HW)-implementation evaluation

HW implementation evaluation results are shown as follows. These results are based on an assumption that a loop architecture is not used and the entire algorithm is optimized for speed. Therefore, it is possible to reduce the circuit size.

Data-randomization part 538,078 Key schedule 106,302 Circuit size (gates) Control circuit ― Entire primitive 724,380 Critical path (ns) 75.55 Processing speed (Mbps) 1,694.24

The following four implementation examples using cell libraries or FPGAs have been reported:

0.14-µm CMOS ASIC 897 Mbps 81.5 Kgates 0.14-µm CMOS ASIC 84.6 Mbps 26.7 Kgates ALTERA Max+plusII 51.0 Mbps, 11 Kgates (Flex 10K Family) ALTERA Max+plusII 4.1 Mbps, 6.3 Kgates (Flex 10K Family)

Academic Papers and References [1] Muratani, Okuma, Sano, Motoyama, and Kawamura, Proposal on 64-bit Hierocrypt, Information Processing Society Research Report CSEC11-9, Sept. 2000.

313 CRYPTREC 2000

[2] Okuma, Muratani, Sano, 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.

314 CRYPTREC 2000

5.2.9 MARS

1. Cryptographic Technique

1.1 Technical overview

MARS is a 128-bit block cipher algorithm developed by IBM that supports key lengths of between 128 and 448 bits. Although MARS has been designed to work on multiple platforms, a major focus has been placed on performance on 32-bit processors. In terms of security, MARS combines multiple structures to maintain resistance to both known and unknown attack methods.

Intellectual property rights (based on the application document) (Proposing organization's patents and their handling) Although an application has been submitted for a MARS-related patent, its laid-open number has not been made public. The same document also states that Tivoli Systems Inc. (a division of IBM) plans to provide MARS-related patents free of charge on a worldwide basis.

1.2 Technical Specifications

(1) MARS partitions the data-randomization part into forward mixing, core mixing, and backward mixing, and is designed to be resistant against both known and unknown attack methods. The purpose of forward mixing and backward mixing is powerful shuffling of key bits, which is expected to provide strength against unknown attack methods. Core mixing is designed to provide sufficient resistance against known attack methods.

(2) Core mixing uses a modified Feistel network that consists of four 32-bit blocks. Among various structures, the modified Feistel network offers superior balance of speed, strength, and ease of analysis.

(3) Although MARS can be used in any environment, a major focus has been placed on using it on 32-bit processors in particular. Consequently, all operations used for encryption assume 32-bit words. Specifically, MARS combines and uses EXOR, modulo 232 addition/subtraction/multiplication, table look up, fixed cyclic shift, and data-dependent rotation.

1.3 Other

MARS was one of the five AES finalists. After an application for MARS had been submitted to CRYPTREC, IBM Japan, the applicant, informed CRYPTREC that IBM Corporation had no plan to

315 CRYPTREC 2000

commercialize MARS.

2. Evaluation Results

2.1 Security evaluation

(1) The various evaluation results on MARS available from the AES proposal indicate that the security of MARS in the specified format is not affected in any way, and it is presumed that none of the existing attack methods will contribute to the breaking of MARS. (2) As a reference, the results known to date are summarized as follows. Note that these security evaluations were conducted by simplifying MARS using various methods, and therefore it is not sufficient to simply use descriptions such as "a version with the number of rounds reduced to x." (3) An environment to which an impossible differential attack can be applied is established when forward/backward mixing is ignored and only eight rounds out of 16 rounds of core mixing functions are considered. (4) Furthermore, theoretical consideration indicates that, when the key length is 256 bits, it is possible to devise an attack method with fewer than 2256 keys for a modified MARS that combines forward/backward mixing and five rounds (16 rounds are used in the standard version) of core mixing, or that ignores forward/backward mixing and uses 11 rounds of core mixing functions. (5) Although no strict evaluation has been done of linear attack methods, MARS is considered secure for the most part.

However, the following point should be noted: (6) Resistance of the data-dependent rotation and modulo 232 multiplication used in MARS against differential power analysis and timing attacks has not been fully evaluated.

2.2 Software (SW)-implementation evaluation

No evaluation has been performed to date.

2.3 Hardware (HW)-implementation evaluation

The following table shows the hardware-evaluation results. These results assume implementation in which speed is optimized for the entire algorithm using a 0.35-µm CMOS ASIC library.

316 CRYPTREC 2000

Data-randomization part 739,069 Key schedule 2,316,846 Circuit size (gates) Control circuit ― Entire primitive 3,055,914 Critical path (ns) 612.64 Key Setup Time (ns) 1,740.99[1] Processing speed (Mbps) 208.93

References [1] 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 Techonlogy, Gaithersburg, MD, April 13-14, 2000, pp.279-285.

317 CRYPTREC 2000

5.2.10 RC6

1. Cryptographic Technique

1.1 Technical overview

RC6 is a variable block length (128 bits in the standard version) symmetric cipher that 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 analysis, using a simple structure. Specifically, RC6 has data-dependent rotation and operations, such as integer addition of round keys, in its core. 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.

Intellectual property rights (based on the application document)

(Proposing organization's patents and their handling) The following four instances of RSA Security Inc.'s intellectual property rights related to RC6 have been reported: • U.S. patents Title: Block Encryption Algorithm with Data-Dependent Rotations Patent number: 5,724,428. Date of patent March 3, 1998 • Title: Block Encryption Algorithm with Data-Dependent Rotations Patent number: 5,835,600. Date of patent: November 10, 1998 • U.S. patent applied Title: Enhanced Block Encryption Algorithm with Data-Dependent Rotations Serial number: 09/094,649 • PCT patent applied Title: Enhanced Block Encryption Algorithm with Data-Dependent Rotations Serial number: PCT/US99/13358

The public web address for the specification of the cryptographic technique being proposed is: http://www.rsasecurity.com/rsalabs/rc6/

1.2 Technical Specifications

RC6 has a wide range of parameters and is expressed as "RC6-w/r/b" to be precise. The letters w, r, and b indicate word-bit length, number of rounds, and key-byte length, respectively. RC6 has a modified

318 CRYPTREC 2000

Feistel structure in which plaintext blocks are divided into four partitions, and has a plaintext block length that is four times the word length w. In the version submitted for evaluation, word length w = 32 bits, key length b = 16, 24, and 32 bytes, and number of rounds 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 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, left and right cyclic shift, are performed in 32-bit word units. That is, the algorithm is designed to efficiently use the operations of a 32-bit CPU. The processing speeds of these operations lead to fast implementation.

2. Evaluation Results

2.1 Security evaluation

RC6 was evaluated as a proposed AES cipher and was selected as one of the five ciphers to be evaluated in further detail. This evaluation, along with the CRYPTREC evaluation, has not uncovered any problems in the proposed version of RC6, and therefore RC6 can be considered a sufficiently usable cipher. For an ideal cipher, there should not be any attack method in which the number of plaintexts needed for the attack is less than the total number of plaintexts, and the number of computations necessary for the attack is less than all possible combinations of secret keys. Resistance of RC6 against various attack methods is summarized as follows. Though not based on an argument of provable security, RC6's resistance to differential and linear attacks has been evaluated for characteristics probabilities based on appropriate consideration in the self-evaluation document. In an algorithm such as RC6, which uses data-dependent rotation, the differential path and linear approximation path vary according to the number of shifts, and therefore it is necessary to consider the sum of characteristics 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 up to 12 rounds for differential attacks and up to 16 rounds for linear attacks. Although these results fall short of the expected cipher strength, the result for an 18-round version is better than this. The 20-round RC6, which is a full specification version, can be considered secure. Among high order and other attacks, one that has been most effective against RC6 is a chi-square attack. According to this attack, which uses chi-square statistics, keys can be estimated for a 15-round version, using 2119 chosen plaintexts, 2215 computations, and 2138 memory. It has been reported that weak keys that exist at a rate of 2-60 can be attacked up to 16 rounds. In this range of number of rounds, RC6 has not reached the expected cipher strength. However, these attacks cannot be considered realistic because the numbers, such as the number of plaintexts, are in the realm that will not materialize at least

319 CRYPTREC 2000

for another ten years, even if communication speed and computation capability improve by tenfold every year. Nonetheless, it is necessary to stay abreast of advances in 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 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 expected cipher strength is reached in nine rounds against higher order differential attacks and in six rounds in avalanche evaluation. Therefore, RC6 can be considered to possess sufficient strength, at least for the time being. As described previously, RC6 has not achieved the expected cipher strength 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.

2.2 Software (SW)-implementation evaluation

SW implementation was evaluated in the following environments. The following tables show the evaluation results.

Data-randomization part speed-measurement results Pentium III (650MHz) Language Assembler Program size 1200 bytes (for encryption and decryption each) Compiler option /o2 (Microsoft C Compiler) First round Second round Third round 258 / 260 258 / 260 258 / 259 262 / 266 262 / 265 262 / 265

Ultra SPARC IIi (400MHz) Language ANSI C Program size 3940 bytes (for encryption and decryption each) Compiler option xo5 (WS Compiler C/SPARC, Optimize 5) First round Second round Third round 2048 / 2088 2047 / 2088 2048 / 2089 2024 / 2076 2023 / 2074 2026 / 2077

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

320 CRYPTREC 2000

Key schedule + data-randomization part speed-measurement results

Pentium III (650MHz) Language Assembler Program size 1200 bytes (for encryption and decryption each), 1500 bytes (key schedule) Compiler option /o2 (Microsoft C Compiler) First round Second round Third round 1631/ 1644 1630 / 1645 1630 / 1642 1633 / 1639 1633 / 1643 1633 / 1640

Ultra SPARC IIi (400MHz) Language ANSI C Program size 3940 bytes (for encryption and decryption each), 2196 bytes (key schedule) Compiler option xo5 (WS Compiler C/SPARC, Optimize 5) First round Second round Third round 4078 / 4111 4078 / 4111 4075 / 4112 4026 / 4054 4024 / 4055 4019 / 4054

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block Note: The codes measured on Pentium III were derived by correcting a commercial program for Microsoft Windows 9X according to the performance evaluation test specification. The codes measured on Ultra SPARC IIi were derived by correcting a commercial program for SUN Solaris according to the performance evaluation test specification. The base product (BSAFE-Crypto-C5.1) is currently commercially available.

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 up to expanded key generation, RC6 is almost the slowest cipher, even when measured on Pentium III. In terms of the overall speed on Ultra SPARC, including encryption/decryption as well as expanded key generation, RC6 is almost the slowest. All of the versions submitted 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.

(Evaluation of SW implementation 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:

321 CRYPTREC 2000

Java: Simplicity 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-function 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.

2.3 Hardware (HW)-implementation evaluation

HW implementation evaluation results are shown as follows. These results are based on the assumption that the entire algorithm is optimized for speed using a 0.35-µm CMOS ASIC library.

Data-randomization part 77,785 Key schedule 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] Processing speed (Mbps) 183.36

In these evaluation results, the group that uses the loop architecture had the smallest circuit size for the data-randomization part. The simplicity of the cryptographic algorithm is presumed to have contributed to this outcome.

The applicant’s evaluation has reported an example of even smaller implementation circuit size.

FPGA[3] Encryption XCV1000 127 (Mbps) Feedback mode Encryption XCV1000 2.4 (Gbps) Non-feedback mode

ASIC[4] Encryption 0.5 µm 104 (Mbps) Repetitive method Encryption 0.5 µm 2.2 (Gbps) Pipeline method

References [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/rc6/ [2] S. Contini, R.L. Rivest, M.J.B. Robshaw, and Y.L. Yin, The security of the RC6 Block Cipher, August 20, 1998. Available at http://www.rsasecurity.com/rsalabs/rc6/

322 CRYPTREC 2000

[3] 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) [4] B.Weeks, M.Bean, T.Rozylowicz, and C.Ficke, Hardware performance simulations of Round 2 AES algorithms, Proceedings of 3rd AES conference, pp.286-304, (2000)

323 CRYPTREC 2000

5.2.11 SC2000

1. Cryptographic Technique

1.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. 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 data communication between networks, fast encryption of large-capacity databases, smart card authentication, and transmission/receipt of cipher data.

Intellectual property rights (based on the application document) (Proposing organization's patents and their handling) The proposing organization has applied for the following four patents: Patent-application No. 00-16413, application date: 1/26/2000, title: "Cipher design device and recording medium" Patent-application No. 00-212813, application date: 7/13/2000, title: "Method of designing a cipher with superior diffusion performance and an encryption device" Patent-application No. 00-212814, application date: 7/13/2000, title: "Operation device that combines a Feistel structure and an SPN structure" Patent-application No. 00-212482, application date: 7/13/2000, title: "Expanded key generation device and recording medium" The proposing organization plans to license these patents and related copyrights belonging to other parties on a non-discriminatory basis and under reasonable conditions. (Other companies' related patents) None

324 CRYPTREC 2000

The public web address for the specification of the cryptographic technique being proposed is:

http://www.labs.fujitsu.com/theme/crypto/sc2000.html

1.2 Technical Specifications

(Data-randomization part) This component encrypts 32 bits x 4 input plaintext data using an expanded key table created by the key schedule, 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 its 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.

(Decryption function) 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 part, 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.

(Key schedule) The key schedule 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 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 expanded key generation function.

325 CRYPTREC 2000

2. Evaluation Results

2.1 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 limits of characteristics differential probability and characteristics linear deviation to guarantee resistance against differential/linear cryptanalysis [1]. In SC2000, the approximation expressions that have the significant characteristics differential probability and characteristics linear 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 a truncated vector [2]. It has been found that, against differential cryptanalysis, the 15-round characteristics differential 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 is no characteristics differential approximation expression that can be used for differential cryptanalysis. Although whether or not repetition of four or more rounds exists is worth determining, 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. Breaking using a truncated vector is possible for linear cryptanalysis as well. It has been found that the 15-round characteristics linear 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 is no characteristics linear approximation expression that can be used for linear cryptanalysis. Higher order differential cryptanalysis 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 the version with 128-bit keys, higher order differential cryptanalysis cannot be applied to SC2000. The maximum number of rounds that can be attacked with a higher order differential/interpolation attack is eight, using 264 or more plaintext-ciphertext pairs and 2256 or fewer computations. Because the specified number of rounds for SC2000 is 22, it has been confirmed that SC2000 has no problems with higher order differential/interpolation attacks. Because SC2000's security margin against ordinary differential cryptanalysis is not that large,

326 CRYPTREC 2000

resistance to truncated differential cryptanalysis must be evaluated in further detail. To determine the applicability of chi-square cryptanalysis and division cryptanalysis, 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 cryptanalysis with impossible differential attack, boomerang cryptanalysis, mod n cryptanalysis, and non-bijective cryptanalysis, but found no threatening shortcomings.

(2) Security of the key schedule against conventional attacks

An exhaustive search is the least effective but reliable cryptanalysis that can be applied to a symmetric cipher. At the existing technical level, an exhaustive 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 this 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 previously, no problematic shortcomings were found in the key schedule.

(3) Resistance to implementation-related 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 to take measures against timing attacks on software implementation and IC card implementation. Or, if attacks occur, they can be dealt with. 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 coutermeasures against these analysis methods can be performed at low cost.

As explained previously, no security-related faults have so far been found in SC2000. However, very little cryptanalysis of a structure that alternately superposes a two-round Feistel structure and an SPN structure has been done.

327 CRYPTREC 2000

Note that in the announcement [3] made at the SCIS2001 in January 2001, the proposing group reported that a three-round repeated differential/linear 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 of 2-34. As a result, 13 out of the total of 19 rounds could be attacked [YS01]. Further analysis is warranted in the future.

2.2 Software (SW)-implementation evaluation

The following tables show the measurement results from software implementation.

Data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler Program size 21340 bytes (including encryption/decryption/key schedule) Compiler option /G6 /O2 /ML /W3 /GX First round Second round Third round 389 / 391 388 / 392 388 / 391 408 / 410 408 / 411 408 / 411

Ultra SPARC IIi (400MHz) Language ANSI C Program size 25548 bytes (including encryption/decryption/key schedule) Compiler option -xtarget=ultra2 -xO5 First round Second round Third round 310 (275) / 313 (277) 310 (276) / 313 (278) 310 (276) / 314 (279) 309 (283) / 312 (286) 309 (283) / 312 (287) 309 (282) / 312 (285)

Alpha21264 (463MHz) Language ANSI C Program size 39854 bytes (including encryption/decryption/key schedule) Compiler option -fast –arch ev6 First round Second round Third round 289 (262) / 297 (276) 289 (262) / 297 (277) 289 (262) / 296 (276) 282 (275) / 296 (289) 282 (275) / 288 (289) 282 (275) / 288 (289)

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

328 CRYPTREC 2000

Key schedule + data-randomization part speed-measurement results

Pentium III (650MHz) Language ANSI C + assembler Program size 23700 bytes (including encryption/decryption/key schedule) Compiler option /G6 /O2 /ML /W3 /GX First round Second round Third round 800 / 803 800 / 803 800 / 803 818 / 822 818 / 821 818 / 819

Ultra SPARC IIi (400MHz) Language ANSI C Program size 22524 bytes (including encryption/decryption/key schedule) Compiler option -xtarget=ultra2 -xO5 First round Second round Third round 623 / 627 623 / 627 623 / 627 618 / 622 618 / 622 618 / 622

Alpha21264 (463MHz) Language ANSI C Program size 39854 bytes (including encryption/decryption/key schedule) Compiler option -fast –arch ev6 First round Second round Third round 572 / 578 572 / 578 572 / 578 586 / 594 586 / 595 586 / 594

Top row: encryption, bottom row: decryption, (Fastest speed)/(Average) Unit: cycles/block

Note: In the measurements using Ultra SPARC IIi and Alpha21264, 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 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, and is several percentage points shorter in UltraSparc. However, these differences were not significant enough to cause any problems.

329 CRYPTREC 2000

The designers have reported results of implementation in a PC containing a Pentium III or Athlon processor. Both the data-randomization part and the key schedule were optimized to a significant degree.

(IC card implementation) The designers have reported results of implementation in an IC card containing an Intel 8051 processor. Codes that can perform both encryption and decryption can be implemented in a 1751-byte ROM device. There is some room for encryption speed improvement.

2.3 Hardware (HW)-implementation evaluation

We did not evaluate any HW implementation.

References [1] Document related to the selection/design/evaluation of a symmetric block cipher, Communication/Broadcasting Mechanism, 2000. [2] T. Shimoyama et al., Symmetric Block Cipher SC2000, Shingaku Giho, ISEC2000-72, 2000. [3] H. Yanami et al., Differential/linear search of symmetric block cipher SC2000, Proceedings of the SCIS 2001, 2001.

330 CRYPTREC 2000

5.2.12 Rijndael

1. Cryptographic Technique

1.1 Technical overview

Rijndael is a symmetric block cipher that was proposed for the AES (Advanced Encryption Standard) in 1998 by J. Daemen (Proton World International) and V. Rijnmen (Katholieke Universiteit Leuven). It can use 128, 192, or 256 bits for both block length and key length [1]. Following a public discussion on AES, Rijndael was selected as the AES winner in October 2000 by the NIST (National Institute of Standards and Technology) [2], and is expected to become the FIPS (Federal Information Processing Standard) within 2001.

Intellectual property rights (Proposing organization's patent and its handling) The patents related to Rijndael have not been investigated yet. The proposing party claims that there are no patents related to Rijndael in the U.S. or other countries. After its selection as the AES, Rijndael will become the FIPS (Federal Information Processing Standard) during 2001 and usable on a royalty-free basis.

The public web address for the specification of the cryptographic technique being proposed is: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/

1.2 Technical Specifications

The main design principles behind Rijndael are (1) sufficient resistance to the existing attack methods, (2) ability to be implemented in various types of platform, and (3) a simple algorithm structure that enables easy security-related analyses. Rijndael is an SPN cipher, and data blocks are transformed inside the round function in 8-bit increments. The number of rounds in the algorithm depends on the block length and key length. For 128-bit blocks, the numbers of rounds are 10, 12, and 14 for key lengths 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 (letter swapping transformation), and the expanded key transformation layers (EXOR with expanded keys). The key schedule part generates (r + 1) (where r is the number of rounds) expanded keys with the same length as the block length. The bit shift and letter swapping in the data-randomization part are used for the transformation in the key schedule part.

331 CRYPTREC 2000

1.3 Other

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

2. Evaluation Results

2.1 Security evaluation

The major evaluation results from published reports on the security of the 128-bit block cipher Rijndael can be summarized as follows:

No attack method has been found that can break full round Rijndael 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 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 reached a passing mark in terms of security (i.e., has adequate security margin) [2]. Rijndael is an AES cipher and can be considered sufficiently reliable in terms of security at present. However, we recommend that the FIPS version, which will be established during 2001, be reevaluated for use in the Digital e-Government.

Additional discussions of these issues follow.

(1) Self-evaluation report by the designers at the time of an AES proposal

In their AES proposal, the designers of Rijndael stated that they had evaluated Rijndael against differential cryptanalysis, linear cryptanalysis, truncated differential cryptanalysis, SQUARE attacks, interpolation attacks, weak key attacks, and related key attacks, and that a cryptanalysis 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 Rijndael is sufficiently secure against differential cryptanalysis and linear cryptanalysis because no path that exceeds a probability of 2-150 in differential characteristics probability or linear characteristics probability exists for Rijndael with four rounds. Against truncated

332 CRYPTREC 2000

differentials, the designers state that a cryptanalysis method that is more efficient than an exhaustive key search does not exist for Rijndael with six or more rounds. Furthermore, they show that a SQUARE attack [4] can be applied to Rijndael with four, five, or six rounds, and state that a cryptanalysis method that is more efficient than an exhaustive key search does not exist for Rijndael with seven or more rounds. The designers state that other attack methods, such as interpolation attacks, weak key attacks, and related key attacks, are difficult to apply to Rijndael.

(2) Security evaluation results following the AES proposal

Since Rijndael was proposed for AES, many investigators have reported the results of their research on Rijndael's security. Some of the major ones are described as follows. It has been reported that, by applying a collision attack to Rijndael 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 Rijndael 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 SQUARE attack to Rijndael 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 between 2128 and 2119, which almost equals the total number. It has been reported that up to nine rounds of Rijndael with 256-bit keys can be broken using a related key attack [7]. As explained previously, although many security evaluations related to Rijndael have been taking place in the public domain, no attack method has yet been found that can break the full-specification Rijndael. Based on these published evaluation reports, NIST reports that Rijndael has reached a passing mark in terms of security (i.e., has adequate security margin) [2].

2.2 Software (SW) implementation evaluation

The results of SW implementation of Rijndael under several evaluation environments (CPU, language, etc.) have been reported [2]. Implementation evaluation results using a 32-bit CPU, i.e., Pentium III, and the C language are provided in the following example [8].

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

333 CRYPTREC 2000

– 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 3255 [cycles] – 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 1 32-bit processors (encryption)

A B C D E (Java) (C language) (C language) (C language) (C language) cycles cycles cycles cycles cycles 128-bit keys 237 1276 805 362 7770 192-bit keys 981 428 256-bit keys 1155 503 A: Intel 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 PentiumIII 600MHz, C.Ref. [8], 5.1, Table 6 (128blocks) 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 2 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.

334 CRYPTREC 2000

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 8-bit processors (encryption: C language + assembly language)

J K cycles cycles 128-bit keys 9464 25494 J: Motorola 6805 CPU Core, C.Ref. [17], Table 3. K: Z80 CPU+coprocessor.Ref. [18], Table 8.

Table 4 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 5 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 6 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

335 CRYPTREC 2000

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

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

K Cycles 128-bit keys 10318 K: Z80 CPU+coprocessor. Ref. [18], Table 8.

2.3 Hardware (HW) implementation evaluation

We did not perform any HW implementation. Fast HW implementation of Rijndael on ASIC has been evaluated and reported by Ichikawa et al [9].

– Evaluation target: ASIC (0.35-µm rule ASIC library made by Mitsubishi Electric) – Coding language: Verilog-HDL – Evaluation condition: Worst case – Gate size (NAND gate equivalent): Total: 612,843 (gates) (Encryption and decryption: 518,508, Key schedule: 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: Rijndael, AES algorithm submission, September 3, 1999,

336 CRYPTREC 2000

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 and Technology, October 2, 2000, http://csrc.nist.gov/encryption/aes/ [3] V. Rijmen, et al., The Cipher SHARK, 3rd Fast Software Encryption, 1996, 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 Rijndael, 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 Rijndael Under 192-bit and 256-bit Keys, in The Third AES Candidate Conference, printed by the National Institute of Standards and Technology, Gaithersburg, MD, April 13-14, 2000, pp.215-229. [7] N. Ferguson, et al., Improved Cryptanalysis of Rijndael, in the preproceedings of the Fast Software Encryption Workshop 2000, April 10-12, 2000. [8] L. Bassham, 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, Gaithersburg, 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 Standards and Technology, Gaithersburg, MD, March22-23, 1999, pp.53-67. [14] J. Worley, et al., AES Finalists on PA-RISC 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

337 CRYPTREC 2000

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.

338 CRYPTREC 2000

5.2.13 MULTI-S01

1. Cryptographic Technique

1.1 Technical overview

MULTI-S01 is a cryptographic technique proposed in 2000 by Furuya, Watanabe, and Takaragi 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 (A ≠ 0, 64 bits), secret key B ((n + 2) x 64 bits), and secret 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 x 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 MULTI-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.

Intellectual property rights (based on the application document) (Proposing organization's patents) The applicants state that the following applied and granted patents are related to MULTI-S01 technologies. The applicants also state that they are willing to license these patents on a non-exclusive basis and for fair compensation. However, these conditions are not applicable if the other party is unwilling to license its MULTI-S01-related patents on a non-exclusive basis and for fair compensation. (1) Patent application 2000-108334 "Encryption device and method" (2) Patent application 2000-070994 "Symmetric cipher method and device" (3) Patent application 2000-210690 "Symmetric cipher method and device"

The public web address for the specification of the cryptographic technique being proposed is: http://www.sdl.hitachi.co.jp/crypto/

339 CRYPTREC 2000

1.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 processes 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 encryption process outputs C using M, R, A, B, and S as inputs, and the data-randomization part of the decryption process outputs either decryption result M' or an 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.

1.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 a 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.

2. Evaluation Results

2.1 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

340 CRYPTREC 2000

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 c characteristics in the input/output of the shuffling function, and no particular problem has been reported. Divide-and-conquer attacks, correlation attacks 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.

2.2 Software (SW)-implementation evaluation

SW implementation was evaluated in the following environment. The following table shows the evaluation results.

Stream-cipher speed-measurement results

Pentium III (650MHz) Language ANSI C Program size 12868Kbyte 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 First round Second round Third round 176 / 180 175 / 177 176 / 177

(Fastest speed)/(Average) Unit: cycles/64 bits

Note: Stream ciphers were originally designed for HW 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.

• The self-evaluation document shows the following results:

341 CRYPTREC 2000

Language: C Compiler option (DEC cc): Optimization option -tune ev56 -arch ev56 -O6 CPU: Alpha 21164A 600 MHz, RAM: 512 MB OS: DIGITAL UNIX 4.0E

Memory usage: Speed (Mbps) (clock/byte) Initialization: 2.4 KB Encryption: 3.6 KB 270.7 Mbps 17.7 Decryption: 3.7 KB 267.3 Mbps 18.0

2.3 Hardware (HW)-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: • ModelSlim VHDL/Verilog Version 5.4e (Model Technology) • Synplify（Synplicity Inc.） The evaluation results follow.

Operating Processing speed Resource usage FPGA used frequency (MHz) (Gbps) 18.8 1.203 19,811/42,240 ATOMs (46%) EP20K1000E

The self-evaluation document shows the following results:

0.35-µm CMOS technology (1) With processing-speed priority 140 Kgates, operating frequency of 140 MHz, and processing throughput of 9.1 Gbps (2) With logic-size priority 68 Kgates, operating frequency of 620 (200) MHz, and processing throughput of 620 (200) Mbps

2.4 Other evaluation

Under the heading "Usage and precaution on random number string number Q," the specification document states, "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

342 CRYPTREC 2000

determine whether or not a pseudorandom number has never been generated by the device. 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 that 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 yet, no result that demonstrates a security problem has been reported so far.

Reference Institute of Electronics, Information and Communication Engineers, Technical Research Report, ISEC2000-68 (September 2000).

343 CRYPTREC 2000

5.2.14 TOYOCRYPT-HS1

1 Cryptographic Technique

1.1 Technical overview

TOYOCRYPT-HS1 is a cryptographic technique that was proposed by Koichi Sugimoto at the Information Security Committee (ISEC) of the Institute of Electronics, Information and Communication Engineers, held in 2000. This technique achieves encryption by EXORing a pseudorandom number generated by a pseudorandom number generation algorithm (HR1) and a plaintext bit by bit. The pseudorandom-number string to be generated is determined by a 128-bit fixed key and a 128-bit stream key.

Intellectual property rights (based on the application document) (Proposing organization's patents and their handling) Patent-application number: H10-039677 (Disclosure number: H11-224183) Pseudorandom-number generator Patent-application number: H10-129606 (Disclosure number: H11-305661) Shift register and circuits for configuring a shift register Patent-application number: H10-267415 (Disclosure number: 2000-081969) Pseudorandom-number generator Patent-application number: H11-007826 (Disclosure number: 2000-209165) Encrypted communication system The applicant has not finalized a licensing policy.

The public web address for the specification of the cryptographic technique being proposed is: http://www.toyocom.co.jp

Overview TOYOCRYPT-HS1 achieves encryption by EXORing a pseudorandom number generated by a pseudorandom number generation algorithm (HR1) and a plaintext bit by bit. The pseudorandom number string to be generated is determined by a 128-bit fixed key and a 128-bit stream key.

Technical points TOYOCRYPT-HS1 has been designed with hardware performance in mind so that it can be most effective in applications that need ultra-fast encryption on hardware requiring compact size and low power consumption. TOYOCRYPT-HS1 also has a simple structure to enable compact software

344 CRYPTREC 2000

implementation. TOYOCRYPT-HS1 is designed based on the Galois field theory, and its basic operations are defined on GF(2). For security, TOYOCRYPT-HS1 uses linear complexity, the non-linear theory, and a theory on attacks unique to non-linear combiners. Bitslice-implementation technology is used for software implementation.

1.2 Technical Specifications

TOYOCRYPT-HS1 achieves encryption by EXORing a pseudorandom number generated by a pseudorandom number generation algorithm (HR1) and a plaintext bit by bit. The pseudorandom-number string to be generated is determined by a 128-bit fixed key and a 128-bit stream key. The pseudorandom number generation algorithm in TOYOCRYPT-HS1 is designed based on the designer's standards listed as follows. (1) Theoretically guarantee equal 0/1 frequency. (2) Theoretically guarantee long periods (guarantee the lower limit of the periods). (3) Theoretically guarantee the lower limit of linear complexity to ensure a smooth ramp-up. (4) Build a structure that is sufficiently resistant to attacks unique to non-linear combiners. (5) Achieve fast operations and small size when implemented in hardware. Of these standards, (1) through (4) are security requirements for the pseudorandom number generation algorithm, i.e., conditions for making it difficult to estimate other partial bits from partial series of the generated pseudorandom numbers. Standard (4) in particular is included by considering such typical attacks as fast correlation attacks, inversion attacks, and conditional correlation attacks. TOYOCRYPT-HS1 is classified as a synchronous key stream cipher and achieves encryption by EXORing the pseudorandom number output generated by a pseudorandom number generation algorithm and a plaintext bit by bit. TOYOCRYPT-HS1's key stream generation algorithm is classified as a non-linear combiner, and generates a pseudorandom number one bit at a time by outputting the output of the linear feedback shift register via the non-linear transformation function. The Galois configuration is used for the structure of the linear feedback shift register. This is because the Galois configuration can run at high speed on hardware. To achieve a compact hardware size, the designers configured the non-linear transformation function using logical operations as the basic operations, and without arithmetic operations.

345 CRYPTREC 2000

2. Evaluation Results

2.1 Security

Because TOYOCRYPT-HS1 could become decodable in the computation environment of the near future, it cannot be recommended in its current form as a cipher for the Digital Government. Improvements must be made to the proposed algorithm before it can be adopted in an actual system. If the fixed key is known, the effective key length is reduced from 128 bits to 96 bits at the most. Although this is in the secure range based on the current processing capability of computers, future security must be judged by the administrator. One of the operational issues is how to provide the LFSR seed. At least a clear guideline for this issue must be provided. Seed omission will affect the security of this random-number generator. Additionally, a divide-and-conquer attack that is more effective than an exhaustive search is possible. The number of computations necessary for this attack is about 296. An analytical paper on TOYOCRYPT-HS1 has been published [1]. This paper uses the time memory trade-off method, which is the latest analytical method by Biryukov-Shamir [Proc. ASIACRYPT 2000]. The result shows that a 128-bit key can be determined from 232-bit output data, using approximately 232 memory and 264 computations.

2.2 Software (SW)-implementation evaluation

SW implementation was evaluated in the following environment. The following table shows the evaluation results.

Stream-cipher speed-measurement results

Pentium III (650MHz) Language ANSI C Program size 5292byte Compiler option /nologo /G6 /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /Fp"Release/toyo-hs1.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c First round Second round Third round 13867 / 13880 13869 / 13895 13865 / 13892

(Fastest speed)/(Average) Unit: cycles/64 bits

Note: Stream ciphers were originally designed for HW implementation. Serial implementation is used to match the measurement-program interface. If parallel implementation is used, fast operations of approximately eight times can be expected.

346 CRYPTREC 2000

The self-evaluation document describes the following implementation data: Implementation language and evaluation conditions Programming language: ANSI C Target processor: SH1 Evaluation environment: SH1 Compiler Simulator made by Hitachi, Windows 95 Ver. 5.0 Compilation condition: Speed priority, no loop/inline expansion

Results Serial implementation Execution speed: 66991 cycle/word, 9.56 Kbps (at 20MHz) Key setup: 591112 cycle, 30.0 ms (at 20MHz) Program code: 910 bytes Constants (including keys): 368 bytes Stack (RAM): 1184 bytes

Parallel implementation Execution speed: 3678 cycle/word, 174 Kbps (at 20MHz) Key setup: 673332 cycle, 33.7 ms (at 20MHz) Program code: 800 bytes Constants (including keys): 1360 bytes Stack (RAM): 2052 bytes

However, software implementation is relatively slow. As a means of increasing speed, the designer is suggesting parallel processing, which, however, creates the problem of longer key length. Furthermore, using keys for generating new primitive polynomials is inefficient (in some applications).

2.3 Hardware (HW)-implementation evaluation

347 CRYPTREC 2000

Evaluation target Operating Processing Resource usage FPGA used frequency speed (MHz) (Gbps) TOYOCRYPT- Circuit 58.1 0.052 11,883/24,320 LCs EP20K600E HS1 size Processing 45.2 1.446 16,144/24,320 LCs EP20K600E speed

The following evaluation was done by the applicant on an FPGA:

Simulation using VHDL The additional circuit necessary for the key-setup area is a single 9-bit counter only, resulting in an extremely small size. The setup time was also extremely short, at 256 clocks.

FPGA-simulation result HDL editor: HDL Turbo Writer Ver5.1C Build3 (Excel Consuitants Ltd) Logic-synthesis tool: Synplify-Lite 3.0 (Synplicity Inc) Routing tool: SpDE 8.1 Simulation tool: SILOS III ver 99.070 (SIMCAD.Inc) Target device: QL3012-4 Package type: 84 pin PLCC Device process: C-MOS 0.35µm, 4 layer

Compile option Item Sub-item Performance Execution speed with speed priority Worst case 226MHz (Mbps) Normal case 339MHz (Mbps) Best case 418MHz (Mbps) Circuit size Cell 235/320 (73.4%) Routing resources 3329/42812 (7.8%)

Execution speed with circuit-size priority Worst case 75MHz (Mbps) Normal case 112MHz (Mbps) Best case 138MHz (Mbps) Circuit size Cell 195/320 (60.9%) Routing resources 2953/42812 (6.9%) * Worst case: 70ºC 3.00 V Normal case: 25ºC 3.30 V Best case: 0ºC 3.60 V

348 CRYPTREC 2000

Performance estimate based on a gate array (by the applicant) It has been reported that when a gate array (TC200G52, 3.3 V, 3 layer, 0.4-µm process, made by Toshiba) is used, 223 Mbps (worst case, 70ºC, 3.0 V) can be achieved with approximately 3.3 Kgates. Condition Delay [ns] Speed [MHz] Worst case 4.5 223 Normal case 2.5 403 Best case 1.3 790 * Worst case: 70ºC 3.00 V Normal case: 25ºC 3.30 V Best case: 0ºC 3.60 V

References [1] Koichi Sugimoto, Tetsuya Chikaraishi, and Tetsuya Morizumi, Stream Cipher Designing Method and Evaluation, Shingaku Giho ISEC2000-69. [2] M. Mihaljevic and H. Imai, Effective secret key size of TOYOCRYPT-HS1 stream cipher, Proc. SCIS2001. [3] Sugimoto, Chikaraishi, Morizumi, Satoh, and Kurosawa, A Method of Configuring a Secure Filter Generator, 1998 Cipher and Information Security Symposium SCIS98-5.1.C, January 1998. [4] Sugimoto, Chikaraishi, Morizumi, Satoh, and Kurosawa, A Method of Configuring a Secure Filter Generator, 1998 Shingaku Sodai, A-7-12, March 1998. [5] Sugimoto, Satoh, and Kurosawa, Fast Correlation Attack on Modular LFSR-type Filter Generator, Shingaku Giho (ISEC), ISEC98-2, pp.11-20, May 1998. [6] Sugimoto and Kurosawa, Fast software implementation of stream cipher, 1998 Shingaku Sodai, A-7-3, September 1998. [7] Sugimoto and Kurosawa, Fast software implementation of stream cipher, 1999 Cipher and Information Security Symposium (SCIS99), F1-2.1, pp.795-799, January 1999.

349 CRYPTREC 2000

6. Hash-Function Evaluation

The following table shows the hash functions that were evaluated. Section 6.1 compares the hash-function categories in terms of characteristics, security, and implementation, and includes short comments. Section 6.2 describes the individual hash functions in more detail. Note that the hash functions are listed in alphabetical order.

Hash-function names Hash function MD5, RIPEMD-160, SHA-1

6.1 Evaluation by type

Table 6.1.1 Hash-function list

MD5 RIPEMD-160 SHA-1 Message-digest length 128 bit 160 bit 160 bit Bit length for each basic process Charac- 512 bit 512 bit 512 bit teristics Total processing step count

160 (5 rounds x 16 64 (4 rounds x 16 steps) 80 (4 rounds x 20 steps) steps x 2 lines) Maximum message length that can be input 64 64 ∞ 2 − 1 bit 2 − 1 bit Although some attacks on MD5 have been reported, it is difficult to consider any of these to be practical. Because no practical attacks on MD5, RIPEMD-160, or SHA-1 have been reported, these hash functions can be considered sufficiently secure for use in the cipher-application field. However, it is of course necessary to ensure resistance to exhaustive search attacks. For example, if the length of a hash value is n bits, a birthday attack may find a collision among the hash values for 2n/2 messages, and therefore the hash values must be made sufficiently long. Because MD5 is a 128-bit hash value, some people think that it is not sufficiently resistant against a birthday attack. Recent research results suggest that at least n = 160 bits is required. Characteristics that are unfavorable to hash functions and how resistant the hash Security functions are to possible attacks, are listed as follows. "–" means that no effective attack method has yet been found; "∆" means that the attack may succeed in some cases. Attack type MD5 RIPEMD-160 SHA-1 Preimage – – – Pseudo-preimage – – – 2nd preimage – – – Collision – – – Pseudo-collision ∆ – –

350 CRYPTREC 2000

6.2 Individual evaluation

6.2.1 MD5

1. Cryptographic Technique

1.1 Technical overview

MD5 is a hash function proposed by R. Rivest in 1991. This function takes a message that has been padded so that its bit length is a multiple of 512 bits as input, and outputs a 128-bit hash value. MD5 is a hash function that has been designed to suit 32-bit computers, and can achieve fast processing speed even with software implementation.

1.2 Technical Specifications

To achieve fast processing speed on 32-bit computers, MD5's main operations consist of 32-bit arithmetic addition, logical operations, and cyclic shift operations. MD5 consists of three components: input, compression, and output. MD5 takes 512-bit message blocks and four 32-bit variables as inputs, and outputs a 128-bit hash value by repeating a function that outputs four new variables. The compression function consists of four rounds and 64 steps.

(1) Input Inputs are converted into 32-bit integers based on the little endian method, and are divided into 512-bit blocks. If a 512-bit message block is expressed as X = (X[0], X[i], …, X[15]), each X[i] (0 ≤ i ≤ 15) is 32 bits, and is used as the input into the step function of the compression function to be explained next.

(2) Compression function Four chain variables (A, B, C, and D) are used for computing the compression function. For the initial values of (A, B, C, and D), i.e., IV = (h1, h2, h3, and h4), the following values are used:

h1 = 0x67452301, h2 = 0xefcdab89, h3 = 0x98badcfe, h4 = 0x10325476 The Boolean functions used in MD5 are defined as follows:

f (x, y, z) = (x ∧ y) ∨ (x ∧ z) g(x, y, z) = (x ∧ z) ∨ (y ∧ z)

h(x, y, z) = x ⊕ y ⊕ z i(x, y, z) = y ⊕ (x ∨ z)

Here, symbols ∧, ∨, and ⊕ indicate AND, OR, and EXOR, respectively, for each bit, and indicates bit inversion of x. Using these Boolean functions, the step functions of the compression function

351 CRYPTREC 2000

of MD5 can be expressed as follows. Round 1 FF(A, B,C, D, X[i], s, K[ j]) : A = B + (A + f (B,C, D) + X[i] + K[ j])<

(3) Output MD5 outputs a 128-bit hash value by first adding the value of the chain variables determined in the last step of the compression function to the first initial value IV, and then by combining the four variables (A, B, C, and D). For the detailed specifications of MD5, refer to [1].

~~1.3 Other~~

~~MD5 was proposed as an improved version of MD4, which also had been announced earlier also by R. Rivest.~~

~~2 Evaluation Results~~

~~2.1 Security evaluation~~

The security of a hash function is evaluated basically from two viewpoints. The first index is the effort necessary to discover the input value that corresponds to a particular output, i.e., (1) the effort necessary to search for the input value (Preimage). The second index is the effort necessary to discover different input values with output values that match each other, i.e., (2) the effort necessary to discover collision. MD5 is considered sufficiently resistant to (1). However, concerning (2), care must be exercised if MD5 is to be used in applications in which collision discovery can become a threat, because the bit count of the hash value is relatively short at 128 bits. Additional explanations follow.

• Attacks unique to MD5 The most efficient attack on MD5 is considered to be a search for a collision among the initial values used inside the algorithm of the hash functions. Examples of these types of attacks (the attack by Boer and Bosselaers [Pseudo-collision was discovered with 216 operations] [2] and the attack by Dobbertin [3]) have been published. However, neither of these attack methods can be considered capable of causing an actual problem.

~~352 CRYPTREC 2000~~

• Effort necessary for input-value search There are only 2n patterns in the hash values to be output by a hash function with a hash value that is n-bit long. Therefore, when searching for an input value that outputs a certain hash value, one can obtain the input value that matches the specified hash value, by providing 2n input values that output different hash values beforehand. In MD5, n = 128, and therefore, 2128 input values are required to apply an attack based on this method. This figure is considered too large to provide using currently available technologies.

• Effort necessary for collision discovery On the other hand, according to the Birthday paradox, by providing 2n/2 input values, input-value pairs in which hash values match can be discovered among these input values at a relatively high probability. In MD5, n = 128, and therefore, a Birthday attack can be applied if approximately 264 input values can be provided.

~~2.2 Software (SW)-implementation evaluation~~

Although CRYPTREC performed no implementation evaluation, the following implementation results were made available at the time of report preparation [4]: Platform: Celeron 850 MHz OS and language used: Window 2000 SP1, C++ Processing performance: 100.738 Mbytes per sec

~~2.3 Hardware (HW)-implementation evaluation~~

~~Neither speed nor circuit size during hardware implementation was evaluated.~~

[1] R. Rivest, The MD5 message-digest algorithm, Request For Comments (RFC) 1321, Internet Activities Board, Internet Privacy Task Force, April 1992 (http://www.roxen.com/rfc/rfc1321.html) [2] B. den Boer and A. Bosselaers, Collisions for the compression function of MD5, Advances in Cryptology – Eurocrypt '93, pp.293-304, 1993. [3] H. Dobbertin, The status of MD5 after recent attack, CryptBytes, 2 (2), Sep., pp.1-6, 1996. [4] http://www.eskimo.com/~weidai/benchmarks.html

~~353 CRYPTREC 2000~~

~~6.2.2 RIPEMD-160~~

~~1. Cryptographic Technique~~

~~1.1 Technical overview~~

RIPEMD-160 is a hash function proposed by Dobbertin, Bosselaers, and Preneel, and is one of the achievements of the European RIPE (Race Integrity Primitive Evaluation) project. Subsequently, RIPEMD-160 was adopted as an ISO international standard along with SHA-1 and RIPEMD-128 [1]. RIPEMD-160 takes a message that has been padded so that its bit length is a multiple of 512 bits as input, and outputs a 160-bit hash value.

~~1.2 Technical Specifications~~

RIPEMD-160 was designed by improving MD4 and MD5, and like MD4, RIPEMD-160's main operations consist of 32-bit arithmetic addition, logical operations, and cyclic shift operations, to achieve fast processing speed on 32-bit computers. RIPEMD-160 consists of three components: input, compression, and output. RIPEMD-160 execute two nearly identical functions in parallel and outputs a 160-bit hash value from a message of any length. The two functions are called the right line and the left line, each of which consists of five rounds and 80 steps. For the detailed specifications of RIPEMD-160, refer to [1].

(1) Input Inputs are converted into 32-bit integers based on the little endian method, and are divided into 512-bit blocks. Sixteen 32-bit inputs, X[0] through X[15], are input into the right line and the left line according to a predetermined sequence.

(2) Compression function Five chain variables (A, B, C, D, and E) are used for computing the compression function. The initial values of A, B, C, and D are the same as in MD5, and a new initial value is defined for E. For the initial values of (A, B, C, D, and E), i.e., IV = (h1, h2, h3, h4, and h5), the following values are used:

h1 = 0x67452301,h2 = 0xefcdab89,h3 = 0x98badcfe,h4 = 0x10325476,h5 = 0xc3d2e1 f 0 These initial values are shared by both the right and left lines. The following five Boolean functions are used in the compression function:

~~354 CRYPTREC 2000~~

~~f (x, y, z) = x ⊕ y ⊕ z g(x, y, z) = (x ∧ y) ∨ (x ∧ z) h(x, y, z) = (x ∧ y) ⊕ z k(x, y, z) = (x ∧ z) ∨ (y ∧ z) l(x, y, z) = x ⊕ (y ∨ z)~~

Here, symbols ∧, ∨, and ⊕ indicate AND, OR, and EXOR, respectively, for each bit, and indicates bit inversion of x. The step functions composing the compression function of RIPEMD-160 are described as follows. Note that the subscripts "R" and "L" for the variables indicate that the variables are for the right and left lines, respectively. RIPEMD-160 performs hashing by executing the right and left lines in parallel. The constants KL[j] and KR[j] used in the step function are defined as follows:

~~K L [ j] = 0 K R [ j] = 0x50a28be6 (1 ≤ j ≤ 16)~~

~~K L [ j] = 0x5a27999 K R [ j] = 0x5c4dd124 (17 ≤ j ≤ 32)~~

~~K L [ j] = 0x6ed9eba1 K R [ j] = 0x6d703ef 3 (33 ≤ j ≤ 48)~~

~~K L [ j] = 0x8 f 1bbcdc K R [ j] = 0x7a6d76e9 (49 ≤ j ≤ 64)~~

~~K L [ j] = 0xa953 fd4e K R [ j] = 0 (65 ≤ j ≤ 80)~~

~~Leftward cyclic shifts sL[j] and sR[j] used in the step function are predefined. The step functions of RIPEMD-160 are described as follows. Note that X<~~

~~Round 1 (1 ≤ j ≤ 16)~~

~~FFL (AL , BL ,CL , DL , EL , X[i], sL [ j], K L [ j]) :~~

~~LLR (AR , BR ,CR , DR , ER , X[i], sR [ j], K R [ j]) :~~

~~Round 2 (17 ≤ j ≤ 32)~~

~~GGL (AL , BL ,CL , DL , EL , X[i], sL [ j], K L [ j]) :~~

~~KK R (AR , BR ,CR , DR , ER , X[i], sR [ j], K R [ j]) :~~

~~355 CRYPTREC 2000~~

~~Round 3 (33 ≤ j ≤ 48)~~

~~HH L (AL , BL ,CL , DL , EL , X[i], sL [ j], K L [ j]) :~~

~~HH R (AR , BR ,CR , DR , ER , X[i], sR [ j], K R [ j]) :~~

~~Round 4 (49 ≤ j ≤ 64)~~

~~KK L (AL , BL ,CL , DL , EL , X[i], sL [ j], K L [ j]) :~~

~~GGR (AR , BR ,CR , DR , ER , X[i], sR [ j], K R [ j]) :~~

~~Round 5 (65 ≤ j ≤ 80)~~

~~LLL (AL , BL ,CL , DL , EL , X[i], sL [ j], K L [ j]) :~~

~~FFR (AR , BR ,CR , DR , ER , X[i], sR [ j], K R [ j]) :~~

(3) Output In basically the same way as MD5, RIPEMD-160 outputs a hash value by first adding the value of the chain variables determined in the last step to the initial value IV, and then by combining the five variables (A, B, C, D, and E). However, because two lines are used, the following computations take place.

~~A = h2 + CL + DR , B = h3 + DL + ER , C = h4 + EL + AR~~

~~D = h5 + AL + BR , E = h1 + BL + CR~~

~~1.3 Other~~

RIPEMD-160 was designed as an improved version of RIPEMD, which had been proposed for the RIPE project in 1995, because an attack method on RIPEMD had been discovered[2]. RIPEMD-160 is one of the hash functions that are based on MD4.

~~356 CRYPTREC 2000~~

~~2 Evaluation Results~~

~~2.1 Security evaluation~~

The security of a hash function is evaluated basically from two viewpoints. The first index is the effort necessary to discover the input value that corresponds to a particular output, i.e., (1) the effort necessary to search for the input value (Preimage). The second index is the effort necessary to discover different input values with output values that match each other, i.e., (2) the effort necessary to discover collision. RIPEMD-160 is presently considered sufficiently resistant to both (1) and (2). Additional explanations follow.

• Attacks unique to RIPEMD-160 It has been reported that a collision can be discovered with 231 or less computations if the first or last round is omitted from RIPEMD, which is the predecessor to RIPEMD-160 [3]. Based on this result, the number of rounds was increased to five and the independence between the right and left parallel lines was enhanced in RIPEMD-160, thereby improving its security. Attacks on RIPEMD cannot be applied to RIPEMD-160, and attacks unique to RIPEMD-160 have not yet been reported.

• Effort necessary for input-value search As mentioned in the section on MD5, there are only 2n patterns in the hash values to be output by a hash function with a hash value that is n-bit long. Therefore, when searching for an input value that outputs a certain hash value, one can obtain the input value that matches the specified hash value, by providing 2n input values that output different hash values beforehand. In RIPEMD-160, n = 160, and therefore, 2160 input values are required to apply an attack based on this method. This figure is considered too large to provide using currently available technologies.

• Effort necessary for collision discovery When the hash-value length is n bits, by providing 2n/2 input values using a general analysis method called a Birthday attack, input-value pairs in which hash values match can be discovered among these input values at a relatively high probability. To prevent this, the hash value must be made sufficiently long. In RIPEMD-160, n = 160, and therefore, a Birthday attack can be applied if approximately 280 messages can be provided. However, providing such a large number of input values is presently considered unrealistic.

~~2.2 Software (SW)-implementation evaluation~~

~~Although CRYPTREC performed no implementation evaluation, the following implementation results were made available at the time of report preparation [4]:~~

~~357 CRYPTREC 2000~~

~~Platform: Celeron (850 MHz) OS and language used: Window 2000 SP1, C++ Processing performance: 30.725 Mbytes/sec~~

~~2.3 Hardware (HW)-implementation evaluation~~

~~Neither speed nor circuit size during hardware implementation was evaluated.~~

References [1] ISO/IEC 10118-3, Information technology — Security techniqes — 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): pp51-70, 1997. [4] http://www.eskimo.com/~weidai/benchmarks.html

~~358 CRYPTREC 2000~~

~~6.2.3 SHA-1~~

~~1. Cryptographic Technique~~

~~1.1 Technical overview~~

SHA-1 is a hash function that is an improved version of SHA (Secure Hash Algorithm) proposed by NIST (National Institute of Standards and Technology). SHA-1 uses input messages as though they were keys in a block cipher. That is, SHA-1 uses an input message to create a new message in each step, and executes a step function using this new message as input. This new message creation is considered resistant to attacks that are based on message manipulation. SHA-1 outputs a 160-bit hash value by performing four rounds and 80 steps of operations for each message block.

~~1.2 Technical Specifications~~

~~SHA-1 takes a message of any length as input and outputs a 160-bit hash value. The input data is processed in 512-bit blocks. The process flow consists of the following five steps:~~

Step 1: Addition of padding bits As with MD5, an input message is processed so that its bit length becomes 448 mod 512 bits. During this process, additional bits are always added, even if the 448 mod 512-bit length is satisfied. The padding bits begin with "1", followed by the necessary number of 0s, and are added immediately following the message bits.

~~Step 2: Addition of length information As with MD5, mod 264 of the bit length of the original input message (before padding) is added after the padding bits in 64-bit length.~~

With the steps up to this point, the bit length of the original message has been transformed into a multiple of 512 bits. The expanded message can be expressed as a 512-bit block series, e.g., Y0, Y1, K YL-1, and the total bit length is L x 512 bits.

Step 3: Buffer initialization The buffers (chain variables) for storing the hash values are expressed as (A, B,C, D, E) using five 32-bit registers. These 160-bit buffers store the intermediate value of the hash values and are used as the inputs for the compression function, or store the final result. The following values are stored in these registers before the process enters the first compression function:

~~359 CRYPTREC 2000~~

~~A = 0x67452301 B = 0xEFCDAB89 C = 0x98BADCFE D = 0x10325476 E = 0xC3D2E1F0 These values are the same as in RIPEMD-160. The first four are the same as in MD5.~~

Step 4: Compression The main feature of SHA-1 is a compression function consisting of four rounds, each of which has 20 steps. Although these four rounds have similar structures, they perform compression using

different logical operation functions called f1, f2, f3, and f4. Each round takes the 512-bit block Yq being processed and the value in the 160-bit buffer as inputs. The output value from each round is used to update the values in the 160-bit buffers ABCDE.

~~The output from the fourth round (80th step) is added to the input (CVq) of the first round of the~~

~~compression function, becoming CVq+1, which is then used in the next compression function. This addition is performed in independent mod 232 in five buffers.~~

~~Step 5: Message digest output After all of the L 512-bit long blocks have been processed by compression functions, the hash values in the 160-bit buffers are output.~~

~~2. Evaluation Results~~

~~2.1 Security evaluation~~

As explained in relation to SHA-1's algorithm, analyzing SHA-1 requires the analysis of both the compression functions and the part that expands messages. The input-expansion area of SHA, the previous version of SHA-1, consisted of EXOR only, and based on its analysis, a collision involving a compression function could be discovered. However, it has been reported that this attack on SHA cannot be applied to SHA-1, which uses 1-bit leftward cyclic shift in the message-expansion area. Because no practical attack on SHA-1 has so far been reported, SHA-1 can be considered secure for use in the cipher-application field. However, resistance to exhaustive searches must be maintained. When the hash value length is n bits, a collision may be discovered among the hash values for 2n/2 messages using a Birthday attack, and therefore the hash value must be made sufficiently long. Because a collision may be discovered among 280 hash values in SHA-1 with a hash value of 160 bits long, future security of SHA-1 cannot be guaranteed.

~~360 CRYPTREC 2000~~

~~7. Evaluation of Pseudorandom Number Generation Methods~~

The following table describes the pseudorandom number generation methods that were evaluated. Section 7.1 compares the pseudorandom-number categories in terms of characteristics, security, and implementation, and includes short comments. Section 7.2 describes the individual pseudorandom number generation methods in more detail.

~~Pseudorandom number generation names~~

~~TOYOCRYPT-HR1, Pseudorandom-num Pseudo-Random Number Generator based on SHA-1 ber generation (FIPS186:DIGITAL SIGNATURE STANDARD APPENDIX C)~~

~~7.1 Evaluation by type Pseudorandom number generation list~~

Pseudo-Random Number TOYOCRYPT-HR1 Generator based on SHA-1 Uses both a 128-round linear A pseudorandom-number generator feedback shift register and a based on the Secure Hash non-linear Boolean logical Algorithm (SHA-1) specified in function. This is a FIPS180-1. Characteristics pseudorandom number generation algorithm that is classified as a non-linear filter generator. A divide-and-conquer attack using 64-bit known plaintexts is possible with O (296) when LFSR is known, and O (2215) when LFSR is unknown. Furthermore, because the effective length for the 128-bit secret key length is 96 bits, a time memory trade-off method Statistical based on a 232-bit output series (about 264 computations and about characteristics 232-bit storage capacity) may exist. Based on the results of this Suitability for security evaluation, TOYOCRYPT-HR1 was judged not pseudorandom-num recommendable for the Digital Government. Because there is a ber applications: 80 Security collision possibility for 2 hash values in SHA-1, the hash values size of input space must be made sufficiently long. Although a Pseudo-Random Number for the estimatable Generator based on SHA-1 currently would be no problem for the possibility Digital Government, care must be exercised for long-term use. If evaluation output possible, it would be more desirable to use a pseudorandom-number series generator that incorporates the next-generation SHA (SHA-256, SHA-384, or SHA-512), which outputs hash values of at least 160 bits and will most likely be established as the 2001 FIPS.

~~361 CRYPTREC 2000~~

~~7.2 Individual evaluation~~

~~7.2.1 TOYOCRYPT-HR1~~

~~1. Cryptographic Technique~~

~~1.1 Technical overview~~

TOYOCRYPT-HR1 is a pseudorandom number generation algorithm that was proposed by Toyo Communication Equipment Co., Ltd., and is classified as a non-linear filter generator. It uses a128-bit fixed key and a 128-bit stream key (internal state) as secret keys, and has a structure that generates a pseudorandom number bit by bit. TOYOCRYPT-HR1 is a pseudorandom number generation method used in the stream cipher TOYOCRYPT-HS1, the specification of which was published on September 29, 2000. This method is considered to be based on the same technology. Although the Fibonacci configuration is often used in non-linear combiners, the company is said to have decided to use a Galois configuration because it runs fast on hardware. It is claimed that in terms of security, the long-period characteristics of the pseudorandom number series, 0/1 frequency, linear complexity, and non-linear complexity were theoretically analyzed, and that the non-linear transformation function was designed to make TOYOCRYPT-HR1 sufficiently resistant to attacks unique to non-linear combiners, such as correlation attacks. The company also states that because TOYOCRYPT-HR1 has been designed with a focus on hardware performance, it is most effective in applications requiring ultra-fast pseudorandom-number generation using hardware that requires compact size and low power consumption. Because TOYOCRYPT-HR1 has an extremely simple structure, it can reportedly be compactly implemented in software.

Intellectual property rights (based on the application document) (Proposing organization's patents and their handling) Patent-application number: H10-039677 (Disclosure number: H11-224183) Pseudorandom-number generator Patent-application number: H10-129606 (Disclosure number: H11-305661) Shift registers and circuits for configuring a shift register Patent-application number: H10-267415 (Disclosure number: 2000-081969) Pseudorandom-number generator The applicant has not finalized a licensing policy.

~~The public web address for the specification of the cryptographic technique being proposed is: http://www.toyocom.co.jp~~

~~362 CRYPTREC 2000~~

~~1.2 Technical Specifications~~

TOYOCRYPT-HR1 is a pseudorandom number generation algorithm that is classified as a non-linear combiner. It uses a128-bit fixed key and a 128-bit stream key (internal state) as secret keys, and has a structure that generates a pseudorandom number bit by bit. The non-linear combiner generates a pseudorandom number bit by bit by outputting the linear feedback shift register via a non-linear transformation function. The design goals of TOYOCRYPT-HR1 are as follows: (1) Its security must be theoretically analyzable. (2) It must be fast and compact in size in hardware. (3) It must have a simple structure. It is said that TOYOCRYPT-HR1 also was designed based on the following design standards: (1) Theoretically guarantee equal 0/1 frequency. (2) Theoretically guarantee long periods (guarantee the lower limit of the periods). (3) Theoretically guarantee the lower limit of linear complexity to ensure a smooth ramp-up. (4) Build a structure that is sufficiently resistant to attacks unique to non-linear combiners. (5) Achieve fast operations and small size when implemented in hardware. Of these standards, (1) through (4) are security requirements for the pseudorandom number generation algorithm, i.e., conditions for making it difficult to estimate other partial bits from partial series of the generated pseudorandom numbers. In particular , standard (4) is included to take into account such typical attacks as fast correlation attacks, inversion attacks, and conditional correlation attacks.

~~1.3 Other~~

~~None.~~

~~2. Evaluation Results~~

~~2.1 Security evaluation~~

Because TOYOCRYPT-HR1 could become decodable in the computation environment of the near future, it cannot be recommended in its current form as a cipher for the Digital Government. Improvements must be made to the proposed algorithm before it can be adopted in an actual system. If the fixed key is known, the effective key length is drastically reduced from 128 bits to 96 bits at the most. Although this is in the secure range based on the current processing capability of computers, future security must be judged by the administrator. One of the operational issues is how to provide the

~~363 CRYPTREC 2000~~

LFSR seed. At least a clear guideline for this issue must be provided. Seed omission will affect the security of this random-number generator. Detailed evaluations have been performed on the statistical characteristics of the random-number series obtained in terms of long-period characteristics, series, equal 0/1 frequency, white-noise characteristics such as self-correlation, etc., as well as linear complexity, and satisfactory and reasonable results have been reported. It has also been reported that several attempts were made using an ordinary attack based on an entropy test, and a correlation attack, which is a representative attack method against stream ciphers, but none of these resulted in an effective attack. However, the structural defects of the algorithm, as described as follows, have also been reported. Improvements must be made in relation to items (1) and (2) in particular before the proposed algorithm can be adopted in an actual system.

（１） If the fixed key is known, the effective key length is drastically reduced from 128 bits to 96 bits at the most. If the fixed key is unknown, the effective key length is reduced from 248 bits to 215 bits at the most. Furthermore, the length of the plaintexts necessary for this attack is only 64 bits. This can lead to a divide-and-conquer attack or a time memory tradeoff method. #A similar issue also has been reported in SCIS2001. Mihaljevic, Imai, Effective Secret Key Size of TOYOCRYPT-HS1 Stream Cipher, Proc. of SCIS, pp.665-667, February 7, 2001 The analysis result indicates that a 128-bit key can be determined from 232-bit output data, using approximately 232 memory and 264 computations. Because there has been a report indicating that this drastic reduction can be avoided by slightly tweaking the input into the g function or π function, improvements should be made before use.

（２） If a fixed key is used as the key to be generated as a random number, the generation may take too long to be practical in on-line applications (e.g., common key generation in a cipher protocol). Therefore, the fixed key may be provided from the start in some cases. In this case, the problem described in item (1) previously becomes more prominent. As an operational issue, a guideline on how the LFSR seed will be provided must be clarified. Seed omission will directly affect the security of this random-number generator.

~~2.2 Software (SW)-implementation evaluation~~

~~The self-evaluation document shows the following:~~

~~Programming language: ANSI-C~~

~~364 CRYPTREC 2000~~

Target processor: SH1 made by Hitachi (32-bit RISC processor) Evaluation environment: SH1 Compiler Simulator made by Hitachi, Windows 95 Ver. 5.0 Compilation condition: Speed priority, no loop/inline expansion

Serial implementation Parallel implementation Execution speed 66991 cycle/word,9.56 Kbps (at 20MHz) 3678 cycle/word,174 Kbps (at 20MHz) Key setup 591112 cycle, 30.0 ms (at 20MHz) 673332 cycle, 33.7 ms (at 20MHz) Program code 910 bytes 800 bytes Constants 368 bytes 1360 bytes (including keys) Stack (RAM) 1184 bytes 2052 bytes

TOYOCRYPT-HR1 has been designed to achieve the highest performance (compact size and high speed) in hardware. Serial implementation uses a bitslice-implementation method, a method that produces the same level of output as in normal implementation, albeit not very efficiently. Parallel implementation is a method that simultaneously outputs the processor's word-long independent pseudorandom number data efficiently.

~~2.3 Hardware (HW) implementation evaluation~~

~~For TOYOCRYPT-HS1's evaluation, refer to the result obtained using Altera's FPGA "EP20K600E."~~

~~The self-evaluation document shows the following simulation results using an FPGA:~~

~~Simulation tool: SILOS III Ver. 99.070 (SIMCAD. Inc.) Target device: QL3012-4, device process: C-MOS 0.35 µm, four-layer~~

Compile option Item Sub-item Performance Worst case 227 MHz (Mbps) Execution speed Normal case 340 MHz (Mbps) Speed priority Best case 418 MHz (Mbps) Cell 233/320 (71.6%) Circuit size Routing resources 3340/42812 (7.8%) Worst case 81 MHz (Mbps) Execution speed Normal case 122 MHz (Mbps) Circuit-size priority Best case 150 MHz (Mbps) Cell 196/320 (61.3%) Circuit size Routing resources 2928/42812 (6.8%)

~~365 CRYPTREC 2000~~

~~The self-evaluation document shows the following performance estimate using a gate array:~~

~~When a gate array (TC200G52, 3.3 V, three-layer, 0.4-µm process, made by Toshiba) is used, 223 Mbps (worst case, 70ºC, 3.0 V) can reportedly be achieved with approximately 3.3 Kgates.~~

~~Condition Delay [ns] Speed [MHz] Worst case 4.5 223 Normal case 2.5 403 Best case 1.3 790~~

~~Reference [1] Koichi Sugimoto, Tetsuya Chikaraishi, and Tetsuya Morizumi, Stream Cipher Designing Method and Evaluation, Shingaku Giho ISEC2000-69.~~

~~366 CRYPTREC 2000~~

~~7.2.2 PRNG based on SHA-1~~

~~(FIPS186-2:DSS Appendix 3.Random number Generator for the DSA)~~

~~1. Cryptographic Technique~~

~~1.1 Technical overview~~

The Digital Signature Algorithm (DSA) requires a user secret key x, a secret key k for each message signature, and r = (gk mod p)mod q (where p, q, and g are public parameters). For generating these parameters, the Digital Signature Standard (DSS) of FIPS186 (May 1994, revised in January 2000 as FIPS186-2) specifies the following three pseudorandom number generation methods as FIPS-recommended versions: (1) A 160-bit one-way function G(t, c) according to "Financial Institution Key Management (Wholesale)" in Appendix 2.4 of ANSI X9.31 (t is 160 bits, c is b bits. If G[•] is based on SHA-1, 160 ≤ b ≤ 512; if G[•] is based on Data Encryption Algorithm [DEA] [DES is used in Appendix C of ANSI X9.17], b = 160 fixed). (2) Method for generating m kinds of x in Appendix 3.1 of FIPS186-2. The 160-bit one-way function G(t, c) is based on SHA-1 or DES. (3) Method for generating m kinds of k and r that are not based on the knowledge about the messages to be signed, in Appendix 3.2 of FIPS186-2. The 160-bit one-way function G(t, c) is based on SHA-1 or DES.)

FIPS 186 recommended the use of the Secure Hashing Algorithm (SHA), which meets the FIPS 180 standard. Subsequently, the Secure Hash Standard (SHS) was specified as the FIPS 180-1 standard in April 1995, and the specification of the Secure Hash Algorithm (SHA-1) that generates 160-bit long hash values was announced as the only recommended version of SHS.

To strengthen the various types of statistical tests for assaying the randomness of the binary values used in the cipher-application field and to promote software implementation of various types of tests and test applications, NIST has published Random Number Generation and Testing on the Web.

~~1.2 Technical specifications~~

~~(Technical specifications for the method for generating m kinds of x in Appendix 3.1 of FIPS186-2)~~

~~(1) Select a new secret number ω xkey .~~

~~(2) Select the following initial value of 512-bit H 0 H1 Λ H 4 in SHS:~~

~~367 CRYPTREC 2000~~

~~t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0~~

~~(3) Repeat (a) - (d) described as follows using 0 ≤ j ≤ m −1 .~~

~~(a) Select ω j (user option).~~

~~b (b) c j = (ω xkey + ω j ) mod 2 ,160 ≤ b ≤ 512~~

~~(c) x j = G(t,c j ) mod q~~

~~b (d) ω xkey = (1+ ω xkey + x j ) mod 2~~

~~(Technical specifications for the method for generating m kinds of r and k in Appendix 3.2 of FIPS186-2)~~

~~(1) Select a new secret number ω kkey .~~

~~(2) Select the following value that results from shifting the initial value of 512-bit H 0 H1 Λ H 4 in~~

~~SHS:~~

~~t = EFCDAB89 98BADCFE 10325476 C3D2E1F0 67452301~~

~~(3) Repeat (a) - (d) described as follows using 0 ≤ j ≤ m −1 .~~

~~(a) k = G(t,ω kkey ) mod q~~

~~−1 −1 (b) Compute k j = k mod q .~~

~~k (c) rj = (g mod p) mod q~~

~~b (d) ω kkey = (1+ ω kkey + k) mod 2~~

~~(4) Repeat (a) - (c) described as follows using M 1 , M 2 ,Λ, M m−1 as m messages.~~

~~(a) h = SHA-1 (M j ) , SHA-1(•) means a one-way function based on SHA-1.~~

~~−1 (b) Compute s j = (k j (h + xrj ))mod q .~~

~~(c) (rj , s j ) is used as the signature for M j .~~

~~(5) t = h (6) Return to (3).~~

~~368 CRYPTREC 2000~~

(Technical specifications for the one-way function G(t,c) are based on SHA-1) G(t,c) can be computed according to procedures (a) - (e) in Sec. 7 of the Technical Specification of Secure Hash Standard (SHS) listed as follows under (II). However, before executing these procedures, initialize {H j } and perform input-message padding according to the following procedure:

~~(I) {H j } initialization and padding of c~~

~~(i) Use H j = t j , ( 0 ≤ j ≤ 4 ) in the 32-bit partitioning of 160-bit t, i.e., t = t0 t1 Λ t4~~

~~(ii) X = c 0512−b~~

~~Next, execute the procedures (a) - (e) described as follows and use the 160-bit character string~~

G(t,c) = H 0 H1 Λ H 4 obtained in procedure (e) as the output. (II) Procedures in Sec. 7 of the technical specification of SHS The padded message X shown previously consists of 16 × n words words (1 word is 32 bits). These n blocks (1 block is 16 words, 512 bits) are designated as M 1 , M 2 ,Λ, M n . The first block M 1 contains the first several blocks of the input message c. For the first group of buffers A, B,C, D, E, F of the five 32-bit words, the second buffer group

~~H 0 , H1 ,Λ, H 4 , and 80-words group W0 ,W1 ,Λ,W79 the initial value of H 0 H1 Λ H 4 is set as follows:~~

~~t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0~~

~~Assume that n messages M 1 , M 2 ,Λ, M n have been processed. The procedures (a) - (e) described as follows are executed for processing M i .~~

~~(a) Divide M i into 16 words. M i = W0 W1 Λ W15~~

~~1 (b)Wt = S (Wt−3 ⊕Wt−8 ⊕Wt−14 ⊕Wt−16 ) ,16 ≤ t ≤ 79 .~~

~~Note that ⊕ means EXOR, and S n (X ) means a leftward n bit cyclic shift operation (0 ≤ n ≤ 32) of word X, i.e., S n (X ) = (X << n) ∪ (X >> 32 − n)~~

(c) Set A = H 0 , B = H1 ,C = H 2 , D = H 3 , E = H 4 . (d) Perform the computation described as follows for 0 ≤ t ≤ 79 . Before entering a character string x with a bit length of λ ≤ 264 −1, which is equal to or less than 64 bits, into SHA-1, perform the following padding:

~~X = x 1 0m λ~~

~~Note that m + λ +1 = 448mod512 .~~

~~369 CRYPTREC 2000~~

~~5 TEMP = S (A) + f t (B,C, D) + E + Wt + K t ;~~

~~E = D; D = C;C = S 30 (B); B = A; A = TEMP~~

~~Note that ft (B,C, D) is defined as follows.~~

~~(B ∩ C) ∪ (B ∩ D), (0 ≤ t ≤ 19)~~

~~ft (B,C, D) = B ⊕ C ⊕ D, (20 ≤ t ≤ 39) (B ∩ C) ∪ (B ∩ D) ∪ (C ∩ D), (40 ≤ t ≤ 59) B ⊕ C ⊕ D, (60 ≤ t ≤ 79)~~

~~Where, ・, ∩ , and ∪ indicate logical NOT, logical product, and logical add, respectively. K t is a constant defined as follows.~~

~~5A827999 , (0 ≤ t ≤ 19)~~

~~K t = 6ED9EBA1, (20 ≤ t ≤ 39) 8F1BBCDC , (40 ≤ t ≤ 59) CA62C1D6 , (60 ≤ t ≤ 79)~~

~~(e)~~

~~H 0 = H 0 + A~~

~~H1 = H1 + B~~

~~H 2 = H 2 + C~~

~~H 3 = H 3 + D~~

~~H 4 = H 4 + E~~

~~(III) After the last message M n is processed, 160-bit H 0 H1 Λ H 4 are output as hash values.~~

~~1.3 Other~~

~~A. CMV Program~~

To establish standards such as the Digital Signature Standard (DSS) and Secure Hash Standard (SHS), the Cryptographic Module Validation (CMV) Program by NIST has evaluated DSA, RSA, SHA-1, etc., using the Digital Signature Validation System (DSSVS), v2.3. It is expected that three kinds of

~~370 CRYPTREC 2000~~

~~next-generation SHA that are capable of outputting longer message digests, for use in the next revisions of DSA and AES, will be proposed as 2001 FIPS drafts.~~

~~B. Next-generation SHA technical specifications~~

For AES, three types (SHA-256, SHA-512, and SHA-384) are being proposed as new hash functions with enhanced security. (1) SHA-256: Based on the same design as MD4, MD5, and SHA-1. (i) Compute the following 512-bit-long padded message from bit character string x:

~~M = x 1 0k λ~~

~~Note that x is a modulo 232 integer, λ = x mod264 , and λ +1+ k ≡ 448mod512 .~~

~~()i N (i) (ii) Partition M into N ≡ 0mod16 512-bit blocks {M }i=1 . Note that M consists of 16~~

~~32-bit-long words. (0) (iii) Compute the following recurrence formula using the initial hash value H , compression function C .(•) and SHA-256 message-schedule function:~~

~~(i) (i−1) (i ) , H = H + CM ()i (H ) 1 ≤ i ≤ N~~

32 (N ) Note that “ + ” means modulo 2 computation for each 32-bit word. H is the hash value of M . (2) SHA-512: The 32-bit word length of SHA-256 has been changed to 64. (i) Compute the following 1024-bit-long padded message from bit character string x:

~~M = x 1 0k λ~~

~~Note that x is a modulo 264 integer, λ = x mod 2128 , and λ +1+ k ≡ 896 mod1024 .~~

~~()i N (i) (ii) Partition M into N ≡ 0mod16 1024-bit blocks {M }i=1 . Note that M consists of 16~~

~~64-bit-long words. (0) (iii) Compute the following recurrence formula using the initial hash value H , SHA-512 compression function C .(•), and SHA-512 message-schedule function:~~

~~(i) (i−1) (i ) , H = H + CM ()i (H ) 1 ≤ i ≤ N~~

~~64 (N ) Note that “ + ” means modulo 2 computation for each 64-bit word. H is the hash value of M . (3) SHA-384: Basically the same as SHA-512, with the following two different points:~~

~~371 CRYPTREC 2000~~

~~(0) Change in the initial hash value H , and the value obtained by truncating the 512-bit hash value (N ) H after the first 384 bits on the left side is used as the hash value.~~

~~C. Cryptographic Toolkit~~

According to the Cryptographic Toolkit, random number generation methods can basically be classified into Random Number Generator (RNG) ("true" random number generator that is usually referred to as a nondeterministic theory generator) and Pseudorandom Number Generators (PRNGs) (so-called deterministic theory generators). The first method generates based on noise in an electrical circuit, user key stroke on a computer, timing such as mouse movement, or some sort of physical quantity such as quantum effect in a semiconductor. The output of an RNG itself is used as a random number or as an input into a PRNG. The latter method generates multiple "pseudorandom numbers" in response to single or multiple inputs using the output from an RNG as a seed (the output of the PRNG is a function of the seed). At present, there is no FIPS standard for the latter. A PRNG number string can be generated faster than one generated from a physical source in an RNG, and according to evaluation using a statistical testing method for randomness, PRNG is known to often provide excellent values. To standardize the method used by the U.S. government and other organizations for selecting cipher-security technologies, NIST is developing recommendations and comprehensive standards for creating guidelines with respect to various Cryptographic Toolkits, such as Encryption, Modes of Operation, Digital Signatures, Secure Hashing, Key Management, Random-Number Generation, Message Authentication, Entity Authentication, and Password Usage and Generation.

~~D. 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-testing methods, their uses, interpretation of their results, and other pseudorandom number generation methods.

References • Cryptographic Toolkit:http://csrc.nist.gov/encryption/ • Secure Hashing:http://csrc.nist.gov/encryption/tkhash.html • Random Number Generation:http://csrc.nist.gov/encryption/tkrng.html • New hashing algorithms (SHA-256,SHA-384, and SHA-512): Descrptions of SHA-256,SHA-384, and SHA-512 • FIPS Pub 186-2,Digital Signature Standard (DSS) (updated on January 27, 2000) Appendix3:Random

~~372 CRYPTREC 2000~~

Number Generation for the DSA • NIST Special Pubilication 800-22 (updated in December 2000) A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications • FIPS140-1, Security Requirements for Cryptographic Modules, Cryptographic Module Validation (CMV) Program: http://csrc.nist.gov/cryptval/cmvp.html

~~2 Evaluation Results~~

~~2.1 Security evaluation~~

~~A. Overview~~

We believe that there is no problem in using a FIPS approved pseudorandom number generator (with SHA-1) in the Digital Government. However, it must be noted that assumptions for a theoretical proof cannot be established if this SHA-1-based pseudorandom number is used for realizing a random oracle in the cryptographic method to be used (electronic signature). Nonetheless, the SHA-1-based pseudorandom number should not pose any problems because of restrictions in the implementation environment, though the actual situation would depend on the application that uses the pseudorandom number. However, if SHA-1 itself is used for a hash function for electronic signatures, there is a risk of alteration with about 280 computations based on a birthday attack. Nowadays, this is the lowest security level. If possible, it would be more desirable to use the next-generation SHA with a longer output, which will be standardized within the next one to two years. If restrictions are placed in the implementation environment, even the SHA-1 (or DES)-based FIPS186 pseudorandom number generator can be used securely, considering the length of the pseudorandom numbers to be generated and the number of times they will be generated.

~~B. DSA flaw~~

News that Daniel Bleichenbacher, a researcher at the Bell Research Laboratories, had discovered a bias in the random numbers of DSA (news of a DSA flaw) was circulated (on February 6, 2001). However, it has been reported that the DSA flaw may not be caused by SHA-1. NIST's formal response regarding the DSA flaw, based on a discussion held at the ANSI X9F1 Conference (which is handling X9.30 DSA standardization) is as follows: • No problem exists if the number of signatures is 2 million or less. • If the algorithm is to be fixed in software, ECDSA should be used to generate a k that is at least twice the hash length. • For computing k , additional bits of at least 32 bits are needed. That is, for a 160-bit k ,

~~373 CRYPTREC 2000~~

~~random bits of at least 192 bits are required.~~

~~Reference [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~~

~~374 CRYPTREC 2000~~

~~8. Other~~

~~8.1 Cryptographic Techniques Evaluated~~

~~(1) Public-key cryptosystems~~

Number Cryptosystem Cryptosystem Evaluation result type name 1 Public-key ACE Encrypt This cryptosystem was proposed through public invitation cryptosystem for applications. Screening and detailed evaluation were (confidentiality) performed. See Chapter 4 of this report for the evaluation results. 2 Public-key ECAES in This cryptosystem was proposed through public invitation cryptosystem SEC1 for applications. Screening and detailed evaluation were (confidentiality) performed. See Chapter 4 of this report for the evaluation results. 3 Public-key EPOC This cryptosystem was proposed through public invitation cryptosystem for applications. Screening and detailed evaluation were (confidentiality) performed. See Chapter 4 of this report for the evaluation results. 4 Public-key ESIGN This cryptosystem was proposed through public invitation cryptosystem identification for applications. Screening and detailed evaluation were (confidentiality) performed. See Chapter 4 of this report for the evaluation results. 5 Public-key HIME-2 This cryptosystem was proposed through public invitation cryptosystem for applications. Screening and detailed evaluation were (confidentiality) performed. See Chapter 4 of this report for the evaluation results. 6 Public-key PSEC This cryptosystem was proposed through public invitation cryptosystem for applications. Screening and detailed evaluation were (confidentiality) performed. See Chapter 4 of this report for the evaluation results. 7 Public-key RSA-OAEP This cryptosystem was proposed through public invitation cryptosystem for applications. Screening and detailed evaluation were (confidentiality) performed. See Chapter 4 of this report for the evaluation results. 8 Public-key Cryptosystem This cryptosystem was proposed through public invitation cryptosystem that uses a for applications. Screening was performed. (confidentiality) numerical Determined that this cryptosystem does not fit the public expression that invitation category. (It is considered not established as a proves that an public-key cryptosystem technology.) infinite number of prime numbers exist. 9 Public-key ACE Sign This cryptosystem was proposed through public invitation cryptosystem for applications. Screening and detailed evaluation were (signature) performed. See Chapter 4 of this report for the evaluation results. 10 Public-key DSA This cryptosystem was judged to require evaluation cryptosystem regardless of whether or not it was submitted for evaluation (signature) through public invitation. Detailed evaluation was performed. See Chapter 4 of this report for the evaluation results.

~~375 CRYPTREC 2000~~

Number Cryptosystem Cryptosystem Evaluation result type name 11 Public-key ECDSA in This cryptosystem was proposed through public invitation cryptosystem SEC1 for applications. Screening and detailed evaluation were (signature) performed. See Chapter 4 of this report for the evaluation results. 12 Public-key ESIGN – This cryptosystem was proposed through public invitation cryptosystem signature for applications. Screening and detailed evaluation were (signature) performed. See Chapter 4 of this report for the evaluation results. 13 Public-key MY-ELLTY This cryptosystem was proposed through public invitation cryptosystem ECMR-160-h for applications. Screening and detailed evaluation were (signature) performed. See Chapter 4 of this report for the evaluation results. 14 Public-key MY-ELLTY This cryptosystem was proposed through public invitation cryptosystem ECMR-160-p for applications. Screening was performed. (signature) Determined that this cryptosystem is not secure enough (padding method is not secure.) 15 Public-key MY-ELLTY This cryptosystem was proposed through public invitation cryptosystem ECMR-192-h for applications. Screening and detailed evaluation were (signature) performed. See Chapter 4 of this report for the evaluation results. 16 Public-key MY-ELLTY This cryptosystem was proposed through public invitation cryptosystem ECMR-192-p for applications. Screening was performed. (signature) Determined that this cryptosystem is not secure enough (padding method is not secure.) 17 Public-key MY-ELLTY This cryptosystem was proposed through public invitation cryptosystem ECMR-OEF-h for applications. Screening and detailed evaluation were (signature) performed. See Chapter 4 of this report for the evaluation results. 18 Public-key MY-ELLTY This cryptosystem was proposed through public invitation cryptosystem ECMR-OEF-p for applications. Screening was performed. (signature) Determined that this cryptosystem is not secure enough (padding method is not secure.) 19 Public-key RSA-PSS This cryptosystem was judged to require evaluation cryptosystem regardless of whether or not it was submitted for evaluation (signature) through public invitation. Detailed evaluation was performed. See Chapter 4 of this report for the evaluation results. 20 Public-key DH This cryptosystem was judged to require evaluation cryptosystem regardless of whether or not it was submitted for evaluation (key sharing) through public invitation. Detailed evaluation was performed. See Chapter 4 of this report for the evaluation results. 21 Public-key ECDHS in This cryptosystem was proposed through public invitation cryptosystem SEC1 for applications. Screening and detailed evaluation were (key sharing) performed. See Chapter 4 of this report for the evaluation results. 22 Public-key ECMQVS in This cryptosystem was proposed through public invitation cryptosystem SEC1 for applications. Screening and detailed evaluation were (key sharing) performed. See Chapter 4 of this report for the evaluation results.

~~376 CRYPTREC 2000~~

Number Cryptosystem Cryptosystem Evaluation result type name 23 Public-key EPOC key This cryptosystem was proposed through public invitation cryptosystem sharing for applications. Screening was performed. (key sharing) Decided not to perform a detailed evaluation of this cryptosystem in the "key sharing" category because it has the same technical specification as the cryptosystem included in the "confidentiality" category. 24 Public-key HDEF-ECDH This cryptosystem was proposed through public invitation cryptosystem for applications. Screening and detailed evaluation were (key sharing) performed. See Chapter 4 of this report for the evaluation results. 25 Public-key HIME-1 This cryptosystem was proposed through public invitation cryptosystem for applications. Screening and detailed evaluation were (key sharing) performed. See Chapter 4 of this report for the evaluation results. 26 Public-key PSEC key This cryptosystem was proposed through public invitation cryptosystem sharing for applications. Screening was performed. (key sharing) Decided not to perform a detailed evaluation of this cryptosystem in the "key sharing" category because it has the same technical specification as the cryptosystem included in the "confidentiality" category.

~~(2) Symmetric ciphers~~

Number Cryptosystem Cryptosystem name Evaluation result type 1 Symmetric CIPHERUNICORN-E This cryptosystem was proposed through public cipher (64-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 2 Symmetric FEAL-NX This cryptosystem was proposed through public cipher (64-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 3 Symmetric Hierocrypt-L1 This cryptosystem was proposed through public cipher (64-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 4 Symmetric MISTY1 This cryptosystem was proposed through public cipher (64-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 5 Symmetric Triple DES This cryptosystem was judged to require evaluation cipher (64-bit regardless of whether or not it was submitted for block cipher) evaluation through public invitation. Detailed evaluation was performed. See Chapter 5 of this report for the evaluation results.

~~377 CRYPTREC 2000~~

Number Cryptosystem Cryptosystem name Evaluation result type 6 Symmetric Camellia This cryptosystem was proposed through public cipher (128-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 7 Symmetric CIPHERUNICORN-A This cryptosystem was proposed through public cipher (128-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 8 Symmetric FS-CES This cryptosystem was proposed through public cipher (128-bit invitation for applications. Screening was performed. block cipher) Determined that the processing speed (as a block cipher) was not sufficient. 9 Symmetric Hierocrypt-3 This cryptosystem was proposed through public cipher (128-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 10 Symmetric K-7 This cryptosystem was proposed through public cipher (128-bit invitation for applications. Screening was performed. block cipher) Determined that this cryptosystem does not fit the application category, and description is insufficient for a third party to implement and evaluate this cryptosystem. 11 Symmetric MARS This cryptosystem was proposed through public cipher (128-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 12 Symmetric RC6 This cryptosystem was proposed through public cipher (128-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 13 Symmetric Rijndael This cryptosystem was judged to require evaluation cipher (128-bit regardless of whether or not it was submitted for block cipher) evaluation through public invitation. Detailed evaluation was performed. See Chapter 5 of this report for the evaluation results. 14 Symmetric SC2000 This cryptosystem was proposed through public cipher (128-bit invitation for applications. Screening and detailed block cipher) evaluation were performed. See Chapter 5 of this report for the evaluation results. 15 Symmetric SXAL/MBAL This cryptosystem was proposed through public cipher (128-bit invitation for applications. Screening was performed. block cipher) Determined that self-evaluation was insufficient. 16 Stream cipher FSAngo This cryptosystem was proposed through public invitation for applications. Screening was performed. Determined that security is insufficient. 17 Stream cipher GCC Chaos cipher This cryptosystem was proposed through public invitation for applications. Screening was performed. Determined that description is insufficient for a third party to implement and evaluate this cryptosystem. (Algorithm cannot be evaluated.) 18 Stream cipher MDSR This cryptosystem was proposed through public invitation for applications. Screening was performed. Determined that self-evaluation was insufficient.

~~378 CRYPTREC 2000~~

Number Cryptosystem Cryptosystem name Evaluation result type 19 Stream cipher MULTI-S01 This cryptosystem was proposed through public invitation for applications. Screening and detailed evaluation were performed. See Chapter 5 of this report for the evaluation results. 20 Stream cipher SEAL Was not evaluated because an application-withdrawal notice was received. 21 Stream cipher TOYOCRYPT-HS1 This cryptosystem was proposed through public invitation for applications. Screening and detailed evaluation were performed. See Chapter 5 of this report for the evaluation results.

~~(3) Hash functions~~

Number Cryptosystem Cryptosystem name Evaluation result type 1 Hash function MD5 This cryptosystem was judged to require evaluation regardless of whether or not it was submitted for evaluation through public invitation. Detailed evaluation was performed. See Chapter 6 of this report for the evaluation results. 2 Hash function RIPEMD-160 This cryptosystem was judged to require evaluation regardless of whether or not it was submitted for evaluation through public invitation. Detailed evaluation was performed. See Chapter 6 of this report for the evaluation results. 3 Hash function SHA-1 This cryptosystem was judged to require evaluation regardless of whether or not it was submitted for evaluation through public invitation. Detailed evaluation was performed. See Chapter 6 of this report for the evaluation results.

~~(4) Pseudorandom number generators~~

Number Cryptosystem Cryptosystem name Evaluation result type 1 Pseudorandom-n FSRansu This cryptosystem was proposed through public umber invitation for applications. Screening was performed. generation Determined that security is insufficient. 2 Pseudorandom-n Pseudo-Random This cryptosystem was judged to require evaluation umber Number Generator regardless of whether or not it was submitted for generation based on SHA-1 evaluation through public invitation. Detailed evaluation was performed. See Chapter 7 of this report for the evaluation results. 3 Pseudorandom-n TAO TIME This cryptosystem was proposed through public umber code-generation system invitation for applications. Screening was performed. generation Determined that it could not be evaluated because no cryptographic technique specification had been submitted.

~~379 CRYPTREC 2000~~

4 Pseudorandom-n TOYOCRYPT-HR1 This cryptosystem was judged to require evaluation umber regardless of whether or not it was submitted for generation evaluation through public invitation. Detailed evaluation was performed. See Chapter 7 of this report for the evaluation results. 5 Pseudorandom-n Tsw-b This cryptosystem was proposed through public umber invitation for applications. Screening was performed. generation Determined that security is insufficient, and description is insufficient for a third party to implement and evaluate this cryptosystem. 6 Pseudorandom-n Mersenne Twister This cryptosystem was proposed through public umber invitation for applications. Screening was performed. generation Determined that description is insufficient for a third party to implement and evaluate this cryptosystem.

~~380 CRYPTREC 2000~~

~~8.2 Trend Toward Cipher Standardization~~

~~8.2.1 About DES/AES~~

~~Related web address: http://csrc.nist.gov/encryption/~~

~~(1) DES~~

DES (Data Encryption Standard) is a U.S. government standard cipher algorithm that was thoroughly tested for security and established by the U.S. National Bureau of Standards (NBS), the predecessor to the National Institute of Standards and Technology (NIST), as a standard for the purpose of protecting computer data and communication. The algorithm possesses interoperability and can withstand actual use. DES is a symmetric cipher algorithm that has been in use for more than 20 years as FIPS (FIPS46) and ANSI (X3.92), and is the first commercial-level algorithm that has been made completely public. FIPS46-3 is expected to use DES only for downward compatibility and to use Triple DES for encryption and decryption.

DES Challenge DES Challenge is a DES-breaking contest organized by RSA Security Inc. of the U.S. Because the rule calls for searching for a key given several pairs of plaintexts and ciphertexts (along with the initial vector), the contest is basically the same as an exhaustive search contest for the DES key space. The DES Challenge was held four times in total between 1997 and 1998. DES Challenge I, which began on January 28, 1997, was broken in 140 days by a network-distributed method of distributed.net. In this method, distributed.net called for a large number of volunteers who have computers connected to the Internet, and used these computers to run dedicated breaking software on a distributed-processing basis. DES Challenge II-1, which began on January 13, 1998, was also broken by distributed.net in 39 days. In DES Challenge II-2, which began on July 13, 1998, the Electronic Frontier Foundation used a dedicated machine designed for DES Challenge and succeeded in breaking in 56 hours. EFF DES Cracker, which cost as much as $210,000 to build, is a special parallel machine for DES Challenge that has 1,536 dedicated AWT-6001 LSIs, which had been designed specifically for key-space searches. Each chip contains 24 key-search units. Although the producer of this EFF DES Cracker Project was John Gilmore, the actual development was jointly done by Cryptography Research Corporation and Advanced Wireless Technologies Corporation, both of which are U.S. companies. Because EFF DES Cracker can execute approximately 90 billion key searches per second, it take only a little more than nine days, even for searching through the entire 56-bit key space. DES Challenge III was successfully broken in 22 hours and 16 minutes through cooperation between distributed.net and EFF.

~~381 CRYPTREC 2000~~

~~(2) AES~~

AES (Advanced Encryption Standard) is the U.S.'s next-generation standard encryption algorithm, which replaces DES. Because the security and reliability of DES had declined by the latter half of the 1990's, Triple DES (FIPS 46-3) began to be used. However, there was an efficiency problem with Triple DES because it repeats DES three times. Therefore, it became necessary to select a cipher for replacing DES, which was sufficiently secure and fast at the same time. Although many of the new ciphers actually being used have been evaluated for security from a scientific perspective and are recognized to be secure to a certain extent, their security has not been completely evaluated or verified. Therefore, a cipher algorithm was needed that had gone through repeated security evaluations and verifications and that could be used by anybody without concern.

~~AES Selection Process~~

In 1997, the National Institute of Standards and Technology (NIST), a technology standardization organization under the U.S. Commerce Department, began a selection plan for the next-generation standard cipher to replace DES. The first step of the plan was to publicly invite applications for AES from around the world during 1998, and then to take approximately one year to evaluate these applications and narrow them down to five candidates for the final evaluation. Then, approximately one more year would be spent evaluating the five candidates to select the AES winner. Subsequently, the cryptographic algorithm selected as the AES would be standardized as a FIPS (Federal Information Processing Standard). The selection process was organized by NIST, and the NSA (National Security Agency) acted as a consultant. In the AES evaluation process, all related data was published on the Web. People were allowed to download all information related to the algorithms of the five final candidates, including their source codes. The evaluation rounds were performed in an open manner, with public comments being encouraged and discussion groups being held at the NIST Web site.

In October 2000, Rijndael was selected as the AES. At present (as of March 2001), a FIPS text draft has been made public, and public comments are being encouraged. Rijndael is expected to be issued as the formal FIPS by August or October of 2001.

~~382 CRYPTREC 2000~~

~~Required AES technology specifications • Must be a symmetric cipher. • Must be a block cipher. • Must support a block size of 128 bits. • Must support key lengths of 128, 192, and 256 bits.~~

~~The Rijndael public Web page is: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/~~

The process for selecting the AES was a completely open and visible one. It was not a non-transparent process like the one used for selecting DES. The AES (Rijndael), which has been determined to be sufficiently secure and to have excellent processing efficiency after being thoroughly scrutinized by cryptography scientists from all over the world for nearly three years, is expected to be used as the de facto standard cryptographic algorithm beyond the framework of FIPS. More than Rijndael's technical strength, the fact that the U.S.'s next-generation standard cipher was born in Europe should psychologically help make Rijndael the de facto standard. From now on, Rijndael is expected to spread, first by basically being established as a FIPS as AES, and then moving from AES to ANSI, to ISO, and then to IETF RFC.

~~383 CRYPTREC 2000~~

~~8.2.2 About the NESSIE Project~~

Related web address: http://cryptonessie.org/ NESSIE (New European Schemes for Signatures, Integrity, and Encryption) is a cipher algorithm standardization activity in Europe, and is being implemented as part of the Information Societies Technology Programme of the European Commission. NESSIE's aggressive plan is to create a recommendation list for all cryptographic components, including public-key cryptography, symmetric ciphers, and hash functions, in the three years from January 2000 to December 2002.

The main objective of the NESSIE Project is to create a list of strong cryptographic primitives by evaluating them (cryptographic components represented by block-cipher algorithms and public-key cryptographic algorithms). Primitives would be obtained through a public application process open to anyone, using a public procedure. One of the aims of this project is to make a contribution to the final stage of the AES block cipher standardization process organized by NIST in the U.S. The NESSIE Project will also collect new primitives related to confidentially, completeness, and authentication. In more specific terms, these primitives will be composed of block ciphers, stream ciphers, hash functions, message-authentication algorithms, digital-signature methods, and public-key cryptographic methods. The project also plans to develop methods for evaluating security and processing capability, as well as software tools for implementing these methods.

The goal of the NESSIE Project is to make its results widely available and to obtain a consensus based on those results through a public discussion forum. Ultimately, the project aims to maintain Europe's strong research position and to strengthen European industry's cryptography-related position.

Selection criteria NESSIE's selection criteria are security over a long period, market requirements, effectiveness (performance), and flexibility. More specifically, these criteria have been announced as follows:

Security is the most important criterion. This is because the security of a cryptographic primitive is essential for achieving reliability and consensus. This evaluation process is expected to be affected by progress that is made outside this project (e.g., new attack methods and evaluation methods). The second criterion relates to market requirements. Market requirements are related to the necessity of primitives, applicability, and worldwide usability. The third criterion is the performance of the primitive in a particular environment. For software, such an environment ranges from 8-bit processors (e.g., inexpensive smart cards), to 32-bit processors (e.g., the Pentium family), and to the latest 64-bit processors. For hardware, both FPGA and ASIC will be considered.

~~384 CRYPTREC 2000~~

~~The fourth criterion is flexibility. A primitive that can be used in a wide range of applications is clearly more desirable.~~

~~Applicant Primitives~~

NESSIE considers a wide range of cryptographic primitives as potential candidates. Specifically, primitives are classified into the following 10 types: [Type number] [Type name] Type 1 Block cipher Type 2 Synchronous stream cipher Type 3 Self-synchronizing stream cipher Type 4 Message-authentication code (MAC) Type 5 No-collision hash function Type 6 One-way hash function Type 7 Pseudo-random function Type 8 Asymmetric cryptography Type 9 Asymmetric digital signature method Type 10 Asymmetric authentication method

Evaluation criteria details The evaluation criteria consist of four parts: security criterion, implementation criterion, other criteria, and licensing condition. Each of these is described in detail as follows.

Security criterion Any attack must contain the same level of difficulty as ordinary attacks (exhaustive search or birthday attack) on the particular type of primitive would. A primitive is attacked and evaluated against the security claim made by the applicant. Any attack that succeeds with fewer computation resources than what the applicant claimed will reduce the value of the applicant's cryptographic technique. The primitive is evaluated within the range of environments described so far. Therefore, it is appropriate to consider resistance to side-channel attacks (e.g., timing attacks and differential power analysis).

Implementation criterion Software and hardware efficiency are assessed through comparison with another similar candidate and existing primitives. Execution codes and memory size are evaluated from the viewpoints of reasonableness under different conditions. Particular attention is paid to smart cards. A primitive is evaluated against the implementation claim made by the applicant. One that can be flexibly

~~385 CRYPTREC 2000~~

~~used in a wide range of applications is naturally more desirable.~~

~~Other criteria Design simplicity and clarity are important considerations. Variable parameters are not that important.~~

Licensing condition If selected by NESSIE, a candidate primitive must be royalty-free. If possible, the use of the primitive must be non-discriminatory. The applicant must declare its position related to intellectual property rights. The declaration document must be updated as needed.

~~386 CRYPTREC 2000~~

~~8.2.3 About ISO/IEC JTC1/SC27/WG2~~

Related web address: http://www.din.de/ni/sc27/ ISO/IEC JTC1/SC27 (ISO stands for International Organization for Standardization; IEC stands for International Electrotechnical Commission; JTC1 is a committee responsible for creating an international standard for information processing related technologies, jointly set up by ISO and IEC; SC27 is an organization under JTC1) is an organization for determining international standards for overall information security technologies. Three WGs (technical working groups) are established under SC27. WG2 is working on IT security and mechanisms, and is standardizing confidentiality maintenance, entity authentication, non-repudiation, key management, and data integrity (message authentication, hash function, digital signature, etc.). ISO/IEC JTC1 goes through the following draft stages before issuing International Standards: (1) New Work Item Proposal (NP) (2) Working Draft (WD) (3) Committee Draft (CD) (4) Final CD (FCD) (5) Final Draft of IS (FDIS) (6) International Standard (IS) As part of the cryptographic algorithm standardization activities, the evaluation of 18033, which consists of the four parts listed as follows, began in October 1999, with international standardization targeted for 2003. – Part 1 General model – Part 2 Public-key cryptography – Part 3 Block cipher – Part 4 Stream cipher

~~ISO Standards Related to Symmetric Ciphers ISO# Content TITLE STATUS~~

8372 Modes of operation for a Modes of operation for a 64-bit block cipher IS 64-bit block cipher algorithm algorithm 10116 Modes of operation for an Modes of operation for an n-bit block cipher IS n-bit block cipher algorithm algorithm 9798-1 Entity authentication Entity authentication IS 9798-2 -Part 1: General -Part 2: Mechanisms using symmetric encipherment algorithms 9797-1 Message authentication Message-authentication codes (MACs) - IS codes Part 1: Mechanisms using a block cipher Part 2: Mechanisms using a hash-functions

~~387 CRYPTREC 2000~~

~~ISO# Content TITLE STATUS~~

13888-2 Non-repudiation Non-repudiation IS -Part 2: Using symmetric techniques 10118-2 Hash functions Hash-functions IS -Part 2: Hash-functions using an n-bit block cipher algorithm 11770-2 Key management Key management IS -Part 2: Mechanisms using symmetric techniques(confirmed 1999) 18033-3 Block ciphers Encryption algorithms WD being -Part 3: Block ciphers prepared 18033-4 Stream ciphers Encryption algorithms WD being -Part 4: Stream ciphers prepared

~~ISO Standards Related to Public-Key Ciphers ISO# Content TITLE STATUS~~

9796-1 Digital Digital signature schemes giving message recovery 9796-2 signature -Part 1: Not in use - 9796-3 scheme giving -Part 2: Mechanisms using a hash-function IS message -Part 3: Discrete logarithm based mechanisms IS recovery 9798-1 Entity Entity authentication IS 9798-3 authentication -Part 1: General IS -Part 3: Mechanisms using asymmetric signature techniques 11770-1 Key Key management 11770-2 management -Part 1: Framework IS 11770-3 -Part 2: Mechanisms using symmetric techniques IS -Part 3: Mechanisms using asymmetric techniques IS 13888-3 Non-repudiatio Non-repudiation IS n -Part 3: Using asymmetric techniques 14888-1 Digital Digital signatures with appendix 14888-2 signatures with -Part 1: General IS 14888-3 appendix -Part 2: Identity-based mechanisms IS -Part 3: Certificate-based mechanisms IS 15946-1 Cryptographic Cryptographic techniques on elliptic curves 15946-2 techniques on -Part 1: General FDIS 15946-3 elliptic curves -Part 2: Digital signatures FDIS 15946-4 -Part 3: Key establishment FDIS -Part 4: Digital signatures giving message recovery CD 18033-1 Public-key Encryption algorithms WD being 18033-2 encryption -Part 1: General prepared algorithm -Part 2: Asymmetric ciphers

~~388 CRYPTREC 2000~~

~~8.2.4 About IEEE~~

Related web address: http://grouper.ieee.org/groups/1363/ IEEE (Institute of Electrical and Electronics Engineers) is a "U.S. electrical and electronics engineers society" headquartered in New York. It was established in 1963 and has more than 320,000 members worldwide in 130 countries. Although IEEE is a U.S. academic society, it is one of the U.S.’s domestic standardization organizations entrusted by ANSI (American National Standards Institute) that establishes domestic standards in the U.S., and also has established various international standards. With IEEE P1363 ("Standard Specifications for Public Key Cryptography"), IEEE is trying to standardize public-key cryptographic systems in the functional classifications of key sharing, public-key cryptography, and digital signature, by targeting the schemes based on the discrete logarithm problem, elliptic curve discrete logarithm problem, and integer-factoring problem.

~~8.2.5 About IETF~~

Related web address: http://www.ietf.org/ The IETF (Integrated Engineering Task Force) is an organization that is promoting the standardization of Internet-related technologies, and its main activities include mailing lists and three off-line meetings every year. One of the eight areas - Security Area - includes working groups such as IPSec (IP Security Protocol WG), PKIX (Public-Key Infrastructure [X.509] WG), and TLS (Transport Layer Security WG), in which active discussions are taking place on the implementation of cryptographic techniques.

A basic agreement has been reached on the primitives of the S/MIME Mail Security WG. That is, DSA and RSA (PKCS#1v1.5) will be used as the signature methods; SHA-1 will be used as the hash function; RSA (PKCS#1v1.5) will be used for key management; and Triple DES will be used as the encryption method.

~~389 CRYPTREC 2000~~

Copyright (C) 2001 INFORMATION-TECHNOROGY PROMOTION AGENCY, JAPAN INFORMATION-TECHNOROGY PROMOTION AGENCY, JAPAN BUNKYO GREEN COURT CENTER OFFICE 2-28-8 HONKOMAGOME, BUNKYO-KU TOKYO, 113-6591 JAPAN TEL:+81-3-5978-7508 (IT SECURITY CENTER) FAX:+81-3-5978-7518

~~390~~