Transcript on how to make secure keys using 4096 bit RSA from #debian-nyc. There is a summary first, and then the whole conversation.
# 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) <firstname.lastname@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 [~email@example.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
12:38 -!- dkg [~firstname.lastname@example.org] 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 [~email@example.com] 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) <firstname.lastname@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 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-22.214.171.124 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-126.96.36.199 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 [~email@example.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 [firstname.lastname@example.org] has joined #debian-nyc 14:55 -!- damog [~email@example.com] has quit [Ping timeout : 480 seconds] 14:57 -!- damog [~firstname.lastname@example.org] 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