Home

Awesome

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 <br /> Number of libraries that fixed the issue after the announcement: 8 <br /> last updated: May 04, 2023

Proof of Concept implementations that demonstrate this potential exploit:

Talks:

News and social network coverage of 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.