From kmigoe@nsa.gov Wed Jan 4 05:15:31 2012 Return-Path: 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 E871121F85BA; Wed, 4 Jan 2012 05:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 y6fvyeFjYwPX; Wed, 4 Jan 2012 05:15:31 -0800 (PST) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2A25521F8716; Wed, 4 Jan 2012 05:15:30 -0800 (PST) Received: from MSCS-GH1-UEA02.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id q04DFPM6004461; Wed, 4 Jan 2012 13:15:29 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jan 2012 08:14:37 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Jan 2012 08:14:37 -0500 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B8F@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] password-based key exchange Thread-Index: Acy/X7Yum82oOjagRhO3T6IYweJmAwLgcKcw References: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> From: "Igoe, Kevin M." To: "Dan Harkins" , X-OriginalArrivalTime: 04 Jan 2012 13:14:37.0865 (UTC) FILETIME=[CF719990:01CCCAE2] Cc: tls@ietf.org Subject: Re: [Cfrg] password-based key exchange X-BeenThere: cfrg@irtf.org 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: Wed, 04 Jan 2012 13:15:32 -0000 I really like this idea & can find no problems. One nitpicking detail: HashToElement should return an element of a=20 cryptographic subgroup of (Z/pZ)*, i.e. an element of a cyclic subgroup=20 of prime order q, q suitably large. (Of course both sides should use the=20 same subgroup, but in practice this isn't a problem since the standard mod p=20 groups specify both q and an element g of order q which generates the=20 cryptographic subgroup.) I'm curious as to what size parameters are under consideration by IEEE. > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Dan Harkins > Sent: Tuesday, December 20, 2011 4:38 PM > To: cfrg@irtf.org > Cc: tls@ietf.org > Subject: [Cfrg] password-based key exchange >=20 >=20 > Hello, >=20 > I proposed a new TLS ciphersuite using a zero knowledge proof at > IETF 82 in Taipei. The draft is here: >=20 > http://tools.ietf.org/html/draft-harkins-tls-pwd-01 >=20 > At the TLS WG meeting I was requested to ask people on the CFRG list > with expertise in this field to take a look at it. So here I am, > asking. > If someone has some spare cycles this holiday season, if you just gotta > get away from the relatives, or you are just feeling in the giving > mood, > please take a look and comment. Any analysis on this would be greatly > appreciated. (I tried to do a formal proof but I cannot, and that's > what's prompting this). >=20 > I can describe the key exchange broadly here. There are subtle > differences in the draft-- like one side keeps a salted version of the > password and communicates the salt during a HELLO message-- that don't > affect the exchange. It is symmetric so I can describe it from one > side's > perspective. The side being described is "local" and the other side is > "peer", it goes like this: >=20 > Given: local ID, peer ID, password, an agreed-upon set of domain > parameters defining a finite field group (it works will elliptic > curve crypto too) and using two function: >=20 > - E =3D HashToElement(d) which takes some data, d, and hashes into > the finite field to return an element, E. > - x =3D H(y) returns a random stream, x, given some input, y. >=20 > The key exchange works like this: >=20 > 1. PE =3D HashToElement(local_ID | peer_ID | password) > gets a "password element" >=20 > There is an ordering defined in the draft to ensure that the IDs > are put in the same order on each side. >=20 > 2. generate 2 random numbers between 0 and the order of the group, q: >=20 > 0 < local_rand, local_mask < q >=20 > 3. compute a scalar and an element: > local_scalar =3D (local_rand + local_mask) mod q > local_element =3D 1/(PE^local_mask) mod p >=20 > where p is the prime and q is the order. Send local_scalar and > local_element to other side >=20 > 4. receive peer_scalar and peer_element from other side >=20 > 5. compute shared key, K >=20 > K =3D (PE^peer_scalar * peer_element)^local_rand mod p =3D > (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p > =3D > PE^(peer_rand*local_rand) mod p >=20 > 6. compute a confirmation >=20 > local_confirm =3D H(K, local_scalar | local_element | > peer_scalar | peer_element) >=20 > send confirmation to peer >=20 > 7. receive peer's confirmation, calculate verifier >=20 > verifier =3D H(K, peer_scalar | peer_element | local_scalar | > local_element) >=20 > if verifier equals peer's confirmation the peer is authenticated. >=20 > The peer does the same thing but from its perspective it is "local" > and the side described above is "peer". >=20 > Thank you in advance for any analysis that can be provided on this > exchange. >=20 > regards, >=20 > Dan. >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From dharkins@lounge.org Wed Jan 4 10:30:09 2012 Return-Path: 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 62A2D21F8788 for ; Wed, 4 Jan 2012 10:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 NlKGZv+pA6b0 for ; Wed, 4 Jan 2012 10:30:09 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6F121F878A for ; Wed, 4 Jan 2012 10:30:09 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 859C1A88810C; Wed, 4 Jan 2012 10:30:08 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 4 Jan 2012 10:30:08 -0800 (PST) Message-ID: <4ef8068ab2486a8f2ba8e067c07be426.squirrel@www.trepanning.net> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B8F@MSIS-GH1-UEA06.corp.nsa.gov> References: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B8F@MSIS-GH1-UEA06.corp.nsa.gov> Date: Wed, 4 Jan 2012 10:30:08 -0800 (PST) From: "Dan Harkins" To: "Igoe, Kevin M." User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org, tls@ietf.org Subject: Re: [Cfrg] password-based key exchange X-BeenThere: cfrg@irtf.org 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: Wed, 04 Jan 2012 18:30:09 -0000 Hi Kevin, Thank you very much for reviewing this draft. On Wed, January 4, 2012 5:14 am, Igoe, Kevin M. wrote: > I really like this idea & can find no problems. > > One nitpicking detail: HashToElement should return an element of a > cryptographic subgroup of (Z/pZ)*, i.e. an element of a cyclic subgroup > of prime order q, q suitably large. (Of course both sides should use > the > same subgroup, but in practice this isn't a problem since the standard > mod p > groups specify both q and an element g of order q which generates the > cryptographic subgroup.) I believe the two techniques used in section 4.1-- one for FFC groups, another for ECC groups-- return an element from a subgroup of prime order q. > I'm curious as to what size parameters are under consideration by IEEE. The specification of this key exchange in IEEE 802.11 uses the IANA registry created by IKE for "diffie-hellman groups" so it can use the NIST elliptic curves, and the safe prime FFC groups (from 1024 bits up to 8192 bits). Implementations are required to support NIST's 256 bit random ECP group (group 19 from IKE's IANA registry). regards, Dan. From smb@cs.columbia.edu Wed Jan 4 13:41:59 2012 Return-Path: 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 CAE8F1F0C3C; Wed, 4 Jan 2012 13:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jFAmWLdU3icB; Wed, 4 Jan 2012 13:41:59 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 17D261F0C3B; Wed, 4 Jan 2012 13:41:59 -0800 (PST) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q04Lfuvi028926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Jan 2012 16:41:56 -0500 (EST) From: Steven Bellovin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 4 Jan 2012 16:41:55 -0500 Message-Id: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> To: cfrg@irtf.org, saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Subject: [Cfrg] New draft: Hashed Password Exchange X-BeenThere: cfrg@irtf.org 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: Wed, 04 Jan 2012 21:41:59 -0000 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 From smb@cs.columbia.edu Wed Jan 4 14:56:12 2012 Return-Path: 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 E163E11E80B6; Wed, 4 Jan 2012 14:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 woq8L7Cyj8ss; Wed, 4 Jan 2012 14:56:12 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 962CF11E80C5; Wed, 4 Jan 2012 14:56:11 -0800 (PST) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q04Mu9sE012435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Jan 2012 17:56:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Steven Bellovin In-Reply-To: <4F04D0CD.9010807@isi.edu> Date: Wed, 4 Jan 2012 17:56:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:56:13 -0000 Good point; let me think about it for -01. An obvious solution is to = send the hostname with the effective password. On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote: > Hi, Steve, >=20 > 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? >=20 > Joe >=20 > On 1/4/2012 1:41 PM, Steven Bellovin wrote: >> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: >>=20 >> Abstract >>=20 >> 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. >>=20 >>=20 >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 --Steve Bellovin, https://www.cs.columbia.edu/~smb From smb@cs.columbia.edu Wed Jan 4 15:36:38 2012 Return-Path: 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 A764211E8135; Wed, 4 Jan 2012 15:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] 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 6CWQwAD6rYXz; Wed, 4 Jan 2012 15:36:38 -0800 (PST) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id B322611E8134; Wed, 4 Jan 2012 15:36:37 -0800 (PST) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q04NaY1C018521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Jan 2012 18:36:35 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Steven Bellovin In-Reply-To: <4F04DAA1.5050604@isi.edu> Date: Wed, 4 Jan 2012 18:36:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <33E0B548-D141-48CA-86DC-F7E4EB1DEDD2@cs.columbia.edu> References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> <4F04DAA1.5050604@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:36:38 -0000 Not with HMAC -- we do it all the time with, say, ESP-NULL. On Jan 4, 2012, at 6:02 57PM, Joe Touch wrote: >=20 >=20 > On 1/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. >=20 > Yes, I considered that, but then you're sending cleartext that was = part of the hash; I thought that was frowned upon... >=20 > Joe >=20 >>=20 >> On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote: >>=20 >>> Hi, Steve, >>>=20 >>> 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? >>>=20 >>> Joe >>>=20 >>> On 1/4/2012 1:41 PM, Steven Bellovin wrote: >>>> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: >>>>=20 >>>> Abstract >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> saag mailing list >>>> saag@ietf.org >>>> https://www.ietf.org/mailman/listinfo/saag >>>=20 >>=20 >>=20 >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>=20 >>=20 >>=20 >>=20 >>=20 >=20 --Steve Bellovin, https://www.cs.columbia.edu/~smb From jkatz@cs.umd.edu Wed Jan 4 17:27:35 2012 Return-Path: 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 3D54C21F8746 for ; Wed, 4 Jan 2012 17:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 j1489qX99I8G for ; Wed, 4 Jan 2012 17:27:34 -0800 (PST) Received: from bacon.cs.umd.edu (router-304.cs.umd.edu [128.8.127.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3298521F856B for ; Wed, 4 Jan 2012 17:27:34 -0800 (PST) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (Authenticated sender: jkatz) by bacon.cs.umd.edu (Postfix) with ESMTPSA id E96C8B4101E for ; Wed, 4 Jan 2012 20:27:30 -0500 (EST) Received: by iadj38 with SMTP id j38so93699iad.13 for ; Wed, 04 Jan 2012 17:27:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.219.226 with SMTP id pr2mr68396348igc.30.1325726850542; Wed, 04 Jan 2012 17:27:30 -0800 (PST) Received: by 10.231.49.65 with HTTP; Wed, 4 Jan 2012 17:27:30 -0800 (PST) Date: Wed, 4 Jan 2012 20:27:30 -0500 Message-ID: From: Jonathan Katz To: cfrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.8 (bacon.cs.umd.edu [0.0.0.0]); Wed, 04 Jan 2012 20:27:31 -0500 (EST) X-CSD-MailScanner-ID: E96C8B4101E.AAC6C X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: jkatz@cs.umd.edu X-CSD-MailScanner-Watermark: 1326331651.33834@mMKKFFx+mthWbA1a+3ZXTQ Cc: tls@ietf.org Subject: Re: [Cfrg] password-based key exchange X-BeenThere: cfrg@irtf.org 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 01:27:35 -0000 You don't specify your threat model. One formal model for password-based key exchange is the one introduced by Bellare, Pointcheval, and Rogaway in 2000 and used in several papers since then. What threat model did you have in mind? (In fact, the protocol seems susceptible to attacks within the [BPR00] model, although I didn't manage to find any full-fledged attack.) Some other "obvious" things you may want to consider: - It's usually considered a bad idea to let the final session key be one that was also used for key confirmation. So you may want to add a step where the final session key is derived (using a suitable KDF) from the intermediate key K. - To head off potential avenues of attack, it is probably a good idea to have peer check that local_scalar \neq 0 and local_element \neq 1, and vice versa. > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Dan Harkins > Sent: Tuesday, December 20, 2011 4:38 PM > To: cfrg@irtf.org > Cc: tls@ietf.org > Subject: [Cfrg] password-based key exchange > > > Hello, > > I proposed a new TLS ciphersuite using a zero knowledge proof at > IETF 82 in Taipei. The draft is here: > > http://tools.ietf.org/html/draft-harkins-tls-pwd-01 > > At the TLS WG meeting I was requested to ask people on the CFRG list > with expertise in this field to take a look at it. So here I am, > asking. > If someone has some spare cycles this holiday season, if you just gotta > get away from the relatives, or you are just feeling in the giving > mood, > please take a look and comment. Any analysis on this would be greatly > appreciated. (I tried to do a formal proof but I cannot, and that's > what's prompting this). > > I can describe the key exchange broadly here. There are subtle > differences in the draft-- like one side keeps a salted version of the > password and communicates the salt during a HELLO message-- that don't > affect the exchange. It is symmetric so I can describe it from one > side's > perspective. The side being described is "local" and the other side is > "peer", it goes like this: > > Given: local ID, peer ID, password, an agreed-upon set of domain > parameters defining a finite field group (it works will elliptic > curve crypto too) and using two function: > > - E = HashToElement(d) which takes some data, d, and hashes into > the finite field to return an element, E. > - x = H(y) returns a random stream, x, given some input, y. > > The key exchange works like this: > > 1. PE = HashToElement(local_ID | peer_ID | password) > gets a "password element" > > There is an ordering defined in the draft to ensure that the IDs > are put in the same order on each side. > > 2. generate 2 random numbers between 0 and the order of the group, q: > > 0 < local_rand, local_mask < q > > 3. compute a scalar and an element: > local_scalar = (local_rand + local_mask) mod q > local_element = 1/(PE^local_mask) mod p > > where p is the prime and q is the order. Send local_scalar and > local_element to other side > > 4. receive peer_scalar and peer_element from other side > > 5. compute shared key, K > > K = (PE^peer_scalar * peer_element)^local_rand mod p = > (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p > = > PE^(peer_rand*local_rand) mod p > > 6. compute a confirmation > > local_confirm = H(K, local_scalar | local_element | > peer_scalar | peer_element) > > send confirmation to peer > > 7. receive peer's confirmation, calculate verifier > > verifier = H(K, peer_scalar | peer_element | local_scalar | > local_element) > > if verifier equals peer's confirmation the peer is authenticated. > > The peer does the same thing but from its perspective it is "local" > and the side described above is "peer". > > Thank you in advance for any analysis that can be provided on this > exchange. > > regards, > > Dan. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From dharkins@lounge.org Wed Jan 4 18:47:28 2012 Return-Path: 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 082F411E8080 for ; Wed, 4 Jan 2012 18:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 ANOVjcE6m5Mc for ; Wed, 4 Jan 2012 18:47:27 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAB221F84EC for ; Wed, 4 Jan 2012 18:47:27 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C12CDA88810C; Wed, 4 Jan 2012 18:47:25 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 4 Jan 2012 18:47:26 -0800 (PST) Message-ID: In-Reply-To: References: Date: Wed, 4 Jan 2012 18:47:26 -0800 (PST) From: "Dan Harkins" To: "Jonathan Katz" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org, tls@ietf.org Subject: Re: [Cfrg] password-based key exchange X-BeenThere: cfrg@irtf.org 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 02:47:28 -0000 Hello, Thank you for looking at this protocol. On Wed, January 4, 2012 5:27 pm, Jonathan Katz wrote: > You don't specify your threat model. One formal model for > password-based key exchange is the one introduced by Bellare, > Pointcheval, and Rogaway in 2000 and used in several papers since > then. What threat model did you have in mind? That is one I had in mind. I think this protocol can be described in that model. Each side is an instance of the protocol controlled by a principle. Each side consumes and produces flows until they accept. While the distinction is not apparent in the TLS version of this key exchange, the 802.11 one does note that "acceptance" (obtaining a good session key) is different than "termination" (quitting the protocol run). I looked closely at their paper "Authenticated Key Exchange Secure Against Dictionary Attacks" but I do not have the information-theoretic background to complete a proof of this protocol in that model. If you happen to know a student who wants make a name for himself or herself by finding a flaw in the latest version of 802.11 (and hopefully in a new TLS ciphersuite) please have him or her take a look. I imagine there could be a paper in it. :-) > (In fact, the protocol seems susceptible to attacks within the [BPR00] > model, although I didn't manage to find any full-fledged attack.) Can you elaborate on what seems susceptible to attack? > Some other "obvious" things you may want to consider: > - It's usually considered a bad idea to let the final session key be > one that was also used for key confirmation. So you may want to add a > step where the final session key is derived (using a suitable KDF) > from the intermediate key K. The key becomes the pre-master secret in TLS and that does get input into a KDF to derive a suitable set of keys for protecting the application data. This was not obvious in the brief overview I presented below, my bad. > - To head off potential avenues of attack, it is probably a good idea > to have peer check that local_scalar \neq 0 and local_element \neq 1, > and vice versa. Thank you for this. Such a check is made upon receipt of the peer's scalar and element, and at generation time there is a check that local_scalar is not equal to 0 but there is no check that local_element is valid (for FFC, between 1 and p, and exponentiation of the element with the order does equal 1; and, for ECC, the coordinates satisfy the equation of the curve and the element is not the "point at infinity"). I will add the missing element check at generation time. regards, Dan. > >> -----Original Message----- >> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf > Of >> Dan Harkins >> Sent: Tuesday, December 20, 2011 4:38 PM >> To: cfrg@irtf.org >> Cc: tls@ietf.org >> Subject: [Cfrg] password-based key exchange >> >> >> Hello, >> >> I proposed a new TLS ciphersuite using a zero knowledge proof at >> IETF 82 in Taipei. The draft is here: >> >> http://tools.ietf.org/html/draft-harkins-tls-pwd-01 >> >> At the TLS WG meeting I was requested to ask people on the CFRG list >> with expertise in this field to take a look at it. So here I am, >> asking. >> If someone has some spare cycles this holiday season, if you just > gotta >> get away from the relatives, or you are just feeling in the giving >> mood, >> please take a look and comment. Any analysis on this would be greatly >> appreciated. (I tried to do a formal proof but I cannot, and that's >> what's prompting this). >> >> I can describe the key exchange broadly here. There are subtle >> differences in the draft-- like one side keeps a salted version of the >> password and communicates the salt during a HELLO message-- that don't >> affect the exchange. It is symmetric so I can describe it from one >> side's >> perspective. The side being described is "local" and the other side is >> "peer", it goes like this: >> >> Given: local ID, peer ID, password, an agreed-upon set of domain >> parameters defining a finite field group (it works will elliptic >> curve crypto too) and using two function: >> >> - E = HashToElement(d) which takes some data, d, and hashes into >> the finite field to return an element, E. >> - x = H(y) returns a random stream, x, given some input, y. >> >> The key exchange works like this: >> >> 1. PE = HashToElement(local_ID | peer_ID | password) >> gets a "password element" >> >> There is an ordering defined in the draft to ensure that the IDs >> are put in the same order on each side. >> >> 2. generate 2 random numbers between 0 and the order of the group, q: >> >> 0 < local_rand, local_mask < q >> >> 3. compute a scalar and an element: >> local_scalar = (local_rand + local_mask) mod q >> local_element = 1/(PE^local_mask) mod p >> >> where p is the prime and q is the order. Send local_scalar and >> local_element to other side >> >> 4. receive peer_scalar and peer_element from other side >> >> 5. compute shared key, K >> >> K = (PE^peer_scalar * peer_element)^local_rand mod p = >> (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p >> = >> PE^(peer_rand*local_rand) mod p >> >> 6. compute a confirmation >> >> local_confirm = H(K, local_scalar | local_element | >> peer_scalar | peer_element) >> >> send confirmation to peer >> >> 7. receive peer's confirmation, calculate verifier >> >> verifier = H(K, peer_scalar | peer_element | local_scalar | >> local_element) >> >> if verifier equals peer's confirmation the peer is authenticated. >> >> The peer does the same thing but from its perspective it is "local" >> and the side described above is "peer". >> >> Thank you in advance for any analysis that can be provided on this >> exchange. >> >> regards, >> >> Dan. >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > From yaronf.ietf@gmail.com Wed Jan 4 23:13:02 2012 Return-Path: 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 031611F0C41 for ; Wed, 4 Jan 2012 23:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Bjmh0EHeuhfd for ; Wed, 4 Jan 2012 23:13:01 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD5A21F8688 for ; Wed, 4 Jan 2012 23:13:01 -0800 (PST) Received: by eekc50 with SMTP id c50so171373eek.13 for ; Wed, 04 Jan 2012 23:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UeGoE+W6fBSmDbX/8Fi0B14nahJhTXFb4sg1a/xFG6I=; b=QUA3DeYcrXggw7Riaku3H781aRrsgm1Fsb+dvQ+ybt5X7ZrXdqt3FtamVZxHH/fOoT aVfjrcT+vNeK1//bnzUPhyUDMgv41hlBqmYspkZZcmrlCYgcA4KhbReAnOcnioGt3H2X WC644fYNME6FUULSTfgnCSifGaX5TGojN3W1k= Received: by 10.213.8.145 with SMTP id h17mr279192ebh.62.1325747579975; Wed, 04 Jan 2012 23:12:59 -0800 (PST) Received: from [10.0.0.6] ([109.67.155.85]) by mx.google.com with ESMTPS id a60sm230100356eeb.4.2012.01.04.23.12.58 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 23:12:59 -0800 (PST) Message-ID: <4F054D78.1080008@gmail.com> Date: Thu, 05 Jan 2012 09:12:56 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Steven Bellovin References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> <4F04DAA1.5050604@isi.edu> <33E0B548-D141-48CA-86DC-F7E4EB1DEDD2@cs.columbia.edu> In-Reply-To: <33E0B548-D141-48CA-86DC-F7E4EB1DEDD2@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 07:13:02 -0000 Hi Steve, thanks for the new draft. A few comments: * The argument against using a random salt is somewhat unconvincing: "it would have to be known to the user as well as the server, and users typically have multiple devices on which they enter passwords." Since we assume computing power on the client side, there's no reason why we cannot have the server send the salt to the user instead of having it stored client-side. I do agree though that the benefits of a random salt added to this scheme are minimal. * Arbitrary non-ASCII passwords must be supported. I suggest to remove the under-specified bullet about "canonicalizing the entered password" and adopt text similar to (from RFC 6124): This protocol supports internationalized, non-ASCII passwords. The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output is the binary representation of the processed UTF-8 [RFC3629] character string. Prohibited output and unassigned code points encountered in SASLprep preprocessing SHOULD cause a preprocessing failure and the output SHOULD NOT be used. * The text implicitly assumes that we are "sending the effective password over the wire." This is obviously not the case if strong password-based methods of the EKE family are used. * "If effective passwords are used only for the usual password verification and not for cryptographic purposes, they should be treated with the care used for ordinary password, i.e., salted, hashed, etc. " I can see the value of hashing here, but not of salting. Thanks, Yaron > >> >>> 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 >>> >> >>> >> >>> >> >>> >> >>> >> >> > > --Steve Bellovin,https://www.cs.columbia.edu/~smb > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From ynir@checkpoint.com Wed Jan 4 23:29:33 2012 Return-Path: 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 C85F521F86BE for ; Wed, 4 Jan 2012 23:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.881 X-Spam-Level: X-Spam-Status: No, score=-9.881 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751] 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 W0yVjCqPPioL for ; Wed, 4 Jan 2012 23:29:33 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CDF0621F8522 for ; Wed, 4 Jan 2012 23:29:32 -0800 (PST) X-CheckPoint: {4F054F19-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q057TUvj008069 for ; Thu, 5 Jan 2012 09:29:30 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 5 Jan 2012 09:29:30 +0200 From: Yoav Nir To: "cfrg@irtf.org" Date: Thu, 5 Jan 2012 09:29:35 +0200 Thread-Topic: Question about the order of hashing Thread-Index: AczLe8NYNGQU3c3hQTGsUoEUIw5y7w== Message-ID: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Cfrg] Question about the order of hashing X-BeenThere: cfrg@irtf.org 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 07:29:33 -0000 Hi. When using keyed hash functions such as HMAC, GHash, and CBC-MAC, does the = order of the items being concatenated and hashed make any difference to the= security properties of the keyed hash? IOW, does changing HMAC(k, a||b) into HMAC(k, b||a) change the security pro= perties. My motivation for this question is that I would like to propose a variant f= or IPsec where the sequence numbers are hashed after the payload rather tha= n before it. Different size packets take different times to hash, so if we = try to parallelize IPsec processing, arbitrarily many packets may finish pr= ocessing before a large single packet has finished processing.=20 IPsec emitters are required to emit the packets in order of the sequence nu= mbers, but since the sequence numbers (which are sent in the clear) are has= hed first, they have to be allocated before hashing begins. By moving them = to the end of the hash, I can allocate the sequence number after having has= hed most of the packet, and have nearly constant-time processing after allo= cating the sequence number. So is this scheme I'm proposing save, or would it introduce some major vuln= erability. Thanks Yoav From smb@cs.columbia.edu Thu Jan 5 01:10:24 2012 Return-Path: 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 9347F21F86DF for ; Thu, 5 Jan 2012 01:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.257 X-Spam-Level: X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=-2.009, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, SARE_OBFU_ALL=0.751] 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 CmWLs+t07Afz for ; Thu, 5 Jan 2012 01:10:22 -0800 (PST) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 938CD21F86B2 for ; Thu, 5 Jan 2012 01:10:22 -0800 (PST) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q059AAvq021411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2012 04:10:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com> Date: Thu, 5 Jan 2012 04:10:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <49D24499-1C16-44C4-84C2-36F94F95235C@cs.columbia.edu> References: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Question about the order of hashing X-BeenThere: cfrg@irtf.org 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 09:10:24 -0000 On Jan 5, 2012, at 2:29 35AM, Yoav Nir wrote: > Hi. >=20 > When using keyed hash functions such as HMAC, GHash, and CBC-MAC, does = the order of the items being concatenated and hashed make any difference = to the security properties of the keyed hash? >=20 > IOW, does changing HMAC(k, a||b) into HMAC(k, b||a) change the = security properties. >=20 > My motivation for this question is that I would like to propose a = variant for IPsec where the sequence numbers are hashed after the = payload rather than before it. Different size packets take different = times to hash, so if we try to parallelize IPsec processing, arbitrarily = many packets may finish processing before a large single packet has = finished processing.=20 >=20 > IPsec emitters are required to emit the packets in order of the = sequence numbers, but since the sequence numbers (which are sent in the = clear) are hashed first, they have to be allocated before hashing = begins. By moving them to the end of the hash, I can allocate the = sequence number after having hashed most of the packet, and have nearly = constant-time processing after allocating the sequence number. >=20 > So is this scheme I'm proposing save, or would it introduce some major = vulnerability. >=20 What is your traffic model? If it's a single TCP stream, I think you'll = introduce performance problems at that layer if you're sending packets out of TCP = order. --Steve Bellovin, https://www.cs.columbia.edu/~smb From ynir@checkpoint.com Thu Jan 5 01:19:22 2012 Return-Path: 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 C5CCC21F8643 for ; Thu, 5 Jan 2012 01:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.802 X-Spam-Level: X-Spam-Status: No, score=-9.802 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751] 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 WNlm42iYTtKS for ; Thu, 5 Jan 2012 01:19:22 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B951221F860B for ; Thu, 5 Jan 2012 01:19:21 -0800 (PST) X-CheckPoint: {4F0568D5-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q059JC1c001079; Thu, 5 Jan 2012 11:19:12 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 5 Jan 2012 11:19:12 +0200 From: Yoav Nir To: Steven Bellovin Date: Thu, 5 Jan 2012 11:19:15 +0200 Thread-Topic: [Cfrg] Question about the order of hashing Thread-Index: AczLixWdboFGgb0mTuaGb+2KYIDM+A== Message-ID: <5C0E5BE9-FE11-46BD-9D91-08FBE0299F10@checkpoint.com> References: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com> <49D24499-1C16-44C4-84C2-36F94F95235C@cs.columbia.edu> In-Reply-To: <49D24499-1C16-44C4-84C2-36F94F95235C@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Question about the order of hashing X-BeenThere: cfrg@irtf.org 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 09:19:22 -0000 On Jan 5, 2012, at 11:10 AM, Steven Bellovin wrote: >=20 > On Jan 5, 2012, at 2:29 35AM, Yoav Nir wrote: >=20 >> Hi. >>=20 >> When using keyed hash functions such as HMAC, GHash, and CBC-MAC, does t= he order of the items being concatenated and hashed make any difference to = the security properties of the keyed hash? >>=20 >> IOW, does changing HMAC(k, a||b) into HMAC(k, b||a) change the security = properties. >>=20 >> My motivation for this question is that I would like to propose a varian= t for IPsec where the sequence numbers are hashed after the payload rather = than before it. Different size packets take different times to hash, so if = we try to parallelize IPsec processing, arbitrarily many packets may finish= processing before a large single packet has finished processing.=20 >>=20 >> IPsec emitters are required to emit the packets in order of the sequence= numbers, but since the sequence numbers (which are sent in the clear) are = hashed first, they have to be allocated before hashing begins. By moving th= em to the end of the hash, I can allocate the sequence number after having = hashed most of the packet, and have nearly constant-time processing after a= llocating the sequence number. >>=20 >> So is this scheme I'm proposing save, or would it introduce some major v= ulnerability. >>=20 > What is your traffic model? If it's a single TCP stream, I think you'll = introduce > performance problems at that layer if you're sending packets out of TCP o= rder. With a single TCP stream that is transferring a lot of data, all packets te= nd to be the same size - that of the MSS. My model is a lot of packets, som= e UDP, some TCP, belonging to multiple streams. My implementation would place every TCP stream on a single processor, but t= hat's because my implementation is also a firewall. This won't help cases w= here all (or most) traffic is a single TCP stream, but parallelizing can he= lp where you have multiple streams or packets under the same SA.= From pornin@bolet.org Thu Jan 5 05:09:02 2012 Return-Path: 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 DE1E921F8815 for ; Thu, 5 Jan 2012 05:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, SARE_OBFU_ALL=0.751] 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 f2iTB1G1knX6 for ; Thu, 5 Jan 2012 05:09:02 -0800 (PST) Received: from arges.bolet.org (arges.bolet.org [88.191.65.205]) by ietfa.amsl.com (Postfix) with ESMTP id D0F7C21F8679 for ; Thu, 5 Jan 2012 05:09:01 -0800 (PST) Received: from [10.0.1.101] (unknown [184.163.20.48]) by arges.bolet.org (Postfix) with ESMTPSA id 600B968C090; Thu, 5 Jan 2012 14:08:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Thomas Pornin In-Reply-To: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com> Date: Thu, 5 Jan 2012 08:08:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <84B1FEDA-5224-4E67-BF14-6B55A9769D56@bolet.org> References: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1251.1) Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Question about the order of hashing X-BeenThere: cfrg@irtf.org 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 13:09:03 -0000 On 2012-01-05, at 2:29 AM, Yoav Nir wrote: > IOW, does changing HMAC(k, a||b) into HMAC(k, b||a) change the = security properties. As long as the concatenation can be unambiguously undone, the security = properties are maintained. The trouble with concatenation is that, when done carelessly, it can = introduce ambiguities. For instance, if you take a protocol which = concatenates the user name and his password directly, then user 'steven' = with password 'cipher', and user 'steve' with password 'ncipher', end up = with the same concatenation result: 'stevencipher'. That can be a = problem for the security properties. In the case of users and passwords, = a common solution is to add a separator character, which is forbidden in = user names (hence 'steven:cipher' and 'steve:ncipher'). By swapping your 'a' and 'b', you might introduce ambiguities. For = instance, suppose that 'a' is a self-terminated structure (i.e. it = begins with a header which defines its length, so the end of 'a' and the = start of 'b' can be reliably located within 'a||b' by looking at the = first bytes), but 'b' is not. Then 'a||b' can always be split back into = a single, well-defined (a,b) pair. On the other hand, 'b||a' might not = be unambiguously split, so you could have distinct pairs 'b1||a1' and = 'b2||a2' which both match the 'b||a' string (and yield the same MAC). As long as you take care of that point, i.e. do not introduce the = possibility of a 'stevencipher', then you can choose whichever = conventional order you like, it will not impact the security of HMAC (of = course, sender and receiver must both agree on the same, single, = well-defined order). --Thomas Pornin From sfluhrer@cisco.com Thu Jan 5 08:27:13 2012 Return-Path: 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 7137721F84DE for ; Thu, 5 Jan 2012 08:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751] 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 xLON691JcsYp for ; Thu, 5 Jan 2012 08:27:12 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D4E4321F84D2 for ; Thu, 5 Jan 2012 08:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=3576; q=dns/txt; s=iport; t=1325780833; x=1326990433; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KJgsJmY8esSRpg/AB3Cr1l+UB7GcH8pS5IrWoyJChas=; b=YhhAkL8BjErNuqkYAxQ35IJi7nAdqlbgDxoBvLMGokS+hmhJBDygVFt6 YtmZG/ljcxZH7baIHwlSBPHaA+tO3rUFpoZXl26Bvb8GBtYedj0Uj4mI+ SAq5SrKV7Ia+2jGmRw2VYd78cJJyC8EJh8DKwpW5NJMKz4df07c3Q5xl8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAMjOBU+rRDoG/2dsb2JhbABCDoF3qniBBYFyAQEBBBIBHQo/DAQCAQgOAwQBAQEKBhcBBgFFCQgBAQQBCQkIGp87AZ4Tiy5jBIg5nktY X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; d="scan'208";a="23963411" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 05 Jan 2012 16:26:55 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q05GQtbu004318; Thu, 5 Jan 2012 16:26:55 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 08:26:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2012 08:26:53 -0800 Message-ID: In-Reply-To: <5C0E5BE9-FE11-46BD-9D91-08FBE0299F10@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] Question about the order of hashing Thread-Index: AczLixWdboFGgb0mTuaGb+2KYIDM+AAN8Krw References: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com><49D24499-1C16-44C4-84C2-36F94F95235C@cs.columbia.edu> <5C0E5BE9-FE11-46BD-9D91-08FBE0299F10@checkpoint.com> From: "Scott Fluhrer (sfluhrer)" To: "Yoav Nir" , "Steven Bellovin" X-OriginalArrivalTime: 05 Jan 2012 16:26:55.0260 (UTC) FILETIME=[D6AE1DC0:01CCCBC6] Cc: cfrg@irtf.org Subject: Re: [Cfrg] Question about the order of hashing X-BeenThere: cfrg@irtf.org 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:27:13 -0000 > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Yoav Nir > Sent: Thursday, January 05, 2012 4:19 AM > To: Steven Bellovin > Cc: cfrg@irtf.org > Subject: Re: [Cfrg] Question about the order of hashing >=20 >=20 > On Jan 5, 2012, at 11:10 AM, Steven Bellovin wrote: >=20 > > > > On Jan 5, 2012, at 2:29 35AM, Yoav Nir wrote: > > > >> Hi. > >> > >> When using keyed hash functions such as HMAC, GHash, and CBC-MAC, > does the order of the items being concatenated and hashed make any > difference to the security properties of the keyed hash? > >> > >> IOW, does changing HMAC(k, a||b) into HMAC(k, b||a) change the > security properties. > >> > >> My motivation for this question is that I would like to propose a > variant for IPsec where the sequence numbers are hashed after the > payload rather than before it. Different size packets take different > times to hash, so if we try to parallelize IPsec processing, > arbitrarily many packets may finish processing before a large single > packet has finished processing. > >> > >> IPsec emitters are required to emit the packets in order of the > sequence numbers, but since the sequence numbers (which are sent in the > clear) are hashed first, they have to be allocated before hashing > begins. By moving them to the end of the hash, I can allocate the > sequence number after having hashed most of the packet, and have nearly > constant-time processing after allocating the sequence number. > >> > >> So is this scheme I'm proposing save, or would it introduce some > major vulnerability. > >> > > What is your traffic model? If it's a single TCP stream, I think > you'll introduce > > performance problems at that layer if you're sending packets out of > TCP order. >=20 > With a single TCP stream that is transferring a lot of data, all > packets tend to be the same size - that of the MSS. My model is a lot > of packets, some UDP, some TCP, belonging to multiple streams. >=20 > My implementation would place every TCP stream on a single processor, > but that's because my implementation is also a firewall. This won't > help cases where all (or most) traffic is a single TCP stream, but > parallelizing can help where you have multiple streams or packets under > the same SA. Yoav, might I point out that with ESP-GCM (and GMAC), you can actually compute things out of order. That is, you can compute the entire encrypted data and ICV field assuming a sequence number of 0, and afterwards figure out how to adjust the ICV for the actual sequence number. This adjustment does involve computing H**n (where H is an internal GCM value derived from the key, and n is the packet length in 16 byte increments, and the multiplications are GF(2**128) field multiplications). Computing this is logarithmic time, not constant (unless you precompute all the possible H**n values; there's about 100 of them for standard MTU sizes), but is certainly closer to constant what you're originally looking at with the standard HMAC authentication. So, what's the benefit of putting up with this complexity? Well, you can basically get what you want with standard (RFC-compliant) protocols. So, you can implement what you want without asking anyone else to do anything (well, other than implement the GCM RFC, I suppose). I share Steve's concerns about sending packets out of order (my personal worry would be video), but you can implement it yourself, and see in practice if it works well. From prvs=2351dd59fc=uri@ll.mit.edu Thu Jan 5 08:28:40 2012 Return-Path: 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 9DD6E21F8767; Thu, 5 Jan 2012 08:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.45 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2cdrCpCCoDt; Thu, 5 Jan 2012 08:28:39 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id C306421F86D1; Thu, 5 Jan 2012 08:28:38 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (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: <4F054D78.1080008@gmail.com> 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_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: "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:28:40 -0000 --B_3408607697_86656470 Content-type: multipart/alternative; boundary="B_3408607692_86683219" --B_3408607692_86683219 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Steve, How would you compare your proposed localizing-by-URI approach with localizing-by-host (or by "SNMP engine") approach proposed in RFC 3414 http://datatracker.ietf.org/doc/rfc3414/ ? 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 =AD based on some rules that are out of scope for this email =AD 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 choos= e 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 =AD 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=8A Oh, and since this proposal seems to be addressing the same problem in a somewhat similar way =AD perhaps it would make sense to include a reference t= o RFC 3414 (section 2.6 Key Localization Algorithm)? :) Tnx! --=20 Regards, Uri uri@ll.mit.edu --B_3408607692_86683219 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Steve,

How would you compare you= r proposed localizing-by-URI approach with localizing-by-host (or by "SNMP e= ngine") approach proposed in RFC 3414 http://datatracker.ietf.org/doc/rfc3414/ ?=  

Some questions to consider. 

You propose "localization" by service - i.e., by hos= tname + port. How many passwords per user would a server store? How critical= is your requirement that "no two [effective] `passwords for different servi= ces [on the same host] should be the same for the same user"?  A benefi= t of not localizing based on th= e 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 "domin= ant" name and localize users' passwords to it, thus storing one password per= user on this server; avoiding the potential ambiguity that Joe Touch pointe= d 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 abo= ut non-invertibility/one-way-ness, not collision resistance)? Or did you cho= ose 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 – c= ouldn'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 pr= oblem in a somewhat similar way – perhaps it would make sense to inclu= de a reference to RFC 3414 (section 2.6 Key Localization Algorithm)? :)

Tnx!
-- 
Regards,
Uri      uri@= ll.mit.edu
--B_3408607692_86683219-- --B_3408607697_86656470 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUAAYJKoZIhvcNAQcCoIIT8TCCE+0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EeMwggTLMIIDs6ADAgECAgocykucAAAAABz0MA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTIwHhcNMTEwNzE0MTYzMTE0WhcNMTIwNzEzMTYzMTE0WjBhMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBANv2QbmKZtfoxOVYMXLUdwjqMm8jsN4GK0n18a6R9uyRcEp4 NLdVAFZ6JeImmxZWNEWXmDyCC+ykliyIJwIUER3zT2LJyIbpELsIv1tkIhWcuLfAYZMsH+kT cKk1LpDm0tE4Z5cCrqTJvS8lUSrglJKOyy9mSG4lySkqqIMg5eRw/oZ/RstqIHy+EJgHgJDY pxleRZbl7s9w1VYKbp8kbHarX9zCzOfp6HW/xtovwP07Z7lUBOWlw7AXXehwC1flwWbG9Eq8 5fDeIKIPj+xS9TmUYguPfJBdDOZYOlUfoRspJ0nwujjeoP9rX3NKyq6cmbOEuP/yTEkDwBrS lEUpNCkCAwEAAaOCAZMwggGPMB0GA1UdDgQWBBREe8exSTToHSIt2geg++QNUdKYHDAOBgNV HQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcB AQRWMFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAj BggrBgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIB ZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQB17CA8es2u0zGsL5JSMclcdzRDtQHW7cH4HgCJ8neeWltNXQ6x/OhYPFCWAz8x84mQ AnbIycHLKDuuBn17b35Ct3zTs6jbJj0T0m8Elnj6ONk9z/uwmB+fWh43rMjlUyWNVmNOm7sG X2EmZHm7EqHyMzNW3f8bqw+pw9sC5BHQvkPgmBNFxI18YNmpeQYg48ZRP0cRHKaNPTm7AECj up9wxnuW8CnDKW6bzaNErKEQt4HOGvcbHqlLkRwZK1CXEXesI9vCB2Nrytdkbovr2BkvzmUr 5QpGJ+YsLHl2WrM0+yHHW3SKRPJyo3cJylni86AbehQ6k0dZha6exy/UBwmLMIIEtzCCA5+g AwIBAgIBFDANBgkqhkiG9w0BAQsFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExp bmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENB MB4XDTA5MTIxNDEyMDAwMFoXDTE1MTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKcEyyNhSIfsN6AzBwVh Zkzo6SdjNGAQ7mA2A8T0kmdCB8MH6jWjVVMwFZwlg9cgjgLKEuEO9KN8K9M8jgeZEMoinlRf k3YELPC7sEkkzBQkcVpLhEwALue9iHowgSLGmXZpYKmRhfvhvYJ4MNCuIaWpcK/GaDZCE+U2 aTg42kv/zQrH3AoqFX81OF7niwXNnanP1hQRfkMTRrnaEW8DX0TMaG/t9Ry5xSMrLTNc9DvQ tjA5ZcuWnECiUpyDBFWxLr9yx7xgf1/LwgCxcoBeKSBBoWzkQmKAsgMo9Mq1Fp/nnIqw5FKm gOs7Vy+6e0Dk+cgf+oAV8AK8ZFMQrVE0uH0CAwEAAaOCAZUwggGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0OBBYEFI5KfYmhYxccgYg0VzcmRV4Zin4kMB8GA1UdIwQYMBaAFGeqes/0 Cqa5crWKoNKd8hDDQ+0pMA4GA1UdDwEB/wQEAwIBhjBhBggrBgEFBQcBAQRVMFMwLQYIKwYB BQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAiBggrBgEFBQcwAYYW aHR0cDovL29jc3AubGwubWl0LmVkdTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZIhvcSAgEDAQYwDQYL KoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYLKoZIhvcSAgED AQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8wDQYLKoZI hvcSAgEDARAwDQYJKoZIhvcNAQELBQADggEBAIh3BqHQ/XH8C6DCL+eEGroOzxBcCqTNItms v4MANaOTodgU2jrjHcGjXlzqhpb8ZxOlkAK3dK09rc6+yACcoK2TzVtDRZXYxov/SqZRjI3d ufU2JatAPxosCyy/1otjl1TKUY47Wvft31vdf5i0XK2DQVEJ+XlqtgBiFTVIMIfBJwPajrsi z+pgFEYwhhwJxvs8flSi0FLCE77VYLEioP5hxG6zIPeQRxzh1bogbfphWHHtoiTDkBSZ4Ufv GXQTVf7QjhD5yYw10yICtjHmtgbfgBkH5/vvR92NY9RSlNPzZqmGKIia61bJCmagRYGyexfe dVNF0cJWL4J/cLHhgNYwggODMIICa6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV BAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kx FjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMDgwOTIzMTIwMDAwWhcNMjkxMjMxMjM1OTU5 WjBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxU4pF1iyJrL5rYq/XBAKg93kCTATG7Bw0NGFpEJ1A3Xsr6UIIq9/1VJB OgCwDqrVsAK1lRwy/lkrHzPkobiMr1wzjQ28SR/9sg5kAcmrMqBYbc302qtwCGKZxdNdhAh2 nUOCO10AMpUsCNdpikPY9ukT8lsA+eorM4Q1rc/L0J6AHRptOU7IuDBdZj+tdNb7gv+GKknr 6wj9m2sVGawoaG7AAqhsWvQUM/q4h/H5FpYlwnVAEh2AzhqiG9bwl6uJJIzJ/8uUWldNkVwz 1I5fR/vCaxiLXIW4oUydBuRKTG+ekEoxHGuD73yx5JtsSciS8HQL2oEM8tv+VAC+albqgwID AQABo2AwXjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRnqnrP9AqmuXK1iqDSnfIQw0Pt KTAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTALBgNVHQ8EBAMCAYYwDQYJKoZI hvcNAQEFBQADggEBAD4bbQVg0Hh42EpYX4/JPkNS3OUAEWR/YgzZUY1QGi9rQZ4pfcjU1/Ta oNT8Y7Yf0RO+e9NiG9+BDhQH/kQiZOQo9rv9NUb8xDtKCYCad7zEQtVsYsWuvK2XLw/Ji1m2 eBvoOB4RS/5LAWfNws7W+DWt2ayzeTCyrLSrx7ZVgBjzNOm0TPIkbfppdwgxuo7FZL8ts+M2 492Al87d3VasevUS1pprRBEupChmPTt1hjtajkQOpT4BQAzP1lVEYrWzlv+O/lbP9iujKpYW cfYqQ3FGf37YCvuDeues4xm+nqmyraNsNeI8Gh3XDIwqfzHnLhy4Y80VyqN/Jj8df3SK9AAw ggTOMIIDtqADAgECAgpbJUqmAAAAAA8TMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTIwHhcNMTEwMzI0MTIyNjExWhcNMTIwMzIzMTIyNjExWjBhMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVv cGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJgc1a1sochMa7t5yY+uE41Zbsv3nHOSCIrCSh4rMUGd7uQLJev7 yg12DVeG5aD0Mh4CfvWY4aPqpLbKmgvtQwRGK7Q4AI8LkmXsrHTPePj8q1xl9D9iLOLJB7NI 6tIWBLoRUpdnpTXpVY48vYh3EawGOoyATcjGIgFDxdQRduCdOfgnhwV5VKLidwTa2u3c1jYr FiCnGwiWRzKFSoNORzEp+Ya9+3IxAoXv1njOCRSsjs0NW1Dk0NRbcQ8GvomFNv0l9wVbKZFP SOxfIdaImNOR6plD0hZXyS1R3AM2rmC+8sHhTe8SjTCH4wTU5GDl3ggMma9Hs9TaH5tQt8AT nj0CAwEAAaOCAZYwggGSMB0GA1UdDgQWBBQQR4g7yYztZ0FyMkiRO+qlMFa91jAOBgNVHQ8B Af8EBAMCBSAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcBAQRW MFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAjBggr BgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIB BDAlBgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQBTX15euArO0iAXeKleS4RByMTW91D/0ihJOIbxiqNkYtyBau2nj11c4njjB58a0pGk YEfxa+LK/bWrOIw1NuZ1f00GcorNcfxixxH4JpiMdC55PYH5aN0r3s3HFTd/Irbdr0J4XA2s K7MyhyiOaOY1rTV7idWdyL8KJW+Y38sOVHLwe0JHpF/TUbF1wmtyam1kj5VJvrBEIjbuEKjl +bPzgCx6ZaTajuo16Op5xFK3ABdq+zKXgXmFGR2NT0nNQ7OnqCpGnVyoOvahFZk1Chr/zUvb V6rINQxtvgnCUGLbaKROfVlmes/vtbLALimVsPRVseBE4I/bpyzfI9F8NwRXMYIB5TCCAeEC AQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEM MAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yAgocykucAAAAABz0MAkGBSsOAwIa BQCgXTAjBgkqhkiG9w0BCQQxFgQUHONf+kuCj+TP05cKSB2t5ak0DVgwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMTA1MTYyODEyWjANBgkqhkiG9w0B AQEFAASCAQCSbUAvTBgUhQGoUNxa02JZ+mQdNxw1yooAbDjB3dZwKBYrGu5sPti4YBZZq9fY mYgFX/UE8mD6PG86kBJZSIyG0s0v+f4q9wCJXr5W0yLgcmkeHEnYJ644knqKW1qlFJfui4j5 RLYDNl4YwYtAgtFdkAvlZeFutL5ihCRIBxWlpM6e6uPRIjkItwxRl1VckE1rcm0NL/8Eaneb r/bq0X4viSGN7xUayU/iNLyO//unITBN/SXLphvx4s1Jiglj9mORl8SSKljfA+Rva2kZAO94 lLsu5Cv02W3aESqpCXf/yEpae/jpxHZy5kbiL2QBwGGfwmZDW5RJ4e+bOUAQiQPv --B_3408607697_86656470-- From mcgrew@cisco.com Thu Jan 5 10:22:44 2012 Return-Path: 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 EAF9C21F86E5 for ; Thu, 5 Jan 2012 10:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.248 X-Spam-Level: X-Spam-Status: No, score=-105.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, 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 y-f7obbGuHP4 for ; Thu, 5 Jan 2012 10:22:39 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1F021F85A0 for ; Thu, 5 Jan 2012 10:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=4283; q=dns/txt; s=iport; t=1325787754; x=1326997354; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=MkTpIvkGCoYXZRN4I7lZ2DpQQHjJA0gwqvPwukS7jVw=; b=kvxurmMGfIrxe65vHlMvLkpLNCw9u4FoxDR1JvaudcKfCn6inUkZdvGW CIrRxPJFkHGe52ol3xd7JehIAlzdcJ4J+xTgVnHNAXc54jo6vV+NGn4PL 3eZHDiyaI6qiut0oZRoESIiJ/DFYVmrJqDodJVFpQ1y2xklpotZDLFoJ8 8=; X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; d="scan'208";a="22281168" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 05 Jan 2012 18:22:34 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q05IMXMr019871; Thu, 5 Jan 2012 18:22:33 GMT Message-Id: From: David McGrew To: "Scott Fluhrer (sfluhrer)" , Yoav Nir In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Jan 2012 10:22:32 -0800 References: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com><49D24499-1C16-44C4-84C2-36F94F95235C@cs.columbia.edu> <5C0E5BE9-FE11-46BD-9D91-08FBE0299F10@checkpoint.com> X-Mailer: Apple Mail (2.936) Cc: cfrg@irtf.org Subject: Re: [Cfrg] Question about the order of hashing X-BeenThere: cfrg@irtf.org 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 18:22:44 -0000 Thanks Scott for pointing out that the use of the "incremental" property can be used here. Yoav, there are more details on that property in from IEEE SIS 2005, if you are interested. As far as I know, there are no intellectual property considerations that are specific to incremental MACs or the use of GCM/GMAC in that manner. David On Jan 5, 2012, at 8:26 AM, Scott Fluhrer (sfluhrer) wrote: > > >> -----Original Message----- >> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf > Of >> Yoav Nir >> Sent: Thursday, January 05, 2012 4:19 AM >> To: Steven Bellovin >> Cc: cfrg@irtf.org >> Subject: Re: [Cfrg] Question about the order of hashing >> >> >> On Jan 5, 2012, at 11:10 AM, Steven Bellovin wrote: >> >>> >>> On Jan 5, 2012, at 2:29 35AM, Yoav Nir wrote: >>> >>>> Hi. >>>> >>>> When using keyed hash functions such as HMAC, GHash, and CBC-MAC, >> does the order of the items being concatenated and hashed make any >> difference to the security properties of the keyed hash? >>>> >>>> IOW, does changing HMAC(k, a||b) into HMAC(k, b||a) change the >> security properties. >>>> >>>> My motivation for this question is that I would like to propose a >> variant for IPsec where the sequence numbers are hashed after the >> payload rather than before it. Different size packets take different >> times to hash, so if we try to parallelize IPsec processing, >> arbitrarily many packets may finish processing before a large single >> packet has finished processing. >>>> >>>> IPsec emitters are required to emit the packets in order of the >> sequence numbers, but since the sequence numbers (which are sent in > the >> clear) are hashed first, they have to be allocated before hashing >> begins. By moving them to the end of the hash, I can allocate the >> sequence number after having hashed most of the packet, and have > nearly >> constant-time processing after allocating the sequence number. >>>> >>>> So is this scheme I'm proposing save, or would it introduce some >> major vulnerability. >>>> >>> What is your traffic model? If it's a single TCP stream, I think >> you'll introduce >>> performance problems at that layer if you're sending packets out of >> TCP order. >> >> With a single TCP stream that is transferring a lot of data, all >> packets tend to be the same size - that of the MSS. My model is a lot >> of packets, some UDP, some TCP, belonging to multiple streams. >> >> My implementation would place every TCP stream on a single processor, >> but that's because my implementation is also a firewall. This won't >> help cases where all (or most) traffic is a single TCP stream, but >> parallelizing can help where you have multiple streams or packets > under >> the same SA. > > Yoav, might I point out that with ESP-GCM (and GMAC), you can actually > compute things out of order. That is, you can compute the entire > encrypted data and ICV field assuming a sequence number of 0, and > afterwards figure out how to adjust the ICV for the actual sequence > number. > > This adjustment does involve computing H**n (where H is an internal > GCM > value derived from the key, and n is the packet length in 16 byte > increments, and the multiplications are GF(2**128) field > multiplications). Computing this is logarithmic time, not constant > (unless you precompute all the possible H**n values; there's about 100 > of them for standard MTU sizes), but is certainly closer to constant > what you're originally looking at with the standard HMAC > authentication. > > So, what's the benefit of putting up with this complexity? Well, you > can basically get what you want with standard (RFC-compliant) > protocols. > So, you can implement what you want without asking anyone else to do > anything (well, other than implement the GCM RFC, I suppose). I share > Steve's concerns about sending packets out of order (my personal worry > would be video), but you can implement it yourself, and see in > practice > if it works well. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From hugokraw@gmail.com Thu Jan 5 13:11:51 2012 Return-Path: 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 9162121F88B1 for ; Thu, 5 Jan 2012 13:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] 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 mOpCrDfhu19s for ; Thu, 5 Jan 2012 13:11:50 -0800 (PST) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id A127321F88A7 for ; Thu, 5 Jan 2012 13:11:50 -0800 (PST) Received: by obbwd18 with SMTP id wd18so1559367obb.13 for ; Thu, 05 Jan 2012 13:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=h05Yjy796ZQqo8iQqd2U73VBi/fwkcxv2lPaaN4d0og=; b=rOCGFWRG41eygaxnqA+r52DwTl9VsN5GIWtlZV+YcSfHRcWv9JshXGlR5S98eoZ51n C/KrlgDtdwfUKN7A0Dv40iT4LaQSZUwSuRqk9pAG2JYIeYtBMUaM9w3yfy8AvduZjPxp 6AILEk+9Y5DU9SBr4Xhjr0146XNWdckP7QRdk= Received: by 10.182.159.70 with SMTP id xa6mr2839954obb.1.1325797910117; Thu, 05 Jan 2012 13:11:50 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.182.121.103 with HTTP; Thu, 5 Jan 2012 13:11:29 -0800 (PST) In-Reply-To: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com> References: <5E6BDD30-3EB8-4FBA-826E-4A44DED36283@checkpoint.com> From: Hugo Krawczyk Date: Thu, 5 Jan 2012 16:11:29 -0500 X-Google-Sender-Auth: 3uPWevukPyt8n9Ll233KqgX_YZ4 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=14dae939977179fc7a04b5ce611e Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Question about the order of hashing X-BeenThere: cfrg@irtf.org 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 21:11:51 -0000 --14dae939977179fc7a04b5ce611e Content-Type: text/plain; charset=UTF-8 The security properties of HMAC do not change by the order of the data items. However, the change of order may affect the security of a cryptographic protocol that uses HMAC. Particularly, ambiguous parsing as in Thomas example can break a protocol. Or think of a DH key exchange that is authenticated with a preshared key K by transmitting HMAC(K, g^a||g^b) from A to B and HMAC(K, g^b||g^a) from B to A (and assume the parties check that g^a \noteq g^b to prevent reflection attacks). Now, if you change the order of arguments in the B to A flow, you create a reflection attack opportunity that did not exist in the original protocol. I would assume that if the only thing that you change is the position of the sequence number and in the new ordering the position and length of this number is uniquely determined (e.g., last 4 bytes of the message) then you should be ok, but it is just an assumption. You should look more carefully at your specific protocol/usage. Hugo On Thu, Jan 5, 2012 at 2:29 AM, Yoav Nir wrote: > Hi. > > When using keyed hash functions such as HMAC, GHash, and CBC-MAC, does the > order of the items being concatenated and hashed make any difference to the > security properties of the keyed hash? > > IOW, does changing HMAC(k, a||b) into HMAC(k, b||a) change the security > properties. > > My motivation for this question is that I would like to propose a variant > for IPsec where the sequence numbers are hashed after the payload rather > than before it. Different size packets take different times to hash, so if > we try to parallelize IPsec processing, arbitrarily many packets may finish > processing before a large single packet has finished processing. > > IPsec emitters are required to emit the packets in order of the sequence > numbers, but since the sequence numbers (which are sent in the clear) are > hashed first, they have to be allocated before hashing begins. By moving > them to the end of the hash, I can allocate the sequence number after > having hashed most of the packet, and have nearly constant-time processing > after allocating the sequence number. > > So is this scheme I'm proposing save, or would it introduce some major > vulnerability. > > Thanks > > Yoav > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --14dae939977179fc7a04b5ce611e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The security properties of HMAC do = not change by the order of the data items. However, the change of order may= affect the security of a cryptographic protocol that uses HMAC. Particular= ly, ambiguous parsing as in Thomas example can break a protocol. Or think o= f a DH key exchange that is authenticated with a preshared key K by transmi= tting HMAC(K, g^a||g^b) from A to B and HMAC(K, g^b||g^a) from B to A (and assume = the parties check that g^a \noteq g^b to prevent reflection attacks). Now, = if you change the order of arguments in the B to A flow, you create a refle= ction attack opportunity that did not exist in the original protocol.

I would assume that if the only thing that you change is the position o= f the sequence number and in the new ordering the position and length of th= is number is uniquely determined (e.g., last 4 bytes of the message) then y= ou should be ok, but it is just an assumption. You should look more careful= ly at your specific protocol/usage.

Hugo


<= div class=3D"gmail_quote">On Thu, Jan 5, 2012 at 2:29 AM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi.

When using keyed hash functions such as HMAC, GHash, and CBC-MAC, does the = order of the items being concatenated and hashed make any difference to the= security properties of the keyed hash?

IOW, does changing HMAC(k, a||b) into HMAC(k, b||a) change the security pro= perties.

My motivation for this question is that I would like to propose a variant f= or IPsec where the sequence numbers are hashed after the payload rather tha= n before it. Different size packets take different times to hash, so if we = try to parallelize IPsec processing, arbitrarily many packets may finish pr= ocessing before a large single packet has finished processing.

IPsec emitters are required to emit the packets in order of the sequence nu= mbers, but since the sequence numbers (which are sent in the clear) are has= hed first, they have to be allocated before hashing begins. By moving them = to the end of the hash, I can allocate the sequence number after having has= hed most of the packet, and have nearly constant-time processing after allo= cating the sequence number.

So is this scheme I'm proposing save, or would it introduce some major = vulnerability.

Thanks

Yoav

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg

--14dae939977179fc7a04b5ce611e-- From dharkins@lounge.org Sat Jan 7 01:03:29 2012 Return-Path: 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 3D3BB21F8572 for ; Sat, 7 Jan 2012 01:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.147 X-Spam-Level: X-Spam-Status: No, score=-5.147 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] 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 wz8iv5FfC76l for ; Sat, 7 Jan 2012 01:03:29 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 12BA321F8570 for ; Sat, 7 Jan 2012 01:03:26 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 671131022404A; Sat, 7 Jan 2012 01:03:25 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 7 Jan 2012 01:03:25 -0800 (PST) Message-ID: <1c680c52d4a354cdeda0a39e9cc47d32.squirrel@www.trepanning.net> In-Reply-To: <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> Date: Sat, 7 Jan 2012 01:03:25 -0800 (PST) From: "Dan Harkins" To: "Steven Bellovin" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 09:03:29 -0000 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). 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 > From mcgrew@cisco.com Tue Jan 10 06:20:40 2012 Return-Path: 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 A029721F85EA for ; Tue, 10 Jan 2012 06:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 sPOc2cJ8aTMb for ; Tue, 10 Jan 2012 06:20:40 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 70B7A21F85E4 for ; Tue, 10 Jan 2012 06:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1339; q=dns/txt; s=iport; t=1326205239; x=1327414839; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=pB7zz+jHOxhS5vDOhZwYyVjBwggLX3QWIRbFVE/D3do=; b=HFypTkJ3UxQqp+MZXbIZ/mD/KeiRGduNomohLiE0ITlUiGzN9OX0lU0N ukHYQtcBUYCPVwe632iYxwHl1ZbGWvcyQ7yJXhJpKRumhzOgYibCQtqYo +VRNYz11Pdr8+iwPlMn8gXE92HiYdD2rBIJoPLvCHzRHDzJlImq+aREIu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAARIDE9Io8UY/2dsb2JhbABDrWCBcgEBAQMBAQEBDwElAjEDCwULC0YnMBkih1gImEoBnjKId4I5YwSIOoxShVGNCg X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; d="scan'208";a="3122600" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 10 Jan 2012 14:20:33 +0000 Received: from [192.168.5.97] ([10.86.252.142]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0AEKTZK027778; Tue, 10 Jan 2012 14:20:30 GMT Message-Id: <8AD2FCD4-39ED-4DB5-8E1E-1F4B992D4C09@cisco.com> From: David McGrew To: cfrg@irtf.org In-Reply-To: <35510875-4467-40D9-BABE-FD35C298F115@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Jan 2012 06:20:28 -0800 References: <35510875-4467-40D9-BABE-FD35C298F115@gmail.com> X-Mailer: Apple Mail (2.936) Cc: Jouni Korhonen , jouni korhonen , "Mauricio \(HP Networking\) Sanchez" , "Dan \(Dan\) Romascanu" Subject: Re: [Cfrg] [secdir] Requesting review of draft-ietf-radext-radsec-09 X-BeenThere: cfrg@irtf.org 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: Tue, 10 Jan 2012 14:20:40 -0000 Forwarding the request for review to the IRTF Crypto Forum RG. I personally feel that the use of TLS to protect RADIUS is a good way address the security/deployability gaps that are present when RADIUS is used in scenarios where cryptographic security is needed. However, I have not reviewed the draft in detail. David On Jan 9, 2012, at 4:27 AM, jouni korhonen wrote: > Dear Security Directorate, > > We (RADEXT chairs) solicit for security expert review for "TLS > encryption for RADIUS" I-D. The I-D can be found at: > http://tools.ietf.org/html/draft-ietf-radext-radsec-09 > > Do not mind about the expired state. There will shortly be -10 > revision just to keep the I-D alive and fixing one outdated > reference [I-D.winter-dynamic-discovery]. We are moving the document > to IESG process shortly thus the review comments should be directed > to document authors, AD and RADEXT chairs. > > Best regards, > Jouni - RADEXT co-chair > > > > _______________________________________________ > secdir mailing list > secdir@mit.edu > https://mailman.mit.edu/mailman/listinfo/secdir > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From turners@ieca.com Thu Jan 19 05:54:07 2012 Return-Path: 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 ED4BF21F8487 for ; Thu, 19 Jan 2012 05:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 zCoP8e4hygKX for ; Thu, 19 Jan 2012 05:54:07 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.55.14]) by ietfa.amsl.com (Postfix) with ESMTP id 588C121F8476 for ; Thu, 19 Jan 2012 05:54:07 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 88BFD40B8E1B4; Thu, 19 Jan 2012 07:54:04 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 7E4D640B8E179 for ; Thu, 19 Jan 2012 07:54:04 -0600 (CST) Received: from [96.231.123.58] (port=38565 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RnsRH-0004ZR-Kc for cfrg@irtf.org; Thu, 19 Jan 2012 07:54:04 -0600 Message-ID: <4F18207C.7050202@ieca.com> Date: Thu, 19 Jan 2012 08:54:04 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: cfrg@irtf.org References: <4F1816B7.9070101@cs.tcd.ie> In-Reply-To: <4F1816B7.9070101@cs.tcd.ie> X-Forwarded-Message-Id: <4F1816B7.9070101@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-123-58.washdc.east.verizon.net (thunderfish.local) [96.231.123.58]:38565 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [Cfrg] FW: Smart Object Security Workshop Announcement X-BeenThere: cfrg@irtf.org 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, 19 Jan 2012 13:54:08 -0000 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > Sent: 19 January 2012 10:22 > To: IETF-Discussion list > Subject: Smart Object Security Workshop Announcement > > Hi all, > > we would like to make you aware of a workshop on Smart Object Security on the > 23rd March 2012 in Paris (attached to the IETF meeting). > > We are seeking input from participants to share their thoughts about the ability > to utilize existing and widely deployed security mechanisms for smart objects. > > In particular, we are interested to hear about: > . What techniques for issuing credentials have been deployed? > . What extensions are useful to make existing security protocols more > suitable for smart objects? > . What type of credentials are frequently used? > . What experience has been gained when implementing and deploying > application layer, transport layer, network layer, and link layer security > mechanisms (or a mixture of all of them)? > . How can "clever" implementations make security protocols a better fit > for constrained devices? > . Are there lessons we can learn from existing deployments? > > More workshop details can be found on the webpage of our host: > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ > > If you plan to participate at the workshop please drop us a message (with a short > description of what you are planning to contribute) and we can give you an early > notice regarding your participation. > > Greetings > The Workshop Organizers > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf