Patent Publication Number: US-8972738-B2

Title: Incorporating data into an ECDSA signature component

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     The present application is a continuation of U.S. patent application Ser. No. 13/070,226 filed Mar. 23, 2011, which issued as U.S. Pat. No. 8,675,869 and is incorporated by reference herein in its entirety. 
    
    
     TECHNICAL FIELD 
     The technology described herein relates generally to elliptic curve cryptography, and particularly to the generation of cryptographic keys and digital signatures. 
     BACKGROUND 
     Elliptic curve cryptography (ECC) is based on the intractability of the discrete logarithm problem within a group over a finite field where the elements of the group are points on an elliptic curve. Cryptographic values generated using ECC schemes, such as the Elliptic Curve Digital Signature Algorithm (ECDSA), may be smaller than those generated using finite-field cryptography schemes, such as the Digital Signature Algorithm (DSA) and integer factorization cryptography schemes, such as the Rivest Shamir Adleman (RSA) algorithm, while still offering the same level of security. Smaller-sized cryptographic values are desirable because they may reduce storage and transmission requirements. ECDSA is described, for example, in “American National Standard for Financial Services ANS X9.62-2005: Public Key Cryptography for the Financial Services Industry—The Elliptic Curve Digital Signature Algorithm (ECDSA)”, Accredited Standards Committee X9, Inc., 2005. DSA and RSA are described, for example, in “Federal Information Processing Standards Publication 186-3 Digital Signature Standard (DSS)”, National Institute of Standards and Technology, June 2009. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The figures of the accompanying drawings are intended to illustrate by way of example and not limitation. Like reference numbers in the figures indicate corresponding, analogous or similar elements. 
         FIG. 1  is a simplified block diagram of an example ECDSA signature scheme for a signer and a verifier; 
         FIG. 2  is a simplified flowchart of an example method to be performed by a signer for incorporating information in a first signature component of an ECDSA signature; 
         FIG. 3  is a simplified flowchart of another example method to be performed by a signer for incorporating information in a first signature component of an ECDSA signature; 
         FIG. 4  is a simplified flowchart of an example method to be performed by a signer for incorporating information in a second signature component of an ECDSA signature; 
         FIG. 5  is a simplified flowchart of another example method to be performed by a signer for incorporating information in a second signature component of an ECDSA signature; 
         FIG. 6  is a simplified flowchart of an example method to be performed by a verifier for extracting information from a signature component of an ECDSA signature; and 
         FIG. 7  is a simplified block diagram of a signer device and a verifier device. 
     
    
    
     DETAILED DESCRIPTION 
     ECC offers an advantage over other cryptographic algorithms, such as DSA and RSA, in that it uses smaller cryptographic values to provide roughly the same level of security. For example, an ECDSA public key that is 160 bits can provide roughly the same level of security as a DSA public key that is 1024 bits. The use of smaller-sized cryptographic values means that related computations require less processing power or less time or both. This makes ECC-based protocols of interest for application environments where resources such as bandwidth, computing power, and storage, are limited. 
     ECC-based protocols rely on the intractability of the elliptic curve discrete logarithm problem. Given publicly-known points G and Q on an elliptic curve E, where point Q is equal to a product of a scalar multiplying factor d and point G, that is Q=dG, it is conjecturally very difficult to determine scalar multiplying factor d. With known algorithms, the computational difficulty of solving this problem increases exponentially with the size of the subgroup generated by G. 
     To implement an ECC-based protocol, all participants must agree on the domain parameters of the elliptic curve. An elliptic curve E defined over a prime finite field    p , that is E(   p ), is defined by elliptic curve domain parameters D=(p, a, b, G, n, h), where p is an odd prime number that represents the number of elements in the field, integers a and b are elements of prime finite field    p  that that satisfy, for example, 4a 3 +27b 2 ≠0 (mod p), (however curves specified by another equation may be suitable), G is a base point on elliptic curve E(   p ) that has order n, where n is defined as the smallest positive prime number such that a product of prime number n and base point G is equal to a point at infinity O, that is nG=O, and cofactor h is defined as a ratio of the number of points #E(   p ) on elliptic curve E(   p ) over prime number n, that is h=#E(   p )/n. (Alternatively, elliptic curve E could be defined over a characteristic 2 finite field    2   m , where m is a prime number that is greater than or equal to one, that is m≦1.) Arithmetic in subgroups of E(   p ) may be written additively, where the sum of two points P and Q is P+Q, and scalar multiplication by an integer k is kP. Further details of existing ECC-based protocols are described in “Standards for Efficient Cryptography SEC1: Elliptic Curve Cryptography”, Certicom Research, Certicom Corp., 2000, and “Standards for Efficient Cryptography SEC2: Recommended Elliptic Curve Domain Parameters version 2.0”, Certicom Research, Certicom Corp., 2000. 
     In addition to satisfying 4a 3 +27b 2 ≠0 (mod p), elliptic curve domain parameters D may need to satisfy other constraints for cryptographic applications. For example, elliptic curve domain parameters D should be generated such that the number of points #E(   p ) on elliptic curve E(   p ) is not equal to the number of elements in prime finite field    p , that is #E(   p )≠p, and such that odd prime p raised to any integer B, where 1≦B≦20, is not equal to one modulo prime number n, that is p B ≠1 (mod n). Elliptic curve domain parameters D should also be generated such that cofactor h is small, specifically such that cofactor h is less than or equal to four, that is h≦4, and preferably such that cofactor h is equal to one, that is h=1. Recommended elliptic curve domain parameters D are published by standard bodies, such as the National Institute of Standards and Technology (NIST). 
     Once participants have agreed on the domain parameters of an elliptic curve, they can implement ECC-based protocols. Examples of ECC-based protocols include the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme, the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme, the Elliptic Curve Integrated Encryption Scheme (ECIES) public-key encryption scheme, and the previously mentioned ECDSA signature scheme. 
     Perhaps the simplest example of an ECC-based protocol is the generation of an elliptic curve key pair. Given valid elliptic curve domain parameters D=(p, a, b, G, n, h) associated with an elliptic curve E, an elliptic curve key pair (d, Q) can be generated using the following procedure. First, an integer d is randomly or pseudo-randomly selected within an interval [1, n−1]. Next, integer d is used in a scalar multiplication of base point G to obtain a new point Q on elliptic curve E, such that Q=dG. Scalar multiplication of a point on an elliptic curve, also known as point multiplication, can be computed efficiently using the addition rule with the double-and-add algorithm or one of its variants. These rules are known to those of ordinary skill in the art. Upon determining point Q, the pair (d, Q) can be used as a key pair, where integer d is a private key and point Q is a public key. While the point multiplication used to calculate public key Q from private key d and base point G is relatively straightforward, the inverse of this operation is extremely difficult. In general, ECC-based protocols rely on the difficulty of this operation. 
     A framework is herein proposed whereby, during the generation of a signed message by a signer, information is incorporated in a signature component of the signed message. This information may be related to, for example, one or more of the signer, the message being signed, and any other information not explicitly sent in the message being signed. In one example, the message being signed could be a certificate and the signer could be a certificate authority. 
     If part of the message to be signed forms a portion of the information to be incorporated in the signature component, the overall size of the signed message can be reduced because the message can be reduced by the part that is incorporated in the signature component. A reduction in the size of the signed message may reduce one or more of the requirements for bandwidth, computing power, and storage. 
     In the following examples, it may be assumed, unless otherwise stated, that all participants in a cryptographic scheme have agreed on suitable domain parameters. For example, for a scheme instantiated using a group of points on an elliptic curve, the participants agree on the corresponding elliptic curve domain parameters D=(p, a, b, G, n, h) as described above. Furthermore, in the case of certificate schemes or digital signature schemes, it may be assumed that all participants are in possession of the relevant public key of the CA or the signer, respectively. It may be assumed, unless otherwise stated, that implicit certificates are generated according to the ECQV implicit certificate scheme. 
       FIG. 1  is a simplified block diagram of an example ECDSA signature scheme involving a signer  100  and a verifier  102 . Signer  100  generates a first signature component r  104  and a second signature component s  106  on a message M  108  to create a signed message M  110 . Signed message M  110  is sent from signer  100  to verifier  102  for verification. 
     While the digital signature schemes described herein are instantiated using a group of points on an elliptic curve, they could alternatively be instantiated using any finite cyclic group, for example, a subgroup of    p , the group of integers modulo a prime number p. In this case, the group order is p−1 and a generator G generates a subgroup of order n, where n divides p−1. Traditionally, arithmetic in subgroups of    p  is written multiplicatively, where the product of two elements P and Q is PQ, and the analogue of scalar multiplication by an integer k is exponentiation, that is, P k . 
       FIG. 2  is a simplified flowchart of an example method to be performed by a signer for incorporating information in a first signature component of an ECDSA signature. A message M is to be signed by a signer, where the signer has a public key K A  that is equal to a product of a private key k A  of the signer and a base point G, that is K A =k A G, where base point G is a base point on elliptic curve E. As an example, message M may be a certificate and the signer may be a certificate authority. However, other messages and signers are contemplated. 
     At  200 , the signer selects information V A  to incorporate in a signature component of message M. In this case, the signature component is a first signature component r. Information V A  may be related to, for example, to one or more of the signer and the message being signed. It is expected that information V A  is from a relatively small set, for example, a set of cardinality &lt;2 32 . In practice, the cardinality is limited by the computational capability of the signer to handle the processing required to determine first signature component r that incorporates information V A . 
     At  202 , the signer generates a random or pseudo-random integer d A  in an interval [1, n−1], where d A  is a private value of the signer that should not be disclosed to other entities. From private value d A , the signer computes a public value R, such that public value R is equal to a product of private value d A  and base point G, that is R=d A G. 
     At  204 , the signer computes first signature component r as the residue of the x-coordinate of public value R modulo prime number n, that is r=R x  (mod n). At  206 , the signer determines whether first signature component r is non-zero, that is r≠0. If this condition is not satisfied, the signer returns to  202 , generating a new private value d A  and computing a corresponding new public value R. The signer then computes a new first signature component r at  204 . If the signer determines at  206  that new first signature component r is non-zero, that is ‘new r’≠0, the signer proceeds at  208  to check whether application of a known function F to new first signature component r results in information V A , that is F(‘new r’)=V A . It is contemplated that the verifications at  206  and  208  may be performed in a different order than that illustrated in  FIG. 2 , while still yielding the same results. 
     Numerous functions F are contemplated. As a simple example, function F could extract a subset of the bits from first signature component r, such as the first 20 bits or the last 20 bits of 160-bit first signature component r, for example. Alternatively, a more complicated function F could be used, such as a decompression algorithm or a function that adds certain bits of first signature component r together. Regardless of how function F is defined, it must be agreed on by all entities involved in the ECC-based protocol if information V A  is to be incorporated in first signature component r and extracted from first signature component r at some later point in time. 
     Returning to the example method illustrated in  FIG. 2 , if the signer determines at  208  that application of function F to new first signature component r does not result in information V A , that is F(‘new r’)≠V A , then the signer returns to  202 , generating a further new private value d A  and computing a further new public value R. Then the signer proceeds at  204  to compute a further new first signature component r from further new public value R. The signer checks at  206  whether further new first signature component r is non-zero and, if so, checks at  208  whether application of function F to further new first signature component r results in information V A . 
     The process of determining a first signature component r by generating a private value d A  and computing a corresponding public value R and first signature component r is repeated until the signer determines at  208  that information V A  can be obtained by applying function F to first signature component r. Upon this determination, the signer proceeds at  210  to compute a second signature component s, according to equation 1:
 
 s=d   A   −1 (Hash( M )+ rk   A )(mod  n )   (1)
 
     where d A   −1  denotes the inverse of private value d A , and Hash is a cryptographic hash function, such as, for example, SHA-1 or any of the SHA2 functions, for example SHA-256. Although not explicitly shown, Hash(M) is converted to an integer for use in equation 1. 
     At  212 , the signer determines whether second signature component s is non-zero, that is s≠0. If this condition is not satisfied, the signer returns to  202 , generating yet another new private value d A  and computing yet another new corresponding public value R. If the signer determines at  212  that second signature component s is non-zero, the signer signs message M with a signature (r, s) at  214  to form a signed message from first signature component r, from second signature component s, and from message M. 
       FIG. 3  is a simplified flowchart of another example method to be performed by a signer for incorporating information in a first signature component of an ECDSA signature. This method includes a more efficient means of determining a signature component that incorporates selected information V A . 
     As described above with respect to  FIG. 2 , the example method illustrated in  FIG. 3  includes selection of information V A  to be incorporated in first signature component r at  200 , generation of private value d A  and corresponding public value R at  202 , and computation of first signature component r at  204 . However, in this method, after computing first signature component r at  204 , the signer proceeds to check at  305  whether application of known function F to first signature component r results in information V A , that is F(r)=V A . If the signer determines at  305  that application of function F to first signature component r does not result in information V A , that is F(r)≠V A , then, rather than returning to  202  to generate a new private value d A  from scratch, the signer proceeds at  306  to increment private value d A  by a constant integer c, that is ‘new d A ’=‘old d A ’+c. Accordingly, public value R is incremented by the product of constant c and base point G, that is ‘new R’=‘old R’+cG. An example for the constant c is the value one, that is c=1, ‘new d A ’=‘old d A ’+1, and ‘new R’=‘old R’+G. The signer then proceeds to compute a new first signature component r at  204 , and to check again at  305  if application of function F to new first signature component r results in V A , that is F(‘new r’)=V A . Incrementing private value d A  and public value R has the advantage that the signer may avoid performing a separate and lengthier computation of public value R, which requires the use of different point multiplication in each iteration. This may reduce the amount of computation time or computation power or both that is required to find a first signature component r that satisfies F(r)=V A . 
     Once the signer determines at  305  that application of function F to first signature component r results in information V A , that is F(r)=V A , the signer proceeds to check at  206  whether first signature component r is non-zero, that is r≠0. If this condition is not satisfied, the signer returns to  202 , generating a new private value d A  and computing a new public value R. If the signer determines at  206  that first signature component r is non-zero, the signer proceeds to compute a second signature component s at  210  according to equation 1, checking at  212  whether second signature component s is non-zero, that is s≠0 and, if so, signing message M with a signature (r, s) to form a signed message at  214  from first signature component r, from second signature component s, and from message M. Although not explicitly described, it is contemplated that the actions at  305  and  206  may be performed in a different order than that illustrated in  FIG. 3 , while still yielding the same results. 
     As an alternative to the example methods illustrated in  FIG. 2  and  FIG. 3 , information V A  could be incorporated in the second signature component s of the ECDSA signature, such that application of function F to second signature component s results in information V A , that is F(s)=V A . 
     For example,  FIG. 4  is a simplified flowchart of an example method to be performed by a signer for incorporating information in a second signature component of an ECDSA signature. As described above with respect to  FIG. 2 , the example method illustrated in  FIG. 4  includes selection of information V A  to be incorporated in a signature component at  200 . In this case, the signature component is a second signature component s. The method includes generation of private value d A  and corresponding public value R at  202 , computation of first signature component r at  204 , and checking at  206  whether first signature component r is non-zero. However, in this method, if first signature component r is non-zero, the signer proceeds at  210  to compute a second signature component s, according to equation 1. Then the signer checks at  411  whether application of function F to second signature component s results in information V A . If the signer determines at  411  that application of function F to second signature component s does not result in information V A , that is F(s)≠V A , then the signer returns to  202 , generating a new private value d A  and computing a new public value R. Then the signer proceeds at  204  to compute a new first signature component r from new public value R. The signer checks at  206  whether new first signature component r is non-zero and, if so, computes a new second signature component s, according to equation 1. The signer then checks at  411  whether application of function F to new second signature component s results in information V A . 
     The process of determining a first signature component r and calculating therefrom a second signature component s is repeated until the signer determines at  411  that information V A  can be obtained by applying function F to second signature component s. Upon this determination, the signer checks whether second signature component s is non-zero, that is s≠0. If this condition is not satisfied, the signer returns to  202 , generating yet another new private value d A  and computing yet another new corresponding public value R. If the signer determines at  212  that second signature component s is non-zero, the signer proceeds to form a signed message at  214  from first signature component r, from second signature component s, and from message M. Although not explicitly described, it is contemplated that the actions at  411  and  212  may be performed in a different order than that illustrated in  FIG. 4 , while still yielding the same results. 
       FIG. 5  is a simplified flowchart of another example method to be performed by a signer for incorporating information in a second signature component of an ECDSA signature. This method includes a more efficient means of determining a first signature component from which a second signature component may be calculated that incorporates selected information V A . As described above with respect to  FIG. 4 , the example method illustrated in  FIG. 5  includes selection of information V A  to be incorporated in second signature component s at  200 , generation of private value d A  and corresponding public value R at  202 , computation of first signature component r at  204 , checking at  206  whether first signature component r is non-zero, computation at  210  of second signature component s according to equation 1, and checking at  411  whether application of function F to second signature component s results in information V A . However, in this method, if the signer determines at  411  that application of function F to second signature component s does not result in information V A , that is F(s)≠V A , then, rather than returning to  202  to generate a new private value d A  from scratch, the signer proceeds at  306  to increment private value d A  by a constant integer c, that is ‘new d A ’=‘old d A ’+c. Accordingly, public value R is incremented by the product of constant c and base point G, that is ‘new R’=‘old R’+cG. An example for the constant c is the value one, that is c=1, ‘new d A ’=‘old d A ’+1, and ‘new R’=‘old R’+G. The signer proceeds to compute a new first signature component r at  204 , to check whether new first signature component r is non-zero at  206 , to compute a new second signature component s at  210 , and to check again at  411  if application of function F to new second signature component s results in V A , that is F(‘new s’)=V A . This is analogous to the incremental method described with respect to  FIG. 3 . 
     Upon determining at  411  that information V A  can be obtained by applying function F to second signature component s, and upon verifying at  212  that second signature component s is non-zero, the signer forms a signed message at  214  as described with respect to  FIGS. 2 ,  3  and  4 . Although not explicitly shown, it is contemplated that the actions at  411  and  212  may be performed in a different order than that illustrated in  FIG. 5 , while still yielding the same results. 
     At this point, the signed message formed at  214  may be verified by any verifier using the ECDSA verification algorithm, which is known to those of ordinary skill in the art. 
     It is contemplated that a signed message may be formed as a reversible combination of first signature component r, of second signature component s, and of message M. For example, it is contemplated that a signature (r, s) could be formed from a concatenation of first signature component r and second signature component s, that is r∥s. and that the message M could be concatenated with the signature (r, s). Alternatively, if first signature component r and second signature component s are of variable length, it is contemplated, for example, that they could be reversibly combined using ASN.1 as described by Brown in “Standards for Efficient Cryptography SEC 1: Elliptic Curve Cryptography”, Certicom Corp., May 21, 2009, and then combined with message M. ASN.1 involves the use of nested bit strings of the form TLV, where T is a short string indicating a type, L is a string indicating the length of next field V, and V is a value which can itself contain other TLVs. Therefore, to reversibly encode first signature component r and second signature component s, it is contemplated that one could use one outer TLV whose tag indicates that it is a sequence of values, and two inner TLVs that are included as part of the outer V field. It is primarily the length indicators that ensure the encoding is reversible. If the signed message is a reversible combination of first signature component r, of second signature component s, and of message M, a verifier may be able to extract each of these elements from the signed message. 
     Alternatively, it is also contemplated a signed message may be formed in such a way that the message M cannot be extracted by a verifier. For example, the signer may form a signed message as a reversible combination of first signature component r, of second signature component s, and of a hash of the message M, that is Hash(M). In this case, the message M is not directly obtainable from the hash value Hash(M) because the hash function is non-reversible. However, because it is the hash value Hash(M) which is used in the actual signing and verification formulas, the verifier may still verify that the signer has signed a message M that hashes to the hash value Hash(M), without being given explicit knowledge of the message M. There are some auction schemes and message commitment schemes that are conducted in this fashion. 
       FIG. 6  is a simplified flowchart of an example method to be performed by a verifier for extracting information from a signature component of an ECDSA signature. At  600 , the verifier receives a signed message which is purported to be signed by a particular signer. The signed message has been formed from a first signature component r, from a second signature component s, and from a message M. At  602 , the verifier extracts first signature component r and second signature component s. Depending on how the signed message has been formed, at  602  the verifier also extracts either message M or hash value Hash(M) from the signed message. At  604 , the verifier extracts information V A  from first signature component r or alternatively from second signature component s by applying the known function F to the relevant signature component. At  606 , the verifier may optionally check whether information V A  complies with digital signature management rules known to or accessible by the verifier. If this condition is not satisfied, the method may end in failure at  608 . If the verification at  606  is successful or is skipped, the verifier may optionally verify at  610  that first signature component r is greater than zero, that is r&gt;0, and may optionally verify at  612  that second signature component s is less than prime number n, that is s&lt;n. If either of these optional verifications fails, the method may end in failure at  606 . 
     It is contemplated that the verifications at  606 ,  610  and  612  may be performed in a different order than that illustrated in  FIG. 6 , while still yielding the same results. 
     If each of the verifications at  606 ,  610 , and  612  is successful or skipped, the verifier proceeds at  614  to compute values u 1  and u 2  according to equations 2 and 3, respectively:
 
 u   1 =Hash( M ) s   −1 (mod  n )   (2)
 
 u   2   =rs   −1 (mod  n )   (3)
 
     where s −1  denotes the inverse of second signature component s, and Hash is the same cryptographic hash function that was used in the calculation of second signature component s in equation 1. As in equation 1, Hash(M) is converted to an integer for use in equation 2. 
     From values u 1  and u 2  computed at  614 , and assuming that the verifier is in possession of an authenticated copy of public key K A  of the signer, the verifier proceeds at  616  to calculate the signer&#39;s public value R according to equation 4:
 
 R=u   1   G+u   2   K   A    (4)
 
     At  618 , the verifier may optionally verify that public value R is not the point at infinity, that is R≠O. If this condition is not satisfied, the method may end in failure at  608 . If the verification at  618  is successful or skipped, the verifier may optionally proceed to verify at  620  that first signature component r is equal to the residue of the x-coordinate of public value R modulo prime number n, that is r=R x  (mod n). If this condition is not satisfied, the method may end in failure at  608 . It is contemplated that the optional verifications at  618  and  620  may be performed in a different order than that illustrated in  FIG. 6 , while still yielding the same results. If both of the verifications at  618  and  620  are successful or skipped, the verifier determines that information V A  and message M are valid at  622 . The actions taken at  606 , at  610 , at  612 , at  618  and at  620  can collectively be referred to as verifying the signature (r, s). 
     In another application, this framework could be modified for general signed messages wherever the cost of bandwidth is considerably more valuable than the computational power of the signer. For example, information V A  could be incorporated in a RSA signature s of a message M, such that application of a known function F to signature s results in information V A , that is F(s)=V A . In this case, s=H(m) d (mod N), where m is padded version of message M, N is a product of a first prime number p and a second prime number q, d is a coprime of a product (p−1)(q−1), and H is a randomized encoding method like the Rivset-Shamir-Adleman Signature Scheme with Appendix—Probabilistic Signature Scheme (RSASSA-PSS) as described by Kaliski in “Raising the Standard for RSA Signatures: RSA-PSS”, RSA Laboratories, Feb. 26, 2003 (http://www.rsa.com/rsalabs/node.asp?id=2005). 
     Information V A  could also be incorporated in cryptographic values of other signature schemes. For example, information V A  could be incorporated in either a first signature component e or a second signature component s of any Schnorr-based signature scheme as described by Menezes et al. in Section 11.5.3 of “Handbook of Applied Cryptography”, CRC Press, 1997. Briefly, this technique employs a subgroup of order q in    p *, where p is some large prime number. First signature component e may be obtained by hashing of a concatenation of a message M to be signed and a public value r, that is e=Hash(M∥r), where public value r depends on a private integer value k of the signer, a generator a of    p *, and prime number p according to r=a k  (mod p). Second signature component s may be obtained from first signature component e, a private value a of the signer, private value k, and integer q according to s=ae+k (mod q). A public value y of the signer satisfies y=a a  (mod p). It is also contemplated that information V A  could be incorporated in either a first signature component r or a second signature component s of any El Gamal-based signature scheme. 
     There may be cases where function F, when applied to a particular value (such as a first signature component r or a second signature component s), may never yield selected information V A . In these cases a hash function could be applied to the particular value in question prior to applying function F. For example, application of function F to first signature component r at  208  in  FIG. 2 , at  305  in  FIG. 3 , or at  604  in  FIG. 6 , could be replaced by application of function F to a hash of first signature component r, that is F(Hash(r)). Similarly, application of function F to second signature component s at  411  in  FIG. 4  or in  FIG. 5 , or at  604  in  FIG. 6 , could be replaced by application of function F to a hash of second signature component s, that is F(Hash(s)). This would provide the CA or signer with a new set of values for comparison with information V A , which may improve the likelihood that a match will be found, that is F(Hash(B A ))=V A  or F(Hash(r))=V A  or F(Hash(s))=V A . However, it should be noted that the other entities involved in the protocol must also be aware when a hash function is being used. Alternatively, information V A  could be selected so as to avoid the degenerate cases where application of function F never yields information V A . 
       FIG. 7  is a simplified block diagram of a signer device  700  and a verifier device  730 . 
     Signer device  700  is able to perform one or more of the example methods illustrated in  FIGS. 2 ,  3 ,  4  and  5 . Signer device  700  comprises a processor  702  which is coupled to a memory  704  and to a communication interface  706 . Signer device  700  may contain other elements which, for clarity, are not shown in  FIG. 7 . 
     Verifier device  730  is able to perform the example method illustrated in  FIG. 6 . Verifier device  730  comprises a processor  732  which is coupled to a memory  734  and to a communication interface  736 . Verifier device  730  may contain other elements which, for clarity, are not shown in  FIG. 7 . 
     Communication interfaces  706  and  736  may be wired communication interfaces or wireless communication interfaces. For example, communication interfaces  706  and  736  may be Universal Serial Bus (USB) interfaces, Ethernet interfaces, Integrated Services Digital Network (ISDN) interfaces, Digital Subscriber Line (DSL) interfaces, Local Area Network (LAN) interfaces, High-Definition Multimedia (HDMI) interfaces, Digital Visual Interfaces (DVIs), or Institute of Electrical and Electronics Engineers (IEEE) 1394 interfaces such as i.LINK™, Lynx SM  or Firewire®. Alternatively, communication interfaces  706  and  736  may be Wireless Local Area Network (WLAN) interfaces, short-range wireless communication interfaces such as Wireless Personal Area Network (WPAN) interfaces, or Wireless Wide Area Network (WWAN) interfaces. 
     Each of memories  704  and  734  is able to store publicly-known parameters  710 , including a public key K A  of signer device  700  as well as elliptic curve domain parameters D, function F, and hash function Hash that have been agreed on by signer device  700  and verifier device  730 . 
     Memory  704  of signer device  700  is able to store code  708  that, when executed by processor  702 , results in one or more of the example methods illustrated in  FIGS. 2 ,  3 ,  4  and  5 . Memory  704  may also store applications (not shown) installed in signer device  700  to be executed by processor  702 . 
     Memory  704  is able to store a private key k A    712  of signer device  700  that corresponds to public key K A  of signer device  700 , as well as selected information V A    714 , a private value d A    716 , and a public value R  718 . Memory  704  is also able to store a first signature component r  720 , a second signature component s  722 , and a message to be signed M  724 . 
     As denoted by arrow  726 , first signature component r  720 , second signature component s  722 , and message M  724  are able to be sent to verifier device  730  as a signed message, where they may be stored in memory  734  of verifier device  730 . While not explicitly shown, the signed message may be sent from signer device  700  via communication interface  706  and may be received by verifier device  730  via communication interface  736 . Although not explicitly shown in  FIG. 7 , as described above, the signed message may alternatively comprise a hash of message M, that is Hash(M), instead of message M  724  itself. 
     Memory  734  of verifier device  730  is able to store code  738  that, when executed by processor  732 , results in the example method illustrated in  FIG. 6 . Memory  734  may also store applications (not shown) installed in verifier device  730  to be executed by processor  732 . 
     Memory  734  is further able to store value u 1    740 , value u 2    742 , information V A    714 , and public value R  718  of signer device  700 , where these values may be determined upon receipt of the signed message from signer device  700 . 
     Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.