Mailing List Archive

RFC: Gentoo GPG key policies
Hi all,

I've been asked a couple of times in IRC and other mediums, about what
GPG key settings etc to use. I would not not call these final yet, but should
be fairly close to final.

This was originally intended to be part of the tree-signing GLEP series, but
was in one of the unpublished ones (GLEPxx+3 in the references). I guess if
there are no major objections to the below, I'll finalize them into the GLEP.
This will replace the conflicting information in:
http://devmanual.gentoo.org/general-concepts/manifest/index.html
http://www.gentoo.org/doc/en/gnupg-user.xml

The following is based on:
- NIST SP 800-57 recommendations
- Debian GPG documentation
- RiseUp.net OpenPGP best practices.

Bare minimum requirements:
--------------------------
1. SHA2-series output digest (SHA1 digests internally permitted).
"personal-digest-preferences SHA256"
2. root key & signing subkey of EITHER:
2.1. DSA, 1024 or 2048 bits
2.2. RSA, >=2048 bits
3. Key expiry: 5 years.

Recommendations:
----------------
1. SHA2-series digest on output & certifications:
"personal-digest-preferences SHA256"
"cert-digest-algo SHA256"
2. Root key type of RSA, 4096 bits
2.1. This may require creating an entirely new key.
3. Dedicated Gentoo signing subkey of EITHER:
3.1. DSA 2048 bits
3.2. RSA 4096 bits
4. Key expiry:
4.1. Root key: 3 year max.
4.2. Gentoo subkey: 1 year max.
5. Create a revocation certificate & store it hardcopy offsite securely
(it's about ~300 bytes).
6. Encrypted backup of your secret keys.
7. In your gpg.conf:
# include an unambiguous indicator of which key made a signature:
# (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g

Notes/FAQ:
----------
1. "Ok, so how do I follow this?"
http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/
http://keyring.debian.org/creating-key.html
2. "How can I be really sure/paranoid enough?"
https://we.riseup.net/riseuplabs+paow/openpgp-best-practices
3. Every 3-6 months, and/or before key expiry and major keysigning
events, you should update your key expiry date with the 'expire'
command (remember to do all subkeys). Put it on your calendar!
4. If you intend to sign on a slow alternative-arch, you may find adding
a DSA1024 subkey significantly speeds up the signing.
5. Can you give me a full ~/.gnupg/gpg.conf file?
===
# -- robbat2's recommendations:
keyserver pool.sks-keyservers.net
emit-version
default-recipient-self
# -- All of the below portion from the RiseUp.net OpenPGP best practices, and
# -- many of them are also in the Debian GPG documentation.
# when outputting certificates, view user IDs distinctly from keys:
fixed-list-mode
# long keyids are more collision-resistant than short keyids (it's trivial to make a key with any desired short keyid)
keyid-format 0xlong
# when multiple digests are supported by all recipients, choose the strongest one:
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
# preferences chosen for new keys should prioritize stronger algorithms:
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
# If you use a graphical environment (and even if you don't) you should be using an agent:
# (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64)
use-agent
# You should always know at a glance which User IDs gpg thinks are legitimately bound to the keys in your keyring:
verify-options show-uid-validity
list-options show-uid-validity
# include an unambiguous indicator of which key made a signature:
# (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
# when making an OpenPGP certification, use a stronger digest than the default SHA1:
cert-digest-algo SHA256
===

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Mon, Feb 18, 2013 at 11:27:46PM +0000, Robin H. Johnson wrote:
> 2. root key & signing subkey of EITHER:
> 2.1. DSA, 1024 or 2048 bits
> 2.2. RSA, >=2048 bits
> 3. Key expiry: 5 years.
Clarification on reason:
These key sizes are the largest supported by many smartcards.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: RFC: Gentoo GPG key policies [ In reply to ]
It may be advantageous to have a gentoo wrapper script that calls GPG
with recommended settings to make some tasks easier,

> gentoo-gpg-create --recommended
> EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF

and gentoo-gpg-rotation would make a templated key-expiry document ,
edited in $EDITOR, and then cross-signed

I may even take a stab at this myself once the GLEP is finalised, just
curious what people think.





--
Kent

perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Tue, Feb 19, 2013 at 04:36:08PM +1300, Kent Fredric wrote:
> It may be advantageous to have a gentoo wrapper script that calls GPG
> with recommended settings to make some tasks easier,
> > gentoo-gpg-create --recommended
> > EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF
> and gentoo-gpg-rotation would make a templated key-expiry document ,
> edited in $EDITOR, and then cross-signed
The key rotation as described in RiseUp best practices should be a very
rare occurrence. Each dev is going to run it at most once.

However, both the creation helper and an expiry update helper would be
useful.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Tue, 19 Feb 2013 16:36:08 +1300
Kent Fredric <kentfredric@gmail.com> wrote:

> It may be advantageous to have a gentoo wrapper script that calls GPG
> with recommended settings to make some tasks easier,
>
> > gentoo-gpg-create --recommended
> > EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF
>
> and gentoo-gpg-rotation would make a templated key-expiry document ,
> edited in $EDITOR, and then cross-signed
>
> I may even take a stab at this myself once the GLEP is finalised, just
> curious what people think.

I'd use it.


--
gcc-porting
toolchain, wxwidgets learn a language baby, it's that kind of place
@ gentoo.org where low card is hunger and high card is taste
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Tue, 2013-02-19 at 04:09 +0000, Robin H. Johnson wrote:
> On Tue, Feb 19, 2013 at 04:36:08PM +1300, Kent Fredric wrote:
> > It may be advantageous to have a gentoo wrapper script that calls GPG
> > with recommended settings to make some tasks easier,
> > > gentoo-gpg-create --recommended
> > > EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF
> > and gentoo-gpg-rotation would make a templated key-expiry document ,
> > edited in $EDITOR, and then cross-signed
> The key rotation as described in RiseUp best practices should be a very
> rare occurrence. Each dev is going to run it at most once.
>
> However, both the creation helper and an expiry update helper would be
> useful.
>

It can be done as part of gkeys from the gentoo-keys project I've
started which will be used to manage gpg keys for validating git
commits, release media, layman's repositories.xml list, etc...

I welcome help in coding it.

http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-keys.git;a=summary
http://wiki.gentoo.org/wiki/Project:Gentoo-keys

Sadly, I got sidetracked, so haven't gotten much done lately. But am
getting back to it again now.
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Mon, Feb 18, 2013 at 11:27:46PM +0000, Robin H. Johnson wrote:
> Bare minimum requirements:
> --------------------------
[...]
> 3. Key expiry: 5 years.

I am assuming we are requiring a maximum of 5 years for key expiry. We
might want to make it explicit. On first reading, it sounded like key
expiry >= 5 years as a bare minimum.

Thanks for the write-up.

--
Eray Aslan <eras@gentoo.org>
Re: RFC: Gentoo GPG key policies [ In reply to ]
> The key rotation as described in RiseUp best practices should be a very
> rare occurrence. Each dev is going to run it at most once.
>

Some material I read recommended doing a key rotation every 6 months,
which I did for a while until it got tiresome to perform the rotation.

I believe the rationale behind it was basically, the longer you use a
key, and the more data you produce signed by a key, the more leverage
an attacker has against you to compromise the key.

But I have no idea if that is really relevant or not.

--
Kent

perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Mon, Feb 18, 2013 at 11:38 PM, Kent Fredric <kentfredric@gmail.com> wrote:
>> The key rotation as described in RiseUp best practices should be a very
>> rare occurrence. Each dev is going to run it at most once.
>>
>
> Some material I read recommended doing a key rotation every 6 months,
> which I did for a while until it got tiresome to perform the rotation.

It turns out that real security is very inconvenient ;)

>
> I believe the rationale behind it was basically, the longer you use a
> key, and the more data you produce signed by a key, the more leverage
> an attacker has against you to compromise the key.
>
> But I have no idea if that is really relevant or not.

Trust is not really conferred by 'how much you have signed with the
key.' It is conferred by 'how many people trust your key.' It is
unclear to me how difficult this is to calculate in practice for an
attacker.

You rotate keys nominally because during routine key handling, your
key (unless it is stored in a smartcard) is exposed to risk during use
(the key material is mlocked in memory, or they can chat with your
gpg-agent to sign content, or try to steal the key material, or steal
the passphrase, and so forth.) If someone got your key, they can only
sign data with it for $INTERVAL until it expires and you generate a
new key. The attacker has no incentive to renew the key for you,
because that would expose him, as he has to publish the renewal. All
of this is similar in scope to changing your password every $INTERVAL,
which is standard security practice.

Generally speaking if the attacker is running code as you, or as root,
on the machine that you are signing content on, you are already
screwed. If the attacker has persistent access to your machine,
generating a new key does not help at all (he will get that one too.)
A common guard against this is simply to perform host attestation. I
don't think that is in scope for Gentoo though :)

-A

>
> --
> Kent
>
> perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
> 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
>
> http://kent-fredric.fox.geek.nz
>
Re: RFC: Gentoo GPG key policies [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just some quick thoughts on this:

> 2. root key & signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits
> 2.2. RSA, >=2048 bits

I don't really agree. From your own link
(https://we.riseup.net/riseuplabs+paow/openpgp-best-practices#dont-use-pgp-mit-edu):

"Many people still have 1024-bit DSA keys. You really should consider
transitioning to a stronger bit-length and hashing algo. This size is
known now to be within Well Funded Organizations’ ability to break.
Also the hashing algo is showing its age."

Some more opinions from different studies: keylength.com.

1024 DSA keys seem pretty short to me. Surely it might be inconvenient
for some (2-3? please write a mail here!) people with smart cards. But
then again, especially people going through the hell of using a
physical token would understand the need for decent crypto. ;)

I think key rotation is overdoing it and pretty annoying. Better use a
non-annoying, long key from the start?

> 4. If you intend to sign on a slow alternative-arch, you may find
> adding a DSA1024 subkey significantly speeds up the signing.

How slow is that actually? Does it make signing very inconvenient?
Maybe someone with a slow machine can write about performance and the
"annoyence-factor"... ;)

Best regards,

Craig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEkGjEACgkQuiczp+KMe7SkWACgrioKjFkuPwJOxUCmhGKcC4Ib
uyQAmwUfM7u3x6sD1rmQJrEjjUu7C6ok
=OyqH
-----END PGP SIGNATURE-----
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Wed, Feb 20, 2013 at 01:34:57AM +0100, Stefan Behte wrote:
> > 2. root key & signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits
> > 2.2. RSA, >=2048 bits
...
> 1024 DSA keys seem pretty short to me. Surely it might be inconvenient
> for some (2-3? please write a mail here!) people with smart cards. But
> then again, especially people going through the hell of using a
> physical token would understand the need for decent crypto. ;)
A physical token defends against a different method of attack than a
longer key. Simply having a longer key isn't going to help you if store
the key on the laptop and it gets compromised: presuming the attacker
extracts your secret key and passphrase). In such a case, the smartcard
at worst limits him to doing some number of signatures only, or even
better if the reader has a hardwired pinpad, he gets nowhere at all.

Also, if there is a Well-Funded-Organization attacking Gentoo, there are
MUCH more effective ways for them to compromise us. Any perceived gains
in that field from requiring DSA2048 and blocking DSA1024 should be
examined very closely.

> I think key rotation is overdoing it and pretty annoying. Better use a
> non-annoying, long key from the start?
NOWHERE did I require key rotation. Why do you think that I did?
My own key is more than a decade old. I need to see about replacing it
soon, but I've been trying to hold out for the OpenPGP standard to have
ECC included, before I repeat getting my extremely large web-of-trust.

> > 4. If you intend to sign on a slow alternative-arch, you may find
> > adding a DSA1024 subkey significantly speeds up the signing.
> How slow is that actually? Does it make signing very inconvenient?
> Maybe someone with a slow machine can write about performance and the
> "annoyence-factor"... ;)
Some benchmark results from hake.hppa.dev.g.o, 552Mhz PA-RISC box.

Average of running clearsign ~100 times, for various signature types.
The gpg.conf was set as in my initial post.

DSA1024 0.059830s
DSA2048 0.158800s
DSA3072 0.274850s
RSA1024 0.060020s
RSA2048 0.173070s
RSA4096 0.896480s

For reasons of time, while I wanted to create the keys on the host as
well for timing, I gave up after the first key, DSA1024, took more than
3 minutes (I did ensure that /dev/random was not the blocking factor).

If somebody from MIPS or m68k wants to chime in, I think they probably
have the slowest hardware around presently.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Tue, Feb 19, 2013 at 7:12 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Wed, Feb 20, 2013 at 01:34:57AM +0100, Stefan Behte wrote:
>> > 2. root key & signing subkey of EITHER: 2.1. DSA, 1024 or 2048 bits
>> > 2.2. RSA, >=2048 bits
> ...
>> 1024 DSA keys seem pretty short to me. Surely it might be inconvenient
>> for some (2-3? please write a mail here!) people with smart cards. But
>> then again, especially people going through the hell of using a
>> physical token would understand the need for decent crypto. ;)
> A physical token defends against a different method of attack than a
> longer key. Simply having a longer key isn't going to help you if store
> the key on the laptop and it gets compromised: presuming the attacker
> extracts your secret key and passphrase). In such a case, the smartcard
> at worst limits him to doing some number of signatures only, or even
> better if the reader has a hardwired pinpad, he gets nowhere at all.

I'm a bit confused.

I agree that a smartcard is much better security vs a longer key. I
don't think attackers targetting Gentoo are going to brute force the
key. They are going to steal the key, trivially, by exploiting a 0-day
in a crappy browser, or flash, or java, or whatever. A smartcard is
the defense against this attack (because the key material is well
protected, and they need physical access to actually relocate it.)
Storing it in the TPM would also be cool, except TPMs are crap on
Linux, *and* most hardware TPMs are crap anyway.

>
> Also, if there is a Well-Funded-Organization attacking Gentoo, there are
> MUCH more effective ways for them to compromise us. Any perceived gains
> in that field from requiring DSA2048 and blocking DSA1024 should be
> examined very closely.

I would ask the opposite question. What is the perceived difficulty in
using DSA2048 vs 1024? For the non-smartcard users, the cost is likely
trivial. Even your perf data shows that signing requests still
complete in 200ms or less, and that is on old / slow hardware.

>
>> I think key rotation is overdoing it and pretty annoying. Better use a
>> non-annoying, long key from the start?
> NOWHERE did I require key rotation. Why do you think that I did?
> My own key is more than a decade old. I need to see about replacing it
> soon, but I've been trying to hold out for the OpenPGP standard to have
> ECC included, before I repeat getting my extremely large web-of-trust.
>
>> > 4. If you intend to sign on a slow alternative-arch, you may find
>> > adding a DSA1024 subkey significantly speeds up the signing.
>> How slow is that actually? Does it make signing very inconvenient?
>> Maybe someone with a slow machine can write about performance and the
>> "annoyence-factor"... ;)
> Some benchmark results from hake.hppa.dev.g.o, 552Mhz PA-RISC box.
>
> Average of running clearsign ~100 times, for various signature types.
> The gpg.conf was set as in my initial post.
>
> DSA1024 0.059830s
> DSA2048 0.158800s
> DSA3072 0.274850s
> RSA1024 0.060020s
> RSA2048 0.173070s
> RSA4096 0.896480s
>
> For reasons of time, while I wanted to create the keys on the host as
> well for timing, I gave up after the first key, DSA1024, took more than
> 3 minutes (I did ensure that /dev/random was not the blocking factor).
>
> If somebody from MIPS or m68k wants to chime in, I think they probably
> have the slowest hardware around presently.

djm works for Google, and I chat with him at least once a quarter.
I've seen some patches go by that we could re-purpose for gpg-agent
forwarding. For slow machines we could have them sign on a
faster-trusted machine with a forwarded agent.

-A

>
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Trustee & Infrastructure Lead
> E-Mail : robbat2@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Tue, Feb 19, 2013 at 10:32:13PM -0800, Alec Warner wrote:
> I agree that a smartcard is much better security vs a longer key. I
> don't think attackers targetting Gentoo are going to brute force the
> key. They are going to steal the key, trivially, by exploiting a 0-day
> in a crappy browser, or flash, or java, or whatever. A smartcard is
> the defense against this attack (because the key material is well
> protected, and they need physical access to actually relocate it.)
> Storing it in the TPM would also be cool, except TPMs are crap on
> Linux, *and* most hardware TPMs are crap anyway.
Exactly. The longer key doesn't block this attack, the smartcard does.

The question being asked becomes:
"If the smartcard only supports a shorter key is that an acceptable
tradeoff where a longer key would be used instead?"

I say it's a very acceptable tradeoff, and the require/recommend of the
proposal reflects this.

> > Also, if there is a Well-Funded-Organization attacking Gentoo, there are
> > MUCH more effective ways for them to compromise us. Any perceived gains
> > in that field from requiring DSA2048 and blocking DSA1024 should be
> > examined very closely.
> I would ask the opposite question. What is the perceived difficulty in
> using DSA2048 vs 1024? For the non-smartcard users, the cost is likely
> trivial. Even your perf data shows that signing requests still
> complete in 200ms or less, and that is on old / slow hardware.
This is why I recommended DSA2048, but only required DSA1024.
I don't want something that says
"If you use a smartcard, you can use DSA1024, otherwise you must use
DSA2048"
That's just too confusing.

> djm works for Google, and I chat with him at least once a quarter.
> I've seen some patches go by that we could re-purpose for gpg-agent
> forwarding. For slow machines we could have them sign on a
> faster-trusted machine with a forwarded agent.
Major +1 on gpg-agent forwarding request; the smartcard crowd would love
it too.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: RFC: Gentoo GPG key policies [ In reply to ]
>>>>> "RHJ" == Robin H Johnson <robbat2@gentoo.org> writes:

RHJ> 2. Root key type of RSA, 4096 bits

rsa 4k provides no real benefits over rsa 3k here; it is just slower
for everyone, signing or verifying.

Cf, eg, http://www.nsa.gov/business/programs/elliptic_curve.shtml which
recommends rsa 3k for use with aes128/sha256, rsa 7k for aes192/sha384
and rsa 15k for aes256/sha512.

If 3k provides comparable security to aes128 and sha256, and one needs
to more than double the rsa key length to compare with aes192 and sha384,
there is no reason to bother with rsa 4k.

-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Wed, Feb 20, 2013 at 01:41:03PM -0500, James Cloos wrote:
> >>>>> "RHJ" == Robin H Johnson <robbat2@gentoo.org> writes:
>
> RHJ> 2. Root key type of RSA, 4096 bits
> rsa 4k provides no real benefits over rsa 3k here; it is just slower
> for everyone, signing or verifying.
You can shorten the subkeys, but the root key should ONLY be used for
certifications & key operations, not signing of external objects.

The subkeys should be used for the external objects, and that's where
you'd shorten if you really wanted. However, I'd suggest you not bother.

> Cf, eg, http://www.nsa.gov/business/programs/elliptic_curve.shtml which
> recommends rsa 3k for use with aes128/sha256, rsa 7k for aes192/sha384
> and rsa 15k for aes256/sha512.
>
> If 3k provides comparable security to aes128 and sha256, and one needs
> to more than double the rsa key length to compare with aes192 and sha384,
> there is no reason to bother with rsa 4k.
Speed for i7-2600K CPU:
DSA1024 0.007980s
DSA2048 0.011940s
DSA3072 0.013530s
RSA1024 0.007000s
RSA2048 0.012290s
RSA3072 0.018420s
RSA4096 0.030800s

30ms is still an acceptable signing time - not noticeably different than
RSA2048/RSA3072.

Better question to all of this, is there somebody with a PGP smartcard that can
do the same tests? I'll provide some scripts for the testcase itself, but
you'll have to see about generating a bunch of keys on the smartcard, which
might be problematic.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: RFC: Gentoo GPG key policies [ In reply to ]
Am Mittwoch, 20. Februar 2013, 20:36:22 schrieb Robin H. Johnson:
>
> Speed for i7-2600K CPU:
> DSA1024 0.007980s
> DSA2048 0.011940s
> DSA3072 0.013530s
> RSA1024 0.007000s
> RSA2048 0.012290s
> RSA3072 0.018420s
> RSA4096 0.030800s
>

Which of course brings up the question, why the hardcoded 4096 limit in
GnuPG... but I guess that's not our problem yet.

https://www.google.de/search?q=gnupg+rsa+8192

--

Andreas K. Huettel
Gentoo Linux developer
dilfridge@gentoo.org
http://www.akhuettel.de/
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Mon, 18 Feb 2013 23:27:46 +0000
"Robin H. Johnson" <robbat2@gentoo.org> wrote:


> 3. Dedicated Gentoo signing subkey

What's the point of this, btw?


Luis
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Wed, Feb 20, 2013 at 09:22:05PM +0100, Andreas K. Huettel wrote:
> Which of course brings up the question, why the hardcoded 4096 limit in
> GnuPG... but I guess that's not our problem yet.
> https://www.google.de/search?q=gnupg+rsa+8192
Standards interoperability. >RSA4096 will not work on legacy PGP
implementations & key servers.

The next release of the OpenPGP spec is supposed to raise this.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Wed, Feb 20, 2013 at 09:38:38PM +0100, Luis Ressel wrote:
> On Mon, 18 Feb 2013 23:27:46 +0000
> "Robin H. Johnson" <robbat2@gentoo.org> wrote:
> > 3. Dedicated Gentoo signing subkey
> What's the point of this, btw?
Ideally keeping your primary key offline to increase security.

However, the original theory was that if there was some attack that
required a large amount of ciphertext or a targeted plaintext input, you
would be limiting the ciphertext to only gentoo-specific content, and
could trivially rotate the subkey without any impact on your primary
key.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Wed, 20 Feb 2013 21:37:38 +0000
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> Ideally keeping your primary key offline to increase security.
>
> However, the original theory was that if there was some attack that
> required a large amount of ciphertext or a targeted plaintext input,
> you would be limiting the ciphertext to only gentoo-specific content,
> and could trivially rotate the subkey without any impact on your
> primary key.

I totally agree with the idea of having a separate subkey for signing
purposes, but look at my key, for example: I already have a separate
subkey for signing, the primary key is only used for certifications
(and is actually kept offline ;). If I was a Gentoo dev, it wouldn't
seem that logical to have to create yet another signing subkey.

Therefore, I'd propose to remove the "Gentoo" part from "Dedicated
Gentoo signing subkey".

Luis
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Mon, 18 Feb 2013 23:27:46 +0000
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> Recommendations:
> ----------------
> 3. Dedicated Gentoo signing subkey of EITHER:
> 3.1. DSA 2048 bits
> 3.2. RSA 4096 bits

As a note for those who didn't know this; to make gpg use the dedicated
subkey, you need to append an exclamation mark (!) to it. Like:

PORTAGE_GPG_KEY="9627F456F9DA7643!"

Otherwise, GPG will just use this as a reference to the whole key,
and may use other subkey.

--
Best regards,
Michał Górny
Re: RFC: Gentoo GPG key policies [ In reply to ]
On 21 February 2013 09:09, Michał Górny <mgorny@gentoo.org> wrote:
> On Mon, 18 Feb 2013 23:27:46 +0000
> "Robin H. Johnson" <robbat2@gentoo.org> wrote:
>
>> Recommendations:
>> ----------------
>> 3. Dedicated Gentoo signing subkey of EITHER:
>> 3.1. DSA 2048 bits
>> 3.2. RSA 4096 bits
>
> As a note for those who didn't know this; to make gpg use the dedicated
> subkey, you need to append an exclamation mark (!) to it. Like:
>
> PORTAGE_GPG_KEY="9627F456F9DA7643!"
>
> Otherwise, GPG will just use this as a reference to the whole key,
> and may use other subkey.
>
> --
> Best regards,
> Michał Górny

Thanks for that. I didn't know it and I couldn't find any references
in the manpages.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
Re: RFC: Gentoo GPG key policies [ In reply to ]
Hello *,

I am stuck and have many questions.

[.In the process of becoming a dev, I've generated a gpg key, of course. It
vwas on an old notebook. When I switched to a newer notebook, I forgot to
copy it, because I don't use gpg regularly. No risk that it became known -
the disk was re-partitioned and re-formatted. Probably, that key has
expired anyway.]

1. So, I start

gpg --gen-key

It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then
edit ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing
gpg.conf can be done later?

2. Then I choose 1, 3y, y, then my name and the @gentoo.org email address.
After that,

gpg --list-keys

says

/home/<username>/.gnupg/pubring.gpg
-------------------------------
pub 4096R/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
uid [ultimate] <my_name> <my_gentoo_email_address>
sub 4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]

So, my key id is 0x<16_hex_digits_1>, right?

3. Now I do

gpg --edit-key 0x<16_hex_digits_1>
addkey

Then I choose

(4) RSA (sign only)

right? Then I choose 4096, 1y, y, y, save. Now

gpg --list-keys

gives

/home/<username>/.gnupg/pubring.gpg
-------------------------------
pub 4096R/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
uid [ultimate] <my_name> <my_gentoo_email_address>
sub 4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]
sub 4096R/0x<16_hex_digits_3> 2013-02-26 [expires: 2014-02-26]

4. I do

gpg --output revoke.asc --gen-revoke 0x<16_hex_digits_1>

and choose 1.

> 6. Encrypted backup of your secret keys.
I don't understand this.

> 7. In your gpg.conf:
> # include an unambiguous indicator of which key made a signature:
> # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
> sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
I don't understand this.

5. I do

gpg --keyserver subkeys.pgp.net --send-key 0x<16_hex_digits_1>

6. On dev.gentoo.org, I am supposed to do

perl_ldap -b user -M gpgkey <gpg-id> <user>
perl_ldap -b user -M gpgfingerprint <gpg-fingerprint> <user>

Is <gpg-id> 0x<16_hex_digits_1>? Or 0x<16_hex_digits_3>? What is
<gpg-fingerprint> and how do I get it? Is <user> my username on
dev.gentoo.org?

What's even more important, perl_ldap asks my ldap password. I suppose I
haven't got one. My usual Gentoo password (used in bugzilla, forums) does
not work. How do I get an ldap password?

7. If I'll ever complete all the above, I'll add sign to FEATURES in
/etc/portage/make.conf, and

PORTAGE_GPG_DIR="/home/<username>/.gnupg"

and also

PORTAGE_GPG_KEY="0x<16_hex_digits_3>!"

Is this correct? Is it <16_hex_digits_3>, and not, say, <16_hex_digits_1>?
Should I add ! at the end, as suggested by mgorny?

During the time I'm reading all these instructions, I could bump 10
packages. Very complicated for a person who does not use gpg and knows
next to nothing about it.

Andrey Grozin
Re: RFC: Gentoo GPG key policies [ In reply to ]
On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT)
grozin@gentoo.org wrote:

> Hello *,
> I am stuck and have many questions.
> [.In the process of becoming a dev, I've generated a gpg key, of course. It vwas on an old notebook. When I switched to a newer notebook, I forgot to copy it, because I don't use gpg regularly. No risk that it became known - the disk was re-partitioned and re-formatted. Probably, that key has expired anyway.]
> 1. So, I start
> gpg --gen-key
> It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can be done later?

Editing the conf should be done first, some of the preferences (e.g.
personal-digest-preference and cert-digest-algo) affect the creation of
keys.

> 2. Then I choose 1, 3y, y, then my name and the @gentoo.org email address. After that,
> gpg --list-keys
> says
> /home/<username>/.gnupg/pubring.gpg
> -------------------------------
> pub 4096R/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
> uid [ultimate] <my_name> <my_gentoo_email_address> sub 4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]
> So, my key id is 0x<16_hex_digits_1>, right?

Yep, but why did you bother to replace the information?

> 3. Now I do
> gpg --edit-key 0x<16_hex_digits_1>
> addkey
> Then I choose
> (4) RSA (sign only)
> right? Then I choose 4096, 1y, y, y, save. Now
> gpg --list-keys
> gives
> /home/<username>/.gnupg/pubring.gpg
> -------------------------------
> pub 4096R/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
> uid [ultimate] <my_name> <my_gentoo_email_address>
> sub 4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]
> sub 4096R/0x<16_hex_digits_3> 2013-02-26 [expires: 2014-02-26]
> 4. I do
> gpg --output revoke.asc --gen-revoke 0x<16_hex_digits_1>
> and choose 1.

That's all correct.

> > 6. Encrypted backup of your secret keys.
> I don't understand this.

It'd make sense to have an backup of your keys (~/.gnupg/secring.gpg)
stored in a safe place, just as with everything else... If you want,
you can protect it by another layer of encryption, but it's not that
important, because the keys are already protected by your passphrase.

> > 7. In your gpg.conf:
> > # include an unambiguous indicator of which key made a signature:
> > # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
> > sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
> I don't understand this.

Neither do I (I know what it does, but I don't see what it's good for) –
just leave it out, it's not necessary.

> 5. I do
> gpg --keyserver subkeys.pgp.net --send-key 0x<16_hex_digits_1>
> 6. On dev.gentoo.org, I am supposed to do
> perl_ldap -b user -M gpgkey <gpg-id> <user>
> perl_ldap -b user -M gpgfingerprint <gpg-fingerprint> <user>
> Is <gpg-id> 0x<16_hex_digits_1>? Or 0x<16_hex_digits_3>? What is <gpg-fingerprint> and how do I get it? Is <user> my username on dev.gentoo.org?
> What's even more important, perl_ldap asks my ldap password. I suppose I haven't got one. My usual Gentoo password (used in bugzilla, forums) does not work. How do I get an ldap password?

I can't help you with that, as I don't have access to any gentoo
infrastructure. But IIRC, that's the password you once set on d.g.o
with passwd.

> 7. If I'll ever complete all the above, I'll add sign to FEATURES in /etc/portage/make.conf, and
> PORTAGE_GPG_DIR="/home/<username>/.gnupg"
> and also
> PORTAGE_GPG_KEY="0x<16_hex_digits_3>!"
> Is this correct? Is it <16_hex_digits_3>, and not, say, <16_hex_digits_1>? Should I add ! at the end, as suggested by mgorny?

16_hex_digits_3 (the one you added later via addkey) is the correct
one. And adding a ! is absolutely necessary.

> During the time I'm reading all these instructions, I could bump 10 packages. Very complicated for a person who does not use gpg and knows next to nothing about it.

Security can be hard to grasp at times. Sadly...


HTH,
Luis
Re: RFC: Gentoo GPG key policies [ In reply to ]
Thanks for the partial response Luis.

On Wed, Feb 27, 2013 at 04:12:14PM +0100, Luis Ressel wrote:
> On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT)
> grozin@gentoo.org wrote:
>
> > Hello *,
> > I am stuck and have many questions.

New addition to the instructions:
0. Copy /usr/share/gnupg/gpg-conf.skel to ~/.gnupg/gpg.conf, append the
block given in my email.
TODO: The upstream skeleton config file has improved over the years,
it would be useful for all users to get updates to it, but etc-update
only works for /etc, since this is deployed per-user. Suggestions
welcome on getting users to do this.

> > [.In the process of becoming a dev, I've generated a gpg key, of course. It vwas on an old notebook. When I switched to a newer notebook, I forgot to copy it, because I don't use gpg regularly. No risk that it became known - the disk was re-partitioned and re-formatted. Probably, that key has expired anyway.]
> > 1. So, I start
> > gpg --gen-key
> > It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can be done later?
> Editing the conf should be done first, some of the preferences (e.g.
> personal-digest-preference and cert-digest-algo) affect the creation of
> keys.
See step 0 above, and do gen-key AFTER that.

> > 3. Now I do
> > gpg --edit-key 0x<16_hex_digits_1>
> > addkey
> > Then I choose
> > (4) RSA (sign only)
> > right? Then I choose 4096, 1y, y, y, save. Now
> > gpg --list-keys
> > gives
> > /home/<username>/.gnupg/pubring.gpg
> > -------------------------------
> > pub 4096R/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26]
> > uid [ultimate] <my_name> <my_gentoo_email_address>
> > sub 4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26]
> > sub 4096R/0x<16_hex_digits_3> 2013-02-26 [expires: 2014-02-26]
> > 4. I do
> > gpg --output revoke.asc --gen-revoke 0x<16_hex_digits_1>
> > and choose 1.
> That's all correct.
Make sure to put that revoke.asc file in a secure place, and REMOVE the
unprotected copy from your system. It has NO encryption on that file, by
design.

> > > 6. Encrypted backup of your secret keys.
> > I don't understand this.
>
> It'd make sense to have an backup of your keys (~/.gnupg/secring.gpg)
> stored in a safe place, just as with everything else... If you want,
> you can protect it by another layer of encryption, but it's not that
> important, because the keys are already protected by your passphrase.

Yes, your normal keys are protected by your passphrase.
If you have additional SEPARATE keys that might not have passphrases (eg
for automation purposes), having them encrypted on your backup media is
a good idea.

If you don't have any other keys like that, I've attached a backup
script for you to use (originally written because some versions ago
there was a gnupg locking bug, and it would occasionally
corrupt/overwrite my public keyring).

> > > 7. In your gpg.conf:
> > > # include an unambiguous indicator of which key made a signature:
> > > # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
> > > sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
> > I don't understand this.
> Neither do I (I know what it does, but I don't see what it's good for) –
> just leave it out, it's not necessary.
Here's the origin of this:
http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html
Basically, just like the rest of the expansion to use full length
keyids to avoid collision attacks, this does the same for
certifications.

> > 5. I do
> > gpg --keyserver subkeys.pgp.net --send-key 0x<16_hex_digits_1>
> > 6. On dev.gentoo.org, I am supposed to do
> > perl_ldap -b user -M gpgkey <gpg-id> <user>
> > perl_ldap -b user -M gpgfingerprint <gpg-fingerprint> <user>
> > Is <gpg-id> 0x<16_hex_digits_1>? Or 0x<16_hex_digits_3>? What is <gpg-fingerprint> and how do I get it? Is <user> my username on dev.gentoo.org?
> > What's even more important, perl_ldap asks my ldap password. I suppose I haven't got one. My usual Gentoo password (used in bugzilla, forums) does not work. How do I get an ldap password?
> I can't help you with that, as I don't have access to any gentoo
> infrastructure. But IIRC, that's the password you once set on d.g.o
> with passwd.
Your recruiter should have pointed you to your LDAP password when you
become a developer for new developers. In case of old developers, this
wasn't reliable followed, and/or gets lost. Please contact infra or
the devrel leads to get your LDAP password reset.

'<user>' is your Gentoo developer username. Be careful to NOT
replace the '-b user' part, that selects 'user' mode for the tool.

> > 7. If I'll ever complete all the above, I'll add sign to FEATURES in /etc/portage/make.conf, and
> > PORTAGE_GPG_DIR="/home/<username>/.gnupg"
> > and also
> > PORTAGE_GPG_KEY="0x<16_hex_digits_3>!"
> > Is this correct? Is it <16_hex_digits_3>, and not, say, <16_hex_digits_1>? Should I add ! at the end, as suggested by mgorny?
> 16_hex_digits_3 (the one you added later via addkey) is the correct
> one. And adding a ! is absolutely necessary.
:-)

> > During the time I'm reading all these instructions, I could bump 10
> > packages. Very complicated for a person who does not use gpg and
> > knows next to nothing about it.
> Security can be hard to grasp at times. Sadly...
But THANK YOU for writing up your email, it's great to have somebody
with no experience try the instructions, and help us figure out where
they need to improve.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

1 2  View All