Blocki and Alwen's second attack

[bryant]

Hi,
bryant/argon2rs#18 brought to my attention an attack documented in https://eprint.iacr.org/2016/759.pdf. The paper has been around for a few months now and mentions that t_cost needs to be > 10. However, the t_cost in run.c is still 3. Is this attack a legitimate concern? Should run.c be patched to 10?

[khovratovich]

The paper actually states that if t_cost>10 then the tradeoff attacks bring no advantage to the attacker, whereas for t_cost<10 some advantage can be theoretically gained.

This does not mean that t_cost should be set to 10 or more, because the increase in t_cost already brings advantage to the attacker, and it is much higher that he would get from tradeoffs.

[technion]

Should run.c be patched to 10?

That starts to run for multiple seconds on some machines. That wouldn't be feasible without a very low m, which should be a much bigger vulnerability.

[CodingMarkus]

10 iterations run multiple seconds on some machines? 1000 iterations with 2 threads and 1 MB memory are hardly 0.5 seconds on my machine and my machine is a 5 year old notebook that wasn't even a top model at the day of purchase. So what machines are you referring to? Mobile phones produced before the year 2010? These would probably not be able to execute run.c as allocating 4 MB of RAM isn't going to succeed.

1 MB is not much memory though. It runs for multiple seconds (or potentially much longer) when you're using a lot of RAM. For example, Argon2d with 2 threads, 10 iterations, and 2048 MB takes ~12 seconds on my X250 Thinkpad. With only 1 iteration, it takes around 2.5 seconds. Argon2i would be similar.

For local key derivation, 2-4 seconds is probably acceptable, but 12 is really pushing it.

[CodingMarkus]

But the default of run.c is just 4 MB memory, not 2048 MB, and with that the default of 3 iterations is nothing. That takes 7.5 ms on my machine.

You can always configure all parameters as you like, they are all available as arguments, make them as high or as low as you like, as secure or as insecure as you like, as many rounds as you like, as much memory as you like. IMHO this issue is just about the default parameters (3 rounds is just the default, not the upper bound) and the default parameters are Argon2i, 3 rounds, 4 MB RAM, 1 thread and this combination is not secure; period. If you know that anything <= 10 iterations isn't secure, then how meaningful is it to choose default settings with less than 10 rounds? Why would you like "insecure" default settings? Nobody profits from insecure default settings. Make default settings secure and let users lower security if these safe settings are too expensive for them (that will then be their own responsibility).

So if we make 16 rounds default, we have Argon2i, 16 rounds, 4 MB, 1 thread and this takes 38 ms on my machine (BTW Argon2d only 32 ms, it's even faster).

technion claimed that more than 10 rounds will

start[s] to run for multiple seconds on some machines.

Okay. Let's take a shortcut in this discussion: Please show me a machine where Argon2i, 16 rounds, 4 MB, 1 thread runs multiple seconds. Easy request, should be easy to fulfill if that statement is really true. If you cannot find such a machine, this whole discussion is void and there is no legit reasoning for now increasing the default numbers of rounds to more than 10.

[technion]

@CodingMarkus At that memory and thread use, it doesn't.

We could bikeshed sensible defaults for hours, but I don't see why you're making an issue of this. This is a patched issue.

We're not really even talking about defaults "as typically used" because run.c is just an example of using the library, no one us making system() calls to ./argon2 to generate a hash.

[CodingMarkus]

@technion I didn't make an issue out of this, you made an issue out of this by publishing a false claim that you cannot patch run.c to more than 10 rounds as that wound run multiple seconds on some machines. First of all the claim itself is wrong (you just admitted it to be wrong), second you admit yourself that it wouldn't even matter (even if the claim was correct) as nobody is calling the command line tool in the first place and patching run.c has absolutely not influence on the library or how existing code would use it. So your argument against patching run.c is... correct, non-existent, you have no argument. So next time at least be so honest and say "Yeah, we could do that... but we don't want to. Not that there was any reason, we just don't want to" as that would at least have been the truth and an honest answer to bryant's concerns.

[technion]

@khovratovich Could you please lock this issue. I have intent in responding to aggression.

[khovratovich]

Break.