Procedure for submitting cryptographic

techniques
(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 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).
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 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 space128 bits or more, number of
states128 bits or more
(ii) 64-bit block cipherskey length128 bits or more
(iii) 128-bit block cipherskey length128 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 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.
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

Item to be submitted

Language

Format

medium

(1)

Cryptographic
Techniques Application

Japanese or English
Document and electronic medium

Form

(2)

Cryptographic
Techniques Overview

(3)

Cryptographic

Cryptographic
Techniques
Application Form

Japanese and English

Document and electronic medium
Japanese and English

Cryptographic
Techniques Overview
No specific format

Techniques

Document and electronic medium

Specifications

(4)

Self Evaluation Report

Japanese and English

No specific format

Document and electronic medium

(5)

Test vector

No specific format
Electronic medium only
(text format)

(6)

Sample code

(7)

Information regarding
the public availability
status of the

Electronic medium only (text format)

No specific format

Japanese

No specific format

Document and electronic medium

"specifications"

(8)

Information regarding
intellectual property
rights

(9)

Company profile

Japanese

No specific format

Document and electronic medium

Japanese or English

Company Profile

Document and electronic medium

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) Submitters name
The submitter should be a person who has a well understanding of
the proposed cryptographic techniques.
Write the submitters name, organization (company) name,
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) Developers 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.
(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 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".

10

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 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.

11

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 key4,096 blocks
Describe a treatment example for one block and the
intermediate result data.
(iii) Hash Functions
Original data sizes512 bits, 1,024 bits, 2,048 bits, 4,096 bits,

12

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

13

by the IPA to confirm that the item 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

14

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 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 submitters 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

15

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
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, p1 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-Rck algorithm, SemaevSmart-Satoh-Araki algorithm, Algorithm using Weil Descent), and
other attacks particular to the primitive.
iv) Asymmetric cryptographic primitives based on other security
reasons

16

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.
- 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

17

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 [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 GateArray, gate array), speed evaluation, resource use quantity
(amount of use cell in the case of Field Programmable GateArray, 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.

18

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 GateArray, gate array), speed evaluation, resource use quantity
(amount of use cell in the case of Field Programmable GateArray, 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

19

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
(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 submitters name and the name of cryptographic
techniques.

20

(3) For Further Information Contact

FAX +81-3-5978-7518
E-mail crypto-kobo@ipa.go.jp:

21