Re: [Ace] Asymmetric signature performance
Michael StJohns <mstjohns@comcast.net> Wed, 08 February 2017 17:10 UTC
Return-Path: <mstjohns@comcast.net>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779D21289B0 for <ace@ietfa.amsl.com>; Wed, 8 Feb 2017 09:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqeG5OT84HnD for <ace@ietfa.amsl.com>; Wed, 8 Feb 2017 09:10:12 -0800 (PST)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB78129BFE for <ace@ietf.org>; Wed, 8 Feb 2017 09:09:53 -0800 (PST)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-04v.sys.comcast.net with SMTP id bVkecPfA2E5a6bVkecI7i8; Wed, 08 Feb 2017 17:09:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1486573792; bh=iVVeFXg7glBeAxC4Nyd1PsbDKLtwpDGnTTsoA10Ahsc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fdSgmSN7oxoMN2IYgCe3gfAhuzmmi04xk8RqMLjTkBrHxqOdJUAdwp978SECj5cAk qaA+F7EhGhTWhASyxMVdwMGDXBlZ1ciMf/OfYzpG548uTHMsyrj7CaHtU6b3JKNW4B XNwwLm9WpE1E2U03T/IuREofsAsyR/CEXBxrKXiNAD+dmgx4FUTlIZRQ1i5YiGF2Gv Tb2B0hUNePt5nRV3lkDxbTszQZ9hiX1Zs6qODH2IEInmoFKisggvLzdHjrqLbx1000 JF1hXeuTeRhzrVHgynVgLbOL4KT8smjdC93hRayTIPij//hRUNWzUt8ycYisb80Zcc O/tKX1rBfv4Pw==
Received: from [IPv6:2601:152:4400:9b5f:1139:d049:134:71bb] ([IPv6:2601:152:4400:9b5f:1139:d049:134:71bb]) by resomta-ch2-02v.sys.comcast.net with SMTP id bVkecWuNy5ddFbVkecRFFZ; Wed, 08 Feb 2017 17:09:52 +0000
To: Mohit Sethi <mohit.m.sethi@ericsson.com>, "ace@ietf.org" <ace@ietf.org>
References: <3c4e0f21-e2ad-85af-4761-e158e7fc45e8@comcast.net> <3fbffd36-f846-3f21-74b8-811e54715847@ericsson.com>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <1fd13717-96d6-a7d3-6fec-86ff428967bc@comcast.net>
Date: Wed, 08 Feb 2017 12:10:03 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <3fbffd36-f846-3f21-74b8-811e54715847@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfEDGmbpTgAMDryzD8EF6LDuyuxULLAeiKKcFroG9Oxo/gM4hoUL7NKx87KcGMDci60lnheUKD/Ca/RwLL6rfSHs83Qo188JnKViFfOHOVxQvDq3QyL4N mrSz8N3eUj8D09HRuLtEmkv+gTQfaACkQXK6HX5jRShG5qQYks1Rhx2T4Rp9TC6HFJEOxLOUZWHASvko58lE0+IY53f4H2Ce5+OElUR0ANIOClYq2qupGGTT
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/j8r9UOPwR65nl87frhySgdAmTk4>
Subject: Re: [Ace] Asymmetric signature performance
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Feb 2017 17:10:13 -0000
On 2/8/2017 8:19 AM, Mohit Sethi wrote: > Hi Mike > > At least with our measurements on an 8-bit microprocessor platform, > 1024-bit RSA exponentiation was extremely slow. Please have a look at > Table 1: > > https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-01 I look at Table 1 the first thing I see is that you're using the wrong abbreviation for time - (ms is milli second), what you want is micro seconds or (us). Or are you actually trying to claim that a 1024 bit operation takes 199 seconds? Or all of 3+ minutes? Or are you using an abacus and a monkey to do the math? (And by the way - using "3" as the RSA exponent is just wrong). Table 1 doesn't actually indicate whether this is a signing operation or a verification operation, or whether or not the summary function (SHA1 or SHA256) is included. If Table 2 and table 3 have the same mistakes in time abbreviation (and I'm not sure why they wouldn't), you're saying that you can do an ECDSA function in 2-6 milliseconds. Which more than meets the requirements. > > Also, a lot of research in the crypto community is now on faster and > more efficient elliptic curves. For example, the Crypto Forum Research > group at the IRTF is currently working on Edwards curve: > https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-08 Aware of this along with Curve25519 and its ilk. Most important thing would be to get the numbers for an ARM M0 or other tiny processor for these. > > Hope this helps the discussion. > > Thanks > Mohit > > On 02/08/2017 04:55 AM, Michael StJohns wrote: >> Hi - >> >> This is sort of non-obvious, but one or two articles I read suggest >> that RSA 1024 performance may be better than the ECDSA equivalent. >> >> The tradeoff here is obviously the size of the signature and the >> transmission thereof, but... >> >> While 1024 bits isn't an ideal security strength for RSA, using any >> asymmetric key system for source authentication in group systems is >> going to be much better than trying to pretend that symmetric group >> key systems have any authentication properties at all. >> >> I saw a PPT presentation by Hannes that didn't include any RSA >> performance numbers for the ARM processors even though the key sizes >> were compared. My guess is that someone has numbers for 1024 RSA >> signatures on the tiny ARM processors that might be useful to throw >> into the mix. >> >> https://www.cryptopp.com/benchmarks.html has comparison values for a >> specific library. >> >> What I'm suggesting is that we figure out how to meet the "can't cost >> anything" requirement with weaker asymmetric keys rather than >> accepting a low end fantasy of symmetric key multicast authentication. >> >> Mike >> >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >
- [Ace] Asymmetric signature performance Michael StJohns
- Re: [Ace] Asymmetric signature performance Somaraju Abhinav
- Re: [Ace] Asymmetric signature performance Mohit Sethi
- Re: [Ace] Asymmetric signature performance Panos Kampanakis (pkampana)
- Re: [Ace] Asymmetric signature performance Derek Atkins
- Re: [Ace] Asymmetric signature performance Michael StJohns
- Re: [Ace] Asymmetric signature performance Michael StJohns
- Re: [Ace] Asymmetric signature performance Mohit Sethi
- Re: [Ace] Asymmetric signature performance Michael StJohns
- Re: [Ace] Asymmetric signature performance Somaraju Abhinav
- Re: [Ace] Asymmetric signature performance Carsten Bormann
- Re: [Ace] Asymmetric signature performance Panos Kampanakis (pkampana)
- Re: [Ace] Asymmetric signature performance Eliot Lear
- Re: [Ace] Asymmetric signature performance Derek Atkins
- Re: [Ace] Asymmetric signature performance Derek Atkins
- Re: [Ace] Asymmetric signature performance Derek Atkins
- Re: [Ace] Asymmetric signature performance Panos Kampanakis (pkampana)
- Re: [Ace] Asymmetric signature performance Derek Atkins
- [Ace] (confusing GNFS and SNFS) Re: Asymmetric si… Rene Struik
- Re: [Ace] Asymmetric signature performance Panos Kampanakis (pkampana)
- Re: [Ace] Asymmetric signature performance Mohit Sethi
- Re: [Ace] Asymmetric signature performance Joona Kannisto
- Re: [Ace] Asymmetric signature performance Derek Atkins