idnits 2.17.1 draft-mattsson-cfrg-det-sigs-with-noise-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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 176: '... is RECOMMENDED instead of step (2) in Section 5.1.6 of [RFC8032]:...' RFC 2119 keyword, line 183: '...ern, the following step is RECOMMENDED...' RFC 2119 keyword, line 196: '... steps is RECOMMENDED instead of ste...' RFC 2119 keyword, line 219: '... RECOMMENDED....' RFC 2119 keyword, line 229: '... SHALL be generated a cryptographica...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2019) is 1564 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-irtf-cfrg-randomness-improvements-08 -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Obsolete informational reference (is this intentional?): RFC 8208 (Obsoleted by RFC 8608) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Preuss Mattsson 3 Internet-Draft E. Thormarker 4 Updates: 6979, 8032 (if approved) S. Ruohomaa 5 Intended status: Informational Ericsson 6 Expires: June 19, 2020 December 17, 2019 8 Deterministic ECDSA and EdDSA Signatures with Noise 9 draft-mattsson-cfrg-det-sigs-with-noise-00 11 Abstract 13 Deterministic elliptic-curve signatures such as deterministic ECDSA 14 and EdDSA have gained popularity over randomized ECDSA as their 15 security do not depend on a source of high-quality randomness. 16 Recent research has however found that implementations of these 17 signature algorithms may be vulnerable to certain side-channel and 18 fault injection attacks due to their determinism. One countermeasure 19 to such attacks is to add noise to the otherwise deterministic 20 calculation of the per-message secret number. This document updates 21 RFC 6979 and RFC 8032 to recommend constructions with noise for 22 deployments where side-channel attacks and fault injection attacks 23 are a concern. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 19, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Updates to RFC 8032 (EdDSA) . . . . . . . . . . . . . . . . . 4 61 3. Updates to RFC 6979 (Deterministic ECDSA) . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 5. TODOs and Other Considerations . . . . . . . . . . . . . . . 7 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 6.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 In Elliptic-Curve Cryptography (ECC) signature algorithms, the per- 73 message secret number has traditionally been generated from a random 74 number generator (RNG). The security of such algorithms depends on 75 the cryptographic quality of the random number generation and biases 76 in the randomness may have catastrophic effects such as compromising 77 private keys. Repeated per-message secret numbers have caused 78 several severe security accidents in practice. As stated in 79 [RFC6979], the need for a cryptographically secure source of 80 randomness is also a hindrance to deployment of randomized ECDSA 81 [FIPS-186-4] in architectures where secure random number generation 82 is challenging, in particular, embedded IoT systems and smartcards. 83 [ABFJLM17] does however state that smartcards typically has a high- 84 quality RNG on board, which makes it significantly easier and faster 85 to use the RNG instead of doing a hash computation. 87 In deterministic ECC signatures schemes such as Deterministic 88 Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6979] and 89 Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8032], the per- 90 message secret number is instead generated in a fully-deterministic 91 way as a function of the message and the private key. Except for key 92 generation, the security of such deterministic signatures does not 93 depend on a source of high-quality randomness. As they are presumed 94 to be safer, deterministic signatures have gained popularity and are 95 referenced and recommended by a large number of recent RFCs [RFC8037] 96 [RFC8080] [RFC8152] [RFC8225] [RFC8387] [RFC8410] [RFC8411] [RFC8419] 98 [RFC8420] [RFC8422] [RFC8446] [RFC8463] [RFC8550] [RFC8591] [RFC8624] 99 [RFC8208] [RFC8608]. 101 Side-channel attacks are potential attack vectors for implementations 102 of cryptographic algorithms. Side-Channel attacks can in general be 103 classified along three orthogonal axes: passive vs. active, physical 104 vs. logical, and local vs. remote [SideChannel]. It has been 105 demonstrated how side-channel attacks such as power analysis 106 [BCPST14] and timing attacks [Minerva19] [TPM-Fail19] allow for 107 practical recovery of the private key in some existing 108 implementations of randomized ECDSA. [BSI] summarizes minimum 109 requirements for evaluating side-channel attacks of elliptic curve 110 implementations and writes that deterministic ECDSA and EdDSA 111 requires extra care. The deterministic ECDSA specification [RFC6979] 112 notes that the deterministic generation of per-message secret numbers 113 may be useful to an attacker in some forms of side-channel attacks 114 and as stated in [Minerva19], deterministic signatures like [RFC6979] 115 and [RFC8032] might help an attacker to reduce the noise in the side- 116 channel when the same message it signed multiple times. Recent 117 research [SH16] [BP16] [RP17] [ABFJLM17] [SBBDS17] [PSSLR17] [SB18] 118 [WPB19] [AOTZ19] [FG19] have theoretically and experimentally 119 analyzed the resistance of deterministic ECC signature algorithms 120 against side-channel and fault injection attacks. The conclusions 121 are that deterministic signature algorithms have theoretical 122 weaknesses against certain instances of these types of attacks and 123 that the attacks are practically feasibly in some environments. 124 These types of attacks may be of particular concern for hardware 125 implementations such as embedded IoT devices and smartcards where the 126 adversary can be assumed to have access to the device to induce 127 faults and measure its side-channels such as timing information with 128 low signal-to-noise ratio, power consumption, electromagnetic leaks, 129 or sound. Fault attacks may also be possible without physical access 130 to the device. RowHammer [RowHammer14] showed how an attacker to 131 induce DRAM bit-flips in memory areas the attacker should not have 132 access to and Plundervolt [Plundervolt19] showed how an attacker with 133 root access can use frequency and voltage scaling interfaces to 134 induce faults that bypasses even secure execution technologies. 135 RowHammer can e.g. be used in operating systems with several 136 processes or cloud scenarios with virtualized servers. Protocols 137 like TLS, SSH, and IKEv2 that adds a random number to the message to 138 be signed mitigate some types of attacks [PSSLR17]. 140 Government agencies are clearly concerned about these attacks. In 141 [Notice-186-5] and [Draft-186-5], NIST warns about side-channel and 142 fault injection attacks, but states that deterministic ECDSA may be 143 desirable for devices that lack good randomness. BSI has published 144 [BSI] and researchers from BSI have co-authored two research papers 145 [ABFJLM17] [PSSLR17] on attacks on deterministic signatures. For 146 many industries it is important to be compliant with both RFCs and 147 government publications, alignment between IETF, NIST, and BSI 148 recommendations would be preferable. 150 One countermeasure to side-channel and fault injection attacks 151 recommended by [RP17] [ABFJLM17] [SBBDS17] [PSSLR17] [SB18] [AOTZ19] 152 [FG19] and implemented in [XEdDSA] [libSodium] [libHydrogen] is to 153 re-introduce some additional randomness or noise to the otherwise 154 deterministic generation of the per-message secret number. This 155 combines the security benefits of fully-randomized per-message secret 156 numbers with the security benefits of fully-deterministic secret 157 numbers. Such a construction protects against key compromise due to 158 weak random number generation, but still effectively prevents many 159 side-channel and fault injection attacks that exploit determinism. 160 Deterministic ECDSA with noise can be made compliant with 161 [FIPS-186-4] but would not be compliant with the recommendations in 162 many RFCs. Adding noise to EdDSA is not compliant with [RFC8032]. 164 This document updates [RFC6979] and [RFC8032] to recommend 165 constructions with noise for deployments where side-channel and fault 166 injection attacks are a concern. Produced signatures remain fully 167 compatible with unmodified ECDSA and EdDSA verifiers and existing key 168 pairs can continue to be used. As the precise use of the noise is 169 specified, test vectors can still be produced and implementations can 170 be tested against them. 172 2. Updates to RFC 8032 (EdDSA) 174 For Ed25519ph, Ed25519ctx, and Ed25519: In deployments where side- 175 channel and fault injection attacks are a concern, the following step 176 is RECOMMENDED instead of step (2) in Section 5.1.6 of [RFC8032]: 178 2. Compute SHA-512(dom2(F, C) || prefix XOR Z || PH(M)), where M 179 is the message to be signed and Z is 32 octets of random data. 180 Interpret the 64-octet digest as a little-endian integer r. 182 For Ed448ph and Ed448: In deployments where side-channel and fault 183 injection attacks are a concern, the following step is RECOMMENDED 184 instead of step (2) in Section 5.3.6 of [RFC8032]: 186 2. Compute SHAKE256(dom4(F, C) || prefix XOR Z || PH(M), 114), 187 where M is the message to be signed, and Z is 57 octets of 188 random data, F is 1 for Ed448ph, 0 for Ed448, and C is the 189 context to use. Interpret the 114-octet digest as a 190 little-endian integer r. 192 3. Updates to RFC 6979 (Deterministic ECDSA) 194 For Deterministic ECDSA: In existing ECDSA deployments where side- 195 channel and fault injection attacks are a concern, the following 196 steps is RECOMMENDED instead of steps (d) and (f) in Section 3.2 of 197 [RFC6979]: 199 d. Set: 201 K = HMAC_K(V || 0x00 || int2octets(x) XOR Z || bits2octets(h1)) 203 where '||' denotes concatenation. In other words, we compute 204 HMAC with key K, over the concatenation of the following, in 205 order: the current value of V, a sequence of eight bits of value 206 0, the encoding of the (EC)DSA private key x XORed with random 207 data Z (of the same length as int2octets(x)), and the hashed 208 message (possibly truncated and extended as specified by the 209 bits2octets transform). The HMAC result is the new value of K. 210 Note that the private key x is in the [1, q-1] range, hence a 211 proper input for int2octets, yielding rlen bits of output, i.e., 212 an integral number of octets (rlen is a multiple of 8). 214 f. Set: 216 K = HMAC_K(V || 0x01 || int2octets(x) XOR Z || bits2octets(h1)) 218 In new deployments, EdDSA with noise as specified in Section 2 is 219 RECOMMENDED. 221 4. Security Considerations 223 The constructions in this document follows the high-level approach in 224 [XEdDSA] to calculate the per-message secret number from the hash of 225 the private key and the message, but add random noise into the 226 calculation for greater resilience. This does not re-introduce the 227 strong security requirement of randomness needed by randomized ECDSA 228 [FIPS-186-4]. The randomness of Z does not need to be perfect, but 229 SHALL be generated a cryptographically secure pseudo random number 230 generator (PRNG) and SHALL be secret. Even if the same random number 231 Z is used to sign two different messages, the security will be the 232 same as deterministic ECDSA and EdDSA and an attacker will not be 233 able to compromise the private key with algebraic means as in fully- 234 randomized ECDSA [FIPS-186-4]. With the construction specified in 235 this document, two signatures over two equal messages are different 236 which prevents information leakage in use cases where signatures but 237 not messages are public. 239 [SBBDS17] states that [XEdDSA] would not prevent their attack due to 240 insufficient mixing of the hashed private key with the random noise. 241 [SBBDS17] suggest a construction where the random noise is padded 242 with zeroes so that the first 1024-bit SHA-512 block is composed only 243 of the hashed private key and the random value, but not the message. 244 This solution does however increase the number of hash function 245 invocations and the amount of padding is dependent on the block size. 246 The construction in this document therefore XOR the random noise with 247 the hashed key. Masking the private key with pseudorandom noise 248 mitigates the attacks in [SBBDS17], does not increase the number of 249 hash function invocations, and does not depend on the block size. 250 XOR is chosen as it is a very simple function and XORing the key with 251 fresh random bytes should not leak sufficient side-channel 252 information about the key for an attack, while preserving the 253 computational entropy of the key. 255 Another countermeasure to fault attacks is to force the signer to 256 verify the signature in the last step of the signature generation or 257 to calculate the signature twice and compare the results. These 258 countermeasure would catch a single fault but would not protect 259 against attackers that are able to precisely inject faults several 260 times [RP17] [PSSLR17] [SB18]. Adding an additional sign or 261 verification operation would also significantly affect performance, 262 especially verification which is a heavier operation than signing in 263 ECDSA and EdDSA. 265 [ABFJLM17] suggests using both a random noise and a counter, which 266 makes the signature generation stateful. While most used signatures 267 have traditionally been stateless, stateful signatures like XMSS 268 [RFC8391] and LMS [RFC8554] have now been standardized and deployed. 269 [I-D.irtf-cfrg-randomness-improvements] specifies a PRNG construction 270 with a random seed, a secret key, a context string, and a nonce, 271 which makes the random number generation stateful. The generation of 272 the per-message secret number in this document is not stateful, but 273 it can be used with a stateful PRNG. The exact construction in 274 [I-D.irtf-cfrg-randomness-improvements] is however not recommended in 275 deployments where side-channel and fault injection attacks are a 276 concern as it relies on deterministic signatures. 278 With the construction in this document, the repetition of the same 279 per-message secret number for two different messages is highly 280 unlikely even with an imperfect random number generator, but not 281 impossible. As an extreme countermeasure, previously used secret 282 numbers can be tracked to ensure their uniqueness for a given key, 283 and a different random number can be used if a collision is detected. 284 This document does not mandate nor stop an implementation from taking 285 such a precaution. 287 Implementations need to follow best practices on how to protect 288 against all side-channel attacks, not just attacks that exploits 289 determinism, see for example [BSI]. 291 5. TODOs and Other Considerations 293 o EdDSA noise construction - It should be discussed what the best 294 construction is for achieving protection against fault and side- 295 channel attacks, simplicity and ease of implementation, as well as 296 efficiency. For reference the noise construction in [XEdDSA] is 298 SHA-512(dom2(F, C) || prefix || PH(M) || Z) 300 where Z is 64 octets of random data. The construction suggested 301 in [SBBDS17] is 303 SHA-512(dom2(F, C) || prefix || 000... || Z || PH(M)) 305 where the number of zeroes is chosen so that the first 1024-bit 306 block is composed only of the hashed private key and the random 307 value, but not the message. E.g. 80 bytes of zeroes and 16 octets 308 of random data. There might be reasons to have different 309 constructions for Ed25519 (SHA-512) and Ed448 (SHAKE256). 311 o ECDSA noise construction - The current noise construction for 312 ECDSA is modelled after the construction for EdDSA. There might 313 be reasons to have different constructions for EdDSA and 314 deterministic ECDSA as ECDSA can be used with any hash function 315 (e.g. SHA-2 or SHAKE) and the construction in [RFC6979] uses 316 HMAC. NIST is planning to approve SHAKE for use in ECDSA 317 [Draft-186-5]. Deterministic ECDSA would then use HMAC-SHAKE 318 instead of the more optimal KMAC, but it is not clear if an update 319 is worth doing, or if people should be adviced to move to EdDSA 320 instead. But, even if EdDSA is superior to ECDSA, ECDSA is widely 321 deployed and will be used for a long time. Small changes that are 322 compatible with existing signature verification implementations 323 are worth doing. 325 o Amount of randomness - The current construction uses 32 bytes of 326 randomness for Ed25519. XEdDSA uses 64 bytes of randomness which 327 might be overkill. As discussed in [SBBDS17], the amount of 328 random noise needed depends on the targeted security level. 32 329 bytes of randomness should be enough for Ed448 and 16 bytes of 330 randomness should be enough for Ed25519. Even less than that is 331 likely sufficient to prevent practical attacks. 333 o EdDSA hash algorithm - For protection against side-channel 334 attacks, the use of SHA-512 may not be optimal. [SBBDS17] states 335 that protection against side-channel attacks would be easier and 336 more robust with a hash function like SHAKE128, but this may not 337 matter when noise is added. The use of SHA-512 in Ed25519 is 338 suitable for software implementations in web servers and may not 339 be optimal for embedded IoT devices and smart cards as it likely 340 requires them to implement one more cryptographic hash algorithms. 341 If CFRG decides to do an update to RFC 8032 addressing IoT devices 342 vulnerable to fault injection and side-channel attacks it should 343 be considered if other changes should be made as well. Currently, 344 most embedded IoT devices implements SHA-256, but in the future 345 they may implement a sponge function like Keccak or Gimli and use 346 that to construct XOF, PRF, and AEAD. Ed25519 with Keccak is 347 discussed in [I-D.moskowitz-small-crypto] and Ed25519 with Gimli 348 is implemented in [libHydrogen]. NIST is planning to approve 349 SHAKE for use in ECDSA [Draft-186-5]. Using a XOF like 351 SHAKE128(..., 64) 353 instead of SHA-512 in Ed25519 would be straightforward, while 354 using SHA-256 would require more invocations of the hash function 355 like 357 SHA-256(... || 0x00) || SHA-256(... || 0x01) 359 6. References 361 6.1. Normative References 363 [FIPS-186-4] 364 Department of Commerce, National., "Digital Signature 365 Standard (DSS)", NIST FIPS PUB 186-4 , July 2013, 366 . 369 [I-D.irtf-cfrg-randomness-improvements] 370 Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 371 and C. Wood, "Randomness Improvements for Security 372 Protocols", draft-irtf-cfrg-randomness-improvements-08 373 (work in progress), November 2019. 375 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 376 Algorithm (DSA) and Elliptic Curve Digital Signature 377 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 378 2013, . 380 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 381 Signature Algorithm (EdDSA)", RFC 8032, 382 DOI 10.17487/RFC8032, January 2017, 383 . 385 6.2. Informative References 387 [ABFJLM17] 388 Ambrose, C., Bos, J., Fay, B., Joye, M., Lochter, M., and 389 B. Murray, "Differential Attacks on Deterministic 390 Signatures", October 2017, 391 . 393 [AOTZ19] Aranha, D., Orlandi, C., Takahashi, A., and G. Zaverucha, 394 "Security of Hedged Fiat-Shamir Signatures under Fault 395 Attacks", September 2019, 396 . 398 [BCPST14] Batina, L., Chmielewski, L., Papachristodoulou, L., 399 Schwabe, P., and M. Tunstall, "Online Template Attacks", 400 December 2014, . 403 [BP16] Barenghi, A. and G. Pelosi, "A Note on Fault Attacks 404 Against Deterministic Signature Schemes (Short Paper)", 405 September 2016, . 408 [BSI] Bundesamt fuer Sicherheit in der Informationstechnik, ., 409 "Minimum Requirements for Evaluating Side-Channel Attack 410 Resistance of Elliptic Curve Implementations", November 411 2016, 412 . 416 [Draft-186-5] 417 National Institute of Standards and Technology (NIST), ., 418 "FIPS PUB 186-5 (Draft)", October 2019, 419 . 422 [FG19] Fischlin, M. and F. Guenther, "Modeling Memory Faults in 423 Signature and Encryption Schemes", September 2019, 424 . 426 [I-D.moskowitz-small-crypto] 427 Moskowitz, R. and L. Xia, "Small Crypto for Small IOT", 428 draft-moskowitz-small-crypto-00 (work in progress), 429 October 2017. 431 [libHydrogen] 432 "The Hydrogen library", n.d., 433 . 435 [libSodium] 436 "The Sodium library", n.d., 437 . 439 [Minerva19] 440 Centre for Research on Cryptography and Security (CRoCS), 441 ., "Minerva", October 2019, 442 . 444 [Notice-186-5] 445 National Institute of Standards and Technology (NIST), ., 446 "Request for Comments on FIPS 186-5 and SP 800-186", 447 October 2019, . 451 [Plundervolt19] 452 Murdock, K., Oswald, D., Garcia, F., Van Bulck, J., Gruss, 453 D., and F. Piessens, "How a little bit of undervolting can 454 cause a lot of problems", December 2019, 455 . 457 [PSSLR17] Poddebniak, D., Somorovsky, J., Schinzel, S., Lochter, M., 458 and P. Roesler, "Attacking Deterministic Signature Schemes 459 using Fault Attacks", October 2017, 460 . 462 [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) 463 and Signatures in JSON Object Signing and Encryption 464 (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, 465 . 467 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 468 Algorithm (EdDSA) for DNSSEC", RFC 8080, 469 DOI 10.17487/RFC8080, February 2017, 470 . 472 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 473 RFC 8152, DOI 10.17487/RFC8152, July 2017, 474 . 476 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 477 Formats, and Signature Formats", RFC 8208, 478 DOI 10.17487/RFC8208, September 2017, 479 . 481 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 482 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 483 . 485 [RFC8387] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical 486 Considerations and Implementation Experiences in Securing 487 Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387, 488 May 2018, . 490 [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. 491 Mohaisen, "XMSS: eXtended Merkle Signature Scheme", 492 RFC 8391, DOI 10.17487/RFC8391, May 2018, 493 . 495 [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for 496 Ed25519, Ed448, X25519, and X448 for Use in the Internet 497 X.509 Public Key Infrastructure", RFC 8410, 498 DOI 10.17487/RFC8410, August 2018, 499 . 501 [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the 502 Cryptographic Algorithm Object Identifier Range", 503 RFC 8411, DOI 10.17487/RFC8411, August 2018, 504 . 506 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 507 Algorithm (EdDSA) Signatures in the Cryptographic Message 508 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 509 2018, . 511 [RFC8420] Nir, Y., "Using the Edwards-Curve Digital Signature 512 Algorithm (EdDSA) in the Internet Key Exchange Protocol 513 Version 2 (IKEv2)", RFC 8420, DOI 10.17487/RFC8420, August 514 2018, . 516 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 517 Curve Cryptography (ECC) Cipher Suites for Transport Layer 518 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 519 DOI 10.17487/RFC8422, August 2018, 520 . 522 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 523 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 524 . 526 [RFC8463] Levine, J., "A New Cryptographic Signature Method for 527 DomainKeys Identified Mail (DKIM)", RFC 8463, 528 DOI 10.17487/RFC8463, September 2018, 529 . 531 [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 532 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 533 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, 534 April 2019, . 536 [RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali 537 Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, 538 April 2019, . 540 [RFC8591] Campbell, B. and R. Housley, "SIP-Based Messaging with 541 S/MIME", RFC 8591, DOI 10.17487/RFC8591, April 2019, 542 . 544 [RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 545 Formats, and Signature Formats", RFC 8608, 546 DOI 10.17487/RFC8608, June 2019, 547 . 549 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 550 Requirements and Usage Guidance for DNSSEC", RFC 8624, 551 DOI 10.17487/RFC8624, June 2019, 552 . 554 [RowHammer14] 555 Kim, Y., Daly, R., Kim, J., Fallin, C., Lee, J., Lee, D., 556 Wilkerson, C., and K. Mutlu, "Flipping Bits in Memory 557 Without Accessing Them: An Experimental Study of DRAM 558 Disturbance Errors", June 2014, 559 . 562 [RP17] Romailler, Y. and S. Pelissier, "Practical fault attack 563 against the Ed25519 and EdDSA signature schemes", 564 September 2017, 565 . 567 [SB18] Samwel, N. and L. Batina, "Practical Fault Injection on 568 Deterministic Signatures: The Case of EdDSA", April 2018, 569 . 571 [SBBDS17] Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. 572 Susella, "Breaking Ed25519 in WolfSSL", October 2017, 573 . 575 [SH16] Seuschek, H., Heyszl, J., and F. De Santis, "A Cautionary 576 Note: Side-Channel Leakage Implications of Deterministic 577 Signature Schemes", January 2016, 578 . 581 [SideChannel] 582 Spreitzer, R., Moonsamy, V., Korak, T., and S. Mangard, 583 "Systematic Classification of Side-Channel Attacks: A Case 584 Study for Mobile Devices", December 2017, 585 . 587 [TPM-Fail19] 588 Moghimi, D., Sunar, B., Eisenbarth, T., and N. Heninge, 589 "TPM-FAIL: TPM meets Timing and Lattice Attacks", October 590 2019, . 592 [WPB19] Weissbart, L., Picek, S., and L. Batina, "One trace is all 593 it takes: Machine Learning-based Side-channel Attack on 594 EdDSA", July 2019, . 596 [XEdDSA] Signal, ., "The XEdDSA and VXEdDSA Signature Schemes", 597 October 2016, 598 . 600 Acknowledgments 602 The authors want to thank TBD for their valuable comments and 603 feedback. 605 Authors' Addresses 606 John Preuss Mattsson 607 Ericsson 609 Email: john.mattsson@ericsson.com 611 Erik Thormarker 612 Ericsson 614 Email: erik.thormarker@ericsson.com 616 Sini Ruohomaa 617 Ericsson 619 Email: sini.ruohomaa@ericsson.com