[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

[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

[Rich Freeman]

Post by Brian Dolbec
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.

[Peter Stuge]

Post by Rich Freeman
gpg --gen-key
option 2 - DSA and Elgamal

Watch that entropy.


//Peter

[Brian Dolbec]

On Sun, 11 Jan 2015 12:06:18 -0500

Post by Rich Freeman

Post by Brian Dolbec
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.
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,...

[Rich Freeman]

Post by Brian Dolbec
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.

Post by Brian Dolbec
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.

Post by Brian Dolbec
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. :)

[Brian Dolbec]

On Sun, 11 Jan 2015 20:55:29 -0500

Post by Rich Freeman

Post by Brian Dolbec
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]

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.

[Andrew Savchenko]

Post by Brian Dolbec
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
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

[Kristian Fiskerstrand]

Post by Rich Freeman

Post by Brian Dolbec
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.

Post by Brian Dolbec
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

[Kristian Fiskerstrand]

Post by Brian Dolbec

On Sun, Jan 11, 2015 at 11:43 AM, Brian Dolbec

Post by Brian Dolbec
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

[Rich Freeman]

Post by Kristian Fiskerstrand
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).

[Kristian Fiskerstrand]

On Mon, Jan 12, 2015 at 1:06 PM, Kristian Fiskerstrand

Post by Kristian Fiskerstrand
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

[Ciaran McCreesh]

On Mon, 12 Jan 2015 19:44:46 +0100

Post by Kristian Fiskerstrand
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?

[Rich Freeman]

On Mon, Jan 12, 2015 at 1:48 PM, Ciaran McCreesh

Post by Ciaran McCreesh
On Mon, 12 Jan 2015 19:44:46 +0100

Post by Kristian Fiskerstrand
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.

[Andrew Savchenko]

Post by Ciaran McCreesh
On Mon, 12 Jan 2015 19:44:46 +0100

Post by Kristian Fiskerstrand
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

Post by Ciaran McCreesh
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

[Andreas K. Huettel]

Post by Andrew Savchenko

Post by Ciaran McCreesh
On Mon, 12 Jan 2015 19:44:46 +0100

Post by Kristian Fiskerstrand
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
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. [phone] (mobile)
e-mail ***@ur.de
http://www.akhuettel.de/
http://www.physik.uni-r.de/forschung/huettel/

[Andrew Savchenko]

Post by Andreas K. Huettel

Post by Andrew Savchenko
Are you sure? The simplest Shor's factorisation machine was already
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

[Andrew Savchenko]

Post by Kristian Fiskerstrand

On Mon, Jan 12, 2015 at 1:06 PM, Kristian Fiskerstrand

Post by Kristian Fiskerstrand
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

[Kristian Fiskerstrand]

Post by Andrew Savchenko

Post by Kristian Fiskerstrand

On Mon, Jan 12, 2015 at 1:06 PM, Kristian Fiskerstrand

Post by Kristian Fiskerstrand
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).

Post by Andrew Savchenko
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

[Chí-Thanh Christopher Nguyễn]

Post by Andrew Savchenko

Post by Kristian Fiskerstrand
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

[Andrew Savchenko]

On Tue, 13 Jan 2015 13:36:01 +0100 Chí-Thanh Christopher Nguyễn

Post by Chí-Thanh Christopher Nguyễn

Post by Andrew Savchenko

Post by Kristian Fiskerstrand
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.

Post by Chí-Thanh Christopher Nguyễn
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