Struct fwsig::types::PublicKey

prehashed_message is an instantiated hash digest with 512-bits of output which has had the message to be signed previously fed into its state.
context is an optional context string, up to 255 bytes inclusive, which may be used to provide additional domain separation. If not set, this will default to an empty string.
signature is a purported Ed25519ph [Signature] on the prehashed_message.

Returns

Returns true if the signature was a valid signature created by this Keypair on the prehashed_message.

source

pub fn verify_strict(
 &self,
 message: &[u8],
 signature: &Signature
) -> Result<(), Error>

Strictly verify a signature on a message with this keypair’s public key.

On The (Multiple) Sources of Malleability in Ed25519 Signatures

This version of verification is technically non-RFC8032 compliant. The following explains why.

Scalar Malleability

The authors of the RFC explicitly stated that verification of an ed25519 signature must fail if the scalar s is not properly reduced mod \ell:

To verify a signature on a message M using public key A, with F being 0 for Ed25519ctx, 1 for Ed25519ph, and if Ed25519ctx or Ed25519ph is being used, C being the context, first split the signature into two 32-octet halves. Decode the first half as a point R, and the second half as an integer S, in the range 0 <= s < L. Decode the public key A as point A’. If any of the decodings fail (including S being out of range), the signature is invalid.)

All verify_*() functions within ed25519-dalek perform this check.

Point malleability

The authors of the RFC added in a malleability check to step #3 in §5.1.7, for small torsion components in the R value of the signature, which is not strictly required, as they state:

Check the group equation [8][S]B = [8]R + [8][k]A’. It’s sufficient, but not required, to instead check [S]B = R + [k]A’.

History of Malleability Checks

As originally defined (cf. the “Malleability” section in the README of this repo), ed25519 signatures didn’t consider any form of malleability to be an issue. Later the scalar malleability was considered important. Still later, particularly with interests in cryptocurrency design and in unique identities (e.g. for Signal users, Tor onion services, etc.), the group element malleability became a concern.

However, libraries had already been created to conform to the original definition. One well-used library in particular even implemented the group element malleability check, but only for batch verification! Which meant that even using the same library, a single signature could verify fine individually, but suddenly, when verifying it with a bunch of other signatures, the whole batch would fail!

“Strict” Verification

This method performs both of the above signature malleability checks.

It must be done as a separate method because one doesn’t simply get to change the definition of a cryptographic primitive ten years after-the-fact with zero consideration for backwards compatibility in hardware and protocols which have it already have the older definition baked in.