New version 1.3 of Argon2

[khovratovich]

The new version addresses the memory optimization attack by Corrigan-Gibbs et al., which allows running Argon2i with 1/3 of required memory for any number of passes without computational penalty.

The main difference is the XOR of the new block into the memory instead of plain overwrite. This tweak not only eliminates the problem with multi-pass Argon2i, but also increases the memory bandwidth thus making it more ASIC-resistant.

The specification contains the analysis of the attack and its status in the new version. It also discusses the recent attack on Argon2i by Alwen and Blocki, showing that for (3 and more)-pass Argon2i it is not efficient.

The update contains new test vectors and the optimized implementation. The new version is 5-10% slower depending on the platform.

[codecov-io]

Current coverage is 79.26%

Merging #115 into master will decrease coverage by -0.31% as of dbe4c5e

@@            master    #115   diff @@
======================================
  Files            9       9       
  Stmts          950     950       
  Branches         0       0       
  Methods          0       0       
======================================
- Hit            756     753     -3
  Partial          0       0       
- Missed         194     197     +3

Review entire Coverage Diff as of dbe4c5e

Powered by Codecov. Updated on successful CI builds.

[hynek]

Since I was on vacation now belatedly: do I understand correctly, that this change invalidates all 1.2 hashes? Is there any intended path forward or how am I supposed to handle this change in my bindings?

[bwesterb]

I have already some argon2 hashes in production... a careless upgrade breaks it, right?

[daniel-dinu]

You just have to regenerate the hash values for the tests you perform.
The changes from branch 1.3 should not affect the implementations of existing bindings in other ways.

[hynek]

How do you mean? If I’ve a production authentication database with Argon2 hashes, I cannot regenerate them for obvious reasons?

---

Unless I’m missing something, Argon2 must detect the version of a hash and act on it accordingly otherwise this is a very dangerous precedent on breaking backward compatibility. I can open a new issue if you prefer, but this looks like a mess to me for everyone that has Argon2 in production already.

For example Django has recently merged Argon2 support and after seeing these breaking changes they’ve indicated they may be inclined to revert that which would be really bad press.

[khovratovich]

Guys,
please do not worry. We will add the version into the encoding string and ensure detection of earlier versions. We will see how best would be to preserver the older code for compatibility.

[daniel-dinu]

Please open an issue.

[hynek]

@khovratovich thanks, that’s exactly what I was about to ask for! :) Sadly the public PHC archives at Gmane are incomplete and I wasn’t subscribed before, so I couldn’t figure out what’s the plan. I won’t update the bindings for now then. Will you do something like a release/announcement/tag once this work is completed?

[jedisct1]

Any idea about how the version is going to be encoded in the string?

[khovratovich]

I guess smth like $argon2i$v=13$m=... for new version, $argon2i$v=12$m=.... or just $argon2i$m=... for 1.2

[jedisct1]

Maybe make it v=1.3, not v=13 in order to avoid confusion when we will reach v1.10.

Unfortunately the current parser code would be unable to parse this.

[jedisct1]

Or better: use ARGON2_VERSION_NUMBER.
Which would then be v=19.

[hynek]

There isn’t much of a reason for the dot anyway since Argon2 doesn’t follow semantic versioning (otherwise 1.3 would be 2 :)).

So how about dropping the dot and just increment integers? I’m sure any really major change would result into Argon3 anyways.