digest-algo SHA256, SHA-1 attacks (was: Setpref is not working or is it a bug or something?))

[Peter Lebbing]

(By the way, how did the topic
- gpg.conf: settings for security and compatibility
ever get confused with the topic
- Setpref is not working or is it a bug or something?
because this definitely is the former but is called the latter. Also, @g, as you
apparently call yourself, you seem to start a new thread with each post, could
you try to get your e-mail client to properly thread?)

On 26/11/14 14:31, Werner Koch wrote:
>> digest-algo SHA256
> 
> May break compatibility because it overrides the preference system.
> 
>> personal-cipher-preferences AES256 TWOFISH AES192 AES CAST5
>> personal-digest-preferences SHA512 SHA384 SHA256 SHA224
>> personal-compress-preferences ZLIB BZIP2 ZIP

Wouldn't personal-digest-preferences be completely redundant when you also
specify digest-algo? It's going to force usage of SHA-256 anyway.

Now about SHA-1 for signatures on data (/not/ certifications).

As long as you sign only things you produced yourself, one would generally need
a preimage attack on SHA-1 to fake your signature. There are currently no
practical preimage attacks on SHA-1.

The attacks on SHA-1 that are the buzz these days are collision attacks.

But this is *only* a risk if the attacker can get you to sign a document the
attacker created!

If you are in the habit of signing binary documents (say, a Microsoft Word file
or an OpenDocument file), then it might in the future become possible to involve
you in a chosen-prefix collision attack and fake your signature. That is because
there is more in such a file than meets the eye. You think you sign what meets
the eye, you don't see the cruft appendage in that file that was cleverly
included to create a chosen-prefix collision.

This is what it would look like:

Company Alice gives the contract for job X to company Bob, Inc.
erfhwGqid389547854ddssdwiAQWQuibidfvsdf

However, you wouldn't see that last bit because it is included in such a way
into the file that it doesn't appear on your screen. Still, it is part of what
you sign. The cruft at the end has the purpose to create a hash collision, and
the whole document hashes to b843e5fb9ccef0091fa3e65d2ff349fcb46a6061, which is
what you sign.

Now, the attacker has created a second message in tandem, which reads:

Company Alice gives the contract for job X to company Mallory.
erfuihrhiwefbwu2347847834sdvbsduBHUIuygvuiUIHUI323432

They created this in tandem with his first message, and the cruft at the end is
chosen carefully such that this again hashes to
b843e5fb9ccef0091fa3e65d2ff349fcb46a6061.[1] And again, the cruft at the end is
hidden in the file and doesn't show when you view the document. Now they can
copy your signature, because you signed that hash.

In practice, there are still several problems, such as the time of the signature
being part of the hash and thus not fully under attacker control. It's just a
rough sketch of the problem to give you a feeling for it. The message behind it
is: unless an attacker can get you to sign something the attacker produced, you
don't have to worry about collision attacks. If you use the same key for
certifications and data signatures, then I think a certification is in the
category "sign something the attacker produced", though.

Has something like randomized hashing[2] been considered by the OpenPGP
standardization people?

Peter.

[1] no, it doesn't, I can't do SHA-1 collisions, I'm sorry :)
[2] for example http://webee.technion.ac.il/~hugo/rhash/

-- 
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 <http://digitalbrains.com/2012/openpgp-key-peter>