# Ed25519 - Is there a reason to not trust the signer - i.e. can there be a dishonest signer?

Ed25519 uses a composite order Elliptic Curve but works in the prime order subgroup of the main group. The signing operation should be using a generator/Base Point from the prime order subgroup.

This blog seems to say the following - Honest Ed25519 signers only work in the prime-order subgroup (i.e they chose a generator/Base point from the prime order subgroup). But nothing stops a signer from deviating from the protocol, and generating a verification key with nonzero torsion component (by using input from the cofactor subgroup). In this case, batched verification will succeed but unbatched verification may fail.

I am unable to understand why there is a need to protect against a dishonest signer? Doesn't the whole signing & verification process work on the basis of trusting the signer?

Also, what would the dishonest signer achieve by doing the above dishonesty?

Consider a blockchain, where nodes on the network verify each new block that is announced.

The nodes may be running different software implementations that are attempting to adhere to the same consensus protocol.

Some nodes may be designed to individually verify each transaction in every block received. Other nodes may only perform batch verification on all transactions in the block simultaneously.

If you announce a block containing a transaction that batch verifies but that does not individually verify, you will now have created a fork in the blockchain.

This would make it easier to mount a 51% attack on the network. Some miners will be attempting to announce newly mined blocks based on a prior block that much of the rest of the network will consider invalid.

• I read through the blog again & it looks like problem created by the dishonest signer will be only for unbatched verification & not for batched verification - and the batched equation is always satisfied & However, a verifier using the unbatched equation will accept the signature only if 8 divides k. Assuming that blockchain use case uses batched verification, this won't trigger a DOS, I think Sep 13, 2022 at 8:28
• @user93353 You're right, I thought of a scenario in the other direction. I've amended the answer so it's the other way around. Sep 13, 2022 at 9:26
• I'm still wondering why nobody argued about the RFC to make is standard.. Sep 13, 2022 at 20:51

More generally, sometimes untrusted parties are given access to a signing oracle. For example, in blind signatures, it's super important to check the point belongs to the right subgroup. Otherwise, overtime, the key could be recovered.