Security evaluation

• Elliptic curve discrete logarithm problem

ECIES is a public-key cryptosystem depending on the difficulty of the elliptic curve discrete logarithm problem. Presently, there are various known attacks against the elliptic curve discrete logarithm problem. With regard to ECIES, elliptic curve parameters, to which known attacks cannot be applied for practically valid number of bits, are specifically presented in the SEC 2 document. (Note that these are recommended parameters and the use of other elliptic curves is not permitted.) The elliptic curve consists of an elliptic curve selected at random in a verifiable form and an elliptic curve called Koblitz curve (see 2.3.2.4 "Security of Koblitz curve"). Since the Koblitz curve can be processed at a high speed and has a track record of use, it is included in SEC 2. However, as it is a curve in a limited class, attention should be paid to the possibility that attacks specific to that class may emerge (see 2.3.2.4 "Security of Koblitz curve").

• Differences between ECIES [5] and ECIES [1][2][3] having provable security In the specifications of ECIES [5], there are some descriptions different from the schemes provided in papers [1][2][3] on which the specifications of ECIES are based. Such differences are: (i) Input data to KDF, and (ii) selection of MK (key used for MAC). More precisely, the differences are distinguished as follows (where the Diffie-Hellman shared key obtained from base points R and Q on the elliptic curve is represented as DH(R,Q):

Differences between ECIES [5] and ECIES [1][2][3] (i) Input data to KDF:

In ECIES [5], x(DH(R,Q)(the x-coordinate of DH(R,Q)) is used as input data to KDF. In [1], R and DH(R,Q) are used. In [2] and [3], DH(R,Q) is used.

(ii) Selection of MK (key used for MAC)

For use of EK and MK, ECIES [5] uses K=EK||MK, while in [1], [2], and [3], K=MK||EK is used.

For schemes in papers [1], [2], and [3], it has been proven that they are semantically secure against adaptive chosen-ciphertext attacks (IND-CCA2) if the Oracle Diffie-Hellman assumption is correct, and ENC and MAC are secure in the standard model.

On the other hand, a full evaluator [6] in 2002 proved that the schemes described in [1], [2], and [3] are semantically secure against adaptive chosen-ciphertext attacks (IND-CCA2) if the Gap-Diffie-Hellman assumption is correct, and ENC and MAC are secure in the random oracle model that assumes the KDF part as a random function. However, in ECIES where provable security is shown here, R and x(DH(R,Q)) are used as the input data to KDF, and K=MK||EK is used for taking EK and MK.

76 Chapter 2 Evaluation of Public-key Cryptographic Techniques

Further, in [9], it has been proven that the scheme is semantically secure against adaptive

chosen-ciphertext attacks (IND-CCA2), if ENC and MAC are secure in the generic group model. However, ECIES that indicates provable security here uses DH(R,Q) as input data to KDF and uses K=EK||MK for taking EK and MK. As stated in [9], attention should be directed to the adequacy of discussion on the generic group model for ECIES.

• Security of ECIES

As mentioned above, there are differences in (i) input data to KDF, and in (ii) selection of MK (key used for MAC), between ECIES [5] and papers [1], [2], and [3]. As pointed out in [8], these differences have brought about the following vulnerability in the security of ECIES [5]:

(i) Vulnerability due to the difference in the input data to KDF:

For input to KDF, only the data of the x-coordinate of a point on the elliptic curve that is the Diffie-Hellman shared key, is used. Therefore, the security proof of IND-CCA2 is not ensured, which will actually allow a chosen-ciphertext attack. (For details, see [8].) (ii) Vulnerability due to the difference in taking MK (key used for MAC)

If XOR is used as ENC and the use of a plaintext with a variable length is permitted, MK (key for MAC) is dependent upon the length of the plaintext as well. Therefore, the security proof of IND-CCA2 is not ensured, which will actually allow a chosen-ciphertext attack. (For details, see [8].)

References

[1] M. Abdalla, M. Bellare and P. Rogaway, "DHAES: An encryption scheme based on the Diffie-Hellman problem", submission to IEEE P1363a, September, 1998.

[2] M. Abdalla, M. Bellare and P. Rogaway, "The oracle Diffie-Hellman assumptions and an analysis of DHIES", Topics in Cryptology, - CT-RSA 2001, LNCS 2020, pages 143-158, Springer-Verlag, 2001.

[3] M. Abdalla, M. Bellare and P. Rogaway, "DHIES: An encryption scheme based on the Diffie-Hellman problem", full version of [4] [2], September, 2001. Available at http://www-cse.ucsd.edu/users/mihir/

[4] M. Bellare and P. Rogaway, "Minimizing the use of random oracles in authenticated encryption schemes", Information and Communications Security, LNCS 1334, pages 1-16, Springer-Verlag, 1997.

[5] Certicom Research, Standards for Efficient Cryptography Group (SECG), September 20, 2000. Version 1.0. Available at http://www.secg.org/

[6] CRYPTREC Evaluation Reports, CRYPTREC, 2002.

[7] IEEE P1363a/D9 - standard specifications for public key cryptography: Additional techniques, June 2001. Draft version 9.

[8] V. Shoup, "A proposal for an ISO Standard for public key encryption", Version 2.0, September 17, 2001. Version 2.1, December 20, 2001. Available at http: //shoup.net/papers/

[9] N. P. Smart, "The exact security of ECIES in the generic group model", Cryptography and Coding 2001, 2001.

2.3 Evaluation of Individual Cryptographic Techniques 77

2.3.6 HIME(R)

2.3.6.1 Cryptographic technique evaluated

• "Cryptographic Technique Specification: HIME(R) Cryptography" submitted to 2002 CRYTREC, Hitachi, Ltd.

2.3.6.2 Technical overview

HIME(R) a public key cryptosystem intended for confidentiality. With a modular square function (Rabin scheme) as a primitive using N=pd

q modulus, the scheme is configured using OAEP padding [5]. The submitter stated that the design policy of HIME(R) was to have provable security in the random oracle model on the assumption of computational difficulty for the integer factoring problem, to make the encryption and decryption speeds high, and to have a plaintext space equivalent to or larger than that of RSA-OAEP.