Looking for a faster cryptographic hash function for embedded devices, I found Edon-R 512 and Blue Midnight Wish 512, both impressively fast. Are they safe for general purpose hashing in hostile environments?

I am especially interested in Edon-R 512, which is faster, but knowing that it came from the same authors as Blue Midnight Wish 512, which was created as a more secure alternative, I expect it to be weaker. Is Edon-R 512 strong enough?

Currently I am using SHA-256, so anything as strong will do. I do not need a hash function at the SHA-3 security level.

  • $\begingroup$ SHA-3 being better suited than SHA-2 for embedded devices is something I know to be true. It seems to me that Edon-R are proposed well before Keccak being standardized as SHA-3, so I suspect you could learn a bit more about using pseudo-random permutations in sponge constructions. $\endgroup$
    – DannyNiu
    Commented Feb 7, 2018 at 10:43
  • 6
    $\begingroup$ "I do not need SHA-3 security level." this makes no sense. SHA-256 and SHA-3-256 have literally the same security level $\endgroup$
    – Biv
    Commented Feb 7, 2018 at 12:01
  • 7
    $\begingroup$ As for your question about Edon-R eprint.iacr.org/2009/378.pdf this makes me say nope nope nope. $\endgroup$
    – Biv
    Commented Feb 7, 2018 at 12:02
  • $\begingroup$ @Biv, well, not everyone might know the formal meaning of that term. For a layman, "security" can mean approximately the same as "not too easy to break", or "as hard to break as X". Besides, isn't SHA-3 immune to length-extension attacks by design, so in that sense it's "more secure" than SHA-2. $\endgroup$
    – ilkkachu
    Commented Feb 8, 2018 at 15:22
  • $\begingroup$ @ilkkachu It's true that SHA-3 is immune to LE attacks (although SHA-512/256 is as well), but SHA-3 is also less secure if you consider password hashing. The reason is that it is rather inefficient in software, but extremely efficient in hardware, making it the worst choice for password hashing. $\endgroup$
    – forest
    Commented Jan 26, 2019 at 3:18

2 Answers 2


Edon-R seems broken, in particular by Peter Novotney and Niels Ferguson's Detectable correlations in Edon-R and (in secret-prefix MAC mode) Gaëtan Leurent's Practical Key Recovery Attack against Secret-IV Edon-R. These attacks got no rebuttal (and attacks only get better; they never get worse); the design did not make it to the SHA-3 competition's second round; a project's archive appears unchanged since November 2008. I thus recommend against using Edon-R.

Blue Midnight Wish, in the variant that made it to the SHA-3 competition's second round (archive), is not broken as far as I can tell. The closest thing to an attack seems to be Gaëtan Leurent and Søren S. Thomsen's Practical Near-Collisions on the Compression Function of BMW (in proceedings of FSE 2011); but they admit that "it does not weaken the security of the iterated hash function" (that is, full BMW); and the rebuttal raises the argument that BMW's double-pipe construction should make it nontrivial to turn a partial collision for the compression function into an attack on the hash. I'd say that if speed was worth living dangerously and far from the mainstream, using Blue Midnight Wish (irrespective of size) could make some sense.

Here's how BMW's elimination from the final SHA-3 round (making BMW history) was justified:

Although BMW has very good software performance, and good potentials for pipelining and area-efficient high-throughput values, a disadvantage of the algorithm is its irregular and not-well-understood design. Since the compression function of BMW does not have a conventional iterated-round structure, there appears to be no obviously simple way to adjust the security margin, or to trade performance for security. Moreover, the attacks on the algorithm, even after an extensive tweak, did not provide confidence in the security of the algorithm. For these reasons, BMW was not selected as a finalist.

Footnote: I second the recommendations in that other answer.


No. These were SHA-3 submissions that did not advance to the final round. Generally they have not been subjected to the same kind of serious scrutiny that the finalists were subjected to. Edon-R did not even make it to the second round, and it's grim. See the other answer for more detailed references about Edon-R and BMW.

Consider using BLAKE2, which is based on the SHA-3 finalist BLAKE, is widely deployed today, is defined in RFC 7693, and tends to provide better performance than SHA-2 or SHA-3.

Alternatively, you might study what you actually need in your protocol, which depends on the details of the protocol. Collision resistance is very expensive—and many applications don't need it. If what you need is a message authentication code, you may be better off with a polynomial evaluation MAC like Poly1305 or GHASH, depending on what resources you have available on your embedded platform.

  • $\begingroup$ I will go with BLAKE2. It would have been nice if these functions were recommendable because they are so far the fastest algorithms implemented in software (bench.cr.yp.to/results-hash.html). $\endgroup$ Commented Feb 7, 2018 at 13:30
  • 2
    $\begingroup$ Sure would be nice! But you really want to pick your security level and choose the cheapest option that confidently attains that security level; otherwise I could give you all sorts of much faster options… $\endgroup$ Commented Feb 7, 2018 at 13:31
  • $\begingroup$ I don't trust me to pick a security level high enough for my applications. Moreover, they are diverse and unrelated. Because my knowledge is limited and I don't want to maintaining a big codebase of cryptographic primitives, I will go with the safer and faster algorithm I find. I was using SHA-256 until now, so anything as strong and fast is OK. $\endgroup$ Commented Feb 7, 2018 at 13:37
  • $\begingroup$ You might also want to check out libhydrogen[1] for an existing library designed for embedded systems. It uses the Gimli permutation as a hash function, which hasn't had a ton of review but does have a very experienced author list. [1]: github.com/jedisct1/libhydrogen $\endgroup$ Commented Feb 7, 2018 at 17:56

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.