Bitcoin Forum
May 04, 2024, 10:48:50 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16]  All
  Print  
Author Topic: Invoices/Payments/Receipts proposal discussion  (Read 24652 times)
phillipsjk
Legendary
*
Offline Offline

Activity: 1008
Merit: 1001

Let the chips fall where they may.


View Profile WWW
November 16, 2013, 06:58:49 AM
 #301

I skimmed the whole tread.

Mike Hearn's FAQ helped explain the reasoning behind this: PKI is hard apparently.

I think the hostility to this stems from the fact that the CA system is known to be broken. An attacker will not try to change the "common name"; they will change the payment address: the very thing being hidden by this proposal.

With money on the line, attackers may even be well-funded, purchasing one of those corporate CA spoofing appliances in order to go after a high-value target.

I was also wondering why it was stated as fact that self-signed certificates allow the MITM attack. Later in the thread, somebody even pointed out that CAs themselves use self-signed certificates. The difficulty, hinted at in this link is that X.509 certificates do not allow the end-user to trust a specific CA for a specific domain. All CAs can sign for all domains: which makes me trying to be my own CA for *.economicprisoner.com a very bad idea.

In my experimentation with OpenPGP, I noticed that most people have shockingly lax certificate verification practices. They are confused when you ask for their public key: when you can simply search for their e-mail address or their short-key is included in their mail signature. They don't realize that it is trivial to generate collisions with both of those identifiers. There has essentially been a gentleman's agreement to not do that as far as I can tell. This tells me that even if a "bricks and mortar" business had the fingerprint of their self-signed cert prominently displayed: nobody would actually check it.

PS: To the people hung up on SSL: You can have Certs without using SSL.

TL;DR: I still don't like it, but don't really have a better suggestion at the moment. Namecoin would not work since the first person to grab a specific .bit domain can not be forced to surrender it in the event of a trademark dispute (unless you can get the holder in court somehow).


James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
In order to achieve higher forum ranks, you need both activity points and merit points.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3071



View Profile
November 16, 2013, 08:29:24 PM
 #302

I was seeking clarification for this, and the reality is that this is no greater a danger to your privacy when paying than what everyone does today, and it increases the needed attack sophistication to replace a genuine merchant payment address with the address of an attacker.

The danger of any MITM attack with the Payments Protocol is not any privacy leak, but someone using a faked or stolen certificate in combination with further attack code infecting the webmerchant itself, all coming together to allow the attacker to supply their own address for the user to pay, instead of the address belonging to the webmerchant. The Payment Protocol could be tricked into validating the authenticity of the faked/stolen Certificate, and in turn incorrectly verifying the address as being one supplied by the webmerchant. Payment Protocol can't solve this problem, it's an issue with the inherent design of the CA system. But pulling it off successfully is more difficult to engineer than attacking the webmerchant payment methods being used today, hence the barrier to hijacking payments through html web pages are higher with Payments Protocol.

Personal information (like your real name, postal address and the Bitcoin address you pay from) is now and will continue to be transmitted to the merchant over plain old html, or using SSL encrypted htmls sessions if they're using currently considered best practice. What level of security the webmerchant uses to store this information on their servers is another factor. These things have nothing to do with Payment Protocol, it's between you and them: your browser and OS, their webstore software and webserver configuration.

Vires in numeris
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1009



View Profile
January 09, 2014, 07:31:25 AM
 #303

A discussion of why the payment protocol should default to using BIP32 extended public keys instead of individual addresses, and a debunking of several common objections:

http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1150


View Profile
January 09, 2014, 11:36:36 AM
 #304

A discussion of why the payment protocol should default to using BIP32 extended public keys instead of individual addresses, and a debunking of several common objections:

http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html

Or if you want to be able to reveal the address publicly without sacrificing privacy: Stealth Addresses

Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1129


View Profile
January 10, 2014, 03:09:54 PM
 #305

A discussion of why the payment protocol should default to using BIP32 extended public keys instead of individual addresses, and a debunking of several common objections:

http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html

Good article, thanks for writing it.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!