Well you own data shows it is pretty much randomly distributed. If birth dates were assigned by a psuedo-random number generator then it would have 8.515 bits of entropy and the FCC files show 8.513. Pretty much random.
Yes, thats why I posted it. I was more entropy than I thought.
How? Unless you contend that all those users also are born in the same city, have same father's last name, have same email address, and went to the same highschool, etc.
You keep adding things. In your first suggestion you said DOB plus email but maybe not email. Fine, if you add enough stuff there you'll make the multiparty speedup ineffective. This still does nothing against attacking individual users where all that data is completely known.
(Add too much and you also create vulnerabilities that they'll get the data wrong later. E.g. If you ask for name I might give you 'greg maxwell' 'gmaxwell 'gregory maxwell' 'Gregory Maxwell' etc. I recently had to go through some pain to get my access to a banking site fixed because I was unable to reproduce the answers they required for the special trapdoor questions— because all the options they had were inapplicable to me, I don't have a favorite sports team, or own a pet, etc.)
email address (
how the fuck does that happen)
Because a lot of users will get tired of the bullshit questions, or mistake them for personal-data-collection that might identify them to other people, and leave them blank or put a dot in them.
Even with a billion users you would be lucky to get more than a handful of matches. The point of salt isn't to be a secret it is to prevent pre-computational attacks, prevent collisions, and to prevent multiplier on work.
Right, so you're spending a lot of effort there on something which does nothing against a targeted attack.
Now drumroll... if you think the entropy of the salt is still too low you can supplement it by a wallet generated small random number with their dictionary words. A 4 digit "pin" would provide another 13 bits and isn't difficult to remember.
So please don't tell me it IMPOSSIBLE.
You have me there: Nothing is IMPOSSIBLE so long as you keep moving the target. But if you're willing to go that far, why not go the whole way and take 128 bits of honest-to-god non-user-generated entropy and not need to have a silly argument of ever escalating measures and arm waving about my-strengthening-is-really-good-I-promise in order to convince people that it's secure, while simultaneously armoring the system against the random idiots who is going to make their key "bitcoin bitcoin bitcoin bitcoin bitcoin 1234" and then make headlines when they get robbed.
memorization although it would require some research.
I have three different genuinely random 128 bit keys memorized with electrum style conversion to words. I'm not especially good at memorizing. ::shrugs:: "So please don't tell me it IMPOSSIBLE"
Human factors can be minimized by using a system which doesn't rely on user making good judgements:
* Wallet provided high entropy passphrase via dictionary
You can stop at that one, it's what I suggested in my original message. If the basis of the wallet is known high entropy stuff with enough entropy to meet regular cryptographic standards (e.g. ~>=128 bits) then there is no need for further discussion.
Your contention initially was that a high security deterministic wallet w/o backups was impossible, flawed, and naively weak.
Not exactly, my contention was the you kept describing 'deterministic' wallets as being based exclusively on a user provided pass-phrase. This kind of scheme is flawed and naively weak,— and moreover that it would be recognized as much by almost anyone who has spent much time thinking about or researching the subject— and I haven't moved an inch from that position. Rather: You've moved from your position of pure user provided data to adding actual randomness, though not quite enough for me to actually declare your proposals secure, so sadly I can't join you in declaring victory.
If I created dispute simply by being unclear about my position, then I apologize. I really wasn't trying to argue that there had to be a backup (though I think there should be)— and my original post explicitly mentioned the possibility of the user memorizing a decently sized machine generated random number after converting it to a friendly form. My position was only that there needs to be enough actual entropy to get near 128 bits of security and that users will not provide even enough security to get by with strengthening (a fact you implicitly admit by suggesting the need of demographic "salt" to prevent collisions
, but fail to acknowledge that the same weak passwords that lead to collisions are also a problem in targeted attacks where the salt doesn't help!).