Are Edon-R 512 and Blue Midnight Wish 512 safe/recommendable?

Question

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.

Answer 1

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.

Answer 2

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.