[openpgp] SHA1 collision found

[v***@nym.hush.com]

On 2/23/2017 at 1:27 PM, ***@web.de wrote:Today was announced that
SHA1 is now completely broken
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

A few weeks back it was mentioned that there is a new proposal for a
openpgp standart including a new algorithm for pgp fingerprints.
As this is currently not applicable in practice, I would like to know
what this new development means for pgp-gnupg and the use of SHA1 for
key identification.

After researching how the fingerprint is generated, I think it would
be easy to include a new option in gnupg to print a fingerprint using
sha256. Would that be something that will/can be included in future
versions of gnupg

=====

The Openpgp standards group is working on this.

The link you give for the collision used 2 PDF's.
Using a PDF is sort-of 'cheating', and does not extrapolate to being
'completely broken'.

Assuming that it is possible to find a pre-image collision, i.e:

[1] m1.txt 1 has an SHA1 hash of H1
[2] m2.txt will now have the same SHA1 hash H1

What will happen to in order to generate m2.txt is that there will be
many trials of a gibberrish string added to the plaintext of m2.txt
until one is found that has the same SHA1 hash as m1.txt
BUT
This will be quite visible in the plaintext of m2.txt, and won't fool
anyone.

With a PDF, the 'extra gibberish string' is 'hidden'. It is not in the
actual PDF the receiver reads, only in the meta-data, the appended PDF
'Suffix'.

While this is *do-able* and a good reason to move on to a future
SHA256 hash, it would not be transferable (at this time, based on the
PDF collision data), to find a fingerprint collision for any v4 key.
vedaal

[v***@nym.hush.com]

On 2/23/2017 at 4:52 PM, ***@web.de wrote:...
Not sure about you but I am not able to see the difference between a
valid pgp key and "gibberish" ;)
...

=====

In the example of the 2 pdf's, they started with one pdf, made
another pdf, then multiple (more than billions) trials of adding a
string to the second pdf so that it hashes to the first.

With regard to generating a new key that hashes to a known specific
key, the forger must do 2 things simultaneously;

[1] generating new key material
[2] seeing that the hashed fingerprint of the new key matches that of
the first key

The forger does not start with a newly generated key and add material
so that the hash would match the first key (the case of the pdf's).
If that were the case, then the key system would be broken now for the
SHA1 hash.

Even for v3 keys, which were not SHA1 hashed, the only way to generate
a new key with the same fingerprint, would be to allow the key size to
vary (usually to a bizarre key size that would be quite suspect, and
not believed).

Now, for a V4 key with an SHA1 hash, and a further restriction that
the forged key size be the same as the first key, this is not known to
be doable day, even with the google cloud computer sharing efforts,
and the breakthrough of finding pdf's with the same hash.

Again, I fully support moving to a secure hash, but I do think that
users have more than enough time until the open-pgp group issues the
official standard.
vedaal