-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Argon2, etc. #16
Comments
I don't have any issues with adding non-standard stuff, as long as it's behind a feature flag. I've always intended for this crate to be useful for other things as well, even unrelated to Bitcoin wallets. That's what it was originally written for after all, generic 128-256-bit crypto keys that also happen to be human readable phrases :)
That I don't know. |
At least the wordlist question boils down to the words being determined by their first four letter. |
Something I wanted to add but didn't get around to yet was an additional feature flag in the style of the language feature flags I added that would allow custom word lists. |
I wrote a short posted about some plausible improvements at https://forum.web3.foundation/t/account-key-creation-ideas-for-polkadot/68 several of which dramatically improve custom word list handling, like rejection sampling. I doubt all those ideas work with each other, or with BIP39's word abbreviation requirement. If I were going to do this seriously, then I'd implement those ideas plus the BIP39's abbreviation, while attempting to maximize their inter-compatibility and shared code. Interesting problem! Also, I've doubts about many users being able to exploit BIP39's distinctness requirement for the first four letters, maybe if taught, but maybe not even then. |
Any opinion on whether this crate would be a good home for incompatible improvements to BIP32, provided the improvements are dramatic enough?
Argon2 would be an obvious improvement over PBKDF2.
If I understand, BIP32 already requires the same wordlist for checksums, yes? I could imagine either (a) improving that to actual error correction, which sounds very user friendly but requires the same wordlist, or (b) making the checksum work without the original wordlist, but doing both (a) and (b) together sounds hard.
Any idea if anyone ever considered the wordlist size question? I know diceware recommends a larger wordlist with like 12.9 bits per word, but not sure if such a wordlist can easily avoid confusables in all desired languages.
The text was updated successfully, but these errors were encountered: