RUSTSEC-2022-0093: Double Public Key Signing Function Oracle Attack on ed25519-dalek

[github-actions]

Double Public Key Signing Function Oracle Attack on ed25519-dalek

Details
Package	ed25519-dalek
Version	1.0.1
URL	https://github.com/MystenLabs/ed25519-unsafe-libs
Date	2022-06-11
Patched versions	>=2

Versions of ed25519-dalek prior to v2.0 model private and public keys as
separate types which can be assembled into a Keypair, and also provide APIs
for serializing and deserializing 64-byte private/public keypairs.

Such APIs and serializations are inherently unsafe as the public key is one of
the inputs used in the deterministic computation of the S part of the signature,
but not in the R value. An adversary could somehow use the signing function as
an oracle that allows arbitrary public keys as input can obtain two signatures
for the same message sharing the same R and only differ on the S part.

Unfortunately, when this happens, one can easily extract the private key.

Revised public APIs in v2.0 of ed25519-dalek do NOT allow a decoupled
private/public keypair as signing input, except as part of specially labeled
"hazmat" APIs which are clearly labeled as being dangerous if misused.

See advisory page for additional details.

[MitchTurner]

libp2p currently depends on an old version of ed25519-dalek which has the vulnerability mentioned in RUSTSEC-2022-0093

Until libp2p fixes it on there side, we have to ignore the advisory in .cargo/audit.toml.

The maintainers of libp2p are aware of the [issue(]libp2p/rust-libp2p#4327). Once they release a fix, we can depend on their new version.

[Dentosal]

This can be fixed by updating libp2p dependency to the latest version.

[Dentosal]

Fixed in #1475. Verified with cargo-tree at 04520a6. Nevermind