Chapter 2 Evaluation of Public-key Cryptographic Techniques 2.3.6.4 Description of specifications

The HIME(R) specification contains some flaws and unclear points. At present, reliable HIME(R) specification is not officially available. Therefore, implementability of HIME(R) by third parties and interoperability are not ensured.

Flaws and unclear points in the HIME(R) specification [1] are shown below. • There is an undefined symbol x0 in the decryption procedure.

• Multiple candidates of plaintext may be obtained in the decryption procedure. Although probability of this problem is negligible, it should be mentioned in the specification. • In the message after OAEP padding, the upper 1 bit is fixed to 0. This is not considered

for the implementation using parameters k=1344, k0=128, and k1=128 described in Chapter

3 of the specification, and "n =1088" is described instead of "n =1087". In the decryption procedure in Chapter 3, it should be checked that the most significant bit is 0 as a result of the calculation to find the square root of the ciphertext.

• Although specifications of hash functions G and H are described in Section 3.2 of the specification, a technique different from the method to hash by linking the input and counter value, which is the simplest configuration, is adopted. The rationale in terms of security on which the technique was adopted should be explained. There is another error regarding constant Ci(1< i < 10). '128' should come to the upper side (from the MSB side),

and not come to the lower side (from the LSB side). Also, '64' of constant C should come to the lower side,

• In 3.4 and 3.6 of the specification, random number r for OAEP padding is determined by determining 192-bit random number R first and then taking the upper 128 bits from the hash result SHA-1(R). The rationale for this is not clear.

• The modulus N(= pd

q) is configured with prime numbers p and q that meet the conditions for 'strong prime'. Though imposing the conditions does not bring about any security problem, there is an opinion that the conditions are not necessary.

2.3.6.5 Security evaluation Provable security :

The HIME(R) self-evaluation report [2] describes the security proof that HIME(R) is semantically secure against adaptive chosen-ciphertext attacks (IND-CCA2) in the random oracle model. However, some parts of the security proof have problems. External evaluators also point out this fact.

Problems regarding the security proof in the self-evaluation report are as follows:

• Probability evaluation in the lemma 2.1 of self-evaluation report has a problem and inequality (2) is incorrect. With respect to the primitive of HIME(R), it is not considered that four plaintexts correspond to one ciphertext. Further, an event s ≠ s' (s' is s' used in the query to the encryption oracle; y'=(s'||t')2 _{mod N, and s is s used in the ciphertext}

y=(s||t) 2 mod N attacked by the HIME(R) attacker) is used to derive expression (2). But the reason for this event is not clear.

• It is difficult to understand the derivation of running time of the decryption oracle simulator, because this is not clearly explained.

• The simulator for hash oracles G and H should reply the same answer for the same query. Therefore, the list of past queries should be checked first in response to a query, but this is not described.

2.3 Evaluation of Individual Cryptographic Techniques 79

• For target ciphertext y, if s that satisfies y=(s||t)2 _{mod N is queried to the H oracle, the}

integer factoring machine M with modulus N immediately stops, and s is not recorded in the query list of the H oracle. On the other hand, the success probability of machine M is evaluated with the event where s is recorded in the query list of the H oracle, which will cause discrepancies in discussions unless description of the machine M operation is corrected.

• The symbol * to be returned when the decryption oracle fails simulation is not explained. Additionally, there are several incorrect descriptions.

• Several external evaluators said that proof in the self-evaluation report was hard to read. On the other hand, an evaluator originally configured the proof that HIME(R) is IND-CCA2 in the random oracle model. Also, other evaluators anticipated that the proof in the self-evaluation report can be corrected and that HIME(R) has provable security.

The evaluator who originally configured the proof of security offered the following two results: 1. According to the proving method in the self-evaluation report, the evaluator corrected the

lemma 2.1 in question. Further, the evaluator corrected the evaluation expression for the success probability and for the execution time between IND-CCA2 attacker and modulus N integer factoring, which will finally be obtained on the assumption that the other parts are correct.

2. By applying the proving technique [6] used by Shoup for proving RSA-OAEP+, the security proof was re-structured. Further, configuration of the decryption oracle simulator was changed to the one that more positively uses the Coppersmith algorithm [3], and the execution time of modulus N integer factoring machine was improved. As a result, the oracle simulator was changed from the old type requiring qGqH times of HIME(R) encryption steps to qDqH

times of Coppersmith algorithm execution steps.

However, the proof of security provided by the evaluator was presented in the external evaluation report for the first time. Therefore, it should be noted that the security proof has not been well scrutinized by many researchers. This is because why we were not able to decide that HIME(R) had provable security as of September 2002.

Recommendable parameter size :

In the self-evaluation report, the size of modulus is obtained, where integer factoring calculation volumes for the RSA type integer (pq type) and for the pd

q type integer are equal. Out of the elliptic curve method and the number field sieve method as an integer factoring algorithm, the calculation volume using the algorithm that requires less calculation volume under the specified parameter size, was evaluated. As a result, for the HIME(R) modulus, 1344 bits, 2304 bits, and 4032 bits are recommended when d=2, and 1536 bits, 3072 bits, and 4928 bits are recommended when d=3, corresponding to 1024 bits, 2048 bits, and 4096 bits, respectively, for the RSA modulus. These recommended modulus sizes are considered to be appropriate.

If the HIME(R) modulus is the p2

q type (d=2), the modulus size corresponding to RSA 4096 bits is reduced to 4032 bits. This is a recommended size calculated from the viewpoint of implementation in the case where 1 word is 32 bits. In general, this does not mean that the p2

q type can reserve the same security level with a smaller size than that of the pq type, when the integer is larger than 4096 bits.

80 Chapter 2 Evaluation of Public-key Cryptographic Techniques