Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"

Steven Bellovin <smb@cs.columbia.edu> Wed, 28 November 2012 22:38 UTC

Return-Path: <smb@cs.columbia.edu>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFB821F895D for <saag@ietfa.amsl.com>; Wed, 28 Nov 2012 14:38:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVibKzICN3tb for <saag@ietfa.amsl.com>; Wed, 28 Nov 2012 14:38:56 -0800 (PST)
Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF4A21F8959 for <saag@ietf.org>; Wed, 28 Nov 2012 14:38:56 -0800 (PST)
Received: from [192.168.1.3] (49.sub-70-192-197.myvzw.com [70.192.197.49]) (user=smb2132 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id qASMcdEb027430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Nov 2012 17:38:54 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F54B580@xmb-rcd-x04.cisco.com>
Date: Wed, 28 Nov 2012 17:38:39 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <F56F28FB-3192-4708-A4B1-95267E227884@cs.columbia.edu>
References: <747787E65E3FBD4E93F0EB2F14DB556B0F54B580@xmb-rcd-x04.cisco.com>
To: David McGrew <mcgrew@cisco.com>
X-Mailer: Apple Mail (2.1499)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2012 22:38:57 -0000

On Nov 28, 2012, at 5:29 PM, David McGrew (mcgrew) <mcgrew@cisco.com> wrote:

> 
> 
> On 11/28/12 4:32 PM, "Mouse" <mouse@Rodents-Montreal.ORG> wrote:
> 
>>> Consider the case of an md5sum hash on a debian ISO image.  If the
>>> person responsible for generating the hash can create a malware-laden
>>> ISO imagine that has a hash collision with the actual ISO image,
>> 
>> ...then you're dealing with second-preimage reisistance, not just
>> collision resistance.
>> 
>> At least, unless the "actual ISO image" creator is in on the deal, and
>> in that case even the best hash imaginable won't help.
> 
> The point that I wanted to make is: if the actual ISO image creator is
> untrustworthy and the hash function is not collision resistant, then it is
> possible for that person to make two images, one good and one bad.   This
> enables attacks on the system that are not otherwise possible, i.e.
> publishing the good image in the distribution channels that will actually
> be checked by security auditors, then publishing the bad one in some other
> distribution channels.
> 

What about the party who prepares part of the contents, i.e., one file?
The hash function reaches that file with fixed but unknown internal state.
It's easy to prepare two different files that would cause a collision from
the standard starting state, but I'm not sure about this scenario.


		--Steve Bellovin, https://www.cs.columbia.edu/~smb