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, 01 Feb 2012 10:49:13 -0500
Thread-Topic: [Cfrg] 答复: Re: [saag] New draft: Hashed Password Exchange
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] 答复: Re: [saag] New draft: Hashed 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>, 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 >> >
- [Cfrg] New draft: Hashed Password Exchange Steven Bellovin
- Re: [Cfrg] [saag] New draft: Hashed Password Exch… Steven Bellovin
- Re: [Cfrg] [saag] New draft: Hashed Password Exch… Steven Bellovin
- Re: [Cfrg] [saag] New draft: Hashed Password Exch… Yaron Sheffer
- Re: [Cfrg] [saag] New draft: Hashed Password Exch… Blumenthal, Uri - 0668 - MITLL
- Re: [Cfrg] [saag] New draft: Hashed Password Exch… Dan Harkins
- [Cfrg] 答复: Re: [saag] New draft: Hashed Password … zhou.sujing
- [Cfrg] 答复: Re: [saag] New draft: Hashed Password … zhou.sujing
- Re: [Cfrg] 答复: Re: [saag] New draft: Hashed Passw… Blumenthal, Uri - 0668 - MITLL
- Re: [Cfrg] 答复: Re: [saag] New draft: Hashed Passw… Rose, Greg
- Re: [Cfrg] 答复: Re: [saag] New draft: Hashed Passw… Blumenthal, Uri - 0668 - MITLL
- [Cfrg] 答复: Re: 答复: Re: [saag] New draft: Hashed P… zhou.sujing
- Re: [Cfrg] ´ð¸´: Re: ´ð¸´: Re: [saag] New draft: … Dan Harkins
- Re: [Cfrg] ´ð¸´: Re: ´ð¸´: Re: [saag] New draft: … Steven Bellovin
- Re: [Cfrg] 答复: Re: [saag] New draft: Hashed Passw… Igoe, Kevin M.
- Re: [Cfrg] 答复: Re: [saag] New draft: Hashed Passw… Blumenthal, Uri - 0668 - MITLL
- Re: [Cfrg] ´ð¸´: Re: ´ð¸´: Re: [saag] New draft: … Henry B. Hotz
- Re: [Cfrg] [saag] New draft: Hashed Password Exch… Yaron Sheffer
- Re: [Cfrg] [saag] New draft: Hashed Password Exch… Steven Bellovin
- [Cfrg] 答复: Re: ´ð¸´: Re: ´ð¸´: Re: [saag] New dra… zhou.sujing
- Re: [Cfrg] 答复: Re: ´ð¸´: Re: ´ð¸´: Re: [saag] New… Steven Bellovin
- Re: [Cfrg] [saag] New draft: Hashed Password Exch… Steven Bellovin