IETF Logo Mail Archive

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

"David McGrew (mcgrew)" <mcgrew@cisco.com> Wed, 28 November 2012 22:30 UTC

Return-Path: <mcgrew@cisco.com>
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 B56D521F88D8 for <saag@ietfa.amsl.com>; Wed, 28 Nov 2012 14:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 WbQDrU1Y6uuB for <saag@ietfa.amsl.com>; Wed, 28 Nov 2012 14:30:01 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1859F21F8893 for <saag@ietf.org>; Wed, 28 Nov 2012 14:30:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=992; q=dns/txt; s=iport; t=1354141801; x=1355351401; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=r0cbFeMlmsEIk0eEJx72Vugq3Zfo1WDZQHnHUaK1Q84=; b=P27xAJYBQxPgbvc0ZJB5LvPu7bH/K9iJHxEfkjdWTvfLdW3/7lz9keUi xZj1KP4PsmB0E1GSA1d/ooZWcm2afFOpm1GnCPWVP9bEOP6qWZOfvzQdj rDPpdc9klbB7DwWJL4iQ4G/TXpbYo+weqZ5ETbaPFOoi3HVUDG2Q74gyg I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAByPtlCtJV2Y/2dsb2JhbABFwCIWc4IeAQEBAwE6UQEIIhRCJQIEARIIiAIGvyeQH2EDpkWCcoIh
X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147282842"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 28 Nov 2012 22:30:00 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qASMU0bv008135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 22:30:00 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.66]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 16:30:00 -0600
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Mouse <mouse@Rodents-Montreal.ORG>, "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"
Thread-Index: AQHNweyKBFECjqGD4EK+xvmKz2CDQJfpYOIAgADxLoCAFTNfAIAAuwAA//+8RAA=
Date: Wed, 28 Nov 2012 22:29:59 +0000
Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F54B580@xmb-rcd-x04.cisco.com>
In-Reply-To: <201211282132.QAA14540@Sparkle.Rodents-Montreal.ORG>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.117.10.227]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E9A71013B591134992809849E174F4DD@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:30:01 -0000

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.

David

v2.23.0 | Report a Bug | By Email