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

"Blumenthal, Uri - 0668 - MITLL" <> Thu, 05 January 2012 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DD6E21F8767; Thu, 5 Jan 2012 08:28:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.45
X-Spam-Status: No, score=-4.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B2cdrCpCCoDt; Thu, 5 Jan 2012 08:28:39 -0800 (PST)
Received: from (MX2.LL.MIT.EDU []) by (Postfix) with ESMTP id C306421F86D1; Thu, 5 Jan 2012 08:28:38 -0800 (PST)
Received: from ( by (unknown) with ESMTP id q05GSKc2015009; Thu, 5 Jan 2012 11:28:20 -0500
From: "Blumenthal, Uri - 0668 - MITLL" <>
To: Steven Bellovin <>
Date: Thu, 5 Jan 2012 11:28:12 -0500
Thread-Topic: [Cfrg] [saag] New draft: Hashed Password Exchange
Thread-Index: AczLxwjthKWn6Sa0TTSjnfq/FJnchw==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3408607697_86656470"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2012-01-05_05:2012-01-05, 2012-01-05, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201050160
Cc: "" <>, "" <>
Subject: Re: [Cfrg] [saag] New draft: Hashed Password Exchange
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jan 2012 16:28:40 -0000


How would you compare your proposed localizing-by-URI approach with
localizing-by-host (or by "SNMP engine") approach proposed in RFC 3414 ?

Some questions to consider.

You propose "localization" by service - i.e., by hostname + port. How many
passwords per user would a server store? How critical is your requirement
that "no two [effective] `passwords for different services [on the same
host] should be the same for the same user"?  A benefit of not localizing
based on the whole service would be the ability for a multi-named server ­
based on some rules that are out of scope for this email ­ choose the
"dominant" name and localize users' passwords to it, thus storing one
password per user on this server; avoiding the potential ambiguity that Joe
Touch pointed out.

Is HMAC an overkill in this case, considering that inverting a decent hash
didn't work even for the long-deprecated MD4 (we seem to worry here about
non-invertibility/one-way-ness, not collision resistance)? Or did you choose
it because it's the best keyed hash construct we have?  Note that the
brute-force attacks would be the same for both plain hash and HMAC (with
HMAC offering one more hash run per iteration).

Regarding salt ­ couldn't it be used on the server only? Treating the
"localized password" as the pre-salted password in the original Unix scheme,
then salting it before comparison? Obviously this is not the method to use
in protocols that employ the password derivative as a cryptographic keyŠ

Oh, and since this proposal seems to be addressing the same problem in a
somewhat similar way ­ perhaps it would make sense to include a reference to
RFC 3414 (section 2.6 Key Localization Algorithm)? :)