Quote from: jspilman on July 23, 2013, 04:56:08 AM

Interesting idea, but I'm not sure why KDF strength should be linked to seed length?

The idea was, if you choose a low entropy seed, then you're not too worried about security. Sure, you don't want your wallet hacked, but there's value in a small seed and lighter scrypt parameters. If you're going for a 512 bit seed, then you're probably not too concerned about it taking a bit when you're importing the seed. So basically a 1:1 relationship between seed length and scrypt difficulty. It also saves me from having to add another field to store encryption settings. Just to be clear, I'm not ruling out adding an extra byte, it's just that I need a little bit more convincing.

Quote from: jspilman on July 23, 2013, 04:56:08 AM

A 128-bit seed is suitable given the overall BIP32 design; you can make it bigger but it doesn't really buy you anything. If 128-bits isn't enough, much bigger things are probably broken.

As mentioned in BIP32, increasing entropy does have an effect on it:

Quote

Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.

Quote from: jspilman on July 23, 2013, 04:56:08 AM

A stronger KDF, on the other hand, is all about deterring brute-force attacks. It might be perfectly reasonable for it to take 60 seconds or longer to run the KDF when I'm restoring my HD wallet from cold storage.

The settings currently in the proposal come from BIP38. Here's the discussion thread. I recommend reading it since the same questions came up there: https://bitcointalk.org/index.php?topic=129317.0

The thing to take away from it is:

Quote

As he has it right now, it takes about a second to decode on my machine if you know the password. This would make it so that this could run on a phone in javascript at this difficulty when the password is known. Same machine would take half a year to crack 5 character single case. Make that upper lower and you're 12 years. Obviously, he had twenty machines and was not using the un-compiled code. For waht he is proposing the current hashing length is sufficient. If I'm calculating all of this right make it alpha numeric upper lower and that same thing takes 29 years on my single computer.

So that's assuming upper, lower, alpha numeric, 5 characters. Remember, you don't necessarily have to increase the scrypt parameters to get better security. The length of your passphrase has the same effect.

Quote from: jspilman on July 23, 2013, 04:56:08 AM

Ultimately the difficulty factor for the KDF will have to change over time to respond to advances in hardware and software, so it's definitely "planned obsolescence" to pick a fixed difficulty. In other words, the entire proposal becomes less and less secure over time (easier to brute-force) if users or implementers can't scale up the difficulty.

It's less clear how well 'scrypt' itself will scale over time, but at least it "should" be able to scale up, barring any fundamental weakness being discovered in its design. So exposing some degree of control of the scrypt parameters should mean the proposal can still protect against brute-force attacks as well 5 years from now as it does today.

Sure, it becomes easier to brute force, but from the numbers given above, you still need a significant amount of time to brute force a 5 character passphrase. Eventually, it all comes down to two things. 1: When is it secure enough for you? 2: How does it affect the default use case (user imports key, enters password, has to wait). Right now that's about 1 second, maybe less on your machine, but for me it's 1 sec.

Quote from: jspilman on July 23, 2013, 04:56:08 AM

My last thought is KDF speed also varies with the use case. If I'm encrypting/decrypting the seed every time I unlock my smartphone and open up my wallet app, obviously that's going to need to run a lot faster than if I'm backing up my "life savings cold wallet" from a desktop app which I only plan to make deposits to over the next 10 years. So different apps could expose radically different timings to the end user (I'm not saying the end-user would/should know enough to pick the timings themselves).

The wallet on your phone doesn't have to store the seed in the same format as proposed here. It could use a completely different encryption scheme for internal storage.

Anyway, it's an interesting argument and I'll have a look at it tomorrow to see what adding an extra settings byte would do, but I'd love to hear some other people weigh in on this matter.