Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
Gmaxwell pointed out that we could safely front-load all the key pre-stretching. The spec has been updated to take advantage of this. The user's password is now protected by 10,000 rounds of salted PBKDF2-HMAC-SHA512, as well as the main KDF (which ranges from scrypt 2^14/8/8 to scrypt 2^18/16/16 and PBKDF2-HMAC-SHA512 2^16 to 2^21). Will On Mon, Apr 21, 2014 at 7:05 PM, William Yager will.ya...@gmail.com wrote: The idea is that more powerful devices (mobile phones, laptops, etc.) can do all the key-stretching on their own, whereas weaker devices with access to another device with more computing power (like Trezors) do a fair amount of key-stretching on their own, but can safely export the rest of the key-stretching to the other device. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
Jean-Paul, it may be worth noting that the BIP39 word list is integrated into Bitcoinj so will likely become the de facto standard for Android, Trezor web and several desktop wallets. Anyone deviating from that word list would likely find themselves in an isolated pocket. Regarding the timestamp, MultiBit HD uses a simple timestamp of number of days since midnight of Bitcoin genesis block in UTC with modulo 97 checksum appended. Thus a new seed generated on 27 January 2014 would have 1850/01 as its checksum. When creating a new wallet the users are tested that they have written the timestamp down along with the associated 12/18/24 words. Modulo 97 was chosen since it catches about 99% of errors. On 12 March 2014 15:55, Pavol Rusnak st...@gk2.sk wrote: On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote: Yes I am. There are some differences between BIP 39 and my proposal though. - BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers. Which is better IMO. I can't imagine anyone writing down a long Base58 encoded string. - BIP 39 only offers one fixed length of entropy, always 12 words, no option to increase or decrease the length. Not true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy). - BIP 39 doesn't have a genesis date field, so no optimization during blockchain rescan. This is nice addition, indeed. But we needed to limit the data as possible in order not to increase the number of words needed to be noted down. - BIP 39 doesn't have password typo detection. No easy way to recover a password if you know most of it. It has a detection. Not correction though. - BIP 39 does not have a user selectable KDF, only 2048 round PBKDF2-HMAC-SHA512. - BIP 39 can't outsource the KDF computation to a 3rd party. True, but having one or two solid options are better than having gazillions of possible options. - BIP 39 wallet implementors can use their own word lists, breaking cross wallet compatibility. True, but they are encouraged to use the list provided. Possibility to outsource KDF outside of your standard breaks much more compatibility than this. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
This spec offers a lot of benefits over BIP 0038: * Multiple KDFs (I think the chosen list is reasonable and fits all required use cases) * Multiple seed lengths * Explicit BIP 0032 support * Creation date field * Plausible deniability (via the multiple-password mechanism) I don't think it makes any sense to compare this to BIP 0039. BIP 0039 is for key import/export, but it doesn't deal with anything like encryption, wallet creation date, etc. The use cases are completely different. I don't think we should let BIP 0039 (which is perfectly good for its intended use case) hold us back from improving on BIP 0038 (which is also good, but could use some changes). Will On Wed, Mar 12, 2014 at 11:49 AM, Gary Rowe g.r...@froot.co.uk wrote: Jean-Paul, it may be worth noting that the BIP39 word list is integrated into Bitcoinj so will likely become the de facto standard for Android, Trezor web and several desktop wallets. Anyone deviating from that word list would likely find themselves in an isolated pocket. Regarding the timestamp, MultiBit HD uses a simple timestamp of number of days since midnight of Bitcoin genesis block in UTC with modulo 97 checksum appended. Thus a new seed generated on 27 January 2014 would have 1850/01 as its checksum. When creating a new wallet the users are tested that they have written the timestamp down along with the associated 12/18/24 words. Modulo 97 was chosen since it catches about 99% of errors. On 12 March 2014 15:55, Pavol Rusnak st...@gk2.sk wrote: On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote: Yes I am. There are some differences between BIP 39 and my proposal though. - BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers. Which is better IMO. I can't imagine anyone writing down a long Base58 encoded string. - BIP 39 only offers one fixed length of entropy, always 12 words, no option to increase or decrease the length. Not true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy). - BIP 39 doesn't have a genesis date field, so no optimization during blockchain rescan. This is nice addition, indeed. But we needed to limit the data as possible in order not to increase the number of words needed to be noted down. - BIP 39 doesn't have password typo detection. No easy way to recover a password if you know most of it. It has a detection. Not correction though. - BIP 39 does not have a user selectable KDF, only 2048 round PBKDF2-HMAC-SHA512. - BIP 39 can't outsource the KDF computation to a 3rd party. True, but having one or two solid options are better than having gazillions of possible options. - BIP 39 wallet implementors can use their own word lists, breaking cross wallet compatibility. True, but they are encouraged to use the list provided. Possibility to outsource KDF outside of your standard breaks much more compatibility than this. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On Mar 12, 2014, at 08:55 AM, Pavol Rusnak st...@gk2.sk wrote:On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:Yes I am. There are some differences between BIP 39 and my proposal though.- BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers. Which is better IMO. I can't imagine anyone writing down a long Base58 encoded string. That depends on your use case. A list of words is totally fine for someone to write down, a long string of case sensitive letters is easier to put into a QR code.- BIP 39 only offers one fixed length of entropy, always 12 words, no option to increase or decrease the length. Not true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy). I stand corrected.- BIP 39 doesn't have a genesis date field, so no optimization during blockchain rescan. This is nice addition, indeed. But we needed to limit the data as possible in order not to increase the number of words needed to be noted down. My proposal didn't have this either initially, but it was deemed an essential feature for SPV clients.- BIP 39 doesn't have password typo detection. No easy way to recover a password if you know most of it. It has a detection. Not correction though. If I understand the code correctly (and please correct me if I'm wrong), the validation only happens on the mnemonic list, not on the password:"Described method also provides plausible deniability, because every passphrase generates a valid seed (and thus deterministic wallet) but only the correct one will make the desired wallet available"So upon entering a password with a typo, the user will not be notified of an error, but be presented with a wallet balance of 0, after the blockchain has been scanned. I'm sorry, but that's not the kind of experience I would want to present to my users.- BIP 39 does not have a user selectable KDF, only 2048 round PBKDF2-HMAC-SHA512.- BIP 39 can't outsource the KDF computation to a 3rd party. True, but having one or two solid options are better than having gazillions of possible options. 5 defined KDFs out of a possible 32 is hardly "gazillions".- BIP 39 wallet implementors can use their own word lists, breaking cross wallet compatibility. True, but they are encouraged to use the list provided. Possibility to outsource KDF outside of your "standard" breaks much more compatibility than this. Would you care to elaborate how optional outsourcing of the KDF breaks compatibility?jp-- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On Mar 12, 2014, at 09:49 AM, Gary Rowe g.r...@froot.co.uk wrote:Jean-Paul, it may be worth noting that the BIP39 word list is integrated into Bitcoinj so will likely become the de facto standard for Android, Trezor web and several desktop wallets. Anyone deviating from that word list would likely find themselves in an isolated pocket.Regarding the timestamp, MultiBit HD uses a simple timestamp of "number of days since midnight of Bitcoin genesis block in UTC with modulo 97 checksum appended". Thus a new seed generated on 27 January 2014 would have "1850/01" as its checksum. I'm a bit confused, are you changing the way the checksum is calculated, or fudging the input seed to produce a specific checksum? Or is checksum in this case another value calculated over the mnemonic list?When creating a new wallet the users are tested that they have written the timestamp down along with the associated 12/18/24 words.So this is specific to MultiBit HD? Wouldn't it be better to include this into the BIP?-- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote: So upon entering a password with a typo, the user will not be notified of an error, but be presented with a wallet balance of 0, after the blockchain has been scanned. I'm sorry, but that's not the kind of experience I would want to present to my users. Sure, you can have either plausible deniability or typo checking, not both at the same time. Would you care to elaborate how optional outsourcing of the KDF breaks compatibility? I'm afraid one would end up with code generated in one client that is unusable in a different client, because the client's developer thought that using fancier algorithm instead of the proposed ones was a good idea. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak st...@gk2.sk wrote: On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote: So upon entering a password with a typo, the user will not be notified of an error, but be presented with a wallet balance of 0, after the blockchain has been scanned. I'm sorry, but that's not the kind of experience I would want to present to my users. Sure, you can have either plausible deniability or typo checking, not both at the same time. The proposed BIP uses a bloom filter, so it has both plausible deniability *and *typo checking. The bloom filter is optimized for two elements and will catch something like 99.9975% of typos, despite allowing two different passwords. Would you care to elaborate how optional outsourcing of the KDF breaks compatibility? I'm afraid one would end up with code generated in one client that is unusable in a different client, because the client's developer thought that using fancier algorithm instead of the proposed ones was a good idea. This is clearly in violation of the spec. You could argue this about anything in Bitcoin. What if a developer decided to replace SHA256 with SHA3 in their implementation of a Bitcoin client? Obviously this would cause issues. Will -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On 03/12/2014 08:55 PM, William Yager wrote: The proposed BIP uses a bloom filter, so it has both plausible deniability *and *typo checking. The bloom filter is optimized for two elements and will catch something like 99.9975% of typos, despite allowing two different passwords. Ok, I see. So the spec allows one real and one fake password. That is something I don't consider plausible deniability. I am not saying that this solution is wrong, I find it quite interesting, but it's not plausible deniability. ;-) I'm afraid one would end up with code generated in one client that is unusable in a different client, because the client's developer thought that using fancier algorithm instead of the proposed ones was a good idea. This is clearly in violation of the spec. Ah, I misunderstood. I thought that outsourcing the KDF means allowing the 3rd party to use any KDF instead of the specified ones. What would be the reason to outsource if this is not possible, anyway? -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On Wed, Mar 12, 2014 at 3:04 PM, Pavol Rusnak st...@gk2.sk wrote: On 03/12/2014 08:55 PM, William Yager wrote: The proposed BIP uses a bloom filter, so it has both plausible deniability *and *typo checking. The bloom filter is optimized for two elements and will catch something like 99.9975% of typos, despite allowing two different passwords. Ok, I see. So the spec allows one real and one fake password. That is something I don't consider plausible deniability. I am not saying that this solution is wrong, I find it quite interesting, but it's not plausible deniability. ;-) It's a little more nuanced than that. There are *always* at least two passwords. If the user doesn't want a second password, a random one is generated for them. A wallet with two known encryption keys and only one known encryption key are indistinguishable. If compelled to decrypt, there is no way to prove that the user actually knows a second password. I'm afraid one would end up with code generated in one client that is unusable in a different client, because the client's developer thought that using fancier algorithm instead of the proposed ones was a good idea. This is clearly in violation of the spec. Ah, I misunderstood. I thought that outsourcing the KDF means allowing the 3rd party to use any KDF instead of the specified ones. What would be the reason to outsource if this is not possible, anyway? Yes, the outsourcing terminology is a little confusing. The idea is this: You have a little device, like a Trezor. It has very little RAM and very little CPU power. However, you want to use a powerful key-stretching algorithm (like the maximum Scrypt KDF defined in the spec). One way to implement this is to allow semi-trusted devices (like desktop PCs) to do all the heavy lifting. The way the spec is defined, it is easy to have a more powerful device do all the tough key stretching work without significantly compromising the security of the wallet. Will -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On 03/12/2014 09:10 PM, William Yager wrote: implement this is to allow semi-trusted devices (like desktop PCs) to do all the heavy lifting. The way the spec is defined, it is easy to have a more powerful device do all the tough key stretching work without significantly compromising the security of the wallet. By disclosing preH to compromised computer (between steps 4 and 5) you make further steps 5-9 quite less important. Too bad you started to work on spec just recently. :-/ -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On Wed, Mar 12, 2014 at 3:24 PM, Pavol Rusnak st...@gk2.sk wrote: On 03/12/2014 09:10 PM, William Yager wrote: implement this is to allow semi-trusted devices (like desktop PCs) to do all the heavy lifting. The way the spec is defined, it is easy to have a more powerful device do all the tough key stretching work without significantly compromising the security of the wallet. By disclosing preH to compromised computer (between steps 4 and 5) you make further steps 5-9 quite less important. Yes, that was my chief complaint as well. A compromised computer removes most of the extra security offered by key stretching (should you choose to outsource the bulk of your key stretching). However, I think we have a good compromise, which is the inclusion of a number of PBKDF2-HMAC-SHA512 based KDFs. For anyone who doesn't want to trust any external device, but also wants to use memory-contrained devices (that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to implement even on devices that only have a few kB of RAM, and even though our number of rounds is very aggressive (2^16 and 2^21), it will still run in reasonable time even on very slow embedded ARM processors. Will -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On 03/12/2014 09:37 PM, William Yager wrote: (that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to implement even on devices that only have a few kB of RAM, and even though our number of rounds is very aggressive (2^16 and 2^21), it will still run in reasonable time even on very slow embedded ARM processors. To give you some numbers: TREZOR (120MHz ARM) does 1024 rounds of PBKDF2-HMAC-SHA512 in around 1 second. So 2^16 is around one minute, 2^21 is around half an hour. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On Wed, Mar 12, 2014 at 3:42 PM, Pavol Rusnak st...@gk2.sk wrote: On 03/12/2014 09:37 PM, William Yager wrote: (that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to implement even on devices that only have a few kB of RAM, and even though our number of rounds is very aggressive (2^16 and 2^21), it will still run in reasonable time even on very slow embedded ARM processors. To give you some numbers: TREZOR (120MHz ARM) does 1024 rounds of PBKDF2-HMAC-SHA512 in around 1 second. So 2^16 is around one minute, 2^21 is around half an hour. Precisely. And since the target of this BIP is generally storage wallets (just like BIP 0038), we figured these were reasonable time scales for encryption/decryption on slow devices. Let's say you're implementing a Raspberry Pi based cold wallet printer. Having the user wait 10 seconds to several minutes is not unreasonable for a one-time activity, especially when at least this much time is used to generate entropy, print the wallet, etc. The same goes for phones. If you're importing a heavily encrypted wallet into your device, the user won't mind waiting a few seconds or even a few minutes. Plus, as an added bonus, the amount of time it will take to encrypt/decrypt is highly deterministic, so it's easy to add a nice progress bar to a UI. Will -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On Mar 12, 2014, at 01:24 PM, Pavol Rusnak st...@gk2.sk wrote:On 03/12/2014 09:10 PM, William Yager wrote:implement this is to allow semi-trusted devices (like desktop PCs) to doall the "heavy lifting". The way the spec is defined, it is easy to have amore powerful device do all the tough key stretching work withoutsignificantly compromising the security of the wallet. By disclosing "preH" to compromised computer (between steps 4 and 5) you make further steps 5-9 quite less important.Agreed, this is a valid concern. This could possibly allow a 3rd party to crack the password, but then again, they would not gain access to any key material. So yes, you could expose your password, but your key would still be safe.If people feel strongly about this vulnerability, we can revisit step 4 and adjust it to make password recovery more expensive.jp-- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On Wed, Mar 12, 2014 at 4:08 PM, Jean-Paul Kogelman jeanpaulkogel...@me.com wrote: Agreed, this is a valid concern. This could possibly allow a 3rd party to crack the password, but then again, they would not gain access to any key material. So yes, you could expose your password, but your key would still be safe. If people feel strongly about this vulnerability, we can revisit step 4 and adjust it to make password recovery more expensive. Just to clarify on J.P.'s comments: *If* you choose to outsource StrongH calculation, and *If* that machine is compromised, then the security of your password is reduced to a single round of salted PBKDF2-HMAC-SHA512. Your private key remains on the trusted device, no matter what. Regrettable, but not catastrophic. Will -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
