Re: [Bitcoin-development] Proposal to replace BIP0039
Indeed, I want to include a version number in the seed phrase because there are multiple ways to define the tree structure used with BIP32. It is certainly too early to make final decisions on that, or to achieve a common standard. Also, I can imagine that bip32 itself might be superseeded in the future. I understand that encapsulating a version number in the seed phrase might not be as important for other wallets as it is for Electrum. So it is probably not necessary to propose another BIP for that. I will simply implement it for Electrum, and I will try to do it in such a way that other wallets can use the same format. The other question we might be solving is strenghtening (your proposal). I consider that this is not a strong requirement for Electrum, because it does not let the user choose their seed phrase. However, if a few bits of the seed phrase are allocated for metadata, then I guess strenghtening can be part of it. That's another good reason to have a version number encapsulated in the seed. I too wonder why the transformation needs to be bidirectional in bip39. Le 26/10/2013 23:30, Pieter Wuille a écrit : Let's first try to agree on what we are solving. It seems that Thomas wants - in addition to the cryptographic data - to encode the tree structure, or at least version information about what features are used in it, inside the seed. I'm not sure whether we're ready to standardize on something like that yet, not having established best practices regarding different wallet structures. I do think we first need to see what possibilities and developments are possible related to it. In addition, information about the wallet structure is strictly less secret than the key data - it is even less confidential than address book data, transaction annotations, labels and comments and bookkeeping information. It could be backed up anywhere and everywhere without any repercussions, as far as I can see. I understand that in the case of Electrum, there is a strong reason to want this encapsulated together with the seed, but it's not really a requirement for most wallets. (if really needed, any key derivation scheme that starts from random strings can be augmented with metadata by enforcing property-bits on a hash of the string (so not of the output), as this data doesn't need protection from brute-forcing). Regarding other requirements, I wonder why we want the transformation to be bidirectional? If it is just about generating master seeds, one direction should be enough, and allows far nicer properties w.r.t. security. If we do settle on a standard for 'brainwallets', I would strongly prefer if it had at least some strengthening built-in, to decrease the impact of worst-case situations. If the reason is backward-compatibility, I think that any client that supports seeds already can just keep supporting whatever they supported before. Only if it matches both encoding schemes (as mentioned before) there is a potential collision (and in that case, the user could just be asked). -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to replace BIP0039
On Thu, Oct 31, 2013 at 11:41:27AM +0100, slush wrote: To be specific, we (in cooperation with / inspired by Timo Hanke) developed method how to prove that the seed generated by Trezor has been created using combination of computer-provided entropy and device-provided entropy, without leaking full private information to other computer, just because we want Trezor to be blackbox-testable and fully deterministic (seed generation is currently the only operation which uses any source of RNG). I just wanted to say the fact that you're making key generation auditable, and using deterministic signatures, is a clear sign that you guys know what you're doing. Hearing this makes me a lot more confident that the Trezor will prove to be a secure way to store my Bitcoins and my pre-order will prove to be money well spent. Kudos! -- 'peter'[:-1]@petertodd.org 000784d399e7c1d1e8f2fc953c6939b115699a1ee05029a59bc9 signature.asc Description: Digital signature -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to replace BIP0039
On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin thoma...@gmx.de wrote: Indeed, I want to include a version number in the seed phrase because there are multiple ways to define the tree structure used with BIP32. It is certainly too early to make final decisions on that, or to achieve a common standard. Well, as we're the first pioneers of bip32, let's start using it in some sane way and I'm sure the others will join. Just because they don't want to incompatible software. Actually I quite like that you're not wasting bip32 space by using some dynamic allocatons in higher address space, so I'm happy to follow your rules and I think we can agree on generic discover algorithm which maybe won't be optimal, but will find all used addresses and won't need any additional information directly in mnemonic. As I wrote in previous post, in worst case I can imagine dropdown list on import dialog, which will ask user which software has been handling the seed before, to speedup the scan. But for now I don't see this necessary at all. Also, I can imagine that bip32 itself might be superseeded in the future. Although I can imagine that as well, I hope that it won't be the case. We need to unite and integrate instead of making incompatible applications. One disadvantage of bip32 is that in fact it is too much flexible, so we even falled into the necessity of defining version of discovery algorithm. Lets set up best practices how to use it and other will follow instead of creating zillion cross-incompatible algorithms which won't understand each to other. The other question we might be solving is strenghtening (your proposal). I consider that this is not a strong requirement for Electrum, because it does not let the user choose their seed phrase. However, if a few bits of the seed phrase are Hardening and password protection are two unrelated requirements. Again, there are some scenarios in which use can leak part of the mnemonic to attacker, so hardening prevent to bruteforce the rest information by attacker, even if the mnemonic isn't passphrase protected. I'm especially refering to our algorithm of mnemonic import to Trezor during disaster recovery (when Trezor is destroyed and user wants to import the seed to another one), so that leak isn't just a theoretical concept, but real-word scenario. allocated for metadata, then I guess strenghtening can be part of it. That's another good reason to have a version number encapsulated in the seed. Actually creating optional features of such algorithm only make things complicated (and less cross-compatible). Every software still needs to implement such hardening even if it is optional feature, to be compatible with other clients. Then I don't see any reason why to have it optional. Don't forget that the proposal uses only 4 bits of version, which isn't too much combination for all these optional features ;-). I too wonder why the transformation needs to be bidirectional in bip39. Well, I wrote longer answer in previous email. tl;dr; there's quite easy way how to make the algorithm bi-directional, so I don't see a necessity to drop potentially useful feature for no good reason. I was thinking about your proposal and I realized that both our solutions solves a bit different problem. Lets summarize features (and forget to wordlist fights for moment): bip39: + bi-directional + passphrase protected + shorter mnemonic or shorter wordlist - predefined wordlist ThomasV proposal: + any software can has its own preferred worlist ? passphrase protected - one-direction only - longer mnemonic or longer wordlist Back to wordlist fights a) actually I think that the wordlist choice is far less important than it may look at first glance. Thomas thinks that bip39 wordlist is disaster, me and many other thinks it is ok, but mainly that it is very subjective. b) I see the beauty of custom wordlists in Thomas proposal, still if it means the algorithm is uni-direction only, it is very strong disadvantage to our usecase. c) I advocated our wordlist mainly because we put a lot of effort into it and after many weeks of tuning it is already done; not because I think that one method of picking the words is superior to other. I mean - if Thomas can offer any other plain-english wordlist which he'll be happy with, I'll vote for dropping our own wordlist and to use Thomas's version for the deal that he'll accept our need for bi-directionality and he agrees on the rest of bip39 ;-). Marek -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list
Re: [Bitcoin-development] Proposal to replace BIP0039
Oh, I forgot to one practical aspect; the way how the mnemonic is mined in Thomas proposal prevents usage in embedded devices, because difficulty of generating proper mnemonic is simply too high for embedded microcontrollers. Maybe this can be solved somehow by modifying the proposal, but right now it is a showstopper for us. Marek On Thu, Oct 31, 2013 at 12:11 PM, slush sl...@centrum.cz wrote: bip39: + bi-directional + passphrase protected + shorter mnemonic or shorter wordlist - predefined wordlist ThomasV proposal: + any software can has its own preferred worlist ? passphrase protected - one-direction only - longer mnemonic or longer wordlist -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
