From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7D639AF0 for ; Wed, 9 Aug 2017 19:41:55 +0000 (UTC) X-Greylist: delayed 00:06:21 by SQLgrey-1.7.6 Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch [138.201.55.219]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 22F8B458 for ; Wed, 9 Aug 2017 19:41:55 +0000 (UTC) Received: from [192.168.0.2] (cable-static-238-67.teleport.ch [213.188.238.67]) by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 465FA15E4209; Wed, 9 Aug 2017 21:35:33 +0200 (CEST) From: Jonas Schnelli Content-Type: multipart/signed; boundary="Apple-Mail=_986A2EB1-ACA0-4ABE-B314-96DB8B64B688"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 9 Aug 2017 21:35:26 +0200 References: To: Colin Lacina , Bitcoin Protocol Discussion In-Reply-To: Message-Id: <5C198808-A3BB-413D-A793-0107095EFBE9@jonasschnelli.ch> X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at bitcoinsrv.jonasschnelli.ch X-Virus-Status: Clean Subject: Re: [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 19:41:55 -0000 --Apple-Mail=_986A2EB1-ACA0-4ABE-B314-96DB8B64B688 Content-Type: multipart/alternative; boundary="Apple-Mail=_7920C06E-0982-44B4-8DDF-9A9DDF407611" --Apple-Mail=_7920C06E-0982-44B4-8DDF-9A9DDF407611 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Colin > In case the server goes rogue and starts refusing to sign, the user = can use their userRecoveryPrivKey to send the funds anywhere they = choose. Because if this, the userRecoveryPrivKey is best suited to cold = wallet storage. Would you then assume that userWalletPubKey is a hot key (stored on the = users computer eventually in a browser based local storage container)? In case of an attack on the server responsible for serverWalletPubKey = (where also the personal information of the user are stored [including = the xpub =3D=3D amount of funds hold by the user)), wound=E2=80=99t this = increase the users risk of being an possible target (False sense of = multisig security, comparing to cold storage / HWW keys)? > In the more likely event that the user forgets their password and/or = looses access to their userWalletPrivKey as well as loses their recovery = key, they rely on the serverRecoveryPrivKey. >=20 > When the user first sets up their wallet, they answer some basic = identity information, set up a recovery password, and/or set up recovery = questions and answers. This information is explicitly NOT sent to serve = with the exception of recovery questions (although the answers remain = with the user, never seeing the server). What is sent to the server is = it's 256 bit hash used to identify the recovery wallet. The server then = creates a 1025 bit nonce, encrypts it, stores it, and transmits it to = the user's client. I guess this will result in protecting the funds stored in this = transaction entirely on the users identity information and eventually = the optional recovery password, though I guess you are adding additional = security by protecting via the server nonce from brute-forcing. Why 1025bit for the nonce? Why SHA512 instead of SHA256 (I guess you need 256bit symmetric key = material for the key encryption)? Considered using a (H)KDF for deriving the symmetric key (even if the = server based nonce reduces the possibility of brute-forcing)? Your modal has probably the TORS (trust on recovery setup) weakness = (compared to a HWW where you [should] be protected on compromised = systems during private key creation). --Apple-Mail=_7920C06E-0982-44B4-8DDF-9A9DDF407611 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Colin

In case the server goes = rogue and starts refusing to sign, the user can use their = userRecoveryPrivKey to send the funds anywhere they choose. Because if = this, the userRecoveryPrivKey is best suited to cold wallet = storage.

Would you then assume that userWalletPubKey is a hot key (stored on the users computer = eventually in a browser based local storage = container)?
In = case of an attack on the server responsible for serverWalletPubKey = (where also the personal information of the user are stored = [including the xpub =3D=3D amount of funds hold by the user)), = wound=E2=80=99t this increase the users risk of being an possible = target (False sense of multisig security, comparing to cold storage = / HWW keys)?

In the more = likely event that the user forgets their password and/or looses access to = their userWalletPrivKey as well as loses their recovery key, they rely on the = serverRecoveryPrivKey.

When the user first sets up = their wallet, they answer some basic identity information, set up a = recovery password, and/or set up recovery questions and answers. This = information is explicitly NOT sent to serve with the exception of = recovery questions (although the answers remain with the user, never = seeing the server). What is sent to the server is it's 256 bit hash used = to identify the recovery wallet. The server then creates a 1025 bit = nonce, encrypts it, stores it, and transmits it to the user's = client.

I = guess this will result in protecting the funds stored in this = transaction entirely on the users identity information and eventually = the optional recovery password, though I guess you are adding additional = security by protecting via the server nonce from = brute-forcing. 

Why = 1025bit for the nonce?
Why SHA512 instead of SHA256 = (I guess you need 256bit symmetric key material for the key = encryption)?
Considered using a (H)KDF for deriving = the symmetric key (even if the server based nonce reduces the = possibility of brute-forcing)?

Your modal has probably the TORS (trust = on recovery setup) weakness (compared to a HWW where you [should] be = protected on compromised systems during private key creation).

</jonas>
= --Apple-Mail=_7920C06E-0982-44B4-8DDF-9A9DDF407611-- --Apple-Mail=_986A2EB1-ACA0-4ABE-B314-96DB8B64B688 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlmLY/4ACgkQHrd2uwPH ki2wcg//QiQoPUO2p536Nq64Yqfiw2vJc3ZAO9tzHhUnErbJ+zqgd9F7gd+uLG8K maWWnpHDfZqXtzjYCgsw5nlt9AmufppW2bW6hqguZvrh6q1FYG2pzFd1+sC6uBFS 7wPlazJbVzyAVyLfkTPC+yUAiBlj4REGOy5fnjF299o5c5WY6F6w6LSBKTuhitjl opyIOTiTKQ7lwm89b2Mx6qj5MGJhcVJ33v2KUAZlX/C7Da87f+K5o5cH9PWsDiOX y/VpqXNnIolteCU0e7CwXto8EaD6e4d6zPIOZJBhRv1orSdL+K1uvg976z5yzP9i 00V0SA1VCntfURRR+rsEKaJNGa03DItqsOtQPMK+ejvy5gmitUHpP6iMepBZjZOb Id8vyo0ebczoiRGelPOkz37RxF3aBmFRkKxSqWlmxO5tNjQLm6b9iHc7ox96MfAC VwiXm5AEoSImqu3TI3++MZlQ7Wu8lncphfJTHFufhiEoWwq+rpsZXg73turkufPD i9WcbDpjcrXWyeuyXNcbxASJYDe91pdvoFRMUUulyO6T1EKnhmTbUUch1t/1ADhJ YbUPECAl8A5gfC+dxhPzgWebn1kKFLyVeHt8TtjC0DL7mR0xMPedleOm1D9njzog JAX9aJ5hYVK8nKIMOk4IiOgC2FDu3d0h5LpHZx23HuoH+Ea+fYs= =Guse -----END PGP SIGNATURE----- --Apple-Mail=_986A2EB1-ACA0-4ABE-B314-96DB8B64B688--