Re: Avoid recipient-compatibility SHA1

[Stefan Claas via Gnupg-users]

Hi Neal,

thanks a lot for the detailed explanation!

Best regards
Stefan

On Thu, Nov 19, 2020 at 7:52 AM Neal H. Walfield  wrote:
>
> Hi Stefan,
>
> A chosen-prefix collision attack works as follows: an attacker chooses
> two message prefixes, and then uses near collisions blocks (in the
> SHA-1 is a Shambles paper they needed about 10 such 512-bit blocks) to
> align the internal state of the two hashes.  Since SHA-1 is a
> streaming function, the attacker can also append a common suffix.
> That is, we want:
>
>   Hash(prefix #1 || near collision blocks #1 || suffix)
>   = Hash(prefix #2 || near collision blocks #2 || suffix)
>
> And the attacker can choose prefix #1, prefix #2, and suffix, but
> cannot control near collision blocks #1 or near collision blocks #2.
>
> One way to exploit this is to create a pair of colliding documents
> (e.g., something benign and a will), and then convince Alice to sign
> the benign one.  If successful, the signature can be transferred to
> the other document, and it appears that Alice has sign it too!
>
> This attack requires the attacker to hide the near collision blocks in
> the documents.  This is often straighforward: most formats have
> provisions for comments, or metadata, which the user does not see.
>
> The difficulty is to get Alice to sign the first document: if she
> modifies it (e.g., adds any context), then the hash will be different.
> But, if Alice is a signing service, then this may be possible even if
> Alice modifies the document as long as the modifications are
> predictable.
>
> On Wed, 18 Nov 2020 14:30:12 +0100,
> Stefan Claas via Gnupg-users wrote:
> > Mallory has managed to listen to the clear text communications from
> > Alice and Bob's online devices. Alice and Bob always use GnuPG
> > to digitally sign their messages.
> >
> > Mallory is *not* in possession of the private keys from Alice and Bob.
> > Mallory has created a document which causes a collision and was
> > signed with his own key.
>
> This is currently not possible.  What you describe is a preimage
> attack, not a collision attack.  A preimage attack is when you can
> create a document with the same hash as an existing document.  Right
> now, it is possible to find two documents that collide, but you can
> only partially control the content of each of them (i.e., you need to
> add the near collision blocks to both to actually create the
> collision).
>
> :) Neal

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

Re: Avoid recipient-compatibility SHA1

[Neal H. Walfield]

Hi Stefan,

A chosen-prefix collision attack works as follows: an attacker chooses
two message prefixes, and then uses near collisions blocks (in the
SHA-1 is a Shambles paper they needed about 10 such 512-bit blocks) to
align the internal state of the two hashes.  Since SHA-1 is a
streaming function, the attacker can also append a common suffix.
That is, we want:

  Hash(prefix #1 || near collision blocks #1 || suffix)
  = Hash(prefix #2 || near collision blocks #2 || suffix)

And the attacker can choose prefix #1, prefix #2, and suffix, but
cannot control near collision blocks #1 or near collision blocks #2.

One way to exploit this is to create a pair of colliding documents
(e.g., something benign and a will), and then convince Alice to sign
the benign one.  If successful, the signature can be transferred to
the other document, and it appears that Alice has sign it too!

This attack requires the attacker to hide the near collision blocks in
the documents.  This is often straighforward: most formats have
provisions for comments, or metadata, which the user does not see.

The difficulty is to get Alice to sign the first document: if she
modifies it (e.g., adds any context), then the hash will be different.
But, if Alice is a signing service, then this may be possible even if
Alice modifies the document as long as the modifications are
predictable.

On Wed, 18 Nov 2020 14:30:12 +0100,
Stefan Claas via Gnupg-users wrote:
> Mallory has managed to listen to the clear text communications from
> Alice and Bob's online devices. Alice and Bob always use GnuPG
> to digitally sign their messages.
> 
> Mallory is *not* in possession of the private keys from Alice and Bob.
> Mallory has created a document which causes a collision and was
> signed with his own key.

This is currently not possible.  What you describe is a preimage
attack, not a collision attack.  A preimage attack is when you can
create a document with the same hash as an existing document.  Right
now, it is possible to find two documents that collide, but you can
only partially control the content of each of them (i.e., you need to
add the near collision blocks to both to actually create the
collision).

:) Neal

___
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 22:18 -0700, Mark wrote:
> 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?

I have a better answer than my previous one, because the very next
mailing-list I read has a post today from the Sequoia devs where they've
written a tool to report this stuff, and even to automatically generate
current bindings, if you trust your private key to their code.

  

Looks to do much of what I recommended; I haven't read the code and
don't know if the current version will also fix preference lists.

(I look forward to this sort of functionality being part of GnuPG
natively, as part of key lifecycle maintenance for long-lived keys.)

-Phil

___
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 22:18 -0700, Mark wrote:
> 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?

With GnuPG, `gpg --list-packets` shows a lot of fine detail, but unless
you're familiar with the standards it can be a bit of a slog.

If I might be forgiven for mentioning another OpenPGP tool from outside
the GnuPG suite which can help here, then Sequioa has an "sq" command
with the "inspect" sub-command.  Using an old revoked key of mine to
demonstrate:

---8< inspect with sequoia >8---
$ gpg --export 0x7C34B4E14CE4F655 | sq inspect
-: OpenPGP Certificate.

Fingerprint: 1745 1D0F BB5E 88F4 0AC0  08F6 7C34 B4E1 4CE4 F655
 Invalid: No binding signature at time 2020-11-18T22:41:24Z
Public-key algo: DSA (Digital Signature Algorithm)
Public-key size: 1024 bits
  Creation time: 2001-08-03 17:34:53 UTC

 UserID: Phil Pennock [censored email address in this list post]
 Invalid: Policy rejected non-revocation signature 
(PositiveCertification)
 because: SHA1 is not considered secure since 
2013-01-01T00:00:00Z

 Bad Signature: [ snip long error which doesn't matter here ]
---8< inspect with sequoia >8---

Here the lack of SHA1 support made the fingerprint invalid, and then
it's explicitly called out under the UserID.

The other thing to do is to use `gpg --edit-key $YOURKEY` and run
`showpref`; it's okay for SHA1 to be _listed_ on the Digest: line, but
you also want SHA256 listed.

Fine:
  Digest: SHA256, SHA512, RIPEMD160, SHA1
Not fine:
  Digest: RIPEMD160, SHA1


With GnuPG:
 * To fix the preferences, "setpref" in the edit-key menu.
 * To fix the self-binding:
 gpg --expert --cert-digest-algo SHA256 --sign-key $YOURKEY

There's also the problem of subkey binding signatures.  That's a whole
other mess, but frankly if you have a key which is worth keeping (it has
a good web-of-trust) and you have old subkeys, just go ahead and make
new ones with a current version of GnuPG, after you've fixed the
self-binding.  I _think_, but have not checked, that GnuPG will do the
right thing there.

Basically, make a subkey for encryption, and a subkey for signing, and
call it good.

-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]

Am 2020-11-18 um 14:30 schrieb Stefan Claas:

On Tue, Nov 17, 2020 at 11:11 PM Ernst G Giessmann via Gnupg-users
 wrote:

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.

Thanks for your reply! So if I check the SHA1 checksums
from https://gnupg.org/download/integrity_check.html
and Alice checks from another evil site the same files then we
could have a problem with tools like openssl or the shasum tool.

No, here you will have no problem, because we all trust gnupg.org ;-)
They will never create two different packages with a SHA-1 collision.

The problem shows up, if Mallory creates two documents D1 and D2 being a 
SHA-1 collision.
D1 says that Alice will owe Bob 10 Euros, D2 says the Bob will owe Alice 
1000 Euros.


Anybody who signs D1 will sign at the same time also D2.  Now I come 
back to your example.

But, sorry to ask again.

I like to give an Example.

Mallory has managed to listen to the clear text communications from
Alice and Bob's online devices. Alice and Bob always use GnuPG
to digitally sign their messages.
Fine. Unfortunally Alice accepts SHA-1 signed messages and Bob creates 
signatures based on SHA-1

Mallory is *not* in possession of the private keys from Alice and Bob.
Mallory has created a document which causes a collision and was
signed with his own key.
No, Mallory does not sign the document, instead he sends D1 to Bob and 
asks him for his signature.
Bob is happy because he gets 10 Euros for free from Alice and 
immediately signs the document D1.

Mallory replaces D1 by D2, leaving the signature untouched.

He sends this message to Alice. What does Alice see when she
does a gpg --verify? I mean she should see, regardless if the
message has a collision or not, that the message was digitally
signed by Mallory's private key and not by Bob's private key.
Alice will see a signed by Bob document D2 with a valid signature (due 
to the fact that SHA1(D1)=SHA1(D2)), where Bob confirms, that he owes 
Alice money.
That Bob signs another document could be proven by showing the other 
document D1, but which document, D1 or D2, was actually signed remains 
nevertheless open. In this particular case, it seems very unlikely that 
Bob had signed D2, but it would have been even better if he had not used 
SHA-1 at all. And SHA-2(D1) is certainly different from SHA-2(D2).


/Ernst.

I suspect, that Mallory and Alice were in fact the same person ;-)


___
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 Wed, Nov 18, 2020 at 2:30 PM Stefan Claas
 wrote:
>
> On Tue, Nov 17, 2020 at 11:11 PM Ernst G Giessmann via Gnupg-users
>  wrote:
> >
> > 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.
>
> Thanks for your reply! So if I check the SHA1 checksums
> from https://gnupg.org/download/integrity_check.html
> and Alice checks from another evil site the same files then we
> could have a problem with tools like openssl or the shasum tool.

evil mirror with 'same' files ...

> But, sorry to ask again.
>
> I like to give an Example.
>
> Mallory has managed to listen to the clear text communications from
> Alice and Bob's online devices. Alice and Bob always use GnuPG
> to digitally sign their messages.

prior encrypting.

> Mallory is *not* in possession of the private keys from Alice and Bob.
> Mallory has created a document which causes a collision and was
> signed with his own key.
>
> He sends this message to Alice. What does Alice see when she
> does a gpg --verify? I mean she should see, regardless if the
> message has a collision or not, that the message was digitally
> signed by Mallory's private key and not by Bob's private key.

The one thing I could currently see is if Alice would make a public
statement on her web site, for example, digitally signed by her
with SHA1 and that Mallory would upload a collided document
with a (completely) different content.

So the question for me would be if a collision could be crafted,
let's say for an important business contract etc., if the different
content of a document would make the same sense, like the one
from the original document.

Regards
Stefan

___
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 Tue, Nov 17, 2020 at 11:11 PM Ernst G Giessmann via Gnupg-users
 wrote:
>
> 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.

Thanks for your reply! So if I check the SHA1 checksums
from https://gnupg.org/download/integrity_check.html
and Alice checks from another evil site the same files then we
could have a problem with tools like openssl or the shasum tool.

But, sorry to ask again.

I like to give an Example.

Mallory has managed to listen to the clear text communications from
Alice and Bob's online devices. Alice and Bob always use GnuPG
to digitally sign their messages.

Mallory is *not* in possession of the private keys from Alice and Bob.
Mallory has created a document which causes a collision and was
signed with his own key.

He sends this message to Alice. What does Alice see when she
does a gpg --verify? I mean she should see, regardless if the
message has a collision or not, that the message was digitally
signed by Mallory's private key and not by Bob's private key.

Regards
Stefan

___
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]

Thank you for your reply, much appreciated! I will however ask also
Ernst here again the same question one more time again, as an
illustrative example.

Regards
Stefan

On Mon, Nov 2, 2020 at 3: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.
>
> In the generic case, there's a hypothetical reward requiring work now.
> In the specific case, it's a case of "you're getting cut out of this
> ongoing conversation which presumably matters to you, do this now to get
> back in".  If the conversation really does matter to that person, then
> they will fix their key.  I have gotten people to fix various problems
> on exactly this basis.
>
> For everyone I am not talking to?  Not my business, not my problem.
> I can only issue advice and shrug when people ignore it.
>
> Now I just need a sane way to figure out which key caused this.  :)
>
> Thanks,
> -Phil
>
> ___
> 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

[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: Avoid recipient-compatibility SHA1

[Phil Pennock via Gnupg-users]

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.

In the generic case, there's a hypothetical reward requiring work now.
In the specific case, it's a case of "you're getting cut out of this
ongoing conversation which presumably matters to you, do this now to get
back in".  If the conversation really does matter to that person, then
they will fix their key.  I have gotten people to fix various problems
on exactly this basis.

For everyone I am not talking to?  Not my business, not my problem.
I can only issue advice and shrug when people ignore it.

Now I just need a sane way to figure out which key caused this.  :)

Thanks,
-Phil

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

Re: Avoid recipient-compatibility SHA1

[Werner Koch via Gnupg-users]

On Fri, 30 Oct 2020 00:10, Phil Pennock said:

> I just sent a message to N recipients, and I think one of them probably
> has some preference algorithm in their key details, because this one
> mail was signed using SHA1, not my defaults.

Fixed:

commit 15746d60d492f5792e4a179ab0a08801b4049695 
Author: Werner Koch 
Date:   Mon Nov 2 13:39:58 2020 +0100

gpg: Do not use weak digest algos if selected by recipient prefs.

* g10/misc.c (is_weak_digest): New.
(print_digest_algo_note): Use it here.
* g10/sig-check.c (check_signature_end_simple): Use it.
* g10/sign.c (hash_for): Do not use recipient_digest_algo if it is in
the least of weak digest algorithm.
--

If a message is signed and encrypted to several recipients, the to be
used digest algorithm is deduced from the preferences of the
recipient.  This is so that all recipients are able to check the the
signature.  However, if the sender has a declared an algorithm as
week, that algorithm shall not be used - in this case we fallback to
the standard way of selecting an algorithm.

Note that a smarter way of selecting the algo is to check this while
figuring out the algorithm - this needs more testing and thus we do it
the simple way.

or in short if any of the preferences would lead to a weak algo the
feature of selecting the digest algo from the preferences is disabled.

I intend to put this also in to 2.2.24.

> 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.


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