Keystore generated by ethers.js takes time to unlock vs Parity keystore is quick

[zemse]

Also raised #11571 in openethereum.

Keystore generated by parity account new:

Parity Keystore
{"id":"d24503a6-8847-199e-fa5e-cf2859e48bb6","version":3,"crypto":{"cipher":"aes-128-ctr","cipherparams":{"iv":"88decf833914efe2897083b3b2400ab0"},"ciphertext":"472d8a51e054374463d016c682102649d8cf56dfbd6cbfa4f04e849e9e30f5d2","kdf":"pbkdf2","kdfparams":{"c":10240,"dklen":32,"prf":"hmac-sha256","salt":"3923cf5f23f653b79ca71134fd974a001bb6adf608fa7020c1f9f345f741c26d"},"mac":"4789351f22f0d74f937699b7579e4786890fdb5b89884583ca8dd2d56bb969dc"},"address":"36560493644fbb79f1c38d12ff096f7ec5d333b7","name":"","meta":"{}"}

Keystore generated using ethers.js library:

Custom keystore (generated using ethers.js):
{"id":"f786d469-b7ef-4dce-9a19-d67437c1f4dc","version":3,"crypto":{"cipher":"aes-128-ctr","cipherparams":{"iv":"88c0756012bb0e104a19472e1dfebd13"},"ciphertext":"6e1df9d2866b8e2fe126f45d0f371035facebee8e7c1d06605b3d7bb81403144","kdf":"scrypt","kdfparams":{"dklen":32,"p":1,"n":131072,"r":8,"salt":"9b63e8032242bf78c9a0aeaabd2f05fb75a34851472056a46b20352ca57516ef"},"mac":"0928b53c317cca2252ff4b60c7ef2b6b2a3d9a47783e5c33beecdb56d7862aca"},"address":"c8e1f3b9a0cdfcef9ffd2343b943989a22517b26","name":"","meta":"{}"}

The password for both keystores is "12" exclusive of inverted commas. If you try unlocking both keystores, the parity keystore is unlocked quickly while Ethers.js keystore takes lot of time to get unlocked.

When I load the custom keystore in the keys folder, and start parity with unlock flag followed by wallet address (0xc8e1f3b9a0cdfcef9ffd2343b943989a22517b26) it takes a while for parity to first load up

2020-03-16 10:14:36 UTC Starting Parity-Ethereum/v2.7.2-unstable-55c90d401-20200205/x86_64-unknown-linux-gnu/rustc1.39.0
2020-03-16 10:14:36 UTC Keys path /tmp/parity0/keys/Era_Swap_Network
2020-03-16 10:14:36 UTC DB path /tmp/parity0/chains/Era_Swap_Network/db/54aabb10bc00d84f
2020-03-16 10:14:36 UTC State DB configuration: fast
2020-03-16 10:14:36 UTC Operating mode: active
2020-03-16 10:15:21 UTC Not preparing block; cannot sign.

You can see about 45 seconds to unlock the keystore.

But when I use a keystore generated by parity account new (0x36560493644fbb79f1c38d12ff096f7ec5d333b7), the unlock is very quick..

Starting Parity-Ethereum/v2.7.2-unstable-55c90d401-20200205/x86_64-unknown-linux-gnu/rustc1.39.0
2020-03-16 10:16:01 UTC Keys path /tmp/parity0/keys/Era_Swap_Network
2020-03-16 10:16:01 UTC DB path /tmp/parity0/chains/Era_Swap_Network/db/54aabb10bc00d84f
2020-03-16 10:16:01 UTC State DB configuration: fast
2020-03-16 10:16:01 UTC Operating mode: active
2020-03-16 10:16:01 UTC Not preparing block; cannot sign.

Due to the time taken for unlocking the keystore, the node wasn't able to author any block using the slow keystore. And it gets stuck on the block which has it's turn to author.

I tried hard to spot the difference in both keystores, only saw that the quick keystore had the kdfparams including c property while the slower one didn't have.

Is there a way to generate a fast unlocking keystore like the one parity generates?

[zemse]

@ricmoo I'm looking for an easy way to generate a keystore with pbkdf2 as the key derivation function. I was checking out the encrypt function inputs, I saw an options field and I had some hopes through that. Though I checked the line 412 function in the library but it seems that by default the kdf is scrypt.

Can you please put some light to this? Also is pbkdf2 obsolete or something?

[ricmoo]

Heya! Sorry for the delay, I was adding some notes to the documentation to better explain this phenomenon.

Please check out this link: https://docs-beta.ethers.io/concepts/security/#security-pbkdf

The pbkdf2 is certainly not one anyone should still be using, since scrypt is far more reliable in its tuning. The above documentation explains how to get a faster wallet, while also explaining it is a really bad idea to do so. :)

Anyways, check it out and let me know if you have any questions, suggestions, etc. :)

[zemse]

Thanks @ricmoo for adding that!

Just ran some benchmarks on my system.

> w = ethers.Wallet.createRandom();
> checkTime = async nvalue => {
    const t1 = Date.now();
    x = await w.encrypt('qw',{N:nvalue});
    const t2 = Date.now();
    await ethers.Wallet.fromEncryptedJson(x, 'qw');
    const t3 = Date.now();
    return {encrypting: (t2-t1)/1000, decrypting: (t3-t2)/1000}
}

> await checkTime(64);
Object { encrypting: 18.59, decrypting: 31.593 }

> await checkTime(1);
Object { encrypting: 18.748, decrypting: 19.505 }

> await checkTime(1024);
Object { encrypting: 18.092, decrypting: 31.697 }

> await checkTime(2**17);
Object { encrypting: 30.263, decrypting: 19.249 }

> await checkTime(2**54);
Object { encrypting: 55.396, decrypting: 19.344 }

Looks like even having lower N is not reducing the difficulty. Am I doing something wrong?

The nodes I'm working only has 4 seconds to author a block, maybe this might be the reason parity is still on pbkdf2 instead of upgrading to scrypt. Does it make sense adding pbkdf2 to ethers.js or will it only increase it size being a rarely using functionality?

[ricmoo]

You aren’t changing the N; look more closely at the example, { scrypt: { N: 64 } }. You are using { N: 64 }. :)

[zemse]

Opps! my bad..

> await checkTime(64);
Object { encrypting: 0.072, decrypting: 0.599 }

It's a quick keystore. I'll make sure that it has a very difficult password when using this, since in my use case password won't be entered again and again.