Security model: X25519 is designed to be strong as a component of various well-known "hashed DH" applications, and in particular is designed to make the CDH problem difficult with respect to the standard base. Ed25519 is designed to provide EUF-CMA, the standard notion of unforgeability of a signature system under chosen-message attacks. However, some applications need other security notions that are not provided by X25519 and Ed25519.

Security level: X25519 and Ed25519 are more difficult to break by any known attacks than a typical 128-bit cipher. They have an extremely stable security track record, with two decades of research changing security levels by only a fraction of a bit. They also proactively avoid various potential risks. However, large quantum computers will break both X25519 and Ed25519.

Software verification: lib25519 is intended to become a central target for verification of full functional correctness of implementations of X25519 and Ed25519. However, only certain portions have been verified so far, and at this point the code should be presumed to have critical bugs.

API safety: The lib25519 API is systematically designed to simplify correct use and complicate incorrect use. As in the SUPERCOP/NaCl API, inputs and outputs are in wire format rather than requiring conversion to an internal format; signing a message uses simply a secret key, not taking the public key as a separate input; and verification recovers a message from a signed message, not treating the signature as a separate object that one can forget to verify.

Timing attacks: lib25519 is designed to avoid all data flow from secret data to memory addresses and branch conditions. Fully protecting the user against timing attacks requires addressing more issues, such as the following:

See for a timing-attack survey and many references.

Speculative-execution attacks: Some countermeasures against speculative-execution attacks are planned but are not included in the current version of lib25519. Full protection again requires addressing issues at other system layers.

Further side-channel attacks: Even if all legitimate user sensors are successfully kept isolated from attackers, attackers can set up their own power sensors, electromagnetic sensors, acoustic sensors, etc. Keeping cryptographic operations physically separated from sensors tends to make such attacks much more expensive but is often infeasible. "Masking" cryptographic computations seems to help and can be affordable, although the security of masking is difficult to evaluate and there are many broken masked implementations. Currently lib25519 does not include any masked implementations, so presumably it is easily breakable by power attacks in environments where attackers can see power consumption.

Further attacks: lib25519 creates an Ed25519 signing nonce as a hash of the message, a long-term secret, and new randomness (specifically, the nonce is a keyed hash of the message, where the key is the hash of the long-term secret and new randomness). The literature identifies various advantages and disadvantages of including these hash inputs:

lib25519 includes a few further steps that could be useful in stopping fault attacks (for example, signature verification internally converts invalid public keys to the key (...,26), which does not have a known discrete logarithm), but in general lib25519 should be presumed breakable by fault attacks.

Version: This is version 2023.06.21 of the "Security" web page.