4 ms·

> 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. >

> 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: B.s = R + A.h B.s.8 = (R + A.h).8 B.s.8 = R.8 + A.h.8 B.s.8 = R.8 + A.h.8 + zero B.s.8 = R.8 + A.h.8 + P.8 B.s.8 = (R+P).8 + A.h.8 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.

cryptbe 7y ago
>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.
- beefhash 7y ago
  > I'm not sure why TweetNaCl is even considered a serious crypto library. Probably because its authors are all big-name people and their paper says: > We have placed TweetNaCl into the public domain, and we encourage applications to make use of it.
- loup-vaillant 7y ago
  > 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.

cryptbe 7y ago

>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.

beefhash 7y ago
> I'm not sure why TweetNaCl is even considered a serious crypto library. Probably because its authors are all big-name people and their paper says: > We have placed TweetNaCl into the public domain, and we encourage applications to make use of it.
loup-vaillant 7y ago
> 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.