Hedged ECDSA and EdDSA Signatures

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 September 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

In Elliptic-Curve Cryptography (ECC) signature algorithms, the per-message secret number has traditionally been generated from a random number generator (RNG). The security of such algorithms depends on the cryptographic quality of the random number generation and biases in the randomness may have catastrophic effects such as compromising private keys (see e.g., [Bernstein19]). Repeated per-message secret numbers have caused several severe security accidents in practice. As stated in [RFC6979], the need for a cryptographically secure source of randomness is also a hindrance to deployment of randomized ECDSA [FIPS-186-5] in architectures where secure random number generation is challenging, in particular, embedded IoT systems and smartcards. [ABFJLM17] does however state that smartcards typically have a high-quality RNG on board, which makes it significantly easier and faster to use the RNG instead of doing a hash computation.¶

In deterministic ECC signatures schemes such as Deterministic Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6979][FIPS-186-5] and Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8032], the per-message secret number is instead generated in a fully deterministic way as a function of the message and the private key. Except for key generation, the security of such deterministic signatures does not rely on a source of high-quality randomness. This makes verification of implementations easier. As they are presumed to be safer, deterministic signatures have gained popularity and are referenced and recommended by a large number of recent RFCs [RFC8037] [RFC8080] [RFC8225] [RFC8387] [RFC8410] [RFC8411] [RFC8419] [RFC8420] [RFC8422] [RFC8446] [RFC8463] [RFC8550] [RFC8591] [RFC8608] [RFC8624] [RFC9053].¶

Side-channel attacks are potential attack vectors for implementations of cryptographic algorithms. Side-Channel attacks can in general be classified along three orthogonal axes: passive vs. active, physical vs. logical, and local vs. remote [SideChannel]. It has been demonstrated how side-channel attacks such as power analysis [BCPST14] and timing attacks [Minerva19] [TPM-Fail19] allow for practical recovery of the private key in some existing implementations of randomized ECDSA. [BSI] summarizes minimum requirements for evaluating side-channel attacks of elliptic curve implementations and writes that deterministic ECDSA and EdDSA requires extra care. The deterministic ECDSA specification [RFC6979] notes that the deterministic generation of per-message secret numbers may be useful to an attacker in some forms of side-channel attacks and as stated in [Minerva19], deterministic signatures like [RFC6979] and [RFC8032] might help an attacker to reduce the noise in the side-channel when the same message it signed multiple times. Recent research [SH16] [BP16] [RP17] [ABFJLM17] [SBBDS17] [PSSLR17] [SB18] [WPB19] [AOTZ19] [FG19] have theoretically and experimentally analyzed the resistance of deterministic ECC signature algorithms against side-channel and fault injection attacks. The conclusions are that deterministic signature algorithms have theoretical weaknesses against certain instances of these types of attacks and that the attacks are practically feasibly in some environments. These types of attacks may be of particular concern for hardware implementations such as embedded IoT devices and smartcards where the adversary can be assumed to have access to the device to induce faults and measure its side-channels such as timing information, power consumption, electromagnetic leaks, or sound with low signal-to-noise ratio. A good summary of fault attacks in given by [Cao20]. See also the discussions and references in [Comments-186-5].¶

Fault attacks may also be possible without physical access to the device. RowHammer [RowHammer14] showed how an attacker to induce DRAM bit-flips in memory areas the attacker should not have access to. Plundervolt [Plundervolt19] showed how an attacker with root access can use frequency and voltage scaling interfaces to induce faults that bypass even secure execution technologies. RowHammer can e.g., be used in operating systems with several processes or cloud scenarios with virtualized servers. Protocols like TLS, SSH, and IKEv2 that add a random number to the message to be signed mitigate some types of attacks [PSSLR17].¶

Government agencies are clearly concerned about these attacks. In [Notice-186-5] and [FIPS-186-5], NIST warns about side-channel and fault injection attacks, but states that deterministic ECDSA may be desirable for devices that lack good randomness. The quantum-resistant ML-DSA [FIPS-204] standardized by NIST uses hedged signing by default. BSI has published [BSI] and researchers from BSI have co-authored two research papers [ABFJLM17] [PSSLR17] on attacks on deterministic signatures. For many industries it is important to be compliant with both RFCs and government publications, alignment between IETF, NIST, and BSI recommendations would be preferable.¶

Note that deriving per-message secret number deterministically, is also insecure in a multi-party signature setting [RFC9591].¶

One countermeasure to entropy failures, side-channel attacks, and fault injection attacks recommended by [Langley13] [RP17] [ABFJLM17] [SBBDS17] [PSSLR17] [SB18] [AOTZ19] [FG19] and implemented in [OpenSSL13a] [OpenSSL13b] [XEdDSA] [libSodium] [libHydrogen] is to generate the per-message secret number from a random string, a secret key, and the message. This combines the security benefits of fully randomized per-message secret numbers with the security benefits of fully deterministic secret numbers. Such a hedged construction protects against key compromise due to weak random number generation, but still effectively prevents many side-channel and fault injection attacks that exploit determinism. Hedged constructions require minor changes to the implementation and does not increase the number of elliptic curve point multiplications and is therefore suitable for constrained IoT. Section 3.6 of [RFC6979] describes a variant of deterministic ECDSA that adds non-repeating additional data k' to the per-message secret number generation. Adding randomness to EdDSA is not compliant with [RFC8032]. [Kampanakis16] describes an alternative [FIPS-186-5] compliant approach where message specific pseudo-random information is used as an additional input to the random number generation to create per-message secret number. [Bernstein14] states that generation of the per-message secret number from a subset of a random string, a secret key, the message, and a message counter is common in DSA/ECDSA implementations.¶

This document updates [RFC6979] and [RFC8032] to recommend hedged constructions in deployments where side-channel and fault injection attacks are a concern. The updates are invisible to the validator of the signature. Produced signatures remain fully compatible with unmodified ECDSA and EdDSA verifiers and existing key pairs can continue to be used. As the precise use of random bytes is specified, test vectors can still be produced, see Section 6, and implementations can be tested against them.¶

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Hedged EdDSA

This document updates RFC 8032 (EdDSA) to recommend hedged variants of EdDSA for deployments where side-channel attacks and fault injection attacks are a concern, the variants are called hedged EdDSA. The updates are invisible to the validator of the signature and compatible with existing EdDSA validators.¶

Update to RFC 8032:¶

For Ed25519ph, Ed25519ctx, and Ed25519: In deployments where side-channel and fault injection attacks are a concern, the following step is RECOMMENDED instead of step (2) in Section 5.1.6 of [RFC8032]:¶

2.  Compute the digest SHA-512(prefix || Z), where Z is 32 octets of
    random data. Let prefix’ denote the leftmost half of the digest.
    Compute SHA-512(dom2(F, C) || prefix’ || PH(M)), where M is the
    message to be signed.  Interpret the 64-octet digest as a
    little-endian integer r.

For Ed448ph and Ed448: In deployments where side-channel and fault injection attacks are a concern, the following step is RECOMMENDED instead of step (2) in Section 5.2.6 of [RFC8032]:¶

2.  Compute the digest SHAKE256(prefix || Z, 114), where Z is 57
    octets of random data. Let prefix’ denote the leftmost half of
    the digest. Compute SHAKE256(dom4(F, C) || prefix’ || PH(M), 114),
    where M is the message to be signed,  F is 1 for Ed448ph, 0 for
    Ed448, and C is the context to use. Interpret the 114-octet digest
    as a little-endian integer r.

4. Hedged ECDSA

This document updates RFC 6979 (deterministic ECDSA) to recommend a hedged variant of ECDSA for deployments where side-channel attacks and fault injection attacks are a concern, the variant is called hedged ECDSA. The updates are invisible to the validator of the signature and compatible with existing ECDSA validators.¶

Update to RFC 6979: In ECDSA deployments where side-channel and fault injection attacks are a concern, the following steps are RECOMMENDED instead of steps (d) and (f) in Section 3.2 of [RFC6979]:¶

d.  Set:

       K = HMAC_K(V || 0x00 || Z || 000... || int2octets(x) || 000...
       || bits2octets(h1))

    where '||' denotes concatenation.  In other words, we compute
    HMAC with key K, over the concatenation of the following, in
    order: the current value of V, a sequence of eight bits of value
    0, random data Z (of the same length as int2octets(x)), a
    sequence of zero bits 000..., the encoding of the (EC)DSA private
    key x, a sequence of zero bits 000..., and the hashed message
    (possibly truncated and extended as specified by the bits2octets
    transform).  The non-negative number of zeroes 000... is chosen
    so that the length of (V || 0x00 || Z || 000...) and
    (int2octets(x) || 000...) are the smallest possible multiples
    of the block size of the hash function. The HMAC result is the
    new value of K.  Note that the private key x is in the [1, q-1]
    range, hence a proper input for int2octets, yielding rlen bits of
    output, i.e., an integral number of octets (rlen is a multiple of 8).

f.  Set:

       K = HMAC_K(V || 0x01 || Z || 000... || int2octets(x) || 000...
       || bits2octets(h1))

    Note that the "internal octet" is 0x01 this time. The string
    (Z || 000... || int2octets(x) || 000.. || bits2octets(h1)),
    called provided_data in HMAC_DRBG, is the same as in step (d).

The construction in [RFC6979] can be seen as using HMAC_DRBG [SP800-90Ar1] with rejection sampling to generate the ECDSA per-message secret number (see Section 3.3 of [RFC6979]). With the updates in this document, Z can be seen as the combination of entropy_input and nonce (see the text on "extra strong" entropy input in Section 8.6.7 of [SP800-90Ar1]). The concatenation 000... || int2octets(x) || 000... || bits2octets(h1) can be seen as the personalization_string. See Section 3.3 of [RFC6979] for the other parameters.¶

When ECDSA is used with SHAKE [SHA3] the HMAC construction in Section 3.2 of [RFC6979] MAY be used but it is RECOMMENDED to use the more efficient KMAC construction [KMAC] with output length hlen = 8 · ceil(qlen / 8), where qlen is the binary length of the order of the base point of the elliptic curve [RFC6979] and ceil(x) is the ceiling function mapping x to the least integer greater than or equal to x. When ECDSA is used with SHAKE128, it is RECOMMENDED to replace HMAC(K, M) in Section 3.2 of [RFC6979] with KMAC128(K, M, hlen, ""). When ECDSA is used with SHAKE256, it is RECOMMENDED to replace HMAC(K, M) in Section 3.2 of [RFC6979] with KMAC256(K, M, hlen, ""). [RFC8692] and [FIPS-186-5] define the use of SHAKE128 with an output length of 256 bits and SHAKE256 with an output length or 512 bits.¶

In new deployments, where side-channel and fault injection attacks are a concern, Hedged EdDSA as specified in Section 3 is RECOMMENDED.¶

5. Security Considerations

The constructions in this document follow the high-level approach in [XEdDSA] to calculate the per-message secret number from the hash of the private key and the message, but add additional randomness into the calculation for greater resilience. This does not re-introduce the strong security requirement of randomness needed by randomized ECDSA [FIPS-186-5]. The randomness of Z need not be perfect but SHALL be generated by a cryptographically secure method and SHALL be secret. Even if the same random number Z is used to sign two different messages, the security will be the same as deterministic ECDSA and EdDSA and an attacker will not be able to compromise the private key with algebraic means as in fully randomized ECDSA [FIPS-186-5]. With the construction specified in this document, two signatures over two equal messages are different which prevents information leakage in use cases where signatures but not messages are public.¶

The construction in this document aims to mitigate fault injection attacks that leverage determinism in deterministic ECDSA and EdDSA signatures (see e.g., [ABFJLM17]), by randomizing nonce generation. Fault injection attacks that achieve instruction skipping as in e.g., Section 3.4 of [ABFJLM17] are not necessarily stopped. It seems to be possible to, at the same time, also mitigate attacks that use first order differential power analysis (DPA) against the hash computation of deterministic nonces in EdDSA and ECDSA (see e.g., [ABFJLM17][SBBDS17]). The Hedged EdDSA construction mitigates the referenced first order DPA attacks by mixing prefix with Z before mixing it with any public variable data (message or context). Similarly, the Hedged ECDSA construction mixes x with a state randomized by Z before mixing it with public variable data (h1). The random bytes Z are re-used in step (d) and (f) of Hedged ECDSA to align with HMAC_DRBG. This may make certain DPA attacks easier than if randomness had been sampled fresh for each respective step. Note however that V is updated between the steps and that the secret key x is processed in a new input block of the hash function after processing V and Z in each respective step.¶

A key pair MAY be reused between implementations of the hedged constructions in this document and the non-hedged original constructions in [RFC8032] and Section 3.2 of [RFC6979]. The Hedged EdDSA construction in this document randomizes prefix in an intermediate step and preserves the domain separation between the different variants of EdDSA (see Section 8.6 of [RFC8032]). The Hedged ECDSA construction has a different HMAC input length in step (d) (and (f)) of Section 4 than the original construction in Section 3.2 of [RFC6979]. It is therefore impossible for an attacker to manipulate the parameters to the nonce generation process (between the different constructions) such that the HMAC input in step (d) and (f) becomes identical for two distinct messages.¶

Implementations need to follow best practices on how to protect against all side-channel attacks, not just attacks that exploit determinism, see for example [BSI].¶

6. Test Vectors

TODO¶

    MESSAGE = { }
 SECRET KEY = { }
RANDOM DATA = { }
  SIGNATURE = { }

    MESSAGE = { }
 SECRET KEY = { }
RANDOM DATA = { }
  SIGNATURE = { }

7. References

Change log

This section is to be removed before publishing as an RFC.¶

Changes from -03 to -04:¶

• Resubmission¶

Changes from -02 to -03:¶

• Same randomness Z in step d and f to align with HMAC_DRBG.¶

• Changed Hedged EdDSA order to 0x00 || Z || dom2(F, C) instead of dom2(F, C) || Z. This avoids collisions with RFC 8032 and aligns with Bernstein's recommendation to put Z before the context.¶

• Changed KMAC output length recommendations to avoid multiple invocations.¶

• Updates some text to align with the hedged signatures/signing terminology.¶

• Added more description about the construction.¶

• Editorial changes.¶

Changes from -01 to -02:¶

• Different names Zd and Zf for the randomness in ECDSA.¶

• Added empty test vector section as TODO.¶

Changes from -00 to -01:¶

• Changed terminology to hedged signatures/signing.¶

• Added reference to the FIPS 204 (ML-DSA) where hedged signatures are the default.¶

• Added a second 000... padding that separates the context from the prefix, aligning with BSI recommendations.¶

• Added note that Z in step f is not reused from step d.¶

• Added note on "internal octet" is 0x01 from RFC 6979.¶

• Removed incorrect statement that context fit in first block.¶

• Added more description about the construction.¶

• Moved "For discussion" section to GitHub issue.¶

• Editorial changes.¶

Acknowledgments

The authors would like to thank Tony Arcieri, Uri Blumenthal, Carsten Bormann, Taylor R Campbell, Quynh Dang, Håkan Englund, Janos Follath, Phillip Hallam-Baker, Chelsea Komlo, Niklas Lindskog, Ilari Liusvaara, Danny Niu, Jim Schaad, Ruggero Susella, Daniel J. Bernstein, Filippo Valsorda, and Sönke Jendral for their valuable comments and feedback.¶

Authors' Addresses