<blockquote>
<p>Can I safely reduce the rounds to make it a bit faster? and if so what would be the minimum?</p>
<p>Could I get away with 10,000?</p>
</blockquote>
<p>Anyone trying to crack your encrypted data is not going to be limited by the speed of javascript executing in a browser. They'll be running FPGAs or something much faster than that. So 20,000, 10,000 or 0 doesn't make any sort of difference here.</p>
<p><a href="https://bitcointalk.org/index.php?topic=812894.msg10907427#msg10907427" rel="nofollow noreferrer">Where I learned this</a></p>

CC BY-SA 3.0
2017-04-19T00:51:25.980Z
So your saying PBKDF2 is a waste of time and I shouldn't even bother? Should I be looking at Scrypt or Bcrypt?
Will-In-China
CC BY-SA 3.0
2017-04-19T04:21:33.960Z
That's not what i mean at all. I mean a low number of key stretching rounds isn't worth anything. You can't get a high number because javascript is slower than C compiled code and much slower than FPGAs. If you see that link G Maxwell talks about how Core does 200,000 rounds using just one CPU core. That's possible because its coded in C++.
Abdussamad
CC BY-SA 3.0
2017-04-19T04:39:44.803Z
So your saying 10-20,000 rounds in a browser isn't worth doing. As I'm stuck in the browser for this project, I guess I shouldn't bother with PBKDF2 or should I approach this problem differently?
Will-In-China
CC BY-SA 3.0
2017-04-19T04:58:57.600Z
Maybe AES-256-CBC is enough? if it is enough why is PBKDF2 thrown into the mix?
Will-In-China
CC BY-SA 3.0
2017-04-19T21:29:25.610Z
a key derivation function is used to derive a random number from a password. you run a kdf multiple times in order to make it harder for someone else to try and bruteforce your password. AES is an encryption algorithm. You use the output of the KDF to encrypt your file using AES. that's how the two fit in. My suggestion is to leave it at the default settings or if that is too slwo then lower the number of rounds. The most important thing you can do is just use a good password. Everything else is fluff.
Abdussamad
CC BY-SA 3.0
2017-04-19T23:46:48.263Z
Thank you Abdussamad, Is 30,000 or 10,000 rounds "the default settings"
Will-In-China
CC BY-SA 3.0
2017-04-20T00:05:13.673Z
if I force the user to enter a 9+ character password with upper, lower and special characters, would 1000 rounds be enough?
Will-In-China
CC BY-SA 3.0
2017-04-18T23:13:57.090Z
2017-04-18T23:13:57.090Z
2020-06-16T11:10:03.350Z
Abdussamad
<p>In the browser, I'm using AES-256-CBC with 128bit IV &amp; PBKDF2 to encrypt the mnemonic</p>

<pre><code>"tell file snow green proof evil six squeeze budget various orbit clock" 
</code></pre>

<p>with a password </p>

<pre><code>"s0mesuperl0ng!password@!" 
</code></pre>

<p>with 30,000 rounds it's taking roughly 22 seconds. It feels too long, but I don't want to make it insecure. </p>

<p>Can I safely reduce the rounds to make it a bit faster? and if so what would be the minimum? </p>

<p>Could I get away with 10,000?</p>

CC BY-SA 3.0
2017-04-17T11:01:06.110Z
Why do you need multiple rounds of AES? Is this some form of key strengthening? Also 1400 rounds of AES is extremely slow, what software are you using?
Pieter Wuille
CC BY-SA 3.0
2017-04-17T11:13:55.593Z
This is just with JavaScript in the browser, the reason for the multiple rounds is to slow down a brute force attack and the use of PBKDF2 is to strengthen the password.
Will-In-China
CC BY-SA 3.0
2017-04-17T12:44:41.227Z
But the 30000 rounds is for PBDKF, not for AES, I assume?
Pieter Wuille
CC BY-SA 3.0
2017-04-17T12:56:33.970Z
yes we are passing in the password, iv, rounds and key size to PBKDF2, sorry if I wasn't clear
Will-In-China
CC BY-SA 3.0
2017-04-17T13:12:53.230Z
I'm editing the title.
Pieter Wuille
CC BY-SA 3.0
2017-04-17T13:46:23.983Z
I'm not an expert here, but AFAIK there isn't a bright line between "secure" and "insecure" and there's no well-defined minimum that is "safe".  Increasing the number of rounds causes a proportional increase in the amount of work a brute-force attacker would have to do, but also means verification will take longer.  It's simply a trade-off and you have to balance the patience of your users against the amount of resources you think an attacker might be willing to commit.
Nate Eldredge
CC BY-SA 3.0
2017-04-17T13:50:36.083Z
Nate, I totally agree, I was looking for some opinion on this gray area, I found 10,000 rounds at about 8 seconds reasonable, but I was looking for a reaction, like "hell no" or "10k seems cool" or the lowest I'd go is "x"
Will-In-China
<cryptography>
Is 30,000 rounds really needed for PBKDF2?
Will-In-China
# Is 30,000 rounds really needed for PBKDF2?

(Asked by: username_0 on 2017-04-17)

In the browser, I'm using AES-256-CBC with 128bit IV & PBKDF2 to encrypt the mnemonic

```
"tell file snow green proof evil six squeeze budget various orbit clock" 

```

with a password

```
"s0mesuperl0ng!password@!" 

```

with 30,000 rounds it's taking roughly 22 seconds. It feels too long, but I don't want to make it insecure.

Can I safely reduce the rounds to make it a bit faster? and if so what would be the minimum?

Could I get away with 10,000?

**Tags:** cryptography

> **Comments:**
> **username_1**: Why do you need multiple rounds of AES? Is this some form of key strengthening? Also 1400 rounds of AES is extremely slow, what software are you using?  
> **username_0**: This is just with JavaScript in the browser, the reason for the multiple rounds is to slow down a brute force attack and the use of PBKDF2 is to strengthen the password.  
> **username_1**: But the 30000 rounds is for PBDKF, not for AES, I assume?  
> **username_0**: yes we are passing in the password, iv, rounds and key size to PBKDF2, sorry if I wasn't clear  
> **username_1**: I'm editing the title.  
> **username_2**: I'm not an expert here, but AFAIK there isn't a bright line between "secure" and "insecure" and there's no well-defined minimum that is "safe".  Increasing the number of rounds causes a proportional increase in the amount of work a brute-force attacker would have to do, but also means verification will take longer.  It's simply a trade-off and you have to balance the patience of your users against the amount of resources you think an attacker might be willing to commit.  
> **username_0**: username_2, I totally agree, I was looking for some opinion on this gray area, I found 10,000 rounds at about 8 seconds reasonable, but I was looking for a reaction, like "hell no" or "10k seems cool" or the lowest I'd go is "x"  

---

## 1 answers

### Answer by username_3 on 2017-04-18. Score: 1

> Can I safely reduce the rounds to make it a bit faster? and if so what would be the minimum?
>
> Could I get away with 10,000?

Anyone trying to crack your encrypted data is not going to be limited by the speed of javascript executing in a browser. They'll be running FPGAs or something much faster than that. So 20,000, 10,000 or 0 doesn't make any sort of difference here.

[Where I learned this](https://bitcointalk.org/index.php?topic=812894.msg10907427#msg10907427)

> **Comments:**
> **username_0**: So your saying PBKDF2 is a waste of time and I shouldn't even bother? Should I be looking at Scrypt or Bcrypt?  
> **username_3**: That's not what i mean at all. I mean a low number of key stretching rounds isn't worth anything. You can't get a high number because javascript is slower than C compiled code and much slower than FPGAs. If you see that link G Maxwell talks about how Core does 200,000 rounds using just one CPU core. That's possible because its coded in C++.  
> **username_0**: So your saying 10-20,000 rounds in a browser isn't worth doing. As I'm stuck in the browser for this project, I guess I shouldn't bother with PBKDF2 or should I approach this problem differently?  
> **username_0**: Maybe AES-256-CBC is enough? if it is enough why is PBKDF2 thrown into the mix?  
> **username_3**: a key derivation function is used to derive a random number from a password. you run a kdf multiple times in order to make it harder for someone else to try and bruteforce your password. AES is an encryption algorithm. You use the output of the KDF to encrypt your file using AES. that's how the two fit in. My suggestion is to leave it at the default settings or if that is too slwo then lower the number of rounds. The most important thing you can do is just use a good password. Everything else is fluff.  
> **username_0**: Thank you username_3, Is 30,000 or 10,000 rounds "the default settings"  
> **username_0**: if I force the user to enter a 9+ character password with upper, lower and special characters, would 1000 rounds be enough?  

---

