Re: SHA1 depreciation ??

[Robert J. Hansen]

> As for the current version v4, SHA1 is used to compute the fingerprint.
> Are there other mandatory places?

Yes.  Search the RFC for the term "SHA-1" and you'll find them.  It's
hardwired into several of the packet formats, for instance.

> Do you know any time frame and significant changes of v5 specs?

No.  The WG is being annoyingly slow.


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

Re: SHA1 depreciation ??

[Lou Wynn]

On 06/29/2017 02:31 PM, Robert J. Hansen wrote:
>> SHA1 got broken some months ago, but I see no useful move to get rid
>> of using it for even new stuff.
> (a) Not for OpenPGP's uses.  For our uses it's still safe, although we
> recommend moving to other, better, hashes as soon as possible.
>
> (b) It's pretty easy to avoid using SHA-1.  There are still a small
> number of places where it's mandatory, and this will not change until
> the IETF OpenPGP Working Group publishes the v5 key specification.
>
> (c) The IETF OpenPGP WG is working on a new key specification ("v5")
> which completely gets rid of SHA-1.

As for the current version v4, SHA1 is used to compute the fingerprint.
Are there other mandatory places?

Others such as signature hash and password hash do not depend on SHA1.

Do you know any time frame and significant changes of v5 specs?


Thanks,

Lou

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

Re: Technical contact for mailing list?

[Ingo Klöcker]

On Thursday 29 June 2017 00:50:49 Pete Stephenson wrote:
> Hi all,
> 
> Who is the appropriate person to contact regarding technical issues
> with the mailing list?

I'd start with the people who run this list. See
https://lists.gnupg.org/mailman/listinfo/gnupg-users

They can be reached at gnupg-users-ow...@gnupg.org.


Regards,
Ingo


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

Re: SHA1 depreciation ??

[Robert J. Hansen]

> SHA1 got broken some months ago, but I see no useful move to get rid
> of using it for even new stuff.

(a) Not for OpenPGP's uses.  For our uses it's still safe, although we
recommend moving to other, better, hashes as soon as possible.

(b) It's pretty easy to avoid using SHA-1.  There are still a small
number of places where it's mandatory, and this will not change until
the IETF OpenPGP Working Group publishes the v5 key specification.

(c) The IETF OpenPGP WG is working on a new key specification ("v5")
which completely gets rid of SHA-1.

> I found out it's really hard to make a key that doesn't say "Digest:
> ... SHA1" in its attributes.

You found out it's *impossible*.  SHA-1 is a MUST algorithm according to
the RFC.  You cannot get rid of SHA-1 from your key preferences.  Even
if you were to do it, every RFC-conformant OpenPGP application on the
planet would say, "that's odd: let me just append SHA-1 to that", as
they are required to do by the RFC.

> I found out why the web of trust collapses; public signing defaults
> to SHA1 unless a command line option is passed to change it. Editing
> key preferences on your signing key won't do it.

You didn't read the manual.  The preferences attached to your key tell
the world what algorithms you're capable of interoperating with.  GnuPG
never uses them to decide which algorithms to apply to your own traffic.

> I'm pretty sure enigmail will sign this message with SHA1 because it
> doesn't have an option to select digest and setting whatever on
> preferences doesn't work.

Enigmail doesn't sign anything.  GnuPG is what signs things.  Enigmail
just hands your documents to GnuPG for processing.

Check what digest was used to sign this message.  Hint: I'm using Enigmail.

Try adding this lines to your gpg.conf file:

personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160



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

SHA1 depreciation ??

[Joshua Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

SHA1 got broken some months ago, but I see no useful move to get rid of using 
it for even new stuff.

I found some email chains awhile back showing the web of trust collapsing if 
SHA1 were not used.

I found ubuntu trying to go at removing it alone: 
https://wiki.ubuntu.com/SecurityTeam/GPGMigration
(mainly talks about changing keys but they are testing SHA2 signatures 
extensively)

I found out it's really hard to make a key that doesn't say "Digest: ... SHA1" 
in its attributes.

I found out why the web of trust collapses; public signing defaults to SHA1 
unless a command line
option is passed to change it. Editing key preferences on your signing key 
won't do it.

I'm pretty sure enigmail will sign this message with SHA1 because it doesn't 
have an option to
select digest and setting whatever on preferences doesn't work.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAllT6MMACgkQE8ihdI6XWvTX1AD/T8oFAb2/TNGkt3Ke8sYSTO9H
wQXh6MqsRajuqF542NUA/2PEajHFahVohQBxQLeUwAZr5G8Kk4q77Nq3mOpwzbfa
=kwi5
-END PGP SIGNATURE-


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

Re: Technical contact for mailing list?

[Kristian Fiskerstrand]

On 06/29/2017 12:50 AM, Pete Stephenson wrote:
> Hi all,

Hi,

> 
> Who is the appropriate person to contact regarding technical issues with
> the mailing list?
> 
> Specifically, it appears that the list doesn't play nice with anti-spam
> measures like DMARC, SPF, and DKIM and so messages sent from domains
> with restrictive DMARC and SPF rules get flagged as spam as mail servers
> think the mailing list server is forging messages for those domains.

This is likely a a continuation of
https://lists.gnupg.org/pipermail/gnupg-users/2017-March/057877.html
-- 

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

"Better to keep your mouth shut and be thought a fool than to open it
and remove all doubt"
(Mark Twain)



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

Re: Managing the WoT with GPG

[Wouter Verhelst]

On Tue, Jun 20, 2017 at 03:34:44PM +0200, martin f krafft wrote:
> 2. I've also tried running --update-trustdb, but it seems that this
>process is *endless*. I have no idea how many keys remain, and
>I also got the impression that I keep seeing keys I already
>processed. How do you approach this? Or does everyone just use
>tofu these days?

This is only true the first time around. GnuPG will store the answers
you enter, and retain them for future use.

I did so on my keyring, and now it asks me to run update-trustdb once
every few months. When I do, I need to answer on only a handful of keys

> 3. Is there a way to run --check-trustdb or --update-trustdb not
>over the entire key graph, but only traversing to a certain depth
>starting from a specific key?

--update-trustdb only asks about keys that are already trusted. It
starts with keys that you yourself signed, then checks which keys are
signed by those and therefore trusted, and asks about them. Etc, etc,
until you've got everything.

[...]
> 5. Has anyone come up with a smart way to keep pubring/trustdb
>synchronised between multiple workstations?

You can export the values you've input into --update-trustdb with
--export-ownertrust (and then import them into another machine with
--import-ownertrust).

This is, in fact, a good idea to do for backup purposes every once in a
while.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

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

[Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526

[Werner Koch]

Hi!

The GnuPG Project is pleased to announce the availability of Libgcrypt
version 1.7.8.  This release fixes a local side-channel attack.

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.7.8 (2017-06-29)  [C21/A1/R8]
===

 * Bug fixes:

   - Mitigate a flush+reload side-channel attack on RSA secret keys
 dubbed "Sliding right into disaster".  For details see
 .  [CVE-2017-7526]


Note that this side-channel attack requires that the attacker can run
arbitrary software on the hardware where the private RSA key is used.
Allowing execute access to a box with private keys should be considered
as a game over condition, anyway.  Thus in practice there are easier
ways to access the private keys than to mount this side-channel attack.
However, on boxes with virtual machines this attack may be used by one
VM to steal private keys from another VM.



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:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.bz2 (2830k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.bz2.sig

That file is bzip2 compressed.  A gzip compressed version is here:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.gz (3398k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.gz.sig

The same files are also available via HTTP:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.bz2 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.8tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.gz 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.8.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.7.8.tar.bz2 you would use this
   command:

 gpg --verify libgcrypt-1.7.8.tar.bz2.sig libgcrypt-1.7.8.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.7.8.tar.bz2, you run the command like this:

 sha1sum libgcrypt-1.7.8.tar.bz2

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

65a4a495aa858483e66868199eaa8238572ca6cd  libgcrypt-1.7.8.tar.bz2
b1290e278170c638955de430699a425c2121750b  libgcrypt-1.7.8.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 list [1].  A
listing with commercial support offers for Libgcrypt and related
software is available at the GnuPG web site [2].

If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gcrypt-devel
mailing list for discussion.

Maintenance and development of Libgcrypt is mostly financed by
donations; see .  We currently employ
4 full-time developers, one part-timer, and one contractor to work on
GnuPG and closely related software like Libgcrypt.


Thanks
==

We like to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.  Also many thanks to all our donors [3].