Can we talk about removing SSL from the payment protocol and put PGP?

[DeathAndTaxes]

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.

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

Code:

openssl req -new -x509 -sha512 ...

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.

[1714730078]

1714730078

[1714730078]

1714730078

[1714730078]

1714730078

[1714730078]

1714730078

[1714730078]

1714730078

[1714730078]

1714730078

[gweedo]

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.

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

Code:

openssl req -new -x509 -sha512 ...

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/.

[DeathAndTaxes]

Well my main focus is getting a decentralized key server, if it supports SSL first then pgp then fine.

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

openssl ecparam -genkey -name secp256k1 -out e:\server.pem
openssl req -new -x509 -nodes -sha256 -key e:\server.pem > e:\server.cert

openssl x509 -in e:\server.cert -text -noout

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            cd:a5:2d:4d:4c:b1:34:94
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=I am as secure as bitcoin itself
        Validity
            Not Before: Apr  9 19:51:02 2014 GMT
            Not After : May  9 19:51:02 2014 GMT
        Subject: CN=I am as secure as bitcoin itself
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:86:80:e3:3b:d6:0e:ab:13:bf:03:5e:ca:02:04:
                    4e:e1:82:7e:10:50:b1:9d:75:d9:4e:63:c6:75:9b:
                    7f:2b:06:c8:e1:11:9c:63:5c:25:29:6a:d3:8f:ee:
                    ae:b0:64:6d:36:80:29:6b:85:ce:73:98:fe:68:22:
                    cf:df:f6:62:53
                ASN1 OID: secp256k1
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                14:ED:A5:89:CD:E8:AB:AA:BF:1D:6D:70:17:81:14:C1:B2:51:BC:3E
            X509v3 Authority Key Identifier:
                keyid:14:ED:A5:89:CD:E8:AB:AA:BF:1D:6D:70:17:81:14:C1:B2:51:BC:3E
            X509v3 Basic Constraints:
                CA:TRUE <-should probably be false but didn't feel like setting up config file
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:65:10:58:29:47:c8:3d:b7:aa:d0:ef:fc:80:47:
         4e:72:77:e5:a5:58:48:0d:6c:37:8f:fc:3d:fc:e1:34:cd:b3:
         02:20:4d:14:5e:8f:0d:31:35:84:20:2d:5a:be:6a:3a:ea:e0:
         7a:69:6d:1e:45:66:4f:5b:e2:d8:57:59:2f:27:4d:ba

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

I am also not a big fan of openssl, that also is playing into it. I rather they used http://nacl.cr.yp.to/.

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.

[MatthewLM]

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.

[gweedo]

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.

[kjj]

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.

[MatthewLM]

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.

[gweedo]

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?

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.

[Carlton Banks]

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.

[justusranvier]

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.

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

[gweedo]

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.

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.

[jbreher]

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

There. I see it. What you did.

[MatthewLM]

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.

[Carlton Banks]

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

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.

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.

[marcus_of_augustus]

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.

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

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

[SlipperySlope]

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.

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.

[gweedo]

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.

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

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

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.

[luv2drnkbr]

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

[gweedo]

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

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

<gmaxwell> go11111111111: Mike Hearn is a nice and smart guy. But he's also nearly a parody of himself with his constant recourse to centralization. I dunno, I haven't paid a lot of attention to anything he's said on privacy since he's generally been pretty hostile to it in the past.

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

[kjj]

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?

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.

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.

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.

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.