To quote Ilari on the CFRG mailing list:

e.g. the vile mess that is ECDSA with SHA-3

I have some ideas what he might mean but I couldn't find the discussion so what is that mess?

  • $\begingroup$ What is CFRG? Do you have a link? $\endgroup$
    – kodlu
    Aug 23, 2022 at 6:43
  • $\begingroup$ mailarchive.ietf.org/arch/msg/cfrg/Wlm5VBoHcrOtUeVDtHaIt8i3DMk $\endgroup$
    – Elias
    Aug 23, 2022 at 6:48
  • 1
    $\begingroup$ @kodlu Crypto Forum Research Group. It's an IETF thing. $\endgroup$ Aug 23, 2022 at 7:34
  • 4
    $\begingroup$ There is a mailing list and a mail address of the author of that post. Why not contact them instead of asking here? A well addressed question is likely to get an answer, and we cannot know the author's intent. $\endgroup$
    – Maarten Bodewes
    Aug 23, 2022 at 9:13

1 Answer 1


The issue seems to be that ECDSA uses bit strings in several places, and SHA-3 uses a surprising bit-string to octet-string conversion. This is exacerbated by the fact that the ECDSA spec is not freely available.

The strangeness of SHA-3 seems to be that the bit order in which SHA-3 expects bytes requires flipping them around compared to the bit order that is used pretty much everywhere else. In other words, the messages are defined as bits but computers deal with bytes so if you change MSB/LSB of the message you not only need to change endianness but you need to flip all the bytes around.

I cannot easily verify this but it's worth being aware of for implementations so I am posting it anyway.

  • 9
    $\begingroup$ The modern ECDSA spec is available in SEC1. Standard curves are in SEC2. What would be parameters or circumstances where the problem that you mention happens? AFAIK the only thing that ECDSA hashes is the message, and as long as these are bytes, there won't be a problem at the input. So I see no link between whatever peculiarity SHA-3 has on input, and ECDSA. $\endgroup$
    – fgrieu
    Aug 31, 2022 at 17:33
  • 3
    $\begingroup$ Yeah, same objection worded differently: as long as the input & output in bytes is specified by the algorithm, it doesn't matter if it is big or little endian internally. To me it was a mistake to require the SHA-3 algorithms to be specified in little endian even though x86 is little endian and ARM almost always runs in little endian mode. However, in the end that doesn't make a difference as long as the input & output is binary & canonical. The same input in bytes will always generate the same output in bytes, indexed zero to the output size. $\endgroup$
    – Maarten Bodewes
    Feb 26, 2023 at 12:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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