Re: [IPsec] PAKE selection: SPSK
Dennis Kügler <dennis.kuegler@bsi.bund.de> Wed, 02 June 2010 08:46 UTC
Return-Path: <dennis.kuegler@bsi.bund.de>
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 DA3353A6968 for <ipsec@core3.amsl.com>; Wed, 2 Jun 2010 01:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_17=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 722zFWjH7T8E for <ipsec@core3.amsl.com>; Wed, 2 Jun 2010 01:46:21 -0700 (PDT)
Received: from m2-bn.bund.de (m2-bn.bund.de [77.87.228.74]) by core3.amsl.com (Postfix) with ESMTP id 2EC283A684B for <ipsec@ietf.org>; Wed, 2 Jun 2010 01:46:20 -0700 (PDT)
Received: from m2.mfw.bn.ivbb.bund.de (localhost [127.0.0.1]) by m2-bn.bund.de (8.13.8/8.13.8) with ESMTP id o528k5A4028921 for <ipsec@ietf.org>; Wed, 2 Jun 2010 10:46:05 +0200 (CEST)
Received: (from localhost) by m2.mfw.bn.ivbb.bund.de (MSCAN) id 4/m2.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Wed Jun 2 10:46:05 2010
X-Virus-Scanned: by amavisd-new at bsi.bund.de
From: Dennis Kügler <dennis.kuegler@bsi.bund.de>
Organization: BSI Bonn
To: ipsec@ietf.org
Date: Wed, 02 Jun 2010 10:45:43 +0200
User-Agent: KMail/1.9.10 (enterprise35 20100401.1112527)
References: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> <201006011517.44654.dennis.kuegler@bsi.bund.de> <2354574b94c9b8805fb3f2bcc6f995b5.squirrel@www.trepanning.net>
In-Reply-To: <2354574b94c9b8805fb3f2bcc6f995b5.squirrel@www.trepanning.net>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201006021045.43514.dennis.kuegler@bsi.bund.de>
X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.1.242; VDF: 7.10.7.210; host: sgasmtp2.bsi.de); id=9395-Js1Ld3
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 08:46:24 -0000
Hi Dan, > > The issue here is the meaning of a "plurality of key distribution > techniques." So let's have again a look at the claim: [...] selecting a parameter based on said password-based value, said parameter defining one of a plurality of unauthenticated key distribution techniques; [...] It explains very clearly that the key distribution mechanism to be used is defined by a parameter, which is derived from the password. I don't think that you can interpret this differently. SPEKE does this by selecting the parameter as group generator but also claims any other method. SPSK does this similarly. > > 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 thing that D-H, Modified D-H, El Gamal, and static variants of D-H-- > i.e other known techniques of unauthenticated key distribution-- is that > the key being distributed is a secret (private key) that has been > obfuscated in a form (a public key) so it cannot be recovered when > distributed. All of these things have the following in common: > > public = g^private modulo prime > > (or equivalent ECC representation). That's the thing-- "public"-- that > gets distributed whether you're doing plain-jane Diffie-Hellman, whether > you're doing Modified Diffie-Hellman, whether you're doing El Gamal, > in other words, when you're doing the "plurality of key distribution > techniques". They all use the discrete logarithm problem to hide > the private key and create a public key as part of their key distribution > technique. > > Dragonfly's method of obfuscation of the private key to produce the > public key is different than the others-- it uses addition modulo the > ORDER of the group. > > public = private + mask modulo order > > It is different, unique, novel, new and therefore cannot be part of any > claimed plurality of key distribution techniques. If you disagree, I defy > you to show me mention of this technique anywhere to construct and > distribute public keys out of private keys (or if you are claiming that > a patent holder can patent today things that have not yet been invented > then please make that claim). As I've already tried to explain in my last mail, you not only define public1 = private + mask but also public2 = g^(-mask) which finally can be combined to (by everyone) public = public2 * g^public1 = g^(-mask + private + mask)= g^private The obfuscation step isn't obfuscating the public key at all, it just introduces potential problems as the OTP on the private key very likely leaks information, if not applied correctly. The correct application of a OTP is not trivial especially if the OTP is applied modulo a prime. This is why I called it cryptographically not sound as this step is not giving you any benefit but may cause a lot of problems. > > 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. > > 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. When can we expect a full paper? Best regards, Dennis
- [IPsec] PAKE selection: SPSK Dan Harkins
- Re: [IPsec] PAKE selection: SPSK Dennis Kügler
- Re: [IPsec] PAKE selection: SPSK Dan Harkins
- Re: [IPsec] PAKE selection: SPSK Dennis Kügler
- Re: [IPsec] PAKE selection: SPSK Dan Harkins
- Re: [IPsec] PAKE selection: SPSK Dennis Kügler
- Re: [IPsec] PAKE selection: SPSK Dan Harkins