Re: gpg2 export-secret-key if no master key present

[Damien Goutte-Gattat]

On 12/13/2016 10:12 AM, Marat Stanichenko wrote:
Hello,


Could you please elaborate what exactly is returned in the former and
the latter cases?


In the former case (in the absence of the secret primary key), the 
--export-secret-keys command will still export a secret packet key 
corresponding to the missing key, but it will be marked as a "dummy key".


Try running the following command:

  $ gpg2 --list-packets secret-key

You should see (among other things) something like the following:

  :secret key packet:
  version 4 [...]
  pkey[0]: [ bits]
  pkey[1]: [ bits]
  gnu-dummy S2K, algo: 0, simple checksum, hash: 0

The "gnu-dummy S2K" is the marker which will tell GnuPG that this file 
does *not* actually contain the secret key.




What command one should run to get the private master key properly to
save with paperkey afterwards?


I would just use

  $ gpg2 --homedir=/my/save/place --export-secret-keys | paperkey | lpr

(the last command "| lpr" would send the output directly to the printer).

This would export both the primary key and all the subkeys. If you want 
to save with paperkey only the primary key, specify its ID and append a 
'!' at the end:


  $ gpg2 --homedir=/my/save/place --export-secret-keys '0xABCDEF10!' \
| paperkey | lpr


Hope that helps,

Damien



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

Re: An attempt at backporting 2.1.16 from Debian sid to Debian jessie

[Peter Lebbing]

On 08/12/16 21:42, Stephan Beck wrote:
> [...], so I don't see the real need for a forced coexistence of the two
> (or three) versions on Jessie.

I did that because all the software in jessie that depends on GnuPG 1.4
might not work with GnuPG 2.1. So by doing it like this, I'm not
breaking any packages that have the package "gnupg" in their dependency
tree.

Cheers,

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 

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

Re: Hybrid keysigning party, your opinion?

[Peter Lebbing]

On 12/12/16 06:27, Lachlan Gunn wrote:
> My apologies if I came across as overly harsh.

Oh, not at all, I hadn't even noticed one could see it that way.

. What I meant was that it
> took me a little bit of time to work out exactly what you meant, so
> someone unfamilar with the web of trust will probably not follow
> exactly;

This was a mail to a crypto-mailing list asking cryppies for advice on
how to cripple... er... subvert a certain setup. Totally different audience!

> One last thought: This may be naïvely optimistic, but if everyone
> finishes at the same time then you can always do a second confirmation
> of the list-hash at the end for people who are late to the session.

Hmm, interesting idea. Could be possible.

>  Or
> if you're into arts and crafts, give them a copy of the master hash on
> overhead transparency that they can use to very quickly check against
> someone else's.

Or hang a truly huge printout on the wall and at the start of the
session, together observe that it is correct. Any latecomers can be told
"look, everybody thinks it's completely normal that we have a 64 digit
hex code on the wall, and that's because we all agreed it's the right one".

Cheers,

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 

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

Re: Hybrid keysigning party, your opinion?

[Peter Lebbing]

On 12/12/16 07:02, Lachlan Gunn wrote:
> Also, while I promised to forever hold my peace, you might want to give
> people a a programmatic way to make the scrubbed list so that those who
> print their own don't need to manually verify it.

If they want to have a known good copy, they can just print the detailed
list!

They then also have the opportunity to have gpgsigs annotate it with the
signatures they already did at an earlier keysigning party, saving them
the trouble of re-identifying someone for nothing. (Note that not all
people consider this "for nothing", some actually like to have a new
signature).

> The //d (rather
> than s///) is important because unless it makes the list shorter, there
> isn't any incentive to go to the trouble :)

I chose to replace them by empty lines so the lists still line up if you
choose the screen font to be a similar size as the printed font. I will
be literally holding my paper list next to my monitor, it's useful if
they line up and all information that is the same looks exactly the
same. You spot errors much quicker that way.

Thanks for your thoughts,

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 

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

Expiration of subkeys (was: Strange behaviour)

[Peter Lebbing]

On 12/12/16 21:09, Stephan Beck wrote:
> Well, the specific reason is that best practices exclude the usage of
> sub keys without any expiry.

There's nothing inherently wrong with non-expiring subkeys. Without
knowing the threat model, I don't see a reason to either start using
expiring subkeys *or* stop using them.

Coincidentally, expiration of subkeys by default was just discussed on
gnupg-devel; you might be interested in that little thread: [1]. If you
want to read the whole thread[2], not just this subthread, note that
Robert J. Hansen's contribution[3] went to gnupg-users instead of
gnupg-devel.

I recommend reading Robert's message anyway, since it also deals with
the whole concept of "best practices" in general. It's a good post and
apt here as well.

> See the FSFE's instructions in the known
> Offline master key and multiple subkeys on smart card guide (or similar,
> don't have the link right now).

When I did a quick look-see, I found that their recommended Card
HOWTO[4] actually creates a non-expiring key.

I don't know which intended public the FSFE's instructions have, or what
threat models they considered.

> The OP holds a main key without expiry date. In
> such a case, I'd set an expiry date on subkeys.

I'd set an expiry on the main key, or trust the OP to guard his
revocation certificate well (in the sense of not losing it).

HTH,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032328.html

[2] https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032298.html

[3] https://lists.gnupg.org/pipermail/gnupg-users/2016-December/057229.html

[4] http://wiki.fsfe.org/TechDocs/CardHowtos/CardWithSubkeysUsingBackups

-- 
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 

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

gpg2 export-secret-key if no master key present

[Marat Stanichenko]

Hello,


I created a master gpg key and an additional signing subkey. I also
backed up the whole .gnupg directory
to /my/save/place and deleted the primary key from the original .gnupg
directory by simply removing the
corresponding file under the private-keys-v1.d.

So far so good, gpg2 -K shows a sec# instead of sec and gpg2
--homedir=/my/save/place -K shows sec as expected.

However, if I run

 $ gpg2 --export-secret-keys --armor > secret-key

and

 $ gpg2 --homedir=/my/save/place --export-secret-keys --armor >
secret-key-original

both commands return something of similar size. Although results are different.


Could you please elaborate what exactly is returned in the former and
the latter cases?

What command one should run to get the private master key properly to
save with paperkey afterwards?


Many thanks in advance!

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