Re: A Quick Supplement

[Werner Koch]

On Tue, 18 Jul 2017 22:49, r...@sixdemonbag.org said:

> random_seed is internal data belonging to the PRNG.

That is right.  However we always add at least 128 bit of fresh random
which would be enough - at least on all systems with /dev/random or on
Windows.  It is just that we are ultra-conservative and use a huge state
of 4800 bits.  The random_seed file gives an initial value to that
state.  From a pure mathematical point of view the 128 bits we always
add are enough.  For key generation we have even stronger requirements.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpqR3niAxD9H.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[Robert J. Hansen]

> Ah, you got me ;-) So you are a developer?

In my day job I'm a developer, among other things.  However, due to my
taking research funding from the U.S. government in the past, I do not
contribute code to either GnuPG or Enigmail.  I find other, non-code,
ways to help the GnuPG and Enigmail teams.

> Thank you for all you do for the computing community and for taking
> the time to answer my emails in a very amicable manner.

You're quite welcome.  :)


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[Daniel Villarreal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/18/17 08:36, Robert J. Hansen wrote:
>> ... shouldn't the focus of GnuPG be on security?
> 
> This *is* a security issue.

Since you put it that way, I agree.


> Some ... GnuPG use a ... "random_seed"... must not be backed up or
>  shared ...

And thanks for pointing that out.


> ... Click Enigmail -> About and see if you spot any familiar names
>  there. Maybe Enigmail's usability guy, who's had to wrestle with 
> the problems of importing and exporting keyrings, will have some 
> interesting thoughts.  :)

Enigmail is developed by the Enigmail Team:
...
Usability: Robert J. Hansen

Ah, you got me ;-) So you are a developer?


> Yep [...] [Re: GnuPG FAQ] It's a pretty good FAQ ...

"GNUPG FREQUENTLY ASKED QUESTIONS
Robert J. Hansen et al."

You got me, again !

BTW, Mozilla Firefox on multiple OS's mangled gnupg-faq.txt (was
showing some garbled characters) until I did this modification ...

View -> Text Encoding -> Western
changed to Unicode
and everything shows properly.

> I do not contribute code to GnuPG -- once upon a time I worked on 
> U.S. government contracts, so it's best for the GnuPG project if I
>  don't contribute code.  I still find other ways to contribute, 
> whether that means non-core code contributions (Sherpa), 
> documentation (the FAQ), usability issues (Enigmail), etc.

Thank you for all you do for the computing community and for taking
the time to answer my emails in a very amicable manner.

- -- 
Daniel Villarreal
http://www.youcanlinux.org
youcanlinux at gmail.com
PGP key 2F6E 0DC3 85E2 5EC0 DA03  3F5B F251 8938 A83E 7B49
https://pgp.mit.edu/pks/lookup?op=get=0xF2518938A83E7B49
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJZbqyjAAoJEPJRiTioPntJXGQH/21aD65Z+EiS1g/L1x8K9Cni
38p96LX7dedjizMBC9JMHl5+imE+jhYQ+bEqbC2A85Qo4FdtRQ49nl9JJyUAKq/Y
tVA68SlOTqiX4SxYI+tJ/FvPVK10LT3j5bFsH0Lfi6IyTjAM3Xne2cxEbvQmnLw/
KykKYGiiXhrFp7ne854/J4ka1VdRPezJBAfssmgtrh7s26WSF9GQ9kj/B4q5dHGZ
xiiZkncgm1B0RQo5ya1/wMvHIRzBXcj9BFtA/rcFONjd1QVHMn9R9zpfBrlToPEj
qzN66OdNBMeVRKiYmkm2BU2NzGt1vGUpevZnHkrFnemmZcFG9hWL5Byhbnogyd0=
=jBO6
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[Robert J. Hansen]

> Sorry if I'm asking dumb questions

Not a dumb question.

> what would be wrong with sync'ing the whole gnupg directory (or the
> whole user profile / home directory) with rsync/duplicity/whatever ?

There are a number of lockfiles, sockets, etc., that live in the
~/.gnupg directory which shouldn't be copied.

> Also, can you point me to a more in-depth explanation on the security
> implications of re-using random_seed? I can imagine what you mean, but
> I'd like to know more.

No, because GnuPG has a ton of different pseudorandom number generators
that it can use.  An in-depth explanation would require knowing specific
versions of your operating system, possibly even which chipsets you're
using (hardware accelerators, etc.) -- and at that point I'm going to
start charging you my consulting rates.  :)

In a nutshell, though: a pseudorandom number generator has some internal
data that it uses to generate the sequences.  If you restore the PRNG to
an earlier state, it'll generate the same numbers over again... at which
point, they're really not random any more.

random_seed is internal data belonging to the PRNG.

Don't share it.  :)


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[Andreas Heinlein]

Am 18.07.2017 um 15:36 schrieb Robert J. Hansen:
>
>> While it would be nice if it were easier to be able to back up easily
>> as you're suggesting, shouldn't the focus of GnuPG be on security?
> This *is* a security issue.
>
> Some versions of GnuPG use a file called "random_seed", for instance.
> This file contains material for seeding a random number generator, and
> for that reason it must not be backed up or shared between computers: if
> the file doesn't exist it'll be recreated, but if it does... then you've
> just reused RNG seeds on two different computers, which has the
> potential to dramatically reduce the cryptographic security of the code.
>
> If you don't make it easy to back up keys, people won't back up their
> keys.  Then, any minor disaster has the possibility of irreparably
> wrecking their keys and the Web of Trust connections they've carefully
> created.  Disaster recovery is an important part of security, too.
Sorry if I'm asking dumb questions, but given that a) I am using the
same GnuPG version on all machines and b) I am excluding random_seed,
what would be wrong with sync'ing the whole gnupg directory (or the
whole user profile / home directory) with rsync/duplicity/whatever ?

Also, can you point me to a more in-depth explanation on the security
implications of re-using random_seed? I can imagine what you mean, but
I'd like to know more.

Thanks,
Andreas



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[NdK]

Il 18/07/2017 14:23, Daniel Villarreal ha scritto:

> Have you ever asked Werner about what he thinks about "ease" of
> backing up?"
Security = confidentiality + integrity + availability

If you're not considering availability, you only can have partial security.

BYtE,
 Diego

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[Robert J. Hansen]

> Have you ever asked Werner about what he thinks about "ease" of
> backing up?"

I have made these observations before, yes.

> While it would be nice if it were easier to be able to back up easily
> as you're suggesting, shouldn't the focus of GnuPG be on security?

This *is* a security issue.

Some versions of GnuPG use a file called "random_seed", for instance.
This file contains material for seeding a random number generator, and
for that reason it must not be backed up or shared between computers: if
the file doesn't exist it'll be recreated, but if it does... then you've
just reused RNG seeds on two different computers, which has the
potential to dramatically reduce the cryptographic security of the code.

If you don't make it easy to back up keys, people won't back up their
keys.  Then, any minor disaster has the possibility of irreparably
wrecking their keys and the Web of Trust connections they've carefully
created.  Disaster recovery is an important part of security, too.

> Werner's company has working for it someone working on Enigmail, which
> lets you do key management, including importing and exporting.

Click Enigmail -> About and see if you spot any familiar names there.
Maybe Enigmail's usability guy, who's had to wrestle with the problems
of importing and exporting keyrings, will have some interesting
thoughts.  :)

> Werner Koch co-founded Free Software Foundation Europe.

So?  He could've been the first man to walk on Mars: it would have no
bearing on whether the difficulty of backing up keyrings is a problem
that needs to be addressed.

> Everyone has the opportunity to make GnuPG better, see the following
> link...

Yep.  Sections 3.8, 3.9, and 3.10 of the FAQ mention this.  You might
also want to check out section 1.2.  It's a pretty good FAQ; someone
clearly put a lot of work into it.  :)

https://www.gnupg.org/faq/gnupg-faq.html

I do not contribute code to GnuPG -- I could: I'm a fairly good C
cryptographic engineer with a strong security background.  However, once
upon a time I worked on U.S. government contracts, so it's best for the
GnuPG project if I don't contribute code.  I still find other ways to
contribute, whether that means non-core code contributions (Sherpa),
documentation (the FAQ), usability issues (Enigmail), etc.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[Daniel Villarreal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/17/17 08:54, Robert J. Hansen wrote:
>> I'm not sure if Rob's routine actually backs up local 
>> signatures... I couldn't see anything explicit about it with a 
>> quick glance at the code. That's fine if you don't use local 
>> signatures at all.
> 
> The step-by-step process I posted last year didn't, because I
> don't use them in my own local policy and thus didn't think about
> them (oops).
> 
> Sherpa doesn't, because GPGME doesn't support the exporting of 
> local signatures.
> 
> It is infuriatingly difficult to come up with a backup method that
>  applies across GnuPG 1.4 - 2.1, is crossplatform, is safe
> (doesn't copy random_seed, etc.), and so on.  Ease of backing up
> has never been a high priority for the GnuPG devs, and it shows.

Have you ever asked Werner about what he thinks about "ease" of
backing up?" He is very accessible on this list, and he often points
out nuances of the coding, versions, etc., and he's very good about
clarifying what people bring up on the list.

While it would be nice if it were easier to be able to back up easily
as you're suggesting, shouldn't the focus of GnuPG be on security?

Werner's company has working for it someone working on Enigmail, which
lets you do key management, including importing and exporting.

Werner Koch co-founded Free Software Foundation Europe.
Everyone has the opportunity to make GnuPG better, see the following
link...
http://fsfe.org/about/basics/freesoftware.en.html

My experience with customer support for German speakers is that the
customers actually study their user documentation very thoroughly
before calling in for help. Let that sink in for a moment.

- -- 
Daniel Villarreal
http://www.youcanlinux.org
youcanlinux at gmail.com
PGP key 2F6E 0DC3 85E2 5EC0 DA03  3F5B F251 8938 A83E 7B49
https://pgp.mit.edu/pks/lookup?op=get=0xF2518938A83E7B49
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJZbf23AAoJEPJRiTioPntJGXMH/iiCs9EgndE8bKtLMUmvIW0O
1NkHYZ+RaDQuBs1fkVGN8jSoIKR9rBipJIuCpGm+CIQQzVyjHCaTc+oGZI/ILpSY
8t1jAmWkgoWWDHICokGSSC6HAxV3inbHEqGwq6LHNavTg2jVuo2UbZmDbjhFJUmD
DOOKOMAeeDaENiJRCWddx416rG/PqeHnzN1ZZmeYI/RJNzCIbR7XSq1NRlYkf4q4
HmT854z0tyndQ2KzDAXK9XHCnA80Elcs4L7nMGqlwKV0cPaBpits9PutsuZps4Yb
qM38aTB5KXPIOfls43cpsEfOhh2ixFUpQDNgk11q9OzWK2eJhQoENIe6KK/t4gU=
=j5pt
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[Robert J. Hansen]

> Please note that  while I greatly appreciate that Mr. Hansen wrote a
> program to handle this, I still like having the option of doing things
> manually.

At risk of sounding arch and caustic -- which I'm not; it's just that
reality is going to sound arch and caustic -- go for it: just remember
that it's a long complex that requires some command-line juggling that's
beyond the skills of the majority of users, and this is something you
really don't want to get wrong.

If you feel you have the necessary skills to safely do it at the command
line, knock yourself out.  But if you don't, please use the tool.  It
will save you a lot of frustration.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[Peter Lebbing]

On 17/07/17 01:50, Daniel Villarreal wrote:
> Are you recommending...
> [...]
> instead of

Yes, instead of, not in addition to. The export-local-sigs will add the
local sigs, the other non-local sigs will still be there as well.

> And this all functions with gpg2 in place of gpg ?

Yes, just use what you want to use, GnuPG v1.4, v2.0 and v2.1 all
support it, if I remember correctly.

> Please note that  while I greatly appreciate that Mr. Hansen wrote a
> program to handle this, I still like having the option of doing things
> manually.

I'm not sure if Rob's routine actually backs up local signatures... I
couldn't see anything explicit about it with a quick glance at the code.
That's fine if you don't use local signatures at all.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A Quick Supplement

[Daniel Villarreal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/14/17 13:56, Peter Lebbing wrote:
> There's an option missing that could cause data loss in its 
> absence:
> 
> $ gpg --armor --export > pub.asc
> 
> I'd make that:
> 
> $ gpg --armor --export-options export-local-sigs --export >pub.asc
> 
> If you have made any signatures that are not exportable (so lsign 
> and friends), they would not be exported otherwise. That is 
> obviously what it is for, but if you do this to make a backup of 
> your own keyring, you would still want to keep those.
> 
> And symmetrically, you'll want
> 
> $ gpg --import-options import-local-sigs --import pub.asc

Are you recommending...

$ gpg --armor --export-options export-local-sigs --export >pub.asc

instead of

$ gpg --armor --export > pub.asc

and

$ gpg --import-options import-local-sigs --import pub.asc

instead of

$ gpg --import < pub.asc

?

Or should
$ gpg --import-options import-local-sigs --import pub.asc
$ gpg --armor --export-options export-local-sigs --export >pub.asc
$ gpg --import-options import-local-sigs --import pub.asc
$ gpg --import < pub.asc
all be done?


And this all functions with gpg2 in place of gpg ?

Please note that  while I greatly appreciate that Mr. Hansen wrote a
program to handle this, I still like having the option of doing things
manually.

Thanks!


Originally referencing this email...

- -- begin quote --
-  Forwarded Message 
Subject: RE: What is a reliable way to backup/restore my keys and test?
Date: Wed, 14 Sep 2016 15:01:47 -0400
From: Robert J. Hansen 
To: 'Duane Whitty' , gnupg-users@gnupg.org

> I am relatively new to GNUPG so my apologies in advance if this >
question is trivial.

Welcome!  And your question is not trivial.

The following is the procedure I use on UNIX systems:

First, export all public certificates into a public keyring:

$ gpg --armor --export > pub.asc

Second, export all secret certificates into a secret keyring:

$ gpg --armor --export-secret-keys > priv.asc

Third, export ownertrust values and save those:

$ gpg --armor --export-ownertrust > trust.asc

Fourth, copy all the *.conf files in ~/.gnupg into your current director
y:

$ cp ~/.gnupg/*.conf .

Fifth,  put these, and all your GnuPG .conf files, all into a single
archive:

$ tar cJf gpg-backup.txz pub.asc priv.asc trust.asc *.conf

Copy gpg-backup.txz to the new machine.  Once you've done that,
uncompress it on the new machine:

$ tar xJf gpg-backup.txz

Import your secret certificates:

$ gpg --import < priv.asc

Import your public certificates:

$ gpg --import < pub.asc

Import your ownertrust values:

$ gpg --import-ownertrust < trust.asc

Make sure your ~/.gnupg directory exists.  If it doesn't, run gpg with
no arguments and hit Ctrl-C to break out of it.

$ gpg

Copy your .conf files into ~/.gnupg:

$ cp *.conf ~/.gnupg

... And at that point you should be done.  This technique should work
regardless of whether you're migrating from 1.4 to 2.0, 1.4 to 2.1,
2.0 to 1.4, 2.0 to 2.1, 2.1 to 2.0, or 2.1 to 1.4.  No matter which
you're doing, you're covered.

> I've just copied my .gnupg directory to a usb key as a backup 
> measure, which I found as a method (more or less) on 
> http://www.glump.net/content/gpg_intro/.

It's a good idea to not copy the random_seed file.  PRNG states should
not be shared between computers.

> How can I make sure my private key and trust assignments were 
> copied properly?

Follow the above process and they will be.  Your private certificates
were exported, as were the trust assignments.

> Once I have completed my OS upgrade how do I restore my keys and 
> the trust levels assigned to them?

See the above process.

> I use Thunderbird/Enigmail which is using gpg2 but I originally 
> created my key pair using gpg 1.4.  Does this have any 
> ramifications?

None.

- --end quote--


- -- 
Daniel Villarreal
http://www.youcanlinux.org
youcanlinux at gmail.com
PGP key 2F6E 0DC3 85E2 5EC0 DA03  3F5B F251 8938 A83E 7B49
https://pgp.mit.edu/pks/lookup?op=get=0xF2518938A83E7B49
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJZa/vbAAoJEPJRiTioPntJN1MH/RHi9MV3CWHPZp7AOHVDfWmI
l4AOaEBs+2CRbW5jj6w6eI+LV5/IsDSmBMNEoPab7iOLdgzxc6SsTL4KjqK+9Imy
kaOHyPTiMJ99GfOpCM9iZ7OuCsavUEWqw8JN/gtBBT561LA+NxZCUrrOkyZyWBCt
pKpSI7cPtPyNe2VC7jrX4M/+SEwhzC1TmaCeXNoyBq3cTPwKPmGDuebfuv76/SVa
1HE5P/iCIDHZ+jxVWgsY2VTiOpifWN+ht54cc2MRZPkPC6KjSktIcuevo+ZDWw4+
QrR0tyn0fyNXHzJEhSie6v4wdM1QnEC6R34JR83LGMRxiH3820mrRyTmJFmvkxA=
=PMER
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

A Quick Supplement

[Peter Lebbing]

There's an option missing that could cause data loss in its absence:

$ gpg --armor --export > pub.asc

I'd make that:

$ gpg --armor --export-options export-local-sigs --export >pub.asc

If you have made any signatures that are not exportable (so lsign and
friends), they would not be exported otherwise. That is obviously what
it is for, but if you do this to make a backup of your own keyring, you
would still want to keep those.

And symmetrically, you'll want

$ gpg --import-options import-local-sigs --import pub.asc

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users