From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VW4m3-0007xy-Oy for bitcoin-development@lists.sourceforge.net; Tue, 15 Oct 2013 13:35:00 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.45 as permitted sender) client-ip=74.125.83.45; envelope-from=adam.back@gmail.com; helo=mail-ee0-f45.google.com; Received: from mail-ee0-f45.google.com ([74.125.83.45]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VW4m1-00037O-02 for bitcoin-development@lists.sourceforge.net; Tue, 15 Oct 2013 13:34:58 +0000 Received: by mail-ee0-f45.google.com with SMTP id c50so3999378eek.4 for ; Tue, 15 Oct 2013 06:34:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=AO9yvEUE1sURfQV/RaOZFhLlbW1blCzRFidoDhhMHWM=; b=ZA59ssg8HLouPOcCnCBxBfqHAxm2EraR+j3DMrjQxRzf5GzdoFR+rihmMHRM/dKeqC YIUKnRGlfhNvXnMlv74JUf6za0H6JJwF84WOea3DkGHY7mCCpmB2dHf0RnS4GeshvCRT 4DKQHHjSGcX85EZFswlezJ5ixxAdsK+XgNs3hDjv7nKIzmTjx2/Dlub+pFq2fTWrnpZy nB8VHJFriNvh4ZKZ6BzgfunapWccZld0mmwMAEdUlUwJ/vwbWK/jHoXm89oh5fvwTOQb LnIs1uiC4zP0d8dkyq5TuVO0rhl9K+glsbgUmGtCKHQ/SHaaoyUwNkoachm01L1Xwyjm AVog== X-Received: by 10.14.204.195 with SMTP id h43mr80522eeo.111.1381844090581; Tue, 15 Oct 2013 06:34:50 -0700 (PDT) Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90]) by mx.google.com with ESMTPSA id f49sm166681601eec.7.1969.12.31.16.00.00 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Oct 2013 06:34:49 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id 86A7F2E016D; Tue, 15 Oct 2013 15:34:49 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Tue, 15 Oct 2013 15:34:46 +0200 Date: Tue, 15 Oct 2013 15:34:46 +0200 From: Adam Back To: Bitcoin-Dev Message-ID: <20131015133446.GA5690@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:131015:bitcoin-development@lists.sourceforge.net::k4SymqqvL1A9d TVg:000000000000000000003m8v X-Hashcash: 1:20:131015:adam@cypherspace.org::pg4Ksao6nnql0cKl:00000000000000000 000000000000000000000000J/Ic X-Spam-Score: -1.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (adam.back[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bitcointalk.org] X-Headers-End: 1VW4m1-00037O-02 Subject: [Bitcoin-development] two comments on brain-wallet security (and BIP 38) 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: Tue, 15 Oct 2013 13:35:00 -0000 So I had a go at deciphering BIP 038 in summary what I think its doing is (ommitting lot and sequence and deterinistic IVs for simplicity): user: x1 = Scrypt( salt=random, pass ) P = x1*G send (salt, P) to coin manufacturer -> manufacturer: x2 = random 24bytes Q = x2*P k = Scrypt( salt2=H(Q)||salt, pass=P ) e = AES_k( x2 ) manufacturer puts es inside coin. <- send coin, (salt, e, Q) to user then optionally creates conf code: B = x2*G c = AES_k( B ) <- send conf code c to user verify code c: (by recreating P, then k from Q & P, decrypt c to get B, check Q = x1*B) x1 = Scrypt( salt, pass ) P = x1*G k = Scrypt( salt2=H(Q)||salt, pass=P ) Which seems reasonable enough, however its unfortunate that you have to repeat the Scrypt work at setup. One thing that occurs to me eg as mentioned by Rivest et al in their time-lock puzzle paper is that it is easy to create work, if you are ok with parallelizable symmetric constructions (like scrypt(i) or PBKDF2(i) with i iterations) without *doing* the work during setup. It seems to me therefore that the above protocol could avoid the javascript overhead issue that forces users to choose a weak iteration level if they want to create the wallet in that way. eg create a 32-bit random salt, replace scrypt(i=16384, salt, pass) with scrypt(i=1,salt, pass) to be brute forced based on deleted salt. Immediate 2^32 = 4billion iteration salt without any significant setup cost. (Or if you want to limit the parallelism say scrypt(i=65536, salt, pass) with a deleted 16-bit salt. That should be parallelizable up to 65536 GPU cores (32x 7970 chips). Symmetric time-lock puzzles can achieve decrypt asymmetry without repeating the work at setup... (Rivest et al goes on to avoid using that symmetric construct with an RSA related mechanism, because they are trying to lock information for an approximate future date, rather than protected by a specific amount of grinding work.) I proposed a different blind (securely server-offloadable) deterministic proof of work relating to (asymmetric RSA-style) time-lock puzzles. The difference from time-lock is it is made blind (so the work can be securely offloaded without the server learning your password or resulting key) and can be easily made parallelizable also which is desirable for server offload. https://bitcointalk.org/index.php?topic=311000.new#new I think that could take brain-wallets to a new level of security, if you protect the amount by an amount of computation proportional to the value, eg 0.1% or 0.01% redemption cost paid to blind proof of work miners. Adam