Artifact [ba1ff1982a]
Not logged in

Artifact ba1ff1982ac9eda4085114d2357b393055c6cda2:

Wiki page [keyrevokation] by bernd 2014-04-27 19:31:03.
D 2014-04-27T19:31:03.976
L keyrevokation
P a96d4d87c4bffbcfab15965b1772b9ad30c33f24
U bernd
W 2430
<h1>Key Revocation</h1>

<p>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. &nbsp;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? &nbsp;After
all, the adversary has stolen it!<br>
</p>

<p>Therefore, the requirements are as follows:</p>

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

<p></p>I create two random number s1 and s2. &nbsp;Using these numbers, I
create pubkeys p1=base*(s1) and p2=base*(s2). &nbsp;I compute (s)=(s1*p2) as
"work secret" (i.e. the secret key that is proving my identity), and
p=base*(s), my pubkey. &nbsp;I publish p and p1, which together are stored as
identity. &nbsp;The assumption is that p1 can't be reversed to get s1, and p
won't reveal s. &nbsp;An attacker who stole s can't guess s1, because he
doesn't have p2, and so it's even more difficult to get s2. &nbsp;An attacker
who stole s can generate a new pair of p1, p2, but that would give him a
different identity (a suspicious identity, though). &nbsp;After generating the
key, s1 is destroyed; it is no longer needed, though it can be recomputed using
s and p2 and the extended euclidean algorithm.

<p>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. &nbsp;To revoke a key, I publish p2, which the recipient can validate
by p1*(p2)==p. &nbsp;</p>

<p>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. &nbsp;Of
course, the new key also has a signature with s, the old key. &nbsp;The format
of the revocation attribute is actually &lt;new pubkeys: pnew, p1new&gt;&lt;p2,
sig using s2&gt;&lt;sig using s&gt;. &nbsp;Both signatures must have the same
signing date, and a never expiration date (a revocation doesn't expire).</p>

Z cf2b5a7bd55f9fd1b9ba82137677cf33