开发者

RSA encryption: Is it possible to revoke a public/private key pair in peer-to-peer?

开发者 https://www.devze.com 2023-03-17 05:13 出处:网络
I\'m creating an app (C#) that is going to send some messages around the network. Outgoing messages will be signed by a private key, incoming mes开发者_如何学Csages decrypted with a private key.

I'm creating an app (C#) that is going to send some messages around the network. Outgoing messages will be signed by a private key, incoming mes开发者_如何学Csages decrypted with a private key.

In case someone steals the private key, I want to be able to revoke it (send a revocation message to all other clients). Since I'm the owner of the stolen private key, only I must be able to revoke it.

My question: Is it possible to create a public/private key pair, depended on a so-called "Master public/private key pair" I have created before, to use in my app and if the private key in the app got stolen, I can revoke it, because with the master key I can proof that I'm the owner?

Hope someone understand what I mean ;-)

Mike

Update 1:

  • I'm developing a peer-to-peer app, so there will be no central server / CA
  • I'm generating the public/private keys by using the RSACryptoServiceProvider class in C#


Basically you'll design a system where each client can receive messages signed from two private keys: if they receive a message from the second private key, it will discard anything received signed with the first key.

Seems to be simple...

So, I think that you meant that you want to "revoke" the first public/private key in a way that your system will consider this pair invalid independent of same processing, I mean, even if someone hack the client, it won't be able to accept the first compromised key pair, because somehow they're revoked by the second key pair.

Is that it?

If so... no, without some kind of server, I don't think you can "revoke" a key pair. Revoking implies in having a central server telling which keys are valid, or your application doing this check internally (for ex., receiving a message from the second key pair and processing it)


You want to wrap you keys in a X.509 Certificate. The certificates should have a revocation Authority that supports OCSP (Online Certificate Status Protocol). see http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol


You don't need a second key (and if you did - what if an attacker stole that?) Simply define a 'revocation' message type which indicates the key that signed it is revoked (irrevocably, as it were). If your key gets stolen, you simply have to send out the revocation message using the stolen key, and the key becomes useless to the attacker.

How to distribute the revocation message depends on the system you're using, of course, but I'm assuming here that you have some way to distribute keys already, and therefore revocations can take the same route.

0

精彩评论

暂无评论...
验证码 换一张
取 消