> This is prevented in RFC 8032 by checking that 0 <= s < L
It is, but some libraries do not perform this check. Including TweetNaCl if I recall correctly.
> Modifying A or R instantly makes the signature invalid.
I was talking about modifying them together. Here's what I claim:
B.s = R + A.h
B.s = R + A.h + P - P
B.s =(R + P) + (A.h - P)
And now I'm realising this should work with any point, not just low order points. I'll correct this. Anyway, it's a commutative group we're talking about how could this not work?
> Multiplying the cofactor or not doesn't matter
Perhaps I went over this a bit to fast. Recall that for any low order point P, P.8 = zero. Once you accept this fact, the rest follows pretty smoothly:
And now you can see that the weaker equation will give the same result for R and R+P, if P has low order. Not a weakness if we're only doing signatures, but still a source of malleability.
I'll add this explanation in the article, thanks for the feedback.
>It is, but some libraries do not perform this check. Including TweetNaCl if I recall correctly.
I'm not sure why TweetNaCl is even considered a serious crypto library. I guess that it can fit in tweets, but this is an optimization that is at best irrelevant at worst a bad software engineering practice.
Re malleability: instead of just thinking about this issue in an abstract way, I recommend writing an exploit. For example, Tink doesn't check R or A at all, try to see if you can produce a new signature from an existing one by modifying R or A as you said.
> Re malleability: instead of just thinking about this issue in an abstract way, I recommend writing an exploit.
Challenge accepted! Hmm, doesn't work. Let me think a bit more abou— <facepalm>
Of course: I totally forgot that h is a hash of R and A, not just the message. So if I change them in any way, h's main factor will change unpredictably, and the signature will fail. Looks like the only malleability left is `s`, and that has nothing to do with the cofactor. Let's take the whole section down.
Lesson learned: I should test my writings like I test my code.
---
If I may, you should have lead with "If R or A is changed, h will change." I let myself get worked up by your first comment¹, and failed to notice the single most important sentence near the bottom. I ended up having to reach the same conclusion independently. I almost missed my error.
[1]: You didn't address me directly, and you didn't start with my error. Regardless of your intentions, that felt mildly confrontational. Being nicer would have been more effective.
It is, but some libraries do not perform this check. Including TweetNaCl if I recall correctly.
> Modifying A or R instantly makes the signature invalid.
I was talking about modifying them together. Here's what I claim:
And now I'm realising this should work with any point, not just low order points. I'll correct this. Anyway, it's a commutative group we're talking about how could this not work?> Multiplying the cofactor or not doesn't matter
Perhaps I went over this a bit to fast. Recall that for any low order point P, P.8 = zero. Once you accept this fact, the rest follows pretty smoothly:
And now you can see that the weaker equation will give the same result for R and R+P, if P has low order. Not a weakness if we're only doing signatures, but still a source of malleability.I'll add this explanation in the article, thanks for the feedback.