Published on: 2014-04-24T19:39:52+00:00
The Bitcoin community has updated its specification to include front-loading all the key pre-stretching, as suggested by Gmaxwell. This update is designed to allow more powerful devices like laptops and mobile phones to handle the key-stretching process on their own, while weaker devices can outsource it to more capable devices. The updated spec includes a minimum of 8192 rounds of salted PBKDF2-HMAC-SHA512 for password protection, even when key-stretching is outsourced. The spec has been updated to remove the Scrypt dependency and add new key derivation functions and plausible deniability.There are concerns about potential password cracking if StrongH calculation is outsourced, but it is emphasized that the key material would still remain safe even if the password is exposed. Adjustments can be made to make password recovery more expensive if users are concerned about this vulnerability.The feasibility of using PBKDF2-HMAC-SHA512 for encryption in storage wallets is discussed. It is noted that this method is easy to implement on devices with limited RAM and can run at reasonable speeds on slow processors. Even if it takes several minutes to encrypt/decrypt, it is considered acceptable for one-time activities such as printing a cold wallet or importing an encrypted wallet into a phone. The deterministic time it takes allows for the addition of a progress bar to the user interface.The idea of using semi-trusted devices, like desktop PCs, for key stretching work in wallets is proposed. Concerns are raised about the security implications if a compromised computer is involved in the process. However, a compromise is reached with the inclusion of PBKDF2-HMAC-SHA512 based KDFs, which can run on memory-constrained devices and slow processors while still providing sufficient security.A bloom filter is proposed for typo checking and plausible deniability in a BIP. It is optimized for two elements and catches 99.9975% of typos while allowing for two different passwords. However, it is noted that this doesn't qualify as true plausible deniability as there are always at least two passwords. The conversation also covers the outsourcing of the KDF and the importance of using the specified algorithms to maintain compatibility.Discussions also touch on the integration of the BIP39 word list into Bitcoinj, timestamping and checksums, entropy length options, cross-wallet compatibility, and the benefits of a new specification over BIP 0038 and BIP 0039. It is suggested that BIP 0039 should not limit improvements on BIP 0038. The email thread concludes with links to a book on graph databases and the Bitcoin-development mailing list.In an email exchange, Jean-Paul Kogelman compared his proposal to BIP 39, highlighting the differences between the two. BIP 39 offers a list of words instead of using case-sensitive letters and numbers. It also supports different lengths of entropy, contrary to the belief that it only supports 12 words. Additionally, BIP 39 lacks a genesis date field, password typo detection, user-selectable KDF, and encourages the use of custom word lists.Kogelman announced updates to his spec, including removing Scrypt dependency, adding new KDFs, and plausible deniability. Pavol Rusnak mentioned BIP-0039, which offers an easy list of words, fixed length of entropy, no genesis date field, lack of password typo detection, no user-selectable KDF, inability to outsource KDF computation, and allows implementers to use their own word lists.On December 3rd, 2014, Kogelman shared the updates made in the spec, incorporating the requested features and removing Scrypt dependency. He also mentioned BIP-0039 as a related Bitcoin Improvement Proposal and provided a link to it.Kogelman proposed a method for encoding and encrypting Bitcoin HD Wallet root keys. The proposal includes encoding methodologies, encrypted and unencrypted wallet prefixes, verification information, salting, user-selectable KDF, second password option for plausible deniability, and prefix changes for alt-chains. The proposal provides KDF functions, date field for faster blockchain transaction search, derivation of master key from root key using SHA512, password encryption steps, bloom filter creation and verification methods, Python reference implementation, and test vectors.The context includes a list of public addresses, private extended keys, public extended keys, encrypted values, and creation dates for various test scenarios. Each scenario has different information such as root key, clear key, password, second password, associated public addresses, private extended keys, and public extended keys.
Updated on: 2023-08-01T07:55:43.899157+00:00