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