Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Thu, 10 May 2012 13:06 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF40A21F8667 for <sidr@ietfa.amsl.com>; Thu, 10 May 2012 06:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level:
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK5jKNDa1tqO for <sidr@ietfa.amsl.com>; Thu, 10 May 2012 06:06:00 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D884821F865B for <sidr@ietf.org>; Thu, 10 May 2012 06:05:59 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 10 May 2012 09:05:52 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 10 May 2012 09:05:58 -0400
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: "Ross.Anderson@cl.cam.ac.uk" <Ross.Anderson@cl.cam.ac.uk>
Date: Thu, 10 May 2012 09:05:04 -0400
Thread-Topic: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)
Thread-Index: Ac0uh7jJi2kgKr4bTGyyhoFdKRp7VgAGphxA
Message-ID: <D7A0423E5E193F40BE6E94126930C4930B985DEF48@MBCLUSTER.xchange.nist.gov>
References: <CAH1iCiruThFzpef5u9NVt+3AokGnuFhq-GrbqEOkkKnVhav4zQ@mail.gmail.com> <CAL9jLab2XT-4NWr8KyHKOiQMTWqE5cTavmEr4Uw+S4zhrA=YLA@mail.gmail.com> <CAH1iCiq3so54pE9XBM5Bp13xaERbmShipmCg=ckEySiDsh5ZPQ@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C4930B990A66A8@MBCLUSTER.xchange.nist.gov> <CAH1iCirMKm1TbtBzWSKy=vHGLdYHvbtnXcwO1G9aG00n3DXmyw@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C4930B990A6710@MBCLUSTER.xchange.nist.gov> <D7A0423E5E193F40BE6E94126930C4930B990A6716@MBCLUSTER.xchange.nist.gov>, <CABFLmSTVmEUMYZmXNkbhSac0_jb0o-2nPG2_58Si0SGmF0podA@mail.gmail.com>
In-Reply-To: <CABFLmSTVmEUMYZmXNkbhSac0_jb0o-2nPG2_58Si0SGmF0podA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: "sidr wg list (sidr@ietf.org)" <sidr@ietf.org>
Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2012 13:06:01 -0000

Hi Ross,

The 10,000/s number is Brian Dickson's and
it is not related to ECDSA (or RSA) signing/verification of BGPSEC updates.

In my work on performance modeling of BGPSEC, I have used the basic
signing/verification measurement data from the eBACS benchmarking effort: 
http://bench.cr.yp.to/results-sign.html
The measurement numbers they report are in the same ballpark as yours for RSA signing.
However, the BGPSEC spec draft specifies ECDSA-P256, which is much faster than RSA-2048 for signing.
(Side note: ECDSA-P256 was also preferred because it results in a much lower size for BGPSEC updates
and hence lower router RIB memory size.
http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf  )

Regarding how the eBACS measurement data were used to model BGPSEC CPU performance, 
please see:
http://ripe63.ripe.net/presentations/127-111102.ripe-crypto-cost.pdf
(slides 10 and 11 summarize signing/verification speeds for various latest Intel and Cavium processors)
or see,
http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf
(slides 7 and 8).

The performance modeling and measurement work is still evolving and there is still ways to go 
w.r.t. prototyping of BGPSEC and measurements with actual signed updates, etc. 

Sriram

________________________________________
From: Ross.Anderson@cl.cam.ac.uk [rossjanderson@googlemail.com]
Sent: Thursday, May 10, 2012 4:35 AM
To: Sriram, Kotikalapudi
Cc: Brian Dickson (brian.peter.dickson@gmail.com) sidr wg list (sidr@ietf.org)
Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)

Sriram

You can't get 10,000 signature creations and verifications a second on
a standard Intel core. You can get maybe 100.

Your colleagues who work on smart grid standards have experience of
this. The IEC working group assumed that all LAN traffic in
electricity substations could be authenticated by digital signatures.
This turned out to not work, and caused a major stall in the smart
grid security program. Some substation LAN traffic has a hard
end-to-end latency bound of 4ms, and that simply can't be achieved on
standard cores using 1024-bit RSA signatures. You need custom
hardware, which brings serious export control headaches as well as
significant costs. We wrote this up in

  http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf

Ross