Re: Problem refreshing keys

[Phil Pennock]

On 2018-06-13 at 09:52 -0400, Jerry wrote:
> On Wed, 13 Jun 2018 15:25:04 +0200, Werner Koch stated:
> >The common problem on Windows: You can't use ' to quote; we Unix folks
> >always forget about that.  Use

Bah, I just didn't know.  :D  I suspected though, which is why I
mentioned typing interactively as a fallback.

> gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye
> S # hosttable (idx, ipv6, ipv4, dead, name, time):
> S #   0   hkps.pool.sks-keyservers.net (216.66.15.2)
> OK
> 
> Is that what it should be reporting?

What version is it?  Is there a newer version available?

  gpg-connect-agent --dirmngr "GETINFO version" /bye

There have been a bunch of fixes for various DNS issues with dirmngr, I
would expect to see something showing that it's a pool.

You're talking to zimmermann.mayfirst.org, which works fine; I just
overrode DNS for the pool and made sure that
hkps.pool.sks-keyservers.net only reached that IP (/etc/hosts override)
and I was able to retrieve a key fine, after which:

> KEYSERVER --hosttable
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S #   0   hkps.pool.sks-keyservers.net
S #   .   hkps.pool.sks-keyservers.net
S #   .   --> 1*
S #   1   4   216.66.15.2 (hkps.pool.sks-keyservers.net)
OK

I suspect that you have an old dirmngr and the problems are fixed with a
newer release of gpg4win.

-Phil

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

[Announce] Libgcrypt 1.8.3 and 1.7.10 to fix CVE-2018-0495

[Werner Koch]

Hi!

The GnuPG Project is pleased to announce the availability of Libgcrypt
versions 1.8.3 and 1.7.10.  These releases mitigate a novel side-channel
attack on ECDSA signatures and also bring fixes for a few other bugs.

Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG.  It does not provide any
implementation of OpenPGP or other protocols.  Thorough understanding of
applied cryptography is required to use Libgcrypt.


Noteworthy changes in version 1.8.3
===

   - Use blinding for ECDSA signing to mitigate a novel side-channel
 attack.  [#4011,CVE-2018-0495]

   - Fix incorrect counter overflow handling for GCM when using an IV
 size other than 96 bit.  [#3764]

   - Fix incorrect output of AES-keywrap mode for in-place encryption
 on some platforms.

   - Fix the gcry_mpi_ec_curve_point point validation function.

   - Fix rare assertion failure in gcry_prime_check.

   Release info at .


We also released a new version of the older 1.7 branch with similar
fixes.


Comments on the attack
==

Details on CVE-2018-0495 can be found in the paper "Return of the Hidden
Number Problem" which can be downloaded from the advisory page
.
See  for a timeline.

One user of Libgcrypt is GnuPG, thus a quick comment: GnuPG does not use
the vulenrable ECDSA signatures by default.  Further, it is much harder
to mount such an attack against an offline protocol like OpenPGP than
against online protocols like TLS.  Anyway, we also released a new
Windows installer for GnuPG 2.2.8 featuring the fixed Libgcrypt version.
That installer is linked from the usual download page and a new Gpg4win
version will be released soon.


Download


Source code is hosted at the GnuPG FTP server and its mirrors as listed
at .  On the primary server
the source tarball and its digital signature are:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.bz2
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.bz2.sig

or gzip compressed:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.gz
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.gz.sig

The URLs for the older 1.7 branch are:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.bz2
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.gz 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.10.tar.gz.sig

In order to check that the version of Libgcrypt you downloaded is an
original and unmodified file please follow the instructions found at
.  In short, you may
use one of the following methods:

 - Check the supplied OpenPGP signature.  For example to check the
   signature of the file libgcrypt-1.8.3.tar.bz2 you would use this
   command:

 gpg --verify libgcrypt-1.8.3.tar.bz2.sig libgcrypt-1.8.3.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 - If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file libgcrypt-1.8.3.tar.bz2, you run the command like this:

 sha1sum libgcrypt-1.8.3.tar.bz2

   and check that the output matches the first line from the
   this list:

13bd2ce69e59ab538e959911dfae80ea309636e3  libgcrypt-1.8.3.tar.bz2
3b4d23db99ef13e6e305f536f009d9de8f5d0535  libgcrypt-1.8.3.tar.gz
66902603f7b6ad62c72db868d93b1772ac2a1afa  libgcrypt-1.7.10.tar.bz2
a0aaea0c514c62de8533a955631134bc57f2e552  libgcrypt-1.7.10.tar.gz

   You should also verify that the checksums above are authentic by
   matching them with copies of this announcement.  Those copies can be
   found at other mailing lists, web sites, and search engines.
   

Copying
===

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+).  The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+).  The file LICENSES has notices about contributions
that require that these additional notices are distributed.


Support
===

For help on developing with Libgcrypt you should read the included
manual and optional ask on the gcrypt-devel mailing

Re: Pinentry: Permission Denied

[Werner Koch]

On Tue, 12 Jun 2018 19:03, tookm...@gmail.com said:

> That seems to be it. I was overriding getty and launching my own service
> as a non-root user and tty1 was still owned by root

If you run gpg with -v with the next released pinentry you will see a
line like this (wrapped)

gpg: pinentry launched (17122 gtk2 1.1.1-beta7 \
   /dev/pts/6 xterm localhost:11.0 20620/1000/5 1000/1000)
 !  !  ! 
   device  mode/uid/gid euid/egid
   of deviceof caller

Maybe this helps in the future to track down such problems easier (mode
and euid etc are new).


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

On Wed 2018-01-17 08:57:12 +0100, Kristian Fiskerstrand wrote:
> On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote:
>> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
>>> thanks for this post Daniel, my primary question would be what advantage
>>> is gained by this verification being done by an arbitrary third party
>>> rather by a trusted client running locally, which is the current modus
>>> operandus. Any keyserver action doing this would just shift
>>> responsibilities to a third party for something better served (and
>>> already happens) locally.
>> 
>> the advantage is spam-abatement -- the keyservers have to keep track of
>> what is attached to each blob they transport/persist.  if all signatures
>> that they transport for a given blob are cryptographically certified,
>> then only the original uploader of that blob can make assertions about
>> it; other people can't spam the blob to make it untransportable.
>
> All the certificates used in trollwot are technically correct. You can
> still use the same mechanisms as you control the other key material, and
> can use intentionally weak key material if wanting to speed things up.

sorry for the blast from the past here, but in re-reading this thread, i
thought i'd follow up on this.

the proposed revocation distribution network wouldn't allow any user IDs
or third-party certifications, so most of the "trollwot" would not be
relevant.

if someone wants to upload their own key and make it unfetchable by
appending garbage to it, that's probably OK (at least, it's a strict
improvement than the current situation, which is that they can append
garbage to *any* key).  and if they use weak key material (or publish
the secret someplace), then sure it's a noisy blob that anyone can
append to.  But no one will care, because they aren't likely to be
relying on that key.

does that make sense as to why this proposal is potentially useful?

--dkg


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

Re: Problem refreshing keys

[Jerry]

On Wed, 13 Jun 2018 15:25:04 +0200, Werner Koch stated:

>On Wed, 13 Jun 2018 00:23, je...@seibercom.net said:
>
>> gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye  
>
>The common problem on Windows: You can't use ' to quote; we Unix folks
>always forget about that.  Use
>
>  gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye
>
>
>Salam-Shalom,
>
>   Werner

OK, now this is what I am receiving:

gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S #   0   hkps.pool.sks-keyservers.net (216.66.15.2)
OK

Is that what it should be reporting?

-- 
Jerry

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

Re: Problem refreshing keys

[Werner Koch]

On Wed, 13 Jun 2018 00:23, je...@seibercom.net said:

> gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye

The common problem on Windows: You can't use ' to quote; we Unix folks
always forget about that.  Use

  gpg-connect-agent --dirmngr "KEYSERVER --hosttable" /bye


Salam-Shalom,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Problem refreshing keys

[Werner Koch]

On Tue, 12 Jun 2018 22:42, gnupg-us...@spodhuis.org said:

> provide more information, and AFAICT the "-->" line is "the order we'll
> try them in, with the currently active server marked with "*"; this

They are not tried in this order but they are picked randomly until one
worked.


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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