Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
If I recall correctly, MD5 does use little endian. The prescribed endianess has only functional reasons and no security implications. – j.p. Mar 16 '12 at 7:44
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 ( they published by accident a collision for MD5 using the wrong endian internally. The day after they corrected this lapse. – j.p. Mar 16 '12 at 7:58
@jug: Would you care to expand your comment into an answer? – Paŭlo Ebermann Mar 18 '12 at 15:06
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. – zwol Mar 20 '12 at 17:44
up vote 5 down vote accepted

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

share|improve this answer
You're absolutely right, I didn't do my research :) Thanks much. – pg1989 Mar 20 '12 at 1:13

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.

share|improve this answer
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 :) – Maarten Bodewes Mar 21 '12 at 0:06

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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