Transcript on how to make secure keys using 4096 bit RSA from #debian-nyc. There is a summary first, and then the whole conversation.

summary

# Add to ~/.gnupg/gpg.conf
12:44 < dkg> before you --gen-key
12:44 < dkg> add a default-preference-list option to ~/.gnupg/gpg.conf
12:45 < dkg> this will make it so that your new key starts off with good preferences
12:45 < dkg> so something like:
12:45 < dkg> echo "default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES BZIP2 ZLIB ZIP Uncompressed" >> ~/.gnupg/gpg.conf
# also add these to the conf
12:46 < MrBeige> ok, I also have the lines from your blog post there:
12:46 < MrBeige> personal-digest-preferences SHA256
12:46 < MrBeige> cert-digest-algo SHA256
# you can use SHA512 if you would like.

12:42 < dkg> anyway, i'd do gpg --gen-key
12:43 < dkg> and choose RSA (sign only)
12:43 < dkg> (you'll make an encryption-capable subkey later)
12:51 < MrBeige> so gpg --gen-key, rsa sign only, 4096

12:53 < dkg> i do recommend an expiration date on the master.
12:53 < dkg> i'd say 5 years for the master is good.

# You don't need a comment.  A comment might be, e.g., your company, "Debian Lenny Archive Signing Key", birthdate, ...
12:56 < dkg> MrBeige: right, comments are useful to indicate specifics about how
 you intend to use the key
12:56 < dkg> if you're planning to use the key as your own identity, that's sort
 of the default assumption
12:56 < dkg> so no comment is needed.
12:56 < dkg> but if you have an automatically-generated, signed APT archive, for
 example
12:56 < dkg> and you don't sign it by hand
12:57 < dkg> you might make a separate primary key for that archive
12:57 < dkg> and the associated UID would be "Foo bar (APT archive signing key)  <apt-archive@example.org>"

# look at 16:07 for info on how to use --list-packets to verify that your key is as expected

# Now add an encryption subkey
13:18 < dkg> sure, but real quick so you can get a useful key:
13:18 < dkg> you want to do:
13:18 < dkg> gpg --edit-key $KEYID
13:18 < dkg> addkey
13:18 < dkg> and tell it to create an encryption-capable RSA subkey
13:19 < MrBeige> "RSA (encrypt only)"
13:19 < dkg> yup.
13:19 < MrBeige> size 4096 for now still ?
13:19 < dkg> it's worked for me for a year now.
13:20 < MrBeige> 5 years again...
13:20 < dkg> yup, reasonable.


13:25 < MrBeige> if I do "showpref" asd see sha512 listed first, sha1 listed last, that's good, correct ?
13:25 < dkg> yup, that
13:25 < dkg> is good
13:27 -!- damog [~damog@cpe-72-225-236-31.nyc.res.rr.com] has joined #debian-nyc

13:34 < MrBeige> i'd like to remind people of the gpg-key2ps command if they did
n't know of it

whole conversation

12:38 -!- dkg [~dkg@lair.fifthhorseman.net] has joined #debian-nyc
12:39 < MrBeige> xjjk: --^
12:39 < dkg> hey folks
12:39 < MrBeige> ok, let the key-gen lesson begin!
12:39 < dkg> :p
12:39 < MrBeige> (heh)
12:40 < dkg> so the question MrBeige asked me was how to make a strong key that
would last for a long time.
12:40 < dkg> my key is 4096-bit RSA
12:40 < dkg> (as is my encrpytion subkey)
12:40 < dkg> this is the strongest key you'll probably want to make
12:40 -!- micah [~micah@micah.riseup.net] has joined #debian-nyc
12:40 < dkg> and i can't guarantee you it'll last 10 years, but should last 5 at
 least
12:41 < MrBeige> a question came up yesterday about if 4096 would be nocicably s
lower
12:41 < dkg> (in 5 years, i expect OpenPGPv5 to create a new format)
12:41 < MrBeige> micah: greetings
12:41 < dkg> 4096-bit is a bit slower, but i haven't characterized it empiricall
y
12:41 < dkg> it'd be cool if someone wanted to do that
12:41 < micah> every single signature on my key was done with SHA1, if I am doin
g this right
12:41 < dkg> might spur some optimizations.
12:41 < MrBeige> i've used 4096 bit for a while now
12:41 < micah> gpg --export 1cf2d62a | gpg --list-packets |grep 'digest algo' |g
rep -v 'subpkt' |cut -d, -f1
12:42 < dkg> one problem with 4096-bit RSA is that there is no external crypto h
ardware that i've seen that can handle a key that size.
12:42 < dkg> so if you want a smartcard for your key yer kinda stuck
12:42 < dkg> (of course, gpg doesn't seem to support most smartcards anyway, eve
n the ones that do 2048-bit RSA)
12:42 < dkg> anyway, i'd do gpg --gen-key
12:43 < dkg> and choose RSA (sign only)
12:43 < dkg> (you'll make an encryption-capable subkey later)
12:43 < dkg> but wait! 
12:43 < dkg> let me look up a note i got via e-mail...
12:43 < MrBeige> ok
12:44 < MrBeige> so selecting RSA (sign only), when you tell it akeysigs, it'll 
get the primary key, not just the subkey like DSA and Elgamal will...
12:44 < dkg> ah, the point was:
12:44 < dkg> before you --gen-key
12:44 < dkg> add a default-preference-list option to ~/.gnupg/gpg.conf
12:45 < dkg> this will make it so that your new key starts off with good prefere
nces
12:45 < dkg> so something like:
12:45 < dkg> echo "default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AE
S192 AES BZIP2 ZLIB ZIP Uncompressed" >> ~/.gnupg/gpg.conf
12:46 < dkg> and then gpg --gen-key
12:46 < MrBeige> ok, I also have the lines from your blog post there:
12:46 < MrBeige> personal-digest-preferences SHA256
12:46 < MrBeige> cert-digest-algo SHA256
12:46 < dkg> yup
12:46 < micah> i found two keys that are using digest algo MD5 ;)
12:46 < dkg> i should probably adjust the blog to talk about default-preference-
list
12:47 < dkg> micah: yeah.  i'm working on getting gpg to even be able to ignore 
MD5-based signatures.
12:47 < micah> that would be good
12:47 < dkg> it's not possible with the current implementation.
12:47 < MrBeige> maybe make a "gpg/pgp best practices page" and keep it updated?
  that would be very useful
12:47 < micah> dkg: clint has an old v3 key with md5 digest, but he doesn't use 
it
12:47 < dkg> MrBeige: that'd be great!  (not sure i want the responsibility)
12:47 < dkg> micah: clint should revoke that key if he doesn't use it.
12:48 < MrBeige> dkg: heh, I was hoping you'd take responsibility...
12:48 < dkg> :P
12:48 < MrBeige> or we can be super-secure and just make it a page on wiki.d.o
12:48 < dkg> i might yet, but i'm too busy to responsibly say yes now.
12:48 < dkg> wiki.d.o isn't a bad idea anyway.
12:48 < Hydroxide> dkg: so you recommend doing a 4096-bit RSA master key with no
 encryption or other subkeys, at least between now and tonight's event?
12:48 < MrBeige> ok, gpg --gen-key     choose RSA (sign only)
12:49 < Hydroxide> or 2048?
12:49 < dkg> Hydroxide: if you've got the cycles to burn on your computer, yes, 
i think 4096 is fine.
12:49 < dkg> my post recommends 2048 because that's the "standard" coming up.
12:49 < dkg> and i needed to make a concrete recommendation.
12:50 < Hydroxide> dkg: well, I can always make subkeys to use on less powerful 
computers if I need to, right?
12:50 < micah> i'm going 4096 and sha512 ;)
12:50 < dkg> there's an argument that says "if you don't really treat your keys 
careefully, 4096-bit keys implies a false level of security."
12:50 < dkg> Hydroxide: yes, that's right.
12:50 < MrBeige> how about: if you plan on smartcards, etc, use 2048, otherwise 
4096 unless you are lacking cpu cycles ?
12:50 < Hydroxide> dkg: as per what micah said, is there a reason not to use sha
512 as the default?
12:50 < Hydroxide> MrBeige: see what I said. subkeys can be made that are less p
owerful
12:50 < dkg> Hydroxide: again, data size and computational cost.
12:50 < dkg> MrBeige: i think Hydroxide is on to something
12:51 < dkg> how about: make your primary key 4096-bit RSA
12:51 < MrBeige> dkg: yes
12:51 < dkg> if you want to use smartcards, generate subkeys for them
12:51 < MrBeige> ok
12:51 < MrBeige> I like this idea
12:51 < dkg> this assumes people are really taking their keys seriously.
12:51 < MrBeige> so gpg --gen-key, rsa sign only, 4096
12:51 < Hydroxide> dkg: also, I have an openpgp smartcard, which of course only 
supports 1024-bit RSA but severely limits the number of attempts you can make to
 crack the PIN before it's locked
12:52 < Hydroxide> dkg: and does support subkeys
12:52 < Hydroxide> dkg: is that still reasonable to use, as a subkey?
12:52 < MrBeige> dkg: i'm also assuming that once there's an attack on a 2048 si
ze key, then 4096 won't be secure for much longer anyway... do you think ?
12:52 < dkg> Hydroxide: i think so, as long as you rotate the subkey regularly.
12:52 < micah> Hydroxide: there could be incompatability problems yet undiscover
ed
12:52 < Hydroxide> dkg: do you recommend an expiration date on the master key? p
robably no on the master, yes on the subs?
12:53 < dkg> don't expect data that's encrypted against RSA-1024 to stay private
 against a determined and well-funded attacker for > 1 year, is what i'm hearing
 roughly.
12:53 < dkg> i do recommend an expiration date on the master.
12:53 < dkg> i'd say 5 years for the master is good.
12:53 < Hydroxide> micah: with sha512?
12:53 < dkg> you can always extend the expiration date 
12:53 < Hydroxide> dkg: sure...
12:53 < dkg> and having one initially published keeps you honest about maintaini
ng the key.
12:53 < Hydroxide> yeah
12:54 < micah> Hydroxide: certainly a significantly small set of people have use
d it, so the liklihood of uncovering corner-cases is much smaller
12:54 < Hydroxide> micah: s/smaller/higher/ ?
12:54 < micah> err, yes
12:54 < Hydroxide> true.
12:54 < MrBeige> should I have a comment on the key?
12:54 < micah> actually smaller is what I meant :)
12:55 < MrBeige> I can't think I need a comment right now
12:55 < dkg> basically: we're in somewhat untrodden ground
12:55 < micah> since there is a smaller subset of people who have used SHA512, t
here is going to be a smaller set of incompatability issues that have been teste
d
12:55 < dkg> which makes your chances of running into them yourself as the first
 victim higher.
12:56 < dkg> MrBeige: right, comments are useful to indicate specifics about how
 you intend to use the key
12:56 < dkg> if you're planning to use the key as your own identity, that's sort
 of the default assumption
12:56 < dkg> so no comment is needed.
12:56 < MrBeige> ok, right .... that's my use case
12:56 < dkg> but if you have an automatically-generated, signed APT archive, for
 example
12:56 < dkg> and you don't sign it by hand
12:57 < dkg> you might make a separate primary key for that archive
12:57  * xjjk reads the backlog
12:57 < MrBeige> ok, 4096, rsa sign only, is what we agree on ?
12:57 < xjjk> dkg: thanks for the info
12:57 < dkg> and the associated UID would be "Foo bar (APT archive signing key) 
<apt-archive@example.org>"
12:57 < Hydroxide> with sha256 preference
12:57 < dkg> Hydroxide: i'm using SHA512
12:57 < dkg> but i recommended SHA256 to help people avoid trouble
12:58 < dkg> if yer up for trying the stronger hash (and reporting problems so w
e can fix them)
12:58 < dkg> and have cycles to spare for the longer computations
12:58 < Hydroxide> dkg: well, if I'm using all new software that supports sha512
, will there be a reason not to use it as far as problems on the other end?
12:58 < dkg> then SHA512 is not unreasonable.
12:58 < Hydroxide> (e.g. correspondents)
12:58 < dkg> Hydroxide: right, that's the problem
12:58 < dkg> this is a networked protocol
12:58 < Hydroxide> yeah
12:58 < dkg> and we can't guarantee who yer other party is
12:58 < dkg> or what tool they have
12:59 < dkg> i'm planning on flushing out folks who can't deal with SHA512 mysel
f
12:59 < xjjk> dkg: would you happen to know off the top of your head, does 4096-
bit key/SHA512 work well enough with PGP?
12:59 < dkg> but that might cause me trouble.
12:59 < dkg> the latest version of PGP, yes (according to their web site)
12:59 < dkg> (i haven't run the software)
12:59 < Hydroxide> dkg: so the number of people who could verify SHA512 signatur
es is significantly lower than the number of people who can verify SHA256 signat
ures?
12:59 < xjjk> I'm only concerned about GnuPG and PGP
12:59 < dkg> i don't know how far back you have to go to get a version of PGP th
at doesn't support it.
12:59 < MrBeige> how do I set sha256?  is that the personal-digest-preferences a
nd cert-digest-algo in gpg.conf ?
12:59 < xjjk> almost everyone I correspond with using OpenPGP stuff is using Gnu
PG anyway
12:59 < dkg> Hydroxide: i don't know about "significantly"
13:00 < dkg> xjjk: right, and those folks have very little difficulty upgrading.
13:00 < dkg> PGP makes you buy the newer version, fwict, which is a stumbling bl
ock for some.
13:00 < Hydroxide> dkg: well, also, this is just a preference in my own .gnupg/g
nupg.conf that I can easily change without affecting how my key appears on keyse
rvers, right? i.e. it's just what I choose to use for each new sig?
13:00 < dkg> Hydroxide: correct
13:00 < dkg> MrBeige: it's both personal-digest-preferences and cert-digest-algo
13:00 < Hydroxide> dkg: and I can default to sha512 and use sha256 if anyone has
 problems with my sigs?
13:01 < Hydroxide> (for specific cases)
13:01 < dkg> right, you can re-send them if you manually tweak things
13:01 < Hydroxide> sure.
13:01 < dkg> but i don't know of a way to set per-recipient digest rules
13:01 < MrBeige> ok
13:01 < Hydroxide> dkg: but it can be per-gpg-invocation, right?
13:01 < MrBeige> so right now, do I need to decide while generating my keys ?
13:01 < dkg> Hydroxide: yes.
13:02 < Hydroxide> dkg: so I could tell mutt "use these extra args to gpg if any
 of these recipients are in the email"
13:02 < MrBeige> should I hit enter now to start generating the keys ?
13:02 < dkg> MrBeige: i don't think you need to decide anything
13:02 < dkg> i think you can start generating the key.
13:02 < dkg> Hydroxide: your mutt-fu exceeds mine.
13:03 < MrBeige> ok, it's going
13:03 < dkg> awelfjawgjq34gijawgelaksjglajkweglakjwg
13:03 < MrBeige> ok, primary key generated
13:03 < dkg> ^^ that's me banging on the kbd for entropy ;)
13:04 < MrBeige> once everyone is ready, we can go to the next step
13:04 < Hydroxide> dkg: :) the gpg command to be used can be overridden in a sen
d-hook in .muttrc based on recipients (incl. to, bcc, and cc)
13:04 < dkg> Hydroxide: awesome.
13:05 < dkg> just so y'all know, i'm using icedove + enigmail as my MUA
13:05 < Hydroxide> dkg, micah: y'all should stick around this channel generally.
 I get an overdose of MrColorPeople and an underdose of the rest of the NYC crow
d :)
13:05 < Hydroxide> ah
13:05 < dkg> my geek cred is in tatters by that admission
13:05 < Hydroxide> 'sokay :)
13:05 < dkg> but i'm trying to use tools that i can actually recommend to real h
umans ;)
13:05 < dkg> it's painful sometimes.
13:06 < dkg> ok, so when the new key is generated, we've got a few choices
13:06 < dkg> do you want to geek out and look at the key and make sure everythin
g is in shape?
13:06 < dkg> or do you want to assume it is, and make the key actually useful?
13:07 < Hydroxide> dkg: why are those mutually exclusive?
13:07 < MrBeige> if you can teach us how to read teh listing, that would be help
ful
13:07 < dkg> they're not
13:07 < dkg> i just didn't want to digress if y'all want to plow ahead.
13:07 < dkg> i like the digressions myself ;)
13:07 < dkg> so you can see all the details like this:
13:07 < Hydroxide> I think we're fine with doing the digressions and then doing 
the useful stuff later.
13:08 < dkg> gpg --export $GPGID | gpg --list-packets | $PAGER
13:08 < dkg> (assuming you have $PAGER defined to something reasonable)
13:08 < dkg> you'll see a few pieces
13:09 < dkg> the first bit is the pubkey packet itself.
13:09 < dkg> it should be algo 1 -- that's RSA
13:09 < dkg> the timestamps you see are all seconds since the unix epoch
13:09 < dkg> pkey[0] is the RSA modulus
13:09 < dkg> so you can verify that it's the size you want.
13:09 < MrBeige> cool
13:10 < dkg> note that the primary key itself doesn't have an expiration in it
13:10 < dkg> next comes (usually) the User ID packet
13:10 < dkg> that's just a UTF-8 string.
13:10 < dkg> after that is the signature packet.
13:10 < MrBeige> ok
13:10 < dkg> tis is the self-signature that binds the uid to the primary key.
13:10 < dkg> the signature is made *by* the primary key
13:11 < dkg> and it contains all the metadata that you expect to be associated w
ith the primary key
13:11 < dkg> as well as the user ID itself.
13:11 < MrBeige> ok
13:11 < dkg> so, walking through:
13:11 < dkg> version 4 is the OpenPGP version
13:11 < dkg> sigclass 0x13 means "i really really really checked"
13:11 < dkg> gpg defaults to 0x13 for self-signatures
13:12 < dkg> and 0x10 ("no level of checking specified") for regular certificati
ons.
13:12 < dkg> (btw, i use the term "certifications" to mean "OpenPGP signatures b
inding keys to UIDs"
13:13 < dkg> this is by way of contrast to general OpenPGP signatures, whcih can
 cover regular data or e-mails, etc)
13:13 < dkg> ok, so next in the signature packet:
13:13 < dkg> digest algo is the digest used to create the signature itself.
13:13 < dkg> you can translate the numbers to algorithms at:
13:13 < MrBeige> I see digest algo 8
13:13 < dkg> http://tools.ietf.org/html/rfc4880#section-9.4
13:14 < MrBeige> sha256 it is
13:14 < dkg> so each subpacket contains some metadata about the key/uid binding
13:15 < dkg> you can look those numbers up at:
13:15 < dkg> http://tools.ietf.org/html/rfc4880#section-5.2.3.1
13:15  * Hydroxide has been doing work stuff instead of following this but will 
definitely read scrollback when I get around to generating the key, probably lat
er in the workday
13:15 < dkg> but you can guess for most of them
13:15 < MrBeige> yeah
13:15 < dkg> key flags is particularly interesting.
13:15 < dkg> it's a bitfield
13:16 < dkg> http://tools.ietf.org/html/rfc4880#section-5.2.3.21
13:16 < dkg> so i you have 0x03, it means
13:16 < dkg> 0x01 - ok for certifications + 
13:16 < dkg> 0x02 - ok for signing data
13:17  * MrBeige is starting to run short on time...
13:17 < dkg> (this is why i asked about the digressions)
13:18 < MrBeige> yeah... I didn't expect it to be so long
13:18 < MrBeige> perhaps this would be good for tonight
13:18 < dkg> sure, but real quick so you can get a useful key:
13:18 < dkg> you want to do:
13:18 < dkg> gpg --edit-key $KEYID
13:18 < dkg> addkey
13:18 < dkg> and tell it to create an encryption-capable RSA subkey
13:19 < MrBeige> "RSA (encrypt only)"
13:19 < dkg> yup.
13:19 < MrBeige> size 4096 for now still ?
13:19 < dkg> it's worked for me for a year now.
13:20 < MrBeige> 5 years again...
13:20 < dkg> yup, reasonable.
13:21 < MrBeige> done
13:21 < dkg> micah:  i note that your new key publishes your digest preferences 
as 2 8 3
13:21 < dkg> pref-hash-algos, that is, in --list-packets format
13:21 < dkg> that's SHA1 SHA256 RIPEMD160, iirc
13:21 < micah> dkg: hm, perhaps I needed to do the setpref?
13:21 < dkg> right.
13:21 < micah> i negelected, will do that now, thanks!
13:22 < dkg> MrBeige: you should be good to go.
13:22 < MrBeige> dkg: excellent, i'll have slips tonight
13:22 < dkg> great!
13:22 < micah> i'm fighting with latex
13:23 < micah> dkg: thanks for noticing that! I got distracted by a weird latex 
bug and forgot that step
13:23 < dkg> np
13:23 < dkg> i just don't want to start dreaming in gpg --list-packets mode.
13:25 < MrBeige> if I do "showpref" asd see sha512 listed first, sha1 listed last, that's good, correct ?
13:25 < dkg> yup, that
13:25 < dkg> is good
13:27 -!- damog [~damog@cpe-72-225-236-31.nyc.res.rr.com] has joined #debian-nyc
13:27 < dkg> hi damog
13:27 < dkg> thanks for organizing the keysigning for tonight.
13:34 < MrBeige> i'd like to remind people of the gpg-key2ps command if they did
n't know of it
14:10 < damog> hey dkg 
14:10 < damog> dkg: how is it going
14:10 < damog> dkg: no prob
14:48 -!- stew [1413@stew.user.oftc.net] has joined #debian-nyc
14:55 -!- damog [~damog@cpe-72-225-236-31.nyc.res.rr.com] has quit [Ping timeout
: 480 seconds]
14:57 -!- damog [~damog@cpe-72-225-236-31.nyc.res.rr.com] has joined #debian-nyc
15:39 < Hydroxide> stew: hi there
15:39 < Hydroxide> stew: welcome back :)
15:39 < stew> aloha
15:41 < dkg> MrBeige: gpg-key2ps is nice!  but it truncates long UIDs (at least 
it does for me)
15:42 < Hydroxide> I may not get to generate the key before I head to pacific st
andard, so I may just have to write the relevant info on the back of my ($employ
er-provided) business cards

GPGKeys (last edited 2009-07-22 19:39:43 by RichardDarst)