Chapter 2 Evaluation of Public-key Cryptographic Techniques User's initial settings

Input: (p,q,g) Parameters common to systems Output: x User's private key (integer)

y User's public key (y ∈ Z*p)

Processing steps:

1. Randomly generate an integer x that is equal to or smaller than 1, and equal to or greater than q-1.

2. Calculate y=gx _{mod p.}

Secret information sharing processing

The user U starting secret information sharing must perform the following process. The user V, the other party, must perform similar process (swap U and V).

Input: (p,q,g) Parameters common to systems xU Private key (integer) of user U

yV Public key (yV ∈ Z*p) of user V

Output: "Failure" or Z Processing steps:

1. Calculate Z= yVXU mod p.

2. Output "Failure" if Z=1. Otherwise, output Z.

2.3.8.4 Security evaluation

a) The schemes described in the previous section have a very simple basic form. Since there are many protocol variations in the Diffie-Hellman method, evaluation of individual protocols is required. (Examples of protocols actually used: RFC2631, ISO 11770-3, Oakley, PGP) The targets of evaluation are basic schemes only.

b) If only passive attacks are assumed, the basic part of a secret sharing protocol is reduced to the Diffie-Hellman problem. In the sense that the shared secret information cannot be distinguished from random bit strings, it is reduced to the Decisional Diffie-Hellman problem by limiting the range or other means.

c) In the scheme where shared secret information is used as a session key, there are various factors that affect the security. The number of combinations of these factors is enormous, so it is difficult to evaluate the security for every combination. The following are some examples of the factors to be taken into consideration.

1) Whether pair of keys is static or ephemeral

2) Whether the correspondence between public key and entity is guaranteed or not (nocert/cert). Moreover, whether it is guaranteed that the entity has a corresponding private key (strongcert). 3) Whether public key is signed or not when it is exchanged (unsigned/signed).

d) In the scheme where shared secret is used as a session key, the use in the form described in the previous section may lead to problems described in e). Therefore, it is required at least to "provide a means to secure the correspondence between the public key and the entity, and if used as a session key, the public key to be exchanged should be ephemeral."

2.3 Evaluation of Individual Cryptographic Techniques 85

e) The following are examples of combinations in question and specific attacks: 1) When both users' keys are static

Fixed-session-key attack: Since the session key is static, the use in counter mode reveals the secret if the same Vernam pad is used for each session.

2) When the correspondence between private key and public key is not guaranteed (not strongcert) Unknown key-share attacks: The attacker pretends as if he/she is communicating by disguising that user's public key is his/her public key, thus invading each user.

3) Others

Captured session key attacks: When at least either one is a static key, once the session key is revealed, the same session key will be used continuously afterwards.

Key-translate attacks: In the case of nocert/unsigned, multiplying the key by α allows sharing of different keys.

Reveal attacks: If secret coin (confidential information) is revealed during public WS operation, other secret information is affected (lack of forward secrecy).

Attacks intrinsic 2-flow AKE (Authenticated Key-Exchange protocols): When there are only two flows and the second flow is independent of the first, this will cause problems that there is no forward secrecy in the strong-corruption model or no A -to-B/B-to-A authentication, etc. f) Making improvements, for example, by using signatures for the public key can solve some of

problems.

References

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

[2] ANSI X9.42-2001, "Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography", American National Standards Institute, 2001.

2.3.9 PSEC-KEM

2.3.9.1 Cryptographic technique evaluated

• NTT Information Sharing Platform Laboratories, "PSEC-KEM Specifications" (May 14, 2002) [4]

2.3.9.2 Technical overview

PSEC-KEM is a key encapsulation mechanism (KEM) based on an elliptic curve discrete logarithm problem. KEM can be used as a component of hybrid encryption that is a means to create a public-key cryptosystem for confidentiality. The hybrid encryption has been studied based on the algorithm [5] proposed by Mr. Victor Shoup at ISO/IEC JTC1/SC27/WG2, and consists of a combination of the following:

• KEM with a public-key cryptosystem based provable security

• Data Encapsulation Mechanism (DEM) with a symmetric-key cryptosystem based provable security

86 Chapter 2 Evaluation of Public-key Cryptographic Techniques

We call the hybrid encryption as KEM-DEM cryptosystems. If KEM and DEM fulfill their provable security defined by each, the provable security for KEM-DEM cryptosystems is ensured. Therefore, KEM-DEM cryptosystems gather attention as a method with provable security, that is highly independent (flexible) between public key cryptosystem and symmetric key cryptosystem.

When using PSEC-KEM, CRYPTREC recommends that the elliptic curve parameters should be selected using the elliptic curve parameter selection method specified by SECG*11 _{(Standards for Efficient}

Cryptography Group). On selection of the elliptic curve parameters, see 2.5.3.

In 2001, PSEC-KEM was submitted to CRYPTREC 2001 (key exchange category) as the revision of PSEC-2 submitted to CRYPTREC 2000 (public key cryptosystems for confidentiality category). The Public-Key Cryptography Subcommittee decided to treat PSEC-KEM as a new submission.

2.3.9.3 Technical specifications

Specifications (overview) of PSEC-KEM are as follows. For details, refer to its specification document. PSEC-KEM consists of a key generation algorithm G, an encryption algorithm E, and a decryption algorithm D, which are described below.

Key generation algorithm G

First, key generation algorithm G determines an elliptic curve E and the base point P using the elliptic curve parameter selection method SEC 1 specified in SECG. Then, public key PK and secret key SK are generated by the following process:

1. Generate a random number s ∈ {0, ... ,p-1}, where p is the order of base point P. 2. Calculate W=sP.

3. Select a proper key derivation function KDF. The KDF can generate a hash function value with an arbitrary length. The PSEC-KEM specifications recommends to use MGF (Mask Generation Function) [5] as KDF based on a hash function SHA-1.

4. Select a proper bit length hLen.

5. Output public key PK =(E,W,KDF,hLen). 6. Output secret key SK =(s,PK).

The PSEC-KEM specification recommends that the p's bit length be 160 and hLen be 160.

Encryption algorithm E

The encryption algorithm E inputs PK and outputs ciphertext C and keyLen-bit shared key K. 1. Generate a hLen-bit random number r.

2. Generate a (pLen+128+keyLen)-bit G = MGF(032||r), where 032 is a bit string representing

32-bit 0.

3. Assuming G=t||K, divide G into (pLen+128)-bit t and keyLen-bit K. 4. Calculate α =t mod p.

5. Calculate Q=αW,C1=αP.

2.3 Evaluation of Individual Cryptographic Techniques 87

6. Generate hLen-bit H=MGF(132 || C1||Q), where 132 is a bit string representing 32-bit 1.

7. Generate hLen-bit C2=r⊕ H.

8. Output ciphertext C=(C1, C2) and shared key K.

The PSEC-KEM specification recommends that the keyLen's bit length be 256.

Decryption algorithm D

The decryption algorithm D inputs SK and ciphertext C, and outputs keyLen-bit shared key K (or "invalid").

1. Divide ciphertext C into C=(C1, C2).

2. Calculate Q = sC1

3. Generate hLen-bit H=MGF(132 || C1||Q), where 132 is a bit string representing 32-bit 1.

4. Generate hLen-bit C2= r⊕H.

5. Generate (pLen+128+keyLen)-bit G = MGF(032||r), where 032 is a bit string representing 32-bit 0.

6. Assuming G=t||k, divide G into (pLen+128)-bit t and keyLen-bit K. 7. Calculateα=t mod p.

8. Verify whether C1=αP stands.

9. If C1=αP, output shared key K. (Otherwise, output "invalid".)

2.3.9.4 Security evaluationε

Definition of KEM security

Definition of IND-CCA2 (semantic security against adaptive chosen-ciphertext attacks) of KEM is slightly different from the definition of IND-CCA2 of a public-key cryptosystem. IND-CCA2 of KEM is defined as follows:

"When ciphertext C and bit string K of KEM are given, any attacker A (in polynomial time) cannot identify whether bit string K is the correct shared key (Key) obtained by KEM or a random key at a significant probability by using the decryption oracle."

The above definition means that attackers using the decryption oracle cannot decode any part of the shared-key information from the ciphertext in polynomial time.

Security evaluation of PSEC-KEM

PSEC-KEM has the provable security of IND-CCA2 as KEM described above on the assumption of the difficulty of EC-CDH in the random oracle model.

Theorem 10: Assume an attacker in IND-CCA2 against PSEC-KEM as A. Assume the success