Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <will.madden@novauri.com>) id 1YIci4-0003hv-Pa for bitcoin-development@lists.sourceforge.net; Tue, 03 Feb 2015 12:36:04 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of novauri.com designates 209.85.213.178 as permitted sender) client-ip=209.85.213.178; envelope-from=will.madden@novauri.com; helo=mail-ig0-f178.google.com; Received: from mail-ig0-f178.google.com ([209.85.213.178]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YIci1-0003G6-Ou for bitcoin-development@lists.sourceforge.net; Tue, 03 Feb 2015 12:36:04 +0000 Received: by mail-ig0-f178.google.com with SMTP id hl2so23991414igb.5 for <bitcoin-development@lists.sourceforge.net>; Tue, 03 Feb 2015 04:35:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-type; bh=1GL5pDu6C/PxW51QJObk+Kd1VrCkF+UsOPDtejYKXe0=; b=kh+qrssn18FZJ6hHI+FlyoSXyDJUMR9QO1HBHr8OOAEiqyPk7vgBajCWEPUwl4sxnc /NHGmZaFpdgTlNGr9yJv2gsnaLbqw6EkAvk6FSV0BfVJQbqwpyBDRSeBpkyd/MiubFf8 HHIpoahgaMVHdpljiYCRzoLYOxss1a3/dzzB1FpxJylK1CCTmB8TuyzBe4ZHha63/EY0 diqVHYeni5uI+b1ZHsDJYWNe1bFNMEhhptHGjN0sFhFp5LgDg8LZ6P2XL/3A2GI1/V6U /0gJmrqyJLcuTqqM+kuzwe34VcD803tzC/k9TyqS5Z5lqYNmOWkrTF2lVXt5b1RI8Yf8 7HlA== X-Gm-Message-State: ALoCoQko+fsdqqb7cbnVLqAqHxV50nFq99VrG01xUl2oOaS5nqQ8FWof7O+6jXRNU37I3ZSDdFEy X-Received: by 10.50.32.33 with SMTP id f1mr17368730igi.9.1422965063683; Tue, 03 Feb 2015 04:04:23 -0800 (PST) Received: from Williams-MBP (c-107-2-216-154.hsd1.co.comcast.net. [107.2.216.154]) by mx.google.com with ESMTPSA id r15sm2986418ioi.1.2015.02.03.04.04.22 for <bitcoin-development@lists.sourceforge.net> (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 04:04:22 -0800 (PST) Date: Tue, 3 Feb 2015 05:04:21 -0700 From: Will <will.madden@novauri.com> To: bitcoin-development@lists.sourceforge.net Message-ID: <etPan.54d0b945.46e87ccd.7f23@Williams-MBP> X-Mailer: Airmail (286) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="54d0b945_3d1b58ba_7f23" 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 X-Headers-End: 1YIci1-0003G6-Ou Subject: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware 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: Tue, 03 Feb 2015 12:36:04 -0000 --54d0b945_3d1b58ba_7f23 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline An idea for the bitcoin malware proposal below, the idea is at the bottom= =E2=80=A6 Using a desktop website and mobile device for 2/3 multisig in lieu of a h= ardware device (trezor) and desktop website (mytrezor) works, but the key= is that the device used to input the two signatures=C2=A0cannot be in th= e same band. =C2=A0What you are protecting against are MITM attacks. =C2=A0= The issue is that if a single=C2=A0device or network is compromised by ma= lware, or if a party is connecting to a counterparty through a channel wi= th compromised security, inputing 2 signatures through the=C2=A0same devi= ce/band defeats=C2=A0the purpose of 2/3 multisig. =C2=A0This is the same = as how MITM defeats 2=46A via mobile phone if the token is entered into t= he same website as the password - the token is simply passed through by t= he attacker to the secure session with the provider, allowing unfettered = access or reuse of tokens for transactions other than those intended by t= he real user. Companies have=C2=A0found clever ways around MITM attacks using SSL sniff= and derivatives by embedding code in mobile apps that communicate not wi= th the website authenticating the user, but with 3rd party company that a= uthenticates the token and passes the authentication to the website throu= gh a different secure channel, making the MITM attack far much more diffi= cult. =C2=A0The trick here is that instead of one channel, we now have tw= o channels that must be compromised. =C2=A0Also, the second channel is be= tween a security company and a (hopefully) professionally run=C2=A0financ= ial=C2=A0services website. =C2=A0There are other approaches to defeat MIT= M, such as fingerprinting pages to detect spoofs. =C2=A0The former (secur= e 3rd party channel) is very secure but requires a trusted third party. =C2= =A0The latter (fingerprinting) is a crap shoot with very high=C2=A0false = positive rates. =C2=A0 Anyway, the exact same principles apply here to this conversation. =C2=A0= The second signature must be presented from a separate band to maintain a= higher=C2=A0degree of security. =C2=A0If one signature occurs via HTTP(s= ) from application 1, another should be SMS through a carrier network, et= c via application 2. The trick we need to look at is how to use the bitcoin network as a deliv= ery mechanism to bypass the need for the trusted third party in the examp= le above. =C2=A0Instead of the second factor routing through a 3rd party = to the intended recipient, we have another option - one that doesn=E2=80=99= t require core development either. 1) Sender > signs signature 1 via desktop > bitcoin network 2/3 P2SH 2) Mobile app also used by sender receives req. from bitcoin network to s= ign signature - not through the site in 1 (similar to the 2nd channel bet= ween the website and security company above) 3) Sender > signs signature 2 via mobile app (or any separate device=C2=A0= operating on a different network - heck could be radio) > 2/3 signatures,= =C2=A0transaction=C2=A0authorized Any wallet service provider can use this model,=C2=A0all they must do is = develop two independent applications=C2=A0such a secure browser plugin an= d a website, or a mobile app and a website that use 2/3 multisig to autho= rize transactions. =C2=A0No core development required - just better secur= ity design and execution by those developing wallets. =C2=A0If the protoc= ol could natively communicate via two=C2=A0separate=C2=A0networks, that m= ight be something to consider, but really developers should already=C2=A0= have all the tools they need, assuming they are competent. If there was a way to perform 2/3 multisig without requiring a second ban= d, performing the function safely by somehow knowing if the service is pe= rformed from a compromised device through some sort of on-blockchain anti= -malware check by validating the signature of the signing=C2=A0applicatio= n by comparing it to a signature recorded when the multisig address was f= unded, =C2=A0that would be a really neat breakthrough. =C2=A0=46ood for t= hought, but I can=E2=80=99t see how that could be executed in a way where= signatures couldn=E2=80=99t be spoofed from a compromised device. =C2=A0= If someone cracks that problem, it=E2=80=99s a really big advance for inf= ormation security. On 02/02/2015 02:54 PM, Eric Voskuil wrote:=C2=A0 >=C2=A0On =46eb 2, 2015, at 11:53 AM, Mike Hearn wrote:=C2=A0 >>=C2=A0 >> In sending the first-signed transaction to another for second=C2=A0 >> signature, how does the first signer authenticate to the second=C2=A0 >> without compromising the independence of the two factors=3F=C2=A0 >>=C2=A0 >> Not sure what you mean. The idea is the second factor displays the=C2=A0= >> transaction and the user confirms it matches what they input to the=C2= =A0 >> first factor. Ideally, using BIP70, but I don't know if BA actually=C2= =A0 >> uses that currently.=C2=A0 >>=C2=A0 >> It's the same model as the TREZOR, except with a desktop app instead=C2= =A0 >> of myTREZOR and a phone instead of a dedicated hardware device.=C2=A0 >=C2=A0 > Sorry for the slow reply, traveling.=C2=A0 >=C2=A0 > My comments were made in reference to this proposal:=C2=A0 >=C2=A0 >>>=C2=A0On =46eb 2, 2015, at 10:40 AM, Brian Erdelyi <brian.erdelyi=40gm= ail.com=C2=A0 >>> <mailto:brian.erdelyi=40gmail.com>> wrote:=C2=A0 >>>=C2=A0 >>> Another concept...=C2=A0 >>>=C2=A0 >>> It should be possible to use multisig wallets to protect against=C2=A0= >>> malware. =46or example, a user could generate a wallet with 3 keys an= d=C2=A0 >>> require a transaction that has been signed by 2 of those keys. One=C2= =A0 >>> key is placed in cold storage and anther sent to a third-party.=C2=A0= >>>=C2=A0 >>> It is now possible to generate and sign transactions on the users=C2=A0= >>> computer and send this signed transaction to the third-party for the=C2= =A0 >>> second signature. This now permits the use of out of band transaction= =C2=A0 >>> verification techniques before the third party signs the transaction=C2= =A0 >>> and sends to the blockchain.=C2=A0 >>>=C2=A0 >>> If the third-party is malicious or becomes compromised they would not= =C2=A0 >>> have the ability to complete transactions as they only have one=C2=A0= >>> private key. If the third-party disappeared, the user could use the=C2= =A0 >>> key in cold storage to sign transactions and send funds to a new wall= et.=C2=A0 >>>=C2=A0 >>> Thoughts=3F=C2=A0 My comments below start out with the presumption of user platform=C2=A0 compromise, but the same analysis holds for the case where the user=C2=A0= platform is clean but a web wallet is compromised. Obviously the idea is=C2= =A0 that either or both may be compromised, but integrity is retained as=C2=A0= long as both are not compromised and in collusion.=C2=A0 > In the multisig scenario the presumption is of a user platform=C2=A0 > compromised by malware. It envisions a user signing a 2 of 3 output wit= h=C2=A0 > a first signature. The precondition that the platform is compromised=C2= =A0 > implies that this process results in a loss of integrity of the private= =C2=A0 > key, and as such if it were not for the second signature requirement,=C2= =A0 > the malware would be able to spend the output. This may be extended to=C2= =A0 > all of the keys in the wallet.=C2=A0 >=C2=A0 > The scenario envisions sending the signed transaction to an another=C2=A0= > (=22third=22) party. The objective is for the third party to provide th= e=C2=A0 > second signature, thereby spending the output as intended by the user,=C2= =A0 > who is not necessarily the first signer. The send must be authenticated= =C2=A0 > to the user. Otherwise the third party would have to sign anything it=C2= =A0 > received, obviously rendering the second signature pointless. This=C2=A0= > implies that the compromised platform must transmit a secret, or proof=C2= =A0 > of a secret, to the third party.=C2=A0 >=C2=A0 > The problem is that the two secrets are not independent if the first=C2= =A0 > platform is compromised. So of course the malware has the ability to=C2= =A0 > sign, impersonate the user and send to the third party. So the third=C2= =A0 > party *must* send the transaction to an *independent* platform for=C2=A0= > verification by the user, and obtain consent before adding the second=C2= =A0 > signature. The user, upon receiving the transaction details, must be=C2= =A0 > able to verify, on the independent platform, that the details match=C2=A0= > those of the transaction that user presumably signed. Even for simple=C2= =A0 > transactions this must include amount, address and fees.=C2=A0 >=C2=A0 > The central assumptions are that, while the second user platform may be= =C2=A0 > compromised, the attack against the second platform is not coordinated=C2= =A0 > with that of the first, nor is the third party in collusion with the=C2= =A0 > first platform.=C2=A0 >=C2=A0 > Upon these assumptions rests the actual security benefit (increased=C2=A0= > difficulty of the coordinated attack). The strength of these assumption= s=C2=A0 > is an interesting question, since it is hard to quantify. But without=C2= =A0 > independence the entire security model is destroyed and there is thus n= o=C2=A0 > protection whatsoever against malware.=C2=A0 >=C2=A0 > So for example a web-based or other third-party-provisioned=C2=A0 > implementation of the first platform breaks the anti-collusion=C2=A0 > assumption. Also, weak comsec allows an attack against the second=C2=A0= > platform to be carried out against its network. So for example a simple= =C2=A0 > SMS-based confirmation could be executed by the first platform alone an= d=C2=A0 > thereby also break the the anti-collusion assumption. This is why I=C2=A0= > asked how independence is maintained.=C2=A0 >=C2=A0 > The assumption of a hardware wallet scenario is that the device itself=C2= =A0 > is not compromised. So the scenario is not the same. If the user signs=C2= =A0 > with a hardware wallet, nothing can collude with that process, with one= =C2=A0 > caveat.=C2=A0 >=C2=A0 > While a hardware wallet is not subject to onboard malware, it is not=C2= =A0 > inconceivable that its keys could be extracted through probing or other= =C2=A0 > direct attack against the hardware. It's nevertheless an assumption of=C2= =A0 > hardware wallets that these attacks require loss of the hardware.=C2=A0= > Physical possession constitutes compromise. So the collusion model with= =C2=A0 > a hardware wallet does exist, it just requires device possession.=C2=A0= > Depending on the implementation the extraction may require a non-trivia= l=C2=A0 > amount of time and money.=C2=A0 >=C2=A0 > In a scenario where the user signs with HW, then sends the transaction=C2= =A0 > to a third party for a second of three signatures, and finally to a=C2=A0= > second platform for user verification, a HW thief needs to collude with= =C2=A0 > the third party or the second platform before the owner becomes aware o= f=C2=A0 > the theft (notifying the third party). This of course implies that=C2=A0= > keeping both the fist and second platforms in close proximity=C2=A0 > constitutes collusion from a physical security standpoint. This is=C2=A0= > probably sufficient justification for not implementing such a model,=C2= =A0 > especially given the cost and complexity of stealing and cracking a=C2=A0= > well-designed device. A device backup would provide comparable time to=C2= =A0 > recover with far less complexity (and loss of privacy).=C2=A0 >=C2=A0 > Incidentally the hardware wallet idea breaks down once any aspect of th= e=C2=A0 > platform or network to which it connects must be trusted, so for these=C2= =A0 > purposes I do not consider certain hybrid models as hardware wallets at= =C2=A0 > all. =46or example one such device trusts that the compromised computer= =C2=A0 > does not carry out a MITM attack between the signing device and a share= d=C2=A0 > secret entered in parts over time by the user. This reduces to a single= =C2=A0 > factor with no protection against a compromised platform.=C2=A0 >=C2=A0 > Of course these questions address integrity, not privacy. Use of a thir= d=C2=A0 > party implies loss of privacy to that party, and with weak comsec to th= e=C2=A0 > network. Similarly, use of hardware signing devices implies loss of=C2=A0= > privacy to the compromised platforms with which they exchange transacti= ons.=C2=A0 >=C2=A0 > e=C2=A0 -------------- next part --------------=C2=A0 A non-text attachment was scrubbed...=C2=A0 Name: signature.asc=C2=A0 Type: application/pgp-signature=C2=A0 Size: 473 bytes=C2=A0 Desc: OpenPGP digital signature=C2=A0 ------------------------------=C2=A0 Message: 3=C2=A0 Date:=C2=A0Mon, 2 =46eb 2015=C2=A016:44:37 -0800=C2=A0 =46rom: Pieter Wuille <pieter.wuille=40gmail.com>=C2=A0 Subject: Re: =5BBitcoin-development=5D =5Bsoftfork proposal=5D Strict DER= =C2=A0 signatures=C2=A0 To: Gregory Maxwell <gmaxwell=40gmail.com>=C2=A0 Cc: Bitcoin Dev <bitcoin-development=40lists.sourceforge.net>=C2=A0 Message-ID:=C2=A0 <CAPg+sBjjYLf4NZ8ezK7ML=5FOO-e6C8=5FV1i12AXejjrgp+w=46B-pg=40mail.gmail.c= om>=C2=A0 Content-Type: text/plain; charset=3DISO-8859-1=C2=A0 On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell <gmaxwell=40gmail.com> w= rote:=C2=A0 > So I think we should just go ahead with R/S length upper bounds as=C2=A0= > both IsStandard and in STRICTDER.=C2=A0 I would like to fix this at some point in any case.=C2=A0 If we want to do that, we must at least have signatures with too-long=C2=A0= R or S values as non-standard.=C2=A0 One way to do that is to just - right now - add a patch to 0.10 to=C2=A0 make those non-standard. This requires another validation flag, with a=C2= =A0 bunch of switching logic.=C2=A0 The much simpler alternative is just adding this to BIP66's DERSIG=C2=A0 right now, which is a one-line change that's obviously softforking. Is=C2= =A0 anyone opposed to doing so at this stage=3F=C2=A0 --=C2=A0 Pieter=C2=A0 ------------------------------=C2=A0 Message: 4=C2=A0 Date: Tue,=C2=A03 =46eb 2015 02:21:24 +0000=C2=A0 =46rom: Gregory Maxwell <gmaxwell=40gmail.com>=C2=A0 Subject: Re: =5BBitcoin-development=5D =5Bsoftfork proposal=5D Strict DER= =C2=A0 signatures=C2=A0 To: Pieter Wuille <pieter.wuille=40gmail.com>=C2=A0 Cc: Bitcoin Dev <bitcoin-development=40lists.sourceforge.net>=C2=A0 Message-ID:=C2=A0 <CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhs=46JoY=3D2j76ArXnBRsiV6g=40mail.gmail.com= >=C2=A0 Content-Type: text/plain; charset=3DUT=46-8=C2=A0 On Tue, =46eb 3, 2015 at 12:44 AM, Pieter Wuille <pieter.wuille=40gmail.c= om> wrote:=C2=A0 > The much simpler alternative is just adding this to BIP66's DERSIG=C2=A0= > right now, which is a one-line change that's obviously softforking. Is=C2= =A0 > anyone opposed to doing so at this stage=3F=C2=A0 Thats my preference.=C2=A0 ------------------------------=C2=A0 Message: 5=C2=A0 Date:=C2=A0Mon, 02 =46eb 2015=C2=A023:38:07 -0800=C2=A0 =46rom: Eric Voskuil <eric=40voskuil.org>=C2=A0 Subject: Re: =5BBitcoin-development=5D Proposal to address Bitcoin malwar= e=C2=A0 To: Brian Erdelyi <brian.erdelyi=40gmail.com>=C2=A0 Cc: Bitcoin Dev <bitcoin-development=40lists.sourceforge.net>=C2=A0 Message-ID: <54D07AD=46.8060809=40voskuil.org>=C2=A0 Content-Type: text/plain; charset=3D=22utf-8=22=C2=A0 On 02/02/2015 11:58 AM, Brian Erdelyi wrote:>=C2=A0 >>Confusing or not, the reliance on multiple signatures as offering=C2=A0= >>greater security than single relies on the independence of multiple=C2=A0= >secrets. If the secrets cannot be shown to retain independence in the=C2= =A0 >>envisioned threat scenario (e.g. a user's compromised operating=C2=A0 >>system) then the benefit reduces to making the exploit more difficult=C2= =A0 >>to write, which, once written, reduces to no benefit. Yet the user=C2=A0= >>still suffers the reduced utility arising from greater complexity,=C2=A0= >>while being led to believe in a false promise.=C2=A0 >=C2=A0 >Just trying to make sure I understand what you=3Fre saying. Are you=C2=A0= >eluding to that if two of the three private keys get compromised there=C2= =A0 >is no gain in security=3F Although the likelihood of this occurring is=C2= =A0 >lower, it is possible.=C2=A0 No, that's not it. Sorry for not being clear. Independence of control is=C2= =A0 the central issue in the analysis of a multiple factor system. If an=C2=A0= attack compromises one factor there must be no way for that attack to=C2=A0= reduce the difficulty of obtaining the other factors.=C2=A0 Some factors (secrets), like a fingerprint, aren't very secret at all.=C2= =A0 But getting someone's fingerprint doesn't also help the attacker get a=C2= =A0 PIN. That factor must be attacked independently. But if the PIN is=C2=A0 encrypted with the fingerprint in a public store, then the PIN is not=C2=A0= independent of the fingerprint and there is really only one secret.=C2=A0= If multiple factors are coincident (located within the same security=C2=A0= perimeter) they are compromized coincidentally. Coincidence has the same=C2= =A0 effect as dependence. Consider a credit card with a =22security code=22=C2= =A0 printed on the back. A successful attack on the leather wallet yields=C2=A0= both secrets.=C2=A0 Individual environments can be compromised with some difficulty (e.g.=C2=A0= desktop malware, fingerprint lift, dictionary attack, brute force PIN,=C2= =A0 etc.). =46or the sake of simplicity, let that chance of successful=C2=A0 independent attack on any factor be 1 in 2 and the resulting probability=C2= =A0 of successful concurrent attack on any n factors be 1 in 2=5En. If m=C2=A0= factors are dependent/coincident on others the relation becomes 1 in=C2=A0= 2=5E(n-m).=C2=A0 Any multi-factor web wallet that handles the user's keys in the browser=C2= =A0 and authenticates the user in the browser to authorize service signing=C2= =A0 is effectively single factor. One attack may be launched by an insider,=C2= =A0 or externally, against the web app, executing in the browser, gaining=C2=A0= coincident access to two secrets. Browser/desktop malware can accomplish=C2= =A0 the same. The difficulty is 1 in 2 vs. the expected 1 in 4.=C2=A0 >As more malware targets bitcoins I think the utility is evident.=C2=A0 >Given how final Bitcoin transactions are, I think it=3Fs worth trying to= =C2=A0 >find methods to help verify those transactions (if a user deems it to=C2= =A0 >be high-risk enough) before the transaction is completed. The balance=C2= =A0 >is trying to devise something that users do not find too burdensome.=C2=A0= I'm not questioning the motive, I agree it's worth trying. But trying is=C2= =A0 not succeeding. Increasing user (and/or system) complexity without=C2=A0 increasing integrity or privacy is a poor trade, and worse if the user=C2= =A0 is misled.=C2=A0 e=C2=A0 -------------- next part --------------=C2=A0 A non-text attachment was scrubbed...=C2=A0 Name: signature.asc=C2=A0 Type: application/pgp-signature=C2=A0 Size: 473 bytes=C2=A0 Desc: OpenPGP digital signature=C2=A0 ------------------------------=C2=A0 -------------------------------------------------------------------------= -----=C2=A0 Dive into the World of Parallel Programming. The Go Parallel Website,=C2=A0= sponsored by Intel and developed in partnership with Slashdot Media, is y= our=C2=A0 hub for all things parallel software development, from weekly thought=C2=A0= leadership blogs to news, videos, case studies, tutorials and more. Take = a=C2=A0 look and join the conversation now.=C2=A0http://goparallel.sourceforge.ne= t/=C2=A0 ------------------------------=C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=C2=A0 Bitcoin-development mailing list=C2=A0 Bitcoin-development=40lists.sourceforge.net=C2=A0 https://lists.sourceforge.net/lists/listinfo/bitcoin-development=C2=A0 End of Bitcoin-development Digest, Vol 45, Issue 11=C2=A0 ***************************************************=C2=A0 --54d0b945_3d1b58ba_7f23 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</= style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s= pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust= omfont=22 style=3D=22margin: 0px;=22><span style=3D=22color: rgb(0, 0, 0)= ; font-family: 'helvetica Neue', helvetica; font-size: 13px; line-height:= 19.5px;=22>An idea for the bitcoin malware proposal below, the idea is a= t the bottom</span><font face=3D=22helvetica Neue, helvetica=22><span sty= le=3D=22line-height: 19.5px;=22>=E2=80=A6</span></font></div><div id=3D=22= bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13= px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><span styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= <br></span></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22margin: 0p= x;=22><font face=3D=22helvetica Neue, helvetica=22><span style=3D=22line-= height: 19.5px;=22>Using a desktop website and mobile device for 2/3 mult= isig in lieu of a hardware device (trezor) and desktop website (mytrezor)= works, but the key is that the device used to input the two signatures&n= bsp;cannot be in the same band. What you are protecting against are= MITM attacks. The issue is that if a single device or network= is compromised by malware, or if a party is connecting to a counterparty= through a channel with compromised security, inputing 2 signatures throu= gh the same device/band defeats the purpose of 2/3 multisig. &n= bsp;This is the same as how MITM defeats 2=46A via mobile phone if the to= ken is entered into the same website as the password - the token is simpl= y passed through by the attacker to the secure session with the provider,= allowing unfettered access or reuse of tokens for transactions other tha= n those intended by the real user.</span></font></div><div id=3D=22bloop=5F= customfont=22 style=3D=22margin: 0px;=22><font face=3D=22helvetica Neue, = helvetica=22><span style=3D=22line-height: 19.5px;=22><br></span></font><= /div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22margin: 0px;=22><font = face=3D=22helvetica Neue, helvetica=22><span style=3D=22line-height: 19.5= px;=22>Companies have found clever ways around MITM attacks using SS= L sniff and derivatives by embedding code in mobile apps that communicate= not with the website authenticating the user, but with 3rd party company= that authenticates the token and passes the authentication to the websit= e through a different secure channel, making the MITM attack far much mor= e difficult. The trick here is that instead of one channel, we now = have two channels that must be compromised. Also, the second channe= l is between a security company and a (hopefully) professionally run = ;financial services website. There are other approaches to def= eat MITM, such as fingerprinting pages to detect spoofs. The former= (secure 3rd party channel) is very secure but requires a trusted third p= arty. The latter (fingerprinting) is a crap shoot with very high&nb= sp;false positive rates. </span></font></div><div id=3D=22bloop=5Fc= ustomfont=22 style=3D=22margin: 0px;=22><font face=3D=22helvetica Neue, h= elvetica=22><span style=3D=22line-height: 19.5px;=22><br></span></font></= div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22margin: 0px;=22><font f= ace=3D=22helvetica Neue, helvetica=22><span style=3D=22line-height: 19.5p= x;=22>Anyway, the exact same principles apply here to this conversation. = The second signature must be presented from a separate band to main= tain a higher degree of security. If one signature occurs via = HTTP(s) from application 1, another should be SMS through a carrier netwo= rk, etc via application 2.</span></font></div><div id=3D=22bloop=5Fcustom= font=22 style=3D=22margin: 0px;=22><font face=3D=22helvetica Neue, helvet= ica=22><span style=3D=22line-height: 19.5px;=22><br></span></font></div><= div id=3D=22bloop=5Fcustomfont=22 style=3D=22margin: 0px;=22><font face=3D= =22helvetica Neue, helvetica=22><span style=3D=22line-height: 19.5px;=22>= The trick we need to look at is how to use the bitcoin network as a deliv= ery mechanism to bypass the need for the trusted third party in the examp= le above. Instead of the second factor routing through a 3rd party = to the intended recipient, we have another option - one that doesn=E2=80=99= t require core development either.</span></font></div><div id=3D=22bloop=5F= customfont=22 style=3D=22margin: 0px;=22><font face=3D=22helvetica Neue, = helvetica=22><span style=3D=22line-height: 19.5px;=22><br></span></font><= /div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22margin: 0px;=22><font = face=3D=22helvetica Neue, helvetica=22><span style=3D=22line-height: 19.5= px;=22>1) Sender > signs signature 1 via desktop > bitcoin network = 2/3 P2SH</span></font></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22= margin: 0px;=22><font face=3D=22helvetica Neue, helvetica=22><span style=3D= =22line-height: 19.5px;=22>2) Mobile app also used by sender receives req= . from bitcoin network to sign signature - not through the site in 1 (sim= ilar to the 2nd channel between the website and security company above)</= span></font></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22margin: 0= px;=22><font face=3D=22helvetica Neue, helvetica=22><span style=3D=22line= -height: 19.5px;=22>3) Sender > signs signature 2 via mobile app (or a= ny separate device operating on a different network - heck could be = radio) > 2/3 signatures, transaction authorized</span></font= ></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22margin: 0px;=22><fon= t face=3D=22helvetica Neue, helvetica=22><span style=3D=22line-height: 19= .5px;=22><br></span></font></div><div id=3D=22bloop=5Fcustomfont=22 style= =3D=22margin: 0px;=22><font face=3D=22helvetica Neue, helvetica=22><span = style=3D=22line-height: 19.5px;=22>Any wallet service provider can use th= is model, all they must do is develop two independent applications&n= bsp;such a secure browser plugin and a website, or a mobile app and a web= site that use 2/3 multisig to authorize transactions. No core devel= opment required - just better security design and execution by those deve= loping wallets. If the protocol could natively communicate via two&= nbsp;separate networks, that might be something to consider, but rea= lly developers should already have all the tools they need, assuming= they are competent.</span></font></div><div id=3D=22bloop=5Fcustomfont=22= style=3D=22margin: 0px;=22><font face=3D=22helvetica Neue, helvetica=22>= <span style=3D=22line-height: 19.5px;=22><br></span></font></div><div id=3D= =22bloop=5Fcustomfont=22 style=3D=22margin: 0px;=22><font face=3D=22helve= tica Neue, helvetica=22><span style=3D=22line-height: 19.5px;=22>If there= was a way to perform 2/3 multisig without requiring a second band, perfo= rming the function safely by somehow knowing if the service is performed = from a compromised device through some sort of on-blockchain anti-malware= check by validating the signature of the signing application by com= paring it to a signature recorded when the multisig address was funded, &= nbsp;that would be a really neat breakthrough. =46ood for thought, = but I can=E2=80=99t see how that could be executed in a way where signatu= res couldn=E2=80=99t be spoofed from a compromised device. If someo= ne cracks that problem, it=E2=80=99s a really big advance for information= security.</span></font></div><div id=3D=22bloop=5Fcustomfont=22 style=3D= =22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); ma= rgin: 0px; line-height: auto;=22><span style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22><br></span></div><div id=3D=22= bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13= px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><span styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= On 02/02/2015 02:54 PM, Eric Voskuil wrote: </span><br style=3D=22fo= nt-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span sty= le=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >> </span><a href=3D=22http://airmail.calendar/2015-02-02%2011:53= :00%20MST=22 style=3D=22font-family: 'helvetica Neue', helvetica; line-he= ight: 19.5px;=22>On =46eb 2, 2015, at 11:53 AM</a><span style=3D=22font-f= amily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>, Mike Hearn = wrote: </span><br style=3D=22font-family: 'helvetica Neue', helvetic= a; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue'= , helvetica; line-height: 19.5px;=22>>> </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >>> In sending the first-signed transaction to another for second&n= bsp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22>>> signature, how does the first signe= r authenticate to the second </span><br style=3D=22font-family: 'hel= vetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fa= mily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>> witho= ut compromising the independence of the two factors=3F </span><br st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>>> </span><br style=3D=22font-family: 'helvetica Ne= ue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22>>> Not sure what = you mean. The idea is the second factor displays the </span><br styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= <span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22>>> transaction and the user confirms it matches what they= input to the </span><br style=3D=22font-family: 'helvetica Neue', h= elvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22>>> first factor. Ideall= y, using BIP70, but I don't know if BA actually </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >>> uses that currently. </span><br style=3D=22font-family: 'h= elvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-= family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>&nbs= p;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-he= ight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetic= a; line-height: 19.5px;=22>>> It's the same model as the TREZOR, ex= cept with a desktop app instead </span><br style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>> of= myTREZOR and a phone instead of a dedicated hardware device. </span= ><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19= .5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22>> </span><br style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family:= 'helvetica Neue', helvetica; line-height: 19.5px;=22>> Sorry for the = slow reply, traveling. </span><br style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: = 'helvetica Neue', helvetica; line-height: 19.5px;=22>> </span><br= style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px= ;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heig= ht: 19.5px;=22>> My comments were made in reference to this proposal:&= nbsp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helve= tica; line-height: 19.5px;=22>> </span><br style=3D=22font-family= : 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22f= ont-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>= > </span><a href=3D=22http://airmail.calendar/2015-02-02%2010:40:= 00%20MST=22 style=3D=22font-family: 'helvetica Neue', helvetica; line-hei= ght: 19.5px;=22>On =46eb 2, 2015, at 10:40 AM</a><span style=3D=22font-fa= mily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>, Brian Erdely= i <</span><a href=3D=22mailto:brian.erdelyi=40gmail.com=22 style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>brian.e= rdelyi=40gmail.com</a><span style=3D=22font-family: 'helvetica Neue', hel= vetica; line-height: 19.5px;=22> </span><br style=3D=22font-family: = 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22fon= t-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>&g= t; <</span><a href=3D=22mailto:brian.erdelyi=40gmail.com=22 style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>mailto:= brian.erdelyi=40gmail.com</a><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>>> wrote: </span><br st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>>>> </span><br style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family:= 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>> Anothe= r concept... </span><br style=3D=22font-family: 'helvetica Neue', he= lvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22>>>> </span><br s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>>>> It should be possible to use multisig wallets to = protect against </span><br style=3D=22font-family: 'helvetica Neue',= helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvet= ica Neue', helvetica; line-height: 19.5px;=22>>>> malware. =46or= example, a user could generate a wallet with 3 keys and </span><br = style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;= =22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22>>>> require a transaction that has been signed by = 2 of those keys. One </span><br style=3D=22font-family: 'helvetica N= eue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'h= elvetica Neue', helvetica; line-height: 19.5px;=22>>>> key is pl= aced in cold storage and anther sent to a third-party. </span><br st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>>>> </span><br style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family:= 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>> It is = now possible to generate and sign transactions on the users </span><= br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5= px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-he= ight: 19.5px;=22>>>> computer and send this signed transaction t= o the third-party for the </span><br style=3D=22font-family: 'helvet= ica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>> seco= nd signature. This now permits the use of out of band transaction </= span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height= : 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; l= ine-height: 19.5px;=22>>>> verification techniques before the th= ird party signs the transaction </span><br style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>>= ; and sends to the blockchain. </span><br style=3D=22font-family: 'h= elvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-= family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>>= </span><br style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helv= etica; line-height: 19.5px;=22>>>> If the third-party is malicio= us or becomes compromised they would not </span><br style=3D=22font-= family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>= >> have the ability to complete transactions as they only have one&= nbsp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helve= tica; line-height: 19.5px;=22>>>> private key. If the third-part= y disappeared, the user could use the </span><br style=3D=22font-fam= ily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>= ;> key in cold storage to sign transactions and send funds to a new wa= llet. </span><br style=3D=22font-family: 'helvetica Neue', helvetica= ; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue',= helvetica; line-height: 19.5px;=22>>>> </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>>>> Thoughts=3F </span><br style=3D=22font-family: 'h= elvetica Neue', helvetica; line-height: 19.5px;=22><br style=3D=22font-fa= mily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>My c= omments below start out with the presumption of user platform </span= ><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19= .5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22>compromise, but the same analysis holds for the case w= here the user </span><br style=3D=22font-family: 'helvetica Neue', h= elvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22>platform is clean but a web w= allet is compromised. Obviously the idea is </span><br style=3D=22fo= nt-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span sty= le=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >that either or both may be compromised, but integrity is retained as&nbs= p;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-he= ight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetic= a; line-height: 19.5px;=22>long as both are not compromised and in collus= ion. </span><br style=3D=22font-family: 'helvetica Neue', helvetica;= line-height: 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', he= lvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22>> In the multisig scenario = the presumption is of a user platform </span><br style=3D=22font-fam= ily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> co= mpromised by malware. It envisions a user signing a 2 of 3 output with&nb= sp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helveti= ca; line-height: 19.5px;=22>> a first signature. The precondition that= the platform is compromised </span><br style=3D=22font-family: 'hel= vetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fa= mily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> implies t= hat this process results in a loss of integrity of the private </spa= n><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22>> key, and as such if it were not for the second s= ignature requirement, </span><br style=3D=22font-family: 'helvetica = Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22>> the malware woul= d be able to spend the output. This may be extended to </span><br st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>> all of the keys in the wallet. </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >> </span><br style=3D=22font-family: 'helvetica Neue', helvetica= ; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue',= helvetica; line-height: 19.5px;=22>> The scenario envisions sending t= he signed transaction to an another </span><br style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> (=22= third=22) party. The objective is for the third party to provide the = ;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-hei= ght: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica= ; line-height: 19.5px;=22>> second signature, thereby spending the out= put as intended by the user, </span><br style=3D=22font-family: 'hel= vetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fa= mily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> who is no= t necessarily the first signer. The send must be authenticated </spa= n><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22>> to the user. Otherwise the third party would hav= e to sign anything it </span><br style=3D=22font-family: 'helvetica = Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22>> received, obviou= sly rendering the second signature pointless. This </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>> implies that the compromised platform must transmit a secret, = or proof </span><br style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>> of a secret, to the third par= ty. </span><br style=3D=22font-family: 'helvetica Neue', helvetica; = line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', h= elvetica; line-height: 19.5px;=22>> </span><br style=3D=22font-fa= mily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>= The problem is that the two secrets are not independent if the first&nbs= p;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-he= ight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetic= a; line-height: 19.5px;=22>> platform is compromised. So of course the= malware has the ability to </span><br style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fam= ily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> sign, impe= rsonate the user and send to the third party. So the third </span><b= r style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-hei= ght: 19.5px;=22>> party *must* send the transaction to an *independent= * platform for </span><br style=3D=22font-family: 'helvetica Neue', = helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helveti= ca Neue', helvetica; line-height: 19.5px;=22>> verification by the use= r, and obtain consent before adding the second </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >> signature. The user, upon receiving the transaction details, must b= e </span><br style=3D=22font-family: 'helvetica Neue', helvetica; li= ne-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', hel= vetica; line-height: 19.5px;=22>> able to verify, on the independent p= latform, that the details match </span><br style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> those = of the transaction that user presumably signed. Even for simple </sp= an><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22>> transactions this must include amount, address = and fees. </span><br style=3D=22font-family: 'helvetica Neue', helve= tica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Ne= ue', helvetica; line-height: 19.5px;=22>> </span><br style=3D=22f= ont-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >> The central assumptions are that, while the second user platform ma= y be </span><br style=3D=22font-family: 'helvetica Neue', helvetica;= line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', = helvetica; line-height: 19.5px;=22>> compromised, the attack against t= he second platform is not coordinated </span><br style=3D=22font-fam= ily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> wi= th that of the first, nor is the third party in collusion with the <= /span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; = line-height: 19.5px;=22>> first platform. </span><br style=3D=22f= ont-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >> </span><br style=3D=22font-family: 'helvetica Neue', helvetica= ; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue',= helvetica; line-height: 19.5px;=22>> Upon these assumptions rests the= actual security benefit (increased </span><br style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> di= fficulty of the coordinated attack). The strength of these assumptions&nb= sp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helveti= ca; line-height: 19.5px;=22>> is an interesting question, since it is = hard to quantify. But without </span><br style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-f= amily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> independ= ence the entire security model is destroyed and there is thus no </s= pan><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height:= 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; li= ne-height: 19.5px;=22>> protection whatsoever against malware. </= span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height= : 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; l= ine-height: 19.5px;=22>> </span><br style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fam= ily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> So for exa= mple a web-based or other third-party-provisioned </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>> implementation of the first platform breaks the anti-collusion= </span><br style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helv= etica; line-height: 19.5px;=22>> assumption. Also, weak comsec allows = an attack against the second </span><br style=3D=22font-family: 'hel= vetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fa= mily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> platform = to be carried out against its network. So for example a simple </spa= n><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22>> SMS-based confirmation could be executed by the = first platform alone and </span><br style=3D=22font-family: 'helveti= ca Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family= : 'helvetica Neue', helvetica; line-height: 19.5px;=22>> thereby also = break the the anti-collusion assumption. This is why I </span><br st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>> asked how independence is maintained. </span><br sty= le=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>> </span><br style=3D=22font-family: 'helvetica Neue',= helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvet= ica Neue', helvetica; line-height: 19.5px;=22>> The assumption of a ha= rdware wallet scenario is that the device itself </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>> is not compromised. So the scenario is not the same. If the us= er signs </span><br style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>> with a hardware wallet, nothi= ng can collude with that process, with one </span><br style=3D=22fon= t-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= > caveat. </span><br style=3D=22font-family: 'helvetica Neue', he= lvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22>> </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >> While a hardware wallet is not subject to onboard malware, it is no= t </span><br style=3D=22font-family: 'helvetica Neue', helvetica; li= ne-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', hel= vetica; line-height: 19.5px;=22>> inconceivable that its keys could be= extracted through probing or other </span><br style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> di= rect attack against the hardware. It's nevertheless an assumption of = ;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-hei= ght: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica= ; line-height: 19.5px;=22>> hardware wallets that these attacks requir= e loss of the hardware. </span><br style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family:= 'helvetica Neue', helvetica; line-height: 19.5px;=22>> Physical posse= ssion constitutes compromise. So the collusion model with </span><br= style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px= ;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heig= ht: 19.5px;=22>> a hardware wallet does exist, it just requires device= possession. </span><br style=3D=22font-family: 'helvetica Neue', he= lvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22>> Depending on the implemen= tation the extraction may require a non-trivial </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >> amount of time and money. </span><br style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> <= /span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; = line-height: 19.5px;=22>> In a scenario where the user signs with HW, = then sends the transaction </span><br style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fami= ly: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> to a third = party for a second of three signatures, and finally to a </span><br = style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;= =22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22>> second platform for user verification, a HW thief need= s to collude with </span><br style=3D=22font-family: 'helvetica Neue= ', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22>> the third party or t= he second platform before the owner becomes aware of </span><br styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= <span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22>> the theft (notifying the third party). This of course impl= ies that </span><br style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>> keeping both the fist and sec= ond platforms in close proximity </span><br style=3D=22font-family: = 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22fon= t-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> const= itutes collusion from a physical security standpoint. This is </span= ><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19= .5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22>> probably sufficient justification for not impleme= nting such a model, </span><br style=3D=22font-family: 'helvetica Ne= ue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22>> especially given t= he cost and complexity of stealing and cracking a </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>> well-designed device. A device backup would provide comparable= time to </span><br style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>> recover with far less complex= ity (and loss of privacy). </span><br style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fami= ly: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> </span= ><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19= .5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22>> Incidentally the hardware wallet idea breaks down= once any aspect of the </span><br style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family:= 'helvetica Neue', helvetica; line-height: 19.5px;=22>> platform or ne= twork to which it connects must be trusted, so for these </span><br = style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;= =22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22>> purposes I do not consider certain hybrid models as ha= rdware wallets at </span><br style=3D=22font-family: 'helvetica Neue= ', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22>> all. =46or example o= ne such device trusts that the compromised computer </span><br style= =3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><= span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19= .5px;=22>> does not carry out a MITM attack between the signing device= and a shared </span><br style=3D=22font-family: 'helvetica Neue', h= elvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22>> secret entered in parts = over time by the user. This reduces to a single </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >> factor with no protection against a compromised platform. </sp= an><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22>> </span><br style=3D=22font-family: 'helvet= ica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> Of course th= ese questions address integrity, not privacy. Use of a third </span>= <br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.= 5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22>> party implies loss of privacy to that party, and w= ith weak comsec to the </span><br style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: = 'helvetica Neue', helvetica; line-height: 19.5px;=22>> network. Simila= rly, use of hardware signing devices implies loss of </span><br styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= <span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22>> privacy to the compromised platforms with which they excha= nge transactions. </span><br style=3D=22font-family: 'helvetica Neue= ', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22>> </span><br styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= <span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22>> e </span><br style=3D=22font-family: 'helvetica Neue'= , helvetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helveti= ca Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family= : 'helvetica Neue', helvetica; line-height: 19.5px;=22>-------------- nex= t part -------------- </span><br style=3D=22font-family: 'helvetica = Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22>A non-text attachment= was scrubbed... </span><br style=3D=22font-family: 'helvetica Neue'= , helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22>Name: signature.asc <= /span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; = line-height: 19.5px;=22>Type: application/pgp-signature </span><br s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>Size: 473 bytes </span><br style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fami= ly: 'helvetica Neue', helvetica; line-height: 19.5px;=22>Desc: OpenPGP di= gital signature </span><br style=3D=22font-family: 'helvetica Neue',= helvetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family:= 'helvetica Neue', helvetica; line-height: 19.5px;=22>-------------------= ----------- </span><br style=3D=22font-family: 'helvetica Neue', hel= vetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helvetica Ne= ue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22>Message: 3 </span>= <br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.= 5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22>Date: </span><a href=3D=22http://airmail.calendar/= 2015-02-02%2012:00:00%20MST=22 style=3D=22font-family: 'helvetica Neue', = helvetica; line-height: 19.5px;=22>Mon, 2 =46eb 2015</a><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22> <= /span><a href=3D=22http://airmail.calendar/2015-02-03%2017:44:37%20MST=22= style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px= ;=22>16:44:37 -0800</a><span style=3D=22font-family: 'helvetica Neue', he= lvetica; line-height: 19.5px;=22> </span><br style=3D=22font-family:= 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22fo= nt-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>=46rom: P= ieter Wuille <</span><a href=3D=22mailto:pieter.wuille=40gmail.com=22 = style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;= =22>pieter.wuille=40gmail.com</a><span style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22>> </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >Subject: Re: =5BBitcoin-development=5D =5Bsoftfork proposal=5D Strict DE= R </span><br style=3D=22font-family: 'helvetica Neue', helvetica; li= ne-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', hel= vetica; line-height: 19.5px;=22>signatures </span><br style=3D=22fon= t-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= To: Gregory Maxwell <</span><a href=3D=22mailto:gmaxwell=40gmail.com=22= style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px= ;=22>gmaxwell=40gmail.com</a><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>> </span><br style=3D=22fo= nt-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span sty= le=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >Cc: Bitcoin Dev <</span><a href=3D=22mailto:bitcoin-development=40lis= ts.sourceforge.net=22 style=3D=22font-family: 'helvetica Neue', helvetica= ; line-height: 19.5px;=22>bitcoin-development=40lists.sourceforge.net</a>= <span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22>> </span><br style=3D=22font-family: 'helvetica Neue', = helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helveti= ca Neue', helvetica; line-height: 19.5px;=22>Message-ID: </span><br = style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;= =22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22><</span><a href=3D=22mailto:CAPg+sBjjYLf4NZ8ezK7ML=5FOO-= e6C8=5FV1i12AXejjrgp+w=46B-pg=40mail.gmail.com=22 style=3D=22font-family:= 'helvetica Neue', helvetica; line-height: 19.5px;=22>CAPg+sBjjYLf4NZ8ezK= 7ML=5FOO-e6C8=5FV1i12AXejjrgp+w=46B-pg=40mail.gmail.com</a><span style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>= </span><br style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helv= etica; line-height: 19.5px;=22>Content-Type: text/plain; charset=3DISO-88= 59-1 </span><br style=3D=22font-family: 'helvetica Neue', helvetica;= line-height: 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', he= lvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22>On Sun, Jan 25, 2015 at 6:48 A= M, Gregory Maxwell <</span><a href=3D=22mailto:gmaxwell=40gmail.com=22= style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px= ;=22>gmaxwell=40gmail.com</a><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>> wrote: </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>> So I think we should just go ahead with R/S length upper bound= s as </span><br style=3D=22font-family: 'helvetica Neue', helvetica;= line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', = helvetica; line-height: 19.5px;=22>> both IsStandard and in STRICTDER.= </span><br style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>I would like to fix this at some p= oint in any case. </span><br style=3D=22font-family: 'helvetica Neue= ', helvetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helvet= ica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22>If we want to do = that, we must at least have signatures with too-long </span><br styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= <span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22>R or S values as non-standard. </span><br style=3D=22font-= family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>One way to do that is to just - right now - add a patch to 0.10 to&= nbsp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helve= tica; line-height: 19.5px;=22>make those non-standard. This requires anot= her validation flag, with a </span><br style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fam= ily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>bunch of switch= ing logic. </span><br style=3D=22font-family: 'helvetica Neue', helv= etica; line-height: 19.5px;=22><br style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'hel= vetica Neue', helvetica; line-height: 19.5px;=22>The much simpler alterna= tive is just adding this to BIP66's DERSIG </span><br style=3D=22fon= t-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= right now, which is a one-line change that's obviously softforking. Is&nb= sp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helveti= ca; line-height: 19.5px;=22>anyone opposed to doing so at this stage=3F&n= bsp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', helvetic= a; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue'= , helvetica; line-height: 19.5px;=22>-- </span><br style=3D=22font-f= amily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>Piet= er </span><br style=3D=22font-family: 'helvetica Neue', helvetica; l= ine-height: 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', helv= etica; line-height: 19.5px;=22><br style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fami= ly: 'helvetica Neue', helvetica; line-height: 19.5px;=22>----------------= -------------- </span><br style=3D=22font-family: 'helvetica Neue', = helvetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: = 'helvetica Neue', helvetica; line-height: 19.5px;=22>Message: 4 </sp= an><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22>Date: Tue, </span><a href=3D=22http://airmail.c= alendar/2015-02-02%2019:21:24%20MST=22 style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22>3 =46eb 2015 02:21:24 +0000</a= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22> </span><br style=3D=22font-family: 'helvetica Neue', hel= vetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica = Neue', helvetica; line-height: 19.5px;=22>=46rom: Gregory Maxwell <</s= pan><a href=3D=22mailto:gmaxwell=40gmail.com=22 style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22>gmaxwell=40gmail.com<= /a><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height= : 19.5px;=22>> </span><br style=3D=22font-family: 'helvetica Neue= ', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22>Subject: Re: =5BBitcoin-d= evelopment=5D =5Bsoftfork proposal=5D Strict DER </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>signatures </span><br style=3D=22font-family: 'helvetica Neue'= , helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22>To: Pieter Wuille <</sp= an><a href=3D=22mailto:pieter.wuille=40gmail.com=22 style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22>pieter.wuille=40g= mail.com</a><span style=3D=22font-family: 'helvetica Neue', helvetica; li= ne-height: 19.5px;=22>> </span><br style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fami= ly: 'helvetica Neue', helvetica; line-height: 19.5px;=22>Cc: Bitcoin Dev = <</span><a href=3D=22mailto:bitcoin-development=40lists.sourceforge.ne= t=22 style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19= .5px;=22>bitcoin-development=40lists.sourceforge.net</a><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>&nb= sp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helveti= ca; line-height: 19.5px;=22>Message-ID: </span><br style=3D=22font-f= amily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><= </span><a href=3D=22mailto:CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhs=46JoY=3D2j76Ar= XnBRsiV6g=40mail.gmail.com=22 style=3D=22font-family: 'helvetica Neue', h= elvetica; line-height: 19.5px;=22>CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhs=46JoY=3D= 2j76ArXnBRsiV6g=40mail.gmail.com</a><span style=3D=22font-family: 'helvet= ica Neue', helvetica; line-height: 19.5px;=22>> </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>Content-Type: text/plain; charset=3DUT=46-8 </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><br = style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;= =22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22>On Tue, =46eb 3, 2015 at 12:44 AM, Pieter Wuille <</span= ><a href=3D=22mailto:pieter.wuille=40gmail.com=22 style=3D=22font-family:= 'helvetica Neue', helvetica; line-height: 19.5px;=22>pieter.wuille=40gma= il.com</a><span style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22>> wrote: </span><br style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> The mu= ch simpler alternative is just adding this to BIP66's DERSIG </span>= <br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.= 5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22>> right now, which is a one-line change that's obvio= usly softforking. Is </span><br style=3D=22font-family: 'helvetica N= eue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'h= elvetica Neue', helvetica; line-height: 19.5px;=22>> anyone opposed to= doing so at this stage=3F </span><br style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22><br style=3D=22font-family= : 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22f= ont-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>Thats my= preference. </span><br style=3D=22font-family: 'helvetica Neue', he= lvetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helvetica N= eue', helvetica; line-height: 19.5px;=22><br style=3D=22font-family: 'hel= vetica Neue', helvetica; line-height: 19.5px;=22><br style=3D=22font-fami= ly: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>-------= ----------------------- </span><br style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22><br style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>Message: 5&= nbsp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helve= tica; line-height: 19.5px;=22>Date: </span><a href=3D=22http://airma= il.calendar/2015-02-02%2012:00:00%20MST=22 style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22>Mon, 02 =46eb 2015</a><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22> </span><a href=3D=22http://airmail.calendar/2015-02-04%2000:3= 8:07%20MST=22 style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22>23:38:07 -0800</a><span style=3D=22font-family: 'helvet= ica Neue', helvetica; line-height: 19.5px;=22> </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >=46rom: Eric Voskuil <</span><a href=3D=22mailto:eric=40voskuil.org=22= style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px= ;=22>eric=40voskuil.org</a><span style=3D=22font-family: 'helvetica Neue'= , helvetica; line-height: 19.5px;=22>> </span><br style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style= =3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>S= ubject: Re: =5BBitcoin-development=5D Proposal to address Bitcoin malware= </span><br style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helv= etica; line-height: 19.5px;=22>To: Brian Erdelyi <</span><a href=3D=22= mailto:brian.erdelyi=40gmail.com=22 style=3D=22font-family: 'helvetica Ne= ue', helvetica; line-height: 19.5px;=22>brian.erdelyi=40gmail.com</a><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>> </span><br style=3D=22font-family: 'helvetica Neue', helv= etica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica N= eue', helvetica; line-height: 19.5px;=22>Cc: Bitcoin Dev <</span><a hr= ef=3D=22mailto:bitcoin-development=40lists.sourceforge.net=22 style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>bitcoin= -development=40lists.sourceforge.net</a><span style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22>> </span><br st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>Message-ID: <</span><a href=3D=22mailto:54D07AD=46.8060809=40= voskuil.org=22 style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22>54D07AD=46.8060809=40voskuil.org</a><span style=3D=22f= ont-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>&nbs= p;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-he= ight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetic= a; line-height: 19.5px;=22>Content-Type: text/plain; charset=3D=22utf-8=22= </span><br style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>On 02/02/2015 11:58 AM, Brian Erde= lyi wrote:> </span><br style=3D=22font-family: 'helvetica Neue', = helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helveti= ca Neue', helvetica; line-height: 19.5px;=22>>>Confusing or not, th= e reliance on multiple signatures as offering </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >>>greater security than single relies on the independence of multi= ple </span><br style=3D=22font-family: 'helvetica Neue', helvetica; = line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', h= elvetica; line-height: 19.5px;=22>>secrets. If the secrets cannot be s= hown to retain independence in the </span><br style=3D=22font-family= : 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22f= ont-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>= envisioned threat scenario (e.g. a user's compromised operating </sp= an><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22>>>system) then the benefit reduces to making t= he exploit more difficult </span><br style=3D=22font-family: 'helvet= ica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>>to write,= which, once written, reduces to no benefit. Yet the user </span><br= style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px= ;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heig= ht: 19.5px;=22>>>still suffers the reduced utility arising from gre= ater complexity, </span><br style=3D=22font-family: 'helvetica Neue'= , helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22>>>while being led to= believe in a false promise. </span><br style=3D=22font-family: 'hel= vetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fa= mily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>> </sp= an><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22>>Just trying to make sure I understand what you=3F= re saying. Are you </span><br style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'hel= vetica Neue', helvetica; line-height: 19.5px;=22>>eluding to that if t= wo of the three private keys get compromised there </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>>is no gain in security=3F Although the likelihood of this occur= ring is </span><br style=3D=22font-family: 'helvetica Neue', helveti= ca; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue= ', helvetica; line-height: 19.5px;=22>>lower, it is possible. </s= pan><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height:= 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helve= tica; line-height: 19.5px;=22>No, that's not it. Sorry for not being clea= r. Independence of control is </span><br style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-f= amily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>the central i= ssue in the analysis of a multiple factor system. If an </span><br s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>attack compromises one factor there must be no way for that at= tack to </span><br style=3D=22font-family: 'helvetica Neue', helveti= ca; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue= ', helvetica; line-height: 19.5px;=22>reduce the difficulty of obtaining = the other factors. </span><br style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helve= tica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-fami= ly: 'helvetica Neue', helvetica; line-height: 19.5px;=22>Some factors (se= crets), like a fingerprint, aren't very secret at all. </span><br st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>But getting someone's fingerprint doesn't also help the attack= er get a </span><br style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>PIN. That factor must be attacked = independently. But if the PIN is </span><br style=3D=22font-family: = 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22fon= t-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>encrypted = with the fingerprint in a public store, then the PIN is not </span><= br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5= px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-he= ight: 19.5px;=22>independent of the fingerprint and there is really only = one secret. </span><br style=3D=22font-family: 'helvetica Neue', hel= vetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helvetica Ne= ue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22>If multiple factors are= coincident (located within the same security </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >perimeter) they are compromized coincidentally. Coincidence has the same= </span><br style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helv= etica; line-height: 19.5px;=22>effect as dependence. Consider a credit ca= rd with a =22security code=22 </span><br style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-f= amily: 'helvetica Neue', helvetica; line-height: 19.5px;=22>printed on th= e back. A successful attack on the leather wallet yields </span><br = style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;= =22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22>both secrets. </span><br style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22><br style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>Individ= ual environments can be compromised with some difficulty (e.g. </spa= n><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22>desktop malware, fingerprint lift, dictionary attack,= brute force PIN, </span><br style=3D=22font-family: 'helvetica Neue= ', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22>etc.). =46or the sake of = simplicity, let that chance of successful </span><br style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style= =3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>i= ndependent attack on any factor be 1 in 2 and the resulting probability&n= bsp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22>of successful concurrent attack on any n fac= tors be 1 in 2=5En. If m </span><br style=3D=22font-family: 'helveti= ca Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family= : 'helvetica Neue', helvetica; line-height: 19.5px;=22>factors are depend= ent/coincident on others the relation becomes 1 in </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>2=5E(n-m). </span><br style=3D=22font-family: 'helvetica Neue'= , helvetica; line-height: 19.5px;=22><br style=3D=22font-family: 'helveti= ca Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family= : 'helvetica Neue', helvetica; line-height: 19.5px;=22>Any multi-factor w= eb wallet that handles the user's keys in the browser </span><br sty= le=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= ><span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22>and authenticates the user in the browser to authorize service= signing </span><br style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neu= e', helvetica; line-height: 19.5px;=22>is effectively single factor. One = attack may be launched by an insider, </span><br style=3D=22font-fam= ily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>or exte= rnally, against the web app, executing in the browser, gaining </spa= n><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line= -height: 19.5px;=22>coincident access to two secrets. Browser/desktop mal= ware can accomplish </span><br style=3D=22font-family: 'helvetica Ne= ue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22>the same. The difficult= y is 1 in 2 vs. the expected 1 in 4. </span><br style=3D=22font-fami= ly: 'helvetica Neue', helvetica; line-height: 19.5px;=22><br style=3D=22f= ont-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >>As more malware targets bitcoins I think the utility is evident.&nbs= p;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-he= ight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetic= a; line-height: 19.5px;=22>>Given how final Bitcoin transactions are, = I think it=3Fs worth trying to </span><br style=3D=22font-family: 'h= elvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-= family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>>find met= hods to help verify those transactions (if a user deems it to </span= ><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19= .5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22>>be high-risk enough) before the transaction is com= pleted. The balance </span><br style=3D=22font-family: 'helvetica Ne= ue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'he= lvetica Neue', helvetica; line-height: 19.5px;=22>>is trying to devise= something that users do not find too burdensome. </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><br = style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;= =22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-heigh= t: 19.5px;=22>I'm not questioning the motive, I agree it's worth trying. = But trying is </span><br style=3D=22font-family: 'helvetica Neue', h= elvetica; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetic= a Neue', helvetica; line-height: 19.5px;=22>not succeeding. Increasing us= er (and/or system) complexity without </span><br style=3D=22font-fam= ily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>increas= ing integrity or privacy is a poor trade, and worse if the user </sp= an><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; lin= e-height: 19.5px;=22>is misled. </span><br style=3D=22font-family: '= helvetica Neue', helvetica; line-height: 19.5px;=22><br style=3D=22font-f= amily: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>e&nb= sp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', helvetica= ; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue',= helvetica; line-height: 19.5px;=22>-------------- next part ------------= -- </span><br style=3D=22font-family: 'helvetica Neue', helvetica; l= ine-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', he= lvetica; line-height: 19.5px;=22>A non-text attachment was scrubbed...&nb= sp;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-h= eight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helveti= ca; line-height: 19.5px;=22>Name: signature.asc </span><br style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span s= tyle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >Type: application/pgp-signature </span><br style=3D=22font-family: = 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22fon= t-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>Size: 473 = bytes </span><br style=3D=22font-family: 'helvetica Neue', helvetica= ; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue',= helvetica; line-height: 19.5px;=22>Desc: OpenPGP digital signature = </span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-heig= ht: 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', helvetica; l= ine-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', he= lvetica; line-height: 19.5px;=22>------------------------------ </sp= an><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: = 19.5px;=22><br style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvet= ica; line-height: 19.5px;=22>--------------------------------------------= ---------------------------------- </span><br style=3D=22font-family= : 'helvetica Neue', helvetica; line-height: 19.5px;=22><span style=3D=22f= ont-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>Dive int= o the World of Parallel Programming. The Go Parallel Website, </span= ><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19= .5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetica; line-= height: 19.5px;=22>sponsored by Intel and developed in partnership with S= lashdot Media, is your </span><br style=3D=22font-family: 'helvetica= Neue', helvetica; line-height: 19.5px;=22><span style=3D=22font-family: = 'helvetica Neue', helvetica; line-height: 19.5px;=22>hub for all things p= arallel software development, from weekly thought </span><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>leadership blogs to news, videos, case studies, tutorials and more.= Take a </span><br style=3D=22font-family: 'helvetica Neue', helveti= ca; line-height: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue= ', helvetica; line-height: 19.5px;=22>look and join the conversation now.= </span><a href=3D=22http://goparallel.sourceforge.net/=22 style=3D=22= font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>http://= goparallel.sourceforge.net/</a><span style=3D=22font-family: 'helvetica N= eue', helvetica; line-height: 19.5px;=22> </span><br style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><br style=3D= =22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><spa= n style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5p= x;=22>------------------------------ </span><br style=3D=22font-fami= ly: 'helvetica Neue', helvetica; line-height: 19.5px;=22><br style=3D=22f= ont-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span st= yle=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F&nbs= p;</span><br style=3D=22font-family: 'helvetica Neue', helvetica; line-he= ight: 19.5px;=22><span style=3D=22font-family: 'helvetica Neue', helvetic= a; line-height: 19.5px;=22>Bitcoin-development mailing list </span><= br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5= px;=22><a href=3D=22mailto:Bitcoin-development=40lists.sourceforge.net=22= style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px= ;=22>Bitcoin-development=40lists.sourceforge.net</a><span style=3D=22font= -family: 'helvetica Neue', helvetica; line-height: 19.5px;=22> </spa= n><br style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22><a href=3D=22https://lists.sourceforge.net/lists/listinfo/bitco= in-development=22 style=3D=22font-family: 'helvetica Neue', helvetica; li= ne-height: 19.5px;=22>https://lists.sourceforge.net/lists/listinfo/bitcoi= n-development</a><span style=3D=22font-family: 'helvetica Neue', helvetic= a; line-height: 19.5px;=22> </span><br style=3D=22font-family: 'helv= etica Neue', helvetica; line-height: 19.5px;=22><br style=3D=22font-famil= y: 'helvetica Neue', helvetica; line-height: 19.5px;=22><br style=3D=22fo= nt-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22><span sty= le=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22= >End of Bitcoin-development Digest, Vol 45, Issue 11 </span><br styl= e=3D=22font-family: 'helvetica Neue', helvetica; line-height: 19.5px;=22>= <span style=3D=22font-family: 'helvetica Neue', helvetica; line-height: 1= 9.5px;=22>*************************************************** </span= ></div><div class=3D=22bloop=5Fcontainer=22><div class=3D=22bloop=5Fframe= =22> </div></div><br><div id=3D=22bloop=5Fsign=5F1422962228822888960=22 = class=3D=22bloop=5Fsign=22><br></div></body></html> --54d0b945_3d1b58ba_7f23--