Gpg revocation anomaly
No such Client
nosuchclient at gmail.com
Fri Aug 17 17:43:04 CEST 2012
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Good day, I have found an anomaly within gpg that I have asked several
other individuals running different linux distros (gpg 1.4.10 / 1.4.11)
to independently verify and they have come to the same conclusion.
After reading the gnupg manual, and the manpages several times for
pleasure, I tried ¨addrevoker sensitive¨ , with a testkey that I
created. I have read the manpages, and the manual, and my understanding
of addrevoker sensitive is that it is a deniable designated revoker that
no one else but the revoked party and the revokee should know what it
is. As well as B. That said ¨sensitive¨ (deniable) designated revoker
can reliably generate and revoke whatever key said individual has been
designated as a sensitive revoker for. So, I tested this feature using
two test keys on a new keyring I created to simulate a real-world
environment. and this raised more questions than answers (addrevoker
sensitive - is not well-documented, nor is it covered in any detail)
# to create a new keyring (using bash)
mkdir new_gpg
export GNUPGHOME=newgpg/
# generating testkeys
gpg --gen-key (generated testkey 1, and testkey2 , using default
settings for sake of example )
gpg --fingerprint
new_gpg//pubring.gpg
- --------------------
pub 1024R/10CAC705 2012-08-17 [expires: 2012-08-19]
Key fingerprint = 9AAE 107E E4F4 80D3 D4A2 633F 61E4 5498 10CA C705
uid testkey1
sub 1024R/33C50E7A 2012-08-17 [expires: 2012-08-19]
pub 1024R/FC736AA2 2012-08-17 [expires: 2012-08-19]
Key fingerprint = AB08 CD0A E5A1 8DB8 CDBC 3DD2 95C6 26F3 FC73 6AA2
uid testkey2
sub 1024R/3C5A6360 2012-08-17 [expires: 2012-08-19]
# designation
gpg --edit-key testkey2
addrevoker sensitive -> testkey1 -> (finish the prompt and save)
#now we will import the testkey2 pubkey into the ¨main keyring¨
gpg -a --export testkey2 > testkey2.pub
# in the primary key-ring (using screen, or opening a new terminal will
open a new bash instance with the standard default gpg path set to
~/.gnupg/)
gpg --import testkey2.pub
(gpg: key FC736AA2: public key "testkey2" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1) )
# now back to the test key-ring
gpg --desig-revoke testkey2
(pub 1024R/FC736AA2 2012-08-17 testkey2
To be revoked by:
sec 1024R/10CAC705 2012-08-17 testkey1
(This is a sensitive revocation key)
Create a designated revocation certificate for this key? (y/N)) -> Y
- -> 0 (No reason specified)
and voila..
Is this okay? (y/N) y
ASCII armored output forced.
Revocation certificate created.
#which is imported ofc... #
to show...
gpg: key FC736AA2: "testkey2" revocation certificate added
gpg: key FC736AA2: "testkey2" 1 new signature
gpg: Total number processed: 1
gpg: new signatures: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2012-08-19
and a gpg --edit-key testkey2 shows:
gpg --edit-key testkey2
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
This key was revoked on 2012-08-17 by RSA key 10CAC705 testkey1
This key may be revoked by RSA key 10CAC705 testkey1 (sensitive)
pub 1024R/FC736AA2 created: 2012-08-17 revoked: 2012-08-17 usage: SC
trust: ultimate validity: revoked
This key was revoked on 2012-08-17 by RSA key 10CAC705 testkey1
sub 1024R/3C5A6360 created: 2012-08-17 revoked: 2012-08-17 usage: E
[ revoked] (1). testkey2
# Now for the anomaly... we update the exported pubkey
gpg -a --export testkey2 testkey2.pub
# and just in case you are wondering, here is what it looks like:
gpg testkey2.pub
pub 1024R/FC736AA2 2012-08-17 [revoked]
uid testkey2
sub 1024R/3C5A6360 2012-08-17 [expires: 2012-08-19]
# and now, using the primary keyring,..
#before import , gpg --edit-key testkey2 shows:
pub 1024R/FC736AA2 created: 2012-08-17 expires: 2012-08-19 usage: SC
trust: unknown validity: unknown
sub 1024R/3C5A6360 created: 2012-08-17 expires: 2012-08-19 usage: E
[ unknown] (1). testkey2
# during import.... :
gpg --import testkey2.pub
gpg: key FC736AA2: "testkey2" revocation certificate added
gpg: key FC736AA2: "testkey2" 1 new signature
gpg: Total number processed: 1
gpg: new signatures: 1
gpg: public key 9AD09F2D is 57303581 seconds newer than the signature
gpg: public key 0B12861B is 9237 seconds newer than the signature
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 26 signed: 13 trust: 0-, 0q, 0n, 0m, 0f, 26u
gpg: depth: 1 valid: 13 signed: 0 trust: 0-, 1q, 8n, 3m, 1f, 0u
gpg: next trustdb check due at 2012-09-11
# after
gpg --edit-key testkey2 shows:
gpg --edit-key testkey2
pub 1024R/FC736AA2 created: 2012-08-17 expires: 2012-08-19 usage: SC
trust: unknown validity: unknown
sub 1024R/3C5A6360 created: 2012-08-17 expires: 2012-08-19 usage: E
[ unknown] (1). testkey2
# Perhaps addrevoker sensitive is not.. supposed to reliably revoke keys
on other systems? Or is it a local revoke option? (if that was the case,
a revokekey in gpg --edit-key would suffice.. )
#hmm... wierd. and just to illustrate my point...
( on the test keyring )
gpg -ea -r testkey2
gpg: testkey2: skipped: unusable public key
gpg: [stdin]: encryption failed: unusable public key
( and on the primary keyringgpg -ea -r testkey2 -o testcipher.txt
gpg: 3C5A6360: There is no assurance this key belongs to the named user
pub 1024R/3C5A6360 2012-08-17 testkey2
Primary key fingerprint: AB08 CD0A E5A1 8DB8 CDBC 3DD2 95C6 26F3 FC73 6AA2
Subkey fingerprint: 851C BE30 B5B8 3617 2542 C31E 5B5E 5515 3C5A 6360
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N) y
.......
I have found a few other slight anomalies and results that raise more
questions on this matter and on others, my pubkey is attached I have
tested this myself now for the fourth time to verify that this behaviour
is not me making a mistake, as well as having three other linux and sec
folks also independently reproduce my little test, and they all came up
with similar results (their testkey2 was not reliably revoked, however
there are variations in the text gpg standard output) And to really make
sure I wasnt making any mistakes, I have also read the gnupg manual
several times, as well as the man page , and this anomaly is believed to
be bona-fide. I invite anyone and everyone who is interested to try
this yourself with the above commands (or with variations) , and share
your results. My pubkey is attached, feel free to email me directly if
you have any questions, concerns, or insights to share.
Thank you for your time
Btw, the checksums for my public key bzip are:
no.tar.bz2: MD5 = 92 24 98 62 B9 E7 01 41 F2 9F 92 89 16 19 9F D0
no.tar.bz2: SHA1 = AF34 35A5 0C14 74B2 2B9A 4CA9 D3BC 12C0 9273 F185
no.tar.bz2: RMD160 = 32FC 0DC6 FECF 7E37 D46C B682 3E83 5C1A 44B2 082F
no.tar.bz2: SHA224 = 0DB36929 5F8FDF73 5145E35E 3F364504 874F2BA2 C4FA398A
D2E88780
no.tar.bz2: SHA256 = D4F3253B D2FCAE6D BF760B35 B6A93F45 35DE83A0 561509D8
766F0DE9 B1C7849D
no.tar.bz2: SHA384 = 256FC5DF 7FE3C7A1 19AA38B7 073FE2C5 206C2700 5798B830
F925770A 987CCC89 660A9EB6 976C5623 EE4ADD7C 32E0C216
no.tar.bz2: SHA512 = C53E5E13 A26E2FC0 ED8CB17A 7B8ECEC0 CC00E5ED D0CE4E4A
171F1C9A CC3C14E9 E703691D 1138DB0C 9F41AF75 FFA70976
395740D4 AC829780 B873D56E 85FA9280
-----BEGIN PGP SIGNATURE-----
iF4EAREKAAYFAlAuZiYACgkQW09oVTHoH/dYuQEAxdabz5ZxFn7FjDnrtrl+ufGj
uZFcix0PoJ6Fq5Ae3pUBAOhWnurb7gQ7hBZZfWCYkVK4YE8ISjwGlk0Z3kF04q+2
=jj6S
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no.tar.bz2
Type: application/x-bzip
Size: 6294 bytes
Desc: not available
URL: </pipermail/attachments/20120817/5a592e5b/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x31E81FF7.asc
Type: application/pgp-keys
Size: 2797 bytes
Desc: not available
URL: </pipermail/attachments/20120817/5a592e5b/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120817/5a592e5b/attachment-0001.pgp>
More information about the Gnupg-devel
mailing list