DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 07:30:25 PM |
|
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. 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.
|
|
|
|
gweedo (OP)
Legendary
Offline
Activity: 1498
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 07:46:39 PM |
|
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. 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
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 08:02:46 PM |
|
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
Legendary
Offline
Activity: 1190
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 08:10:37 PM |
|
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 (OP)
Legendary
Offline
Activity: 1498
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 08:14:40 PM |
|
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
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 08:26:46 PM |
|
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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
MatthewLM
Legendary
Offline
Activity: 1190
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 08:31:15 PM |
|
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 (OP)
Legendary
Offline
Activity: 1498
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 08:50:08 PM |
|
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
Legendary
Offline
Activity: 3430
Merit: 3079
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 08:50:25 PM |
|
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.
|
Vires in numeris
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 09:11:18 PM |
|
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 (OP)
Legendary
Offline
Activity: 1498
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 09:24:15 PM |
|
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
Legendary
Offline
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 09:33:11 PM |
|
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. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
Anyone with a campaign ad in their signature -- for an organization with which they are not otherwise affiliated -- is automatically deducted credibility points.
I've been convicted of heresy. Convicted by a mere known extortionist. Read my Trust for details.
|
|
|
MatthewLM
Legendary
Offline
Activity: 1190
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 09:39:02 PM |
|
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
Legendary
Offline
Activity: 3430
Merit: 3079
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 09:50:53 PM |
|
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.
|
Vires in numeris
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 09, 2014, 10:05:39 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 10, 2014, 12:56:16 AM |
|
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 (OP)
Legendary
Offline
Activity: 1498
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 10, 2014, 01:34:13 AM |
|
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.
|
|
|
|
|
gweedo (OP)
Legendary
Offline
Activity: 1498
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 10, 2014, 02:31:33 AM |
|
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
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 10, 2014, 03:32:57 AM |
|
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. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
|