Re: [Isis-wg] draft-bhatia-manral-crypto-req-isis-01.txt
Vishwas Manral <vishwas@ipinfusion.com> Fri, 02 March 2007 22:08 UTC
Return-path: <isis-wg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFv3-0005EX-3C; Fri, 02 Mar 2007 17:08:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFv1-0005DT-IX for isis-wg@ietf.org; Fri, 02 Mar 2007 17:08:03 -0500
Received: from mail.ipinfusion.com ([65.223.109.2] helo=gateway.ipinfusion.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNFuw-0000AF-Jz for isis-wg@ietf.org; Fri, 02 Mar 2007 17:08:03 -0500
Received: from [127.0.0.1] ([65.223.109.250]) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id l22M7dK10718; Fri, 2 Mar 2007 14:07:39 -0800
Message-ID: <45E8A02A.1050106@ipinfusion.com>
Date: Fri, 02 Mar 2007 14:07:38 -0800
From: Vishwas Manral <vishwas@ipinfusion.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Tony Li <tli@cisco.com>
Subject: Re: [Isis-wg] draft-bhatia-manral-crypto-req-isis-01.txt
References: <7993FE39-A603-4830-B63F-9615A38B3DEA@cisco.com> <45E88174.7040208@ipinfusion.com> <5B7CE451-04FE-42EC-B786-8F952C3F8C0A@cisco.com>
In-Reply-To: <5B7CE451-04FE-42EC-B786-8F952C3F8C0A@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: isis-wg@ietf.org
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isis-wg>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
Errors-To: isis-wg-bounces@ietf.org
Hi Tony, Just so that we clear all confusion on the list of any probable wrong terminology. > This does not make them insecure. Our purpose in using a hashing function is to > provide authentication. We wish to ensure that an attacker cannot take an arbitrary packet > P' and compute a similar hash without knowing the secret. Collision attacks do not > give an attacker that capability. What you talk about above is pre-image attack and not a collision attack. The two are similar though not the same. We will further qualify the statement "making MD5 very insecure" in the draft. You can actually find the right version of the draft at http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-sha-01.txt Thanks a lot for bringing forth the discussion on the draft, Vishwas Tony Li wrote: > > On Mar 2, 2007, at 11:56 AM, Vishwas Manral wrote: > >> Collisions are however against the basic design of hash functions. > > > Vishwas, > > Hashing functions necessarily produce collisions. The input to a > hashing function is usually a set of bits that are a function of the > packet being sent and some secret: f(secret, packet). f() is usually > something simple, such as concatenation. The number of bits produced > by f() is usually large, say on the order of 10,000. As an example a > 1200 byte LSP is going to inject 9600 bits. > > The hashing function H(), then performs a transform: > > h = H(f(secret, packet)) > > where h is the hash result that we insert into the packet. > > The hashing function then takes these 10,000 bits and produces a much > smaller result. In the case of HMAC-MD5, it's producing 128 bits. > Simple combinatorics tells us that if you map 2^10,000 possible inputs > to 2^128th possible results, on average, there will be many different > inputs for any given output. > > Thus, collisions with a hashing function are *inevitable*. > > This does not make them insecure. Our purpose in using a hashing > function is to provide authentication. We wish to ensure that an > attacker cannot take an arbitrary packet P' and compute a similar hash > without knowing the secret. Collision attacks do not give an attacker > that capability. > > They do give the attacker the ability to compute some arbitrary packet > P" that will result in the same hash value. Once again, injecting > arbitrary packets P" is not a very interesting attack. You might as > well just generate random packets and throw them at the system. Both > will result in a DoS attack, but both should be rejected by the simple > and straightforward integrity and syntactic checks of the protocol. > > Regards, > Tony > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg
- [Isis-wg] draft-bhatia-manral-crypto-req-isis-01.… Tony Li
- Re: [Isis-wg] draft-bhatia-manral-crypto-req-isis… Vishwas Manral
- Re: [Isis-wg] draft-bhatia-manral-crypto-req-isis… Vishwas Manral
- Re: [Isis-wg] draft-bhatia-manral-crypto-req-isis… Vishwas Manral
- Re: [Isis-wg] draft-bhatia-manral-crypto-req-isis… Vishwas Manral
- RE: [Isis-wg] draft-bhatia-manral-crypto-req-isis… Parker, Jeff
- Re: [Isis-wg] draft-bhatia-manral-crypto-req-isis… Vishwas Manral
- Re: [Isis-wg] draft-bhatia-manral-crypto-req-isis… Tony Li
- Re: [Isis-wg] draft-bhatia-manral-crypto-req-isis… Russ White