[Cfrg] Status of DragonFly
"Igoe, Kevin M." <kmigoe@nsa.gov> Thu, 13 December 2012 18:42 UTC
Return-Path: <kmigoe@nsa.gov>
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 BCCD421F88D8 for <cfrg@ietfa.amsl.com>; Thu, 13 Dec 2012 10:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OWTW7HL50O1 for <cfrg@ietfa.amsl.com>; Thu, 13 Dec 2012 10:42:57 -0800 (PST)
Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2421F88CE for <cfrg@irtf.org>; Thu, 13 Dec 2012 10:42:56 -0800 (PST)
X-TM-IMSS-Message-ID: <18cfab8c00039ea3@nsa.gov>
Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 18cfab8c00039ea3 ; Thu, 13 Dec 2012 13:42:56 -0500
Received: from MSMR-GH1-UEA02.corp.nsa.gov (10.215.227.180) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 13 Dec 2012 13:42:55 -0500
Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA02.corp.nsa.gov ([10.215.227.180]) with mapi id 14.01.0289.001; Thu, 13 Dec 2012 13:42:55 -0500
From: "Igoe, Kevin M." <kmigoe@nsa.gov>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: Status of DragonFly
Thread-Index: Ac3YlStNhI1Pb7rLTAC7Nu690xzU7Q==
Date: Thu, 13 Dec 2012 18:42:54 +0000
Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA49672A1B@MSMR-GH1-UEA03.corp.nsa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.215.254.27]
Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CA49672A1BMSMRGH1UEA03cor_"
MIME-Version: 1.0
Cc: Dan Harkins <dharkins@arubanetworks.com>
Subject: [Cfrg] Status of DragonFly
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2012 18:42:59 -0000
I'd like the reading list's input on DragonFly (hereafter called DF), Dan Harkins' Password Authenticated Key Exchange design (draft-irtf-cfrg-dragonfly-00). I'd like to point out that draft-harkins-tls-pwd-03 is a proposal to use DF in TLS that differs slightly from the CFRG draft. Here is where I believe we stand: 1) Confidentiality: The proof that the confidentiality of the key generated by the DF protocol is reducible to the standard Diffie-Hellmann problem is quite straight forward, so the resulting shared secret value is at least as secure as with standard DH/ECDH. 2) Authentication: Obviously the system can be no more secure than the password being used. I believe the most viable attack is to guess a password, use this password to initiate the DF protocol with the endpoint being attacked, and see if it works. Monitoring the system logs should easily detect such an attack. 3) Timing: I'm particularly concerned about the method used to generate the PE (password dependent base point) in the ECDH case. Inside a while loop, several parameters, including the identities of the two endpoints, the shared password, and a counter are passed to a KDF to produce an n-bit output, where the curve is mod an n-bit prime p. The resulting n-bit value X is checked to see if 0 <= X < p and X^3+a*X+b is a quadratic residue mod p (an event of probability ½). If both these tests are passed, the while loop is exited and X is used as the x-coordinate of our PE. The problem I see with (3) is that the number of times through the loop gives an opponent a check on any putative value for the password. E.g. if their current guess for the password takes many passes through the while loop to generate the PE, but they observe that the DF response time is inconsistent with that, they have eliminated that guess for the password. When DF is applied to TLS in as described in draft-harkins-tls-pwd-03, two nonces are used as inputs to the KDF, which has two consequences: a. the PE MUST be computed online b. each DF exchange gives an independent timing check on the password. The opponent can passively sit back, monitoring the timing of DF exchanges on various links until they stumble across one where the timings match up with the timings associated with one of the passwords they are testing. They've now are able to bypass the authentication provided by DF. A possible fix is to use the KDF to generate a random X, 1<X<q, where q is the size of the cryptographic subgroup of the curve, and take PE = X*G, where G is the generator of the cryptographic subgroup. For most cryptographic curves, q is very, very close to 2^n, so it is VERY unlikely that more than 1 call to the KDF will be needed. Another fix would be to require PE generation be done offline, which would eliminate any possibility of using nonces in the DF protocol. One could, however, mix the nonces in after the completion to the DF based Diffie-Hellmann exchange. ----------------+-------------------------------------------------- Kevin M. Igoe | "We can't solve problems by using the same kind kmigoe@nsa.gov<mailto:kmigoe@nsa.gov> | of thinking we used when we created them." | - Albert Einstein - ----------------+--------------------------------------------------
- [Cfrg] Status of DragonFly Igoe, Kevin M.
- Re: [Cfrg] Status of DragonFly Rene Struik
- Re: [Cfrg] Status of DragonFly Scott Fluhrer (sfluhrer)
- Re: [Cfrg] Status of DragonFly Igoe, Kevin M.
- Re: [Cfrg] Status of DragonFly Igoe, Kevin M.
- Re: [Cfrg] Status of DragonFly Dan Harkins
- Re: [Cfrg] Status of DragonFly Igoe, Kevin M.
- Re: [Cfrg] Status of DragonFly Scott Fluhrer (sfluhrer)