Bitcoin Forum

I think PGP would be better than SSL, plus all can be keyservers or a DHT keyserver. It really wouldn't be too hard to add this. I think we need to reopen this discussion. Remember the payment protocol doesn't hinder users because of how technical it is but companies that want to use bitcoins can easily do this.

This is not bad idea at all but it need to be think about and it would be not so easy to implement. But :) idea seems not bad.

You can talk about it all you like; the devs will just ignore you, like everybody else who told them this.

The payment coin tracking protocol's use of SSL CAs has been a suicidal idea from day one.  The non-excuse proffered is "yeah but the CAs are the best of a lot of bad solutions".  Guess what folks, if all the solutions are bad then maybe the problem isn't actually a "problem" and doesn't need solving.

Or more specifically, as in this case, you aren't solving a problem you're just hiding a problem (invoice authentication) behind a much harder, much more-unsolved and probably-never-solvable problem (general purpose PKI) so you can piggyback off of the excuses crafted by the probably-never-solvable-problem's non-solution vendors.

General-purpose, worldwide, universally trusted PKI will never exist.

Tossing your lot in with the "most popular failed attempt" at solving this problem is much, much worse than admitting that nobody knows how to solve this problem and secure systems shouldn't be based on the assumption that it can be solved.

I totally agreed that PGP might be a better option. Because it will be more decentralized then using SSL.

PGP, SSL What's the difference?
please explain a little , so that non technical people like me fallow you.

Couldn't we just have a small no fee unconfirmed payment required for security?

If you write good patches to add PGP/WoT authentication, I suspect they would be merged in a heartbeat.

As far as I can tell, no one is opposed to such a thing, they just don't think it has a very good payoff to effort ratio compared to authentication using the global SSL PKI.  Because of this, it is not a good candidate for being built first.  If you disagree, feel free to write some code, or convince/bribe someone to do so.

Yes I know if I want it I should write it myself. I just don't have the time.

Indeed. 100% agreed.

I'm certainly not against better, more distributed alternatives to the payment protocol. BIP0070 was not meant as the be-all and end-all idea, but a immediate workable solution.

But there has been enough talk on this subject. Long, handwavy discussions are just not useful. Show us code.

Not trying to flame gweedo but what would we gain from using PGP over say self signed SSL cert?  SSL doesn't need to mean that CA are used.

Well first SSL cert are one-way. You only validate them for the company you are connecting to. With PGP we could validate two way, that the company is talking to the right user and user could be talking to the right company. Also PKI are expensive so we can't really have any community involvement this yet. Where is we used a key server that was decentralized like using a DHT, we can then not have to worry about hacks on CA's or it being expensive to start your own.

We also could use each full node be a key server and then you query everyone of them for the public key for the company you want to validate from. With majority rule on what is the correct public key.

Yes I agree that code is the overrules talking about it, but by having these talks I am hoping to get a developer who could do this and has the time. Right now many of us just don't have the time to develop this protocol write the features and then convince people to use it.

I don't think a bounty is appropriate with this feature.

That is a valid point although SSL does support client certs.  Bitcoin would be extended to expose that support making it identical to PGP in that respect.


All of that can be done with SSL self signed SSL certs as well.  I guess my point is you seem to be indicating that CA = bad therefore don't use SSL.  SSL can be used in a self signed fashion.  You could have SSL self signed key servers, you could load them into the network DHT style essentially replace public key in your example with SSL cert and the same thing applies.

Yes SSL protocol supports it but no browsers (Firefox does) really support that feature, no web server really makes use of that of feature. So what makes bitcoin going to support?


Well the X509 also isn't that strong. I mean if people think that SSL cert would work better in a decentralized environment I am open to it but I don't think SSL certificates aren't strong enough for this.

How would Bitcoin support PGP client public keys?  Whatever the solution replace PGP public key with SSL Client cert.  Not saying SSL is better but not seeing how we gain anything by going to PGP.


Ok now we are talking or at least to the heart of the matter.  Do you have a cite or link where X509 would fail that PGP wouldn't?

Well technically you can use a X509 to relay pgp information. I think a PGP certificate would be stronger and better in this case. Also X509 is weak with the signature algorithms, you don't need a link to show that.

Note that the BIP doesn't tell you what certificates should be trusted.  That's up to the implementation, not the protocol:

"Trusted root certificates may be obtained from the operating system; if validation is done on a device without an operating system, the Mozilla root store is recommended."

If you want to use a WoT, you can just use something like monkeysphere http://web.monkeysphere.info/ (http://web.monkeysphere.info/) instead of the normal PKI/root-CAs.

There isn't a widely used transport layer standard for OpenPGP, which is what the protocol needs, so TLS is probably a better choice then PGP for the actual encryption.

This is very much false, all information could be encrypted using the public key of the user that wants to send the bitcoins and then decrypt by their machine. Also I wouldn't include gpg into the actually bitcoin client I would have it called out to the shell so their is a disconnect of passwords and stuff.

No it's not false.  TLS (per its name) happens at the transport layer.  It's baked into every http library in the world.  There really isn't a standard to do this for OpenPGP that anyone uses or is supported by any library.  What you're proposing requires everyone to implement an ad-hoc poorly specified made-up-just-for-bip-70 encryption scheme and shoving it into the presentation layer.

We are talking about two different things, you are saying I want to take the transport layer and wrap it in a PGP encryption which is not what i am talking about. I am talking taking a public key encrypting data so only that private key can read it. Two very different things.

Well the subtleties do matter. X509 CAN support weak signature algorithms but it can also use require only cryptographically strong algorithms as well.


The support for older weaker algorithms is mostly for backwards legacy support, support which isn't needed for a greenfield implementation.  No reason that a particular users (or any user) would need to support weak signature algorithms.  You can also use MD5 to hash PGP messages as well. 

If both can be implemented without CAs, both can support key servers, both can use a node network for DHT storage of public keys and/or certs then ultimately the only advantage of using PGP over SSL would be that it is more secure.  Sorry you haven't shown that PGP would be more secure than self signed SSL certs.    This isn't an academic debate.  It is almost certain that Bitcoin will support SSL in payment protocol so it doesn't come down to PGP vs SSL it comes down to SSL vs SSL + PGP.  Adding another entire dependency just because weak SSL certs might be weak (and strong ones are cryptographically unbreakable) is well not a very strong argument.

Well my main focus is getting a decentralized key server, if it supports SSL first then pgp then fine. I am also not a big fan of openssl, that also is playing into it. I rather they used http://nacl.cr.yp.to/.

Thank you for clarifying I think a decentralized keyserver for those who wish to avoid the counterparty risk of CAs (not necessarily SSL) is a very good idea.

SSL is very adaptable

Hell you could even put a backup of the private key in your wallet (or use it as an address too).

Ideally the calls would be encapsulated using an interface then support for other crypto libraries would be plug and play (well maybe not plug and play but far easier for developers once wrappers were written).  For example I may want to use a smartcard for signing and currently that requires a whole host of ugly refactoring but if there was an interface I could write against I simply swap the openssl wrapper for the smartcard wrapper and compile.

Why use PGP when TLS is better designed for this already? I don't know much about it, but it seems you can use identity certificates with PGP, but the infrastructure of digital certificates is no doubt built around TLS.

Because an implementation contained a bug (now fixed) you want to change the protocol? Makes no sense.

No actually I have been bringing this up for a while now, just that I felt this was another good time to remind people. Also I wasn't a fan of openssl before but this makes it sure that it is too centralized and maybe implementing another library maybe better.

The real problem is that WoT is a lousy model for widespread use.

Say I want to buy some hardware from bitcoinstore.com.  I go to their website, prepare my order and check out.  They send a payment request, signed by some PGP key.  Now what?

The options boil down to:

1) I fly to wherever the hell they are and compare the key in person.
2) I get lucky and have a direct path of trustworthy and well known trust delegates between me and their cert.
3) The ad hoc certificate chain is of dubious value.  This is amazingly similar to the SSL CA system, but the entity acting as the CA isn't necessarily obvious, may not even know that they are doing it, and are in no way accountable to anyone.
4) The market recreates the CA system, for real.
5) I proceed with absolutely no security.

While the CA system has huge serious problems, the alternative is much, much worse in 99.9% of actual use cases, and a vastly better 0.1% of the time.

I have to agree with kjj. The PKI solution is simple and a guaranteed way of giving a proof of identity, which despite problems, has and will continue to work.

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.

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.

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

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.

There. I see it. What you did.

:)

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.

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.

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

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

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.

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.

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

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.

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.

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.

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

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?

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.

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

Ha!

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.