From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V0FDS-0000Pb-Ac for bitcoin-development@lists.sourceforge.net; Fri, 19 Jul 2013 18:15:42 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of me.com designates 17.172.220.236 as permitted sender) client-ip=17.172.220.236; envelope-from=jeanpaulkogelman@me.com; helo=st11p02mm-asmtp001.mac.com; Received: from st11p02mm-asmtp001.mac.com ([17.172.220.236]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V0FDQ-0000my-7K for bitcoin-development@lists.sourceforge.net; Fri, 19 Jul 2013 18:15:42 +0000 Received: from st11p02mm-spool002.mac.com ([17.172.220.247]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.05(7.0.4.27.4) 64bit (built Apr 23 2013)) with ESMTP id <0MQ7007EA41WLI70@st11p02mm-asmtp001.mac.com> for bitcoin-development@lists.sourceforge.net; Fri, 19 Jul 2013 18:15:35 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-07-19_07:2013-07-19, 2013-07-19, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000 definitions=main-1307190141 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yJUaRPUvPvzdeOgLJTpPqQ)" Received: from localhost ([17.172.220.223]) by st11p02mm-spool002.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQ7006C641WOJ80@st11p02mm-spool002.mac.com>; Fri, 19 Jul 2013 18:15:32 +0000 (GMT) To: Jeremy Spilman , bitcoin-development@lists.sourceforge.net From: Jean-Paul Kogelman Date: Fri, 19 Jul 2013 18:15:32 +0000 (GMT) X-Mailer: iCloud Mail (1R) X-Originating-IP: [159.153.138.53] Message-id: In-reply-to: X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Headers-End: 1V0FDQ-0000my-7K Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:15:42 -0000 --Boundary_(ID_yJUaRPUvPvzdeOgLJTpPqQ) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Jeremy,=0A=0AThe main reason is to stick as close to BIP 0038 as possib= le, allowing implementers to reuse existing code paths. This proposal and = BIP 0032 don't really put any restrictions on content of the seed itself (= as can be seen in test vector 1).=0A=0Ajp=0A=0AOn Jul 19, 2013, at 11:09 A= M, Jeremy Spilman wrote:=0A=0AVery clear write-up Jean= !=0A=0AQuick question - what is the purpose of step 10 of the encryption p= rocess -- why XOR the master seed with some bytes of the hashed passphrase= before encrypting the XOR'd master seed with the remaining bytes of the h= ashed passphrase? Versus simply encrypting the master seed with the hashed= passphrase of equal length to the seed?=0A=0ADoes this basically serve th= e fucntion of an IV?=0A=0ADo you really need this since the master seed mu= st be high entropy random bytes in the first place?=0A=0AThanks,=0A--Jerem= y=0A=0AOn Fri, 19 Jul 2013 10:46:44 -0700, Jean-Paul Kogelman wrote:=0A=0A=0AHi everyone,=0A=0AI'm looking for feedback on= the proposal below.=0A=0AKind regards,=0A=0AJean-Paul=0A=0A---=0ABIP:=C2=A0= =0ATitle: Base58 encoded HD Wallet master seed with optional encryption=0A= Author: Jean-Paul Kogelman=0AStatus: Draft=0AType: Informational=0ACreated= : 17-07-2013=0A=0AAbstract=0A=0AThis proposal describes a method for encod= ing and optionally encrypting a Bitcoin Hierarchical Deterministic (HD) Wa= llet master seed. Encoded master seeds are intended for use on paper walle= ts. Each string contains all the information needed to verify and reconsti= tute an HD wallet except for the optional passphrase. The encrypted versio= n uses salting and scrypt to resist brute-force attacks.=0A=0AThe method p= rovides two encoding methodologies in 3 lengths each (16, 32 and 64 byte s= eeds). One is a clear version of the master seed with verification informa= tion for integrity checking and the other is an encrypted representation.=0A= =0AA 32-bit hash of the resulting master Bitcoin public address is encoded= in plain text within each seed record, so in the case of an encrypted see= d, it can be correlated to a Bitcoin public address with reasonable probab= ility by someone not knowing the passphrase. The complete Bitcoin public a= ddress can be derived through successful decoding and optional decryption = of the master seed record.=0A=0A=0AMotivation=0A=0AThe extended private ke= ys proposed in BIP 0032 are long, fixed length records and don't offer any= form of security. The master seed used to generate the HD wallet is typic= ally shorter than the extended master private key that results from it.=C2= =A0=0A=0AA compact representation of the master seed is easier to handle a= nd a 2-factor version of the master seed record allows for safe storage an= d the creation of paper wallets by 3rd parties.=C2=A0=0A=0A=0ACopyright=0A= =0AThis proposal is hereby placed in the public domain.=0A=0A=0ARationale=0A= =0AUser story: As a Bitcoin user who uses HD wallets, I would like the abi= lity to store my wallet master seed in a compact form as a paper wallet.=0A= =0AUser story: As a Bitcoin user who uses HD wallets, I would like the abi= lity to have a 3rd party create a paper wallet with my master seed in it, = without having access to the funds stored in the wallet.=0A=0AUser story: = As a Bitcoin user who uses HD wallets, I would like the ability to choose = the strength of the master seed depending on my security requirements and = how I wish to store it.=C2=A0=0A=0A=0ASpecification=0A=0AThis proposal mak= es use of the following functions and definitions:=0A=0AAES256Encrypt, AES= 256Decrypt: the simple form of the well-known AES block cipher without con= sideration for initialization vectors or block chaining. Each of these fun= ctions takes a 256-bit key and a variable legth of input and deterministic= ally yields output data of similar length to the input.=0A=0ASHA256: a wel= l-known hashing algorithm that takes an arbitrary number of bytes as input= and deterministically yields a 32-byte hash.=0A=0ARIPEMD160: a well known= hashing algorithm that takes an arbitrary number of bytes as input and de= terministically yields a 20-byte hash.=0A=0Ascrypt: A well-known key deriv= ation algorithm. It takes the following parameters: (string) password, (st= ring) salt, (int) n, (int) r, (int) p, (int) length, and deterministically= yields an array of bytes whose length is equal to the length parameter.=0A= =0AHMAC-SHA512: Produces a 64 byte (512 bit) hash based message authentica= tion code using the SHA512 hash function using a seed (in our case we will= use a byte representation of "Bitcoin seed") and an aribtrary input messa= ge. The output will be 64 bytes.=0A=0ABase58Check: a method for encoding a= rrays of bytes using 58 alphanumeric characters commonly used in the Bitco= in ecosystem.=0A=0AG, N: Constants defined as part of the secp256k1 ellipt= ic curve. G is an elliptic curve point, and N is a large positive integer.= =0A=0APrefix=0A=0AIt is proposed that the resulting Base58Check-encoded st= ring start with either "WS" for clear master seed records or "ws" for 2-fa= ctor master seed records. The prefixes "WS" and "ws" were chosen as abrevi= ations of the term "Wallet Seed" and upper case to indicate whether it's a= clear representation and lower case when it's a 2-factor representation.=C2= =A0=0A=0ATo keep the size of the encrypted key equal to the clear version,= no initialization vectors (IVs) are used in the AES encryption. Rather, s= uitable values for IV-like use are derived using scrypt from the passphras= e and from using a 32-bit hash of the resulting Bitcoin public address as = salt.=0A=0AProposed specification=0A=0AThere are 2 seed record representat= ions with 3 lengths each, resulting in a total of 6 different object ident= ifier prefixes.=C2=A0=0A=0APrefix 0x1093: Clear 16 byte master seed, total= length: 22 bytes=0APrefix 0x1E68: Clear 32 byte master seed, total length= : 38 bytes=0APrefix 0x665A: Clear 64 byte master seed, total length: 70 by= tes=0A=0APrefix 0x1EE4: 2-factor 16 byte master seed, total length: 22 byt= es=0APrefix 0x38AE: 2-factor 32 byte master seed, total length: 38 bytes=0A= Prefix 0xBECB: 2-factor 64 byte master seed, total length: 70 bytes=0A=0AT= hese are constant bytes that appear at the beginning of the Base58Check-en= coded record, and their presence causes the resulting string to have a pre= dictable prefix.=0A=0AHow the user sees it: 35, 57 or 101 characters alway= s starting with either "WS" or "ws".=0A=0ACount of payload bytes (beyond p= refix): 20, 36 or 68=0A=0APayload format:=0A4 bytes: SHA256(SHA256(master_= bitcoin_public_address))[0...3], used both for typo checking and as salt.=0A= 16, 32 or 64 bytes: either a clear representation or an encrypted represen= tation of the master seed.=0A=0ARange in Base58Check encoding for clear 16= byte master seed (prefix WS):=0AMinimum value: WSJ5JnjiRZT8b15aZr6GGWzt2V= MBPapmhBQ (based on 0x10 0x93 plus twenty 0x00's)=0AMaximum value: WShQumr= 1iGdbTpWiesWbb189p7rSLBiq3EJ (based on 0x10 0x93 plus twenty 0xFF's)=0A=0A= Range in Base58Check encoding for clear 32 byte master seed (prefix WS):=0A= Minimum value: WS7SqjMWhDGCagcZxCk317LLWyWUny7465ENGKEKuxBf5sFvRHmRRfCgr (= based on 0x1E 0x68 plus thirty-six 0x00's)=0AMaximum value: WSLAbo8WHEQr1Z= 1cv26Z5njh5URHMo9fPiDFYE2NpCwmAoPZwDxzm3PjB (based on 0x1E 0x68 plus thirt= y-six 0xFF's)=0A=0ARange in Base58Check encoding for clear 64 byte master = seed (prefix WS):=0AMinimum value: WS2cMzM9WrogWVLKYFzTaTXZnYCryY31uptmdev= XuRFBXTWJhmt4No9Eejoj3apqyU5RkyXsGHFPbZd14oz7Fv1Mi85kadBD4TPsL (based on 0= x66 0x5A plus sixty-eight 0x00's)=0AMaximum value: WS6PXJ1HoJXn9hyLz8uXQEy= 2ZajAVaFDTViXhZDthwYbhyvfHRqjwU4FoGpepCbuuycAwMFbgoZB6E48baqD1c9PdMNUZCSSB= mfE7 (based on 0x66 0x5A plus sixty-eight 0xFF's)=0A=0ARange in Base58Chec= k encoding for 2-factor 16 byte master seed (prefix ws):=0AMinimum value: = ws1nyTi9KjdRkJda4Yh1KkXSLC8SZ6kKzEM (based on 0x1E 0xE4 plus twenty 0x00's= )=0AMaximum value: wsR8aSpScSotd84i9a7LeEei7pdhVkeciX8 (based on 0x1E 0xE4= plus twenty 0xFF's)=0A=0ARange in Base58Check encoding for 2-factor 32 by= te master seed (prefix ws):=0AMinimum value: wsC8sayZpTpeX3k6jcCMeTedDapXk= Xd7SZpRJbSjdeqKBJ2Vnrm1xyfD3 (based on 0x38 0xAE plus thirty-six 0x00's)=0A= Maximum value: wsQrdekZQUyHwv99hRYsj93yn5jLKMfikCoJaWEnXubRGEA9Jnxg5KaPW (= based on 0x38 0xAE plus thirty-six 0xFF's)=0A=0ARange in Base58Check encod= ing for 2-factor 64 byte master seed (prefix ws):=0AMinimum value: ws4XTrr= iTEyyy2TrGWv9R7o94CyBiN69S2VxiK5tVW9htEi48w54sQ43JChCmadoGtYpZSu7vqbbQTMem= CSyyToyLPPMjughcXNxE (based on 0xBE 0xCB plus sixty-eight 0x00's)=0AMaximu= m value: ws8JdAWrjgi5cF6siPqDEuEbqFVVEQJLyhKinDPFJ2T84m8Qib2kS4y4Sji8YCQsD= Q5ZjpcrMMuNu7nnHyJ5j9x1Fcg5iUwvZ7krH (based on 0xBE 0xCB plus sixty-eight = 0xFF's)=0A=0AGeneration of master seed:=0A=0A1. Take either an existing 16= , 32 or 64 byte master seed S, or generate one from a (P)RNG.=0A2. Calcula= te I =3D HMAC-SHA512(key =3D "Bitcoin seed", msg =3D S)=0A3. Split I into = two 32-byte sequences, IL and IR.=0A4. Use IL as master secret key. IR, th= e master chain code is not relevant here.=0A5. In case IL is 0 or >=3D N, = the master key is invalid. Go back to step 1 if generating, or in case of = a provided master seed, return an error.=0A6. Compute the public key K =3D= IL*G=0A7. Calculate the master Bitcoin public address A =3D Base58Check(R= IPEMD160(SHA256(K)))=0A8. Calculate the salt =3D SHA256(SHA256(A))[0...3]=0A= =0AEncryption:=0A=0A9. Derive a hash H from the passphrase using scrypt=0A= =C2=A0 =C2=A0 - Parameters: passphrase is the passphrase itself encoded in= UTF-8, salt =3D salt, n =3D 16384, r =3D 8, p =3D 8, length =3D seed leng= th + 32=0A10. The first number of bytes in H, equal to length of seed S ar= e used to xor seed S. Call the result X.=0A11. Do AES256Encrypt(message =3D= X, key =3D last 32 bytes of H), call this encrypted_seed.=0A=0A=0AThe enc= rypted_master_seed is the Base58Check-encoded concatenation of the followi= ng, which totals 2 + 4 + seed length bytes (22, 38 or 70 bytes):=0A=0Aencr= ypted_master_seed =3D prefix + salt + encrypted_seed=0A=0AThe clear versio= n is:=0A=0Amaster_seed =3D prefix + salt + seed S=0A=0A=0ADecryption:=0A=0A= 1. Collect encrypted_master_seed and passphrase from user.=0A2. Perform st= ep 9 of encryption with the passphrase and the salt from the encrypted_mas= ter_seed.=0A3. With the encrypted_seed from encrypted_master_seed do AES25= 6Decrypt(message =3D encrypted_seed, key =3D last 32 bytes of H), call thi= s decrypted_seed.=0A4. With the first number of bytes in H, equal to the l= ength of the decrypted_seed, perform the xor operation on decrypted_seed a= nd call the result S.=0A5. Perform generation steps 2 until 8 and verify t= hat the generated salt is equal to the salt from encrypted_master_seed.=0A= =0A=0ASuggestions for implementers of proposal with alt-chains=0A=0AThis p= roposal involves hashing of a text representation of a public address whic= h for Bitcoin includes the leading '1'. Alt-chains can easily be denoted s= imply by using the alt-chain's preferred format for representing an addres= s. Alt-chain implementers may also change the prefix such that encoded mas= ter seeds do not start with "WS" or "ws".=0A=0A=0ABitcoin testnet represen= tation=0A=0AThis proposal does not cover separate Bitcoin testnet represen= tations of encoded master seeds, although since the 4 salt bytes are based= on a double SHA256 of the Bitcoin public address, they will be different = for Bitcoin testnet public addresses and validation will fail.=C2=A0=0A=0A= =0AReference implementation=0A=0ATODO=0A=0A=0ATest vectors=0A=0ATest 1:=0A= =0ASeed =C2=A0 =C2=A0 =C2=A0: 000102030405060708090a0b0c0d0e0f=0AClear =C2= =A0 =C2=A0 : WSZsLQ5c1uKrRQugbrZNYsvMhRixiaWaVmJ=0APassword =C2=A0: Satosh= i=0AEncrypted : wsHb15443fYPmneEXskd6wUZeP15fCiA69n=0AAddress =C2=A0 : 15m= KKb2eos1hWa6tisdPwwDC1a5J1y9nma=0Axprv =C2=A0 =C2=A0 =C2=A0: xprv9s21ZrQH1= 43K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRN= NU3TGtRBeJgk33yuGBxrMPHi=0Axpub =C2=A0 =C2=A0 =C2=A0: xpub661MyMwAqRbcFtXg= S5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7= usUDFdp6W1EGMcet8=0A=0ATest 2:=0A=0ASeed =C2=A0 =C2=A0 =C2=A0: 7f0ad7d595b= e13e6fe4cf1fa0fbb6ae9c26c5d9b09920709414982b6363d5844=0AClear =C2=A0 =C2=A0= : WSB7z3izBZwDoaAUA4mDpEHzAZsA5zfTWu3cCxhkaLtZ4Ur6n6mXsgpMK=0APassword =C2= =A0: Nakamoto=0AEncrypted : wsFp1uM2gFhd2PuRzmNFReRud71hgmVwPoc7cGpxuvgETR= sv8J1wHNANJ=0AAddress =C2=A0 : 1A54ECavJaJAoLGqqNrPd9Y3cvSvkL2Roz=0Axprv =C2= =A0 =C2=A0 =C2=A0: xprv9s21ZrQH143K3f9hMVvcbY4EX4CfxsEtc6C5BMkZtgGpTGpxAsc= oq7SLSAcL6k5dxaZ9s4SChrtfSFoKpijuwAnhuPn76eva6W8bDr118t3=0Axpub =C2=A0 =C2= =A0 =C2=A0: xpub661MyMwAqRbcG9EATXTcxfzy563ANKxjyK7fykABT1ooL5A6iQw4NukpHS= hDxYgeso4NHscFmqcVEtdUt61c8RCf7FqXK9z6sgfkQvYBQPP=0A=0ATest 3:=0A=0ASeed =C2= =A0 =C2=A0 =C2=A0: fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1a= eaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542=0A= Clear =C2=A0 =C2=A0 : WS6186bsAkSaGRjRZ1UGyCGigxsXPvnYGSqNHJYmauV9X4W8tLJk= e1DH8UP8YMsDLdsjwgodcghjjKqkWQmk3t7qDbNMJVBDKcD2s=0APassword =C2=A0: Vires= In Numeris=0AEncrypted : ws7vDy7RjqMvcPX7GeakKvdK6vDKGhRSjQtaRfKUVQrJXwwe= tLSeTdNgGzn5BKZZqz1BBdaHBFYfLvNUSxDaoP1ojJMMJD9UnQuwt=0AAddress =C2=A0 : 1= JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg=0Axprv =C2=A0 =C2=A0 =C2=A0: xprv9s21ZrQ= H143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqP= qm55Qn3LqFtT2emdEXVYsCzC2U=0Axpub =C2=A0 =C2=A0 =C2=A0: xpub661MyMwAqRbcFW= 31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJ= Y47LJhkJ8UB7WEGuduB=0A=0ATest 4:=0A=0ASeed =C2=A0 =C2=A0 =C2=A0: 6ca4a27ac= 660c683340f59353b1375a9=0AClear =C2=A0 =C2=A0 : WSXnfK5CJbDoSwcqMfz7Xqy3av= uPHSxDQQk=0APassword =C2=A0: =E8=81=A1=E4=B8=AD=E6=9C=AC=0AEncrypted : wsF= WKz3c5eeHRwtJveSdFvwUrmoNVkJ5ns2=0AAddress =C2=A0 : 1JVncPbsdB2s4zHim3VdAW= NkZ8JANBZ1U9=0Axprv =C2=A0 =C2=A0 =C2=A0: xprv9s21ZrQH143K3mJ4upPSDfXdA34y= Njem6PSsXT63vm8dq8ikUJv4iiTD3PrSKtdGZXFVD689z5T7knXo55BjcHS2WL3Syp2DbGgnbg= xw2QA=0Axpub =C2=A0 =C2=A0 =C2=A0: xpub661MyMwAqRbcGFNY1qvSaoUMi4uTnCNcTcN= UKqVfV6fchw3u1rEKGWmgtfUMRKLgUHNZ7dfsh8Ys6SLwUojZqScFBQL3dFGF3QywNLJVZ2o=0A= =0A=0AAcknowledgements=0A=0AMike Caldwell for BIP 0038, which this proposa= l borrows heavily from.=0A=0A=0ASee Also=0A=0ABIP 0032 Hierarchical Determ= inistic Wallets: https://en.bitcoin.it/wiki/BIP_0032=0ABIP 0038 Passphrase= -protected private key: https://en.bitcoin.it/wiki/BIP_0038=0A=0A=0A=0A=0A= --Boundary_(ID_yJUaRPUvPvzdeOgLJTpPqQ) Content-type: multipart/related; boundary="Boundary_(ID_vCDqojFBlF75WOGzHG7oGw)"; type="text/html" --Boundary_(ID_vCDqojFBlF75WOGzHG7oGw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi Jeremy,

The main reason is to stick as cl= ose to BIP 0038 as possible, allowing implementers to reuse existing code = paths. This proposal and BIP 0032 don't really put any restrictions on con= tent of the seed itself (as can be seen in test vector 1).

<= /div>
jp

On Jul 19, 2013, at 11:09 AM, Jeremy Spilman <jerem= y@taplink.co> wrote:

<= div class=3D"msg-quote">
Very clear write-up Jean!

Quick question - what is the purpose of step 10 of the encryption pr= ocess -- why XOR the master seed with some bytes of the hashed passphrase = before encrypting the XOR'd master seed with the remaining bytes of the ha= shed passphrase? Versus simply encrypting the master seed with the hashed = passphrase of equal length to the seed?

Does this= basically serve the fucntion of an IV?

Do you re= ally need this since the master seed must be high entropy random bytes in = the first place?

Thanks,
--Jeremy
=

On Fri, 19 Jul 2013 10:46:44 -0700, Jean-Paul Kogelman= <jeanpaulkogelman@me.com> wrote:


Hi everyone,

I'm= looking for feedback on the proposal below.

Kind= regards,

Jean-Paul

---<= /div>
BIP: 
Title: Base58 encoded HD Wallet master seed= with optional encryption
Author: Jean-Paul Kogelman
S= tatus: Draft
Type: Informational
Created: 17-07-2013

Abstract

This proposal describes a method for encoding and optionally encrypting a= Bitcoin Hierarchical Deterministic (HD) Wallet master seed. Encoded maste= r seeds are intended for use on paper wallets. Each string contains all th= e information needed to verify and reconstitute an HD wallet except for th= e optional passphrase. The encrypted version uses salting and scrypt to re= sist brute-force attacks.

The method provides two= encoding methodologies in 3 lengths each (16, 32 and 64 byte seeds). One = is a clear version of the master seed with verification information for in= tegrity checking and the other is an encrypted representation.
<= br>
A 32-bit hash of the resulting master Bitcoin public address= is encoded in plain text within each seed record, so in the case of an en= crypted seed, it can be correlated to a Bitcoin public address with reason= able probability by someone not knowing the passphrase. The complete Bitco= in public address can be derived through successful decoding and optional = decryption of the master seed record.


<= div>Motivation

The extended priv= ate keys proposed in BIP 0032 are long, fixed length records and don't off= er any form of security. The master seed used to generate the HD wallet is= typically shorter than the extended master private key that results from = it. 

A compact representation of the master = seed is easier to handle and a 2-factor version of the master seed record = allows for safe storage and the creation of paper wallets by 3rd parties.&= nbsp;


Copyright

This proposal is hereby placed in the public domai= n.


Rationale

User story: As a Bitcoin user who uses HD wallets, I = would like the ability to store my wallet master seed in a compact form as= a paper wallet.

User story: As a Bitcoin user wh= o uses HD wallets, I would like the ability to have a 3rd party create a p= aper wallet with my master seed in it, without having access to the funds = stored in the wallet.

User story: As a Bitcoin us= er who uses HD wallets, I would like the ability to choose the strength of= the master seed depending on my security requirements and how I wish to s= tore it. 


Specificati= on

This proposal makes use of the follow= ing functions and definitions:

AES256Encrypt, AES= 256Decrypt: the simple form of the well-known AES block cipher without con= sideration for initialization vectors or block chaining. Each of these fun= ctions takes a 256-bit key and a variable legth of input and deterministic= ally yields output data of similar length to the input.

SHA256: a well-known hashing algorithm that takes an arbitrary numb= er of bytes as input and deterministically yields a 32-byte hash.

RIPEMD160: a well known hashing algorithm that takes an a= rbitrary number of bytes as input and deterministically yields a 20-byte h= ash.

scrypt: A well-known key derivation algorith= m. It takes the following parameters: (string) password, (string) salt, (i= nt) n, (int) r, (int) p, (int) length, and deterministically yields an arr= ay of bytes whose length is equal to the length parameter.

<= /div>
HMAC-SHA512: Produces a 64 byte (512 bit) hash based message aut= hentication code using the SHA512 hash function using a seed (in our case = we will use a byte representation of "Bitcoin seed") and an aribtrary inpu= t message. The output will be 64 bytes.

Base58Che= ck: a method for encoding arrays of bytes using 58 alphanumeric characters= commonly used in the Bitcoin ecosystem.

G, N: Co= nstants defined as part of the secp256k1 elliptic curve. G is an elliptic = curve point, and N is a large positive integer.

<= span style=3D"text-decoration: underline;" data-mce-style=3D"text-decorati= on: underline;">Prefix

It is proposed that= the resulting Base58Check-encoded string start with either "WS" for clear= master seed records or "ws" for 2-factor master seed records. The prefixe= s "WS" and "ws" were chosen as abreviations of the term "Wallet Seed" and = upper case to indicate whether it's a clear representation and lower case = when it's a 2-factor representation. 

To kee= p the size of the encrypted key equal to the clear version, no initializat= ion vectors (IVs) are used in the AES encryption. Rather, suitable values = for IV-like use are derived using scrypt from the passphrase and from usin= g a 32-bit hash of the resulting Bitcoin public address as salt.

Proposed specification
<= br>
There are 2 seed record representations with 3 lengths each,= resulting in a total of 6 different object identifier prefixes. 

Prefix 0x1093: Clear 16 byte master seed, total leng= th: 22 bytes
Prefix 0x1E68: Clear 32 byte master seed, total len= gth: 38 bytes
Prefix 0x665A: Clear 64 byte master seed, total le= ngth: 70 bytes

Prefix 0x1EE4: 2-factor 16 byte ma= ster seed, total length: 22 bytes
Prefix 0x38AE: 2-factor 32 byt= e master seed, total length: 38 bytes
Prefix 0xBECB: 2-factor 64= byte master seed, total length: 70 bytes

These a= re constant bytes that appear at the beginning of the Base58Check-encoded = record, and their presence causes the resulting string to have a predictab= le prefix.

How the user sees it: 35, 57 or 101 ch= aracters always starting with either "WS" or "ws".

Count of payload bytes (beyond prefix): 20, 36 or 68

Payload format:
4 bytes: SHA256(SHA256(master_bitcoin_publ= ic_address))[0...3], used both for typo checking and as salt.
16= , 32 or 64 bytes: either a clear representation or an encrypted representa= tion of the master seed.

Range in Base58Check enc= oding for clear 16 byte master seed (prefix WS):
Minimum value: = WSJ5JnjiRZT8b15aZr6GGWzt2VMBPapmhBQ (based on 0x10 0x93 plus twenty 0x00's= )
Maximum value: WShQumr1iGdbTpWiesWbb189p7rSLBiq3EJ (based on 0= x10 0x93 plus twenty 0xFF's)

Range in Base58Check= encoding for clear 32 byte master seed (prefix WS):
Minimum val= ue: WS7SqjMWhDGCagcZxCk317LLWyWUny7465ENGKEKuxBf5sFvRHmRRfCgr (based on 0x= 1E 0x68 plus thirty-six 0x00's)
Maximum value: WSLAbo8WHEQr1Z1cv= 26Z5njh5URHMo9fPiDFYE2NpCwmAoPZwDxzm3PjB (based on 0x1E 0x68 plus thirty-s= ix 0xFF's)

Range in Base58Check encoding for clea= r 64 byte master seed (prefix WS):
Minimum value: WS2cMzM9WrogWV= LKYFzTaTXZnYCryY31uptmdevXuRFBXTWJhmt4No9Eejoj3apqyU5RkyXsGHFPbZd14oz7Fv1M= i85kadBD4TPsL (based on 0x66 0x5A plus sixty-eight 0x00's)
Maxim= um value: WS6PXJ1HoJXn9hyLz8uXQEy2ZajAVaFDTViXhZDthwYbhyvfHRqjwU4FoGpepCbu= uycAwMFbgoZB6E48baqD1c9PdMNUZCSSBmfE7 (based on 0x66 0x5A plus sixty-eight= 0xFF's)

Range in Base58Check encoding for 2-fact= or 16 byte master seed (prefix ws):
Minimum value: ws1nyTi9KjdRk= Jda4Yh1KkXSLC8SZ6kKzEM (based on 0x1E 0xE4 plus twenty 0x00's)
M= aximum value: wsR8aSpScSotd84i9a7LeEei7pdhVkeciX8 (based on 0x1E 0xE4 plus= twenty 0xFF's)

Range in Base58Check encoding for= 2-factor 32 byte master seed (prefix ws):
Minimum value: wsC8sa= yZpTpeX3k6jcCMeTedDapXkXd7SZpRJbSjdeqKBJ2Vnrm1xyfD3 (based on 0x38 0xAE pl= us thirty-six 0x00's)
Maximum value: wsQrdekZQUyHwv99hRYsj93yn5j= LKMfikCoJaWEnXubRGEA9Jnxg5KaPW (based on 0x38 0xAE plus thirty-six 0xFF's)=

Range in Base58Check encoding for 2-factor 64 by= te master seed (prefix ws):
Minimum value: ws4XTrriTEyyy2TrGWv9R= 7o94CyBiN69S2VxiK5tVW9htEi48w54sQ43JChCmadoGtYpZSu7vqbbQTMemCSyyToyLPPMjug= hcXNxE (based on 0xBE 0xCB plus sixty-eight 0x00's)
Maximum valu= e: ws8JdAWrjgi5cF6siPqDEuEbqFVVEQJLyhKinDPFJ2T84m8Qib2kS4y4Sji8YCQsDQ5Zjpc= rMMuNu7nnHyJ5j9x1Fcg5iUwvZ7krH (based on 0xBE 0xCB plus sixty-eight 0xFF's= )

Generation of master seed:

=
1. Take either an existing 16, 32 or 64 byte master seed S, or genera= te one from a (P)RNG.
2. Calculate I =3D HMAC-SHA512(key =3D "Bi= tcoin seed", msg =3D S)
3. Split I into two 32-byte sequences, I= L and IR.
4. Use IL as master secret key. IR, the master chain c= ode is not relevant here.
5. In case IL is 0 or >=3D N, the m= aster key is invalid. Go back to step 1 if generating, or in case of a pro= vided master seed, return an error.
6. Compute the public key K = =3D IL*G
7. Calculate the master Bitcoin public address A =3D Ba= se58Check(RIPEMD160(SHA256(K)))
8. Calculate the salt =3D SHA256= (SHA256(A))[0...3]

Encryption:

9. Derive a hash H from the passphrase using scrypt
 = ;   - Parameters: passphrase is the passphrase itself encoded in UTF-= 8, salt =3D salt, n =3D 16384, r =3D 8, p =3D 8, length =3D seed length + = 32
10. The first number of bytes in H, equal to length of seed S= are used to xor seed S. Call the result X.
11. Do AES256Encrypt= (message =3D X, key =3D last 32 bytes of H), call this encrypted_seed.


The encrypted_master_seed is the Base= 58Check-encoded concatenation of the following, which totals 2 + 4 + seed = length bytes (22, 38 or 70 bytes):

encrypted_mast= er_seed =3D prefix + salt + encrypted_seed

The cl= ear version is:

master_seed =3D prefix + salt + s= eed S


Decryption:

1. Collect encrypted_master_seed and passphrase from user.
<= div>2. Perform step 9 of encryption with the passphrase and the salt from = the encrypted_master_seed.
3. With the encrypted_seed from encry= pted_master_seed do AES256Decrypt(message =3D encrypted_seed, key =3D last= 32 bytes of H), call this decrypted_seed.
4. With the first num= ber of bytes in H, equal to the length of the decrypted_seed, perform the = xor operation on decrypted_seed and call the result S.
5. Perfor= m generation steps 2 until 8 and verify that the generated salt is equal t= o the salt from encrypted_master_seed.


=
Suggestions for implementers of proposal with alt-chains

This proposal involves hashing of a text rep= resentation of a public address which for Bitcoin includes the leading '1'= . Alt-chains can easily be denoted simply by using the alt-chain's preferr= ed format for representing an address. Alt-chain implementers may also cha= nge the prefix such that encoded master seeds do not start with "WS" or "w= s".


Bitcoin testnet repres= entation

This proposal does not cover se= parate Bitcoin testnet representations of encoded master seeds, although s= ince the 4 salt bytes are based on a double SHA256 of the Bitcoin public a= ddress, they will be different for Bitcoin testnet public addresses and va= lidation will fail. 


= Reference implementation

TODO
=

Test vectors

=
Test 1:

Seed      : 000= 102030405060708090a0b0c0d0e0f
Clear     : WSZsLQ5c1uKr= RQugbrZNYsvMhRixiaWaVmJ
Password  : Satoshi
Encry= pted : wsHb15443fYPmneEXskd6wUZeP15fCiA69n
Address   : 15mK= Kb2eos1hWa6tisdPwwDC1a5J1y9nma
xprv      : xprv9s= 21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF= 5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
xpub      : xpub6= 61MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8= YtGqsefD265TMg7usUDFdp6W1EGMcet8

Test 2:

Seed      : 7f0ad7d595be13e6fe4cf1fa0fbb6a= e9c26c5d9b09920709414982b6363d5844
Clear     : WSB7z3i= zBZwDoaAUA4mDpEHzAZsA5zfTWu3cCxhkaLtZ4Ur6n6mXsgpMK
Password &nbs= p;: Nakamoto
Encrypted : wsFp1uM2gFhd2PuRzmNFReRud71hgmVwPoc7cGp= xuvgETRsv8J1wHNANJ
Address   : 1A54ECavJaJAoLGqqNrPd9Y3cvSv= kL2Roz
xprv      : xprv9s21ZrQH143K3f9hMVvcbY4EX4= CfxsEtc6C5BMkZtgGpTGpxAscoq7SLSAcL6k5dxaZ9s4SChrtfSFoKpijuwAnhuPn76eva6W8b= Dr118t3
xpub      : xpub661MyMwAqRbcG9EATXTcxfzy5= 63ANKxjyK7fykABT1ooL5A6iQw4NukpHShDxYgeso4NHscFmqcVEtdUt61c8RCf7FqXK9z6sgf= kQvYBQPP

Test 3:

Seed &n= bsp;    : fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1= aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542=
Clear     : WS6186bsAkSaGRjRZ1UGyCGigxsXPvnYGSqNHJYma= uV9X4W8tLJke1DH8UP8YMsDLdsjwgodcghjjKqkWQmk3t7qDbNMJVBDKcD2s
Pas= sword  : Vires In Numeris
Encrypted : ws7vDy7RjqMvcPX7GeakK= vdK6vDKGhRSjQtaRfKUVQrJXwwetLSeTdNgGzn5BKZZqz1BBdaHBFYfLvNUSxDaoP1ojJMMJD9= UnQuwt
Address   : 1JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg
=
xprv      : xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5N= UtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U
xpub      : xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMs= ktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB

Test 4:

Seed     =  : 6ca4a27ac660c683340f59353b1375a9
Clear     : W= SXnfK5CJbDoSwcqMfz7Xqy3avuPHSxDQQk
Password  : =E8=81=A1=E4= =B8=AD=E6=9C=AC
Encrypted : wsFWKz3c5eeHRwtJveSdFvwUrmoNVkJ5ns2<= /div>
Address   : 1JVncPbsdB2s4zHim3VdAWNkZ8JANBZ1U9
xp= rv      : xprv9s21ZrQH143K3mJ4upPSDfXdA34yNjem6PSsXT63vm8dq= 8ikUJv4iiTD3PrSKtdGZXFVD689z5T7knXo55BjcHS2WL3Syp2DbGgnbgxw2QA
x= pub      : xpub661MyMwAqRbcGFNY1qvSaoUMi4uTnCNcTcNUKqVfV6fc= hw3u1rEKGWmgtfUMRKLgUHNZ7dfsh8Ys6SLwUojZqScFBQL3dFGF3QywNLJVZ2o
=

Acknowledgements
=
Mike Caldwell for BIP 0038, which this proposal borrows hea= vily from.


See Also

BIP 0032 Hierarchical Deterministic Wallets: h= ttps://en.bitcoin.it/wiki/BIP_0032
BIP 0038 Passphrase-protected= private key: https://en.bitcoin.it/wiki/BIP_0038




= --Boundary_(ID_vCDqojFBlF75WOGzHG7oGw)-- --Boundary_(ID_yJUaRPUvPvzdeOgLJTpPqQ)--