Re: [IPsec] PAKE selection: SPSK

"Dan Harkins" <dharkins@lounge.org> Wed, 02 June 2010 16:24 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6253A6828 for <ipsec@core3.amsl.com>; Wed, 2 Jun 2010 09:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level:
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQXa-ctyPLfD for <ipsec@core3.amsl.com>; Wed, 2 Jun 2010 09:24:57 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 4E7613A63C9 for <ipsec@ietf.org>; Wed, 2 Jun 2010 09:24:57 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C4C581022404C; Wed, 2 Jun 2010 09:24:44 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Jun 2010 09:24:44 -0700 (PDT)
Message-ID: <c55a736de45cc898565b8e883d57bf8c.squirrel@www.trepanning.net>
In-Reply-To: <201006021045.43514.dennis.kuegler@bsi.bund.de>
References: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> <201006011517.44654.dennis.kuegler@bsi.bund.de> <2354574b94c9b8805fb3f2bcc6f995b5.squirrel@www.trepanning.net> <201006021045.43514.dennis.kuegler@bsi.bund.de>
Date: Wed, 02 Jun 2010 09:24:44 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Dennis Kügler <dennis.kuegler@bsi.bund.de>
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: ipsec@ietf.org
Subject: Re: [IPsec] PAKE selection: SPSK
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2010 16:24:58 -0000

  Hi Dennis,

>>   You say, "[d]ue to the group generator SKE, a pluralty of key
>> distribution techniques is defined - one for each possible (and secret)
>> value of SKE." That's not what the patent is talking about. The
>> "plurality
>> of key distribution techniques" describes different techniques of key
>> distribution not a single technique being used with different
>> passwords--
>> and therefore different SKEs.
>
> ...based on the password??? Strange interpretation, but I don't think that
> we'll find consens on that and therefore I skip this discussion here.

  The strange interpretation is all yours. You said "one for each possible
(and secret) value of SKE." Different values of SKE occur through different
passwords.

  I agree there is no consensus on your view of this matter because it
is not supported by descriptive text in the rest of the patent.

>>   Down at the bottom of this email you mention that this method is
>> "cryptographically not sound". First of all, I will note that this means
>> you are, in fact, treating this technique differently than the others,
>> since I don't believe you are claiming that Diffie-Hellman or El Gamal
>> is "cryptographically not sound". That buttresses my statement above
>> that this technique is different. Thank you for helping to prove my
>> point.
>
> You're welcome. Although I don't think that it'll help you to convince the
> patent holder.

  Thank you for offering your personal opinion. Let me return the favor:
I think it's more convincing that making irrelevant remarks ("the password
is only temporarily used") followed by incorrect statements ("the key
derivation is completely independent of the password").

>>   Regarding your claim, one has to know SKE to generate SKE^private
>> and "anyone" does not know the password, so "anyone" cannot generate
>> SKE^private.
>>
>>   Also, you say the private key can be leaked. If you can show how a
>> passive attacker can determine a private key in dragonfly-- even if
>> you tell the passive attacker the password!-- I will show you how that
>> very same attacker can solve the Computational Diffie-Hellman (CDH)
>> problem with the same computational advantage. Since it is assumed that
>> the CDH problem is computationally infeasible it can safely be assumed
>> that the attack you suggest is also computationally infeasible.
>
> I'm looking forward to that.

  And I'm looking forward to giving it to you :-) But I said "if you
can show me how a passive attacker can determine a private key...." so
the proverbial ball is in your court. Show me how a passive attack can
successfully obtain either private key in dragonfly (not something that
begins "well, if he uses a bad random number generator..." which is not
an attack against the protocol) and I'll show you how you can solve
the CDH.

>                               When can we expect a full paper?

  Real Soon Now (tm). I know you are aware that it is time consuming and
not a trivial task.

  But something that is much easier is for you to do a full and
adequate response to my previous statement on PACE-- it infringes on
claims 1 and 10 of US 6,792,533. When can we expect that?

  It is quite telling that you apparently do not wish to engage in the
same sort of detailed analysis of PACE that you do with dragonfly.

  regards,

  Dan.