It’s 255:19AM. Do you know what your validation criteria are?
1–10 of 32 posts
Re: It’s 255:19AM. Do you know what your validation criteria are?
#2I would recommend using a 24-hours clock, not AM/PM 256-hourglasses. There is also the outrageously absurd idea of putting units next to your entry fields so users know to enter metric values instead of furlongs.
Re: It’s 255:19AM. Do you know what your validation criteria are?
#3I would recommend using a 24-hours clock, not AM/PM 256-hourglasses. There is also the outrageously absurd idea of putting units next to your entry fields so users know to enter metric values instead of furlongs.
Are you being sarcastic? The title is clearly chosen so that it makes the number 25519 in reference to the algorithm.
Re: It’s 255:19AM. Do you know what your validation criteria are?
#4I would recommend using a 24-hours clock, not AM/PM 256-hourglasses. There is also the outrageously absurd idea of putting units next to your entry fields so users know to enter metric values instead of furlongs.
I would simply take 255 modulo 24 and use 15 rather than require the user to enter a so-called "canonical" encoding of an hour.
Re: It’s 255:19AM. Do you know what your validation criteria are?
#5Relevant 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.
Re: It’s 255:19AM. Do you know what your validation criteria are?
#6Relevant 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…
> 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.
Re: It’s 255:19AM. Do you know what your validation criteria are?
#7I would recommend using a 24-hours clock, not AM/PM 256-hourglasses. There is also the outrageously absurd idea of putting units next to your entry fields so users know to enter metric values instead of furlongs.
It's also relevant to the topic because some of the issues its discussing relate to how over full inputs are validated.
Do you reduce the 255 mod 24 to decide if the time is acceptable, or do you just reject anything over 23 as unreasonable... or maybe you only reject larger than 99 (because two digits is enough) but from 23 and 99 you reduce mod 24.
In many kinds of programs it isn't too critical exactly how you handle unreasonable inputs. Garbage in Garbage out. In consensus systems, however, any difference in behaviour can be a fatal vulnerability.
Some might find the motivation section of Bitcoin's BIP340 informative: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawi...
Or this earlier publication: https://slowli.github.io/ed25519-quirks/ (which has more explanation for the S value related issues that the parent article mostly skips over-- but lacks the breadth and the amazing illustration of the incompatibility train-wreak).
Re: It’s 255:19AM. Do you know what your validation criteria are?
#8This is very nice work. For those who are interested in academic work about detecting/preventing such attacks, there have been some recent papers that looked at the formal verifying protocol models [1, 2] to (dis)prove the absence of such vulnerabilities.
1. https://eprint.iacr.org/2019/779 2. https://eprint.iacr.org/2020/823
Re: It’s 255:19AM. Do you know what your validation criteria are?
#9I'm curious, does ECDSA provide this? Not a crypto expert.
Re: It’s 255:19AM. Do you know what your validation criteria are?
#10Relevant 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…
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.