Author: Jean-Paul Kogelman 2014-03-12 03:17:50
Published on: 2014-03-12T03:17:50+00:00
Jean-Paul Kogelman has proposed a method for encoding and encrypting Bitcoin Hierarchical Deterministic (HD) Wallet root keys. The proposal includes two encoding methodologies in three lengths each, along with unencrypted and encrypted wallet prefixes. The clear version of the root key contains verification information for integrity checking, while the encrypted version uses salting and a user-selectable Key Derivation Function (KDF) + parameters to resist brute-force attacks at varying degrees and optionally a second password for plausible deniability. The Base58Check representation of the wallet will start with "RK" (Root Key) if the wallet is unencrypted and will start with "rk" if the wallet is encrypted.The proposal provides KDF functions that can be adapted according to the user's requirements, along with a date field to search blockchain transactions faster. A derivation of the master key from the root key is explained using SHA512. Password encryption steps are clearly defined in this proposal, and bloom filter creation and verification methods are also provided. It is suggested that implementers of the proposal with alt-chains should change the prefixes so that encoded root keys do not start with “RK" or “rk”. Python reference implementation is also provided along with test vectors.The given context contains a list of public addresses, private extended keys, public extended keys, encrypted values, and creation dates for various test scenarios. Each test scenario includes different information such as root key, clear key, password, second password, and their associated public addresses, private extended keys, and public extended keys. The encrypted values are derived from different Key Derivation Functions (KDF) such as KDF0, KDF1, KDF8, and KDF9. The creation dates for each test scenario range from February 2014 to an unspecified date.Three tests have been conducted to generate multiple keys and public addresses from given root keys using different KDFs. Additionally, some tests included setting passwords that may have been used for encrypting the keys. The first test had multiple encrypted and public extended keys generated from the root key using different KDFs, along with public addresses generated for each key. The second and third tests were similar to the first, but they also had multiple passwords set for additional encryption.The proposal includes updated wording of various parts, changed computation of H to use PBKDF2-HMAC-SHA512 instead of Scrypt, moved KDF field from prefix into entropy field and added plausible deniability. It also added new KDFs, added entropy field to encrypted version, changed checksum field to bloom field in encrypted version, supports 2 passwords, added clarifications such as password character set (UTF-8) and endianness of fields, expanded the salt to be prefix + date + checksum and renamed 'master seed' to 'root key'. Implementors are advised to contact the author with new KDF proposals.
Updated on: 2023-06-08T14:50:27.182288+00:00