Re: [IPsec] DH keys calculation performance
Hugo Krawczyk <hugo@ee.technion.ac.il> Tue, 26 July 2011 15:59 UTC
Return-Path: <hugokraw@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B00911E80EC for <ipsec@ietfa.amsl.com>; Tue, 26 Jul 2011 08:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 drTiI2xOmKGR for <ipsec@ietfa.amsl.com>; Tue, 26 Jul 2011 08:59:40 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B202B11E808E for <ipsec@ietf.org>; Tue, 26 Jul 2011 08:59:34 -0700 (PDT)
Received: by vws12 with SMTP id 12so534639vws.31 for <ipsec@ietf.org>; Tue, 26 Jul 2011 08:59:34 -0700 (PDT)
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=RpnQ1x54p91YctjqJhGMUvqKgkxPTYRNaSjs4ZwnZtQ=; b=bT6CChanwlcTZVuI4VzoDpIhIBJEevCqkQIZ6OZ39GHuU+BAdGlUUi043rNrrDAgcD 1ZTU7FYv5zEN+Hc55nTi6OyXB9wEP/AKxfK4fnL+NG3qa/18S3wmVUvujqPVEN4bFtlL JFtyoRCqFfngJvNbiSZb22EAkz+kSjVkMLD1A=
Received: by 10.52.93.65 with SMTP id cs1mr6073443vdb.444.1311695974094; Tue, 26 Jul 2011 08:59:34 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.52.159.4 with HTTP; Tue, 26 Jul 2011 08:59:14 -0700 (PDT)
In-Reply-To: <c43f2432c72d92b6293425e537694474.squirrel@www.trepanning.net>
References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <B97B134FACB2024DB45F524AB0A7B7F203ED2B05@XMB-BGL-419.cisco.com> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> <B97B134FACB2024DB45F524AB0A7B7F203ED2CEA@XMB-BGL-419.cisco.com> <c43f2432c72d92b6293425e537694474.squirrel@www.trepanning.net>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Tue, 26 Jul 2011 11:59:14 -0400
X-Google-Sender-Auth: 91HCxGFAGKjXH1aT9qemdnzraIk
Message-ID: <CADi0yUMdPo+A5YLY2rh4LGU4tP4T5EWuzWAALLmgSEWdy=0pdw@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary="bcaec501649796d6e704a8fb046d"
Cc: ipsec@ietf.org, Yoav Nir <ynir@checkpoint.com>, "Prashant Batra (prbatra)" <prbatra@cisco.com>
Subject: Re: [IPsec] DH keys calculation performance
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 26 Jul 2011 15:59:41 -0000
Regarding Dan's suggestion (*) of using g^x, g^{x+1}, etc as successive DH values, I would like to note the following. This would lead to situations where two parties exchange successive keys of the form g^{xy} and g^{(x+1)(y+1)}=g^{xy}*g^x*g^y*g. In this case, if an attacker learns the key g^{xy} it also learns the next key, something that violates key-exchange security (i.e. security against "known key attacks"). However, if one models the key derivation function applied to g^{xy} as a random oracle then this usage is probably ok (I did not prove it), assuming the attacker does not have access to g^{xy} before hashing. This is a weaker security property than the one achieved by always choosing x and y afresh (in which case we have proof of security without resorting to random oracle assumptions and without assuming that the attacker never gets to see g^{xy}). In a performance-vs-security tradeoff one may choose to use this method, but one should be aware that there is a trade-off here. Hugo (*) I am not blaming Dan. I actually suggested that trick in my 1995 SKEME paper as a way to improve over the suggestion of re-using the same exponent in multiple exchanges as proposed at the time in the Photuris protocol. It indeed improved over Photuris but today I would be more careful about suggesting that. On Tue, Jul 26, 2011 at 10:55 AM, Dan Harkins <dharkins@lounge.org> wrote: > > Hello, > > On Tue, July 26, 2011 6:03 am, Prashant Batra (prbatra) wrote: > > Thanks Yoav and Yaron for the suggestions. > > > > Even I was thinking and tried generating and storing the key pair well > > in the beginning,. This helped to some extent. > > > > > > > > The secret calculation is also very expensive, but this has to be done > > in midst of the exchange only. > > You could pick one secret x and then for IKE exchanges do this: > > 0th exchange: y = g^x mod p > 1st exchange: y = g^(x+1) mod p > 2nd exchange: y = g^(x+2) mod p > . > . > . > nth exchange: y = g^(x+n) mod p > > Getting from exchange i to exchange i+1, then, is just a single modular > multiply, which should be "cheaper" for you. > > Knowing n, y, g and p and that y = g^(x+n) mod p does not really give > an advantage (above the discrete logarithm problem) in finding x. That > said, I still would not suggest doing many more than a few of these (and > I am not qualified to quantify that statement) but for a few-- i.e. keep > n small and after n choose a new x and repeat-- it should be OK. > > Maybe this technique will allow you to "cheapen" your exchange a bit. > I think throwing hardware at this problem is your best bet though. > > regards, > > Dan. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
- [IPsec] New Version Notification for draft-kivine… Tero Kivinen
- [IPsec] DH keys calculation performance Prashant Batra (prbatra)
- Re: [IPsec] DH keys calculation performance Vishwas Manral
- Re: [IPsec] DH keys calculation performance Yoav Nir
- Re: [IPsec] DH keys calculation performance Yaron Sheffer
- Re: [IPsec] DH keys calculation performance Prashant Batra (prbatra)
- Re: [IPsec] DH keys calculation performance Dan Harkins
- Re: [IPsec] DH keys calculation performance Scott Fluhrer (sfluhrer)
- Re: [IPsec] DH keys calculation performance Yoav Nir
- Re: [IPsec] DH keys calculation performance Hugo Krawczyk
- Re: [IPsec] DH keys calculation performance Scott Fluhrer (sfluhrer)
- [IPsec] IPSec implementation query. Prashant Batra (prbatra)
- Re: [IPsec] DH keys calculation performance Naveen B N (nbn)
- Re: [IPsec] DH keys calculation performance Naveen B N (nbn)
- Re: [IPsec] DH keys calculation performance Scott Fluhrer (sfluhrer)
- Re: [IPsec] DH keys calculation performance Naveen B N (nbn)
- [IPsec] New method to resist replay attack in ike… ramaswamy
- Re: [IPsec] DH keys calculation performance Scott Fluhrer (sfluhrer)
- Re: [IPsec] DH keys calculation performance Naveen B N (nbn)
- Re: [IPsec] Perfect Forward secrecy Naveen B N (nbn)
- Re: [IPsec] Perfect Forward secrecy Yoav Nir
- Re: [IPsec] Perfect Forward secrecy Dan Harkins
- Re: [IPsec] Tokes = Session key + lifetime Naveen B N (nbn)
- Re: [IPsec] Perfect Forward secrecy Stephen Kent
- Re: [IPsec] Avoid multiple authentication's Naveen B N (nbn)
- Re: [IPsec] Avoid multiple authentication's Yaron Sheffer
- Re: [IPsec] Avoid multiple authentication's Naveen B N (nbn)
- [IPsec] New method to resist replay attack in ike… Tero Kivinen
- Re: [IPsec] New method to resist replay attack in… ramaswamy
- Re: [IPsec] New method to resist replay attack in… Tero Kivinen
- Re: [IPsec] New method to resist replay attack in… ramaswamy
- Re: [IPsec] New method to resist replay attack in… ramaswamy
- Re: [IPsec] New method to resist replay attack in… ramaswamy