Re: fingerprint of key

[Daniel Kahn Gillmor]

On Thu 2017-08-17 22:39:21 -0300, Duane Whitty wrote:
> Sounds like a good approach but for someone who has more public keys
> stored than me.  I only exchange encrypted email with a very, very
> small group of people and I am in regular voice communication with
> them.

If you're going to manage a keyring manually, this is the right way to
do it, regardless of how many OpenPGP certificates you have in your
keyring.  (it's actually easier to do when you only have a few)

> I guess using that approach I could import public keys from users on
> this list and then assign them various levels of trust, right down to
> no trust and not locally signed at all.

Note that nothing i outlined in my earlier suggestions involved you
setting "trust levels" (a.k.a. "ownertrust") at all.

setting "full trust" on a key means "i'm willing to accept identity
assertions made by the owner of this key" -- it's equivalent to "adding
a root CA to your browser" in some sense.

You can use GnuPG for years without ever setting any sort of ownertrust
on any key but your own (and if you generated your key in gpg, it
probably already has ultimate ownertrust).

Start with "whose keys do i believe i've checked?" -- that's plain
keysigning.

then, only later, if you really want to get into the whole web-of-trust
thing, should you consider setting ownertrust.

> I suppose I chose to use apt or apt-get because it seems like a more
> convenient way to update things as opposed to getting it straight from
> Oracle.

well said :)

> What I mean is that I have 2 email addresses which each have a
> different private key.  The key for du...@nofroth.com has is
> associated with private counterpart to the key you fetched.  I have
> another email address with a different private key associated to it.

i see, so you're talking about signing with a different key (not a
different uid).  You might want to look into adding the --default-key or
--local-user options before you do your next --edit-key operation.

All the best,

--dkg


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

Re: Is it possible to certify (sign) a key using a subkey?

[Daniel Kahn Gillmor]

On Thu 2017-08-17 19:47:16 -0500, Mario Castelán Castro wrote:
> I have chosen RSA as a “known good” algorithm for the primary key
> because if I chose a different curve or algorithm for elliptic key once
> I have the required knowledge to make an informed decision it will be
> more convenient to change only a subkey than to generate a new primary
> key. For example, I can keep the signatures (certifications) that I
> accumulate during that time on my key, supposing I have the opportunity
> to go to a signing party.

I still don't think this is a good justification, fwiw.  If you think
you'll be making these certifications for other people to consume,
please do those other people a favor and just use your primary key.
The OpenPGP world has a habit of trying to make things too fancy.  Keep
it simple!

> Also, using a subkey for signing still has a size advantage. If you
> have, say, 5 keys signed by my ECC subkey. there will be less size

Where are you trying to save these bytes?

> Anyway, my question still stands: How can I enable the certificate
> capability on a subkey with GPG?

I don't know of a way to change usage flags on an existing subkey with
GnuPG without modifying the source.

You can add a new subkey with your chosen usage flags in --expert mode,
though.  But i don't recommend it.

--dkg

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

Re: fingerprint of key

[Daniel Kahn Gillmor]

On Thu 2017-08-17 22:48:36 -0300, Duane Whitty wrote:
> Well, I'm not familiar enough with the arcana to say whether it should
> be done away with or not but, I am a big believer in software not
> trying to guess what I want.  As you said, in version 2.1 GnuPG would
> have complained that I hadn't entered a command, correct?  Does this
> also mean it would have not carried out any action.

nope, GnuPG took the conservative approach and just produced a warning
while still trying to make a guess at what you meant.

> I have to admit to being a little hesitant making these types of
> comments because I don't feel I contributed enough (if anything) to
> have earned that right.  But perhaps as a user the comment is a small
> contribution.  I hope it is seen that way and not as a complaint.

Please don't underestimate the value of suggestions and questions from a
user.  Free software gets better because its users talk about it and
share ideas about how it can improve.  You don't need to have
contributed code to contribute ideas :)

--dkg

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

Re: Is it possible to certify (sign) a key using a subkey?

[Mario Castelán Castro]

On 17/08/17 18:49, Daniel Kahn Gillmor wrote:
> aiui, your main goal was because the certifications are smaller, but
> you're still requiring people to fetch your larger primary key.  if you
> want to really minimize the size, just make a new OpenPGP key that is
> ECDSA-only.

I have chosen RSA as a “known good” algorithm for the primary key
because if I chose a different curve or algorithm for elliptic key once
I have the required knowledge to make an informed decision it will be
more convenient to change only a subkey than to generate a new primary
key. For example, I can keep the signatures (certifications) that I
accumulate during that time on my key, supposing I have the opportunity
to go to a signing party.

Also, using a subkey for signing still has a size advantage. If you
have, say, 5 keys signed by my ECC subkey. there will be less size

Anyway, my question still stands: How can I enable the certificate
capability on a subkey with GPG?

Regards.



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

Re: fingerprint of key

[Duane Whitty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 17-08-17 09:20 PM, Daniel Kahn Gillmor wrote:
> On Mon 2017-08-14 22:12:18 -0300, Duane Whitty wrote:
>> Actually one suggestion, the way options and commands are
>> specified look the same.  It might make things clearer if there
>> was a difference in the way they are expressed on the command
>> line.  Perhaps keep the "--" for options and enter commands
>> without the "--".
> 
> I also prefer this kind of "subcommand" syntax -- it matches what
> tools like git and notmuch use.  However, that's a pretty radical
> departure from the historical GnuPG command line, and it's likely
> to break all sorts of existing things that expect to use the
> canonical interface.
> 
> If we're going to make radical departures like that, perhaps we
> should be specifying an entirely new interface that just does "the
> sensible bits" without all the rest of the arcana.
> 
> --dkg
> 
Well, I'm not familiar enough with the arcana to say whether it should
be done away with or not but, I am a big believer in software not
trying to guess what I want.  As you said, in version 2.1 GnuPG would
have complained that I hadn't entered a command, correct?  Does this
also mean it would have not carried out any action.  In my opinion
that would be the correct behaviour.  I am also a fan of the Unix
tradition of software that completes without error not having any
output unless you have asked for output.  Error output going to stderr
of course :-)

I have to admit to being a little hesitant making these types of
comments because I don't feel I contributed enough (if anything) to
have earned that right.  But perhaps as a user the comment is a small
contribution.  I hope it is seen that way and not as a complaint.

Best Regards,
Duane

- -- 
Duane Whitty
du...@nofroth.com
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJZlkdxAAoJEOJfpr8UVxtkwXwIAKg6U2hJM2v0469V3Q+dr2k8
6cn8+6nwdkARZQhABP+iSOLbFcnaGL2RLzw26+47E3pqf1X837VeHnsdBZvzQYTQ
oXB/0YTmhjsjL6hpN1V5N5+CHkmMwbwyoHD7XGFpETA/1RfgrhlkqUtcfqjBCUw6
zAvUeD6/rxhASeBb1A231924iSUFqqhkf0IXGvgJmrmIU2hPCZPkdwnxEQ+Lm5K5
8AhsnEKdE3mABlqr0mMM/uuYLI1bknxYT2QtIU2Q1gwH0af4+WqLdcv9H4dMAmQS
HYfYv8s8MAyoqPNZs2QXOg76TBhPHF382MYLGCzT9rHMWaRLk/6zmCZKOSiGtO0=
=5mpS
-END PGP SIGNATURE-

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

Re: fingerprint of key

[Duane Whitty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 17-08-17 09:18 PM, Daniel Kahn Gillmor wrote:
> On Mon 2017-08-14 21:50:13 -0300, Duane Whitty wrote:
>> I perceive keys in my keyring as being ones I trust because of 
>> out-of-band confirmation and used for two-way communications.
> 
> You're not the only person with this perception.  But i'm afraid i
> think it's a mistake, unfortunately.
> 
> Actually safely curating an OpenPGP keyring with GnuPG is a
> non-trivial task.  As an example, here's a damned-if-you-do,
> damned-if-you-don't conundrum:
> 
>  Do you refresh the OpenPGP certificates in the keyring
> regularly (e.g. from the keyservers)?  if you do not, then you risk
> missing notice of revocations, so you probably have some revoked
> keys in your keyring which you didn't know you had.
> 
> If you do refresh them regularly, then it's possible that things
> (new user IDs, etc) get added to the certificates in your keyring
> during the refresh (or possibly whole new certificates get added
> entirely), and it contains things you've never actually vetted. 
> 
> 
> 
> So, how to resolve this?
> 
> The short version is that you should treat your GnuPG keyring as
> an untrusted collection of OpenPGP certificates that you know
> about.  But you can explicitly mark the certificates that you think
> are legitimate by certifying them ("signing the keys").  In
> particular, you can make non-exportable ("local") signatures over
> the key+userid combinations that you have actually confirmed
> out-of-band.
> 
> Even better, if you do that with a key which you have marked with 
> "ultimate" ownertrust, then GnuPG will report a "validity" for
> those user IDs you've signed that matches what you intended to do,
> which is to curate a list of known-valid key+userid combinations.
> 
> But treating the whole local keyring as a curated store is a
> mistake. GnuPG doesn't work that way, and it doesn't expect to work
> that way :(

Sounds like a good approach but for someone who has more public keys
stored than me.  I only exchange encrypted email with a very, very
small group of people and I am in regular voice communication with
them.  But I definitely see the merit in what you describe and believe
that it is a cautious way of proceeding.  I may even try working that
way just to practice for the day when perhaps I consider it necessary
to exchange encrypted mail with people I don't know well and don't
talk with in person or on the telephone regularly.

I guess using that approach I could import public keys from users on
this list and then assign them various levels of trust, right down to
no trust and not locally signed at all.

> 
>> I think the VirtualBox key is just to give people assurance that
>> they are downloading what they intended to download from the
>> source they expected, in this case via apt or apt-get, etc. from
>> an Oracle repo.
> 
> If you fetch the key each time you download something that you want
> to check against the key, how do you know it's the right key over
> time?  If it's "the right key" because it was fetched over a secure
> channel from Oracle, why not just fetch the software over that
> channel?
> 
I suppose I chose to use apt or apt-get because it seems like a more
convenient way to update things as opposed to getting it straight from
Oracle.

> The advantage of having a key stored locally is that you only have
> to risk that network-fetch once; then you can make a local
> certification over its sensible VirtualBox User ID, to mark it as
> the expected key (If the User ID is *not* sensible, please complain
> to VirtualBox!).  Then all future updates can be verified against
> the same key.
> 
> Do you see how that's better than fetching the key each time?
> 
Well, I see it potentially as less work but not less risk.  I
downloaded the key using wget and https.  Then I check the validity of
the key by comparing the fingerprint generated by GnuPG with what
Oracle publishes on the VirtualBox site.  Downloading the key once
works if I implement your previous key/keyring management solution.
Also, bear in mind, no software gets updated automatically on my
system.  I get notified of updates but when the update happens is up
to me.

>> I'm not exactly sure what a good suggestion would be.  Would it
>> be correct to say that going forward usability changes would
>> probably be more likely to happen in the 2.1 branch?  If so I
>> guess I should upgrade to the 2.1 branch.
> 
> If a major change is going to happen in GnuPG, it will be in the
> 2.1 branch (or in 2.3 once 2.2 is released).  the older branches of
> GnuPG (1.4.x and 2.0.x) receive very few changes from upstream.
> 
>> I can say that what I usually end up being challenged by is
>> importing keys into my keyring and on being able to choose which
>> UID I want to sign with.  Maybe that just means I don't know the
>> software well enough.
> 
> You don't sign with a UID, you sign with a key.
> 
>> The approach I took 

Re: fingerprint of key

[Daniel Kahn Gillmor]

On Mon 2017-08-14 22:12:18 -0300, Duane Whitty wrote:
> Actually one suggestion, the way options and commands are specified
> look the same.  It might make things clearer if there was a difference
> in the way they are expressed on the command line.  Perhaps keep the
> "--" for options and enter commands without the "--".

I also prefer this kind of "subcommand" syntax -- it matches what tools
like git and notmuch use.  However, that's a pretty radical departure
from the historical GnuPG command line, and it's likely to break all
sorts of existing things that expect to use the canonical interface.

If we're going to make radical departures like that, perhaps we should
be specifying an entirely new interface that just does "the sensible
bits" without all the rest of the arcana.

  --dkg


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

Re: fingerprint of key

[Daniel Kahn Gillmor]

On Mon 2017-08-14 21:50:13 -0300, Duane Whitty wrote:
> I perceive keys in my keyring as being ones I trust because of
> out-of-band confirmation and used for two-way communications.

You're not the only person with this perception.  But i'm afraid i think
it's a mistake, unfortunately.

Actually safely curating an OpenPGP keyring with GnuPG is a non-trivial
task.  As an example, here's a damned-if-you-do, damned-if-you-don't
conundrum:


Do you refresh the OpenPGP certificates in the keyring regularly
(e.g. from the keyservers)?  if you do not, then you risk missing notice
of revocations, so you probably have some revoked keys in your keyring
which you didn't know you had.

If you do refresh them regularly, then it's possible that things (new
user IDs, etc) get added to the certificates in your keyring during the
refresh (or possibly whole new certificates get added entirely), and it
contains things you've never actually vetted.



So, how to resolve this?

The short version is that you should treat your GnuPG keyring as an
untrusted collection of OpenPGP certificates that you know about.  But
you can explicitly mark the certificates that you think are legitimate
by certifying them ("signing the keys").  In particular, you can make
non-exportable ("local") signatures over the key+userid combinations
that you have actually confirmed out-of-band.

Even better, if you do that with a key which you have marked with
"ultimate" ownertrust, then GnuPG will report a "validity" for those
user IDs you've signed that matches what you intended to do, which is to
curate a list of known-valid key+userid combinations.

But treating the whole local keyring as a curated store is a mistake.
GnuPG doesn't work that way, and it doesn't expect to work that way :(

> I think the VirtualBox key is just to give people assurance that they
> are downloading what they intended to download from the source they
> expected, in this case via apt or apt-get, etc. from an Oracle repo.

If you fetch the key each time you download something that you want to
check against the key, how do you know it's the right key over time?  If
it's "the right key" because it was fetched over a secure channel from
Oracle, why not just fetch the software over that channel?

The advantage of having a key stored locally is that you only have to
risk that network-fetch once; then you can make a local certification
over its sensible VirtualBox User ID, to mark it as the expected key (If
the User ID is *not* sensible, please complain to VirtualBox!).  Then all
future updates can be verified against the same key.

Do you see how that's better than fetching the key each time?

> I'm not exactly sure what a good suggestion would be.  Would it be
> correct to say that going forward usability changes would probably be
> more likely to happen in the 2.1 branch?  If so I guess I should
> upgrade to the 2.1 branch.

If a major change is going to happen in GnuPG, it will be in the 2.1
branch (or in 2.3 once 2.2 is released).  the older branches of GnuPG
(1.4.x and 2.0.x) receive very few changes from upstream.

> I can say that what I usually end up being challenged by is importing
> keys into my keyring and on being able to choose which UID I want to
> sign with.  Maybe that just means I don't know the software well enough.

You don't sign with a UID, you sign with a key.

> The approach I took was "gpg2 --search u...@domain.com" and "gpg2
> - --recv-keys key-fingerprint".  Then I did a "gpg2 --edit-key
> key-fingerprint" to sign the key with my default UID.  I thought I
> would get a menu to select options from when I used --edit-key but
> instead I was presented with the prompt "gpg>" and I had to type the
> sign command.  It worked but I might have chosen to sign the key with
> a key from a different UID.

Again, i'm not sure what you mean by "sign from a UID".  can you be more
clear?  You're signing your friend's key+uid, from (or "with") your
primary key.

> Not sure if my method of importing to my keyring and signing the new
> public key was the usual or easiest method but it worked.

Sounds reasonable to me, except that you had to use --recv-keys, rather
than just selecting the key to fetch from the --search interface.

here's a transcript of me fetching a key that appears to be yours from the 
keyservers:

0 dkg@alice:~$ gpg --search du...@nofroth.com
gpg: data source: https://145.100.185.229:443
(1) Arlen Duane Whitty (Duane) 
  2048 bit RSA key E25FA6BF14571B64, created: 2016-06-09
Keys 1-1 of 1 for "du...@nofroth.com".  Enter number(s), N)ext, or Q)uit > 1
gpg: key E25FA6BF14571B64: public key "Arlen Duane Whitty (Duane) 
" imported
gpg: Total number processed: 1
gpg:   imported: 1
0 dkg@alice:~$ 


Note that i just typed "1" at the prompt, and it pulled your key in
directly (no need for a subsequent --recv-keys invocation).

Regards,

--dkg


signature.asc
Description: PGP 

Re: Is it possible to certify (sign) a key using a subkey?

[Daniel Kahn Gillmor]

On Thu 2017-08-17 07:42:06 -0500, Mario Castelán Castro wrote:
> No, it does not have the certify capability. How can I enable this
> capability?

I recommend re-considering this approach, because there is likely to be
software out there that:

 (a) doesn't expect to see certifications from subkeys at all, or
 
 (b) can't handle ECDSA

aiui, your main goal was because the certifications are smaller, but
you're still requiring people to fetch your larger primary key.  if you
want to really minimize the size, just make a new OpenPGP key that is
ECDSA-only.  That will still leave you on the outs with people using
software in the (b) category, but you won't have to worry about the (a)
category of software at all, and you will decrease the size of the
necessary transfered data even further.

  --dkg

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

Re: export secret subkeys

[Mario Castelán Castro]

It is my understanding that --export-secret-subkeys outputs a *dummy*
(not the actual key) for the private part of the primary key, hence the
output of --list-packets.

The “gpg” man page says “The second form of the command [i.e.:
--export-secret-subkeys] has the special property to render the secret
part of the primary key useless;”.

Regards.

On 17/08/17 08:39, Dirk-Willem van Gulik wrote:
> [[elided]]
> 
> Instead the output of --list-packets (and the file size) suggests that both 
> the master and the subkey are exported.
> 
> Output below - followed by a script to reproduce.
> 
> Or am I misreading this ?
> 
> [[elided]]



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

Re: Is it possible to certify (sign) a key using a subkey?

[Mario Castelán Castro]

No, it does not have the certify capability. How can I enable this
capability?

If I add a subkey with  “--expert --edit-key” no option is given to
enable certify capability (as mentioned in my previous message), only
sign and authenticate in the case of ECC keys and sign, authenticate and
encrypt in the case of RSA keys.

This is version 2.1.18 of GNU PG as shipped by Debian 9.

Regards.

On 16/08/17 23:17, Robert J. Hansen wrote:
> [[elided]]
> 
> Does the subkey have the certify capability on it?  If the subkey isn't
> marked for certifying, it can't be used to certify.



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

Re: export secret subkeys

[Dirk-Willem van Gulik]

> On 17 Aug 2017, at 16:06, Peter Lebbing  wrote:
> 
> On 17/08/17 15:39, Dirk-Willem van Gulik wrote:
>> # off=0 ctb=95 tag=5 hlen=3 plen=533
>> :secret key packet:
>>  version 4, algo 1, created 1502976628, expires 0
>>  pkey[0]: [4096 bits]
>>  pkey[1]: [17 bits]
>>  gnu-dummy S2K, algo: 0, simple checksum, hash: 0
>>  protect IV:
>>  keyid: 774BFCB80257A25B
> 
> Note "gnu-dummy S2K". This is an empty placeholder for the key material.
> An OpenPGP secret key always contains the primary key, but this is
> GnuPG's method to get away with not actually including the primary key
> nonetheless.

Thank you !

> "S2K" means "String to Key", and an S2K is a method that derives a
> cryptographic key from a passphrase. The cryptographic key is
> subsequently used to encrypt the secret key material (well, apart from
> the fact that this is a dummy that doesn't actually do that).
> 
> And an OpenPGP secret key always contains the public key as well, which
> /is/ included, in pkey[0] and pkey[1] (pkey -> public key).

Clear. So I need to figure out why paperkey outputs more than I am expecting 
when minimalizing.

>> :secret sub key packet:
>>  version 4, algo 1, created 1502976632, expires 0
>>  pkey[0]: [4096 bits]
>>  pkey[1]: [17 bits]
>>  iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 1B6594BA5204BCCC
>>  protect count: 16777216 (224)
>>  protect IV:  a0 16 38 e5 6b a0 3c f0 16 f9 a4 17 c6 ba 14 a6
>>  skey[2]: [v4 protected]
>>  keyid: 11A28C9369E55B8C
> 
> And this is actually secret key material. First the public key again,
> then the secret key in skey[2] (skey -> secret key). It is protected by
> the "iter+salt" S2K.
> 
> This packet will be significantly larger than the earlier packet.

Ok. And it is. Thanks for helping to narrow this down,

Kind regards,

Dw.


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

Re: export secret subkeys

[Peter Lebbing]

On 17/08/17 15:39, Dirk-Willem van Gulik wrote:
> # off=0 ctb=95 tag=5 hlen=3 plen=533
> :secret key packet:
>   version 4, algo 1, created 1502976628, expires 0
>   pkey[0]: [4096 bits]
>   pkey[1]: [17 bits]
>   gnu-dummy S2K, algo: 0, simple checksum, hash: 0
>   protect IV: 
>   keyid: 774BFCB80257A25B

Note "gnu-dummy S2K". This is an empty placeholder for the key material.
An OpenPGP secret key always contains the primary key, but this is
GnuPG's method to get away with not actually including the primary key
nonetheless.

"S2K" means "String to Key", and an S2K is a method that derives a
cryptographic key from a passphrase. The cryptographic key is
subsequently used to encrypt the secret key material (well, apart from
the fact that this is a dummy that doesn't actually do that).

And an OpenPGP secret key always contains the public key as well, which
/is/ included, in pkey[0] and pkey[1] (pkey -> public key).

> :secret sub key packet:
>   version 4, algo 1, created 1502976632, expires 0
>   pkey[0]: [4096 bits]
>   pkey[1]: [17 bits]
>   iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 1B6594BA5204BCCC
>   protect count: 16777216 (224)
>   protect IV:  a0 16 38 e5 6b a0 3c f0 16 f9 a4 17 c6 ba 14 a6
>   skey[2]: [v4 protected]
>   keyid: 11A28C9369E55B8C

And this is actually secret key material. First the public key again,
then the secret key in skey[2] (skey -> secret key). It is protected by
the "iter+salt" S2K.

This packet will be significantly larger than the earlier packet.

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: export secret subkeys

[Damien Goutte-Gattat]

On 08/17/2017 03:39 PM, Dirk-Willem van Gulik wrote:

This had me believe that export-secret-subkeys would just export a
subkey.

Instead the output of --list-packets (and the file size) suggests
that both the master and the subkey are exported.


Seemingly, yes. But actually, when using --export-secret-subkeys, the 
master private key is not really exported. The command does produce a 
"secret key packet" corresponding to the master key, but this packet 
does not actually contain the private key material.


Look for the "gnu-dummy S2K" line in the details of the secret key packet:


:secret key packet:
version 4, algo 1, created 1502976628, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
gnu-dummy S2K, algo: 0, simple checksum, hash: 0


It's the clue indicating that this packet is actually unusable. And 
that's what the man page means when it says:


"The second form of the command has the special property to render the 
secret part of the primary key useless."


The purpose of this command is to create a situation where only the 
private subkeys are available on the machine, while the master private 
key is stored offline.


Damien



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

export secret subkeys

[Dirk-Willem van Gulik]

I am trying to understand the man page with regards to secret subkey exports. 

  --export-secret-subkeys
  Same  as --export, but exports the secret keys instead.  The 
exported keys are written to STDOUT or to the file given with option --output.  
This command is often
  used along with the option --armor to allow easy printing of the 
key for paper backup; however the external tool paperkey does a better job for  
creating  backups
  on paper.  Note that exporting a secret key can be a security 
risk if the exported keys are send over an insecure channel.
..

This had me believe that export-secret-subkeys would just export a subkey.

Instead the output of --list-packets (and the file size) suggests that both the 
master and the subkey are exported.

Output below - followed by a script to reproduce.

Or am I misreading this ?

With kind regards,

Dw.

# off=0 ctb=95 tag=5 hlen=3 plen=533
:secret key packet:
version 4, algo 1, created 1502976628, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
gnu-dummy S2K, algo: 0, simple checksum, hash: 0
protect IV: 
keyid: 774BFCB80257A25B
# off=536 ctb=b4 tag=13 hlen=2 plen=30
:user ID packet: "Tess von Testy "
# off=568 ctb=89 tag=2 hlen=3 plen=595
:signature packet: algo 1, keyid 774BFCB80257A25B
version 4, created 1502976628, md5len 0, sigclass 0x13
digest algo 10, begin of digest f6 39
hashed subpkt 33 len 21 (issuer fpr v4 
C1CC37B73A5DA5263699A091774BFCB80257A25B)
hashed subpkt 2 len 4 (sig created 2017-08-17)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 9 len 4 (key expires after 1y0d0h0m)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 1 0)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 774BFCB80257A25B)
data: [4095 bits]
# off=1166 ctb=9d tag=7 hlen=3 plen=1862
:secret sub key packet:
version 4, algo 1, created 1502976632, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 1B6594BA5204BCCC
protect count: 16777216 (224)
protect IV:  a0 16 38 e5 6b a0 3c f0 16 f9 a4 17 c6 ba 14 a6
skey[2]: [v4 protected]
keyid: 11A28C9369E55B8C
# off=3031 ctb=89 tag=2 hlen=3 plen=572
:signature packet: algo 1, keyid 774BFCB80257A25B
version 4, created 1502976632, md5len 0, sigclass 0x18
digest algo 10, begin of digest 46 b0
hashed subpkt 33 len 21 (issuer fpr v4 
C1CC37B73A5DA5263699A091774BFCB80257A25B)
hashed subpkt 2 len 4 (sig created 2017-08-17)
hashed subpkt 27 len 1 (key flags: 0C)
hashed subpkt 9 len 4 (key expires after 120d0h0m)
subpkt 16 len 8 (issuer key ID 774BFCB80257A25B)
data: [4094 bits]





#/bin/sh
set -e
set -x

TMPDIR=${TMPDIR:-/tmp}
VOLNAME=${VOLNAME:-gnupg.tmp.$$}
TMPSTORE=${TMPDIR}/${VOLNAME}
GNUPGHOME=/Volumes/${VOLNAME}

FIRST="Tess"
LAST="von Testy"
MOI="${FIRST} ${LAST} "
PASSWD=12345678
NEWPIN=123456
RESET=12345678
NEWMASTER=12345678
OLDMASTER=12345678

PGP=/usr/local/bin/gpg2
SM=/usr/local/bin/gpgsm
PRESET=/usr/local/libexec/gpg-preset-passphrase

SIZE=5M

export RANDFILE=~/.openssl.rand.state

export DAYS=365
export SUBDAYS=120

killall scdaemon gpg-agent || echo Already dead
killall scdaemon gpg-agent || echo Already dead

if test -f /usr/bin/hdiutil; then
openssl rand -base64 128 |\
/usr/bin/hdiutil hdiutil create -attach -stdinpass -quiet \
-encryption -size $SIZE -fs HFS+ \
-volname ${VOLNAME} ${TMPSTORE} 
rm -f ${TMPSTORE}.dmg
ME}
else
crypted_luks 5M

GNUPGHOME=${TMPSTORE}
mkdir -p ${GNUPGHOME}
chmod 700 ${GNUPGHOME}
fi

(
set -e
export GNUPGHOME 
cd $GNUPGHOME

cat > ${GNUPGHOME}/gpg.conf < ${GNUPGHOME}/gpg-agent.conf < ${GNUPGHOME}/scdaemon.conf < sub-enc.sec

cat sub-enc.sec | gpg --list-packets 
#.. snip other unit tests
)





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

I wrote a pinentry dispatcher; is it a sane thing to do/use?

[Olivier Mehani]

Hi list,

# Context

I connect to an OS X machine either locally or via SSH.

When local, I use pinentry-mac and forward my SSH agent to gpg-agent.

When remote, I use $SSH_AUTH_SOCK from the forwarded connection (I'm
also trying to forward the gpg-agent socket, but it doesn't work
reliably due to leftover sockets, so let's ignore that for now).


# Problem

I can't interact with pinentry-mac when connecting over SSH, so
I'd like to fallback to pinentry(-curses).

Potential solution: I just banged out this script, which I am thinking
about using as `pinentry-program /PATH/TO/HOME/bin/pinentry-dispatch`

#!/bin/sh -x
UNAME="$(uname)"
GPG_SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"

PINENTRY=/usr/bin/pinentry
PINENTRY_BREW=/usr/local/bin/pinentry
PINENTRY_MAC=/usr/local/bin/pinentry-mac

case "${UNAME}" in
"Darwin")
case "${SSH_AUTH_SOCK}" in
"${GPG_SSH_AUTH_SOCK}")
exec "${PINENTRY_MAC}"
;;
*)
exec "${PINENTRY_BREW}"
;;
esac
;;
*)
exec "${PINENTRY}"
;;
esac

This way, I could just `gpg-connect-agent 'killagent' /bye` from my SSH
session, and next time the agent spawns, it would fallback to the non-mac
pinentry.


# Question

Is it sane?

My money is on “not very”, but I'd like a more educated discussion.

One of the issues I can see is that the script is in my HOME, which
could be more easily compromised than the rest of the system, and the
script trivially replaced by something that captures the data (but then
again, my gpg-agent.conf could also be overwritten).

Can you see any other issue with (or the idea of using such a dispatcher
to start with)?

(Please CC me on replies, as I only sporadically check the list through
GMane.)

-- 
Olivier Mehani 
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

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

Is it possible to certify (sign) a key using a subkey?

[Mario Castelán Castro]

Suppose I would like to sign another user's key using one of my
secp256k1 subkeys, instead of my primary key, because it generates
smaller signatures. gpg does not appear to support this. If I try to
generate a subkey with certify capability “gpg --expert --edit-key ...”
and then “addkey”, the option to toggle capability is not shown. Also,
if I try to force gpg to use an *existing* subkey for signing another
key with “gpg -u FINGERPRINT1! --sign-key ANOTER_KEY” (where
FINGERPRINT1 is the fingerprint of the subkey, and it is followed by “!”
to try to force use of this subkey) it still uses my primary key.

Why is this behavior? I took a glance at RFC4880 and I could not find a
requirement that only primary keys are used for certifying, although it
is very possible that I just missed it.

Regards.




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