Re: Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG 2.1.22)

[Kosuke Kaizuka]

On Mon, 31 Jul 2017 10:35:24 +0200, Andre Heinecke wrote:
> Hi,
> 
> On Sunday, July 30, 2017 11:41:01 AM CEST Kosuke Kaizuka wrote:
>> On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:>
>>> I have installed the W32 package for GnuPG 2.1.22 and I find keys
>>> cannot be sent to keyservers, or fetched/refreshed. The operation
>>> fails with the message "keyserver send failed: Resource temporarily
>>> unavailable".
>>>
>>> In the event the dirmngr from 2.1.21 is already running, the operation
>>> succeeds.
> 
> Yes, slipped our testing. We are working on it:
> 
> https://dev.gnupg.org/T3318

The problem seems to have been fixed in gnupg-w32-2.1.22_20170731.

-- 
Kosuke Kaizuka 



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

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Gabriel Philippe]

On Mon, Jul 31, 2017 at 5:28 PM, Andrew Gallagher  wrote:
> There are two enormous holes in this argument:
>
> 1. If the people you communicate with regularly don't do "gpg
> --refresh-keys" regularly they won't find out whether *anything* has
> *ever* been revoked.

A good practice is to define close expiration dates for keys and
subkeys, and regularly postpone them (or renew subkeys), which is only
possible with the "master" offline key and not with the possibly
compromised subkeys. This forces those people who never refresh keys
to do it, or complain, or for most of them abandon PGP because they
get painful warnings and this stupid thing does not work.

Furthermore, if you start sending messages signed with a new subkey,
people who have not refreshed your key will get error messages,
hopefully refresh the key (or complain or abandon PGP), and get both
the revocation certificates and the new subkeys. Without even having
to understand what happens.

Definitely, having different keys for signing and certifying looks OK to me.


> But so long as your passphrase is good, it
> shouldn't matter whether an attacker has a copy of your encrypted
> privkey

I prefer having an easy to type (and weak) passphrase, and rely on
full disk encryption with a big, big passphrase I only type once in a
while. Am I wrong?

Strange tuto... Using a laptop, caring about security (which is
deduced from the use of PGP), and not considering having the storage
memory encrypted.

-- 
Gabriel

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

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Mario Figueiredo]

On Mon, 31 Jul 2017 18:38:09 +0200
Damien Goutte-Gattat  wrote:

> The problem with recommanding unnecessary steps is that they will 
> confuse the beginner and make him think that GnuPG is more difficult
> to use than it already is.

Which essentially describes my whole first impressions of GnuPG until I
finally decided to read the official documentation. Particularly the
GNU Privacy Handbook and the Mini HowTo. 

MF


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

3DES deprecated by NIST

[Robert J. Hansen]

For many years I've been saying that 3DES is a much stronger algorithm
than its detractors think, subject to some massive concerns about its
64-bit block size and the near-certainty of a block repeating after
about 32Gb of traffic (2**32 blocks, 8 bytes per block).  This isn't to
say I've been advocating 3DES: we certainly should be moving to AES, but
the fearmongering over 3DES has been -- IMO -- counterproductive.

Well, NIST has recently lowered its estimate of 3DES's safety.  Their
guidance now says a single 3DES key shouldn't be used for more than 8Mb
of traffic.  If previously we were moving to AES and away from 3DES
because the fire alarm went off, this would be the smell of smoke in the
air.

If you're still using 3DES, please migrate to AES immediately.  Until
you do, make sure to follow NIST's guidance.

https://beta.csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA

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

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Damien Goutte-Gattat]

On 07/31/2017 05:49 PM, Dirk-Willem van Gulik wrote:

For what it is worth - the various best practices at `riseup.net’[1] seem to 
strike a good middle ground.


For what it is worth, I disagree.

The main problem I have with that document is that it implies the user 
should care about a lot of details that he actually should not have to 
care about, especially with a decently recent GnuPG version.


Specifically:

* Starting from GnuPG 2.1.16, the user has nothing to do to use the SKS 
keyserver pool, that's already the default. There's no need to manually 
download the CA certificate for the pool, either, because it is now 
included directly in GnuPG.


* There is no need to "ensure that all keys are refreshed through the 
keyserver you have selected"--the honor-keyserver-url option is already 
disabled by default.


* There is no need to generate a revocation certificate. GnuPG already 
does that when you create a new keypair. You need to do it yourself only 
if you generated your key some years ago, before automatic generation of 
revocation certificates was implemented (i.e. before GnuPG 2.1).


* There is no nothing to do to "have a separate subkey for encryption". 
When creating a new keypair, GnuPG automatically creates a primary key 
for signing and certifying, *and* a subkey for encryption. (I do not 
remember when GnuPG started to do that, but I am pretty sure this is not 
new at all.)


* Unless you generated your key a long time ago, you absolutely do not 
have to "make sure your key is OpenPGPv4". No recent or even 
not-so-recent version of GnuPG will ever generate a v3 key.


* Likewise, there is no need to check that self-signatures do not use 
MD5, unless your keys are *very old*.


* Likewise for SHA-1. I think GnuPG stopped using SHA-1 as the default 
hash algorithm sometimes in 2009.


So all of those advices could be replaced by a single one: "Use a recent 
GnuPG version. Ideally, use the most recent version available. At the 
very least, do not use a decade-old version."


The problem with recommanding unnecessary steps is that they will 
confuse the beginner and make him think that GnuPG is more difficult to 
use than it already is.


Damien



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

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Peter Lebbing]

On 31/07/17 17:49, Dirk-Willem van Gulik wrote:
> For what it is worth - the various best practices at `riseup.net
> ’[1] seem to strike a good middle ground.

IMO, the good middle ground is the defaults. A wide middle. Maybe more a
country than a ground ;-). And I wasn't very impressed last time I read
the riseup.net article.

I wholeheartedly agree with "Use the defaults until and unless you can
articulate a specific and compelling reason to deviate from them."

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: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Dirk-Willem van Gulik]

> On 31 Jul 2017, at 17:41, Robert J. Hansen  wrote:
> 
>> Could probably be a direct application of this Debian article (1) on
>> subkeys. And meant to to facilitate the recovery of the web of trust in
>> case of disaster.
>> 
>> On a separate tutorial (2), Alan Eliasen strongly advises against this
>> practice.
> 
> I hate to say something bad about a tutorial someone put so much obvious
> love into, but most of these tutorials are _just plain bad_.  And even
> the good ones, I don't recommend.
> 
> A newcomer to GnuPG needs to be told the defaults are safe for the vast
> majority of users, that GnuPG does not require any special tuning before
> use, and that the developers chose the defaults very carefully to be
> applicable to the vast majority of users.
> 
> Debian may have specific needs which GnuPG does not meet in its default
> configuration.  So if Debian wants to put together a tutorial teaching
> people how to configure GnuPG in a way that meets the Debian developer
> needs, I'm all in favor of that -- but I wince every time I see a
> newcomer to GnuPG think that process is somehow necessary for them to
> follow.  It's not.  Use the defaults until and unless you can articulate
> a specific and compelling reason to deviate from them.

For what it is worth - the various best practices at `riseup.net’[1] seem to 
strike a good middle ground.

This was also were my question came form; while historically (given DSA & 
patents of that time) it made sense to have S or SC on the master key — the 
contemporary use seems to be mainly ‘C’.

So one could surmise that the historic default of SC for a non DSA (e.g. RSA or 
ECC) is a bit out of date.

Hence the question as to what good practice is today.

Dw.

1: https://riseup.net/en/security/message-security/openpgp/best-practices 
 et.al.___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Mario Figueiredo]

On Mon, 31 Jul 2017 15:44:52 +0100
Mario Figueiredo  wrote:

> On a separate tutorial (2), Alan Eliasen strongly advises against this
> practice.

I'm replying to my own post, because the above seem a little like I'm
trying to make an argument from authority. That was not my intention.
It's just poorly worded.

Read it as "The author of a separate tutorial advises against this
practice".

MF


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

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Robert J. Hansen]

> Could probably be a direct application of this Debian article (1) on
> subkeys. And meant to to facilitate the recovery of the web of trust in
> case of disaster.
> 
> On a separate tutorial (2), Alan Eliasen strongly advises against this
> practice.

I hate to say something bad about a tutorial someone put so much obvious
love into, but most of these tutorials are _just plain bad_.  And even
the good ones, I don't recommend.

A newcomer to GnuPG needs to be told the defaults are safe for the vast
majority of users, that GnuPG does not require any special tuning before
use, and that the developers chose the defaults very carefully to be
applicable to the vast majority of users.

Debian may have specific needs which GnuPG does not meet in its default
configuration.  So if Debian wants to put together a tutorial teaching
people how to configure GnuPG in a way that meets the Debian developer
needs, I'm all in favor of that -- but I wince every time I see a
newcomer to GnuPG think that process is somehow necessary for them to
follow.  It's not.  Use the defaults until and unless you can articulate
a specific and compelling reason to deviate from them.

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

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Andrew Gallagher]

On 2017/07/31 15:44, Mario Figueiredo wrote:
> On a separate tutorial (2), Alan Eliasen strongly advises against 
> this practice.

He does, but his argument is weak. The meat of it is:

> Unless everyone that you communicate with regularly does something 
> like:
> 
> gpg --refresh-keys
> 
> to find out that keys have been revoked, they may never even know 
> that you revoked the signing key, and they will continue to trust 
> your signature.
> 
> If the person who stole your laptop (and thus your secret keys) could
> ever impersonate you (because they guessed the password for your
> secret key), then they can forever decrypt all the communications
> sent to you with that same key if you follow the "perfect keypair"
> advice.
> 
> Allowing your attacker to read your encrypted communications forever,
> and pretending it didn't happen, is extremely bad and wrong 
> cryptographic practice, obviously. If your decryption key is stolen,
> revoke that entire keypair and never use any part of it again!
> Otherwise, your attacker can forever read messages encrypted to your
> public key.

There are two enormous holes in this argument:

1. If the people you communicate with regularly don't do "gpg
--refresh-keys" regularly they won't find out whether *anything* has
*ever* been revoked. So they will continue to trust your bad signature
regardless of whether you're using a subkey, a primary key, a wax seal,
thumbprints in blood, whatever. This is a completely separate argument.

2. He seems to be operating under the impression that encryption subkeys
can't be individually revoked, which is complete nonsense. And no matter
what you do after your encryption key is compromised, yes of course all
your past communications using that key are still readable by the
attacker. But again, that's the case with or without subkeys.

And of course he overlooks the strongest argument in favour of using
subkeys, and that's so you can put them on a hardware token and not have
to store them on your laptop at all.

The only bit where he has (half) a point is that it may be a good idea
to revoke your entire key because it is noisy, and therefore more likely
to be noticed (and your compromise paid due attention to) than if you
simply rolled your subkeys. But so long as your passphrase is good, it
shouldn't matter whether an attacker has a copy of your encrypted
privkey (see: RJH's NYT small ads offer) and rolling your subkeys is a
precaution against your passphrase having been keylogged at some point
prior to losing your laptop (remembering of course that if your laptop
had malware, it's Game Over anyway).

A



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

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Mario Figueiredo]

On Sun, 30 Jul 2017 22:19:22 +0200
Dirk-Willem van Gulik  wrote:

> I see a growing number of keys that have well managed & expired
> separate subkeys for Signing, Encryption and Authentication switch
> from ‘SC’ on the master key to just ‘C’ (all RSA, ignoring DSA).
> 
> Would anyone know if there is some documented best practice ?

Could probably be a direct application of this Debian article (1) on
subkeys. And meant to to facilitate the recovery of the web of trust in
case of disaster.

On a separate tutorial (2), Alan Eliasen strongly advises against this
practice.


(1) https://wiki.debian.org/Subkeys?action=show=subkeys
(2) https://futureboy.us/pgp.html#PerfectKeypair

MF


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

Re: Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG 2.1.22)

[Andre Heinecke]

Hi,

On Sunday, July 30, 2017 11:41:01 AM CEST Kosuke Kaizuka wrote:
> On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:>
> > I have installed the W32 package for GnuPG 2.1.22 and I find keys
> > cannot be sent to keyservers, or fetched/refreshed. The operation
> > fails with the message "keyserver send failed: Resource temporarily
> > unavailable".
> > 
> > In the event the dirmngr from 2.1.21 is already running, the operation
> > succeeds.

Yes, slipped our testing. We are working on it:

https://dev.gnupg.org/T3318

Regards,
Andre
-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users