Evaluation of Public-key Cryptographic Techniques
50 Chapter 2 Evaluation of Public-key Cryptographic Techniques Differences between ECDSA in SEC 1 and ANSI X9
The same ECDSA signature scheme is used for both ECDSA in SEC 1 and ANSI X9.62, however, there are some differences in the detailed specifications. The major differences of specifications between the two are:
• Selectable range of elliptic curve parameter • Hash process for a message in the signature • Pseudo-random number generator
In ECDSA in SEC 1, selectable range of the elliptic curve parameter is limited. The bit sizes of field order are limited to 8 types for each of the field Fp and F2m. Among them, 2 types each with the field
order smaller than 160 bits are included. Furthermore, recommended specific elliptic curve parameters are listed in the SEC2 document. In the SEC2 document, the curve selected verifiably at random and the Koblitz curve, based on multiple field sizes, are recommended with regard to the elliptic curves with characteristic p and characteristic 2. The approach to select a curve at random in a verifiable manner is described in ANSI X9.62. On the other hand, in ANSI X9.62, the field size is not limited except that the base point order n is larger than 2160. ANSI X9.62 simply lists elliptic curve parameters as samples in
the Appendix, and includes no recommendable specific curve parameters. However, the Appendix shows elliptic curve parameter selection procedures; a scheme to select parameters verifiably at random and other schemes (including Weil method and CM method).
Regarding hash processing of a message in the signature, ECDSA in SEC 1 specifies that the left-most log2 n bit of h(M) is used for the elliptic curve parameter with the base point order n (log2 n < 160).
In other cases, ECDSA in SEC 1 and ANSI X9.62 use the same hash processing.
With regard to the pseudo-random number generator, ECDSA in SEC 1 describes no specific algorithms. In contrast, ANSI X9.62 specifies the method described in FIPS186.
2.3.2.4 Evaluation of security Security of primitives
In ECDSA, the security of primitives is based on the elliptic curve discrete logarithm problem. See "Section 2.4.3 Elliptic Curve Discrete Logarithm Problem" for the evaluation results of this problem. Parameters with field order size smaller than 160 bits are included in the parameters specified in ECDSA in SEC 1 [3]. From the standpoint of security, parameters with field order size of 160 bits or more should be used.
Provable security
For ECDSA, provable security in the random oracle model has not been verified. On the other hand, Brown has given the proof of security in a generic group model (also called generic model) that is different form the random oracle model [2]. The generic group model is a virtual model on the
assumption that expression of group elements is given at random. In other words, this model assumes a generic group oracle that defines the expression of group elements from the additive group Zn to the bit
string set S ∈ {0,1} *, at random. It also assumes that the operation of group elements is executed by asking the generic group oracle. In this model, Brown emphasized that ECDSA is existentially unforgeable against adaptive chosen-plaintext attacks assuming the hash function is collision-free. Another proof to the Brown's theorem is shown in Reference [5].
2.3 Evaluation of Individual Cryptographic Techniques 51
However, whether the proof of security in the generic group model gives significance to the security of ECDSA is negatively considered [5]. This is because a seemingly conflicting situation arises, where 'malleable' properties have been found in ECDSA but 'non-malleability' can be proven in the generic group model. In this context, 'malleable' means a property that allows a third party to create another signature (r', s') for message m from the signature (r, s) for the same message m. In ECDSA, (r,-s) is a valid signature given the signature (r,s) and therefore the above-mentioned properties can be verified. The reason why such a confliction arises is that function σ defining the expression of group elements cannot be regarded as random and has a special algebraic structure.
As described above, regarding provable security of ECDSA, it is considered that security proof in the generic group model gives very little significance.
Vulnerability originating from reduction function
The reduction function f(R) of ECDSA that maps point R = (x,y) on an elliptic curve to the element r in Z/nZ has a property of f(R) = f(-R). Specifically, f(R) = x mod n. The following two types of vulnerability have been pointed out using this property [5].
• duplicate signature • malleability
Malleability is the property described in the section of provable security given above. Although attention should be paid to this property, it will have almost no problem in the actual situation. Therefore, duplicate signature is explained below. For ECDSA, a malicious user can issue duplicate signatures. Duplicate signatures mean two pairs of signatures (m1,r,s) and (m2,r,s), where m1≠ m2.
The malicious user must execute the illegal key generation procedure. The user defines a secret key d so that the ECDSA verification sR = h(m)G + r(dG) will hold in two cases; R = kG, r = f(R), e1 = h(m1) and
R' = -R = -kG, r = f(R') = f(-R), e2 = h(m2). When d in the simultaneous equations is solved,
d = -(e1+e2)/(2r) mod n. This d becomes a key that can issue duplicate signatures for messages (m1,m2).
However, the forger will also have a risk because the secret key d will be known by third parties once the duplicate signatures are issued.
This vulnerability may lead to attacks against non-repudiation that is a basic feature of signature, and may cause problems depending on the environment where such signatures are used. In an example of vulnerable operation, the signature recipient saves signature (r,s) only, but does not save message m. In this case, the signer (forger) may replace the message m with m' that becomes duplicate signatures. Against this illegal action, the message m as well as the signature must be saved together. Alternatively, the message hash result e = h(m) should be saved along with the signature. With such operational precautions, problems regarding duplicate signatures are avoidable. Another preventive measure can be taken by generating and distributing a user key using a trusted third-party.
There is an example of a similar attack against DSA using the illegal key generation phase [6]. In DSA, if (m1,m2) that satisfies h(m1)= h(m2) mod q is selected, and then a set of (m1,m2,q) is defined by
repeatedly checking to see if the difference becomes a prime number q with a specified size, the signature for m1 is also the signature for m2. In DSA, since the attack requires an illegal action to public key
generation, verifiable key generation steps can be a solution. Since the illegal action of duplicate signature in ECDSA includes the user private key generation steps, it should be noted that the countermeasure in DSA cannot be used as is.
DSKS (duplicate-signature key selection) characteristic
In ECDSA, if base point changes are permitted, valid signers for the same signature can be added through illegal key generation.
52 Chapter 2 Evaluation of Public-key Cryptographic Techniques
The attacker generates a random number c between 1 and n-1 for the signature (r,s) to a given message m, its elliptic curve parameter T (including base point G), and public key Q, and then calculates t = s-1
(h(m) + rc) mod n (≠ 0), X = s-1h(m)G + s-1rQ, G' = t-1X, Q′ = cG' Then, (r,s) becomes a valid signature to the message m, elliptic curve parameter T (however, only base point is changed to G'), and public key Q'. Actually, X'=s-1 (h(m) G' + rQ′) = s-1(h(m) G' + rcG') = tG'= X .
As a method to prevent this illegal action, the base point G should be common throughout the system or a trusted third-party should generate base points.
Verification of elliptic curve parameters
There is an opinion that it should be verified that elliptic curve parameters, which are system parameters used in ECDSA, have no trapdoors.
Related to this matter, ECDSA in SEC 1 describes a method for validating the elliptic curve parameters by checking conditions for avoiding attacks against the elliptic curve discrete logarithm problem. The presented checking conditions are satisfactory at present, but new attacks may be found in the future. There is a potential threat that new attacks are used as a trapdoor, so attention should be paid to the trend of attacks.
Pseudo-random number generator
ANSI X9.62 [2] specifies the pseudo-random number generator described in FIPS186-2(DSS). Since k = rand mod n generated by this pseudo-random number generator is not uniformly distributed with [1,n-1], Bleichenbacher pointed out an attack to DSA using this property. As a countermeasure against this attack, NIST presents a revision of the pseudo-random number generator in FIPS186-2 Change Notice. Specifically, by using double-size random number data linking two random numbers rand and rand', k is generated as k = (rand||rand') mod n. Presently, the specification change of the
pseudo-random number generator for ECDSA has not been proposed. However, similar attacks may be applied to the pseudo-random number generator in ECDSA, so attention should be paid to the trend. Regarding this matter, see "2.3.1 DSA" as well.
References
[1] NSI X9.62, "Public Key Cryptography for the Financial Services Industry:
The Elliptic Curve Digital Signature Algorithm (ECDSA)", American National Standard for Financial Services, 1998.
[2] .Brown, "The exact security of ECDSA", Technical Report CORR 200-34, Dept. of C&O, University of Waterloo, 2000. Available at http://www.cacr. math.uwaterloo.ca
[3] Standards for Efficient Cryptography, "SEC 1:Elliptic Curve Cryptography", Certicom Research, Ver.1.0, September 2000, available from http://www.secg.org/secg_docs.htm [4] Standards for Efficient Cryptography, "SEC2: Recommended Elliptic Curve Domain
Parameters", Certicom Research, Ver.1.0, September 2000, available from http://www.secg.org/secg_docs.htm
[5] .Stern, D.Pointcheval, J.M.-Lee, and N.P.Smart, "Flaws in Applying Proof Methodologies to Signature Schemes", Advanced in Cryptology – CRYPTO2002, Lecture Notes in Computer Science 2442, Springer-Verlag, pp.93–110, 2002.
[6] .Vaudenay, "Hidden Collisions on DSS", Advances in Cryptology – CRYPTO'96, Lecture Notes in Computer Science 1109, Springer-Verlag, pp.83–88, 1996.
2.3 Evaluation of Individual Cryptographic Techniques 53
2.3.3 ESIGN signature
2.3.3.1 Cryptographic techniques evaluated
• "ESIGN Specifications", submitted to 2001 CRYPTREC, Nippon Telegraph and Telephone Corporation [10]
• "TSH-ESIGN: Efficient Digital Signature Scheme Using Trisection Size Hash", T. Okamoto, E. Fujisaki, H. Morita, Submission to P1353a [12]
2.3.3.2 Technical overview
ESIGN signature is a cryptographic scheme intended for signature. ESIGN signature has multiple specifications, and they are classified into two categories; one is specifications where no provable security is presented, and the other presents provable security that ensures existential unforgeability against single-occurrence adaptive chosen-message attacks, under the assumption of the difficulty of the approximate e-th root problem and under the random oracle model.
The former is called ESIGN [10]*5, while the latter is called TSH-ESIGN [12, 6]. Unless otherwise
specified, description in the following sections means common evaluation for two types of ESIGN signature.
2.3.3.3 Technical specifications
Specification changes of ESIGN signature were made several times, so there are several versions other than the CRYPTREC submission version [10]. Differences in specifications are summarized in Table 2.5. Recommended parameters are increasing year by year. As security theory research develops, ESIGN signature has been modified into a scheme that can verify the truly strongest security in signature schemes (under a certain assumption).
*5 A scheme described in Clause 3, No.4 in Guideline on Authorization of Specific Certification Jobs based on the Guidelines on the Law concerning Electronic Signatures and Certification, Notification No.2, the Ministry of Public Management, Home Affairs, Posts and Telecommunications, the Ministry of Justice, and the Ministry of Economy, Trade and Industry in 2001 (Official Gazette Extra Edition No.86, April 27, 2001). Deleted at the time of amendment of Notification No.13, the Ministry of Public Management, Home Affairs, Posts and Telecommunications, the Ministry of Justice, and the Ministry of Economy, Trade and Industry in 2002 (Official Gazette Extra Edition No.3492, November 21, 2001).
54 Chapter 2 Evaluation of Public-key Cryptographic Techniques
Table 2.5 Various ESIGN signatures
Recommended parameter Provable security Scheme described in the Guidelines
on the Law concerning Electronic Signatures and Certification Services
|n|≥1024,e≥8 CRYPTREC 2001 |n| = 1152, e = 1024 None at present CRYPTREC 2000 IEEE P1363a |n|≥960,e≥8 – TSH-ESIGN (Submission to NESSIE) –
Provided (existential unforgery against single-occurrence adaptive chosen-message attacks under the assumption of n=p2q type
integer factoring, assumption of approximation of e-th root, and random oracle model)
Note
In NESSIE [8], ESIGN-D and ESIGN-R [4, 5] that may have the provable security against ordinary adaptive chosen-message attacks has also been evaluated. But both are not included in the NESSIE portfolio.
ESIGN and TSH-ESIGN have common specifications for the primitive part. The overview is as follows:
Key generation
Input: k Security parameter (positive integer) e Exponent of 8 or larger (positive integer) Output: PK Public key (n, k, e)
SK Private key (p, q)
Step 1 Choose two prime numbers of k bit, p and q.