RE: FW: New Version Notification for draft-rafiee-6man-cga-attack-00.txt

Greg Daley <gdaley@au.logicalis.com> Mon, 02 December 2013 01:07 UTC

Return-Path: <gdaley@au.logicalis.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951CB1AE2B7 for <ipv6@ietfa.amsl.com>; Sun, 1 Dec 2013 17:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.908
X-Spam-Level:
X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
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 UaHvYt3eh6UW for <ipv6@ietfa.amsl.com>; Sun, 1 Dec 2013 17:07:27 -0800 (PST)
Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id 33DE81AE2AD for <ipv6@ietf.org>; Sun, 1 Dec 2013 17:07:27 -0800 (PST)
Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only
Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only
Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp2.au.logicalis.com with ESMTP; 02 Dec 2013 12:07:24 +1100
Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 12:07:24 +1100
From: Greg Daley <gdaley@au.logicalis.com>
To: 'Hosnieh Rafiee' <ietf@rozanak.com>, 'marcelo bagnulo braun' <marcelo@it.uc3m.es>, 'Christian Huitema' <huitema@microsoft.com>, 'Ray Hunter' <v6ops@globis.net>
Subject: RE: FW: New Version Notification for draft-rafiee-6man-cga-attack-00.txt
Thread-Topic: FW: New Version Notification for draft-rafiee-6man-cga-attack-00.txt
Thread-Index: Ac7smeEVAgkCvPF12cG9eyx+VjbUAgAFOGeg//+TVQCAAAQngIAEEkEAgAAIeYCAAADmAP//KfvQ
Date: Mon, 02 Dec 2013 01:07:22 +0000
Message-ID: <72381AF1F18BAE4F890A0813768D992801207E57@sdcexchms.au.logicalis.com>
References: <005601ceec99$ed4cfc40$c7e6f4c0$@rozanak.com> <C91E67751B1EFF41B857DE2FE1F68ABA2FBC395D@tk5ex14mbxc272.redmond.corp.microsoft.com> <000001ceecd4$a69b4aa0$f3d1dfe0$@rozanak.com> <529845A5.5060807@it.uc3m.es> <001101ceeedf$da768080$8f638180$@rozanak.com> <529BB70F.1060804@it.uc3m.es> <001401ceeee4$8a1af620$9e50e260$@rozanak.com>
In-Reply-To: <001401ceeee4$8a1af620$9e50e260$@rozanak.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.196.183]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, 'Erik Nordmark' <nordmark@sonic.net>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 01:07:29 -0000

Hi Hosnieh, 

I think that the points raised by Marcelo and Christian are important.

Your analysis appears to focus on the field (from the paper referenced) being heavily populated.   For a more usual number of link (or subnet) residents, the rate of collision is lower.   As pointed out by Christian, the attack would be directed at all devices present, but a single (not pre-determined/predictable) device would be collided with under the "birthday" collision.

Please forgive any mistakes in my attempt at analysis.  It has been a while.

>From the referenced paper the probability of a collision on population q on field  r is :

/q\ 
\2/
---
 r^(mu(h))

for:
q is the number of nodes resident on the subnet.
r = 2^62, (or 2^64, omitted for brevity).
q << r
mu(h) ~ 1  (but < 1 for some hash functions)
Following Christian, the number of trials isn't impacted by the SEC value (but each trial is more expensive).  I've not had time to work through this this morning.   Even in the case of the 

~> for the balanced hash function:

/q\
\2/
---
 r

~>

( q! / ( 2* ( q - 2)! )
-----------------------
         r
~>

( q * (q-1) )
-------------
   2r

so for subnets with 1000 hosts:

500*999
------- 
2^62

~> p ~ 2^-43.06 
~> on average 2^42.06 trials to find a single collision.

If SHA-1 was as bad as mu(h) = 0.98, we lose about 1.04 bits:

500*999
-------
2^60.96

~> p ~ 2^-42.02
~> on average 2^41.02 trials to find a single collision on the 1000 nodes.

>From the research presented, this is a generously high side estimate of the SHA-1 imbalance so the impact is between the values presented (0.98 and 1).

For 10000 nodes on the subnet, the possibility of a collision for one of the nodes may be found in:

5000*9999
---------
2^62

~> p ~ 2^-36.42 
~> on average 2^35.62 trials to find a single collision on the 10000 nodes (2^34.58 at high imbalance)


(perfect hash distribution, 2^62 possible values, 
nodes | log2(0.5n*(n-1)) | p(collision) | mean trials for collision.
-----------------------------------------------
32     | 9.1241       | 2^-54.87 | 2^53.87
64     | 10.977       | 2^-51.022 | 2^50.02
128   | 12.988       | 2^-49.011 | 2^48.01
256   | 14.994       | 2^-47.005 | 2^46.00
512   | 16.997       | 2^-45.002 | 2^44.00
1024  | 18.998       | 2^-43.001 | 2^42.00
2048  | 20.999       | 2^-41.000 | 2^40.00
4096  | 23.000       | 2^-39.000 | 2^38.00
8192  | 25.000       | 2^-37.000 | 2^36.00
16384 | 27.000       | 2^-35.000 | 2^34.00
32768 | 29.000       | 2^-33.000 | 2^32.00

* For 2^64 possible values, add 2 bits to the number of trials/subtract two bits for the probability
* For mu(h) of 0.98 subtract 1.04 bits from the number of trials/add 1.04 bits for the probability

Please note that this is for a single collision with a non-predictable CGA. A second collision would be on average slightly harder than the prior one (since the potential targets are fewer, although some of the search space would be processed), and so on, with increasing complexity to collide with subsequent nodes. 

I'll leave it for others to identify if this is accurate, or reflects a significant impact on SEND/CGA when SEC is non-zero (getting back to work).

Greg Daley 



-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Monday, 2 December 2013 9:27 AM
To: 'marcelo bagnulo braun'; 'Christian Huitema'; 'Ray Hunter'
Cc: ipv6@ietf.org; 'Erik Nordmark'
Subject: RE: FW: New Version Notification for draft-rafiee-6man-cga-attack-00.txt

> > Birthday attack is still possible with the following approach. Check 
> > this nice article.
> > http://eprint.iacr.org/2003/065.pdf
> 
> I just skimmed the paper and it seems to state that in some hash 
> functions fewer attemps are needed to find a clash.
> This does not contradicts my statement. Birthday paradox can be used 
> to
find
> tow values that clash, not to find a preimage of a given target value.
> 

What I understood from reading it is that, they want to find the possible collision for any given value. So, I saw the similarity of our case. What we wanna do is to find a collision for the value of legitimate node.

Smile,
Hosnieh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------