[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