Re: Avoid recipient-compatibility SHA1

[Mark]

Not to ask a stupid question but how can you tell which algorithm your
keys are using and if using SHA1 update them to a more secure one?

Thanks,

On 11/17/2020 4:13 PM, Phil Pennock via Gnupg-users wrote:


The current state of SHA1 is "dangerously exposed, you should be
hurrying for the exits, there might still be time to grab your coat on
the way out of the door."  The history is such that when the current
attacks against a digest system are where the SHA1 attacks are now, you
really don't want to be dealing with the next revelations because you
will not be happy.

At present, using "weak-digest sha1" in your GnuPG configuration files
reveals a lot of problems and in day-to-day use you will have to
periodically comment it back out again.  I know, because I've been doing
this since January.  It has helped me with pushing people I need to
exchange private mail with to update their keys.

-Phil

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


--
PGP Key Upon Request


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

Re: Avoid recipient-compatibility SHA1

[Phil Pennock via Gnupg-users]

On 2020-11-17 at 15:47 +, Stefan Claas wrote:
>} Since 2005, SHA-1 has not been considered secure against well-funded
>} opponents;[4] as of 2010 many organizations have recommended its
>} replacement.[5][6][7] NIST formally deprecated use of SHA-1 in 2011
>} and disallowed its use for digital signatures in 2013.
> 
> Was this therefore ever discussed on OpenPGP Mailing Lists, between
> OpenPGP experts and Mr. Zimmermann and Werner?

It's been discussed on the standardization lists, where I would
summarize the view as "What the hell, why are people still using SHA1?"

The answer is that some people are still using tools such as GnuPGv1 and
other similarly ancient software and get upset when asked to use the
current code-bases.

If you made a key using such old software but are now using modern
software, you should re-sign your UID and check for other problems.

If anyone wants to explore working with OpenPGP message formats while
writing a standalone tool, I suggest a public key reporter tool which
will report on the use of SHA1 (or MD5) digests where there's not
also a signature with a modern digest scheme, and provide guidance about
updating the keys. There's a few places such things might creep in.
Re-reading RFC 4880 while taking notes about all the places you see such
keys would help in writing a good tool.

This strikes me as a good way for a developer to become more familiar
with the ecosystem and to create an actively useful tool to help the
community move forward away from ancient systems.

Please don't demand this tool of any other developers: I offer the idea
as a suggestion only.


> Second question:
> 
> What does it really mean for the OpenPGP ecosystem if there would be a
> SHA1 collision found in an email or detached signed document or file?
> I ask, because when one checks a GnuPG
> digitally signed message or file it usually says it comes from the key
> (owner) blah and this key has a fingerprint of blah if one checks.

If someone can knowingly construct collisions against an existing
signature, without the cooperation of the key owner, then SHA1 would be
completely useless and such signatures would be nearly meaningless.

The current state of SHA1 is "dangerously exposed, you should be
hurrying for the exits, there might still be time to grab your coat on
the way out of the door."  The history is such that when the current
attacks against a digest system are where the SHA1 attacks are now, you
really don't want to be dealing with the next revelations because you
will not be happy.

At present, using "weak-digest sha1" in your GnuPG configuration files
reveals a lot of problems and in day-to-day use you will have to
periodically comment it back out again.  I know, because I've been doing
this since January.  It has helped me with pushing people I need to
exchange private mail with to update their keys.

-Phil

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

Re: Avoid recipient-compatibility SHA1

[Ernst G Giessmann via Gnupg-users]

The answer to the second question is:

A SHA-1 collision of two documents D1 and D2 means that the hash values
Hash(D1) and Hash(D2) are equal, which in turn means that (regardless
who signs) any signature of D1 (be it OpenPGP or SMIME) can also be used
as a signature of D2. Any signer and any key, if used with SHA-1!

So if you got a harmless document D to sign, you must be sure that there
is no evil twin of it. This is usually the case if you are the author of
D, because the construction of an evil twin remains hard. But it is easy
to construct docs with the same hash value.

/Ernst.

Am 2020-11-17 um 16:47 schrieb Stefan Claas via Gnupg-users:
> ...
> Second question:
>
> What does it really mean for the OpenPGP ecosystem if there would be a
> SHA1 collision found in an email or detached signed document or file?
> I ask, because when one checks a GnuPG
> digitally signed message or file it usually says it comes from the key
> (owner) blah and this key has a fingerprint of blah if one checks.
>
> Regards
> Stefan
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

Re: Avoid recipient-compatibility SHA1

[Stefan Claas via Gnupg-users]

On Mon, Nov 2, 2020 at 2:25 PM Phil Pennock via Gnupg-users
 wrote:
>
> On 2020-11-02 at 13:49 +0100, Werner Koch via Gnupg-users wrote:
> > On Fri, 30 Oct 2020 00:10, Phil Pennock said:
> > > recipient.  That's fine.  I'd rather create pressure for people to fix
> > > their systems to use modern cryptography than cater to their brokenness
> > > with sensitive messages.
> >
> > People won't update their keys - that just does not work.  Ignoring the
> > preferences is a better way here.
>
> First: thank you for the code changes!
>
> As to the people part: for a generic call to action, you're right.  But
> that's not the social dynamic in play here.
>
> For a specific set of people who know each other, trying to communicate
> securely, if someone says "hey your key is too broken to use, please fix
> it, here's a command to run (which you should check for yourself),
> please do so and send us your new public key" ... then that works.

I do have a question for you and Werner, if you don't mind.

When one checks Wikipedia for SHA1:

https://en.wikipedia.org/wiki/SHA-1

People may ask when seeing this [Quote]:

Since 2005, SHA-1 has not been considered secure against well-funded
opponents;[4] as of 2010 many organizations have recommended its
replacement.[5][6][7] NIST formally deprecated use of SHA-1 in 2011
and disallowed its use for digital signatures in 2013.

Was this therefore ever discussed on OpenPGP Mailing Lists, between
OpenPGP experts and Mr. Zimmermann and Werner?

Second question:

What does it really mean for the OpenPGP ecosystem if there would be a
SHA1 collision found in an email or detached signed document or file?
I ask, because when one checks a GnuPG
digitally signed message or file it usually says it comes from the key
(owner) blah and this key has a fingerprint of blah if one checks.

Regards
Stefan

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

Re: How to change the protect cipher algorithm and the digest algorithm of the secret key?

[Werner Koch via Gnupg-users]

On Tue, 17 Nov 2020 02:28, Gao Xiaohui said:

> conf.conf". At present, the "--s2k-count" option can be used in both
> gpg.exe and gpg-agent.exe.Thank you.

In gpg.conf this is used for deriving a passphrase for symmetric
encryption.

In gpg-agent.conf it is used to override the calibrated iteration code
for protecting keys in gpg-agent.  There is no need to change the
algorithms.  For interoperability and maintenance reasons we try to
limit the number of user modifiable parameters.  Eventually there will
be change to an AEAD algorithm, howver interoperability is the main
concern and not theoretical attacks.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: How to change the protect cipher algorithm and the digest algorithm of the secret key?

[Gao Xiaohui via Gnupg-users]

Thank you for your reply to my question.
In "https://dev.gnupg.org/T1800;, Werner responded: "It is an open question 
whether gpg should be allowed to change the s2k options because the keys are a 
property of the agent and not of gpg. For export it might hwoever make sense to 
be able to change that (think export for use on a slower box)."Excuse me, why 
not use "--s2k-digest-algo" and "--s2k-cipher-algo" and other options for 
gpg-agent.exe, so you can also write these options in "gpg- conf.conf". At 
present, the "--s2k-count" option can be used in both gpg.exe and 
gpg-agent.exe.Thank you.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Announce] GnuPG 2.2.24 released

[Werner Koch via Gnupg-users]

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.24.  This is maintenace release fixing some long standing
bugs.  See below for details.


What is GnuPG
=

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.2.24


  * Allow Unicode file names on Windows almost everywhere.  Note that
it is still not possible to use Unicode strings on the command
line.  This change also fixes a regression in 2.2.22 related to
non-ascii file names.  [#5098]

  * Fix localized time printing on Windows.  [#5073]

  * gpg: New command --quick-revoke-sig.  [#5093]

  * gpg: Do not use weak digest algos if selected by recipient
preference during sign+encrypt.  [4c181d51a6]

  * gpg: Switch to AES256 for symmetric encryption in de-vs mode.
[166e779634]

  * gpg: Silence weak digest warnings with --quiet.  [#4893]

  * gpg: Print new status line CANCELED_BY_USER for a cancel during
symmetric encryption.  [f05d1772c4]

  * gpg: Fix the encrypt+sign hash algo preference selection for
ECDSA.  This is in particular needed for keys created from
existing smartcard based keys.  [aeed0b93ff]

  * agent: Fix secret key import of GnuPG 2.3 generated Ed25519 keys.
[#5114]

  * agent: Keep some permissions of private-keys-v1.d.  [#2312]

  * dirmngr: Align sks-keyservers.netCA.pem use between ntbtls and
gnutls builds.  [e4f3b74c91]

  * dirmngr: Fix the pool keyserver case for a single host in the
pool.  [72e04b03b1a7]

  * scd: Fix the use case of verify_chv2 by CHECKPIN.  [61aea64b3c]

  * scd: Various improvements to the ccid-driver.  [#4616,#5065]

  * scd: Minor fixes for Yubikey [25bec16d0b]

  * gpgconf: New option --show-versions.

  * w32: Install gpg-check-pattern and example profiles.  Install
Windows subsystem variant of gpgconf (gpgconf-w32).

  * i18n: Complete overhaul and completion of the Italian translation.
Thanks to Denis Renzi.

  * Require Libgcrypt 1.8 because 1.7 has long reached end-of-life.

  Release-info: https://dev.gnupg.org/T5052


Getting the Software


Please follow the instructions found at  or
read on:

GnuPG 2.2.24 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.24.tar.bz2 (7027k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.24.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.24_20201117.exe (4322k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.24_20201117.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.

New versions of the GnuPG VS-Desktop(tm) as well as Gpg4win for Windows
featuring this version of GnuPG will be released shortly.


Checking the Integrity
==

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.2.24.tar.bz2 you would use this command:

 gpg --verify gnupg-2.2.24.tar.bz2.sig gnupg-2.2.24.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