idnits 2.17.1 draft-struik-secdispatch-verify-friendly-ecdsa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 1019 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'FIPS-186-4' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'SEC1' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'SEC2' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'ECC' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'GECC' is defined on line 493, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-4' == Outdated reference: A later version (-23) exists of draft-ietf-lwig-curve-representations-20 ** Downref: Normative reference to an Informational draft: draft-ietf-lwig-curve-representations (ref. 'I-D.ietf-lwig-curve-representations') == Outdated reference: A later version (-13) exists of draft-ietf-openpgp-crypto-refresh-03 ** Downref: Normative reference to an Informational RFC: RFC 8032 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 sedispatch R. Struik 3 Internet-Draft Struik Security Consultancy 4 Intended status: Standards Track July 12, 2021 5 Expires: January 13, 2022 7 ECDSA Signatures in Verification-Friendly Format 8 draft-struik-secdispatch-verify-friendly-ecdsa-00 10 Abstract 12 This document specifies how to represent ECDSA signatures so as to 13 facilitate accelerated verification of single signatures and fast 14 batch verification. We demonstrate that this representation 15 technique can be applied retroactively by any device (rather than 16 only by the signer), thereby facilitating transitioning to always 17 generating ECDSA signatures in this way, without changing 18 standardized ECDSA specifications with instantiations with prime- 19 order curves. This facilitates verifying devices to reap the 20 significant speed-up potential (ranging from ~1.3x to ~6x) fast 21 verification techniques afford. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 13, 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Fostering Fast Verification with ECDSA . . . . . . . . . . . 2 66 2. Review of ECDSA and ECDSA* . . . . . . . . . . . . . . . . . 3 67 3. Signature Verification with ECDSA and ECDSA* . . . . . . . . 4 68 4. Transitionary Considerations . . . . . . . . . . . . . . . . 5 69 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 70 6. Informal Comparison with Speed-ups for EdDSA Signatures . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 9.1. OIDs for Use with PKIX and CMS . . . . . . . . . . . . . 7 75 9.2. Algorithm Id for ECDSA* with OpenPGP . . . . . . . . . . 9 76 9.3. Other Uses . . . . . . . . . . . . . . . . . . . . . . . 9 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 11.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Fostering Fast Verification with ECDSA 85 ECDSA is one of the most widely used elliptic-curve digital signature 86 algorithms. It has been standardized in FIPS Pub 186-4, ANSI X9.62, 87 BSI, SECG, and IETF, and is widely deployed by a plethora of internet 88 protocols specified by the Internet Engineering Task Force (IETF), 89 with industry specifications in the areas of machine-to-machine 90 communication, such as ZigBee, ISA, and Thread, with wireless 91 communication protocols, such as IEEE 802.11, with payment protocols, 92 such as EMV, with vehicle-to-vehicle (V2V) specifications, as well as 93 with electronic travel documents and other specifications developed 94 under a more stringent regulatory oversight regime, such as, e.g., 95 ICAO and PIV. ECDSA is the only elliptic-curve based signature 96 scheme endorsed by regulatory bodies in both the United States and 97 the European Union. 99 While methods for accelerated verification of ECDSA signatures and 100 for combining this with key computations have been known for over 1 101 1/2 decade (see, e.g., [SAC2005] and [SAC2010]), these have been 102 commonly described in technical papers in terms of ECDSA*, a slightly 103 modified version of ECDSA, where their use with standardized ECDSA 104 seems less well known. It is the purpose of this document to bridge 105 this gap and describe how ECDSA signatures can be easily generated to 106 facilitate more efficient verification, without failing. We 107 emphasize that this does not require changes to standardized 108 specifications of ECDSA instantiated with prime-order curves, thereby 109 allowing reuse of existing standards and easy integration with 110 existing implementations. We exemplify this for ECDSA certificates. 112 2. Review of ECDSA and ECDSA* 114 In this section, we summarize the properties of the signature scheme 115 ECDSA and of the modified signature scheme ECDSA* that are relevant 116 for our exposition (for more details, see, e.g., Appendix Q of 117 [I-D.ietf-lwig-curve-representations]). The signature schemes are 118 defined in terms of a suitable elliptic curve E, hash function H, and 119 several representation functions, where n is the (prime) order of the 120 base point G of this curve, and where E is an elliptic curve in 121 short-Weierstrass form. For full details, we refer to the relevant 122 standards. 124 With the ECDSA signature scheme, the signature over a message m 125 provided by a signing entity with static private key d is an ordered 126 pair (r,s) of integers in the interval [1,n-1], where the value r is 127 derived from a so-called ephemeral signing key R:=k*G generated by 128 the signer via a fixed public conversion function and where the value 129 s is a function of the ephemeral private key k, the static private 130 key d, the value r and the value e derived from message m via hash 131 function H and representation hereof in the interval [0,n-1]. (More 132 specifically, one has e=s*k-d*r (mod n), where r is a function of the 133 x-coordinate of R.) A signature (r,s) over message m purportedly 134 signed by an entity with public key Q:=d*G is accepted if Q is indeed 135 a valid public key, if both signature components r and s are integers 136 in the interval [1,n-1] and if the reconstructed value R' derived 137 from the purported signature, message, and public key yields r, via 138 the same fixed conversion function as used during the signing 139 operation. (More specifically, one computes R':=(1/s)*(e*G+r*Q) and 140 checks that r is the same function of the x-coordinate of R'.) 142 With the ECDSA* signature scheme, one follows the same signing 143 operation, except that one outputs as signature the ordered pair 144 (R,s), rather than the pair (r,s), where R is the ephemeral signing 145 key; one accepts a signature (R,s) over message m purportedly signed 146 by an entity with public key Q by first computing the value r derived 147 from signature component R via the conversion function, checking that 148 Q is indeed a valid public key and that both r and s are integers in 149 the interval [1,n-1], computing R':=(1/s)*(e*G+r*Q) and checking 150 whether, indeed, R'=R. 152 It is known that ECDSA signatures and the corresponding ECDSA* 153 signatures have the same success/failure conditions (i.e., ECDSA and 154 ECDSA* are equally secure): if (r,s) is a valid ECDSA signature for 155 message m purportedly signed by an entity with public key Q, then 156 (R',s) is a valid corresponding ECDSA* signature, where R':=(1/ 157 s)(e*G+r*Q) is a point for which the conversion function yields r. 158 Conversely, if (R,s) is a valid ECDSA* signature for message m 159 purportedly signed by an entity with public key Q, then (r,s) is a 160 valid corresponding ECDSA signature, where r is obtained from R via 161 the conversion function. 163 It is well-known that if an ECDSA signature (r,s) is valid for a 164 particular message m and public key Q, then so is (r,-s) -- the so- 165 called malleability -- and that, similarly, if an ECDSA* signature 166 (R,s) is valid, then so is (-R,-s), where this relies on the fact 167 that the conversion function only depends on the x-coordinate of R. 169 3. Signature Verification with ECDSA and ECDSA* 171 In this section, we more closely scrutinize ECDSA and ECDSA* 172 verification processes. 174 With ECDSA*, signature verification primarily involves checking an 175 elliptic curve equation, viz. checking whether R = (1/s)*(e*G+r*Q), 176 which lends itself to accelerated signature verification techniques 177 and the ability to use batch verification techniques, with 178 significant potential for accelerated verification (with ~1.3x and up 179 and ~6x speed-up potential, respectively). Here, speed-ups are due 180 to the availability of the point R, which effectively allows checking 181 an equation of the form -s*R + (e*G+r*Q)=O instead (where O is the 182 identity element of the curve). Similarly to the case with EdDSA 183 [RFC8032] (which natively represents the ephemeral signing key R as 184 part of the signature), this offers the potential for batch 185 verification, by checking a randomized linear combination of this 186 equation instead (thereby sharing the so-called point doubling 187 operations amongst all individual verifications and, potentially, 188 sharing scalars for signers of more than one message). In the case 189 of single verifications, efficient tricks allow reducing the bit-size 190 of the scalars involved in evaluating this expression (thereby 191 effectively halving the required point doubling operations). 193 With ECDSA itself, these techniques are generally not available, 194 since one cannot uniquely (and efficiently) reconstruct R from r: 195 both R and -R yield the same r value. If the conversion function 196 only has two pre-images, though, one can use malleability to remove 197 ambiguity altogether. 199 The modified ECDSA signing procedure is as follows: 201 a. Generate ECDSA signature (r,s) of message m; 203 b. If the ephemeral signing key R has odd parity of the 204 y-coordinate, change (r,s) to (r,-s). 206 Note that this modified signing procedure removes the ambiguity in 207 the reconstruction of R from r if the conversion function would 208 otherwise only have two preimages, since R and -R have different 209 parity of the y-coordinate. In practice, this is the case for all 210 prime-order curves, including the NIST prime curves P-256, P-384, 211 P-521, all standardized Brainpool curves, and, e.g., the "BitCoin" 212 curve secp256k1. (This follows from the observation that, for prime- 213 order curves, r generally uniquely represents the x-coordinate of R.) 215 NOTE: With ECDSA, any party (not just the signer) can recompute the 216 ephemeral signing key R' from a valid signature, since R':=(1/ 217 s)(e*G+r*Q). In particular, any party can retroactively put the 218 ECDSA signature in the required form above, thereby allowing 219 subsequent unique reconstruction of the R value from r by verifying 220 entities that know this modified signing procedure was indeed 221 followed (again, subject to the assumption that r would only have two 222 preimages otherwise, as is generally the case with prime-order 223 curves). 225 One can extend this technique to also apply to curves that have a 226 small co-factor h, e.g., h=4 or h=8 (rather than h=1, as is the case 227 with prime-order curves). This extension is out of scope for the 228 current document. 230 4. Transitionary Considerations 232 The modified signing procedure described in Section 3 facilitates the 233 use of accelerated ECDSA verification techniques by devices that wish 234 to do so, provided these know that this modified signing procedure 235 was indeed followed. This can be realized explicitly via a new 236 "fast-verification-friendly" label (e.g., OID) indicating that this 237 was indeed the case. This has the following consequences: 239 a. New device: accept both old and new label and apply speed-ups 240 with new label if possible (and desired); 242 b. Old device: implement flimsy parser that replaces new label by 243 old label and proceed as with traditional ECDSA verification. 245 Note that this parser "label replacement" step is a public operation, 246 so any interface can implement this step. 248 A label can also be realized implicitly (e.g., by stipulating the 249 modified signing procedure in protocol specifications that use ECDSA 250 signatures), where the benefit of not having to introduce a new label 251 explicitly should be weighed against potential disadvantages of 252 implicit labels, such as requiring extra care with specification work 253 to avoid confusion and the likely need to reintroduce an explicit 254 label if ECDSA signatures are processed outside the original context 255 (e.g., using a generic crypographic token). 257 As suggested before, any device can implement the modified ECDSA 258 signing procedure retroactively, so one could conceivably implement 259 this once for all existing ECDSA signatures and only use "new" labels 260 once this task has been completed (i.e., old labels could be 261 mothballed from then on). 263 NOTE: the above labeling procedures assume that old and new labels 264 are not part of the message to be signed. If they are, one may not 265 be able to mothball old labels. In this case, signing devices should 266 always use the old label during ECDSA signing and only change this to 267 the corresponding new label afterwards, whereby verifying devices 268 always replace the new label (since simply a pseudonym) by the 269 corresponding old label before processing the ECDSA signature. This 270 ensures that the signature semantics are not impacted and that old 271 devices' ECDSA verification implementations (after reinstating old 272 labels) work as is, while still being able to flag verification- 273 friendly ECDSA signature formatting. 275 5. Implementation Status 277 [Note to the RFC Editor] Please remove this entire section before 278 publication, as well as the reference to [RFC7942]. 280 The ECDSA* signature scheme has been implemented in V2V 281 specifications [P1609.2], where ECDSA is used with the NIST curves 282 P-224 and P-256. 284 6. Informal Comparison with Speed-ups for EdDSA Signatures 286 The main message of this draft is as follows (no crypto required, 287 except believing that the third step below works): 289 a. EdDSA [RFC8032] does allow speedy signature verification and 290 batch verification, since the signature is (R,s), i.e., it 291 represents the ephemeral signing key R as part of the signature; 293 b. With ECDSA, the signature is (r,s), where r is derived from the 294 signing key R (essentially, r is the x-coordinate of R if the 295 curve has co-factor h=1). However, generally, one cannot go back 296 and get (r,s) --> (R,s), at least not efficiently; 298 c. If one uses the modified ECDSA signing procedure of Section 3, 299 one can, though, thereby allowing similar accelerations (30% and 300 up) for signature verification as EdDSA does. This can be viewed 301 as "point compression" (since it determines which of R and -R 302 apply); 304 d. The rest is detail, where the ideas underlying the speed-ups 305 informally described in Section 3 are described in detail in the 306 papers [SAC2005] and [SAC2010]. 308 7. Security Considerations 310 The signature representation change described in this document is 311 publicly known and, therefore, does not affect security provisions. 312 Obviously, any adversary could change the signature value in a 313 malicious way, so as to make signature verification fail. This does, 314 however, not extend capabilities the adversary already had. 316 8. Privacy Considerations 318 The signature representation change described in this document is 319 publicly known and, therefore, does not affect privacy provisions. 321 9. IANA Considerations 323 This section requests the following IANA code point assignments. 325 Editorial Note: the approach below is simply one way of realizing 326 ECDSA* functionality. Other options to consider include, e.g., 327 introducing a non-critical extension as label, where old devices can 328 simple ignore this. This will be elaborated upon further in next 329 versions of this draft, after feedback. 331 9.1. OIDs for Use with PKIX and CMS 333 This section registers the following object identifiers for the 334 verification-friendly version of ECDSA introduced in this document: 336 a. id-ecdsa-star-with-sha256 ::= {iso(1) identified-organization(3) 337 thawte (101) (100) 81}; 339 b. id-ecdsa-star-with-sha384 ::= {iso(1) identified-organization(3) 340 thawte (101) (100) 82}; 342 c. id-ecdsa-star-with-sha512 ::= {iso(1) identified-organization(3) 343 thawte (101) (100) 83}; 345 d. id-ecdsa-star-with-shake128 ::= {iso(1) identified- 346 organization(3) thawte (101) (100) 84}; 348 e. id-ecdsa-star-with-shake256 ::= {iso(1) identified- 349 organization(3) thawte (101) (100) 85}. 351 Each of these object identifiers indicates the use of ECDSA with the 352 indicated hash function, as the corresponding object identifiers 353 without the "-star-" substring specified in [RFC5480] (for ECDSA with 354 SHA2-hash family members) and in [RFC8692] (for ECDSA with SHAKE 355 family members) do, where the "-star-" substring simply indicates 356 that the modified signing procedure specified in Section 3 of this 357 document was indeed used. 359 These new object identifiers are used with PKIX certificates and CMS 360 in the same way as the corresponding object identifiers without the 361 "-star-" substring, except that verifying devices now have the option 362 to implement ECDSA signature verification as if ECDSA* signatures had 363 been used, since the new object identifiers indicate the modified 364 signing operation was followed, as illustrated in Section 3 of this 365 document. 367 As mentioned in Section 4, any ECDSA signature with the old object 368 identifier can be changed retroactively to one with the corresponding 369 new object identifier, provided one has assurance that the modified 370 ECDSA signing procedure was indeed followed and, conversely, any 371 ECDSA signature with the new object identifier can be changed to one 372 with the corresponding old object identifier, without change in 373 semantics (assuming these object identifiers are not part of the 374 message that is signed). 376 With [RFC5280], the signature algorithm is indicated twice: once as 377 signatureAlgorithm field of the Certificate and once as the Signature 378 field of the sequence tbsCertificate, where the former is not part of 379 the message to be signed, whereas the latter is. Moreover, these two 380 fields are stipulated to be the same (see Sections 4.1.1.2 and 381 4.1.2.3 of [RFC5280]). In this case, old and new labels MUST be used 382 as indicated in the NOTE of Section 3, where the two fields 383 indicating the signature algorithm are always both changed at the 384 same time (thereby, strictly complying with MUST behavior of PKIX 385 that these two fields should be the same). 387 9.2. Algorithm Id for ECDSA* with OpenPGP 389 This section registers the ECDSA signature scheme with the modified 390 signing procedure of this document as the public-key algorithm ECDSA* 391 (with ID=25) in Section 9.1 of [I-D.ietf-openpgp-crypto-refresh] by 392 including the following item in Table 15 of that section: 394 +-----+------------+ 395 | ID | Algorithm | 396 +-----+------------+ 397 | 25 | ECDSA* | 398 +-----+------------+ 400 Table 1: Public-Key Algorithm Registry 402 As before, the provisions of Section 4 apply. 404 9.3. Other Uses 406 As suggested in Section 4, any party can retroactively put ECDSA 407 signatures into the verification-friendly format, thereby conceivably 408 allowing this to be done once and for all for all existing ECDSA 409 signatures, no matter the application. In particular, one could 410 apply this to ECDSA-based certificate chains, ECDSA-signed firmware 411 updates, COSE, JOSE, etc., etc. In other words: going forward, never 412 use ECDSA signing, always use ECDSA* signing. 414 Similar techniques can be used to put the German ECGDSA signature 415 scheme, the Russian GOST signature scheme, and Chinese SM2 signature 416 in a verification-friendly format, although this cannot be done 417 retroactively without changing the signature format (it requires one 418 extra bit). Further details are left to a future version of this 419 document. 421 10. Acknowledgements 423 Thanks to Rich Salz for suggesting to informally compare speed-ups 424 with ECDSA* with those of EdDSA (now in Section 6). 426 11. References 427 11.1. Normative References 429 [FIPS-186-4] 430 FIPS 186-4, "Digital Signature Standard (DSS), Federal 431 Information Processing Standards Publication 186-4", US 432 Department of Commerce/National Institute of Standards and 433 Technology, Gaithersburg, MD, July 2013. 435 [I-D.ietf-lwig-curve-representations] 436 Struik, R., "Alternative Elliptic Curve Representations", 437 draft-ietf-lwig-curve-representations-20 (work in 438 progress), February 2021. 440 [I-D.ietf-openpgp-crypto-refresh] 441 Koch, W. and P. Wouters, "OpenPGP Message Format", draft- 442 ietf-openpgp-crypto-refresh-03 (work in progress), May 443 2021. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 451 Housley, R., and W. Polk, "Internet X.509 Public Key 452 Infrastructure Certificate and Certificate Revocation List 453 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 454 . 456 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 457 "Elliptic Curve Cryptography Subject Public Key 458 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 459 . 461 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 462 Code: The Implementation Status Section", BCP 205, 463 RFC 7942, DOI 10.17487/RFC7942, July 2016, 464 . 466 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 467 Signature Algorithm (EdDSA)", RFC 8032, 468 DOI 10.17487/RFC8032, January 2017, 469 . 471 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 472 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 473 May 2017, . 475 [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key 476 Infrastructure: Additional Algorithm Identifiers for 477 RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, 478 DOI 10.17487/RFC8692, December 2019, 479 . 481 [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", 482 Standards for Efficient Cryptography, , June 2009. 484 [SEC2] SEC2, "SEC 2: Elliptic Curve Cryptography, Version 2.0", 485 Standards for Efficient Cryptography, , January 2010. 487 11.2. Informative References 489 [ECC] I.F. Blake, G. Seroussi, N.P. Smart, "Elliptic Curves in 490 Cryptography", Cambridge University Press, Lecture Notes 491 Series 265, July 1999. 493 [GECC] D. Hankerson, A.J. Menezes, S.A. Vanstone, "Guide to 494 Elliptic Curve Cryptography", New York: Springer-Verlag, 495 2004. 497 [P1609.2] IEEE 1609.2-2013, "IEEE Standard for Wireless Access in 498 Vehicular Environments-Security Services for Applications 499 and Management Messages", IEEE Vehicular Technology 500 Society, New York: IEEE, 2013. 502 [SAC2005] A. Antipa, D.R. Brown, R. Gallant, R. Lambert, R. Struik, 503 S.A. Vanstone, "Accelerated Verification of ECDSA 504 Signatures", SAC 2005, B. Preneel, S. Tavares, Eds., 505 Lecture Notes in Computer Science, Vol. 3897, pp. 307-318, 506 Berlin: Springer, 2006. 508 [SAC2010] R. Struik, "Batch Computations Revisited: Combining Key 509 Computations and Batch Verifications", SAC 2010, A. 510 Biryukov, G. Gong, D.R. Stinson, Eds., Lecture Notes in 511 Computer Science, Vol. 6544, pp. 130-142, Berlin- 512 Heidelberg: Springer, 2011. 514 Author's Address 516 Rene Struik 517 Struik Security Consultancy 519 Email: rstruik.ext@gmail.com