Comment by loup-vaillant | Hacker News Reader

Comment by loup-vaillant | Hacker News Reader

Parent Full thread

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

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

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

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

Reply on news.ycombinator.com