CRYPTREC Cryptographic Technique Evaluation Workshop
CRYPTREC Cryptographic Technique Evaluation Workshop
March 29, 2002
Information-Technology Promotion Agency, Japan
Telecommunications Advancement Organization of Japan
Organizer | Information-Technology Promotion Agency, Japan Telecommunications Advancement Organization of Japan |
---|---|
Date | January 28, 2002 |
Time | 13:30–21:00 |
Place | Kamitonda Bunka-kaikan (Asso, Kamitonda-machi, Nishimurou-gun, Wakayama, JAPAN) |
Attendance | Approx. 170 Participants |
Time | Program | |
---|---|---|
13:30 | Opening | |
The position of Cryptography Evaluation in e-Japan strategy Hidetoshi Ohno, Director, Office of IT Security Policy, Ministry of Economy, Trade and Industry |
![]() |
|
Representing the secretariat of the CRYPTREC Advisory Committee at the Ministry of Public Management, Home Affairs, Posts and Telecommunications and Ministry of Economy, Trade, and Industry, Mr. Ohno provided an explanation of policy on the standardization of cryptographic technique and CRYPTREC Advisory Committee activity in regards to the e-Japan Priority Policy Program and e-Government Action Plan, following presentation materials. He went on to explain that major activities of the Committee in the future are to include the compilation of cryptographic technique-use policy, to include the issue of a "guidebook for procurement" and a list of e-government recommended ciphers for each field of application. Mr. Ohno also indicated that the Agency was working toward agreement on these issues among the various ministries and agencies within the time frame of the end of next year. |
||
The CRYPTREC Evaluation Hideki Imai, Chair, CRYPTREC Evaluation Committee, Professor, The University of Tokyo |
![]() |
|
Professor Imai, Chair of the CRYPTREC Evaluation Committee and CRYPTREC Advisory Committee, provided an overview of CRYPTREC's work and its evaluation system. He also indicated that approaches to possible cryptographic techniques for use in e-government and promotion of cryptography evaluation, plus the scope of cryptographic evaluation for this year, would be covered at the April 16th presentations. |
||
14:00 | Session 1: Presentations of Evaluation Status about Symmetric-Key Cryptography Technique | |
Presentation of Evaluation Status about Symmetric-Key Cryptography Technique Toshinobu Kaneko, Chair, Symmetric-Key Cryptography Subcommittee, Professor, Science University of Tokyo |
![]() |
|
Professor Kaneko, Chair of the CRYPTREC Symmetric-Key Subcommittee, presented on evaluation policy and the current state of evaluation methods for symmetric-key cryptographic technique. | ||
Presentation of Evaluation Status about Screening Evaluation | ||
MUGI Koichi Sakurai, Member, Symmetric-Key Cryptography Subcommittee |
||
Question by audience: Item (1)-1 on the fifth page of the general evaluation commentson the presentation slides states "...these two ciphers need to be compared...". What does "these two ciphers" refer to? Answer by presenter: The committee was unable to determine which comparison with MULTI-S01 or with PANAMA was appropriate. |
||
TAO TIME Cognition Algorithm Kazuo Takaragi, Member, Symmetric-Key Cryptography Subcommittee |
||
Question by audience: What is the evaluation basis for Evaluator 3's statement that "there is a problem with security"? Answer by presenter: There were unclear aspects to the formula, so it was not possible to evaluate the cognition algorithm. The random numbers used in the algorithm do not directly enable the function expected by CRYPTREC. Question by audience: "a" is simply part of a random number for generating a seed. Why were "s" and "c" not evaluated? Answer by presenter: This is not a call for cognition systems, but rather a call for pseudo-random number generator. Please understand that this evaluation was made with the utmost in good will. |
||
Presentation of Evaluation Status about Detail Evaluation | ||
CIPHERUNICORN-E Toshio Tokita, Member, Symmetric-Key Cryptography Subcommittee |
||
Question by audience: Why are the calculated results of Evaluators 1 through 4 slightly different from each other? Answer by presenter: Because the techniques used to estimate the values are different. |
||
CIPHERUNICORN-A Masayuki Kanda, Member, Symmetric-Key Cryptography Subcommittee |
||
Comment by proposer: In the rump session we plan to disclose the results of a slightly more stringent evaluation of portions that were omitted from the evaluation at the time of the proposal. |
||
MULTI-S01 Takeshi Shimoyama, Yukiyasu Tsunoo, Kiyomichi Araki, Member, Symmetric-Key Cryptography Subcommittee |
||
Comment by audience: We would like to make a disclosure of detailed values, such as for the set parameters, in the PANAMA SP 800-22 evaluation. |
||
15:30 | Break | |
15:45 | Session 2: Presentations of Evaluation Status about Public-Key Cryptographic Technique | |
Presentation of Evaluation Status about Public-Key Cryptographic Technique Tsutomu Matsumoto, Chair, Public-Key Cryptography Subcommittee, Professor, Yokohama National University |
![]() |
|
Professor Matsumoto, Chair of the Public-Key Subcommittee, presented on evaluation policy and the current state of evaluation methods for public-key cryptographic technique. | ||
Presentation of Evaluation Status about Screening Evaluation | ||
HIME(R) (High Performance Modular Squaring Based Public Key Encryption <Revised version>) Seigo Arita, Member, Public-Key Cryptography Subcommittee |
||
No particular questions or answers. | ||
NTRU public key cryptosystem Jun Kogure, Member, Public-Key Cryptography Subcommittee |
||
No particular questions or answers. | ||
OK-ECDSA/OK-ECDH Atsushi Shimbo, Member, Public-Key Cryptography Subcommittee |
||
Question by audience: Who does the order calculations? Answer by presenter: Depending on the method of use, it is expected that reliable institutions or individuals would do this. Question by audience: What is the meaning of the evaluation stating that the ability to withstand side-channel attacks is quantitatively poor? Answer by presenter: This was an external evaluation comment meaning there are no implementation comparison results providing a comparison against other techniques. |
||
PSEC-KEM Key agreement Natsume Matsuzaki, Member, Public-Key Cryptography Subcommittee |
||
Comment by proposer in response to the evaluation that the parameter values and conditions were missing: On page 20 of the specifications it states that the elliptic curve parameter is selected from SECG, and a base point of 160 bits or more is used. This is not a detailed explanation, but at least that much was written in the specifications. As a proposer, our policy is that this should not be described in detail. Comment by proposer regarding the evaluation that the hLen condition needs revision: PSEC-KEM and PSEC-2 have different algorithms of using hLen symbols (in order to be compatible with ISO). With PSEC-KEM, the hLen problems in PSEC-2 are solved. Answer by the committee in response to this comment: They would like the proposer to create a symbol correspondence table. Comment by proposer regarding the evaluation that the cryptosystem types (key exchange and key encapsulation) are unclear in terms of consistency and correspondence: The specifications state that key encapsulation can be used for key agreement. |
||
16:40 | Break | |
16:55 | Presentation of Evaluation Status about Detail Evaluation | |
EPOC-2 Hajime Watanabe, Member, Public-Key Cryptography Subcommittee |
||
Comment by proposer: In the rump session I will comment on the critique stating that the primitives used have different parameter conditions from the original function presented at Eurocrypt '98. |
||
ESIGN Yasuyuki Sakai, Member, Public-Key Cryptography Subcommittee |
||
Comment by committee: An external reviewer may have made a new discovery, so we are engaged in intensive verification. | ||
RSA Public-Key Cryptosystem with Probabilistic Signature Scheme (RSA-PSS) RSA Public-Key Cryptosystem with Optimal Asymmetric Encryption Padding (RSA-OAEP) RSASSA-PKCS-v1_5 Kazuo Ohta, Member, Public-Key Cryptography Subcommittee |
||
Comment by audience: Does the textbook RSA use the hash function or not? Comment by committee: This is a subtle issue, such as the hash function containing full-domain hash. This matter has not been clarified. In addition, the hash value is small in size and limited. Comment by audience: A comparison of OAEP+ and OAEP, etc. in terms of reduction efficiency will be presented at SCIS2002. In addition, regarding the transition from PKCS#1 v1.5 to PSS, the situation is the same for ESIGN. |
||
Digital Signature Algorithm Seiichi Suzaki, Member, Public-Key Cryptography Subcommittee |
||
No particular questions or answers. | ||
ECDSA (Elliptic Curve Digital Signature Algorithm) in SEC1 Atsushi Shimbo, Member, Public-Key Cryptography Subcommittee |
||
No particular questions or answers. | ||
18:25 | Break | |
18:55 | Method for Achieving Enhanced Freedom with the Digital Signature Shigeo Tsujii, Adviser, CRYPTREC Evaluation Committee, Professor, Chuo University |
![]() |
An ideal explanation was provided for understanding an electronic form system using cryptography easily, which will be increasingly important going forward in e-government. | ||
19:10 | Rump Session | |
Differential and Linear cryptanalysis of CIPHERUNICORN-A Yukiyasu Tsunoo, Hiroyasu Kubo |
||
Presentation overview Under the title "Differential and Linear cryptanalysis of CIPHERUNICORN-A", it was explained that an additional self-evaluation was done regarding differential and linear characteristics probabilities. In both cases, the results were below 2-128. |
||
Overview of questions and answers Comment by committee: There is a possibility that the committee will request documents. We want you to prove that 3-round elimination attacks cannot be used. Question by audience: Modifications were made with respect to the multiplication evaluation, but what is the status of the evaluation of the A3 function? Answer by presenter: The same as before. |
||
Unique methods to generate PRN in TAO TIME Cognition Algorithm Akira Sugiyama |
||
Presentation overview Under the title "Unique methods to generate PRN in TAO TIME Cognition Algorithm", an explanation covering the following was provided: We would like the evaluation to be redone, with the pseudo-random numbers in TAO TIME set as C(n), S(n-1). With respect to the TAO TIME evaluation, we would like you to explain the statement that "there are problems with security as well." |
||
Overview of questions and answers Comment by committee: Based on the submitted documents, the cognition system is outside the scope of CRYPTREC evaluations. The proposal was made as a pseudo-random number generator, so we evaluated only the algorithm for generating random numbers and judged that it is not secure. Comment by committee: If the recurrence relation is solved and any term is determined, then it is possible to forge the authentication data for the next time using the value from three times before. If the cognition algorithm is treated as an authentication system, then it does not seem to have sufficient security. |
||
Latest Information of MUGI Soichi Furuya |
Presentation overview Under the title "Latest Information of MUGI", an explanation of the errors in the MUGI specification document was provided. In addition, it was explained that the test vector mismatches were editorial errors. Unlike MULTI-S01, this is an ordinary stream cipher (MULTI-S01 includes MAC). In addition, it was explained that MUGI is a modification of PANAMA in the following respects: 1. Small gates (18 Kgates) 2. Initialization is "lighter" than PANAMA 3. "Over-spec" portions of PANAMA are deleted. |
|
Overview of questions and answers Explanation by committee: This presentation is not an algorithm change; it is merely a disclosure of errors in the specification document. It is not accepted as a revision to the documents submitted to CRYPTREC. In addition, there is a possibility that revision documents will be requested at the discretion of the committee. Comment by audience: Regarding the small gates, which is a modification, 650 Mbps @ 18 Kgates is hardly small. AES has achieved 310 Mbps @ 5.4 Kgates, and 2.6 Gbps @ 21 Kgates. Question by audience: Is the PANAMA in MULTI-S01 ever be replaced by MUGI? Answer by presenter: The issue is one of design policy; PANAMA is never simply replaced by MUGI. |
||
Latest Information of MULTI-S01 Soichi Furuya |
||
Presentation overview Under the title "Latest Information of MULTI-S01", the following explanation was provided in response to the critique that the Vernam cipher plus MAC would be OK: S01 is superior in the following respects: 1. Security 2. Usability |
||
Overview of questions and answers Question by audience: How does MULTI-S01 without MAC compare against MUGI? Answer by presenter: This is simply a stream cipher that uses PANAMA. The claim can be made that it is superior to MUGI in HW/SW implementations. Comment by committee: With respect to requests to submit such comparative reports, we would like to proceed after considering an arrangement that would provide a fair opportunity for all proposers. |
||
EPOC-2: Relationship between CRYPTREC'01 submission version and provable security in ROM Eiichiro Fujisaki |
||
Presentation overview Under the title: "EPOC-2: Relationship between CRYPTREC'01 submission version and provable security in ROM", the revised version of the proposed technique was explained. The method for selecting h was changed to h = gn (mod n). (Same as Eurocrypt '98 and NESSIE '01) There is also a revised plan for the r range (hLen), but there are no changes. |
||
Overview of questions and answers Question by audience: Are there any security problems with randomly selecting a public parameter h? Answer by presenter: It is not that there is any particular attack method. Rather, the meaning is that even if a random selection is made, the parameter h order should be made sufficiently large. However, the precise behavior is related to the modulus n factors p and q. Comment by audience: Even if the specifications are not changed, shouldn't you do an order analysis of parameter h using the modulus n factors (p, q), and then provide a secure parameter selection? |
||
Correction of a test vector generation program of Camellia Mitsuru Matsui |
||
Presentation overview Under the title "Correction of a test vector generation program of Camellia", it was explained that the test vector generation program contained a bug. |
||
Overview of questions and answers No particular questions or answers. |
||
NTRUSign: Digital Signature using the NTRU Latice William White |
||
Presentation overview An explanation was provided under the title "NTRUSign: Digital Signature using the NTRU Latice." |
||
Overview of questions and answers Question by committee: Are the NTRU cipher and NTRU signature based on the difficulty for the same lattice? Answer by presenter: They are based on the difficulty for the same lattice. Question by committee: About the draft of the NTRU provable security. Answer by presenter: This has not yet been disclosed at the present time. |
||
Key points for ASIC implementation of 128-bit block ciphers (+KASUMI) Akashi Sato |
||
Presentation overview Under the title "Key points for ASIC implementation of 128-bit block ciphers (+KASUMI)", an explanation was provided regarding the points of the HW implementation evaluation for the 128-bit block ciphers and 64-bit block cipher MISTY/KASUMI submitted to CRYPTREC. |
||
Overview of questions and answers Comment by audience: At SCIS2002 we plan to make a presentation on implementation pertaining to SC2000. |
||
21:00 | Program concludes |