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

"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> Wed, 01 February 2012 15:50 UTC

Return-Path: <prvs=337851090d=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 D72E211E8071 for <cfrg@ietfa.amsl.com>; Wed, 1 Feb 2012 07:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.7
X-Spam-Level:
X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 iJ0wY8Egtdce for <cfrg@ietfa.amsl.com>; Wed, 1 Feb 2012 07:50:20 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id C7FF411E811C for <cfrg@irtf.org>; Wed, 1 Feb 2012 07:50:19 -0800 (PST)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id q11FoA4i002058 for <cfrg@irtf.org>; Wed, 1 Feb 2012 10:50:12 -0500
From: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Date: Wed, 1 Feb 2012 10:49:13 -0500
Thread-Topic: =?utf-8?B?W0NmcmddIOetlOWkjTogUmU6ICBbc2FhZ10gTmV3IGRyYWZ0OiBIYXNoZWQg?= =?utf-8?B?UGFzc3dvcmQgRXhjaGFuZ2U=?=
Thread-Index: Aczg+RC2lj+msthfRmKs/9gBkmGtJg==
Message-ID: <CB4EC84A.A54E%uri@ll.mit.edu>
In-Reply-To: <OFE5B4F6A2.A17AFEF9-ON48257997.002D1C71-48257997.002D29C8@zte.com.cn>
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_3410938159_118727070"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.211, 0.0.0000 definitions=2012-02-01_06:2012-01-31, 2012-02-01, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=55 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202010129
Subject: Re: [Cfrg] =?utf-8?b?562U5aSNOiBSZTogIFtzYWFnXSBOZXcgZHJhZnQ6IEhhc2hl?= =?utf-8?q?d_Password_Exchange?=
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: Wed, 01 Feb 2012 15:50:23 -0000

My take on this is: if you believe that a hash-function is a good randomizer
and can be used in cryptographic key generation process – then  it does not
matter whether what you feed as a "key" input to HMAC is uniformly
distributed or not (because of HMAC internal "hash spins"). And if you are
uneasy on how really random your hash output is – then a lot of the
currently used mechanisms and primitives need revisiting.
-- 
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology  Fax:    (781) 981-0186
MIT Lincoln Laboratory


From:  "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn>
Date:  Wed, 1 Feb 2012 03:13:07 -0500
To:  Dan Harkins <dharkins@lounge.org>
Cc:  "cfrg@irtf.org" <cfrg@irtf.org>rg>, Steven Bellovin <smb@cs.columbia.edu>
Subject:  [Cfrg] 答复: Re:  [saag] New draft: Hashed Password Exchange

> 
> Hi,all
> 
> cfrg-bounces@irtf.org 写于 2012-01-07 17:03:25:
> 
>> > 
>> > 
>> > On Wed, January 4, 2012 2:56 pm, Steven Bellovin wrote:
>>> > > Good point; let me think about it for -01.  An obvious solution is to
>>> send
>>> > > the hostname with the effective password.
>> > 
>> >   How is that different than using random salt then? If _something_ is
>> > going to be sent shouldn't it be a uniformly random bitstring instead of
>> > a hostname?
>> > 
>> >   A uniformly random bitstring would be more appropriate as a key to
>> > HMAC than a highly structured string like a password too. Iterate
>> > HMAC(salt, password | service-URI) instead of HMAC(password, service-URI).
> 
> 
> 
> I think Dan's suggestion is reasonable, I checked the RFC 2104 and found the
> following section :
> 
> "3. Keys
> 
>    The key for HMAC can be of any length (keys longer than B bytes are
>    first hashed using H).  However, less than L bytes is strongly
>    discouraged as it would decrease the security strength of the
>    function.  Keys longer than L bytes are acceptable but the extra
>    length would not significantly increase the function strength. (A
>    longer key may be advisable if the randomness of the key is
>    considered weak.)
> 
>    Keys need to be chosen at random (or using a cryptographically strong
>    pseudo-random generator seeded with a random seed), and periodically
>    refreshed.  (Current attacks do not indicate a specific recommended
>    frequency for key changes as these attacks are practically
>    infeasible.  However, periodic key refreshment is a fundamental
>    security practice that helps against potential weaknesses of the
>    function and keys, and limits the damage of an exposed key.)"
> 
> 
> 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.
> 
> 
> Regards~~~
> 
> -Sujing Zhou
>> > 
>> >   That said, goal 4 in the draft-- "By iterating a sufficient number of
>> > times, dictionary attacks can be made arbitrarily expensive"-- seems a
>> > bit misguided. The Amazon cloud service has been used to launch an
>> > off-line dictionary attack against the WPA-PSK protocol which uses PBKDF2
>> > (HMAC-SHA1) with 4096 iterations to obfuscate a password. This attack
>> > checks 24,000,000 candidate passwords per minute at a cost of $0.28.
>> > That's more than 1,600,000,000 iterations per second for about 1/2 a cent.
>> > So I don't think increased iteration makes dictionary attacks much more
>> > expensive.
>> > 
>> >   Which begs the question, how is this proposal different than PBKDF2?
>> > That the "salt" is a service URI?
>> > 
>> >   regards,
>> > 
>> >   Dan.
>> > 
>>> > > On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote:
>>> > >
>>>> > >> Hi, Steve,
>>>> > >>
>>>> > >> This doc doesn't appear to address the case where a host has multiple
>>>> > >> DNS names, which could make it difficult to incorporate the hostname
>>>> > >> into the transform. I.e., I could contact a mail server at an IP
>>>> address
>>>> > >> that represents any of dozens of DNS names - how does the server know
>>>> > >> which one I used so it can match without exhaustively trying all its
>>>> > >> equivalent names?
>>>> > >>
>>>> > >> Joe
>>>> > >>
>>>> > >> On 1/4/2012 1:41 PM, Steven Bellovin wrote:
>>>>> > >>> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt:
>>>>> > >>>
>>>>> > >>> Abstract
>>>>> > >>>
>>>>> > >>>    Many systems (e.g., cryptographic protocols relying on symmetric
>>>>> > >>>    cryptography) require that plaintext passwords be stored.  Given
how
>>>>> > >>>    often people reuse passwords on different systems, this poses a
very
>>>>> > >>>    serious risk if a single machine is compromised.  We propose a
>>>>> > >>> scheme
>>>>> > >>>    to derive passwords limited to a single machine from a typed
>>>>> > >>>    password, and explain how a protocol definition can specify this
>>>>> > >>>    scheme.
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>       --Steve Bellovin, https://www.cs.columbia.edu/~smb
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>> _______________________________________________
>>>>> > >>> saag mailing list
>>>>> > >>> saag@ietf.org
>>>>> > >>> https://www.ietf.org/mailman/listinfo/saag
>>>> > >>
>>> > >
>>> > >
>>> > >       --Steve Bellovin, https://www.cs.columbia.edu/~smb
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > saag mailing list
>>> > > saag@ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/saag
>>> > >
>> > 
>> > 
>> > _______________________________________________
>> > Cfrg mailing list
>> > Cfrg@irtf.org
>> > http://www.irtf.org/mailman/listinfo/cfrg
>> >