Here's an tweet from Jean-Philippe Aumasson, one of the authors of BLAKE(2) (uses ChaCha ARX construction) and NORX (uses modified ChaCha replacing addition with an approximation based on XOR, AND, shift operations):
Ok but, in reply to that tweet, one point keccak.team make, which seems valid for non-classified cryptanalysis, is that researchers don't invest time in trying to analyse ARX because the propagation of addition makes it too complicated.
One thing I got from that is that ARX designs are less likely to be broken, not because they are necessarily more secure, but because ARX is often less analysed than designs which yield more concise mathematical representations.
Shots fired indeed, although the 132-character argument is a bit of a straw man; the original argument was that using ARX operations in cryptographic primitives makes it harder to analyze the primitive, regardless of whether the actual weakness is in a boolean or an ARX operation.
The final line refers to agl' "maybe skip SHA-3" blogpost. I think there is a lot of FUD about SHA-3 (including SHAKE) being too slow for mortals to use, I'm guessing the Keccak team is pushing back with some marketing. Honnestly this is how the world works. Nobody understand anything about crypto and people take decisions based on standards and public opinions (which are often based on articles and blog posts). If you want your primitive to have some weight, you have to give people an excuse to use it.
To be honest, if I'd design something this elegant, and nobody considers if because of an irrelevant attack, I'd be very sore and alert for it happening again, too.
It is however a fact that several cryptographers are moving away from ARX. Some do that for hardware efficiency (e.g., as promoted by NORX designers), some do that to better estimate impacts of differential cryptanalysis (e.g., MD6, probably Gimly too?).
The post makes those points more explicitly to our attention than any other post I had seen before. Hence, no FUD to me.
Hashing is pretty much a market for lemons - the adopting user is confronted by a complex math they don't understand and there is a definite problem if you drive out with the wrong hash function. And there is no way to tell without actually being miles down the road when you find out whether it was a peach or a lemon.
The choice by a user might come down to the same sort of vague arguments in a used car lot - "I hear Hondas don't break down much".
There's always some "academic influencing" to do more research based off your own papers, which in turn drives more grants to your own branch of research. At least that's what I read off the following quote
> "We feel that the cryptanalysis of more structured designs such as Rijndael/AES or Keccak/SHA-3 leads to publications that provide more insight."
Previous to this I did sha256, and I have to say that the Keccak algorithm was a bit easier to reason about ( as to what it was doing at the bit level, and why )...at least it was for me.
> (...) (crypt)analyzing ARX, despite its merits, is relatively unrewarding in terms of scientific publications: It does not lend itself to a clean mathematical description and usually amounts to hard and ad-hoc programming work. A substantial part of the cryptographic community is therefore reluctant to spend their time trying to cryptanalyze ARX designs. We feel that the cryptanalysis of more structured designs such as Rijndael/AES or Keccak/SHA-3 leads to publications that provide more insight.
The nuance that's being made here is that the public cryptanalytic results we have are from researchers that need to publish. However blackhats (be it government or private) have no such need. Thus, they do not care if the analysis is elegant or neat.
This means that ARX functions will have less published analysis, but may still be successfully attacked.
This isn't even a new argument they're making here. It's been well understood that simple cipher designs are better, because they are easier to understand. If you can understand it well, yet not break it, that gives confidence. If you don't understand it, it might break as soon as you do.
While security by obscurity might be a valid security layer in some systems [1], it rarely is considered a good one when designing cryptosystems; Kerckhoff's principle [2] is usually adhered to thoroughly.
* make your cipher complicated, so that analysis and attacks are hard
* make your cipher easier to analyze and attack
The second one usually brings more confidence in the strength of the algorithm after a long period of peer review and cryptanalysis.
PS: not sure but I think I remember reading that Ketje was designed specifically to make theoretical attacks and analysis easier: https://keccak.team/ketje_contest.html
Please, please darken your font color. The contrast is so bad that it makes my eyes hurt. I actually had to pop dev tools and tweak your css to make this site readable.
The old site from the keccak team was nice, light, easy to use (you could easily find the paper or post that you wanted) and cute. The new one can't even be accessed with js disabled. Why that huge step backwards?
And referring to DJB just by his twitter handle, seriously?
For better or worse, javascript (enabled) is now an expected feature in all browsers, just like HTML and CSS; if you browse with it disabled, you can expect many things to break and don't really have cause for complaint.
And yet if you browse this website with CSS also disabled, you get to enjoy the content without the pointless, distracting, time-consuming, and resource-wasting full-page second loading indicator (the browser already includes one!) and animations.
"But even software ARX gets into trouble when protection against power or electromagnetic analysis is a threat." - I still don't get this. If attackers have physical access to your machine, you should consider it compromised. Switching from SHA2 to SHA3 is irrelevant.
>If attackers have physical access to your machine, you should consider it compromised.
This bit of "wisdom" dates back to the very, very old days when security wrt computers was primarily a consideration for servers in physically secure locations. It is utterly obsolete, and every more so with each passing year. HSMs, CPU-level trusted modules, etc. have long since been a thing, as for that matter has even basic software measures like FDE. All exist in part or in whole to help with certain kinds of physical access. It is not in fact straight forward, reliable or for most attackers even possible to pull bits directly off a well designed physically secure chip with an STM or whatever.
I don't think looking back the actual weaknesses in MD5/SHA were related to ARX, but I'm not equipped to judge whether ARX might introduce TEMPEST related issues. It is not a fundamentally invalid consideration however. Side-channel attacks are one of the most classic and fiendishly difficult issues in cryptography and EM emissions are a known domain problem that can't always be solved merely via use of shielding. It's better even then to have it considered right down the primitive level. Layers and all that.
There are plenty of real-world examples that are hardened against physical access; smartcards are the most ubiquitous example. You ought not be able to recover key material from a smart card just by analyzing the power-draw, or you could skim chips just as easily as stripes.
There are situations where an attacker doesn't have full physical access to a device but can still observe EM radiation. For example, someone sitting next to you with an EM receiver, observing emissions from your 2FA token.
There is a subtle cargo cult fallacy that occurs in many crypto construction competitions: that resource light (time, RAM & operations) in hw/sw is "good." Certainly, minimum performance is necessary but being too cheap means brute-forcing is also cheaper. I wish resource-adaptive algorithms that require a minimum of RAM and ops in both hw and sw optimized implementations a-la scrypt were the rule, not the exception.
State actors can easily afford ASIC AES and SHA2 brute-force farms, and that's a concern, especially with monocultural recommendations to "always use AES/SHA2." Now that Keccak's been chosen as the basis for SHA3 in-lieu of more hw expensive alternatives like ECHO, the cost of cracking has been reduced for future scenarios. Do we really want to slash the security margin for a modest bump in runtime performance?
When one hash is a billion times too fast to securely store passwords, and another hash is ten billion times too fast to securely store passwords, the speed difference doesn't matter.
All the hashes you'd care to look at are within an order of magnitude of speed. They all need to be repeated a very large number of times to fight brute forcing. Using more repetitions for a faster hash is so utterly trivial it's not even worth mentioning in the context of security. There is zero difference in security margin from the speed of a hash.
And yes, memory-intensive algorithms are good for passwords, so you shouldn't be caring about normal hashes at all.
Brute force is irrelevant in hashing. The faster the better.
PS: this is because the complexities for attacks are too high. For SHA-3-256 you need 2^128 operations to approach finding a collision. Whatever your speed you will never reach this amount of computation (or storage).
You've confused password hashes with general-purpose cryptographic hashes. The latter is a building block of the former. SHA-3 is the latter: a general-purpose hash.
Here's an tweet from Jean-Philippe Aumasson, one of the authors of BLAKE(2) (uses ChaCha ARX construction) and NORX (uses modified ChaCha replacing addition with an approximation based on XOR, AND, shift operations):
"where @KeccakTeam misses a big point: MD5 and SHA-1 got broken because of Boolean operations (AND/OR), not because of ARX operations" https://twitter.com/veorq/status/910255284920180736