Why Keccak is not ARX

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.

Well, AND and OR "lose information" more than XOR

x.0 is 0 and x+1 is 1 (to use combinational logic notation)

Now XOR(x,y) depend on x and y and there are no values that cause the other value to be ignored

I also think the point they make about speed is kinda picking at straws, it's valid for an FPGA, but not so much for a CPU

Is there marketing when it comes to hashing? That's absurd; it seems more like a hard stop being put to an unfair comparison.

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.

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.

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.

[1] https://danielmiessler.com/study/security-by-obscurity/

[2] https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

There are two schools:

* 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

You might contact them directly via the address listed on their About Us page.

I like the new site. It feels more organized to me.

I’m guessing the article was edited, because now it says “Daniel J. Bernstein”.

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.

In the case of this site, disabling stylesheets will let you read the article while keeping JS disabled.

ARX in this case is referring to Add Rotate XOR, which is a common construction for hash functions. You are referring to the language.

EM radiation and power draw patterns from your device can leak information about what the device is doing. The NSA takes this stuff seriously: https://en.wikipedia.org/wiki/Tempest_(codename)

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.

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

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

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.

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.