[ale] hosed gpg key

[Jeremy T. Bouse]

On 12/12/2011 07:02 PM, Michael B. Trausch wrote:
> On 12/12/2011 05:20 PM, Aaron Ruscetta wrote:
>> Since I've pretty well hit all the likely alternate forms of the pass
>> phrase at this point, I'm thinking there must be something else
>> going on here. Is there a limit to pass phrase length or something?
>> Is there an undeclared timeout on multiple attempts?
> 
> There is no limit to the passphrase that I am aware of.  My current one
> is in excess of 70 characters and it works, with gpg2 at least.  I'm not
> sure if any of it works differently for gpg1.
> 
	Likewise I'm not aware of any passphrase length limitations.

>> If I'm unable to re-discover the pass phrase, how do I just go
>> about trashing this key and removing it from the keyring and such?
>> Would anyone in the key ring be willing to sign a new alternative
>> if I were to generate it and post it to BigLumber?
> 

	I don't know about others, so I'll speak only for myself. If you have
multiple keys and I've already verified your ID and signed your key,
then if you generate a new key and send me a signed (or encrypted)
message with the fingerprint of the new key signed by the key I've
signed and is still valid (ie- not revoked) AND your new key is also
signed by the key you're sending the signed request with. Then I will
verify the signature of the request, verify the signature chain on the
new key along with fingerprint and if everything matches will sign the
key. Again as per my usage of caff I'd send the signed key back
encrypted to the email on the UID thus again verifing email address and
possession of the private key file. This is the same method mentioned by
others regarding transitioning keys [1]. When transitioning I'll sign
the new key with the old keys but not the other way around. The only
sigs initially on the new key will be those of my old keys and the
self-signed by the new key itself.

	I'll actually be going through this when I get the OpenPGP cards and
generate new RSA keys for use with them. In that case my new RSA key
will be a 4096 bit RSA key and then I'll have 2048 bit subkeys on the card.

> Question:  Did you generate a revocation certificate when you created
> your new stronger key?  If so, import the revocation certificate and
> then re-upload the public key to the keyservers so that your revocation
> will reach the whole keyserver network.  If not... well, there is no way
> to revoke the key, and if I am understanding my gpg2 output correctly,
> your key doesn't expire.
> 
	Yes, again this is why generation of the revocation certificate when
you create a new key and before even uploading it to the keyservers for
use is a good idea. My new key generation routine includes doing this
for just this very reason.

> Since we all have certified both of your keys, I'd have no problem
> signing your new key if you send a signed message to the ML with your
> other key that you still control, and in that message put the key ID for
> the new key that you need signed.  At the very least, that will prove
> sufficient for me.
> 
> When you create your new key, I'd recommend that you make it expire at
> some point.  It doesn't have to be 1 year; I tell people to set the
> expiration for somewhere between 5 and 15 years.  The expiration
> shouldn't be too frequent, because that increases the burden on yourself
> (maintaining your key) and everyone else (because they have to re-sign
> your key).  The only thing the expiration really guards against is the
> loss of both a key and its corresponding revocation certificate.  Also,
> generate a revocation certificate.  I generate mine and print it on a
> piece of paper which I then put in a safe place.
>

	I don't generate an expiration on my primary keys, though I do so
because I don't use them for daily usage and instead use sub-keys which
I revoke with regular frequency. The main reason I don't set an
expiration on the primary key is because it holds all your signatures
and if you forget about your expiration date and let it pass you will
find yourself having a hard time changing the expiration date after the
fact.

	I also keep the revocation certificate on a CD and print it out with
both stored securely off-line. Along with utilizing the means you
mention below that I'll respond to.

> A side note:  Jeremy mentioned after the social a piece of software that
> can take an input file and split it into any x number of chunks, where
> any y of those are required to reconstitute the original file.  That way
> one could, for example, generate a revocation certificate, make 5 chunks
> where any 4 are required to recreate the revocation certificate, and
> give those 5 chunks to friends.  Alas, I forgot to write down the name
> of the software, so I can't remember what it was.
> 

	What I was talking about was gfshare (Shamir Secret Sharing) that will
slice a file into M parts that requires N of those to reconstitute the
whole file. On Debian & Ubuntu systems it's installed with the
libgfshare-bin package, I'm not sure about other distros but I'm sure
it's available. I've usually split my private key and revocation
certificates into 7 parts and require 5 parts to restore it. I then send
1 part to a friend I trust on the West coast, another to a friend here
on the East coast, I keep one part off-line for myself and the other
parts stored on-line in private locations on remote storage such as AWS
S3, ExaVault and my various hosted accounts.

	Regards,
	Jeremy

1. http://www.debian-administration.org/users/dkg/weblog/48

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20111212/a91af7a2/attachment.bin