I've looked at several hash function specifications, and they all emphasize the need for big-endian byte ordering. Is there a reason for this that has to do with security, or is it simply convention?

  • 3
    $\begingroup$ If I recall correctly, MD5 does use little endian. The prescribed endianess has only functional reasons and no security implications. $\endgroup$
    – j.p.
    Commented Mar 16, 2012 at 7:44
  • 3
    $\begingroup$ Regarding the (non existent) security implications: When Xiaoyun Wang, Dengguo Feng, Xuejia Lai and Hongbo Yu announced that they broke the MD5 on the IACR eprint server (eprint.iacr.org/2004/199) they published by accident a collision for MD5 using the wrong endian internally. The day after they corrected this lapse. $\endgroup$
    – j.p.
    Commented Mar 16, 2012 at 7:58
  • 1
    $\begingroup$ @jug: Would you care to expand your comment into an answer? $\endgroup$ Commented Mar 18, 2012 at 15:06
  • $\begingroup$ When you see big-endianness in a protocol or algorithm nowadays, the odds are that it is following network byte order as defined by IP. Conversely, when you see little-endianness, the odds are that it is an attempt to make things more convenient for the x86. Neither choice has any security consequence. $\endgroup$
    – zwol
    Commented Mar 20, 2012 at 17:44

2 Answers 2


Probably you just looked at the SHA-family of cryptographic hash functions as others (like MD5 and the RIPEMD-family use little endian (see for example this table for the compression functions).

The emphasis on a certain byte ordering is purely functional and not relevant for security (see my 2nd comment to your question).

  • $\begingroup$ You're absolutely right, I didn't do my research :) Thanks much. $\endgroup$
    – pg1989
    Commented Mar 20, 2012 at 1:13
  • $\begingroup$ BLAKE2 and BLAKE3 also use little-endian (BLAKE1 use big-endian) $\endgroup$
    – hanshenrik
    Commented Aug 5, 2020 at 12:56

If we look at the Advanced Hash Standard finalists, we find that 4 of the 5 finalists do not insist on a big-endian byte ordering:

  • Skein uses a little-endian convention internally.

  • Blake uses a big-endian convention internally.

  • Grøstl, JH and Keccak doesn't have any endian-bias (that is, big-endian and little-endian implementations are equally easy).

Here, we don't see any strong bias. I suspect jug is correct; you just looked at the SHA family of hash functions.

  • 2
    $\begingroup$ As the reference machine defined by NIST for the competition was an Intel little endian CPU, it's not a coincidence that most use the little endian convention internally. The first reference implementation of Skein, including the first test vectors, were wrong because of an ordering bug relating to little endian. Somebody just beat me to it reporting it to the authors, but I did send them their corrected test vectors before they got published :) $\endgroup$
    – Maarten Bodewes
    Commented Mar 21, 2012 at 0:06
  • $\begingroup$ * update: blake2 and blake3 use little-endian, blake1 use big-endian $\endgroup$
    – hanshenrik
    Commented Aug 5, 2020 at 12:57
  • $\begingroup$ (to verify, just go to blake2.net/blake2.pdf and search for the first reference of "endian" - i assume they changed it to little-endian for performance reasons, it's cheaper to think in native-endian, and little-endian is the dominant/native endian on most computers these days) $\endgroup$
    – hanshenrik
    Commented Aug 5, 2020 at 14:51

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.