4 ms·

Blockchains are better than anything at key revocation. Publishing public keys isn't enough.

by natrius 11y ago

geofft 11y ago
With PGP, key revocation is pretty straightforward: a self-authenticating revocation certificate gets published to the shared PGP database. This certificate could be kept in the clear in my safe deposit box, could be encrypted to a friend's key, could be M-of-N secret shared to N friends' keys, could be maintained by a third-party service that I've decided I trust, etc. As soon as that certificate is published, everyone sees it immediately. What does a blockchain add to this?
- natrius 11y ago
  > As soon as that certificate is published, everyone sees it immediately. PGP key servers can refuse to relay your revocation. Blockchains are censorship-resistant. They also let you define your own authentication, revocation and backup logic. PGP identities are keys. Blockchain identities are programs.
  - geofft 11y ago
    The censorship-resistance property here doesn't require a blockchain, just a Merkle tree. See the article and discussion here: https://news.ycombinator.com/item?id=10844612 https://news.ycombinator.com/item?id=10844612 (in particular my comment there). Specifically, a miner can refuse to encode your transaction just as much as your first PGP server can refuse to accept the sent key. (PGP actually has a strong advantage here, since it's easy to push your revocation to all the servers on your own, immediately, but you yourself are extremely unlikely to mine a block with your own transaction, unless the network is otherwise broken security-wise.) So the primary thing to worry about is a server that refuses to provide information on the revocation, once it has hit the shared database. But that can be solved by just having cryptographic monotonicity, that no transactions can be removed once encoded; you don't need the blockchain's specific power to order transactions and resolve conflicts. And a Merkle tree provides monotonicity. Certificate Transparency works this way. I agree that the PGP keyserver infrastructure doesn't currently provide this; I'm just asserting that it doesn't take a blockchain to provide it, and there are significant downsides (like waiting for a transaction to commit) to taking that approach. One thing that a blockchain would provide is the ability to revoke one key in favor of another, and uniquely determine which key supersedes the old. But it's not clear how important that ability is and whether it justifies the tradeoffs of a blockchain approach.
    - natrius 11y ago
      You're right that a Merkle tree is sufficient for censorship resistance when the criteria in your linked comment are met. (I read that comment earlier and enjoyed it!) So I'm changing my argument: I think key succession is very important and blockchains do it better. When you revoke a PGP key, you have to rebuild your web of trust from scratch, right? The key is your identity, and continuity is hard. With blockchains, a program is your identity. I can trust your new key immediately if the backup process your program encodes has been fulfilled. PGP keys can't be used to build identities that are as permanent and resilient as state-issued identities. Blockchains can.

Blockchains are better than anything at key revocation. Publishing public keys isn't enough.

by natrius 11y ago

Blockchains are better than anything at key revocation. Publishing public keys isn't enough.

With PGP, key revocation is pretty straightforward: a self-authenticating revocation certificate gets published to the shared PGP database. This certificate could be kept in the clear in my safe deposit box, could be encrypted to a friend's key, could be M-of-N secret shared to N friends' keys, could be maintained by a third-party service that I've decided I trust, etc. As soon as that certificate is published, everyone sees it immediately. What does a blockchain add to this?

natrius 11y ago
> As soon as that certificate is published, everyone sees it immediately. PGP key servers can refuse to relay your revocation. Blockchains are censorship-resistant. They also let you define your own authentication, revocation and backup logic. PGP identities are keys. Blockchain identities are programs.
- geofft 11y ago
  The censorship-resistance property here doesn't require a blockchain, just a Merkle tree. See the article and discussion here: https://news.ycombinator.com/item?id=10844612 https://news.ycombinator.com/item?id=10844612 (in particular my comment there). Specifically, a miner can refuse to encode your transaction just as much as your first PGP server can refuse to accept the sent key. (PGP actually has a strong advantage here, since it's easy to push your revocation to all the servers on your own, immediately, but you yourself are extremely unlikely to mine a block with your own transaction, unless the network is otherwise broken security-wise.) So the primary thing to worry about is a server that refuses to provide information on the revocation, once it has hit the shared database. But that can be solved by just having cryptographic monotonicity, that no transactions can be removed once encoded; you don't need the blockchain's specific power to order transactions and resolve conflicts. And a Merkle tree provides monotonicity. Certificate Transparency works this way. I agree that the PGP keyserver infrastructure doesn't currently provide this; I'm just asserting that it doesn't take a blockchain to provide it, and there are significant downsides (like waiting for a transaction to commit) to taking that approach. One thing that a blockchain would provide is the ability to revoke one key in favor of another, and uniquely determine which key supersedes the old. But it's not clear how important that ability is and whether it justifies the tradeoffs of a blockchain approach.
  - natrius 11y ago
    You're right that a Merkle tree is sufficient for censorship resistance when the criteria in your linked comment are met. (I read that comment earlier and enjoyed it!) So I'm changing my argument: I think key succession is very important and blockchains do it better. When you revoke a PGP key, you have to rebuild your web of trust from scratch, right? The key is your identity, and continuity is hard. With blockchains, a program is your identity. I can trust your new key immediately if the backup process your program encodes has been fulfilled. PGP keys can't be used to build identities that are as permanent and resilient as state-issued identities. Blockchains can.