So, Mirmir wrote:
| 13. Targeted attacks against PGP key ids are possible
This is an advantage of Keybase. Then we're not depending on the KeyID, or even on the fingerprint, but rather on an identity that's multiply and independently authenticated.
I keep hearing more and more about keybase, and I have a problem with it. It's a centralised service, owned and controlled by a single entity; moreover, the keys are tied to online identities controlled by corporate third parties (Twitter, Facebook, et al). I don't see a Diaspora/The Federation support, for instance. My problem with this is two-fold: 1. It might allow abuse, esp. MITM attacks. If Keybase becomes a /de facto/ standard of acquiring keys, it seems trivial to me for them to replace a valued target's key with something a LEA would provide. 2. It still promotes the closed, walled-gardens. Diaspora or GNU Social support would not be that hard to implement. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/17/2015 03:52 AM, rysiek wrote:
So,
Mirmir wrote:
| 13. Targeted attacks against PGP key ids are possible
This is an advantage of Keybase. Then we're not depending on the KeyID, or even on the fingerprint, but rather on an identity that's multiply and independently authenticated.
I keep hearing more and more about keybase, and I have a problem with it. It's a centralised service, owned and controlled by a single entity; moreover, the keys are tied to online identities controlled by corporate third parties (Twitter, Facebook, et al). I don't see a Diaspora/The Federation support, for instance.
As I understand it, Keybase is an API. The website/service is merely a demonstration. The developers are aiming for mass adoption, and so they've targeted the most popular sites. With some coding, arbitrary sites could be used, with two requirements. First, it must be possible for users to post persistent signed proofs. Second, it must be possible for the API to access those signed proofs, in order to verify them.
My problem with this is two-fold:
1. It might allow abuse, esp. MITM attacks. If Keybase becomes a /de facto/ standard of acquiring keys, it seems trivial to me for them to replace a valued target's key with something a LEA would provide.
That's the value of trackers. Those tracking such a comprised target would see that various public signed proofs are no longer valid for the target's key on Keybase. The adversary could alter all of the target's public signed proofs. But even that wouldn't suffice, because trackers have independent snapshot histories of public proofs. And furthermore, snapshot histories are embedded in the Bitcoin blockchain.
2. It still promotes the closed, walled-gardens. Diaspora or GNU Social support would not be that hard to implement.
Signed proofs could be placed anywhere that's accessible to the API. But that takes coding, and developers have priorities. One can request. Anyway, I've created a test identity: https://keybase.io/Proba. Once I've added enough proofs, and have enough trackers, I plan to mess with it by replacing the public key held by Keybase, altering some of the proofs, and so on. Then we can see how that shows up for its trackers, and for other users. I'll also explore impacts of malicious trackers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJUuqg5AAoJEGINZVEXwuQ+WGMIAISP/IMu0gZeuGoNJLtIgAgE R1KEv0dpU6egwzM97vJYOHvgHkGdt+mvqGOSf9C7Xnvzb/ksGKbpWoOpc2mufQq2 MZ+p2/Fp7XAJoLHn5dXaImaFt4RLQCVkBdbc3UXaoXNf59btWiOOm6VcRrKXeSNd SUedVOU+PGP2p/HO22VbdJ/uTOwPzXR9cq1q0LZ/XNODzoHi7iRz91FdNNx3dMgw FjCWXwIKfihHYfScYE8NFQ7ORZauu/DlErd92wiyRo5TEP4BhoImGUzL9Cvwm2bA pRYFxXWOsk5a4vYfVh6CMsLTlH9M7adhv08Vs+wEDuIjDLFgUR6H+u3c8NdWd5w= =6k0+ -----END PGP SIGNATURE-----
Dnia sobota, 17 stycznia 2015 11:22:02 Mirimir pisze:
On 01/17/2015 03:52 AM, rysiek wrote:
So,
Mirmir wrote:
| 13. Targeted attacks against PGP key ids are possible
This is an advantage of Keybase. Then we're not depending on the KeyID, or even on the fingerprint, but rather on an identity that's multiply and independently authenticated.
I keep hearing more and more about keybase, and I have a problem with it. It's a centralised service, owned and controlled by a single entity; moreover, the keys are tied to online identities controlled by corporate third parties (Twitter, Facebook, et al). I don't see a Diaspora/The Federation support, for instance.
As I understand it, Keybase is an API. The website/service is merely a demonstration. The developers are aiming for mass adoption, and so they've targeted the most popular sites. With some coding, arbitrary sites could be used, with two requirements. First, it must be possible for users to post persistent signed proofs. Second, it must be possible for the API to access those signed proofs, in order to verify them.
My problem with this is two-fold:
1. It might allow abuse, esp. MITM attacks. If Keybase becomes a /de facto/ standard of acquiring keys, it seems trivial to me for them to replace a valued target's key with something a LEA would provide.
That's the value of trackers. Those tracking such a comprised target would see that various public signed proofs are no longer valid for the target's key on Keybase. The adversary could alter all of the target's public signed proofs. But even that wouldn't suffice, because trackers have independent snapshot histories of public proofs. And furthermore, snapshot histories are embedded in the Bitcoin blockchain.
Wait, how/where does Bitcoin come into this? Did I miss it somehow? I admit I didn't dive into keybase increadibly deep, but still...
2. It still promotes the closed, walled-gardens. Diaspora or GNU Social support would not be that hard to implement.
Signed proofs could be placed anywhere that's accessible to the API. But that takes coding, and developers have priorities. One can request.
Right.
Anyway, I've created a test identity: https://keybase.io/Proba. Once I've added enough proofs, and have enough trackers, I plan to mess with it by replacing the public key held by Keybase, altering some of the proofs, and so on. Then we can see how that shows up for its trackers, and for other users. I'll also explore impacts of malicious trackers.
Oh, great, I really appreciate that effort. Please keep me posted! -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/17/2015 01:34 PM, rysiek wrote:
Dnia sobota, 17 stycznia 2015 11:22:02 Mirimir pisze:
On 01/17/2015 03:52 AM, rysiek wrote:
So,
Mirmir wrote:
| 13. Targeted attacks against PGP key ids are possible
This is an advantage of Keybase. Then we're not depending on the KeyID, or even on the fingerprint, but rather on an identity that's multiply and independently authenticated.
I keep hearing more and more about keybase, and I have a problem with it. It's a centralised service, owned and controlled by a single entity; moreover, the keys are tied to online identities controlled by corporate third parties (Twitter, Facebook, et al). I don't see a Diaspora/The Federation support, for instance.
As I understand it, Keybase is an API. The website/service is merely a demonstration. The developers are aiming for mass adoption, and so they've targeted the most popular sites. With some coding, arbitrary sites could be used, with two requirements. First, it must be possible for users to post persistent signed proofs. Second, it must be possible for the API to access those signed proofs, in order to verify them.
My problem with this is two-fold:
1. It might allow abuse, esp. MITM attacks. If Keybase becomes a /de facto/ standard of acquiring keys, it seems trivial to me for them to replace a valued target's key with something a LEA would provide.
That's the value of trackers. Those tracking such a comprised target would see that various public signed proofs are no longer valid for the target's key on Keybase. The adversary could alter all of the target's public signed proofs. But even that wouldn't suffice, because trackers have independent snapshot histories of public proofs. And furthermore, snapshot histories are embedded in the Bitcoin blockchain.
Wait, how/where does Bitcoin come into this? Did I miss it somehow? I admit I didn't dive into keybase increadibly deep, but still...
See <https://keybase.io/docs/server_security> and re the blockchain <https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain>. | Every public announcement you make on Keybase is now verifiably | signed by Keybase and hashed into the Bitcoin blockchain. To be | specific, all of these: | | o announcing your Keybase username and your public key | o identity proofs (twitter, github, your website, etc.) | o public bitcoin address announcements | o public tracking statements | o revocations of any of these
2. It still promotes the closed, walled-gardens. Diaspora or GNU Social support would not be that hard to implement.
Signed proofs could be placed anywhere that's accessible to the API. But that takes coding, and developers have priorities. One can request.
Right.
Anyway, I've created a test identity: https://keybase.io/Proba. Once I've added enough proofs, and have enough trackers, I plan to mess with it by replacing the public key held by Keybase, altering some of the proofs, and so on. Then we can see how that shows up for its trackers, and for other users. I'll also explore impacts of malicious trackers.
Oh, great, I really appreciate that effort. Please keep me posted!
Thanks. If you join, you can play :) I'm <https://keybase.io/mirimir> and the test account is <https://keybase.io/proba>. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJUut40AAoJEGINZVEXwuQ+3zAH/A7f9GqRi3T3P+viT6M46pXw 4TcxxWGmWtqGz6fbtkYN5AMuedG1hgSRSaqoznpdVhC82kzv6oljC5DyGDJ96Rqv UH0d3xAtiDHO2xN8v7nzE8NmQj7MPRHD0/dZouVaryEAmlFxmsEm0EUGYWhNyIr8 6r6aSCpLgfQi26AhdUdc2PhGf+bAnLnWVQHmpFVaEddi6Vws8MCEeCqhtRmNsoGJ E9wDxhciVcMQKthATgo7K9a8yfEY5jglyFlK38qMrcGrE0TZ/f3wmShQGQqI7B4E aQ4AXCc1X09DwuzEoCiYZQpCixkteH9ZKOMXCWR834SHYcEUNu7lV2eMowXv6OM= =1QmD -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a Keybase profile at https://keybase.io/jcrawfordor I have several invites available as well if anyone else is interested. I think of Keybase very positively, it is perhaps not perfect but it's a big improvement in usability for typical people than the web-of-trust system. Attaching cryptographic keys to social network identities matches how most people really use the internet very well. Perhaps this has already been mentioned, but it's worth pointing out that the Keybase service (keybase.io) is NOT trusted to verify the proofs. The keybase command-line tool verifies the proofs independently itself, preventing the keybase service lying. That said, I would not advocate uploading your private key to keybase. There is a huge usability tradeoff surrounding this, and while Keybase is trying to maintain as much security as possible, I'm not yet convinced that it is safe to provide the private key to a third party even if they have zero knowledge (primarily because of problems with web browser cryptographic implementation). Jesse B. Crawford Student, Information Technology New Mexico Inst. of Mining & Technology https://jbcrawford.us // jesse@jbcrawford.us https://cs.nmt.edu/~jcrawford // jcrawford@cs.nmt.edu On 2015-01-17 15:12, Mirimir wrote:
On 01/17/2015 01:34 PM, rysiek wrote:
Dnia sobota, 17 stycznia 2015 11:22:02 Mirimir pisze:
On 01/17/2015 03:52 AM, rysiek wrote:
So,
Mirmir wrote:
| 13. Targeted attacks against PGP key ids are possible
This is an advantage of Keybase. Then we're not depending on the KeyID, or even on the fingerprint, but rather on an identity that's multiply and independently authenticated.
I keep hearing more and more about keybase, and I have a problem with it. It's a centralised service, owned and controlled by a single entity; moreover, the keys are tied to online identities controlled by corporate third parties (Twitter, Facebook, et al). I don't see a Diaspora/The Federation support, for instance.
As I understand it, Keybase is an API. The website/service is merely a demonstration. The developers are aiming for mass adoption, and so they've targeted the most popular sites. With some coding, arbitrary sites could be used, with two requirements. First, it must be possible for users to post persistent signed proofs. Second, it must be possible for the API to access those signed proofs, in order to verify them.
My problem with this is two-fold:
1. It might allow abuse, esp. MITM attacks. If Keybase becomes a /de facto/ standard of acquiring keys, it seems trivial to me for them to replace a valued target's key with something a LEA would provide.
That's the value of trackers. Those tracking such a comprised target would see that various public signed proofs are no longer valid for the target's key on Keybase. The adversary could alter all of the target's public signed proofs. But even that wouldn't suffice, because trackers have independent snapshot histories of public proofs. And furthermore, snapshot histories are embedded in the Bitcoin blockchain.
Wait, how/where does Bitcoin come into this? Did I miss it somehow? I admit I didn't dive into keybase increadibly deep, but still...
See <https://keybase.io/docs/server_security> and re the blockchain <https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain>.
| Every public announcement you make on Keybase is now verifiably | signed by Keybase and hashed into the Bitcoin blockchain. To be | specific, all of these: | | o announcing your Keybase username and your public key | o identity proofs (twitter, github, your website, etc.) | o public bitcoin address announcements | o public tracking statements | o revocations of any of these
2. It still promotes the closed, walled-gardens. Diaspora or GNU Social support would not be that hard to implement.
Signed proofs could be placed anywhere that's accessible to the API. But that takes coding, and developers have priorities. One can request.
Right.
Anyway, I've created a test identity: https://keybase.io/Proba. Once I've added enough proofs, and have enough trackers, I plan to mess with it by replacing the public key held by Keybase, altering some of the proofs, and so on. Then we can see how that shows up for its trackers, and for other users. I'll also explore impacts of malicious trackers.
Oh, great, I really appreciate that effort. Please keep me posted!
Thanks. If you join, you can play :) I'm <https://keybase.io/mirimir> and the test account is <https://keybase.io/proba>.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUvE+yAAoJEBPrCUVAhb3Br/oH/jRXBKdeBMcCRo5jSc9cmyXD +WuWWUfnWW+xWS+sRuBxMVU+nZTUS5Zku7/us5XzP/i6QwKHtYD2dUr2CA7kdzqP JzY33yEoFRt2rQxcEgEgwDtIgPN24r9kkZJEeoBm+WF0uZViFCiAHc8PinRmjC6q xIGWBL9syq0mWB68KMJbgdjRChG+rPUxEFZxngdr8bXYHjo5JlCwP71xNAdamjcA 5K1yqV7YlAYAlFqWhdszNh48tu4Yn1Qgt6WuGoxXB+vqQUrtBCgZnkq6RQmcSm/d VpT2A4zVutLHkHUvD7hlxCUKaP+8JtK8EMMuJ1poqrRnmEmRcMNaYlqEuihpFgo= =42Ig -----END PGP SIGNATURE-----
participants (3)
-
Jesse B. Crawford -
Mirimir -
rysiek