IETF Logo Mail Archive

Re: about security level evaluation of draft-zhou-6man-mhash-cga-00

Jari Arkko <jari.arkko@piuha.net> Tue, 27 March 2012 21:23 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E091E21F8513 for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 14:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.525
X-Spam-Level:
X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC3Bvz9ML-uE for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 14:23:01 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 576F021F8510 for <ipv6@ietf.org>; Tue, 27 Mar 2012 14:23:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A87F12D35A; Wed, 28 Mar 2012 00:23:00 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymR3tl-r19jP; Wed, 28 Mar 2012 00:23:00 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id EE9F02CC56; Wed, 28 Mar 2012 00:22:59 +0300 (EEST)
Message-ID: <4F722FB3.1010606@piuha.net>
Date: Tue, 27 Mar 2012 23:22:59 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Christian Huitema <huitema@microsoft.com>
Subject: Re: about security level evaluation of draft-zhou-6man-mhash-cga-00
References: <OF974F286A.B19B0ED5-ONC12579CE.004B58ED-C12579CE.004C335D@zte.com.cn> <4F71CD00.8000208@piuha.net> <C91E67751B1EFF41B857DE2FE1F68ABA03CCFA91@tk5ex14mbxc272.redmond.corp.microsoft.com>
In-Reply-To: <C91E67751B1EFF41B857DE2FE1F68ABA03CCFA91@tk5ex14mbxc272.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 27 Mar 2012 21:23:02 -0000

Christian,

>> Well, I think it is quite a simple trade-off. Increasing Sec increases computational effort on both sides by equal amount. Increasing the length of
>> the hash increases computational effort only on the attacker side. As a result, the hash bits are relatively valuable.
> Jari, the effect of sec is different on both sides. The effort is not increased "by equal amount" but rather "in the same proportion." Suppose that an attacker could crack the 59 bit hash in a day with sec=0. Adding sec = 1 means that the attacker will have to try 65536 times as many keys. The time to crack becomes 65536 hours, i.e. about 7 years. The defender will have to try 65536 instead of one to get the right sec, taking only  a fraction of a second.

Right. I was imprecise in what I said. In the same proportion is right.

Jari

v2.23.0 | Report a Bug | By Email