path: root/26/b1b7b156e0d0926bb17827ae1728b83c28daa8

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 <jeanpaulkogelman@me.com>) 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 <jeremy@taplink.co>,
	bitcoin-development@lists.sourceforge.net
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
Date: Fri, 19 Jul 2013 18:15:32 +0000 (GMT)
X-Mailer: iCloud Mail (1R)
X-Originating-IP: [159.153.138.53]
Message-id: <acc0f014-7ae3-4e45-87ad-2b0e5358dca9@me.com>
In-reply-to: <op.w0hd2nthyldrnw@laptop-air>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <jeremy@taplink.co> 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 <jeanpaulkog=
elman@me.com> 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

<html><body><div>Hi Jeremy,</div><div><br></div><div>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><div><br><=
/div><div>jp<br><br>On Jul 19, 2013, at 11:09 AM, Jeremy Spilman &lt;jerem=
y@taplink.co&gt; wrote:<br><br></div><div><div><blockquote type=3D"cite"><=
div class=3D"msg-quote"><div>Very clear write-up Jean!</div><div><br></div=
><div>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?</div><div><br></div><div>Does this=
 basically serve the fucntion of an IV?</div><div><br></div><div>Do you re=
ally need this since the master seed must be high entropy random bytes in =
the first place?</div><div><br></div><div>Thanks,</div><div>--Jeremy</div>=
<div><br></div><div>On Fri, 19 Jul 2013 10:46:44 -0700, Jean-Paul Kogelman=
 &lt;jeanpaulkogelman@me.com&gt; wrote:<br></div><br><blockquote style=3D"=
margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex" dat=
a-mce-style=3D"margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding=
-left: 1ex;"><div><br></div><div>Hi everyone,</div><div><br></div><div>I'm=
 looking for feedback on the proposal below.</div><div><br></div><div>Kind=
 regards,</div><div><br></div><div>Jean-Paul</div><div><br></div><div>---<=
/div><div>BIP:&nbsp;</div><div>Title: Base58 encoded HD Wallet master seed=
 with optional encryption</div><div>Author: Jean-Paul Kogelman</div><div>S=
tatus: Draft</div><div>Type: Informational</div><div>Created: 17-07-2013</=
div><div><br></div><div><strong>Abstract</strong></div><div><br></div><div=
>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.</div><div><br></div><div>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.</div><div><=
br></div><div>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><div><br></div><div><br></div><=
div><strong>Motivation</strong></div><div><br></div><div>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.&nbsp;</div><div><br></div><div>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;</div><div><br></div><div><br></div><div><strong>Copyright</strong></=
div><div><br></div><div>This proposal is hereby placed in the public domai=
n.</div><div><br></div><div><br></div><div><strong>Rationale</strong></div=
><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.&nbsp;</div><div><br></div><div><br></div><div><strong>Specificati=
on</strong></div><div><br></div><div>This proposal makes use of the follow=
ing functions and definitions:</div><div><br></div><div>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.</div><div><br></di=
v><div>SHA256: a well-known hashing algorithm that takes an arbitrary numb=
er of bytes as input and deterministically yields a 32-byte hash.</div><di=
v><br></div><div>RIPEMD160: a well known hashing algorithm that takes an a=
rbitrary number of bytes as input and deterministically yields a 20-byte h=
ash.</div><div><br></div><div>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><div><br><=
/div><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.</div><div><br></div><div>Base58Che=
ck: a method for encoding arrays of bytes using 58 alphanumeric characters=
 commonly used in the Bitcoin ecosystem.</div><div><br></div><div>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.</div><div><br></div><div><=
span style=3D"text-decoration: underline;" data-mce-style=3D"text-decorati=
on: underline;">Prefix</span></div><div><br></div><div>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.&nbsp;</div><div><br></div><div>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.</div><div=
><br></div><div><span style=3D"text-decoration: underline;" data-mce-style=
=3D"text-decoration: underline;">Proposed specification</span></div><div><=
br></div><div>There are 2 seed record representations with 3 lengths each,=
 resulting in a total of 6 different object identifier prefixes.&nbsp;</di=
v><div><br></div><div>Prefix 0x1093: Clear 16 byte master seed, total leng=
th: 22 bytes</div><div>Prefix 0x1E68: Clear 32 byte master seed, total len=
gth: 38 bytes</div><div>Prefix 0x665A: Clear 64 byte master seed, total le=
ngth: 70 bytes</div><div><br></div><div>Prefix 0x1EE4: 2-factor 16 byte ma=
ster seed, total length: 22 bytes</div><div>Prefix 0x38AE: 2-factor 32 byt=
e master seed, total length: 38 bytes</div><div>Prefix 0xBECB: 2-factor 64=
 byte master seed, total length: 70 bytes</div><div><br></div><div>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.</div><div><br></div><div>How the user sees it: 35, 57 or 101 ch=
aracters always starting with either "WS" or "ws".</div><div><br></div><di=
v>Count of payload bytes (beyond prefix): 20, 36 or 68</div><div><br></div=
><div>Payload format:</div><div>4 bytes: SHA256(SHA256(master_bitcoin_publ=
ic_address))[0...3], used both for typo checking and as salt.</div><div>16=
, 32 or 64 bytes: either a clear representation or an encrypted representa=
tion of the master seed.</div><div><br></div><div>Range in Base58Check enc=
oding for clear 16 byte master seed (prefix WS):</div><div>Minimum value: =
WSJ5JnjiRZT8b15aZr6GGWzt2VMBPapmhBQ (based on 0x10 0x93 plus twenty 0x00's=
)</div><div>Maximum value: WShQumr1iGdbTpWiesWbb189p7rSLBiq3EJ (based on 0=
x10 0x93 plus twenty 0xFF's)</div><div><br></div><div>Range in Base58Check=
 encoding for clear 32 byte master seed (prefix WS):</div><div>Minimum val=
ue: WS7SqjMWhDGCagcZxCk317LLWyWUny7465ENGKEKuxBf5sFvRHmRRfCgr (based on 0x=
1E 0x68 plus thirty-six 0x00's)</div><div>Maximum value: WSLAbo8WHEQr1Z1cv=
26Z5njh5URHMo9fPiDFYE2NpCwmAoPZwDxzm3PjB (based on 0x1E 0x68 plus thirty-s=
ix 0xFF's)</div><div><br></div><div>Range in Base58Check encoding for clea=
r 64 byte master seed (prefix WS):</div><div>Minimum value: WS2cMzM9WrogWV=
LKYFzTaTXZnYCryY31uptmdevXuRFBXTWJhmt4No9Eejoj3apqyU5RkyXsGHFPbZd14oz7Fv1M=
i85kadBD4TPsL (based on 0x66 0x5A plus sixty-eight 0x00's)</div><div>Maxim=
um value: WS6PXJ1HoJXn9hyLz8uXQEy2ZajAVaFDTViXhZDthwYbhyvfHRqjwU4FoGpepCbu=
uycAwMFbgoZB6E48baqD1c9PdMNUZCSSBmfE7 (based on 0x66 0x5A plus sixty-eight=
 0xFF's)</div><div><br></div><div>Range in Base58Check encoding for 2-fact=
or 16 byte master seed (prefix ws):</div><div>Minimum value: ws1nyTi9KjdRk=
Jda4Yh1KkXSLC8SZ6kKzEM (based on 0x1E 0xE4 plus twenty 0x00's)</div><div>M=
aximum value: wsR8aSpScSotd84i9a7LeEei7pdhVkeciX8 (based on 0x1E 0xE4 plus=
 twenty 0xFF's)</div><div><br></div><div>Range in Base58Check encoding for=
 2-factor 32 byte master seed (prefix ws):</div><div>Minimum value: wsC8sa=
yZpTpeX3k6jcCMeTedDapXkXd7SZpRJbSjdeqKBJ2Vnrm1xyfD3 (based on 0x38 0xAE pl=
us thirty-six 0x00's)</div><div>Maximum value: wsQrdekZQUyHwv99hRYsj93yn5j=
LKMfikCoJaWEnXubRGEA9Jnxg5KaPW (based on 0x38 0xAE plus thirty-six 0xFF's)=
</div><div><br></div><div>Range in Base58Check encoding for 2-factor 64 by=
te master seed (prefix ws):</div><div>Minimum value: ws4XTrriTEyyy2TrGWv9R=
7o94CyBiN69S2VxiK5tVW9htEi48w54sQ43JChCmadoGtYpZSu7vqbbQTMemCSyyToyLPPMjug=
hcXNxE (based on 0xBE 0xCB plus sixty-eight 0x00's)</div><div>Maximum valu=
e: ws8JdAWrjgi5cF6siPqDEuEbqFVVEQJLyhKinDPFJ2T84m8Qib2kS4y4Sji8YCQsDQ5Zjpc=
rMMuNu7nnHyJ5j9x1Fcg5iUwvZ7krH (based on 0xBE 0xCB plus sixty-eight 0xFF's=
)</div><div><br></div><div>Generation of master seed:</div><div><br></div>=
<div>1. Take either an existing 16, 32 or 64 byte master seed S, or genera=
te one from a (P)RNG.</div><div>2. Calculate I =3D HMAC-SHA512(key =3D "Bi=
tcoin seed", msg =3D S)</div><div>3. Split I into two 32-byte sequences, I=
L and IR.</div><div>4. Use IL as master secret key. IR, the master chain c=
ode is not relevant here.</div><div>5. In case IL is 0 or &gt;=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.</div><div>6. Compute the public key K =
=3D IL*G</div><div>7. Calculate the master Bitcoin public address A =3D Ba=
se58Check(RIPEMD160(SHA256(K)))</div><div>8. Calculate the salt =3D SHA256=
(SHA256(A))[0...3]</div><div><br></div><div>Encryption:</div><div><br></di=
v><div>9. Derive a hash H from the passphrase using scrypt</div><div>&nbsp=
; &nbsp; - 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</div><div>10. The first number of bytes in H, equal to length of seed S=
 are used to xor seed S. Call the result X.</div><div>11. Do AES256Encrypt=
(message =3D X, key =3D last 32 bytes of H), call this encrypted_seed.</di=
v><div><br></div><div><br></div><div>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):</div><div><br></div><div>encrypted_mast=
er_seed =3D prefix + salt + encrypted_seed</div><div><br></div><div>The cl=
ear version is:</div><div><br></div><div>master_seed =3D prefix + salt + s=
eed S</div><div><br></div><div><br></div><div>Decryption:</div><div><br></=
div><div>1. Collect encrypted_master_seed and passphrase from user.</div><=
div>2. Perform step 9 of encryption with the passphrase and the salt from =
the encrypted_master_seed.</div><div>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.</div><div>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.</div><div>5. Perfor=
m generation steps 2 until 8 and verify that the generated salt is equal t=
o the salt from encrypted_master_seed.</div><div><br></div><div><br></div>=
<div><strong>Suggestions for implementers of proposal with alt-chains</str=
ong></div><div><br></div><div>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".</div><div><br></div><div><br></div><div><strong>Bitcoin testnet repres=
entation</strong></div><div><br></div><div>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.&nbsp;</div><div><br></div><div><br></div><div><strong>=
Reference implementation</strong></div><div><br></div><div>TODO</div><div>=
<br></div><div><br></div><div><strong>Test vectors</strong></div><div><br>=
</div><div>Test 1:</div><div><br></div><div>Seed &nbsp; &nbsp; &nbsp;: 000=
102030405060708090a0b0c0d0e0f</div><div>Clear &nbsp; &nbsp; : WSZsLQ5c1uKr=
RQugbrZNYsvMhRixiaWaVmJ</div><div>Password &nbsp;: Satoshi</div><div>Encry=
pted : wsHb15443fYPmneEXskd6wUZeP15fCiA69n</div><div>Address &nbsp; : 15mK=
Kb2eos1hWa6tisdPwwDC1a5J1y9nma</div><div>xprv &nbsp; &nbsp; &nbsp;: xprv9s=
21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF=
5kejMRNNU3TGtRBeJgk33yuGBxrMPHi</div><div>xpub &nbsp; &nbsp; &nbsp;: xpub6=
61MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8=
YtGqsefD265TMg7usUDFdp6W1EGMcet8</div><div><br></div><div>Test 2:</div><di=
v><br></div><div>Seed &nbsp; &nbsp; &nbsp;: 7f0ad7d595be13e6fe4cf1fa0fbb6a=
e9c26c5d9b09920709414982b6363d5844</div><div>Clear &nbsp; &nbsp; : WSB7z3i=
zBZwDoaAUA4mDpEHzAZsA5zfTWu3cCxhkaLtZ4Ur6n6mXsgpMK</div><div>Password &nbs=
p;: Nakamoto</div><div>Encrypted : wsFp1uM2gFhd2PuRzmNFReRud71hgmVwPoc7cGp=
xuvgETRsv8J1wHNANJ</div><div>Address &nbsp; : 1A54ECavJaJAoLGqqNrPd9Y3cvSv=
kL2Roz</div><div>xprv &nbsp; &nbsp; &nbsp;: xprv9s21ZrQH143K3f9hMVvcbY4EX4=
CfxsEtc6C5BMkZtgGpTGpxAscoq7SLSAcL6k5dxaZ9s4SChrtfSFoKpijuwAnhuPn76eva6W8b=
Dr118t3</div><div>xpub &nbsp; &nbsp; &nbsp;: xpub661MyMwAqRbcG9EATXTcxfzy5=
63ANKxjyK7fykABT1ooL5A6iQw4NukpHShDxYgeso4NHscFmqcVEtdUt61c8RCf7FqXK9z6sgf=
kQvYBQPP</div><div><br></div><div>Test 3:</div><div><br></div><div>Seed &n=
bsp; &nbsp; &nbsp;: fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1=
aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542=
</div><div>Clear &nbsp; &nbsp; : WS6186bsAkSaGRjRZ1UGyCGigxsXPvnYGSqNHJYma=
uV9X4W8tLJke1DH8UP8YMsDLdsjwgodcghjjKqkWQmk3t7qDbNMJVBDKcD2s</div><div>Pas=
sword &nbsp;: Vires In Numeris</div><div>Encrypted : ws7vDy7RjqMvcPX7GeakK=
vdK6vDKGhRSjQtaRfKUVQrJXwwetLSeTdNgGzn5BKZZqz1BBdaHBFYfLvNUSxDaoP1ojJMMJD9=
UnQuwt</div><div>Address &nbsp; : 1JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg</div>=
<div>xprv &nbsp; &nbsp; &nbsp;: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5N=
UtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U</div=
><div>xpub &nbsp; &nbsp; &nbsp;: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMs=
ktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB</di=
v><div><br></div><div>Test 4:</div><div><br></div><div>Seed &nbsp; &nbsp; =
&nbsp;: 6ca4a27ac660c683340f59353b1375a9</div><div>Clear &nbsp; &nbsp; : W=
SXnfK5CJbDoSwcqMfz7Xqy3avuPHSxDQQk</div><div>Password &nbsp;: =E8=81=A1=E4=
=B8=AD=E6=9C=AC</div><div>Encrypted : wsFWKz3c5eeHRwtJveSdFvwUrmoNVkJ5ns2<=
/div><div>Address &nbsp; : 1JVncPbsdB2s4zHim3VdAWNkZ8JANBZ1U9</div><div>xp=
rv &nbsp; &nbsp; &nbsp;: xprv9s21ZrQH143K3mJ4upPSDfXdA34yNjem6PSsXT63vm8dq=
8ikUJv4iiTD3PrSKtdGZXFVD689z5T7knXo55BjcHS2WL3Syp2DbGgnbgxw2QA</div><div>x=
pub &nbsp; &nbsp; &nbsp;: xpub661MyMwAqRbcGFNY1qvSaoUMi4uTnCNcTcNUKqVfV6fc=
hw3u1rEKGWmgtfUMRKLgUHNZ7dfsh8Ys6SLwUojZqScFBQL3dFGF3QywNLJVZ2o</div><div>=
<br></div><div><br></div><div><strong>Acknowledgements</strong></div><div>=
<br></div><div>Mike Caldwell for BIP 0038, which this proposal borrows hea=
vily from.</div><div><br></div><div><br></div><div><strong>See Also</stron=
g></div><div><br></div><div>BIP 0032 Hierarchical Deterministic Wallets: h=
ttps://en.bitcoin.it/wiki/BIP_0032</div><div>BIP 0038 Passphrase-protected=
 private key: https://en.bitcoin.it/wiki/BIP_0038</div><div><br></div></bl=
ockquote><br><br><br></div></blockquote></div></div><style class=3D"_messa=
ge-styles">div.msg-quote  {font-family: 'Times New Roman'; font-size: 13px=
;}=0A</style></body></html>=

--Boundary_(ID_vCDqojFBlF75WOGzHG7oGw)--

--Boundary_(ID_yJUaRPUvPvzdeOgLJTpPqQ)--