On 02/02/2015 11:58 AM, Brian Erdelyi wrote:> >>Confusing or not, the reliance on multiple signatures as offering >>greater security than single relies on the independence of multiple >secrets. If the secrets cannot be shown to retain independence in the >>envisioned threat scenario (e.g. a user's compromised operating >>system) then the benefit reduces to making the exploit more difficult >>to write, which, once written, reduces to no benefit. Yet the user >>still suffers the reduced utility arising from greater complexity, >>while being led to believe in a false promise. > >Just trying to make sure I understand what you’re saying. Are you >eluding to that if two of the three private keys get compromised there >is no gain in security? Although the likelihood of this occurring is >lower, it is possible.
No, that's not it. Sorry for not being clear. Independence of control is the central issue in the analysis of a multiple factor system. If an attack compromises one factor there must be no way for that attack to reduce the difficulty of obtaining the other factors. Some factors (secrets), like a fingerprint, aren't very secret at all. But getting someone's fingerprint doesn't also help the attacker get a PIN. That factor must be attacked independently. But if the PIN is encrypted with the fingerprint in a public store, then the PIN is not independent of the fingerprint and there is really only one secret. If multiple factors are coincident (located within the same security perimeter) they are compromized coincidentally. Coincidence has the same effect as dependence. Consider a credit card with a "security code" printed on the back. A successful attack on the leather wallet yields both secrets. Individual environments can be compromised with some difficulty (e.g. desktop malware, fingerprint lift, dictionary attack, brute force PIN, etc.). For the sake of simplicity, let that chance of successful independent attack on any factor be 1 in 2 and the resulting probability of successful concurrent attack on any n factors be 1 in 2^n. If m factors are dependent/coincident on others the relation becomes 1 in 2^(n-m). Any multi-factor web wallet that handles the user's keys in the browser and authenticates the user in the browser to authorize service signing is effectively single factor. One attack may be launched by an insider, or externally, against the web app, executing in the browser, gaining coincident access to two secrets. Browser/desktop malware can accomplish the same. The difficulty is 1 in 2 vs. the expected 1 in 4. >As more malware targets bitcoins I think the utility is evident. >Given how final Bitcoin transactions are, I think it’s worth trying to >find methods to help verify those transactions (if a user deems it to >be high-risk enough) before the transaction is completed. The balance >is trying to devise something that users do not find too burdensome. I'm not questioning the motive, I agree it's worth trying. But trying is not succeeding. Increasing user (and/or system) complexity without increasing integrity or privacy is a poor trade, and worse if the user is misled. e
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
