1
$\begingroup$

According to walkthrough steps for ECDSA topic from wikipedia as shown below, What if the impact if we don't apply the hashing function (highlighted in blue in the image) to the raw messages?

Although this sounds a bit silly, but let's say we have both with or without SHA256 engine test cases like below.

Hex Message (256 bits): "0123456789012345678901234567890123456789012345678901234567890123"

Hex Message after SHA256 (256 bits): "9674d9e078535b7cec43284387a6ee39956188e735a85452b0050b55341cda56"

Can anyone explain what is the problems with the first Hex Message if I proceed with this to the subsequent ECDSA signing flow?

Just assume Alice signed the raw message in this case?

enter image description here

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ Signing raw message isn't unheard of, EdDSA specified in RFC-8032 has such option. Problem being the length of the message is very limited. $\endgroup$ – DannyNiu Nov 18 '20 at 6:13
  • $\begingroup$ So the key point here is using hash function to create the "collision-resistant" same length signature regardless of the message lengths before feeding it into the ECDSA engine? $\endgroup$ – Pi-Turn Nov 18 '20 at 6:41
  • $\begingroup$ Pretty much. Now you can answer your own question and earn some reputation points. $\endgroup$ – DannyNiu Nov 18 '20 at 6:42
  • 1
    $\begingroup$ That's right, it doesn't matter as long as the required collision-resistance is met. One thing to be noted is that compatibility with legacy software/hardware/firmware is also important in the choice, as some older systems weren't built with support for SHA-3, either in the implementation of the algorithm, or in the support for its ASN.1 modules. $\endgroup$ – DannyNiu Nov 18 '20 at 6:59
  • 2
    $\begingroup$ @DannyNiu: "Signing raw message" is unheard of in an EdDSA context, and AFAIK for ECDSA too! PureEdDSA of RFC-8032 does hash the message: "First define r = H(h_b || ... || h_(2b-1) || M)". Difference with HashEdDSA is that it hashes the raw message, rather than a pre-hash. This is radically different from what's envisioned in the question, where there is no hash of the message at all. I second Yehuda Lindell's answer: removing the hash in ECDSA is venturing into uncharted territory. $\endgroup$ – fgrieu♦ Nov 18 '20 at 8:00
2
$\begingroup$

The truthful answer here is that I don't know. I am pretty sure actually that the better answer is that this is unknown. The assumption that the hash is only required for collision resistance is blatantly false, since typically one needs a random oracle for such schemes. In ECDSA specifically, we don't have actually have proof of security even with a random oracle, so it's even worse. However, given that it's been around for so many years, its security is essentially a well accepted assumption. However, as soon as you change something, and not hashing the message is certainly changing something, then it falls apart.

Improve this answer
$\endgroup$
1
  • $\begingroup$ This is consistent with OccamsTrimmer's detailed answer on the status of ECDSA security "proofs". $\endgroup$ – fgrieu♦ Nov 18 '20 at 7:41
1
$\begingroup$

If the only change you make is removing the hashing step, things certainly fall apart. Using the description from Wikipedia you used in your question, this would mean to replace the first step with $e := m$ and then continue with the rest of the steps unchanged.

The second step would then define $z$ as the $L_n$ leftmost bits of $m$. Thus, any messages that differ only in bits further to the right than $L_n$ would immediately collide and thus allow for trivial forgeries.

If you further modify the signature scheme to exclude this type of forgery, e.g. by restricting the message length, Yehuda's answer applies.

Improve this answer
$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.