Re: [Cfrg] 答复: Re: [saag] New draft: Hashed Password Exchange

"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> Fri, 03 February 2012 15:46 UTC

Return-Path: <prvs=338045c413=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C01A21F8613 for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2012 07:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.923
X-Spam-Level:
X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
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 1KmNQwWgkR7Y for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2012 07:46:27 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 366A721F8610 for <cfrg@irtf.org>; Fri, 3 Feb 2012 07:46:27 -0800 (PST)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id q13FkCi2002212; Fri, 3 Feb 2012 10:46:21 -0500
From: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
To: "Igoe, Kevin M." <kmigoe@nsa.gov>, "cfrg@irtf.org" <cfrg@irtf.org>
Date: Fri, 3 Feb 2012 10:45:54 -0500
Thread-Topic: =?big5?B?W0NmcmddILWqzmA6IFJlOiAgW3NhYWddIE5ldyBkcmFmdDogSGFzaGVkIFBhc3M=?= =?big5?B?d29yZCBFeGNoYW5nZQ==?=
Thread-Index: AcziiuvZralO01ZATtGSzKnRilvCdA==
Message-ID: <CB516A66.ECDA%uri@ll.mit.edu>
In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425BAD@MSIS-GH1-UEA06.corp.nsa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.12.0.110505
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3411110754_7626301"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-03_05:2012-02-02, 2012-02-03, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=57 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202030133
Subject: Re: [Cfrg] =?big5?b?tarOYDogUmU6ICBbc2FhZ10gTmV3IGRyYWZ0OiBIYXNoZWQg?= =?big5?b?UGFzc3dvcmQgRXhjaGFuZ2U=?=
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2012 15:46:28 -0000

The real benefit of hashing a password is making the result more-or-less
uniformly distributed in the key-space of the subsequent consumer (some
cryptographers argue that all the proofs about block cipher constructs
hold only if the key is random & uniformly distributed :). In this
particular case, it shouldn't matter what kind of input HMAC (or the
underlying hash) is fed. My $0.02.
-- 
Regards,
Uri      uri@ll.mit.edu





On 2/3/12 09:08 AM, "Igoe, Kevin M." <kmigoe@nsa.gov> wrote:

>Applying a function to a random variable can never increase its
>entopy.  See chapter 2 of Cover & Thomas' "Elements of Information
>Theory", exercise 5, which shows that for any function g and random
>variable X in the domain of g,
>
>	H( g(X) ) <= H(X)
>
>(where H(Z) = the entropy of a random variable Z).
> 
>In our case g is a hash function, X is the original password and
>g(X) is the hash of the password. Then a hashed password cannot
>have more entropy than the original password and may in fact
>have less entropy.
>
>
>> -----Original Message-----
>> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
>> Blumenthal, Uri - 0668 - MITLL
>> Sent: Wednesday, February 01, 2012 4:46 PM
>> To: cfrg@irtf.org
>> Subject: Re: [Cfrg] 答复: Re: [saag] New draft: Hashed Password
>> Exchange
>> 
>> On 2/1/12 12:11 , "Rose, Greg" <ggr@qualcomm.com> wrote:
>> 
>> >On 2012 Feb 1, at 0:13 , <zhou.sujing@zte.com.cn>
>> ><zhou.sujing@zte.com.cn> wrote:
>> >> Since passwords are often not too long, and not so random, it is
>> better
>> >> to hash it before using it as a key in a HMAC.
>> >
>> >I'm afraid this is a fallacy. While it will be longer, and will look
>> >random, there is exactly the same (lack of) entropy in a hashed weak
>> >password as there is in the original password. It's still vulnerable
>> to
>> >password search, although with a slightly increased workload due to
>> the
>> >(single) extra hash invocation.
>> 
>> Concur 100%.
>> 
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg