I noticed in the last release that the ability to select the number of PBKDF2 iterations had been added. My initial reaction was that #510 was a really bad idea and should be reverted.
I considered that this web tool could be used in a number of different ways, including as:
A reference implementation for developers to test against
A sandbox to allow for experimentation
A tool for end users to create keying material for wallets, including entropy collection
...you have the unlucky position of having created a reference implementation.
My biggest concern is the developers might get the wrong idea that this is a good thing. It is not.
BIP39 does not specify an optional number of iterations. It is fixed at 2048.
Perhaps BIP39's greatest achievement is interoperability and this option defeats that.
I know of no wallets which support a non-standard number of iterations, guaranteeing full incompatibility.
There are many stories of people attempting something "clever" like this and losing access to their funds.
However, as a sandbox, sure. As a tool for end users, I think it is quite dangerous, but I'm not all that concerned because of how difficult it would be for users to actually use it to send and receive funds.
When generating cryptographic keys, the most important ingredient is sufficient entropy. During the initial design of BIP39 there was much concern about BIP39 becoming a "brainwallet" and people using human generated phrases for input (instead of the mnemonic). As far as I can tell, that has not happened. All wallets and devices that I know of try very hard to generate sufficient quality entropy for the generation of the mnemonic.
The documentation on the web tool is misleading at best and plain incorrect otherwise.
The web tool states:
Using less than 2048 PBKDF2 iterations is insecure without strong optional BIP39 Passphrase.
This is not true.
The web tool also states:
Increasing this parameter will increase security against brute force attack, ...
While technically true, this is not practically true. If you are already using commonly recommended amounts of entropy, brute force attacks already consume more energy than available in our universe. Multiplying that by some number of iterations is silly.
The largest listed suggested option for number of iterations in this tool is 32768, which is a meager 16 times the standard 2048. This enhances security equivalently to adding a single lower case hex digit.
As an education sandbox tool, the data on the page generally flows from the top of the page to the bottom of the page. The PBDKF2 "rounds" appears before the BIP39 mnemonic on the page, in the entropy section (and only appears when "Show entropy details" is checked), leading a user to believe this parameter is used during entropy generation which is not true.
While the web page claims that increasing this parameter will increase security against brute force attacks, changing this parameter does not in any way affect the the web page's display of "Time to Crack".
In summary, modifying the number of iterations is of extremely limited practical value, if any. I believe the way this feature was implemented and documented gives developers the wrong impression that it might be useful to them.
I noticed in the last release that the ability to select the number of PBKDF2 iterations had been added. My initial reaction was that #510 was a really bad idea and should be reverted.
I considered that this web tool could be used in a number of different ways, including as:
As @kristovatlas said about this site
My biggest concern is the developers might get the wrong idea that this is a good thing. It is not.
However, as a sandbox, sure. As a tool for end users, I think it is quite dangerous, but I'm not all that concerned because of how difficult it would be for users to actually use it to send and receive funds.
When generating cryptographic keys, the most important ingredient is sufficient entropy. During the initial design of BIP39 there was much concern about BIP39 becoming a "brainwallet" and people using human generated phrases for input (instead of the mnemonic). As far as I can tell, that has not happened. All wallets and devices that I know of try very hard to generate sufficient quality entropy for the generation of the mnemonic.
The documentation on the web tool is misleading at best and plain incorrect otherwise.
This is not true.
While technically true, this is not practically true. If you are already using commonly recommended amounts of entropy, brute force attacks already consume more energy than available in our universe. Multiplying that by some number of iterations is silly.
In summary, modifying the number of iterations is of extremely limited practical value, if any. I believe the way this feature was implemented and documented gives developers the wrong impression that it might be useful to them.