Academically, I've been thinking of a system where every user has identities tied to private/public key pairs. A Web Of Trust style of verifying other users builds trust in who is who. If you want to be anonymous, just generate a new key pair and don't have anybody sign it. If these keys were used for absolutely everything in life both professionally and leisurely then a user could potentially generate a lot of keys. For one reason or another, some of these key pairs may wish to be destroyed.

If forward secrecy was always used with the key, could a method of revocation be to publicly post the private key? What downsides would this approach to revocation have?

  • 3
    What would be the positive outcome you expect? Because I can't see any.
    – Josef
    Jun 5, 2018 at 7:59
  • I wanted the cost of revocation to be high. I've been entertaining the idea of a blockchain who's sole purpose is key management even for the trivial things in life. It seemed important to have a way to revoke a key in a truly permanent way. In this specific scenario I'm not worried about people claiming a message was signed before the revocation. If a signed message was published after revocation, it should not be trusted. But a stolen key (say a hardware wallet without backups) means it couldn't be withdrawn as easily. Jun 6, 2018 at 0:03
  • The cost of revocation is to share the private key which has a few kilobytes at most. I don't see why this would be high?
    – Josef
    Jun 6, 2018 at 12:19
  • The cost is a private key that's no longer private. There is no path to unrevoke it. That's a high cost. Jun 6, 2018 at 20:49
  • If you just have a global list of revoked certificates that can only be appended to or use revokation certificates, there is also no path to unrevoke it. So what is the difference?
    – Josef
    Jun 7, 2018 at 11:11

1 Answer 1


The idea of simply publishing the private key works only if the private key is definitely not in use anymore. Apart from using forward secrecy for encryption it means that the key was never and will be never allowed to be used for digitally signing something (i.e. proof of authorship, proof of trust relationship...), because otherwise everybody could just take this private key to impersonate someone and claim that the message has been created by the other one before the private key was published.

Also, revocation by publishing the private key means that the owner still has access to the key. This is not necessarily the case if his computer was stolen or compromised by the attacker, but this is definitely a case where the owner wishes to revoke the key.

While one might probably construct a system were guarantees about not signing can be given it looks like your specific system has not this property, since there is actually signing involved to have some web of trust. But in any case it would be better if revocation would be possible without relying on such restrictions in the first place.

One way would not to publish the private key itself but a revocation message which was signed by the private key and can be verified by the public key. This is kind of revocation message could be created at any time, for example immediately after creating a new key. It could also be kept separately from the key and replicated to many places so that in case the private key got lost it would still be possible to revoke it by publishing such revocation message.

And this kind of pre-created revocation message is actually used in practice. To cite from the GPG manual:

After your keypair is created you should immediately generate a revocation certificate for the primary public key using the option --gen-revoke. If you forget your passphrase or if your private key is compromised or lost, this revocation certificate may be published to notify others that the public key should no longer be used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.