[gentoo-dev] First release of Gentoo Keys

[gentoo-dev] First release of Gentoo Keys

[Pavlos Ratis]

Hello all,

We're very pleased to announce the first official release of the Gentoo Keys
toolkit.

What is the Gentoo Keys project?
=========================
Gentoo Keys is a Python based project that aims to manage the OpenPGP keys
used for validation on users and Gentoo's infrastructure servers. It is
a toolkit that helps the community establish the trust between the users and
developers.

Gentoo Keys can verify OpenPGP keys used for Gentoo's release media,
packages and other OpenPGP signed documents, i.e LiveDVDs, LiveCD's ,
stage* releases, Gentoo tree ebuild commits, layman repositories list.

Gentoo Keys project consists of three tools:
* gkeys
* gkeys-gen
* gkeys-ldap.

Tools
====
gkeys-ldap
----------------
Is the tool that is going to be used internally in Gentoo infrastructure.
It performs LDAP look-ups to all the developers and generates the so
called seed files[1].

gkeys
---------
Is the major tool that manages the seed files and the keyrings[2] of the
developers. This tool is also going to be used for file signing and
verification. In addition it can generate binary keyrings based on selected
keys which then can be signed and distributed to the user base.

gkeys-gen
--------------
Is the tool that generates OpenPGP keys based on the recommended
specifications of the Gentoo council approved GLEP 63[3].

We have written an extensive guide on how to generate a GLEP 63 based
OpenPGP key:
https://wiki.gentoo.org/wiki/Project:Gentoo-keys/Generating_GLEP_63_based_OpenPGP_keys

Glossary
=======
[1] Seed files: A JSON file that contains the trusted users with their keys.
[2] Keyrings: A collection of trusted OpenPGP keys.
[3] GLEP 63: https://wiki.gentoo.org/wiki/GLEP:63

Automated Checks
===============
As of today, we insist all the Gentoo Developers to start creating GLEP
63 based OpenPGP keys.
In the following months we are going to start running a suite of
automated checks in all the developers OpenPGP keys.

Some of the checks are for:
* Invalid keys
* Expired keys
* Revoked keys
* GLEP63 requirements for keys

It is also worth mentioning that the following tools can be used from
users too. The Gentoo Keys project also aims to extend the usability of
the toolkit to the overlays so everyone can manage their own web of trust
and support signed files.

Installation
========
gkeys
--------
emerge app-crypt/gkeys

Note: app-crypt/gentoo-keys package contains the Gentoo release
keyrings and it is auto-fetched by app-crypt/gkeys package.

gkeys-gen
---------------
emerge app-crypt/gkeys-gen

Feedback
=======
For comments and suggestions feel free to contact us
in <gkeys AT gentoo DOT org> or join the #gentoo-keys IRC channel on Freenode.

Patches are always welcome!

Official project page: https://wiki.gentoo.org/wiki/Project:Gentoo-keys
Source code: https://github.com/gentoo/gentoo-keys

On behalf of the Gentoo Keys team,
Pavlos Ratis

Re: [gentoo-dev] First release of Gentoo Keys

[Brian Dolbec]

There is a short, "First USE" intro to using gkeys [4] in our wiki.

Notes:

  Not all devs have seeds in the gentoo-devs.seeds file downloaded
  during the install of gkeys.  The log stating the devs with bad info
  in LDAP can be viewed here [1].  There were 19 devs with conflicting
  or missing information.

  Of the devs with gpg key seeds created, 1 dev has incorrect
  fingerprint data in LDAP and fails to install his key properly.

  Of the remaining devs, only 16 keys total pass the GLEP 63
  requirements.  More info can be found in the First-Use wiki page [4]

You can find us for help in #gentoo-keys IRC channel to help fix your
keys, or deal with any issues you have running gkeys or gkeys-gen.
There is also several wiki pages (more to come, help appreciated) [3]
and the "First-Use" page (to be expanded) here [4].

Please keep in mind this is the initial release.  We have disabled a
few sub-commands which were not yet ready and will be in later releases.
Plus there are several more features on our TODO list.  But the primary
functionality is there.

Please report bugs in bugzilla [2], project: Gentoo-keys

[1] http://dev.gentoo.org/~dolsen/gkey-logs/
[2] http://bugs.gentoo.org/
[3] https://wiki.gentoo.org/wiki/Project:Gentoo-keys
[4] https://wiki.gentoo.org/wiki/Project:Gentoo-keys/Fisrt-Use
-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] First release of Gentoo Keys

[Rich Freeman]

On Sun, Jan 11, 2015 at 11:43 AM, Brian Dolbec <dolsen@gentoo.org> wrote:
>   Of the remaining devs, only 16 keys total pass the GLEP 63
>   requirements.  More info can be found in the First-Use wiki page [4]

If you just create a gpg key with 5yr expiry and otherwise-default
options, typing a larger number into the keysize prompt, do you get a
compliant key?  The guides talk about editing your gpg.conf, and it
looks like the tool does it for you, but is any of that necessary to
generate a compliant key?  I'd prefer raw gpg commands and not a
script that automates everything.

Would this work:
gpg --gen-key
option 2 - DSA and Elgamal
size 3072 (the max)
expires 5y
Enter your name, email, and passphrase.

I've been putting off generating a new key until this all settles
down, and would prefer to mess with it as infrequently as possible.
Most likely I'll just switch to Gentoo-dedicated key for the tree.

-- 
Rich

Re: [gentoo-dev] First release of Gentoo Keys

[Peter Stuge]

Rich Freeman wrote:
> Would this work:
> gpg --gen-key
> option 2 - DSA and Elgamal

Watch that entropy.


//Peter

Re: [gentoo-dev] First release of Gentoo Keys

[Brian Dolbec]

On Sun, 11 Jan 2015 12:06:18 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Jan 11, 2015 at 11:43 AM, Brian Dolbec <dolsen@gentoo.org>
> wrote:
> >   Of the remaining devs, only 16 keys total pass the GLEP 63
> >   requirements.  More info can be found in the First-Use wiki page
> > [4]
> 
> If you just create a gpg key with 5yr expiry and otherwise-default
> options, typing a larger number into the keysize prompt, do you get a
> compliant key?  The guides talk about editing your gpg.conf, and it
> looks like the tool does it for you, but is any of that necessary to
> generate a compliant key?  I'd prefer raw gpg commands and not a
> script that automates everything.
> 
> Would this work:
> gpg --gen-key
> option 2 - DSA and Elgamal
> size 3072 (the max)
> expires 5y
> Enter your name, email, and passphrase.
> 
> I've been putting off generating a new key until this all settles
> down, and would prefer to mess with it as infrequently as possible.
> Most likely I'll just switch to Gentoo-dedicated key for the tree.
> 

Wait for Kristian to reply about the algorythm choice.

But for the rest, yes, you don't need gkeys to create your key, It is
just most people seem to know little about using gpg, so creating the
template where you just filled out name, email, password, makes it easy.

From the above, it looks like you also need to create a signing subkey
with a preferred 1 yr. expiry.  But it can be 5 years max. too.  You
may also want to add an encryption subkey for encrypted email and such.

I added a little more info to the First-Use wiki page, I included a
link to a great webpage about setting up gpg keys.

https://alexcabal.com/creating-the-perfect-gpg-keypair/

there are lots more, but I like that one, it is clear, concise,...

-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] First release of Gentoo Keys

[Rich Freeman]

On Sun, Jan 11, 2015 at 8:34 PM, Brian Dolbec <dolsen@gentoo.org> wrote:
> But for the rest, yes, you don't need gkeys to create your key, It is
> just most people seem to know little about using gpg, so creating the
> template where you just filled out name, email, password, makes it easy.

Makes sense.  I can always create a new account, create a key,
export/import, and delete the account.  That will avoid messing with
config files and such.

>
> From the above, it looks like you also need to create a signing subkey
> with a preferred 1 yr. expiry.  But it can be 5 years max. too.  You
> may also want to add an encryption subkey for encrypted email and such.

From docs I was reading it sounds like a signing and encryption subkey
are created by default (two keys total).  Is there any difference
between a "main key" and a subkey?  I have to admit that I haven't
kept up with gpg features over the years.

>
> I added a little more info to the First-Use wiki page, I included a
> link to a great webpage about setting up gpg keys.
>
> https://alexcabal.com/creating-the-perfect-gpg-keypair/
>
> there are lots more, but I like that one, it is clear, concise,...

From that site: By default GPG creates one signing subkey (your
identity) and one encryption subkey (how you receive messages intended
for you)...Use GPG to add an additional signing subkey to your
keypair. This new subkey is linked to the first signing key. Now we
have three subkeys.

But, whatever.  If we want a total of three keys in the key then I
don't really have a problem with that.  I'm not sure what it buys you
other than lots of confusion about how to sign the right thing with
the right key.  :)

-- 
Rich

Re: [gentoo-dev] First release of Gentoo Keys

[Brian Dolbec]

On Sun, 11 Jan 2015 20:55:29 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Jan 11, 2015 at 8:34 PM, Brian Dolbec <dolsen@gentoo.org>
> wrote:

> > I added a little more info to the First-Use wiki page, I included a
> > link to a great webpage about setting up gpg keys.
> >
> > https://alexcabal.com/creating-the-perfect-gpg-keypair/
> >
> > there are lots more, but I like that one, it is clear, concise,...
> 
> From that site: By default GPG creates one signing subkey (your
> identity) and one encryption subkey (how you receive messages intended
> for you)...Use GPG to add an additional signing subkey to your
> keypair. This new subkey is linked to the first signing key. Now we
> have three subkeys.
> 
> But, whatever.  If we want a total of three keys in the key then I
> don't really have a problem with that.  I'm not sure what it buys you
> other than lots of confusion about how to sign the right thing with
> the right key.  :)
> 


Ok, the original text:

1. Create a regular GPG keypair. By default GPG creates one signing
subkey (your identity) and one encryption subkey (how you receive
messages intended for you).


That looks like a slight error in the authors wording.  

It create one primary key with signing, authorization capability, and a
one encryption sub-key.

When you add a signing subkey, that subkey then becomes the default key
used for signing with.  If you have more than one signing subkey, the
default can be set in gnupg.conf without editing the key.  Otherwise
you must specify which key to sign with.  It is much easier to
revoke that signing subkey and add a new one, without the need to
create an entirely new key, losing all the key signatures it is signed
with.  If you revoke a primary key, all subkeys it contains are revoked
as well. In that article the author describes how to generate the
subkeys and remove the original (master) keypair for installation on a
laptop, desktop, etc. (separate subkeys for each machine) which may be
stolen. You keep the original(master) keypair in a secure location (eg:
bank safe deposit box, etc.) If the laptop is stolen, the thieves do not
have access to modify the gpg keys (even if they have the password),
and those specific subkeys can be easily revoked, without losing your
entire gpg key and the signatures it has accumulated. Using your master
keypair you generate new subkeys for installation on your replacement
laptop, and continue...

-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] First release of Gentoo Keys

[Brian Dolbec]

On Sun, 11 Jan 2015 18:37:36 -0800

I forgot to mention:

 You enter the primary key fingerprint and keyid
into LDAP, not the signing subkey.  

The subkeys information will be imported along
with the primary key.  Even if you change signing subkey later, there
should be no need to edit LDAP with the new key provided it belongs to
the same primary key.  Updates like that will be taken care of whenever
a "gpg --refresh-key ..." or "gkeys-refresh-key -C gentoo-devs"
operation is done on the keyring.



-- 
Brian Dolbec <dolsen>

Re: [gentoo-dev] First release of Gentoo Keys

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/12/2015 02:55 AM, Rich Freeman wrote:
> On Sun, Jan 11, 2015 at 8:34 PM, Brian Dolbec <dolsen@gentoo.org>
> wrote:
>> But for the rest, yes, you don't need gkeys to create your key,
>> It is just most people seem to know little about using gpg, so
>> creating the template where you just filled out name, email,
>> password, makes it easy.
> 
> Makes sense.  I can always create a new account, create a key, 
> export/import, and delete the account.  That will avoid messing
> with config files and such.
> 
>> 
>> From the above, it looks like you also need to create a signing
>> subkey with a preferred 1 yr. expiry.  But it can be 5 years max.
>> too.  You may also want to add an encryption subkey for encrypted
>> email and such.
> 
> From docs I was reading it sounds like a signing and encryption
> subkey are created by default (two keys total).  Is there any
> difference between a "main key" and a subkey?  I have to admit that
> I haven't kept up with gpg features over the years.

By default GnuPG only create a primary key with SC flags (sign &
certification) and an encryption subkey. In this case you'll want to
add a signing subkey using the "addkey" command of --edit-key to make
a compliant key.


- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtAvMAAoJEPw7F94F4TagBsEQALMRpYPlAsVm/J/3cqA57BYH
+mcCFA9sNVd8zwGp2fAybGl7Umj0oCTU/c5R/YICPtmuzu8hxYjhvPpKc1gF3UBb
QzjCeqMEHNXz1hEsfbmQyqw10Jc9xxiJZmUVESB8tC1l/OTmDOHjgfU5APWzAIg/
4scM91Y1lbtKoeJsTpfW0Tv9ROC75PuWudHhEx/3RKJvygACeWGbeLZX9tmdKZbz
Zc+Iv3je0XCabC4G0vviuAddpeyNMj0ck5d9lrPLM+MxdJDSkeAT0/+aMBhiQOqt
jZImJ4eZq48sEdh0wUqt7EeLuKL6w5rO9N8DTHPCfDhJ9mhFmxPgozVkRmzhTrTX
Twac69fSklDzEcQZHr/kPynYdp1ZTN97MxcLxNMXNhWTIG51sFfNK4is+kdmBVUk
9wAuMQbWdeeC7oFy60h8sIak7yNeh7L34C7XrYIN7urT9W9zw0tQttRmPbY82yBU
K/w8OvdpcwkYNGoAkFfpCL1aqJjwfrWqyWglNGgbaWgw5hkKQ5f+Ljvou9sdfiVc
1e4Vu5Tiblz1Ucs5JZRoioXwsW9EAxUYg7wAxnjHyEgE4opFpvVwgq4beWMzgbG9
1f2YVxrrakLfpuJ5WneDZJBToaDeVDpMInERiF9xlJDb8vvZeUtKzEElAOF0Ptg4
6b9fY0tzc1eAd4uuYPj2
=v+RL
-----END PGP SIGNATURE-----

Re: [gentoo-dev] First release of Gentoo Keys

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/12/2015 02:34 AM, Brian Dolbec wrote:
> On Sun, 11 Jan 2015 12:06:18 -0500 Rich Freeman <rich0@gentoo.org>
> wrote:
> 
>> On Sun, Jan 11, 2015 at 11:43 AM, Brian Dolbec
>> <dolsen@gentoo.org> wrote:
>>> Of the remaining devs, only 16 keys total pass the GLEP 63 
>>> requirements.  More info can be found in the First-Use wiki
>>> page [4]
>> 
>> If you just create a gpg key with 5yr expiry and
>> otherwise-default options, typing a larger number into the
>> keysize prompt, do you get a compliant key?  The guides talk
>> about editing your gpg.conf, and it looks like the tool does it
>> for you, but is any of that necessary to generate a compliant
>> key?  I'd prefer raw gpg commands and not a script that automates
>> everything.
>> 
>> Would this work: gpg --gen-key option 2 - DSA and Elgamal size
>> 3072 (the max) expires 5y Enter your name, email, and
>> passphrase.
>> 
>> I've been putting off generating a new key until this all
>> settles down, and would prefer to mess with it as infrequently as
>> possible. Most likely I'll just switch to Gentoo-dedicated key
>> for the tree.
>> 
> 
> Wait for Kristian to reply about the algorythm choice.

GnuPG defaults to 2048 bit RSA primary key with 2048 bit RSA
encryption subkey. DSA and ElGamal have not been the default for a
while for a few reasons. For those interested in a bit more technical
details read further.

One issue with DSA/ElGamal is the requirement for a random k value
while signing/encrypting, i.e. there is a requirement for a random
source for all signatures and encryption, not only while generating
the key, and the lack of proper randomness can cause private key
leakage (in the case of signatures). This can be mitigated by the use
of RFC6979 "
Deterministic Usage of the Digital Signature Algorithm (DSA) and
Elliptic Curve Digital Signature Algorithm (ECDSA)" , however this is
only introduced in libgcrypt 1.6.

Another issue is that DSA key sizes > 1024 bits are part of what is
commonly referred to as DSA2-standard, so this is less interoperable
with older versions.

Newer versions of GnuPG (in the 2.1 branch) won't give algorithm
choice at all unless --full-gen-key is used but generate using the
defaults.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtA0/AAoJEPw7F94F4TagGMIP/31V+VrAvB3PtEYeS+jhNc+D
1a020/Zo8rnrHKElK4+WDg+M+Dvw6UoQEpTvAu/ViZkGoCkDCE2iSo1Pv35NkwhB
7wVzJJU4yoK/qdxwi9hjZSXTjuLjGRvxOvHLRJ0bChMDbgPs4O3pODlvTf4Uyqxx
dUkfLblntJeFYEEMnx3ryFxpLpbKSc27cQLg+DlXvASMTMulbhb2wRi5HfCJ1zfj
14FzSQFPuolkgLbuRJGvntq8uDAD03nTTnuAX9QiTOaT8GxRxw6RLIWa35E1tctq
jBPPfGn+SyrPEHx5Gqgzo7Q8PfFTk6X60Fkzau+1qPd6sE0G8EA54CG/sFydoZEr
N8XKPYOM+lw51kVHNR6GSjgFitc53Adqx0yHzzm1l+hYVmk3ZKitjmyCf+pyTS+a
wkFxcNd/N1pfhfBs3LVSqvKPjw1NUaengt5eeC2YGkhYXs1qT0e1aO9uUzBAhsCc
aH+6oTIG8fm0RClFUuuNVOv4STDPOpNtiOvOboO9ICHE6nwYaGUblKxCSvQ8gz/Q
wEpqZ0rXDz9dJKBGBXMNIb0jxLejWvoiUb6V6oWYS5xHMWdiM+JpVInmNs7OZ9ks
Yn65z5Ffi54X2fc6qAFUaTpMZ7NVIq5f6D96Mx7SZD3VCOzIhgWh8fbEnWqqCkVE
Qf0hbsyzeHZXyxQWQNwb
=Odoa
-----END PGP SIGNATURE-----

Re: [gentoo-dev] First release of Gentoo Keys

[Rich Freeman]

On Mon, Jan 12, 2015 at 1:06 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>
> One issue with DSA/ElGamal is the requirement for a random k value
> while signing/encrypting,

Thanks - that was very informative.  I guess the thing that makes me
more concerned about RSA is that Shor's algorithm makes it quite
possible that it will be defeated at some point in the future, perhaps
without public disclosure.

Granted, forging Gentoo commit signatures isn't really a high-profile
target for somebody who has a secret quantum computer at their
disposal (which they'd presumably like to remain secret).

-- 
Rich

Re: [gentoo-dev] First release of Gentoo Keys

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/12/2015 07:29 PM, Rich Freeman wrote:
> On Mon, Jan 12, 2015 at 1:06 PM, Kristian Fiskerstrand
> <k_f@gentoo.org> wrote:
>> 
>> One issue with DSA/ElGamal is the requirement for a random k
>> value while signing/encrypting,
> 
> Thanks - that was very informative.  I guess the thing that makes
> me more concerned about RSA is that Shor's algorithm makes it
> quite possible that it will be defeated at some point in the
> future, perhaps without public disclosure.

Shor's would be effective against discrete logs (including ECC) as
well, so wouldn't be applicable to this selection. For post-quantum
asymmetric crypto we'd likely need e.g a lattice based primitive.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtBYdAAoJEPw7F94F4TagA0cP/1fUOfyn+goHBJUPsrqNBt72
tkEShCRRtdqwknPf5XYR5oM3jRpG9QZ4L89vjXC/3SklIT1wz+IFLkUgJHbfg33k
rbmr6oMXbQaqHami3l646DMjoqItLl1Nlnd5sqTVSBEB16KiJGE3oCVTAX6KisFW
72chafJh+4x9Cbbt48PL1FjCiLDunokCOHPtbXthkL2NJaPnIJh7HHCQk2CtgFZX
tER2gXai7VsQMMQdO9VuwNvrFS1svWFK97Eba1xgQx7tMg4hxWJadQphlwMKMEj+
uvZZ0HE708AUYBah+VCNJRFbJpyoND+7prUR19MnleUfehLWZHNUaOc1G8PK8X2b
GhH6fe2wft05e8jrfMgV0acECqdvsb82zvfYQRVksQbtxdhTB3ObPcBLYveG6tQU
IKLv47imTGAIW+Hwqk7EYQpLAMCcNhLmnwOdIe3CT+pvnluiGKZ55O67DJvE5QPS
goPkh8nmSRIcLdCYyJxU0X+nODQLUNi0sb1b8ryKM1OLz2jSq2vhehet0jZ8vu2T
0FpHKKo0dK7QTQQMmaoQ4Opfe3fff3kROhq3o0h6XMEg6niyzObg87ULecqKq59w
CfeYHq6RIKnc3Yfn0flzcAlKXVlW+dpcHS1hXHiaLrO6iVtvtfZxBG4mAUZuqWyi
k4FfOwRIvhFN5nTvM/TF
=yIog
-----END PGP SIGNATURE-----

Re: [gentoo-dev] First release of Gentoo Keys

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

On Mon, 12 Jan 2015 19:44:46 +0100
Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> Shor's would be effective against discrete logs (including ECC) as
> well, so wouldn't be applicable to this selection. For post-quantum
> asymmetric crypto we'd likely need e.g a lattice based primitive.

We're not post-quantum, and if we were no-one knows how anything would
do anyway... Why not stick to threats that actually exist?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] First release of Gentoo Keys

[Rich Freeman]

On Mon, Jan 12, 2015 at 1:48 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 12 Jan 2015 19:44:46 +0100
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>> Shor's would be effective against discrete logs (including ECC) as
>> well, so wouldn't be applicable to this selection. For post-quantum
>> asymmetric crypto we'd likely need e.g a lattice based primitive.
>
> We're not post-quantum, and if we were no-one knows how anything would
> do anyway... Why not stick to threats that actually exist?

For the same reason that we don't deploy 1024-bit RSA keys?  Also, you
wouldn't necessarily know if we were post-quantum or not.

Nobody made the claim that nobody should ever use RSA, just that this
is an area of concern.

-- 
Rich

Re: [gentoo-dev] First release of Gentoo Keys

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

On Sun, 11 Jan 2015 18:37:36 -0800 Brian Dolbec wrote:
> When you add a signing subkey, that subkey then becomes the default key
> used for signing with.  If you have more than one signing subkey, the
> default can be set in gnupg.conf without editing the key.  Otherwise
> you must specify which key to sign with.  It is much easier to
> revoke that signing subkey and add a new one, without the need to
> create an entirely new key, losing all the key signatures it is signed
> with.  If you revoke a primary key, all subkeys it contains are revoked
> as well. In that article the author describes how to generate the
> subkeys and remove the original (master) keypair for installation on a
> laptop, desktop, etc. (separate subkeys for each machine) which may be
> stolen. You keep the original(master) keypair in a secure location (eg:
> bank safe deposit box, etc.) If the laptop is stolen, the thieves do not
> have access to modify the gpg keys (even if they have the password),
> and those specific subkeys can be easily revoked, without losing your
> entire gpg key and the signatures it has accumulated. Using your master
> keypair you generate new subkeys for installation on your replacement
> laptop, and continue...

I still don't understand why requirement of a separate signing
subkey is mandatory in GLEP:63. I solves such a corner case where
other solutions are possible meanwhile, e.g. encrypt your laptop's
HDD, use a LUKS partition on top of it, store password-protected
secret key there. In fact the most dangerous attack is in-memory
breach when key is being stolen from memory without any trace
(Heltzner hosting breach comes to my mind here) and a separate
signing subkey wouldn't help here at all. While this requirement
may improve security a bit, it should go to recommendations and not
to bare minimum stuff. Even document referenced by GLEP:63:
RiseUp.net OpenPGP best practices
[https://we.riseup.net/riseuplabs+paow/openpgp-best-practices]
points out that a separate signing subkey is only an optional bonus:

(bonus) Have a separate subkey for signing, and keep your primary
key entirely offline.

Meanwhile link above is outdated and the following should be used
instead:
https://help.riseup.net/en/security/message-security/openpgp/best-practices

On the other hand GLEP:63 allows weak algos like DSA-2048, which
makes me shivers. Yes, DSA-2048 is not officially broken yet, but
with RSA-1024 already broken in open media I don't trust 2048
algos, especially when they have numerous design flaws (like good
entropy requirement for every signing) and implementations weakness
are likely to be there. Agencies are always a few steps ahead, so
this should be taken into account.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] First release of Gentoo Keys

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

On Mon, 12 Jan 2015 18:48:41 +0000 Ciaran McCreesh wrote:
> On Mon, 12 Jan 2015 19:44:46 +0100
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> > Shor's would be effective against discrete logs (including ECC) as
> > well, so wouldn't be applicable to this selection. For post-quantum
> > asymmetric crypto we'd likely need e.g a lattice based primitive.
> 
> We're not post-quantum,

Are you sure? The simplest Shor's factorisation machine was already
built and published in open press:
http://arxiv.org/abs/quant-ph/0112176
This was done 14(!!) years ago. I don't doubt there was a
significant progress in this field thereafter. But it is likely
that results are classified.

And Yale university have annonced a serious progress in errors
correction recently:
http://news.yale.edu/2013/01/11/new-qubit-control-bodes-well-future-quantum-computing

> and if we were no-one knows how anything would
> do anyway... Why not stick to threats that actually exist?

They are exist. No agency will announce that they broke RSA
regardless of the key length. This information will be kept
top secret as long as possible, so one should prepare today and
beforehand.

There are post-quantum solutions and implementations, see
app-crypt/codecrypt.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] First release of Gentoo Keys

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Mon, 12 Jan 2015 19:44:46 +0100 Kristian Fiskerstrand wrote:
> On 01/12/2015 07:29 PM, Rich Freeman wrote:
> > On Mon, Jan 12, 2015 at 1:06 PM, Kristian Fiskerstrand
> > <k_f@gentoo.org> wrote:
> >> 
> >> One issue with DSA/ElGamal is the requirement for a random k
> >> value while signing/encrypting,
> > 
> > Thanks - that was very informative.  I guess the thing that makes
> > me more concerned about RSA is that Shor's algorithm makes it
> > quite possible that it will be defeated at some point in the
> > future, perhaps without public disclosure.
> 
> Shor's would be effective against discrete logs (including ECC) as
> well, so wouldn't be applicable to this selection. For post-quantum
> asymmetric crypto we'd likely need e.g a lattice based primitive.

Why not to use post-quantum signing together with a traditional one?
app-crypt/codecrypt is already in tree and provides an GnuPG-like
solution based on post-quantum cryptography.

It would be no harm to use this solution together with GnuPG, e.g.
have two detached signatures: a traditional RSA-4096 and a
post-quantum one.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] First release of Gentoo Keys

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/13/2015 05:58 AM, Andrew Savchenko wrote:
> On Mon, 12 Jan 2015 19:44:46 +0100 Kristian Fiskerstrand wrote:
>> On 01/12/2015 07:29 PM, Rich Freeman wrote:
>>> On Mon, Jan 12, 2015 at 1:06 PM, Kristian Fiskerstrand 
>>> <k_f@gentoo.org> wrote:
>>>> 
>>>> One issue with DSA/ElGamal is the requirement for a random k 
>>>> value while signing/encrypting,
>>> 
>>> Thanks - that was very informative.  I guess the thing that
>>> makes me more concerned about RSA is that Shor's algorithm
>>> makes it quite possible that it will be defeated at some point
>>> in the future, perhaps without public disclosure.
>> 
>> Shor's would be effective against discrete logs (including ECC)
>> as well, so wouldn't be applicable to this selection. For
>> post-quantum asymmetric crypto we'd likely need e.g a lattice
>> based primitive.
> 
> Why not to use post-quantum signing together with a traditional
> one? app-crypt/codecrypt is already in tree and provides an
> GnuPG-like solution based on post-quantum cryptography.

My opinion is that it would only increase the complexity of things, in
particular requiring a double set of trust paths / WoT.

When such a shift becomes a prudent move (my interpretation of that is
that it is advocated by people far more knowledgeable about crypto
than I am) a lattice-based primitive (McEliece as used by this tool is
part of this class) is likely to be brought into OpenPGP as an
encryption algorithm by form of extension to RFC4880 (or part of an
updated V5 key format).

> 
> It would be no harm to use this solution together with GnuPG, e.g. 
> have two detached signatures: a traditional RSA-4096 and a 
> post-quantum one.

The harm would be overhead, both computationally and not the least
operationally to establish valid trust paths. Keep in mind that if it
is to be any use, several steps would need to be fulfilled including
that operational security perimeters would need to match the
requirements, so all devs would need lattice-based keys in additional
to classical keys, and probably make adjustments to their overall life
to match such a key requirement.


- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtNt/AAoJEPw7F94F4Tag2HcP+wZTK1vLR1q0fYlGTAUi7I8G
3cWMrSAAVXqpfzezb7x/PYUm99y0G6gE9lmfkKQNG9sX6u/LsJDd7x6t92w99nI/
aJzYZi6WX5LKX7o22mFsSp8CjzJJwoNpdngKySjiTnFkMcsRmBANZnktsvxjKTS3
bgusId9LsT1w/hcXmIxmBUaM7hudffrV53XYdJtnlFPCCx6iLM4vQcjKxCQ60v67
LU11PWNw3Z7/M2UFHkWULMPYfezAUclTqdcMLTWNlWHugF2GJ8CTyrCTErV+ABKA
f3awAB2rga2+gIwHiBtqPcepw8e0iFfzG3/NmQh2Q3+q6FwAgUyQL5NUzZI9GBqX
xcwFJ2Y1OtMKvlJapHntZSXrwcj8uZvGC1DG+Srf0b+LF5JZUslp1F/aNPwHgpq/
GxM32EXtCHCN9w1BMlqrQSr1RE9NVKdcy43XEYSMA8D865+YqkHBnjylPrz5o+Q3
+r4iumNTBeyts7m4wWCcBHaFQCJJGsuy/JLcWQVTmq2zX3Y17atQh5UX83dzphP+
L8t3A0DXKdpJrbt0TcaxaYOaMcSp6eP+Two9UBRH3lJQzjydO70s2+YzyO55buJJ
pjMZ1OAX/VH5NpNPWQlLUPWuZO9FlOarjYbg91DZtIEXf1d1/rTQ8edM/tbtq75Q
pUPjmePbp6rw3y2AI4WF
=MLZo
-----END PGP SIGNATURE-----

Re: Re: [gentoo-dev] First release of Gentoo Keys

[Andreas K. Huettel]

Am Dienstag 13 Januar 2015, 07:54:16 schrieb Andrew Savchenko:
> On Mon, 12 Jan 2015 18:48:41 +0000 Ciaran McCreesh wrote:
> > On Mon, 12 Jan 2015 19:44:46 +0100
> > 
> > Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> > > Shor's would be effective against discrete logs (including ECC) as
> > > well, so wouldn't be applicable to this selection. For post-quantum
> > > asymmetric crypto we'd likely need e.g a lattice based primitive.
> > 
> > We're not post-quantum,
> 
> Are you sure? The simplest Shor's factorisation machine was already
> built and published in open press:
> http://arxiv.org/abs/quant-ph/0112176
> This was done 14(!!) years ago. I don't doubt there was a
> significant progress in this field thereafter. But it is likely
> that results are classified.

Lieven's paper 2001 was a milestone but the technology in this case 
fundamentally didn't scale. So, while there certainly have been advances, they 
aren't directly based on it, but on completely different experimental 
approaches.

http://web.physics.ucsb.edu/~martinisgroup/
If there's any place to look for technological advances, then ^ here.

(No, not d-wave either. IMHO.)

-- 
Dr. Andreas K. Huettel
Institute for Experimental and Applied Physics
University of Regensburg
D-93040 Regensburg
Germany

tel. +49 151 241 67748 (mobile)
e-mail andreas.huettel@ur.de
http://www.akhuettel.de/
http://www.physik.uni-r.de/forschung/huettel/

Re: [gentoo-dev] First release of Gentoo Keys

[Chí-Thanh Christopher Nguyễn]

Andrew Savchenko schrieb:
> On Mon, 12 Jan 2015 19:44:46 +0100 Kristian Fiskerstrand wrote:
>> Shor's would be effective against discrete logs (including ECC) as
>> well, so wouldn't be applicable to this selection. For post-quantum
>> asymmetric crypto we'd likely need e.g a lattice based primitive.
> Why not to use post-quantum signing together with a traditional one?

Indeed. Problem is that so-called post-quantum cryptosystems are 
sometimes not even secure against non-quantum computers. I remember back 
when NTRU was the latest hotness, and the breaking and fixing ping-pong 
that security researchers played between conferences with it, 
particularly with the signature part.

None of these has stood the test of time like RSA or DLP-based crypto. 
If post-quantum signing is desired, I agree that it should be strongly 
considered using it in addition to traditional signing.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] First release of Gentoo Keys

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

On Tue, 13 Jan 2015 13:36:01 +0100 Chí-Thanh Christopher Nguyễn
wrote:
> Andrew Savchenko schrieb:
> > On Mon, 12 Jan 2015 19:44:46 +0100 Kristian Fiskerstrand wrote:
> >> Shor's would be effective against discrete logs (including ECC) as
> >> well, so wouldn't be applicable to this selection. For post-quantum
> >> asymmetric crypto we'd likely need e.g a lattice based primitive.
> > Why not to use post-quantum signing together with a traditional one?
> 
> Indeed. Problem is that so-called post-quantum cryptosystems are 
> sometimes not even secure against non-quantum computers. I remember back 
> when NTRU was the latest hotness, and the breaking and fixing ping-pong 
> that security researchers played between conferences with it, 
> particularly with the signature part.

I think this is a problem of all new crypto solutions: they are
likely to have flaws at both theory/model and implementation. But
using them as addition (on AND basis) doesn't hurt security.
However, as was pointed out in another reply, management overhead
(second keypair, signature and web of trust) is considered as too
much now.

> None of these has stood the test of time like RSA or DLP-based crypto. 
> If post-quantum signing is desired, I agree that it should be strongly 
> considered using it in addition to traditional signing.



Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] First release of Gentoo Keys

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Tue, 13 Jan 2015 12:10:47 +0100 Andreas K. Huettel wrote:
> Am Dienstag 13 Januar 2015, 07:54:16 schrieb Andrew Savchenko:
> > Are you sure? The simplest Shor's factorisation machine was already
> > built and published in open press:
> > http://arxiv.org/abs/quant-ph/0112176
> > This was done 14(!!) years ago. I don't doubt there was a
> > significant progress in this field thereafter. But it is likely
> > that results are classified.
> 
> Lieven's paper 2001 was a milestone but the technology in this case 
> fundamentally didn't scale. So, while there certainly have been advances, they 
> aren't directly based on it, but on completely different experimental 
> approaches.
> 
> http://web.physics.ucsb.edu/~martinisgroup/
> If there's any place to look for technological advances, then ^ here.
> 
> (No, not d-wave either. IMHO.)
 
Thanks for the link, I'll study it.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]