[bjornedstrom]

Relevant quote from the Ed25519 paper [1] under the heading "Signature System": "This section specifies the signature system used in this paper, and a generalized signature system EdDSA that can be used with other choices of elliptic curves":

> Malleability. We also see no relevance of “malleability” to the standard definition of signature security. For example, if we slightly modified the system then replacing S by −S and replacing A by −A (a slight variant of the “attack” of [75]) would convert one valid signature into another valid signature of the same message under a new public key; but it would still not accomplish the attacker’s goal, namely to forge a signature on a new message under a target public key. One such modification would be to omit A from the hashing; another such modification would be to have A encode only |A|, rather than A.

They key here is the second half of the paragraph: "it would still not accomplish the attacker’s goal, namely to forge a signature on a new message under a target public key".

Similarly how the design doesn't see a problem with malleability in the sense of converting one valid signature into another valid signature, It seems to me it was never a design goal of Ed25519 to begin with to strictly define the set of valid (and invalid) signatures.

This is why cryptography is difficult, because it's easy to use a primitive in a complex system and assume things about the primitives that possibly make them unsuited for the system developed.

[1] https://ed25519.cr.yp.to/ed25519-20110926.pdf

[matthewdgreen]

A general rule is that cryptographers never know what applications’ requirements are, unless we’re also developing those applications. The Ed paper took a very opinionated view on what the requirements should be: out in the real world, it turned out that they were often stronger. This doesn’t mean anyone is “wrong” per se, but it should perhaps be a lesson in humility for people who develop primitives.

[hdevalence]

In this case, simply fixing the problem would have taken the same or less work than writing the quoted paragraph.

[nullc]

At least the paper was extremely clear in that particular respect, often this isn't the case.

[tialaramex]

Over the past decades it's been clear that we should provide the consumers of a cryptographic system with everything they might reasonable expect, rather than define narrowly what we'll set out to do and then surprise the consumer when they actually needed more than was delivered.

AEAD is a big example of that, delivering integrity protection for symmetric encryption that too many engineers never even realised their application required. Moving from the Merkle–Damgård construction to Sponge construction for hashes is one way to deliver another unspecified requirement - preventing length extension attacks.

Way too often in cryptography when somebody is sure that they don't need a big complicated system with a bunch of features it turns out actually they just didn't understand their full requirements, and as those become clear all the baggage they were pleased to be rid of turns out to have been necessary all along.

[Joker_vD]

> it was never a design goal of Ed25519 to begin with to strictly define the set of valid (and invalid) signatures

For a popular enough protocol, if there is an underspecified thing then there will be two implementations that implement that thing differently, and if possible, incompatibly. And I am talking about correctly programmed and compliant implementations, never mind the buggy and/or deliberately non-compliant implementations (cf. Microsoft's "No standard or clause in a standard has a divine right of existence" stance). That's why the designer should not leave the implementers any rope whatsoever to strangle themselves, especially in cryptography.

[formerly_proven]

> That's why the designer should not leave the implementers any rope whatsoever to strangle themselves, especially in cryptography.

5 bits of choice is a lot of rope to auto-asphyxiate oneself in cryptography.