On Wednesday 12 May 2010 02:49:43 Grant Olson wrote: > So now Alice doesn't even realize that Bob is still sending sensitive > info on a potentially compromised key. > > You might be able to put a weird exception where gpg checks to see if > any of your private keys that are revoked are one of the keys that gpg > has encrypted to, but that would behave completely differently than > having a revoked key from random user X on the keyring. > > And if you did, I'm not sure how applications like Enigmail would end up > handling the special case.
Here are some tests how gnupg currently handles revoked subkeys. As you can
see programs like Enigmail would notice if someone is still sending to a
revoked subkey. If programs now recognize mails are being encrypted to revoked
subkeys they would notice with a encrypt-to-all-not-revoked-encryption-subkeys
behavior.
Alice has a primary key with two encryption subkeys:
pub 4096R/637AD7FA created: 2010-05-12 expires: never usage: C
trust: ultimate validity: ultimate
sub 4096R/97E46ACF created: 2010-05-12 revoked: 2010-05-12 usage: E
sub 4096R/5855A984 created: 2010-05-12 revoked: 2010-05-12 usage: E
[ultimate] (1). Goo Gle <[email protected]>
Three messages were send to Alice (last would be encrypt-to-all):
10.asc encrypted to subkey 97E46ACF
01.asc encrypted to subkey 5855A984
11.asc encrypted to subkeys 97E46ACF 5855A984
Alice decrypts the message if no key is revoked:
gpg2 --decrypt -o /dev/null < 10.asc
gpg: encrypted with 4096-bit RSA key, ID 97E46ACF, created 2010-05-12
"Goo Gle <[email protected]>"
gpg2 --decrypt -o /dev/null < 01.asc
gpg: encrypted with 4096-bit RSA key, ID 5855A984, created 2010-05-12
"Goo Gle <[email protected]>"
gpg2 --decrypt -o /dev/null < 11.asc
gpg: encrypted with 4096-bit RSA key, ID 5855A984, created 2010-05-12
"Goo Gle <[email protected]>"
gpg: encrypted with 4096-bit RSA key, ID 97E46ACF, created 2010-05-12
"Goo Gle <[email protected]>"
Alice revokes a subkey (first or last) (example: 97E46ACF):
gpg2 --decrypt -o /dev/null < 11.asc
gpg: NOTE: key has been revoked
gpg: encrypted with 4096-bit RSA key, ID 5855A984, created 2010-05-12
"Goo Gle <[email protected]>"
gpg: encrypted with 4096-bit RSA key, ID 97E46ACF, created 2010-05-12
"Goo Gle <[email protected]>"
Gnupg informs Alice the message has been encrypted with a revoked key if Bob
didn't refresh his keyring and his gnupg continues to do a encrypt-to-all. She
could inform Bob to refresh his keyring. The same goes for other combinations
of key revocation.
If Alice revoked her last key (5855A984) and Bob's (unrefreshed) gnupg would
encrypt a message to the last key as it currently does it would look like
this:
gpg2 --decrypt -o /dev/null < 01.asc
gpg: NOTE: key has been revoked
gpg: encrypted with 4096-bit RSA key, ID 5855A984, created 2010-05-12
"Goo Gle <[email protected]>"
There is no different on Alice side if gnupg would do a encrypt-to-all-not-
revoked-encryption-subkeys.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
