[SATLUG] XCSSA Pre-GPG Keysigning Party "To-Do Steps" (if you want your key signed March 17th)

David Kowis dkowis at shlrm.org
Mon Mar 3 11:01:23 CST 2008


Quoting ed <horned0wl93 at gmail.com>:

> Hello;
>
> I have a few questions and problem:
>
> 1. Apparently, per GPG setup instructions, I'd need a separate GPG key
> for each email account?
> 2. I've tested the setup using one of my email accounts, and have saved
> the fingerprint as a screen shot, but don't know how to access/print it
> any other way. Suggestions?
>
http://www.gnupg.org/gph/en/manual.html

I recommend this document to follow for generating keys and such.
I also have some beef with the suggestions on the XCSSA site.  
Particularly with the age of the keys and the encryption algorithms.

According to http://www.gnupg.org/gph/en/manual.html#AEN526 :
"It is almost always the case that you will not want the master key to  
expire. There are two reasons why you may choose an expiration date.  
First, you may intend for the key to have a limited lifetime. For  
example, it is being used for an event such as a political campaign  
and will no longer be useful after the campaign is over. Another  
reason is that if you lose control of the key and do not have a  
revocation certificate with which to revoke the key, having an  
expiration date on the master key ensures that the key will eventually  
fall into disuse.

Changing encryption subkeys is straightforward but can be  
inconvenient. If you generate a new keypair with an expiration date on  
the subkey, that subkey will eventually expire. Shortly before the  
expiration you will add a new subkey and publish your updated public  
key. Once the subkey expires, those who wish to correspond with you  
must find your updated key since they will no longer be able to  
encrypt to the expired key. This may be inconvenient depending on how  
you distribute the key. Fortunately, however, no extra signatures are  
necessary since the new subkey will have been signed with your master  
signing key, which presumably has already been validated by your  
correspondents."

Basically, unless you want your signing key to expire, it shouldn't.  
That way you retain the signatures. However, you want your encryption  
key to expire so that it's no longer used. The main factor of  
encryption is how long the data is valid for. If it's extremely  
important, but isn't useful after a week, encryption that can't be  
brute-forced within a week (reasonably) is probably good enough.

Also I would reccomend using RSA encryption as opposed to El-Gamal. I  
think there might be another algorithm, but I can't remember at the  
moment. the 4096bit key length is good :)

Just my $0.02

>
> tweeks wrote:
>
> Hey all,
>> As promised, here is the list of steps that you MUST do NOW to   
>> prepare for the
>> XCSSA March 17th, 2008 GPG Keysigning Party:
>> 	http://xcssa.org/#STEPS
>> 	(permalink = http://xcssa.org/archives/XCSSA_2008-03-17.html#STEPS )
>>
>> Please follow steps 1-3 NOW to prepare for the keysigning party or you will
>> not be able to participate or get your key signed by the group!  :v(
>>
>> If anyone has any questions or concerns, please feel free to send them to me
>> (tweeks-junk2 at theweeks d0t 0rg) and I'll try to answer them and get you
>> taken care of in time.
>>
>> Take care, and we'll see you at the party!
>>
>> Tweeks
>> XCSSA President
>>
>



-- 
David Kowis
==================================================================
|       www.ronpaul2008.com      |    www.sourcemage.org         |
|      Ron Paul for President!   |   SourceMage GNU/Linux        |
==================================================================


More information about the SATLUG mailing list