Guidance for Submissions(104
Guidance for Submissions in 2001 (Provisional Translation)
Information-technology Promotion Agency, Japan
Telecommunications Advancement Organization of Japan
August 1, 2001
Contents
1. Objective ...... 1
2. Outline and schedule ...... 2
2.1 Outline of the project ...... 2
2.2 Schedule ...... 2
3. The Categories of Solicited Cryptographic Technique ...... 3
3.1 Follow-up evaluation candidate and newly submitted technique ...... 3
3.2 Classification of cryptographic technologies ...... 4
4. Evaluation Items ...... 6
4.1 Asymmetric Cryptographic Schemes ...... 6
4.2 Symmetric Ciphers ...... 7
4.3 Hash Functions ...... 8
4.4 Pseudo-Random Number Generators ...... 8
5. Documents for Submission ...... 9
6. Remarks ...... 18
7. How to make the submission ...... 19
Reference ...... 20
Appendix A Application Form ...... 24
Appendix B Information on the public availability status of specification .... 25
Appendix C Self checklist ...... 26
Guidance for Submissions (Provisional translation)
August 1, 2001 Information-technology Promotion Agency, Japan(IPA) Telecommunications Advancement Organization of Japan(TAO)
1. Objective
The Japanese government aims at joining in the most advanced IT nations in the world within the next 5 years as a consequence of executing e-Japan Strategy. We have to ensure the security and reliability of the advanced info-communications networks in Japan for realization of our target. In particular, unbiased evaluation and standardization of cryptographic techniques are required as a basic item for the spread of digital authentication schemes like digital signatures and consequently for the construction of the electronic government, which is the governmental execution of e-Japan Strategy. For this reason, following the last year project, we call for submitting cryptographic techniques, scrutinize the submitted cryptographic techniques, evaluate their security and performance and publicize the results as the CRYPTREC report 2001. The CRYPTREC report 2001 is supposed to be employed by Japanese government in many ways for their selection of cryptographic techniques used for constructing the electronic government.
1/27 2. Outline and schedule
2.1 Outline of the project
(1) Requested by the CRYPTREC Advisory Committee, which is held by the ministry of public management, home affairs, posts and telecommunications and the ministry of economy, trade and industry, the secretariat of the CRYPTREC project consisting of TAO and IPA organizes the CRYPTREC Evaluation Committee consisting of experts in cryptology and evaluate the submitted cryptographic techniques.
(2) Some of the cryptographic techniques that were evaluated last year and judged to deserve further evaluation will be advanced to the full evaluation phase this year. Newly submitted cryptographic techniques in 2001 will be a subject of the screening evaluation. Only cryptographic techniques that pass the screening evaluation will advance to the full evaluation phase executed after April of 2002.
(3) We evaluate security and software and hardware implementation of the submitted cryptographic techniques referring the existing academic literature in cryptology and investigation carried out by the experts nominated by the CRYPTREC Evaluation Committee. The results will be publicized even though these may disadvantage some applicants.
(4) Besides evaluation of the submitted cryptographic techniques, the activity of CRYPTREC in this year contains the investigation of the cryptographic techniques that are judged to deserve evaluation by the CRYPTREC evaluation committee. No public submission is solicited for this special evaluation.
2.2 Schedule The tentative schedule is set as follows. - Deadline for submissions: September 27, 2001 17:00 (Japan Standard Time) *A submission should be received by the CRYPTREC secretariat before September 27, 17:00 (JST). Only a postal mail or parcel delivery will be accepted. - Screening evaluation and follow-up evaluation: October, 2001 ～ March, 2002 - CRYPTREC submission explanation meeting: October 9 and 10, 2001 9th of October: Symmetric key cryptographic techniques 10th of October: Asymmetric key cryptographic techniques *This will be open to the public. All applicants shall present their submissions. - CRYPTREC workshop: January 2002 - Publication of CRYPTREC Report 2001: March 2002
2/27 3. The Categories of Solicited Cryptographic Techniques
3.1 Follow-up evaluation candidate and newly submitted technique Any submitted cryptographic technique shall be supplied by the applicant or another developer not later than March 2003 for construction of the electronic government. The evaluation policy will be announced and the evaluation will be carried out based on the policy. The results will be publicized.
(1) Remarks on new submissions i) The specification and other information on the submitted cryptographic techniques shall be disclosed to the public by the deadline for the submission (September/27). Please inform the secretariat of any obstacle to make the submission public by the 10th of September if any. ii) A submission shall be a cryptographic technique that can be implemented by third parties in and out of Japan. In addition, the submission should be restricted to the one whose specification and information is public and possible to be evaluated. iii) The submitted cryptographic technique should possess certain features (for security or performance) that make itself superior or equal to the existing cryptographic techniques fully evaluated for CRYPTREC project in the year 2000*. *Refer to “CRYPTREC report 2000” given in http://www.ipa.go.jp/security/enc/CRYPTREC/index.html iv) Only one cryptographic technique shall be submitted for one category. If you submit more than one technique belonging to one category, those techniques should be designed using distinct principles. Moreover, if a submission has more than one function in several categories of the classification described in Section 3.2, the applicant is asked to choose one category that is most appropriate to the submission for the submission. v) Newly submitted cryptographic techniques in 2001 will be in the screening evaluation phase this year. Only cryptographic techniques that pass screening evaluation phase will advance to the full evaluation phase executed after April of 2002.
(2) Remarks on follow-up evaluation i) The subjects of the full evaluation this year will be the cryptographic techniques which were fully evaluated in 2000 and the CRYPTREC evaluation committee judged to deserve further evaluation*. Moreover, the applicant should express their will to continue follow-up evaluation process, and the status of availability should be clarified. *The CRYPTREC evaluation committee will notice to each applicant that the submission will be advanced to the follow-up evaluation. ii) The applicant of the subject of the follow-up evaluation is asked to give in the
3/27 materials described in Section 5. iii) The CRYPTREC evaluation committee may regard a submission as new if the specifications are substantially updated (change of parameters, algorithms, auxiliary functions and so on).
3.2 Classification of cryptographic technologies A submitted cryptographic technique shall belong to one of the categories. (1) Asymmetric Cryptographic Schemes We solicit asymmetric cryptographic schemes possessing one of the following objectives; confidentiality, authentication, signature, and key agreement. A scheme shall have at least one software implementation. An asymmetric cryptographic scheme here means a synthetic algorithm consisting of a cryptographic primitive and several auxiliary functions. Requirements of the cryptographic primitives, the auxiliary functions and the description of the comprehensive algorithm are required to be presented. A cryptographic primitive is a mathematical assumption that a submitted cryptographic technique is based on. For example, a primitive may be an algorithmic problem related to the integer factoring problem, the discrete logarithm problem of the multiplicative group of finite fields or the group of rational points on an elliptic curve, or another intractable problem. An auxiliary function is a necessary element to construct a scheme such as a hash function or a pseudorandom number generator. If a submission employs a novel hash function or pseudorandom number generator, such primitives should be submitted to the corresponding category as well. If a submission attains more than one objective in several categories of the classification described below, the applicant is asked to choose one category that is most appropriate to the submission. For instance, an authentication scheme based on a signature scheme should be submitted to signature category and not submit to authentication category. Instead of submitting to all categories, the applicant is asked to choose only one category and to present all functions that the submission possesses. Auxiliary functions should be specified concretely. An applicant’s criterion for selecting parameters and recommended parameters should be specific as well.
(2) Symmetric ciphers The following symmetric ciphers are solicited: a) 64-bit block ciphers(key length : 128 bits or longer) b) 128-bit block ciphers(key length : 128 bits or longer) c) Stream ciphers (initial value space : 128 bits or longer, number of states：128 bits or
4/27 more)
(3) Hash Functions Hash functions of 160-bit or longer hash values are solicited. They are supposed to be employed as primitives for constructing asymmetric cryptographic schemes.
(4) Pseudo-Random Number Generators We solicit pseudo-random number generation algorithms that are employed for asymmetric cryptographic schemes or appropriate to generating session keys in symmetric ciphers. The specification of seeds for random numbers should be clearly presented.
5/27 4. Evaluation Items
4.1 Asymmetric Cryptographic Schemes
(1) Security Evaluation Items The submitted cryptographic scheme, which has at least one of the following functions, confidentiality, authentication, signature, and key agreement, will be comprehensively evaluated on the assumption that the cryptographic primitives and auxiliary functions satisfy the specified requirements. The cryptographic primitives and auxiliary functions used in the implementation will be evaluated whether or not they are appropriate for the specified requirements. (a) Evaluation items on schemes The behavior of the cryptographic scheme will be evaluated under numerous attack models and methods. We will examine the argument for provable security if it is claimed, otherwise we investigate whether or not the submitted scheme has sufficient security for the electronic government. (b) Evaluation items on primitive i) Integer factoring problem Resistance against well-known attacks (such as rho method, p-1 method, p+1 method, quadratic sieve method, number field sieve method, elliptic curve method), and other attacks particular to the primitive. ii) Discrete logarithm problem on the multiplicative group of finite fields Resistance against well-known attacks (such as Pohlig-Hellman algorithm, Baby-Step-Giant-Step algorithm, Pollard’s rho method, lambda method, index calculus method), and other attacks particular to the primitive. iii) Discrete logarithm problem on the group of rational points on elliptic curves Resistance against well-known attacks (such as Pohlig-Hellman algorithm, Baby-Step-Giant-Step algorithm, Pollard’s rho method, lambda method, Frey-Ruck algorithm, Semaev-Smart-Satoh-Araki algorithm, Algorithm using Weil Descent), and other attacks particular to the primitive. iv) Other algorithmically intractable problem Resistance against well-known attacks and other attacks particular to the primitive.
(2) Evaluation Items on Implementation The evaluation will be carried out from the following standpoint. i) Cryptographic Technique Specifications provides sufficient information so that any third party can implement it.
6/27 ii) An extremely special hardware or a huge amount of storage should not be required for implementation. iii) We consider special conditions when the scheme is applied to practical systems. For example, the scheme may require a trusted authority and so on. iv) The size of data block of the submitted scheme or primitive will be evaluated. Also if the proposed scheme requires interactions (data exchanges) between two or more parties, the number of data exchanges will be evaluated.
4.2 Symmetric Ciphers
(1) Security Evaluation Items (a) Evaluation Items on Block Ciphers We will evaluate the submitted block cipher’s resistance against well-known attacks, such as linear cryptanalysis, differential cryptanalysis (see [B3],[B7]), and resistance against other attacks (such as algebraic attacks, derivatives of differential attack). Moreover, we may evaluate the resistance of the submitted block cipher against other attacks, and also discuss heuristically analyzed security. Refer to the papers [B1]-[B18]. (b) Evaluation Items on Stream Ciphers The submitted stream cipher will be evaluated based on the statistical properties including the length of period and linear complexity. We will also evaluate the resistance against well-known attacks, such as correlation attack, divide-and-conquer attack (refer to [S1]). Moreover, we may evaluate the resistance of the proposed stream cipher against other attacks and heuristically analyzed security. Refer to the papers [S1]-[S18]. (2) Evaluation Items on Implementation (a) Evaluation on software implementation The evaluation will be carried out from the following standpoint. i) We will measure speed, memory usage (code size, work area, etc), and so on. ii) We will measure speed of the key scheduling for the block cipher. (b) Evaluation items on hardware implementation We will evaluate the process used (Field Programmable Gate-Array, gate array), speed evaluation, resource use quantity (amount of use cell in the case of Field Programmable Gate-Array, the number of gates in case of the gate array etc,) and so on. Note: We may only carry out simulation evaluation and regard the results as the evaluation of the processing speed and resource consumption.
7/27 4.3 Hash Functions
(1) Security Evaluation Items We will check that the submitted technique is one-way, collision free in practical time, and investigate the resistance against well-known attacks, such as differential cryptanalysis and algebraic attacks. Moreover, we may examine the statistical properties, the resistance against other attacks reported in the papers [H1]-[H8], and discuss heuristically analyzed security.
(2) Evaluation Items on Implementation (a) Evaluation on software implementation We will measure speed, memory usage (code size, work area, etc). (b) Evaluation items on hardware implementation We will evaluate the process used (Field Programmable Gate-Array, gate array), speed evaluation, resource consumption (amount of cells used in the case of Field Programmable Gate-Array, the number of gates in case of the gate array etc,) and so on. Note: We may only carry out simulation evaluation and regard the results as the evaluation of the processing speed and resource consumption
4.4 Pseudo-Random Number Generators
(1) Security Evaluation Items Our evaluation views are statistical properties with randomness tests such as the Monobit Test, the Poker Test, the Runs Test (0-1 balancedness, frequency test) and the Long Run Test as referred in FIPS140-1. We may also evaluate the resistance against other attacks (refer to [R1]-[R25]), unpredictability and heuristically analyzed security.
(2)Evaluation on Software Implementation We will measure speed, memory usage (code size, work area, etc), and so on.
8/27 5. Documents for Submission The following documents are required to submit. An applicant is asked to make sure that all following materials are sent to the secretariat. The contents of the submitted documents may be released to third parties as of the date of submission.
List of Documents for Submission Refer 1. Language No Documents Format file name or directory name ence 2. Medium page 1. Japanese and English Application form 01japp.(pdf/doc/ps) for Japanese (1) 2. Document and 11 in 2001 Appendix A 01eapp.(pdf/doc/ps) for English electronic medium 1. Japanese and English Specifications in No specific 01jspec.(pdf/doc/ps) for Japanese 2. Document and 2001 format 01espec.(pdf/doc/ps) for English electronic medium Difference 1. Japanese and English No specific 01jspdif.(pdf/doc/ps) for Japanese (2) between 2. Document and 12 format 01espdif.(pdf/doc/ps) for English Specifications* electronic medium 1. Japanese and English Specifications in No specific 00jspec.(pdf/doc/ps) for Japanese 2. Document and 2000* format 00espec.(pdf/doc/ps) for English electronic medium 1. Japanese and English Self Evaluation No specific 01jeval.(pdf/doc/ps) for Japanese 2. Document and Report in 2001 format 01eeval.(pdf/doc/ps) for English electronic medium (3) Difference 13 1. Japanese and English between Self No specific 01jevldif.(pdf/doc/ps) for Japanese 2. Document and Evaluation format 01eevldif.(pdf/doc/ps) for English electronic medium Report* 2. Electronic medium No specific (4) Test vector tvect (directory) 15 only format 1. English No specific Reference program ref (directory) 2. Electronic medium format 1. Japanese and English 01jref.(txt/pdf/doc/ps) for Specifications of No specific 2. Document and Japanese reference code format electronic medium 01eref.(txt/pdf/doc/ps) for English Test vector (5) 1. English No specific 15 generating tp (directory) 2. electronic medium format program Specifications of 01jtvect.(txt/pdf/doc/ps) for 1. Japanese and English test vector No specific Japanese 2. Document and generating format 01etvect.(txt/pdf/doc/ps) for electronic medium program English publication 1. Japanese and English 01jpub.(pdf/doc/ps) for Japanese (6) status of 2. Document and Appendix B 16 01epub.(pdf/doc/ps) for English specification electronic medium Presentation file for 1. Japanese and English CRYPTREC No specific 01jbrf.ppt for Japanese (7) 2. Document and 17 submission format 01ebrf.ppt for English electronic medium explanation meeting 1. Japanese and English (8) Self-checklist 2. Document and Appendix C 01chk.(pdf/doc/ps) for Japanese 17 electronic medium
9/27 Directory tree for documents for submission
tvect Test vector( complete set：text format ) Reference program( complete set : text format ) ref 01jref.(txt/pdf/doc/ps) - - - - Specifications (jp)
01eref.(txt/pdf/doc/ps) - - - - Specifications (en)
tp Test Vector Generating Program( complete set : text format) 01jtvect.(txt/pdf/doc/ps) - - - - Specifications (jp) 01etvect.(txt/pdf/doc/ps) - - - - Specifications (en) 01japp.(pdf/doc/ps) - - - - Application form in 2001 (jp) 01eapp.(pdf/doc/ps) - - - - Application form in 2001 (en) 01jspec.(pdf/doc/ps) - - - - Specifications in 2001 (jp)
01espec.(pdf/doc/ps) - - - - Specifications in 2001 (en) 00jspec.(pdf/doc/ps) - - - - Specifications in 2000 (jp) 00espec.(pdf/doc/ps) - - - - Specifications in 2000 (en) 01jspdif.(pdf/doc/ps) - - - - Difference between Specifications (jp) 01espdif.(pdf/doc/ps) - - - - Difference between Specifications (en) 01jeval.(pdf/doc/ps) - - - - Self Evaluation Report (jp) 01eeval.(pdf/doc/ps) - - - - Self Evaluation Report (en) 01jevldif.(pdf/doc/ps) - - - - Difference between Self Evaluation Report (jp) 01eevldif.(pdf/doc/ps) - - - - Difference between Self Evaluation Report (en)
01jpub.(pdf/doc/ps) - - - - Information on the public availability (jp) 01epub.(pdf/doc/ps) - - - - Information on the public availability (en) 01jbrf.ppt - - - - Presentation file for CRYPTREC submission explanation meeting (jp) 01ebrf.ppt - - - - Presentation file for CRYPTREC submission explanation meeting (en) 01chk.(pdf/doc/ps) - - - - Self-checklist i) Use the filename for documents given above ii) For test vectors, test vector generating program, reference code, make the directory structure and put files shown above. iii) Except for ii), all files are put in the root directory. - Use the A4 size paper. - For electronic data (1)-(3), (6) and (8), file format should be Adobe PDF, Adobe PostScript or Microsoft Word. - For electronic data (4)-(5), file format should be text file. - For electronic data (7) should be made by Microsoft PowerPoint. - The details of file format are as follows. Adobe PDF: Japanese - - - - Adobe Acrobat 4.0 + Japanese font set : English ------Adobe Acrobat 4.0 Adobe PostScript: Japanese - - - - PostScript whose level is equal or less than12 (17 or less English fonts, 2 or less Japanese fonts) : English ------PostScript whose level is equal or less than12 (17 or less English fonts) 10/27 Microsoft Word: Japanese - - - - File format should be read by Microsoft Word 97. : English - - - - File format should be read by Microsoft Word 97. *) For example, save the file for Word 97 formula by Word 2000.
Submit files (1)-(3) and (6)-(7) in both Japanese and English. We mainly use documents in Japanese language for our evaluation purpose. Documents in English will be auxiliary. Thus, the priority is given to Japanese papers, if a different between them is found. Use CD-R, CD-RW or MO as the media for submission. Please attach a label and write the name of applicant and cryptographic technique.
(1) Application Form (Appendix A) Following Appendix A, give in the name of the submitted cryptographic technique, the name of the applicant and the name of the developer and so on. i) Date of submission Give in the date of the submission. ii) Name of the submitted cryptographic technique Give in the official name. If the official name is long, give an abbreviation consisting about 5 letters. iii) URL giving information on submitted cryptographic technique Give in the URL where the specifications and related information of the submitted cryptographic technique can be obtained. iv) Category Select only one category appropriate to the submission. v) Applicant in charge An applicant in charge takes the responsibility of the submission. Give in the name, affiliation [Institution/Agency/Company], and the title of the applicant in charge. vi) Contact person The contact person will correspond with the secretariat of the CRYPTREC. He or she should be fluent in Japanese language (not only written language skill, but oral communication skill is required). Give in the name, affiliation [Institution/Agency/Company], the title, address, telephone number, fax number and e-mail address of the contact person. vii) Developer Give in the name of the person (or the name of the company) of the developer. viii) Contact person for supply We require that the applicant make the submitted cryptographic technique available for supply by March/2003. A contact person for supply will be corresponded with Japanese government for the matter of supplying the submitted technique if
11/27 necessary. Give in the name, affiliation [Institution/Agency/Company], the title, address, telephone number, fax number and e-mail address of the contact person for supply. Even though the cryptographic technique is not supplied at the moment of the submission, the applicant should set a temporary contact person for supply and give his or her name. ix) CRYPTREC submission explanation meeting Give in the number of attendants and the name of the speaker for CRYPTREC submission explanation meeting, which will be held in 9th and 10th of October.
(2) Specifications In the case that the submitted cryptographic technique is a subject of the follow-up evaluation as of 2000, the applicant is asked to give in an updated documents for submission explicitly mentioning renewal information (new security evaluation in the recent literature or improvement of performance and so on) in addition to the documents submitted in 2000. (a) Design policy i) Describe the design policy and criterion of the submitted cryptographic technique. ii) If the cryptographic technique is submitted to CRYPTREC for the first time, describe special features (security or performance) that make the submitted technique superior or equal to the cryptographic technique fully evaluated in 2000 for CRYPTREC project. (b) Algorithm of cryptographic technique (sufficient information to implement the algorithm) The information provided should be complete so that any third party can completely implement the submitted cryptographic techniques and fully evaluate it. Unless sufficient information is provided, the submission will not be considered. Follow the instructions below. i) Describe a complete specification for the submitted cryptographic technique. Provide necessary information (mathematical equations, tables, algorithm logic, charts and parameters) to implement the algorithm. ii) Give in the parameter selection criterion and recommended parameters if the parameters of keys or security parameters need to be specified by users. iii) Describe auxiliary functions to construct a cryptographic scheme. If a novel hash function or a pseudo random number generator is employed in the submitted cryptographic technique, the applicant is asked to apply for the corresponding category as well. iv) If the submitted symmetric cipher supports multiple key lengths, specify whether or not it provides compatibility between functions corresponding to
12/27 different key lengths. v) Describe input and output for the submitted cryptographic technique in bit-oriented manner. vi) Describe the transformation algorithm for input and output if the representation of group elements like Z/nZ is not uniquely determined when realizing the submitted cryptographic technique as a software implementation. vii) Describe the endian type. viii) Describe the optimized implementation method if any. ix) Explanation of implementation method Provide necessary information to implement the submitted cryptographic technique. Unless sufficient information is provided, the submission will not be considered. We may request an applicant to provide additional information if necessary. (c) Version information If a cryptographic technique under a similar name of the submission to CRYPTREC was submitted to any other organization, enumerate all such cryptographic techniques and give reference. (If the technique was submitted to ISO/IEC or NESSIE, indicate clearly. Give in the object ID if any.) Clarify the difference among distinct versions. In the case that distinct parameters are specified to distinct versions, explain the reason that the parameters were altered. Moreover, explain the design policy, security, ease of implementation for each version. Describe the compatibility among distinct versions and the plausible user’s disadvantage cased by the existence of more than one version. (d) Application systems Inform all systems to which the technique was applied. It is advisable to attach brochure or so.
(3) Self Evaluation Report Describe self-evaluation information on the submitted cryptographic technique. In particular, explain the items (c) and (d) in detail. Unless sufficient information is provided, the submission will not be considered. Moreover, for a follow-up evaluation technique, write clearly the difference (updated evaluation, newly developed implementation, and so on) from the last year submission in the Self Evaluation Report. (a) Design policy Describe any distinction or superiority to other existing well-known cryptographic techniques in the same category. Explain why the submission is appropriate for the electronic government in Japan. (b) Mathematical assumptions and theoretical background
13/27 Describe mathematical assumptions and theoretical background on which the submission is based. (c) Security evaluation Explain the basis on which the security of the submission is based. Provide concrete countermeasures against plausible. For attacks, we refer to Evaluation Item in Section 4. It is not necessary to explain the resistance against all attacks given in Evaluation Items in Section 4. In the case that an attack is not appropriate for the submission, no evaluation is required for such an inappropriate attack, however, clearly state and explain why the attack is not appropriate for the submitted cryptographic technique. If no self-evaluation is provided, the submitted cryptographic technique will not be considered. If the submitted cryptographic technique can be mounted by a specific attack, describe countermeasures against such an attack if any. If an attack is reported or pointed out officially or unofficially in any journal article or academic meeting like ASIACRYPT, CRYPTO, EUROCRYPT, FSE, ISEC, PKC, SCIS, refer to the paper and provide a technical commentary and submitter’s opinion on them. For asymmetric cryptographic schemes, if any provable security is claimed, clearly state the level of provable security, discuss the argument and provide the related reference. (d) Evaluation on software implementation Describe performance of speed, memory usage (code size, work area, etc), description language, platform used, and so on. Describe the method in detail, if the speed is actually measured. Note: the measurement of speed for individual key schedule is required for a submission of a block cipher. (e) Evaluation on hardware implementation Describe the process used (Field Programmable Gate-Array, gate array), speed evaluation, design environment, resource consumption (amount of cells used in the case of Field Programmable Gate-Array, the number of gates in case of the gate array etc,) and so on. Simulation evaluation results are acceptable as information on the processing speed and resource consumption. * This item is not asked for submission of asymmetric cryptographic schemes. (f) Third party’s evaluation results If a third part already evaluated the submission, provide the evaluation report. Attach the copy of the report. (Electronic form is preferable.)
14/27 (4) Test Vectors Provide sufficient number of test. If the number of the submitted test vectors is not enough, the submitted cryptographic technique will not be considered. Submit the two kinds of test vectors. One is intermediate values in the computation of cryptographic techniques, and the other is input-output pairs of the cryptographic technique which is considered as a “black box.” Both test vectors should be generated to plain text, and represented by ASCII. Use the new line code for MS-DOS (CR+LF). The intermediate values consists of at least one input-output pair, and it should be useful for debugging when a third party implements the submission technique. For asymmetric cryptographic schemes, describe the input-output values of auxiliary functions and modular exponentiation, and for symmetric ciphers, describe input-output values of iteration function, for examples. Follow the policy below for the description of the input-output pairs of cryptographic techniques. Appropriate test vectors should be chosen. For example, test vectors include the value that detects the mistakes of endian interpretation. (a) Asymmetric Cryptographic Schemes Number of key pairs: at least 3 Number of processing samples: at least 3 for each key pair Provide both test vectors randomly generated and test vectors satisfying the boundary condition satisfied if the submission contains mathematical structure, say modular exponentiation. (b) Symmetric Ciphers i) Stream ciphers Number of keys: at least 10 Number of processing samples: at least 8192 bits for each key ii) Block ciphers Number of keys: at least 10 Number of processing samples: at least 128 blocks for each key (c) Hash Functions At least 10 hash values for input sizes: 0, 512, 1024, 2048, 4096, 16384, 65536 Of course, one hash value is sufficient for 0 bit input. (d) Pseudo-Random Number Generators Number of inputs for seed from outer source: at least 10 Number of outputs: at least 8192 bits for each input
(5) Reference Program i) To achieve the following goals, submit a reference program and its specification. An applicant is asked to confirm that the reference program runs.
15/27 To confirm that the submission of cryptographic schemes can actually be implemented. To verify efficiently whether or not the data regarding the submission of cryptographic primitives are correct. Code the reference program using ANSI C. Do not include any process that makes the reference program hard to understand, for example, zeroizing the variables that is no longer to use, in the reference. ii) Implement all functions described in the specification including recommended parameters. The reference program should be portable, however, the readability of the reference program may not be sacrificed by the portability. For example, endian independent is preferable. The reference program should run on the platform whose sizes of int and long and the length of pointers are 32 bits. We recommend GNU MP library version 3.1.x if the computation of multiprecision integer is necessary. iii) A test vector generating program and its specification should be submitted. The program should call the reference program. iv) In the full evaluation phase, we may ask applicants to submit the program and its specifications to evaluate speed. The reference program and test vector generation program are required to submit for submission of symmetric ciphers, hash functions and pseudo random number generators, while they are not for submission of asymmetric cryptographic schemes.
(6) Publication status of specification (Appendix B) Describe (a), (b) and (c) in Appendix B. (a) Publicities related to the proposed cryptographic technique In this submission, all specifications of the technique should be disclosed. Provide the confirmation for publicities (for example, the time to disclose the specifications, academic meetings and articles, etc.). If it is not disclosed at the time of submission, provide the current status, the plan for publicity and the confirmation that it will be disclosed by the end of this September. Inform the CRYPTREC secretariat of the confirmation. (b) The export control rules Carrying out this project, the CRYPTREC evaluation committee will request evaluation of experts oversea. This means that submitted information may be provided to nonresidents of Japan. Provide the evidences and the confirmations by which the export control permission becomes clear for each of items (1) to (7) specified in Section 5, “Documents for Submission”. For example, if you have determined that no permission will be required because the technique has already been disclosed in academic journals, magazines, papers or other publications and is generally available to the public, submit copies of
16/27 such publications with the explanations showing how the technique has been disclosed. (c) Intellectual property rights and the license. Explain intellectual property rights (IPR) related to the submitted cryptographic technique, including an effective/pending patent, copyright, license, in appendix B. If a third-party company owns a patent, copyright, license, or other IPR related to the submitted cryptographic techniques, explain them, as far as possible, in appendix B. Submit information in which the CRYPTREC secretariat is able to use the IPR (including the implementation of an invention as defined in the Patent Law and the copying and distribution of a copyright materials as defined in the Copyright Law) in order to evaluate the cryptographic technique without any fee. If any IPR problem turns out to be an obstacle for CRYPTREC evaluation committee to evaluate the submitted cryptographic technique, the submission will not be considered. Describe the applicant’s policy of license when the cryptographic technique is applied to systems of the Japanese government organizations. It is desirable that license condition is "permitting no exclusive use" or looser. If the CRYPTREC secretariat determines that the condition is not suitable for the Japanese electronic government, the submission will not be considered. No contract is to be made between an applicant and CRYPTREC to evaluate the submitted cryptographic technique.
(7) Presentation file for CRYPTREC submission explanation meeting An applicant is requested to make presentation documents in the PowerPoint format referring to the following profile. Each presentation will be 15-minute duration. This document will be distributed at the CRYPTREC submission explanation meeting. Remember that the distributed document will be monochrome.
(8) Self-check List (Appendix C) Confirm all documents for submission according to this list. The copy of the completed list should be enclosed.
17/27 6. Remarks
(1) The copy of the completed self-check list shall be enclosed. (2) In this submission, neither CRYPTREC secretariat nor the applicant will pay any fees and reimbursement costs to the other party. (3) The applicant will bear the cost for cryptography development, document preparation, self-evaluation and other procedure related to this submission. Any cost for making responses to our questions or requests and dispatching personnel to us, is also the applicant share. The CRYPTREC office will bear the cost for evaluation in our office. (4) If the CRYPTREC office determines that the submitted information is insufficient to evaluate a cryptographic technology, evaluation may be given up. (5) The contact person should be fluent in Japanese language and rapidly respond to any inquiry from the CRYPTREC secretariat. Especially, the applicant should be ready to respond to any request during the deadline and the CRYPTREC submission explanation. When any changes occurs in address, email address, telephone number, fax number of the contact person, the applicant should renew the Application Form and submit to the secretariat immediately (includes electronic media).
18/27 7. How to make the submission
(1) Deadline September 27, 2001 17:00 (Japan Standard Time). A submission should be received by the CRYPTREC secretariat before September 27, 2001 17:00 (JST). Only a postal mail or parcel delivery (at the applicant’s expense) will be accepted.
(2) Items Enclose all items listed in Section 5, “Documents for Submission”. The electronic media shall be provided on CD-R or CD-RW or M.O. (Magneto Optical Disk), which is titled by the applicant’s name and the name of the cryptographic technique. If the applicant submits more than one cryptographic technique, make an Application Form for each submission and send it separately. Do not put more than one Application Form in one envelope. (3) Forwarding address: CRYPTREC secretariat c/o IT Security Center, Information-technology Promotion Agency, Japan Bunkyo Green Court Center Office 2-28-8 Honkomagome, Bunkyo-ku Tokyo 113-6591 Japan
For further information, contact to: CRYPTREC secretariat c/o IT Security Center, Information-technology Promotion Agency, Japan Bunkyo Green Court Center Office 2-28-8 Honkomagome, Bunkyo-ku Tokyo 113-6591 Japan FAX: +81-3-5978-7518 e-mail: cryptrec[email protected] (Not acceptable by phone)
19/27 Reference
Block ciphers [B1] L.R. Knudsen, “Practically Secure Feistel Ciphers,” 1st Fast Software Encryption(1993), LNCS 809, pp.211-221, Springer-Verlag, 1994. [B2] M.E. Hellman, “A Cryptanalytic Time-Memory Trade-Off,” IEEE Trans. On Information Theory,26(4), pp.401-406,1980. [B3] E. Biham, A. Shamir, “Differential Cryptanalysis of DES-Like Cryptosystems,” Journal of Cryptology, 4(1), pp.3-72, 1991. [B4] L.R. Knudsen, T.A. Berson, “Truncated Differentials of SAFER,” 3rd Fast Software Encryption(1996), LNCS 1039, pp.15-25, Springer-Verlag, 1996. [B5] S. Lucks, “On the Security of the 128-Bit Block Cipher DEAL,” 6th Fast Software Encryption(1999), LNCS 1636pp.60-69, Springer-Verlag, 1999 [B6] D. Wagner, “The Boomerang Attack,” 6th Fast Software Encryption(1999), LNCS 1636pp.156-170, Springer-Verlag, 1999 [B7] M. Matsui, “Linear Cryptanalysis Method for DES Cipher,” EUROCRYPT’93, LNCS 765, pp.386-397, Springer-Verlag, 1994. [B8] P. Hawkes, “Differential-Linear Week Key Class of IDEA,” EUROCRYPT’98, LNCS 1403, pp.112-126, Springer-Verlag, 1994. [B9] M. Tanaka, T. Hamaide, K. Hisamatsu and T. Kaneko, “Linear cryptanalysis by Linear Sieve Method,” IEICE Transactions on Fundamentals of Electronics, Communications and Computer Science, E81-A(1), pp.82-87, 1998. [B10] L.R. Knudsen, “Truncated and Higher Order Differentials,” 2nd Fast Software Encryption(1996), LNCS 1008, pp.196-211, Springer-Verlag, 1995. [B11] T. Jakobsen and L.R. Knudsen, “ The Interpolation Attack on Block Ciphers,” 4th Fast Software Encryption(1997), LNCS 1267, pp.28-40, Springer-Verlag, 1997. [B12] E. Biham, A. Biryukov, N. Ferguson, L.R. Knudsen, B. Schneier, A. Shamir, “Cryptanalysis of Magenta,” 2nd AES Conference, pp. 182-183, 1999. [B13] A. Biryukov, D. Wanger, “Slide Attacks,” 6th Fast Software Encryption(1999), LNCS 1636, pp.245-259, Springer-Verlag, 1999. [B14] E. Biham, “New Type of Cryptanalytic Attacks Using Related Keys,” EUROCRYPT’93 LNCS 765, pp.398-409, Springer-Verlag, 1993. [B15] C. Harpes, J.L. Massey, “Partitioning Cryptanalysis,” FSE’97, LNCS 1267, pp.13-27, Springer-Verlag, 1997. [B16] J. Kelsey, B. Schneier, and D. Wagner, “Mod n Cryptanalysis, with Applications against RC5P and M6,” FSE’99, LNCS1636, pp.139-155, Springer-Verlag, 1999. [B17] V. Rijmen, B. Preneel and E.De Win, “On Weaknesses of Non-surjective Round Functions,” Designs, Codes and Cryptography, 12, pp.253-266, 1997. [B18] J.Daemen and V. Rijmen, “Resistance against Implementation Attacks: A Comparative Study of the AES Proposals,” 2nd AES Conference, pp.122-133, 1999. [B19] P. Kocher, “Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other systems,” CRYPTO’96, LNCS 1109, pp.104-113, Springer-Verlag, 1996. [B20] TAO Research Project on Info-communication Security, “Technical Report on Design, Analysis and Use of Block Ciphers,” Telecommunications Advancements Organization of Japan, 2000 (in Japanese). 20/27 Stream ciphers [S1] Biryukov, Shamir, Wagner, “Real Time Cryptanalysis of A5/1 on a PC,” FSE2000 [S2] Canteaut, Filiol, “Ciphertext Only Reconstruction of Stream Ciphers based on Combination Generator,” FSE2000 [S3] Chepyzhov, Johansson, Smeets, “A simple algorithm for fast correlation attacks on stream ciphers,” FSE2000 [S4] Ding, “The Differential Cryptanalysis and Design of Natural Stream Ciphers,” Fast Software Encryption, Cambridge Security Workshop, December 1993, LNCS 809 [S5] Ding, Xiao, Sham, “The Stability Theory of Stream Ciphers,” LNCS 561 [S6] Johansson, Jonsson, “Fast correlation attacks based on Turbo code techniques,” CRYPTO’99, August 99, 19th Annual International Cryptology Conference, LNCS 1666 [S7] Fossorier, Mihaljevic, Imai, “Critical Noise for Convergence of Iterative Probabilistic Decoding with Belief Propagation in Cryptographic Applications,” LNCS 1719. [S8] Golic, “Linear Cryptanalysis of Stream Ciphers,” Fast Software Encryption, Second International Workshop, December 1994, LNCS 1008. [S9] Johansson, Jonsson, “Improved Fast Correlation Attacks in Stream Ciphers via Convolutional codes,” EUROCRYPT’99, International Conference on the Theory and Application of Cryptographic Techniques, May 1999, LNCS 1592 [S10] Meier, Staffelbach, “Correlation Properties of Combiners with Memory in Stream Ciphers,” Journal of Cryptology 5(1992) [S11] Palit, Roy, “Cryptanalysis of LFSR-Encrypted Codes with Unknown Combining,” LNCS 1716 [S12] Rueppel, “Correlation Immunity and Summation Generator,” CRYPTO’85 Proceedings, August 85, LNCS 218. [S13] Sigenthalar, “Decrypting a class of Ciphers using Ciphertext only,” IEEE C-34. [S14] Tanaka, Ohishi, Kaneko, “An Optimized Linear Attack on Pseudorandom Generators using a Non-Linear Combiner, Information Security,” First International Workshop, ISW’97 Proceedings, September 1997, LNCS 1396 [S15] Zeng, Huang, “On the Linear Syndrome Method in Cryptanalysis,” CRYPTO’88 Proceedings, August 1988, LNCS 403. [S16] Zeng, Yang, Rao, “On the Linear Consistency Test in cryptanalysis and its applications,” CRYPTO’89 Proceedings, August 89, LNCS 435. [S17] Zeng, Yang, Rao, “An improved Linear Syndrome Algorithm in Cryptanalysis with Applications,” CRYPTO’90 Proceedings, August 90, LNCS 537. [S18] Zeng, Yang, Wei, Rao, “Pseudorandom Bit Generators in Stream-Cipher Cryptography,” IEEE Computer Feb-1991
21/27 Hash Functions [H1] H.Dobbertin, “Cryptanalysis of MD4,” Fast software encryption,Springer-Verlag, 1996, pp.53-69 [H2] H.Dobbertin, “The status of MD5 after recent attack,” CryptoBytes, 2(2), Sep., 1996, pp.1.-6 [H3] F. Chabaud and A. Joux, “Differential Collisions in SHA-0,” Advances in Cryptology-Crypto’94, Springer-Verlag,pp.56-71 [H4] B.den Boer and A, Bosselaers “ An attack on the last two rounds of MD4,” Advances in Cryptology-Crypto’91, Springer-Verlag, pp.194-203 [H5] E.Biham, and A.Shamir, Differential cryptanalysis of the Data encryption Standard, Springer-Verlag, 1993 [H6] M. Bellare, J.Kilian, and P.Rogaway, “ The security of cipher blocks chaining,” Advances in Cryptology-Crypto’94, Springer-Verlag, pp.341-358 [H7] Preneel and Knudsen, Hash Functions Based on Block Ciphers and Quaternary Codes, Advances in Cryptology - Proc. ASIACRYPT’96, LNCS 1163, pp. 77-90, Springer Verlag, 1996. [H8] B. Preneel and P.C. van Oorschot and Knudsen, “MDx-MAC and building fast MACs from hash functions,” Advances in Cryptology, Proceedings Crypto’95, LNCS 963, D. Coppersmith, Ed., Springer-Verlag, 1995, pp. 1-14.
Pseudo-Random Number Generators [R1] Rueppel: Analysis and Design of stream ciphers, Springer-Verlag, Berlin,1986 [R2] Niederreiter: “The probabilistic theory of liner complexity”, Advances in Cryptology-EUROCRYPT ‘88 (LNCS 330), 191-209, 1988 [R3] Niederreiter: “A combinatorial approach to probabilistic results on the liner-complexity profile of random sequences”, Journal of Cryptology, 2(1990), 105-112 [R4] Niederreiter: “Keystream sequences with a good linear complexity profile for every starting point”, Advances in Cryptology-EUROCRYPT ‘89 (LNCS 433), 523-532,1990 [R5] Niederreiter: “The linear complexity profile and the jump complexity of keystream sequences”, Advances in Cryptology-EUROCRYPT ‘90 (LNCS 473), 174-188, 1991 [R6] Jansen and Boekee: “On the significance of the directed acyclic word graph in cryptology”, Advances in Cryptology-AUSCRYPT ‘90 (LNCS 453), 318-326,1990 [R7] Jansen and Boekee: “The shortest feedback shift register that can generate a given sequence”, Advances in cryptology-CRYPTO ‘89 (LNCS 435), 90-99, 1990 [R8] Ziv and Lempel: “On the complexity of finite sequences”, IEEE Transactions on Information Theory, 22(1976), 75-81 [R9] Erdmann: “Empirical tests of binary keystreams”, Master’s thesis, Department of Mathematics, Royal Holloway and Bedford New College, University of London, 1992 [R10] Kolmogorov: “Three approaches to the definition of the concept ‘quantity of
22/27 information’”, Problemy Peredachi Informatsii, 1(1965), 3-11 [R11] Chaitin: “On the length of programs for computing finite binary sequences”, Journal of the association for Computing Machinery, 13(1996), 547-569 [R12] Meier and Staffelbach: “Fast attacks on certain stream ciphers”, Journal of Cryptography, 1(1989), 159-176 [R13] Chepyzhov and Smeets, “On a fast correlation attack on certain stream ciphers”, Advances in Cryptography-EUROCRYPT ‘91 (LNCS 547), 176-185,1991 [R14] Coppersmith, Krawczyk, and Mansour, “The shrinking generator”, Advances in Cryptography-CRYPTO ‘93 (LNCS 773), 22,39,1994 [R15] Rubin, “Decrypting a stream cipher based on J-K flip-flops”, IEEE Transaction on computers, 28(1979), 483-487 [R16] Zeng, Yang, and Rao, “On the linearsyndrome algorithm in cryptanalysis with applications”, Advances in Cryptology-CRYPTO ‘90 (LNCS 537), 34-37,1991 [R17] Siegenthaler, “Decrypting a class of stream cipher using ciphertext only”, IEEE Transactions on Computers, 34(1985), 81-85 [R18] Golic, “Correlation via linear sequential circuit approximation of combiners with memory”, Advances in Cryptology-EUROCRYPT ‘92 (LNCS 658), 113-123, 1993 [R19] Siegenthaler, “Cryptanalysis representation of nonlinear filtered ML-sequences”, Advances in Cryptology-EUROCRYPT ‘85 (LNCS 219), 103-110, 1986 [R20] Ding, “The differential cryptanalysis and design of natural stream ciphers”, R. Anderson, editor, Fast Software Encryption, Cambridge Security Workshop (LNCS 809), 101-115, Springer-Verlag [R21] Zeng, Yang, and Rao, “On the linear consistency test (LCT) in cryptanalysis with applications”, Advances in Cryptology-CRYPTO ‘89 (LNCS 435), 164-174,1990 [R22] Massey and Rueppel, “Linear ciphers and random sequence generators with multiple clocks”, Advances in Cryptology-Proceedings of EUROCRYPT 84 (LNCS 209), 74-87, 1985 [R23] Gunther, “Alternating step generators controlled by de Bruijn sequence”, Advances in Cryptology-EUROCRYPT ‘87 (LNCS 304), 5-14, 1988 [R24] Zivkovic, “An algorithm for the initial state reconstruction of the clock-controlled shift register”, IEEE Transactions on information Theory, 37(1991), 1488-1490 [R25] NIST Computer Security Special Publications 800 Series, “A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,” NIST SP800-22, June 2000
23/27 (Appendix A)
Receipt number
To CRYPTREC Submission Date: / /2001 Application Form(Submission Form 1 ) Name of cryptographic technique: Abbreviation:
URL for submitted cryptographic technique:
Category 1 Asymmetric a) Confidentiality b) Authentication c) Signature cryptographic scheme d) Key agreement 2 Symmetric cipher a) 64bit block cipher b) 128bit block cipher c) Stream cipher
3 Hash function
4 Pseudorandom number generator Applicant in charge Affiliation:
Name: Title:
Contact person Affiliation:
Name: Title:
Address:
TEL:
FAX: e-mail: Developer Name: Affiliation:
Contact person for supply Name: Title:
Affiliation: Address:
TEL: FAX: e-mail: CRYPTREC submission explanation meeting Name of the speaker: Number of attendants:
TEL: FAX: e-mail:
24/27 (Appendix B)
Publication status of specification (Submission Form 6) Name of cryptographic technique i) Date and the name of the conference where the submission was publicized Date Name of the speaker Name of the conference Title of the talk and the paper ii) Oath on settlement of the export regulations and the evidence We declare that there is no regulations on the documents of the submitted technique ( ). Name of the applicant in charge
Evidence on settlement of the regulations (attach a copy of the document).
Title of the document iii) Intellectual property and license We declare that there is no responsibility for evaluation purpose of CRYPTREC On the submitted technique ( ).
Name of the applicant in charge
Describe all patents and intellectual properties regarding the submission Patent number, Title, Date of application
Copyright Describe all related patents
Describe license policy of usage for the electronic government in Japan.
Any other remark
25/27 Self checklist (SubmissionForm 8) (Appendix C) This is to make sure your submission materials. We summarize the statements underlined in the main text. Please check ( X ) after you confirm the following items.
Check items ( ) 1 Will the submitted cryptographic technique be available by March of 2003? ( ) 2 Will the specifications and other information of the submitted cryptographic technique be disclosed to the public by the deadline of the submission (Sep/27/2001)? (Please contact with our secretariat by Sep/10/2001, if you have any reason you cannot disclose the specification by the deadline.) ( ) 3 Do you submit only one cryptographic technique for a category? ( ) 4 Does the submitted cryptographic technique belong to one of the categories of solicited cryptographic technique? ( ) 5 Do you give in all the following materials? - Application Form, - Specifications, - Self Evaluation Report, - Test vector (test vector generating program), - Reference code, - Information regarding the public availability status of the “specifications”, - Presentation file for CRYPTREC submission explanation meeting, - Self checklist ( ) 6 Do you prepare all documents given below?
Application Form ( ) 7 Do you give URL giving information on submitted cryptographic technique ( ) 8 Can we get in touch with the contact person? Is he or she fluent in Japanese language? ( ) 9 Do you give in the telephone number, the fax number, e-mail address for the contact person?
Specifications, ( ) 10 If the cryptographic technique is submitted to CRYPTREC for the first time, do you describe special features that make the technique superior or equal to the cryptographic techniques fully evaluated in the year 2000 for CRYPTREC project? ( ) 11 Do you provide necessary information for implementation of the submitted cryptographic technique?
26/27 ( ) 12 Can a third party implement all functions of the submitted cryptographic technique? ( ) 13 If you submitted a cryptographic technique to any other organization under a similar name of your submission to CRYPTREC, do you enumerate all such cryptographic techniques and give references?
Self Evaluation Report ( ) 14 Do you provide sufficient information on your evaluation of the submitted cryptographic technique?
Test vector ( ) 15 Do you provide test vectors for the cryptographic technique more than the number specified for the corresponding category?
Reference Program *Submission is recommended for asymmetric cryptographic schemes. ( ) 16 Did you confirm that the reference program runs? ( ) 17 Do you provide a test vector generating program?
Publication status of specification ( ) 18 Do you state when and where the submitted cryptographic technique was made open to the public? ( ) 19 Do you give an oath on settlement of the export regulations and the documents giving its evidence? ( ) 20 Do you describe the related intellectual property and license? ( ) 21 Is your license policy reasonable for constructing electronic government in Japan?
Presentation file for CRYPTREC submission explanation meeting ( ) 22 Do you provide the presentation file?
27/27