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