Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID:	a96d4d87c4bffbcfab15965b1772b9ad30c33f24
Page Name:	keyrevokation
Date:	2014-04-20 23:19:04
Original User:	bernd
Parent:	9ea7785a94217005fd0529bb6581e9299b5af312 (diff)
Next	ba1ff1982ac9eda4085114d2357b393055c6cda2

Content

Key Revocation

Key revocation usually is done with a signature of the lost key, i.e. both the owner and the adversary can revoke a compromised key. However, the important function in case of a revocation is declaring the successor key, which reestablishs trust. To do that, you must actually proof that you are the legitimate owner of the exposed secret key, so how do you do that? After all, the adversary has stolen it!

Therefore, the requirements are as follows:

Only the creator of the secret key can revoke it
A thief of the secret key can't (i.e. further information is necessary)
Revocation must present a trustworthy replacement key
Third parties must trust both the revocation and the replacement key without another trustworthy instance, i.e. trusting only their communication partner

I create two random number s1 and s2. Using these numbers, I create pubkeys p1=base*(s1) and p2=base*(s2). I compute (s)=(s1*p2) as "work secret" (i.e. the secret key that is proving my identity), and p=base*(s), my pubkey. I publish p, p1, and hash(p2), which together are stored as identity. The assumption is that hash(p2) can't be reversed to get p2, and using p and p1 don't reveal s and s1.

I keep s2 as offline copy (it's just 64 hex digits), and s as protected online copy in my device; s is subject to attacks and backdoors, and therefore at risk. To revoke a key, I publish p2, which the recipient can validate by p1*(p2)==p, and hash(p2).

To sign a new key, I use s2 as signature key, i.e. the recipient can use the just published p2 to verify the transition to the replacement key. Of course, the new key also has a signature with s, the old key.