A few newbie questions, I'am doing this right?
mailinglisten at hauke-laging.de
Thu Dec 13 02:21:06 CET 2012
Am Mi 12.12.2012, 19:28:18 schrieb Roy Sindre Norangshol:
> I'm trying to setup my gpg setup properly for the first time, and wondering
> if this setup seems fine:
"Best practice" is often subjective.
> Master keypair with only the «certificate» as it's only role, this master
> keypair I'll only use for:
> * signing someone else's key
> * creating a new subkey
> * revoking a subkey
I would add signing ability at any rate and (depending on the circumstances
perhaps) even encryption. This allows you to make very secure signatures. This
is very useful for a key policy document (--set-policy-url).
If you do not have another key another key which is more secure then your
mainkey allows you encrypt data more safely which from time to time can be
> as mentioned on debian's wiki and will be stored offline on my private
> encrypted usb thumbdrive and only used on my own secure equipment (fully
> encrypted laptop or home computer)
You can put your private mainkey on your website. A passphrase like
02NWL7YLKTa9uUhosA is harder than the key itself (at 2048 bit). Just never
enter the passphrase in an unsecure system. And don't forget ist. :-)
Full disk encryption does not make a system secure. Get a safe boot medium.
(And store it physically secure... ;-) )
> (planning to buy a cryptostick after new years)
Security is much better with a card reader which has a PIN pad.
> So I've created 3 seperate subkeys for each role:
> * sign (2y expire)
> * auth (2y expire)
> * encryption (never)
> I assume two year expire on sign and auth is good and requirements me to
> redo sign and auth subkeypairs every each year to «show I'am alive and
This can be shown by extending the expiration date of existing keys, too. One
argument for expiration dates is that they stop others from using your key if
you have lost the private (main) key. I use a time limit of one year.
> Encryption is set to never, if it gets compromised I'll have to
> reencrypt all my stuff that I want to keep safe anyway and wipe existing
> old copies.
This has nothing to do with the expiration date, does it?
> Encryption key I will only have at home, laptop and server
> stationed at my parents (used for mutt) which are all fully encrypted.
The real danger should be online attacks. I would not consider a system secure
which is used for WWW or email.
> I've attached two identities (roy.sindre at norangshol.no and my current
> identity at work.)
Is roy.sindre at norangshol.no a private address? In general I would not mix
private and business addresses within a key.
> I thought I could create two additional subkeys (sign and auth) for use at
> work for my work identity, in case these subkeys gets compromised I can
> easily revoke these two keys and create new ones to use at work
One more reason to create different mainkeys. Subkeys are not bound to UIDs.
Both subkeys and UIDs are bound to the mainkey. And what if someone wants to
send encrypted mail to your work account? I do not see any advantage in mixing
the IDs (and environments), just problems.
> Since I'm using subkeys I don't have to «redo» the web-of-trust/signing when
> renewing my subkeys, right?
Right. The WoT refers to mainkeys and UIDs only.
> Kinda want to properly setup this before attending any kind of signing
> parties. Thank you in advance!
Further recommendations for a "proper setup":
• add a UID without email (just your name and a comment; this will be valid
• configure a preferred keyserver (--default-keyserver-url)
• configure a policy URL (even if you write the real document later; --set-
• configure your cipher and digest preferences (--default-preference-list)
• don't make non-local (lsign) certifications before you have finished your
• If you create two keys then create your work key with your personal key as
• After key creation make small slips of paper with your name, email and
fingerprint and always have some with you, like
| Hauke Laging |
| hauke at laging.de |
| 7D82 FB9F D25A 2CE4 5241 |
| 6C37 BF4B 8EEF 1A57 1DF5 |
PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 572 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users