# Why use argon2i or argon2d if argon2id exists?

So I am currently working on a GitHub project of mine and I want to implement Argon2. The problem is that I dont really know a lot about it. Internet research is not really helpful, because Argon2 is only 2 years old so all that really exists are scientific papers and that GitHub page.

But before I carry on developing with argon2 I need some important question answered. I will start with the first one :

If Argon2id is the hybrid version of Argon2i and d then why do people even use one of the other two, would it not be more secure to use something that is resistant to side channel attacks and gpu cracking?

• I'd guess Argon2id sacrifices some of its trade-off resistance from Argon2d, so Argon2d should be better in that regard. There may also be some side-channel issues with Argon2id (didn't really dig into that) that may be mitigated by Argon2i. Did you consider reading the specification (PDF on GH) to answer your questions? ;) – SEJPM Jul 7 '17 at 18:36
• It's because Argon2id was added later. Originally there was only Argon2i and Argon2d; and which one you chose depended on whether you were concerned about side-channel attacks. Later they came up with Argon2id; a blend of both i and d. It's nice to remove some ambiguity, and that they recommend id as a baseline. – Ian Boyd Oct 29 '17 at 20:52

The current Argon2 draft RFC, I think, provides a good, reasonably brief answers to this question. TL;DR: most people will indeed want to use Argon2id and not the "pure" variants.

The introduction summarizes the issues quite well:

Argon2 has one primary variant: Argon2id, and two supplementary variants: Argon2d and Argon2i. Argon2d uses data-depending memory access, which makes it suitable for cryptocurrencies and proof-of-work applications with no threats from side-channel timing attacks. Argon2i uses data-independent memory access, which is preferred for password hashing and password-based key derivation. Argon2id works as Argon2i for the first half of the first iteration over the memory, and as Argon2d for the rest, thus providing both side-channel attack protection and brute-force cost savings due to time-memory tradeoffs. Argon2i makes more passes over the memory to protect from tradeoff attacks.

Basically, there are two kinds of attack considered:

1. Side-channel timing attacks.

Argon2d is vulnerable to timing attacks, but offers the best resistance to TMTO (section 9.2):

The best tradeoff attack on $t$-pass Argon2d is the ranking tradeoff attack, which reduces the time-area product by the factor of 1.33.

Argon2i is invulnerable to side-channel timing attacks, but is weaker against TMTO:

The best attacks on the 1-pass and 2-pass Argon2i is the low-storage attack described in [CBS16], which reduces the time-area product (using the peak memory value) by the factor of 5. The best attack on 3-pass and more Argon2i is [AB16] with reduction factor being a function of memory size and the number of passes. For 1 GiB of memory: 3 for 3 passes, 2.5 for 4 passes, 2 for 6 passes. The reduction factor grows by about 0.5 with every doubling the memory size. To completely prevent time-space tradeoffs from [AB16], number $t$ of passes must exceed binary logarithm of memory minus 26.

Argon2id sits in between:

The best tradeoff attack on 1-pass Argon2id is the combined low-storage attack (for the first half of the memory) and the ranking attack (for the second half), which bring together the factor of about 2.1.

Since the Argon2 runtime grows linearly with the number of passes, Argon2i with six passes is about six times as slow as Argon2id with one pass.

The draft RFC also states (without explanation) that Argon2id resists timing attacks, and recommends it as the primary variant, and explicitly telling you (section 4, "Parameter choice") that if you don't know which to use, you should pick Argon2id. You should probably wait until the RFC is approved to fully commit to anything, but in the meantime if you're writing some early code it makes sense to bias things in favor of Argon2id.

• true, but intrestingly PHP7.2 goes pretty straight to argon2i for passwordhashing, which is kinda sad because you are more vulnerable to the tradeoffs, and doesnt have argon2id inside. – My1 Sep 21 '17 at 10:37
• Argon2i isn't the worst outcome, but getting Argon2id in 7.3 would be a good move. Open an RFC today. – Scott Arciszewski Oct 2 '17 at 14:48
• Argon2id is already supported in PHP via the libsodium extension. – Frank Denis Dec 14 '17 at 15:43
• @FrankDenis yes, but 1) the host needs sodium (not every host has that) and the host needs a recent sodium because older sodium versions run on a2i, as far as I grasped the situation (which may be wrong, because I am not very familiar with sodium) – My1 Jan 16 '18 at 12:07
• With the release of PHP 7.3, Argon2id is now officially supported by PHP – Sumit Sep 8 '19 at 19:58