Skip to content

Latest commit

 

History

History
222 lines (155 loc) · 19.5 KB

README.md

File metadata and controls

222 lines (155 loc) · 19.5 KB
Raw

ed25519-unsafe-libs

Double Public Key Signing Function Oracle Attack on Ed25519

A list of potentially unsafe ed25519 signature libraries that allow a public api where secret and public key can be provided independently as signing function inputs. Misuse of these public apis can result to private key exposure.

Μost of the repositories in our analysis are enlisted in IANIX :: Things that use Ed25519.

Number of impacted libraries: 45
Number of libraries that fixed the issue after the announcement: 8
last updated: May 04, 2023

Proof of Concept implementations that demonstrate this potential exploit:

Talks:

  • Invited talk to USA's National Institute of Standards and Technology (NIST) Crypto Reading Club: slides - Taming the Many EdDSAs (pages 28-39), Konstantinos Chalkias, François Garillot, Valeria Nikolaenko (2023). Taming the Many EdDSAs & Ed25519 Signing Attacks.

News and social network coverage of this attack

  • NIST Crypto Reading Club "Taming the Many EdDSAs" (March 08, 2023)
  • The Daily Swig "Dozens of cryptography libraries vulnerable to private key theft" (June 28, 2022)
  • Risky Biz News "New crypto vulnerability: Tens of cryptography libraries have misimplemented the Ed25519 digital signature algorithm" (June 28, 2022)
  • SafeHeron blogpost "Analysis on Ed25519 Use Risks: Your Wallet Private Key Can Be Stolen" (June 17, 2022)
  • kryptera.se "Vulnerability in most ed25519 libraries" (in Swedish) (June 29, 2022)
  • Difesa e Sicurezza & Yoroi "Librerie crittografiche ed25519 potenzialmente non sicure" (in Italian) (July 1 & June 29, 2022)
  • Medium post by Prof Bill Buchanan OBE "Ed25519 is Great, But ..." (July 1, 2022)
  • Reddit r/crypto (best post of the month - June 18, 2022)
  • Reddit r/cryptography (June 17, 2022)
  • Interesting tweets:
    • tweet 1 (by Kostas Kryptos - "The original 26 vulnerable libs")
    • tweet 2 (by Kostas Kryptos - "Aftermath of the 40 vulnerable libs")
    • tweet 3 (by Catalin Cimpanu - "40 cryptography libraries are impacted by same Ed25519 misimplementation")
    • tweet 4 (by Kenny Paterson - "Potential for widespread EdDSA private key recovery, cf. http://kopenpgp.com where same vector exploited in OpenPGP libs")
    • tweet 5 (by Steven Galbraith - "A hazard for deterministic signatures: better check it is the correct public key!")
    • tweet 6 (by Riyaz Faizullabhoy - "If you’re using EdDSA in prod please take a look")
    • tweet 7 (by Bart Preneel - "Reminder that implementing cryptographic algorithms securely and correctly is hard").
  • CTF (capture the flag) challenges that feature this attack:

What is the issue?

Note that normally and according to the related rfc8032, EdDSA signatures are deterministic, and thus for the same input message to be signed, a unique signature output that includes two elements, a curve point R and a scalar S, is returned.

An algorithmic detail is that that signer's public key is involved in the deterministic computation of the S part of the signature only, but not in the R value. The latter implies that if an adversary could somehow use the signing function as an Oracle (that expects arbitrary public keys as inputs), then it is possible that for the same message one can get two signatures sharing the same R and only differ on the S part. Unfortunately, when this happens, one can easily extract the private key; this StackOverflow post post explains why this is feasible.

That said, public apis should NOT allow a decoupled private/public key-pair as signing input. To circumvent that, many implementations store the public key along with the private key (or seed) and consider the whole keypair as the secret OR they always re-derive the public key inside the signing function. Unfortunately, a large number of existing libraries fail to address this issue by allowing arbitrary public keys as inputs without checking if the input public key corresponds to the input private key.

Of course, this does not mean that all applications with dependencies to these libraries are prone to key exposure attacks; actually, most are probably safe due to usually not publicly exposing the affected api to their users and coupling their pub/priv key pair just before the sign invocation. On the other hand, even when these apis are not exposed, there are applications with different TCB threat model strategies on how the private and public keys are managed and stored. That said, to prevent this attack, developers should also enforce an integrity protection protocol for the public keys as well.

Here, we enlist some affected libraries along with the related code-references.

Ed25519 api misuse resulting to key extraction Fig 1. An example api misuse in the ed25519-dalek Rust crate.

Affected libraries

Fixed libraries

False Positives (probably safe)

Libraries originally reported as vulnerable, but removed from the list based on community feedback.