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
>