(Provisional Translation)
Information-technology Promotion Agency, Japan
June 13, 2000
Final Version July 5, 2000
1. Purpose of this Project
With the goal of improving administrative efficiency and reducing paperwork costs for the private sector, the Japanese government aims to create, by FY 2003, the infrastructure of an electronic government that will computerize administrative procedures.
When created, this electronic government will be a model in a digital economy/society. A set of IT security measures that will be implemented in the electronic government is also expected to become a model for the private sector, thereby enhancing the security and reliability of the nationwide information network which are a core element of information security in the electronic government.
The purpose of this project is to list valid cryptographic techniques, together with their profile of their security and implementation aspects safety and ease of implementation. People are encouraged to present various proposals for cryptographic techniques, which will be evaluated in a professional and objective manner. The results of this project will be submitted to the government, and used in various ways as references for using cryptographic techniques in the electronic government.
2. Overview and Schedule of this Project
This project is part of the Electronic Government Security Technology
Development Project, which is sponsored by the Ministry of International
Trade and Industry (MITI) and entrusted to the Information-technology
Promotion Agency (IPA), Japan. For the implementation of this
1

cryptography evaluation project, IPA has established the Cryptography
Research and Evaluation Committee, which consists of experts in cryptography. The tasks of IPA and its expert committee are as follows:
(1) To issue a call for submissions for cryptographic techniques that can be applied in building systems within the electronic government
(2) To establish evaluation criteria for each category of cryptographic techniques
(3) To evaluate submitted cryptographic techniques in accordance with the evaluation criteria. Some non-submitted cryptographic techniques will also be evaluated if an evaluation of these techniques is considered to be necessary. The evaluation will be conducted in two phases: screening and detailed. Detailed evaluation will be conducted on those techniques that have passed the screening phase. Part of the evaluation will be conducted by external cryptography experts in Japan and abroad.
(4) To scrutinize and list the profiles of the cryptographic techniques by using the results of external evaluations and other evaluations by academic groups. The evaluation results will be used within the government, and appropriate portions of the evaluation results will be publicized (The evaluation results might include information that is not beneficial to the submitters).
Schedule for the evaluation of cryptographic techniques (planned)
Publication of evaluation criteria (done): July 5, 2000
Deadline for the proposal of cryptographic techniques arrival:
July 14, 2000
Screening evaluation: August - September, 2000
Announcement of screening evaluation results: Early October, 2000
Detailed evaluation: October - December, 2000
Announcement of detailed evaluation results: February, 2001 or later
3. The Categories of Solicited Cryptographic Techniques
We are soliciting proposals regarding cryptographic techniques that may be useful for building systems in the electronic government and that belong to one of the following categories, (1), (2), (3) and (4).
2

We will limit the scope of proposals to cryptographic techniques whose specifications and other information have been disclosed to the public. The purpose of this limitation is to ensure we receive evaluations from a wide range of specialists as well as to allow many implementers (vendors) to use the results in various applications.
Category (1) Asymmetric Cryptographic Schemes
We are soliciting Asymmetric Cryptographic Schemes that are designed for the following security functions: confidentiality, authentication, signature, and key-sharing. They must be submitted with at least one design example. If your asymmetric cryptographic scheme can implement more than one security function, select one function as the primary. If you believe that your asymmetric cryptographic scheme is capable of handling more than one primary function, submit your proposals respectively for each function.
An Asymmetric Cryptographic Scheme referred to here refers to an algorithm that provides one or more security function by using
Cryptographic Primitive(s) and some Auxiliary Function(s), and consists of a description of the algorithm, requirements for cryptographic primitives and auxiliary functions.
A Cryptographic Primitive is an elementary cryptographic algorithm that provides security based on integer factoring problems, discrete logarithm problems, elliptic curves discrete logarithms problems, or other security reasons.
An Auxiliary Function is an element, such as a hash function, a
(pseudo-) random number generator, that is not a cryptographic primitive but necessary for a scheme.
Design examples of cryptographic schemes need to clarify specific cryptographic techniques that will be defined by the following procedure and can be implemented on software or hardware. First, define your cryptographic scheme, and then provide details of your specific cryptographic primitive(s) and auxiliary function(s). If your scheme uses a
3

new auxiliary function, submit it to the respective category.
Further, specify the criteria used for selecting parameters to be assigned to the cryptographic primitive(s) or auxiliary function(s), and provide recommended samples of parameter values. Finally, state clearly any multiple-precision operation routines, co-processors, and other features that will be needed to implement your design example.
Category (2) Symmetric Ciphers
The subcategories comprising this Symmetric Ciphers are as follows:
(i) Stream ciphers （ initial value space ： 128 bits or more, number of states ：
128 bits or more ）
(ii) 64-bit block ciphers （ key length ： 128 bits or more ）
(iii) 128-bit block ciphers （ key length ： 128 bits or more ）
Category (3) Hash Functions
We are soliciting functions that generate 128-bit or longer hash values.
Category (4) Pseudo-Random Number Generators
We are soliciting pseudo-random number generation algorithm that generates keys or seeds of keys or other parameters for cryptographic techniques.
4. What is Required When Making a Submission
The following is required when submitting a proposal for cryptographic techniques:
4.1 Consistency of Submitted Cryptographic Techniques with the Scope of this Project
Any submission of cryptographic technique must satisfy the condition specified in Chapter 3, "The Categories of Solicited Cryptographic
Techniques ".
In particular, the “specifications” of submitted technique needs to be available to the public. Whether the proposed cryptographic techniques are available to the public is determined by using criteria (1) and (2) below. (If
4

any procedures are needed in respect to the Foreign Exchange and Foreign
Trade Control Law or other statutes, patents or other rights, among others, the applicant is responsible for satisfying the procedures.) If cryptographic techniques are not available to the public as defined above, but are expected to be so by the end of September, 2000, before the detailed evaluation phase is to start in October, a proposal for that technique may be submitted. (If cryptographic techniques cannot be proved to be available to the public by the end of September, 2000 by the IPA, further evaluation for the techniques will not take place.)
(1) The information (both Japanese and English) identified by (2) - (4) in the
Section 4.2, "Submission of Information Needed for Evaluation"
(Cryptographic Techniques Overview, Cryptographic Techniques
Specifications, and Self Evaluation Reports. These are hereafter called the “specifications” in this paper) is publicly known technology or another form of information generally available to the public without restriction, and is one of the following:
(i) Technical data generally available to the public by way of newspapers, books, magazines, catalogs, or similar documents (excluding information that is contained in users manuals, maintenance manuals, or other documents attached to purchased products).
(ii) Technical data generally accessible to the public by way of academic journals, published patent information, minutes of open symposiums, or similar documents.
(iii) Technical data that can be read or listened to by the general public at libraries, through regular courses offered to plant visitors, at lectures, at exhibitions, or in a similar manner.
(2) The “specifications” or specific procedures for obtaining the
“specifications” for the general public without restriction or difficulty have been made available on a Web page prepared by the applicant.
If submitted cryptographic techniques have passed screening evaluation, the IPA will create a link to the Web page prepared by the applicant to publicize the information.
5

4.2 Submission of Information Needed for Evaluation
When submitting a proposal before July 14, 2000, the following items
(1) to (9) are available to the public. These items will be used to evaluate the submitted cryptographic techniques. These items may be disclosed by the
Information-technology Promotion Agency, Japan to third parties from July
14, 2000.
No
Language
Item to be submitted
Format medium
Japanese or English
Document and electronic medium
(1)
Cryptographic
Techniques Application
Form
(2)
Cryptographic
Techniques Overview
(3)
Cryptographic
Techniques
Specifications
(4) Self Evaluation Report
Japanese and English
Document and electronic medium
Japanese and English
Document and electronic medium
Cryptographic
Techniques
Application Form
Cryptographic
Techniques Overview
No specific format
No specific format
(5) Test vector
Japanese and English
Document and electronic medium
Electronic medium only
(text format)
No specific format
(6)
Sample code Electronic medium only (text format) No specific format
Japanese No specific format
(7)
Information regarding the public availability status of the
"specifications"
(8) Information regarding intellectual property rights
(9) Company profile
Document and electronic medium
Japanese
Document and electronic medium
Japanese or English
Document and electronic medium
No specific format
Company Profile
6

Japanese and English versions are required for items (2) to (4). However, at the time of submission (on or before July 14, 2000), a Japanese or English version may be submitted independently. The other version must be submitted by the end of September, 2000.
During the evaluation process, the Japanese version will be treated as the formal document and the English version will be treated as an auxiliary document.
Since detailed evaluation may be conducted overseas, items (2) to (4) need to be submitted in both English and Japanese. The Japanese version will be treated as the formal document and the English version will be treated as an auxiliary document. If a conflict is found between the two versions, the Japanese version will be considered correct. However, such conflicts should be eliminated as far as possible. If a conflict of this type hinders the execution of evaluation, the submitted Cryptographic
Techniques might be made ineligible for evaluation.
Each item to be submitted is explained below.
(1) Cryptographic Techniques Application Form
Write the name of submitted cryptographic techniques, submitter, inventor(s)/developer(s), and other information in the proper location on the
Cryptographic Techniques Application Form format.
(i) Application date
Write the application date.
(ii) Name of cryptographic techniques
Write the name of submitted cryptographic techniques.
(iii) Categories
Select one from asymmetric cryptographic schemes, symmetric ciphers, hash functions and pseudo-random number generators.
(iv) Submitter’s name
The submitter should be a person who has a well understanding of the proposed cryptographic techniques.
Write the submitter’s name, organization (company) name,
7

department/faculty name, title, address, phone number (whether it is a company or dial-in telephone), FAX number, e-mail address, and web address.
(v) Developer’s name
Write the name of the cryptographic technique inventor(s)/developer(s) if the developer is different from the submitter.
Write the name and organization (company) name of the inventor(s)/developer(s).
(2) Cryptographic Techniques Overview
Write the following information according to the Cryptographic
Techniques Overview format.
(i) Name of submitted cryptographic techniques
Write the name of submitted cryptographic techniques.
(ii) Categories
Select one from asymmetric cryptographic schemes, symmetric ciphers, hash functions and random number generators.
(iii) Security Functions / Subcategories
Choose one out of confidentiality, authentication, signature and key- sharing in the case of asymmetric cryptographic scheme.
Choose one out of the stream ciphers, 64-bit block ciphers and 128-bit block ciphers in the case of the symmetric cipher.
(iv) Design policy
Write what you consider to be most beneficial about your submission in terms of design clarity, structural simplicity, and flexibility.
(v) Intended applications
Write the kind of applications you propose to apply the cryptography to.
(vi) Basic theory and techniques
Write the theory and techniques on which the cryptography is based.
(vii) References of submission
Write principal references of the cryptography and underlying techniques (paper titles, authors, magazine names, and publication dates).
(viii) Previous use
Write previous use of the cryptographic techniques.
8

(3) Cryptographic Techniques Specifications
(i) Design policy and design criteria
(ii) Cryptographic techniques (all information needed for implementation)
The information provided needs to contain information sufficient to allow any third party to evaluate and implement the submitted cryptographic techniques. If this information is insufficient, the proposal could be made ineligible for evaluation. Follow the Criteria below. a) Write a complete specification for the cryptographic technique. The specification needs to include all information needed to implement the cryptographic techniques (such as mathematical equations, tables, algorithm logic, charts, and parameters). b) If conditions must be satisfied before cryptographic key or other parameters can be properly set, you should also write configuration standards and recommended parameter values. c) For an asymmetric cryptographic scheme, specify the field, ring, or group on which the submitted algorithm is based. d) You should also specify any auxiliary functions required to make the submitted algorithm available (to implement the scheme). If your scheme uses a new auxiliary function, submit it to the respective category. e) If your symmetric cipher supports multiple key lengths, specify whether compatibility between functions corresponding to different key lengths is provided.
If your submission requires a special device or relies on an algorithm that is not in publicly available, your submission will be made ineligible for evaluation as a rule.
If the information provided is determined to be insufficient for implementation, your submission will be made ineligible for evaluation.
You may be requested to provide additional information required for evaluation.
(4) Self Evaluation Report
Describe self-evaluation information regarding your proposal. In particular, items (i) and (ii) are mandatory. If we conclude that your self-evaluation information is insufficient, your proposal might be made
9

ineligible for evaluation.
(i) Evaluation of security aspects
Show a concrete basis of the security provided by your submission.
And, provide information on the countermeasures to be used against a specific attack. You should also specify countermeasures that will be used against typical attacks that could occur in ordinary environments.
For typical attacks, see Chapter 5, "Evaluation Criteria".
You need not evaluate to resistance against all attacks assumed in
Chapter 5, "Evaluation Criteria". If you conclude that your cryptographic techniques are unable to resist against one of the attacks listed in Chapter 5, you do not have to evaluate your proposal in this respect, but you should clearly state why believe that your proposal would not be able to resist against the attack. If no self-evaluation is included, cryptographic techniques will not be evaluated.
If a specific attack can be assumed on your proposal, describe specific countermeasures against that attack.
If any academic articles concerning that attack method exist, or any references about the attack method have been made in academic meetings (ISEC, SCIS, CRYPTO, EUROCRYPT, ASIACRYPT, FSE, PKC, etc.), provide a technical commentary quoting the relevant information from such sources.
(ii) Evaluation of software implementation
Describe about speed evaluation, memory usage (code quantity, work area, etc), optimization level, description language, evaluation platform, and so on.
Note: you should also describe the speed evaluation result of the key scheduler individual for the block cipher.
If co-processors are used in an asymmetric cryptographic scheme for acceleration, provide information about the size of the RAM and
ROM that control the co-processors. Also provide evaluations about processing speed for entire software/hardware implementations when co-processors are used.
(iii) Evaluation of hardware implementation
Describe the process used (Field Programmable Gate-Array, gate
10

array), speed evaluation, design environment, 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.
Simulation evaluation results may also accept as information that proves the processing speed and resource consumption.
Note the following for evaluation of implementation aspects of asymmetric cryptographic scheme; if the use of a co-processor can increase the speed of processing, describe the functions, the number of gates, and processing performance of the co-processor used.
(iv) Third party's evaluation results
If a third party has already evaluated your submission, provide a report on the evaluation results. Attach the report, if any are available.
(5) Test vector
Provide test vectors that are sufficient in quantity to evaluate the implementation performance of the cryptographic technique. If the quantity of the submitted test vectors is insufficient, the submitted cryptographic technique might be made ineligible for evaluation. The minimum requirements are as follows:
(i) Asymmetric Cryptographic Schemes
Number of key pairs ： 10
Number of processing samples for each key pair ： 20
(ii) Symmetric Ciphers a) Stream ciphers
Number of keys ： 10
Processing sample for each key ：
16 initial vectors for each 512 bits/block
8 initial vectors for each 1,024 bits/block
4 initial vectors for each 2,048 bits/block
2 initial vectors for each 4,096 bits/block
1 initial vector for 8,192 bits/block b) Block Ciphers
Number of keys ： 10
Processing sample in ECB mode for each key ： 4,096 blocks
Describe a treatment example for one block and the intermediate
11

result data.
(iii) Hash Functions
Original data sizes ： 512 bits, 1,024 bits, 2,048 bits, 4,096 bits, 16,384 bits, 65,536 bits
Number of processing samples for each data size ： 10
Note: In the case of Hash function of the repetition type, include one example that contains the intermediate result when the data size of the cause is 512 bits.
(iv) Pseudo-Random Number Generators
Number of samples (Initial vector) ： 10
Each sample size : 32,768 bits each
(6) Sample Code
Even if sample code is not submitted, your submission will be evaluated. However, it is recommended that you submit sample code in order to reduce the workload required for implementation evaluation.
Write sample code in ANSI-C.
(7) Information regarding the public availability status of the
“specifications”
This project is targeted at cryptographic techniques whose
“specifications” have been made available to the public (see Section 4.1).
Therefore, submit information that can be used to confirm that the submitted cryptographic technique satisfies the public availability requirements. (If the technique does not meet the public availability requirements at the time of submission, submit the current status and schedule outlining the planned disclosure procedure up to the end of
September. As soon as the public availability requirements are met, submit the information needed to confirm it.)
In carrying out this project, the IPA plans to use evaluation by outside experts, including organizations or people overseas. This means that submitted information may be provided to nonresidents of Japan.
Accordingly, for each of items (2) to (6) specified in Section 4.2,
"Submission of Information Needed for Evaluation," specify the export-control-related condition (i), (ii), or (iii) below the item is in and provide information that can be used by the IPA to confirm that the item
12

is in the indicated condition.
If the IPA determines that the submitted information is insufficient for adequate and speedy evaluation, it may rule that the proposal is ineligible for evaluation.
(i) If you have determined that export control permission is not required for the presentation of the submitted information to nonresidents, submit information that can be used by the IPA to confirm that this judgment is correct. (For example, if you have determined that no permission will be required because the technique has already been publicized in academic journals, magazines, papers, or other publications and, therefore, is generally available to the public, submit copies of such publications with an explanation showing how the technique has been disclosed.)
(ii) If you have determined that the presentation of the submitted information to nonresidents will require an export control permission at the time of submission, but will not by the time of the end of September, submit a written proof of this judgment (such as a specific schedule). (When the condition that eliminates the need for a permission ensues, immediately submit a document that states and proves this fact.)
(iii) If you have determined that an export control permission will be required for the presentation of the submitted information to nonresidents, submit this statement.
(8) Information regarding intellectual property rights (IPR)
Explain intellectual property rights related to the proposed cryptographic technique, including a effective/pending patent, copyright, license, in the paragraph entitled " Our IPR and Their Handling."
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 the paragraph entitled "Other Companies' Related IPR."
Submit information that can be used by the IPA to confirm that the use of 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) required for the evaluation (including any evaluation conducted by outside evaluators) will be free of charge. If
13

restrictions imposed by the IPR involved hinder the implementation of the evaluation, the IPA may determine that the proposed technique is ineligible for evaluation.
Proposed cryptographic technique will not be made ineligible for evaluation merely for reasons related to IPR policy regarding the ordinary use of the technology. However, if restrictions imposed by IPR are expected to raise serious problems with the use of the technique in the electronic government, the technique may be made deemed ineligible for evaluation.
(9) Company Profile
Write "Company Profile" if the submission is company's proposal.
4.3 Response to Questions for Evaluation
During evaluation process, IPA may pose inquiries aimed at clarifying the comprehensive submission package. It is required that replies to such questions be in Japanese. If the IPA determines that the submitter’s replies are insufficient, it may rule that the proposal is ineligible for evaluation.
5. Evaluation Criteria
The proposed cryptographic technologies will be evaluated from the security and implementation aspects.
5.1 Asymmetric Cryptographic Schemes
(1) Security Evaluation Criteria
First, the proposed cryptographic scheme will be evaluated on the assumption that the cryptographic primitive(s) and auxiliary function(s) satisfy the specified requirements. Then the cryptographic primitive(s) and auxiliary function(s) used in the implementation will be evaluated if they are appropriate for the specified requirements. Recommended parameters and primitives will be evaluated from the point that whether they are vulnerable to well-known attacks or not.
(a) Security evaluation items for the cryptographic scheme
The behavior of the cryptographic scheme when varying the
14

methods and goals of the attacks will be evaluated. For each combination of the methods and goals, the security of the scheme will be considered from aspects such as, if it has a proof of security, if it can be considered to be heuristically secure, and so on.
The method of the attack: active attacks, passive attacks, and other attacks.
The goal of the attack: classified by the degree of damage on the security function.
(b) Security evaluation items for the cryptographic primitive i) Asymmetric cryptographic primitives based on integer factoring problems
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) Asymmetric cryptographic primitives based on discrete logarithm problems
Resistance against well-known attacks (such as Pohlig-Hellman algorithm, square root method, index calculus method, number field sieve method), and other attacks particular to the primitive. iii) Asymmetric cryptographic primitives based on elliptic curve discrete logarithm problems
Resistance against well-known attacks (such as Pohlig-Hellman algorithm, square root method, Frey-Rück algorithm,
Semaev-Smart-Satoh-Araki algorithm, Algorithm using Weil Descent), and other attacks particular to the primitive. iv) Asymmetric cryptographic primitives based on other security reasons
Resistance against well-known attacks and other attacks particular to the primitive.
(2) Evaluation Criteria from Implementation Aspects
The evaluation from implementation point of view will be carried out based on the following items.
- The details of the specification on the proposed scheme should give enough information so that anyone can implement it.
15

- The proposed scheme should be implemented on a normal platform. An extremely special hardware or a huge amount of storage should not be required for the implementation.
-
We will evaluate speed and the amount of storage on a normal platform, especially in software implementation.
-
Special notes that the proposed scheme requires when it is applied to a real system or an application, if exist, will also be evaluated. For example, the scheme may require a privileged center and so on.
-
The size of data block of the proposed scheme or primitive will be evaluated. Also if the proposed scheme requires some data exchanges
(interactions) between two or more parties, the number of data exchanges will be evaluated.
-
If the proposed scheme has already been in public use, its experience of exposure will be evaluated.
5.2 Symmetric Ciphers
(1) Security Evaluation Criteria
(a) Stream Ciphers
Proposed stream cipher will be evaluated resistance against well-known attacks, such as linear cryptanalysis, linear complexity, difdivide-and-conquer attack (refer to [S1]). And, the proposed stream cipher may be evaluated resistance against other attacks and heuristically security. Refers to the following papers [S1]-[S18].
(b) Block Ciphers
The proposed block cipher will be evaluated resistivity against well-known attacks, such as linear cryptanalysis, differential cryptanalysis (see [B3],[B7]), and resistivity against other attacks (such as high order differential cryptanalysis, interpolation attack, impossible differential attack, truncated differential attack, boomerang attack, non-surjective attack, mod n attack,  2 cryptanalysis, related key attack, slide attack). And, the proposed block cipher may be evaluated resistance against other attacks and heuristically security. Refers to the following papers [B1]-[B17].
We will evaluate statistical property, and resistance against side channel attacks (such as timing attack, differential power analysis)(See
16

[B18], [B19]).
(2) Evaluation items for implementation aspects
(i) Evaluation of software implementation
The evaluation on implementation point of view will be carried out based on the following items.
- We will evaluate speed, memory usage (code quantity, work area, etc), and so on.
- We will evaluate the speed of the key scheduler individual for the block cipher.
(ii) Evaluation Criteria for Hardware Implementation Aspects
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: Simulation evaluation results may be also accepted as information that proves the processing speed and resource consumption.
5.3 Hash Functions
(1) Security Evaluation Criteria
The security evaluation will be carried out based on the following items.
- Collision intractability.
- Statistical property.
The proposed Hash function may be evaluated resistivity against other attacks as refers to the following paper [H1]-[H8] and heuristically security.
(2) Evaluation items for implementation aspects
(i)Evaluation of software implementation
The evaluation on implementation point of view will be carried out based on the following item.
-
We will evaluate speed, memory usage (code quantity, work area, etc), optimization level, description language, evaluation platform, and so on.
(ii) Evaluation Criteria for Hardware Implementation Aspects
We will evaluate the process used (Field Programmable Gate-Array, gate array), speed evaluation, resource use quantity (amount of use
17

cell in the case of Field Programmable Gate-Array, the number of gates in case of the gate array etc,) and so on.
Note: Simulation evaluation results may be also accepted as information that proves the processing speed and resource consumption.
5.4 Pseudo-Random Number Generators
(1) Security Evaluation Criteria
Our evaluation views are statistical property 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 refers to
FIPS140-1. We may evaluate resistance against other attacks (refer to
[R1]-[R24]), unpredictability and heuristically security.
(2) Evaluation of software implementation
The evaluation on implementation point of view will be carried out based on the following items.
We will evaluate about speed, memory usage (code quantity, work area, etc), and so on.
6. Remarks
(1) In this project, neither the IPA nor the applicant will pay any fees and reimbursement costs to the other party.
(2) The applicant will bear the cost for cryptography development, document preparation, self-evaluation and other procedure related to submission.
Any cost that will be incurred for responses to questions or requests during the evaluation phase also will be included.
The IPA will bear the cost for evaluation at external evaluators.
(3) If the IPA determines that the submitted information is insufficient for adequate and speedy evaluation, it may rule that the proposal is ineligible for evaluation. When making a submission, provide all the necessary information by referring to Chapter 4, " What Is Required
When Making a Submission".
7. How to Make a Submission
18

(1) Submission Deadline
Candidate nomination package must be arrived by July 14, 2000 by mail.
Address:
Candidate submission packages should be sent to.
Cryptography Technology Office,
IT Security Center, Information-technology Promotion Agency,
Japan
Bunkyo Green Coat Center Office, 2-28-8 Honkomagome,
Bunkyo-ku, Tokyo 113-6591, Japan
(2) Items
Enclose all items listed in Section 4.2, " Submission of Information
Needed for Evaluation,"
The electronic version of the supporting documents should be provided on magneto-optical disk, CD-R, CD-RW, which shall be labeled with the submitter’s name and the name of cryptographic techniques.
(3) For Further Information Contact
FAX +81-3-5978-7518
E-mail crypto-kobo@ipa.go.jp:
19