0
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?
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.
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 – 2017-04-19T00:51:25.980
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 – 2017-04-19T04:21:33.960
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 – 2017-04-19T04:39:44.803
Maybe AES-256-CBC is enough? if it is enough why is PBKDF2 thrown into the mix? – Will-In-China – 2017-04-19T04:58:57.600
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 – 2017-04-19T21:29:25.610
Thank you Abdussamad, Is 30,000 or 10,000 rounds "the default settings" – Will-In-China – 2017-04-19T23:46:48.263
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 – 2017-04-20T00:05:13.673
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 – 2017-04-17T11:01:06.110
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 – 2017-04-17T11:13:55.593
But the 30000 rounds is for PBDKF, not for AES, I assume? – Pieter Wuille – 2017-04-17T12:44:41.227
yes we are passing in the password, iv, rounds and key size to PBKDF2, sorry if I wasn't clear – Will-In-China – 2017-04-17T12:56:33.970
1I'm editing the title. – Pieter Wuille – 2017-04-17T13:12:53.230
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 – 2017-04-17T13:46:23.983
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 – 2017-04-17T13:50:36.083