Re: [Cfrg] PKEX Update and Summary

Dan Harkins <dharkins@lounge.org> Mon, 19 September 2016 23:07 UTC

Return-Path: <dharkins@lounge.org>
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 D44D312B007 for <cfrg@ietfa.amsl.com>; Mon, 19 Sep 2016 16:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCDqGmDm3xdB for <cfrg@ietfa.amsl.com>; Mon, 19 Sep 2016 16:07:07 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8389612B010 for <cfrg@irtf.org>; Mon, 19 Sep 2016 16:07:07 -0700 (PDT)
Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 3EFD210224230; Mon, 19 Sep 2016 16:07:07 -0700 (PDT)
To: Paul Lambert <paul@marvell.com>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <D405A14A.A0FA0%paul@marvell.com>
From: Dan Harkins <dharkins@lounge.org>
Message-ID: <0a42eb53-aeb3-2c60-3994-0fa5332f7d5b@lounge.org>
Date: Mon, 19 Sep 2016 16:07:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <D405A14A.A0FA0%paul@marvell.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/4yuPnHKmQ787bC5l4RUyKEHXFlA>
Subject: Re: [Cfrg] PKEX Update and Summary
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2016 23:07:12 -0000

   Hi Paul,

On 9/19/16 2:52 PM, Paul Lambert wrote:
> I¹ve posted a summary of the ³PKEX² protocol and it¹s background:
>
> 	https://mentor.ieee.org/802.11/dcn/16/11-16-1142-02-00ai-cryptographic-rev
> iew-and-pkex.ppt
>
> The presentation provides an overview of the protocol and details of the
> O(sqrt(N)) off-line attack and the MiTM attack.
>
> Any productive comments and would be greatly appreciated. Please do let me
> know me know if you identify significant errors or omissions.

   I do not think you and Andy represent "a 'good' PAKE" properly vis-a-vis
off-line dictionary attacks on slide 9 of your presentation. The 
definition of
a dictionary attack is one where the adversary gains an advantage through
_computation_ and not _interaction_.

   For "a 'good' PAKE" an off-line dictionary attack is not possible. 
It's not,
as you claim, that it takes O(sqrt(q)), it's that it's not possible at all.

   Given resistance to dictionary attack, the best an attacker can do is
repeated active attacks learning one thing with each attack: whether a 
single
guess of the password is correct. The work order of this type of attack is
based on the size of the pool from which the password is drawn (the pool
being known to the adversary).

   So your comment that an attack against "a 'good' PAKE" using curve 
P256 "for
any passphrase...is of order 2^127" is also incorrect. The order of the
curve does not matter in this sort of repeated active guessing attack,
merely the size of the pool from which the password was drawn.

> Note - the PKEX protocol was removed from IEEE 802.11ai last week.

   If you are going to make summaries of "PKEX" then you should be
complete and point out that the attacks described in your presentation
are not possible against the protocol called PKEX as described in
draft-harkins-pkex. Please correct the record.

   regards,

   Dan.