Topic: Can we talk about removing SSL from the payment protocol and put PGP? (Read 2455 times)

Well think about if it costed $10 for someone to put an PGP key into the DHT then that would probably solve the problem of them registering a fake one.

Ha!

That can easily be solved with a proof of burn or some soft of proof of stake.

No.  You give Mallory your email address, she gives the server her address.  The server encrypts the message with Mallory's key, she decrypts it, changes is, signs it with her key, then encrypts it with your key.  You then place the order with Mallory, and send the payment to her bitcoin address.

The server doesn't know how to distinguish your key from Mallory's key, and you don't know how to distinguish Mallory's key from the server's key, because that is the problem we are trying to solve.

So lets explore this, I give them a fake email that is in the key server, I get a PGP message, that I can't decrypt and if I can decrypt it I can changed anything cause it is signed. So what is the attack?

How do they know the email address they are looking up is mine?

How would they look up an attacker's key if you have it in a decentralized environment? If they use your email they would get yours, if your private key is compromised then an attacker could read it, but can't sign on behalf of the store.

Ok, so the merchant's store software looks up the attacker's key and encrypts the store's key so that only the attacker has access to it.  The attacker then decrypts it, and re-encrypts it using your actual key, then signs it using their key, which you think is the store's key.  Got it. 

Just kidding.  What will really happen is that the attacker will look up your pubkey, encrypt their key with your key.  Since you have no way to authenticate the store's key, you'll have no idea that it was swapped around.


Keep in mind that the problem we are trying to solve is how I authenticate a key that I've never seen before.  You can't solve that problem with another unauthenticated key.

I don't agree with the man much but gmaxwell is correct with this.


Centralization shouldn't always be the answer, privacy much more important.

https://bitcointalk.org/index.php?topic=421608.0;all

Sadly this is true. He also hasn't done much in the way of smart fees which I think should be a high priority but I guess still having that under his control is the main focus.

I use client side certificates in my peer to peer research. I set up my own X.509 certificate server that creates certificates for one-time download to the client. I like SSL/TLS, but use it what I believe is a more secure fashion than just having a certificate on the server. Futhermore, SSL/TLS allows negotiation of the encryption protocol, which can be quite strong.

... and has lovely, juicy big back-doors.

I see Gavin has moved on now that "the job" has been done.

Exactly. It works great when you're communicating with people you know IRL. But the trust is difficult to establish with unknowns, you have no idea how good their bespoke key security hygiene is. Standardise or get a better convention to replace the bespoke part, and then you can actually have more confidence in unknown links on the trust network. Then the spread of the network will strengthen, and not weaken, the trust in those you can't verify easily.

One way PKI could be improved is to optionally allow or even require multiple CA signatures so that the identities are verified by multiple third parties, so that way you don't have to put trust in one single point of failure. Of-course there is still the problem of the private keys being compromised for whom you wish to deal with. PGP keys can be compromised also. The only way WoT can practically work is by involving a sort of CA system where you would have global trusted parties, so you can be guaranteed of obtaining trust from people, like you already do by obtaining a widely supported certificate from a CA. Why not use the existing PKI for that?

It makes sense to me to outsource the role of identity verification to certificate authorities.

There. I see it. What you did.

Namecoin can be used, I am just saying DHT because I think that would be the smallest and can easily be used along side bitcoind. But I mean this can implemented many ways in many different decentralized format.

Can't Namecoin potentially solve much or most of this problem?

There's a very good case to be made for using a hashed blockchain database to store this kind of WoT information.

I've heard it said before that CA's are a problem because they're: 1) expensive to run 2) not infallible despite this expense 3) corruptible or subject to coercion anyway. Storing the certificates in a blockchain would mitigate alot of this, but creating a system with effective incentives to deliver the service is not easy. Namecoin is the closest candidate for that now, but I'm not convinced the model of mixing a currency and a data service (and narrowed to DNS resolution only) really works.

PGP WoT also has a significant problem: protecting your keys becomes increasingly more important as you become more reliant on the system. The more frequently you get put in a position where you have to revoke a PGP public key, the more uncertainty others might have about how much they can trust (your most recent) key. Has anyone seen the number of Gavin Andressen PGP keys there are on the MIT listings? It doesn't confer much confidence to someone unfamiliar with PGP. And of course, dealing with the leak of a private key is a total disaster.

Having an inexpensive & well designed hardware module would be a great starting point here. Decentralised model would be stronger in principle, but needs stronger infrastructure in place to make assurance of key integrity at least scale linearly with the number of people who have a need to trust public keys and certs. At present, PGP WoT works best between a small number of people, that needs to change to make it viable for identifying bitcoin payees. Having an endless list of revoked keys that users have to navigate piecemeal is not indicative of a mature infrastructure.

So bitcoinstore's servers will look up a pgp key for you, which I am guessing since you supplied them an email would be easy in the key server. They take that public key and use it to encrypt the address, which they also signed. Your client takes this decrypts it and checks the signature, if it is good it displays a green box just like the current payment protocol.

Lets say you don't want your email hashed in the DHT. Then the bitcoind would have it's own public key which then can be sent to bitcoin store, and this would only allow a one way verification by the user and not by the site. These would be less trustworthy than the above but would still work.