Status update for recommendations

[henrycg]

Status update for recommendations

[henrycg]

There's not a one-size-fits-all answer to this question—it really depends on the specifics of your application. Feel free to email me if you want to discuss further.

[WildCryptoFox]

I'd rather keep this public. Towards Practical Attacks on Argon2i and Balloon Hashing recommends using Argon2i-B.

Edit: @eternaleye pointed me to newer papers: Sustained Space Complexity, Bandwidth-Hard Functions: Reductions and Lower Bounds, and Data-Independent Memory Hard Functions: New Attacks and Stronger Constructions.

I'd rather have the information to do this analysis myself. I could enumerate places where I'd want to use an iMHF but I wouldn't want an answer that doesn't apply to another person.

For what it is worth, I'll list where I'd like to use an iMHF. All client side without cooperation with an external computation service. (2), (3) and (4) may have system-specific parameters but (1) may need global "defaults" with an optional advanced manual configuration due to no client state and an obliviously derived client-secret salt.

1. In a PAKE protocol such as OPAQUE (optionally extended with GenTFA).

2. For full disk encryption; either early in boot when nothing is running; or on a live environment with not too many things running, for recovery.

3. For an encrypted USB which needs to be mountable despite "low" memory available.

4. To unlock a running system or an ssh or PGP key, even under high load on system resources.

[henrycg]

Great. It sounds like you have two independent questions:

Q1. Which hash function should I use?
Q2. Given a choice of hash function, what are the right parameters?

---

On Q1: My sense is that you would probably be safe using any of scrypt, Argon2id, or Balloon. If you care about interoperability, use scrypt or Argon2id, since there are well-maintained and widely used implementations of both of these hash functions.

The people I know who are using Balloon
(i) don't care about interoperability,
(ii) are happy to maintain their own implementation, and
(iii) like how simple the design is and that it works with any underlying cryptographic hash function.
Apparently, because of (iii), the code size of Balloon can be relatively small. This is important in some applications.

Assuming that you do care about interoperability, then you are left with Argon2id and scrypt. Argon2id gives you better protection against certain side-channel attacks. In particular, if an adversary can somehow—through timing or cache attacks—learn the memory-access pattern of the scrypt algorithm as it executes, it can essentially break the memory-hardness of the scrypt function. See Appendix G.2 of the Balloon paper for details. Argon2id does not have this problem.

If you use Argon2i (not Argon2id) then the amortization attacks you cite apply. Argon2id essentially composes Argon2i with an scrypt-like hash function to defeat both the cache and amortization attacks. I view Argon2id as a safe default for this reason. The only downside of Argon2id is that—in the absence of cache attacks—it is not quite as memory hard as pure scrypt. But this feels like a very low-order concern to me.

So, the bottom line is: unless you have a good reason to prefer one of the other designs, I would stick with Argon2id.

On Q2: The right way to set the parameters for any of these functions is to set the memory parameter to the largest value that you can tolerate (with the minimal time parameter). Then increase the time parameter to the largest value you can tolerate. Memory is the expensive resource, so this parameter setting will maximize the attacker's cost, subject to whatever resource constraints you (the defender) have.

You'll have to experiment a bit to find the right setting of the parameters for your application. Before you fix the parameters, make sure that they'll work on all of the different architectures on which your code will need to run.

The Argon2 RFC gives example parameter settings along with a strategy for choosing your own parameters.

[WildCryptoFox]

Q1. I personally fit in that set, and would be willing to contribute implementations to help make it mainstream if there are no cryptographic reasons against BH.

Q2. Fair recommendation, though I guess I should have asked for the conservative lower bounds to avoid naive misuse by consumers?

Thanks for the quick replies!

[WildCryptoFox]

(Added this to the previous comment with the link to the old paper) @eternaleye pointed me to newer papers: Sustained Space Complexity, Bandwidth-Hard Functions: Reductions and Lower Bounds, and Data-Independent Memory Hard Functions: New Attacks and Stronger Constructions.

[WildCryptoFox]

Current verdict. Use Argon2i for now. Maybe accept the tweaks from the latest paper after further analysis is done on it.