Re: Download of public keys

[Kristian Fiskerstrand]

On 02/17/2017 09:46 PM, si...@web.de wrote:
> Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand:
>> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote:


>> 
>> That change would also be consistent with 
>> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9
>>
>
>> 
> Not quite sure I get this.
> 
> So what this means is that effectively gnupg still uses plaintext
> connections to update public keys by default, does it not? 

Yes (if not a tor configuration locally)

> If the
> change I suggested is not correct, shouldn't we find another way to
> use secure connection by default whenever possible?

Probably nitpick, but it would likely increase privacy - not security.

> 
> As it is now, the default fallback mentioned in the referenced commit
> never takes effect as long as the skel file is used.
> 

Never would be inaccurate;
kristianf@ares ~/workspace $ mkdir abc
kristianf@ares ~/workspace $ gpg --homedir abc --recv-key
94CBAFDD30345109561835AA0B7F8B60E3EDFAE3

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Qui audet vincit
Who dares wins



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

Re: Download of public keys

[sivmu]

Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand:
> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote:
>> On 02/17/2017 07:00 PM, si...@web.de wrote:
>>> keyserver hkps://jirk5u4osbsr34t5.onion
>>> keyserver hkps://keys.gnupg.net
>>>
>>> would solve this I guess.
>>
>> No, that'd result in certificate errors and non-responsive servers
>>
>
> That said, you are indeed correct, and skel file is used to create
> dirmngr.conf on other systems as well (it has been a while since
> starting with a fresh homedir :) ) ... if wanting hkps the latter should
> be switched to hkps://hkps.pool.sks-keyservers.net  ,the former is
> protected already as tor usage would be to an endpoint running a tor
> hidden service.
>
> That change would also be consistent with
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9
>

Not quite sure I get this.

So what this means is that effectively gnupg still uses plaintext connections 
to update public keys by default, does it not?
If the change I suggested is not correct, shouldn't we find another way to use 
secure connection by default whenever possible?

As it is now, the default fallback mentioned in the referenced commit never 
takes effect as long as the skel file is used.

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

Re: GPG homedir path length limit

[Daniel Kahn Gillmor]

On Fri 2017-02-17 04:42:14 -0500, Justus Winter wrote:
> Well, I tested it on all systems I had access to at that time.  I could
> have written a small test program, and asked people to run it on systems
> we don't have access to.  But we never got to that point :(

That would be a way to advance this conversation, i think :)

However, path length may only be one concern.  What about other
scenarios, like trying to operate with a read-only $GNUPGHOME ?  Is that
something we want to support?  What about a $GNUPGHOME that resides on a
network-mount drive, or a filesystem that doesn't support unix-domain
sockets?

>> But if you ever use getsockname (e.g. common/sysutils.c and
>> dirmngr/dns.c), the long socket path names are bound to fail on *any*
>> system, right?
>
> Yes.  And iirc I went over why we use getsockname and figured that we
> could do away with them.

but they're still there!  if they're not necessary, we should remove
them.  useful diffs with more -'s than +'s are very nice contributions
to any complex software project :)

--dkg


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

Re: powertop(8) Points at gpg-agent.

[Daniel Kahn Gillmor]

On Fri 2017-02-17 08:59:52 -0500, Ralph Corderoy wrote:
> There's a few relevant patches by Daniel Kahn Gillmor, e.g. cancelling
> the socket check if inotify(7) can be used.
> https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032012.html

We're shipping these patches in debian testing and unstable right now,
and i don't think i've seen any problems with the current set.

You can find the current set at:

  
https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/gpg-agent-idling/

You can also find a set of similar patches for dirmngr, which has the
same issue:

  https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/dirmngr-idling/

I would be happy to merge any of these upstream if the upstream team
wants them.

Regards,

--dkg


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

Re: Download of public keys

[Kristian Fiskerstrand]

On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote:
> On 02/17/2017 07:00 PM, si...@web.de wrote:
>> keyserver hkps://jirk5u4osbsr34t5.onion
>> keyserver hkps://keys.gnupg.net
>>
>> would solve this I guess.
> 
> No, that'd result in certificate errors and non-responsive servers
> 

That said, you are indeed correct, and skel file is used to create
dirmngr.conf on other systems as well (it has been a while since
starting with a fresh homedir :) ) ... if wanting hkps the latter should
be switched to hkps://hkps.pool.sks-keyservers.net  ,the former is
protected already as tor usage would be to an endpoint running a tor
hidden service.

That change would also be consistent with
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Qui audet vincit
Who dares wins



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

Re: Download of public keys

[Kristian Fiskerstrand]

On 02/17/2017 07:00 PM, si...@web.de wrote:
> keyserver hkps://jirk5u4osbsr34t5.onion
> keyserver hkps://keys.gnupg.net
> 
> would solve this I guess.

No, that'd result in certificate errors and non-responsive servers

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Qui audet vincit
Who dares wins



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

Re: Download of public keys

[sivmu]

Am 17.02.2017 um 17:31 schrieb Kristian Fiskerstrand:
> On 02/17/2017 01:37 PM, si...@web.de wrote:
>> Is there something I missed or is this unintended?
>
> gnupg does not ship an installed dirmngr.conf, when no keyserver is
> specified it defaults to hkps://hkps.pool.sks-keyservers.net, the
> existence of a (I presume) arch installed dirmngr.conf changes this
> behavior.
>
> Whether that is intended or not is a question for your distribution's
> package maintainer.
>

Arch does not ship a dirmngr.conf either as far as I can see.

When running the gpg command for the first time on a new system, the 
dirmngr.conf file is creates together with some other files.

I just tested it again on ubuntu 16.04.2 and the same file appear in the gnupg 
directory, so it does not seem to be a distribution issue.

It seems that gnupg does ship this template file as dirmngr-conf.skel although 
I am not sure if the distributions have anything to do with it being copied to 
the user directory.

In any case, it might be a good idea to change the template gnupg ships

Changing the lines:

keyserver hkp://jirk5u4osbsr34t5.onion
keyserver hkp://keys.gnupg.net

to

keyserver hkps://jirk5u4osbsr34t5.onion
keyserver hkps://keys.gnupg.net

would solve this I guess.

I will although check with the arch maintainer about this to be sure but I do 
not think this is a distro issue

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

Re: Download of public keys

[Kristian Fiskerstrand]

On 02/17/2017 01:37 PM, si...@web.de wrote:
> Is there something I missed or is this unintended?

gnupg does not ship an installed dirmngr.conf, when no keyserver is
specified it defaults to hkps://hkps.pool.sks-keyservers.net, the
existence of a (I presume) arch installed dirmngr.conf changes this
behavior.

Whether that is intended or not is a question for your distribution's
package maintainer.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Qui audet vincit
Who dares wins



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

Re: GPG, subkeys smartcard and computer

[Andrew Gallagher]

Stefano,

I meant to reply last night, but didn't fancy writing this out on a
phone keyboard. No need to resend questions - this tends to be a
high-latency list for people in odd time zones, working from home, on
the move etc.

NB all the below is IMHO, YMMV etc. :-D

On 16/02/17 15:04, Stefano Tranquillini wrote:
> 
> I can't get my head around on how to use GPG in the "correct" way to
> guarantee the maximum result. That is: protect, at the best, my 
> privacy and also don't get the system too complicated.

Both of those are subjective criteria... ;-)

> My ideal setup is:
> 
> * Master generated on offline pc and stored in a cold storage * 
> subkeys for the pc (main pc, that I use everyday) - i need 
> (A)utenticate (E)encrypt (S)ign keys * subkeys for the smartcard - 
> if I use a pc of someone else, and as backup for what is worth. (In 
> the future I may switch to just the smartcard, removing the keys 
> from pc, but I would like to have the keys on the pc for time being)
> * I would like to avoid moving the master ouside the offline pc/cold
> storage

What you describe is a common scenario for those who want a little more
physical security than a standard online key. If you are not an
experienced gnupg user maybe you should try using the defaults for a
while until you are comfortable. If you make a mess of encryption you
run the risk of either a) losing access to your encrypted data or b)
leaving your encrypted data wide open. You can choose for yourself
which scenario is worse. ;-)

But if you know what you're doing, then:

Personally, if you have a smartcard I see no advantage in keeping the
subkeys on your laptop (so long as you have a backup). If you want to
take things one step at a time that's up to you - just understand that
keeping an online copy of your subkeys negates the security advantages
of having a smartcard, the point of which is that the key material
never gets stored in a format accessible by malware.

If you want to use your key on a friend's PC, just beware that if you
don't trust it enough to keep a copy of your actual key on, you may not
trust it enough to not alter your messages or keylog your PIN.
Compromising the key material is the sexy bit of cryptanalysis, but
it's usually much easier to work around security measures than break
through them.

> Create the master:
> 
> I should create the master on a device that is not my primary one 
> and that is not online. It seems kind of freak approach to me, but
> I can understand why. Once created, I backup it to a file which I 
> store on a usb key or somewhere outside of computers. With the 
> master I can create, later, subkeys for what I need and the revoke 
> certificate in case of compromised subkeys.  Other than the master 
> key, do I've to export anything else (not talking of subkeys yet, 
> that's next topic)?

Back up the entire .gnupg directory just to be sure. Technically, you
can make do with just a backup of the secret keyring, but it will make
your life a lot easier if you back up the public keyring and your
trustdb also.

> When creating the master, I've two possibility: (i) use the dafault
>  setting that results in a (SC) key or (ii) set it as only (C). The 
> best solution seems to be the second, right? 
> (http://security.stackexchange.com/questions/32386/why-do-pgp-master-keys-only-have-a-single-subkey-and-tie-certification-with-sig).
>
>
> 
Is it worth to use that approach or, as of today, the (i) is fine? I
> still don't get the full benefit of one or the other solution

The second is a "cleaner" solution, but makes no practical difference.
If you have S capability on your primary key but never use it, only
your subkey signatures will ever exist, and only the subkey will
therefore ever be checked. And if your primary is compromised you have
worse problems. ;-)

> Create the subkey
> 
> With the master key I can create subkeys. I should do it from the 
> offline pc in which I created the key, or import the master in a pc 
> and then create the subkeys (it doesn't sound so safe though). Now:

If you import your master to an online PC, you lose the advantages
of keeping it offline in the first place. See below.

> o  should each subkey be for only one scope (A) (S) (E) or is it 
> fine if one key does  two or three scopes (ASE) or (SE)?

If you are using a smartcard, it is normal practice to generate a
separate subkey for each usage. It is no harm, and has the advantage
that you can rotate them separately.

One thing that you should NEVER do is have E on a subkey that has any
other capability, as there are known methods of tricking a user into
decrypting data by getting them to sign a specially crafted plaintext.
This is difficult to achieve in PGP, but better to be safe than sorry.

> o once subkeys are creted I've to export them and also their revoke 
> certifications (do they have one)? correct?

You do not create a revocation for subkeys, only for the primary. If
you still have access to the primary you 

powertop(8) Points at gpg-agent.

[Ralph Corderoy]

Hi,

gnupg 2.1.18-1 on Arch Linux.  I noticed powertop ranking the
gpg-agents, one per user, quite highly, and their impact is multiplied
by their number.  strace(1) showed the two-second select(2) timing out
with no syscalls in between, and the forking of two siblings to have a
`GETINFO pid' chat every minute.

Hans-Christoph Steiner noticed back in 2012, and Werner pointed the
relevant #defines.
https://lists.gnupg.org/pipermail/gnupg-devel/2012-March/026589.html

# define TIMERTICK_INTERVAL  (2)
# define CHECK_OWN_SOCKET_INTERVAL  (60)
#endif

There's a few relevant patches by Daniel Kahn Gillmor, e.g. cancelling
the socket check if inotify(7) can be used.
https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032012.html

Are there any plans to make gpg-agent consume less background resources?
It remains running here when a user logs out.  Is that common?  A
variety of users logging in over time divides TIMERTICK_INTERVAL quite a
bit.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

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

GPG, subkeys smartcard and computer

[Stefano Tranquillini]

Hi all,
I'm sort of new to GPG/PGP, I'm not new to the encryption/crypto world and
to computers, however, some concepts are yet not clear to me.

I can't get my head around on how to use GPG in the "correct" way to
guarantee the maximum result. That is: protect, at the best, my privacy and
also don't get the system too complicated.

The problems that I've are multiple, I'll try to summarize them here asking
for help. I've read the manual, but it's a bit outdated, and online I found
scattered information that does not always explain why some decision are
made.

My ideal setup is:

   - Master generated on offline pc and stored in a cold storage
   - subkeys for the pc (main pc, that I use everyday) - i need
   (A)utenticate (E)encrypt (S)ign keys
   - subkeys for the smartcard - if I use a pc of someone else, and as
   backup for what is worth. (In the future I may switch to just the
   smartcard, removing the keys from pc, but I would like to have the keys on
   the pc for time being)
   - I would like to avoid moving the master ouside the offline pc/cold
   storage

Create the master:

I should create the master on a device that is not my primary one and that
is not online. It seems kind of freak approach to me, but I can understand
why. Once created, I backup it to a file which I store on a usb key or
somewhere outside of computers. With the master I can create, later,
subkeys for what I need and the revoke certificate in case of compromised
subkeys.  Other than the master key, do I've to export anything else (not
talking of subkeys yet, that's next topic)?

When creating the master, I've two possibility: (i) use the dafault setting
that results in a (SC) key or (ii) set it as only (C). The best solution
seems to be the second, right? (http://security.stackexchange.com/questions/
32386/why-do-pgp-master-keys-only-have-a-single-subkey-and-
tie-certification-with-sig). Is it worth to use that approach or, as of
today, the (i) is fine? I still don't get the full benefit of one or the
other solution

Create the subkey

With the master key I can create subkeys. I should do it from the offline
pc in which I created the key, or import the master in a pc and then create
the subkeys (it doesn't sound so safe though). Now:

   -  should each subkey be for only one scope (A) (S) (E) or is it fine if
  one key does  two or three scopes (ASE) or (SE)?
  - once subkeys are creted I've to export them and also their revoke
  certifications (do they have one)? correct?
  - I've a smartcard, but I've also a pc, should I create 6 subkeys, 2
  for A, 2 for S and 2 for E and move the 3 A S E to the yubikey and the
  other 3 to the pc?.
  - moving the keys on the smartcard is done via "keytocard" but to
  move the keys on the pc I've to export subkeys, will this export also the
  keys on the smartcard and then I'll need the smartcard to access some of
  those? how can I decide what to import where?
  - Do I've to rexport my public key or anything else to let the world
  know my subkeys?
  - Do I've to export anything else to achieve my scenario's goal?

Am I missing anything? Or is there anything that can guide me to achieving
my goals?

PS: Sorry for the long questions, but I can't find online something that
explains my scenario. Solutions are for base cases or for smart-card only.
Well, probably there's a guide, but I can't find it out.

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

Download of public keys

[sivmu]

Some time ago I asked about the unencrypted download of public keys.

The answer was that the current gnupg does use https by default to fetch the 
keys.
I found the time to retest this on a new setup and found that gnupg 2.1.18 
still uses http connections to fetch the keys.

I uses a newly installes arch linux setup with basically nothing but the base 
linux tools and downloaded a public key whil sniffing on the network.
All requests, first to keys.gnupg.net and tehn to some other keyservers were in 
plaintext.

The default dirmngr.conf file provided by arch, which seems to use gnupg 2.1.18 
without changes, contains the followging lines:

# If exactly two keyservers are configured and only one is a Tor hidden
# service, Dirmngr selects the keyserver to use depending on whether
# Tor is locally running or not (on a per session base).

keyserver hkp://jirk5u4osbsr34t5.onion
keyserver hkp://keys.gnupg.net


This would explain why no encryption is used. 

Is there something I missed or is this unintended?

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

Re: GPG homedir path length limit

[Justus Winter]

Daniel Kahn Gillmor  writes:

> On Thu 2017-02-16 04:12:36 -0500, Justus Winter wrote:
>> That is still wrong.  The length of the path of the socket is not
>> limited in any way, the length of the path passed to connect is.
>
> this is a clever approach to *connect* to such a socket,

Yes.

> on some systems.

Well, I tested it on all systems I had access to at that time.  I could
have written a small test program, and asked people to run it on systems
we don't have access to.  But we never got to that point :(

> But if you ever use getsockname (e.g. common/sysutils.c and
> dirmngr/dns.c), the long socket path names are bound to fail on *any*
> system, right?

Yes.  And iirc I went over why we use getsockname and figured that we
could do away with them.


Justus


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