That’s true about pbkdf2, but 6-12GB for phones seems high (not everyone has a flagship).
Those GPU-accelerated attacks have to run through something like 100,000 iterations of pbkdf2 (customizable per account) per test, and they’re salted so any given attack would be specific to an individual user account.
Is anyone else using Argon2 yet? I think LastPass is still pbkdf2.
You’re probably right, though, going forward. PBKDF2 won’t last forever.
You don’t need a “flagship” phone to benefit. Even a few MiB would make all of the difference. And 6GiB is for a 4 year old flagship that I can get for free with a $40/m cellphone plan on a 2 year contract.
100,000 iterations isn’t a whole lot. Modern GPUs can crank through about 50mil hashes per second, which is about 500 passwords a second. Not much, but enough for a dedicated attack. Custom asic can do about 16 trillion hashes per second, which would be 160,000,000 passwords per second.
The bitcoin network is processing about 74 quintillion hashes per second, or at 100k hashes per attempt, about 74 trillion passwords per second.
Instead of GPUs being 1000x faster and asics being 1,000,000x faster than your CPU, they would be about the same speed at best. This is the main issue with pbkdf2. It’s only slow on your device, but fast for attackers. Argon2 levels the playing field.
If there is funding available, I would love to work on this. I have experience with Haxe and could create a polyglot library for using an accelerated version of Argon2 on any platform.
Thanks for keeping the discussion alive! Funding isn’t so much the issue as is engineering time to scope/plan/discuss the implementation plan, since it will touch so many parts of the platform.
Chad is working on prepping for a release this week, so we’ll see if he has any input once he comes up for air 
@tgreer The main concern is getting Argon2 available for all platforms and benchmarking it/figuring out the right settings, correct? I’m overqualified for both of those tasks (I wanted to get a PhD on this topic at one point). If you put up some bounties, I would love to work on it!
Is there any update around argon2?
Hope argon2id support.
Most users of Argon2 use as much memory as possible because memory is usually the bottleneck for attackers. But even using much smaller amounts of memory is helpful. Even using just 128MB would greatly limit an attacker. E.g. a typical top end consumer GPU such as a 3090 which many gamers already own has 10,496 cores to use in parallel but only 24GB RAM, limiting parallelism to 24GB / 128 MB = about 180 - a decline of two orders of magnitude - and that’s an absolute ceiling with the actual limit being probably much lower depending on architecture.
There’s some relevant speculation of the precise limit at hash - Since GPUs have gigabytes of memory, does Argon2id need to use gigabytes of memory as well in order to effectively thwart GPU cracking? - Information Security Stack Exchange
I found the comment on 1Password quite interesting and tried to gather the current state of options that other password managers offer:
| 1Password | PBKDF2-HMAC-SHA256 |
| Dashlane | Argon2d , PBKDF2 |
| GnomeKeyring | PBKDF2 planned, but not implemented |
| LastPass | PBKDF2 with SHA-256 |
| Keepass | AES-KDF, Argon2 |
| KeePassXC | AES-KDF, Argon2 |
| Password Safe | PBKDF2 with SHA-256 |
So, Bitwarden supporting “only” PBKDF2 SHA-256 appears to be quite reasonable by comparison.
Is this planned at all? or is a dead end?
Bitwarden constantly looks at the landscape for the right combination of industry standard and emerging encryption technologies. This is an ongoing endeavor. Argon2 is on our radar screen but not slated for 2022.
@bw-admin Given your response (which implies Bitwarden’s approach may be broader than looking only at Argon2), would you consider merging in the handful of votes from the following request, which provides several suggestions for improving vault encryption?
In addition, please also consider the relevance of the following request, which provides some interesting encryption recommendations specific to iOS:
Thank you!
Encryption
Bitwarden uses AES-CBC 256-bit encryption for your Vault data, and PBKDF2 SHA-256 to derive your encryption key.
AES-GCM vs. AES-CBC
Just use AES-GCM. No contest.
AES-GCM is an authenticated encryption mode. It doesn’t just provide confidentiality by encrypting your message, it also provides integrity (which guarantees that nobody tampered with the encrypted message over the wire).
If you select AES-CBC instead of AES-GCM, you’re opening your systems to a type of attack called a padding oracle (which lets attackers decrypt messages without the key, by replaying altered ciphertexts and studying the behavior of your application).
If you must use AES-CBC, then you must also MAC your ciphertext (and the initialization vector–IV for short). You should also devise some sort of key-separation mechanism so you’re not using the same key for two different algorithms. Even something like this is fine:
encKey := HmacSha256(“encryption-cbc-hmac”, key)
macKey := HmacSha256(“authentication-cbc-hmac”, key)
iv := RandomBytes(16)
ciphertext := AesCbc(plaintext, iv, encKey)
tag := HmacSha256(iv + ciphertext, macKey)
For decryption you need a secure compare function. If one is not available to you, or you cannot guarantee it will run in constant time, a second HMAC call with a random per-comparison key will suffice.
There is no possible world in which case unauthenticated AES-CBC is a safer choice than AES-GCM.
AES-CBC + HMAC-SHA256 (encrypt then MAC) is message-committing and therefore can be safely used with algorithms like OPAQUE.
The Signal Protocol uses AES-CBC + HMAC-SHA2 for message encryption.
I think you should consider changing your encryption method. Maybe to XSalsa20/XChaChaCha
For some reason, I have doubts that you’re actually Soatok, namely because of the lack of a furry profile pic. More importantly, however, nearly the entire post was lifted from https://soatok.blog/2020/07/12/comparison-of-symmetric-encryption-methods/#aes-gcm-vs-aes-cbc, without tailoring any of it to towards what Bitwarden is doing in particular. I also highly doubt Soatok would fail to realize that Bitwarden does in fact use AES-CBC + HMAC-SHA256 (encrypt then MAC), not just plain AES-CBC.
At the moment, Bitwarden might not using the best method of storage. I would like to use the best encryption method available for storing the encryption keys. The encryption keys is used to encrypt our data. On iOS, the best encryption available is Class A: Complete Protection and Bitwarden is not using it. This minor modification would seriously hamper unauthorized attempts to access our data.
The on device iOS data encryption is dependent of the data Protection class key parameter that the app is using. There are 4 types of Data Protection classes:
Since Bitwarden does not specify which one to use it’s using the default one (AFU), the key is decrypted after the first unlock of the device and then stored in the device’s memory endlessly.
I was not aware of Data Protection classes before reading an article about “How Law Enforcement Gets Around Your Smartphone’s Encryption” (yes that’s a pretty click bait title). This article is based on the report of security researchers at Johns Hopkins University about the critical lack in coverage due to under-utilization of the powerful and compelling security and privacy control tools.
Without stating the entire report, it made me aware that the vast majority of apps available are using “Protected Until First User Authentication (a.k.a. After First Unlock) (AFU)” where the encryption keys are decrypted into memory when the user first enters the device passcode after a reboot, and remain in memory even if the device is locked. This practice is sensible to attacks since everybody, I assume, reboot their phones only rarely and the phones are carried in a locked-but-authenticated state. Since Bitwarden does not select a different protection class, it uses the default class (Protected Until First User Authentication).
#encryption and derivation function Argon2id!
it should have twofish or Xchacha20 encryption besides Aes
twofish found unbreakable
@mukesh_Play Welcome!
Argon2 algorithm support has been requested before. See link below.
Maybe you can change the feature request to just Twofish and Chacha20 support, because specific requests tend to get more votes 
Hello everyone and team,
Please add the encryption algorithm xchacha20 to Bitwarden.NordPass already uses this technology I think it would be amazing if Bitwarden get’s this encryption method too.
Best Wishes
