3 ms·

> That's all well and good, but the problem is finding a business-sustainable way to scalably deploy such a system. Is this effectively not how keybase.io work

> That's all well and good, but the problem is finding a business-sustainable way to scalably deploy such a system. Is this effectively not how keybase.io works / what they are doing? Bootstrapping identity is pretty easy, unless you're working remotely. Even then, trust-on-first-use can probably go marginally farther than what we have now. I don't think the problem is scaling that web of trust, as not everyone should need to know / sign for every employee immediately. I think the bigger issue is just getting people to adopt public keys and digital identities based on them. Hijacking identity through social engineering is pretty rare, even if it's not particularly "hard." So most people won't want to bother with something like this until it's too late.

nbadg 10y ago
Keybase is definitely working on creating a trust bridge between physical identity and (a specific type of) digital identity. Whether they've managed to do it in a scalable, business-sustainable way remains to be seen. Let me be clear: that's not a slight against them; from a business standpoint I find no good analysis or speculation on their financial numbers and see no publicly commented monetization strategy). The reality of the world today is that if you can't make something economically self-perpetuating, it will almost certainly eventually fail -- especially if the problem you're trying to solve is one of as large a magnitude as literally any social interaction on the internet (they all involve connecting digital identities to physical ones). From a technical standpoint, the primary problem I have with Keybase is that it uses PGP. I'm not [1] the only [2] person (and, since I'm effectively 100% unknown, I'm far, FAR from the most prominent, who is arguably Bruce Schneier [3]) to criticize PGP, but at the core of it, even ignoring substantial usability issues, have you ever tried to forward a PGP message? It's sort-of possible, if you re-encrypt and re-sign everything, but it's certainly not practical and definitely not scalable. Sharing and re-sharing is the cornerstone of much of the social internet, and PGP renders it effectively impossible. Keybase has a really, really cool body of work surrounding "connect this PGP key to this physical identity", but unfortunately PGP keys are only one in a small subset of cryptographic identities, which is itself an even smaller subset of digital identities in general. I get why they've done it this way; the alternative is to write your own cryptographic protocol that nobody is using, which is a much riskier thing (speaking from experience [4]). But at the end of the day, all of Keybase hinges around using PGP (or a PGP-like approach), and I'm very skeptical that's a viable solution to the social problems we have today. [1] https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma... [2] https://moxie.org/blog/gpg-and-me/ https://moxie.org/blog/gpg-and-me/ [3] https://www.schneier.com/blog/archives/2015/11/testing_the_usa.html https://www.schneier.com/blog/archives/2015/11/testing_the_u... [4] https://github.com/Muterra/doc-golix https://github.com/Muterra/doc-golix
- wfn 10y ago
  > have you ever tried to forward a PGP message? I believe this is a solvable UI / UX problem; what you are in fact criticizing is not the OpenPGP format of asymmetric keys, but rather the conventional implementations of PGP, based around GPG. I agree that GPG is not very user-friendly for the use cases at hand; but surely things can be improved on this front while not ditching the general PGP model itself? edit as to the more technical issues, e.g. lack of PFS, core issue of initializing WoT, the defaults in the PGP format etc., yes, they suck, but surely one could iterate on the UX side of things, abstracting all internals behind a more general PGP API, and later gracefully changing the internals themselves, too? Not saying it's a piece of cake or anything!
  - nbadg 10y ago
    To your first point: I agree that it's not the key format that's the problem with forwarding -- so, you could use a PGP key definition for a different message format that worked better, and as long as you ignored all of the extra stuff in a PGP public key definition, it's no harm no foul. At its core, it's just a public key. But that's not what breaks forwarding, the actual message format does, and that isn't just a UI/UX problem. You must personally decrypt and re-encrypt the message against the public key of the person you're forwarding it to, and if the original author signed it you then need to somehow encapsulate the signature (which is outside of PGP spec), and then you're still left with the key distribution problem, which becomes exponentially more difficult with each tome the message is forwarded. That's not just a UI/UX problem, that's also a fundamental technical failing of the PGP message. PGP is incompatible with social. That's not to say, by any stretch of the imagination, that these are unsolvable problems. Quite the opposite, actually; I hope at the very least that my company has made some decent progress down the road to solving them. I'm saying only that PGP simply isn't the vehicle to take us there, because it is (in my experience) a very poor design for general-purpose usage (especially social). To your edit: unfortunately PGP encapsulation is really, really poorly situated to construct general-purpose abstractions on top of. It just doesn't work with reused (ie forwarded, replied, etc) data. Building an abstraction facade on top of that to ease transition to a new format, though technically possible, is definitely infeasible: both your storage requirements and computation requirements are going to increase linearly with each reuse of existing data (meaning it would grow exponentially with the number of shares, assuming the worst case, that everyone re-shares it).

nbadg 10y ago

Keybase is definitely working on creating a trust bridge between physical identity and (a specific type of) digital identity. Whether they've managed to do it in a scalable, business-sustainable way remains to be seen. Let me be clear: that's not a slight against them; from a business standpoint I find no good analysis or speculation on their financial numbers and see no publicly commented monetization strategy). The reality of the world today is that if you can't make something economically self-perpetuating, it will almost certainly eventually fail -- especially if the problem you're trying to solve is one of as large a magnitude as literally any social interaction on the internet (they all involve connecting digital identities to physical ones). From a technical standpoint, the primary problem I have with Keybase is that it uses PGP. I'm not [1] the only [2] person (and, since I'm effectively 100% unknown, I'm far, FAR from the most prominent, who is arguably Bruce Schneier [3]) to criticize PGP, but at the core of it, even ignoring substantial usability issues, have you ever tried to forward a PGP message? It's sort-of possible, if you re-encrypt and re-sign everything, but it's certainly not practical and definitely not scalable. Sharing and re-sharing is the cornerstone of much of the social internet, and PGP renders it effectively impossible. Keybase has a really, really cool body of work surrounding "connect this PGP key to this physical identity", but unfortunately PGP keys are only one in a small subset of cryptographic identities, which is itself an even smaller subset of digital identities in general. I get why they've done it this way; the alternative is to write your own cryptographic protocol that nobody is using, which is a much riskier thing (speaking from experience [4]). But at the end of the day, all of Keybase hinges around using PGP (or a PGP-like approach), and I'm very skeptical that's a viable solution to the social problems we have today. [1] https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma... [2] https://moxie.org/blog/gpg-and-me/ https://moxie.org/blog/gpg-and-me/ [3] https://www.schneier.com/blog/archives/2015/11/testing_the_usa.html https://www.schneier.com/blog/archives/2015/11/testing_the_u... [4] https://github.com/Muterra/doc-golix https://github.com/Muterra/doc-golix

wfn 10y ago
> have you ever tried to forward a PGP message? I believe this is a solvable UI / UX problem; what you are in fact criticizing is not the OpenPGP format of asymmetric keys, but rather the conventional implementations of PGP, based around GPG. I agree that GPG is not very user-friendly for the use cases at hand; but surely things can be improved on this front while not ditching the general PGP model itself? edit as to the more technical issues, e.g. lack of PFS, core issue of initializing WoT, the defaults in the PGP format etc., yes, they suck, but surely one could iterate on the UX side of things, abstracting all internals behind a more general PGP API, and later gracefully changing the internals themselves, too? Not saying it's a piece of cake or anything!
- nbadg 10y ago
  To your first point: I agree that it's not the key format that's the problem with forwarding -- so, you could use a PGP key definition for a different message format that worked better, and as long as you ignored all of the extra stuff in a PGP public key definition, it's no harm no foul. At its core, it's just a public key. But that's not what breaks forwarding, the actual message format does, and that isn't just a UI/UX problem. You must personally decrypt and re-encrypt the message against the public key of the person you're forwarding it to, and if the original author signed it you then need to somehow encapsulate the signature (which is outside of PGP spec), and then you're still left with the key distribution problem, which becomes exponentially more difficult with each tome the message is forwarded. That's not just a UI/UX problem, that's also a fundamental technical failing of the PGP message. PGP is incompatible with social. That's not to say, by any stretch of the imagination, that these are unsolvable problems. Quite the opposite, actually; I hope at the very least that my company has made some decent progress down the road to solving them. I'm saying only that PGP simply isn't the vehicle to take us there, because it is (in my experience) a very poor design for general-purpose usage (especially social). To your edit: unfortunately PGP encapsulation is really, really poorly situated to construct general-purpose abstractions on top of. It just doesn't work with reused (ie forwarded, replied, etc) data. Building an abstraction facade on top of that to ease transition to a new format, though technically possible, is definitely infeasible: both your storage requirements and computation requirements are going to increase linearly with each reuse of existing data (meaning it would grow exponentially with the number of shares, assuming the worst case, that everyone re-shares it).