Re: [openpgp] SHA1 collision found

vedaal@nym.hush.com Thu, 23 February 2017 19:10 UTC

Return-Path: <vedaal@nym.hush.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0E129BED for <openpgp@ietfa.amsl.com>; Thu, 23 Feb 2017 11:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENwqk13l_0th for <openpgp@ietfa.amsl.com>; Thu, 23 Feb 2017 11:10:01 -0800 (PST)
Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AB8129A7F for <openpgp@ietf.org>; Thu, 23 Feb 2017 11:10:01 -0800 (PST)
Received: from smtp1.hushmail.com (localhost [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id C6F32402D9 for <openpgp@ietf.org>; Thu, 23 Feb 2017 19:10:00 +0000 (UTC)
X-hush-tls-connected: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=cP/KxD7d6t0RIex2Q52ZcBhViVsR2G6kP/9LvjSXEe4=; b=impevbVGZ1N5ixX2OVZutOF/R6Dxatq+DxxA9aoTKMxA+8xMyhFQfpVhvUM51iRT21ukOIMyb6ND5bYcxJt5+CVdt0rzW115QJV/2tLyngR4bnxTH3peqR6kscPVTxDz9IEhnkBu7+s9TnDbA94gfJYrpT3PcoXMphspbUmPTGDfbuGkm/RNlHrqe3MfOhVagm6tSaFs4yHA5RCgev3a+M1Px0ZsSZW6O4fqbHW1tA8YeVTnz4bCYsatLwtEZERW524wjfGbEbyVYoTgArte/ghzMZ6XFpEQt0S7v018afzK4JYFce3gneK8TSh0wk/M7c1vPXAlWzw8wVKr458ERA==
Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.hushmail.com (Postfix) with ESMTPS; Thu, 23 Feb 2017 19:10:00 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id 2CD7FE0163; Thu, 23 Feb 2017 19:10:00 +0000 (UTC)
MIME-Version: 1.0
Date: Thu, 23 Feb 2017 14:09:59 -0500
To: gnupg-users@gnupg.org, openpgp <openpgp@ietf.org>
From: vedaal@nym.hush.com
In-Reply-To: <trinity-34844406-6907-4632-a57b-4d00d8a8e64a-1487874242949@3capp-webde-bap07>
Content-Type: multipart/alternative; boundary="=_13531d97fd2a241ddb02b5af3e7b79a9"
Message-Id: <20170223191000.2CD7FE0163@smtp.hushmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/AjJ3BHzd2c9K2KQ3DTk9Ry_QVYM>
Subject: Re: [openpgp] SHA1 collision found
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 19:10:03 -0000


On 2/23/2017 at 1:27 PM, sivmu@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