Re: [Cfrg] Hardware requirements for elliptic curves
Torsten Schuetze <torsten.schuetze@gmx.net> Thu, 11 September 2014 08:51 UTC
Return-Path: <torsten.schuetze@gmx.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1B11A0690 for <cfrg@ietfa.amsl.com>; Thu, 11 Sep 2014 01:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.152
X-Spam-Level:
X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
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 0aSGAqf-YasT for <cfrg@ietfa.amsl.com>; Thu, 11 Sep 2014 01:51:03 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54541A0688 for <cfrg@irtf.org>; Thu, 11 Sep 2014 01:51:02 -0700 (PDT)
Received: from [192.168.0.12] ([109.192.91.63]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MMpYB-1XRCkC3Ajf-008dli; Thu, 11 Sep 2014 10:50:47 +0200
Message-ID: <54116278.3080901@gmx.net>
Date: Thu, 11 Sep 2014 10:51:04 +0200
From: Torsten Schuetze <torsten.schuetze@gmx.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: cfrg@irtf.org
In-Reply-To: <54099FCC.6050200@secunet.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:3Bnsd82P9SbwBXZJ4Uwzi+W44qs2YCWuA8rZS5k5G6toJYhn81E 14CBKXg2/Jc0zp835cnNwsuVnqPYrXUaEd2mv1VZmwN4ftln3wdr5QUBiDa5ixeWHCl7+ii E/6BmvxymcBHgCMHZvAuuyuAHLMxWj7A5AT+HMddX9auQ+pPXCxv3ePbA6ondPuOcccg0r8 MH+PmkCLfOw6THuCxKYnw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/tkbz5ex1YlRgajIF0dQ2Xz04uLU
Subject: Re: [Cfrg] Hardware requirements for elliptic curves
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 08:51:05 -0000
On 06/09/2014 15:52:54 +0100, Alyssa Rowan <akr at akr.io> wrote: > On 05/09/2014 12:34, Johannes Merkle wrote: > >> What I understood is that [hardware vendors] do not want to >> specialize their hardware to minimize their investment while being >> fully flexible (algorithm agile). [...] Furthermore, I guess that >> new implementations can be built easier based on existing ones. > > Quite. For decades, many vendors of cryptoprocessors have been basing > their implementations almost directly on existing ones with very few, > extremely conservative changes, presumably minimising their investment > by reusing as much as possible. > > Respectfully, I do not think that conservative approach delivers > sufficient assurance where the integrity of the base is properly in > question: you don't add a conservatory to fix uncertain foundations. Respectfully, could you please elaborate on what is an uncertain foundation with a general modular multiplier that computes Z=M*C mod N for general modulus structure of N and arbitrary multiplier M and multiplicand C? > While some existing hardware could indeed be adapted, whether abusing > the RSA multiplier where possible or (more likely, I feel) implementing > it entirely in firmware, I suggest those seeking these recommendations > for new elliptic curves, via an open process like this, should also have > plenty of concerns about crypto implementations presented as a closed > "black box" with an uncertain pedigree which has not also been designed, > audited, and certified as openly as possible from its inception. Rusty, > closed crypto hardware with new paintwork is, I feel, unlikely to meet > those needs. Only the multiplier is in hardware. ECC on smart cards is usually done in firmware, as you call it. Companies like Gemalto or Giesecke & Devrient do this regularly, if you don't trust the hardware vendor like NXP, Samsung, Infineon, etc. What do you mean with "an uncertain pedigree which has not also been designed, audited, and certified as openly as possible from its inception"? Smart cards, i.e., its coprocessors and its ECC software implementations, are always certified by Common Criteria, usually with rather high assurance level. Don't you trust this certification in principle? Shall everything be open-source? Do you trust your compiler when compiling your specialized highly-optimized elliptic curve arithmetic? Or do you perform a formal verification before hand? Do you trust your Intel processor? > I'm not aware of any cryptoprocessor vendor who has shipped any new > hardware like that, but I would heartily welcome and encourage it. As I have said, they do this regularly, i.e., ship "new" hardware that has been evaluated and certified by defined processes. By the way, in a mail from Sep 02 you wrote "I think it would be a mistake to allow old hardware implementations to (yet again) needlessly overshadow improved software ones" Only the multiplier is in hardware, everything else is in software/firmware. What is old hardware for you? Do you know the product and development cycles/costs for ASICs/smart cards? We do not want and we will not design a new public-key coprocessor, a new RNG, a new symmetric coprocessor, a new memory encryption unit, etc. every new year. Besides that, the software on the smart cards has much shorter cycles. For example, the German scheme for qualified digital signatures, the highest security requirements in the public sector, has cycle times about 7-8 years, i.e., 2-3 years development and evaluation, 5 years in the field. > I gather a few efforts are under way from private teams, as has been > previously discussed. We as high-security/hardware crypto community certainly welcome new ideas. Competition is always good for security. Regards, Torsten -- ROHDE & SCHWARZ SIT GmbH Hemminger Str. 41 D-70499 Stuttgart/Weilimdorf http://www.sit.rohde-schwarz.com mailto:torsten.schuetze@rohde-schwarz.com
- [Cfrg] Hardware requirements for elliptic curves Joppe Bos
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Michael Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Johannes Merkle
- Re: [Cfrg] Hardware requirements for elliptic cur… Michael Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Andy Lutomirski
- Re: [Cfrg] Hardware requirements for elliptic cur… Robert Ransom
- Re: [Cfrg] Hardware requirements for elliptic cur… Lochter, Manfred
- Re: [Cfrg] Hardware requirements for elliptic cur… Johannes Merkle
- Re: [Cfrg] Hardware requirements for elliptic cur… Wieland.Fischer
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Watson Ladd
- Re: [Cfrg] Hardware requirements for elliptic cur… Patrick Georgi
- Re: [Cfrg] Hardware requirements for elliptic cur… Paul Lambert
- Re: [Cfrg] Hardware requirements for elliptic cur… Torsten Schuetze
- Re: [Cfrg] Hardware requirements for elliptic cur… Torsten Schuetze
- Re: [Cfrg] Hardware requirements for elliptic cur… Andy Lutomirski
- Re: [Cfrg] Hardware requirements for elliptic cur… Mike Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Torsten Schuetze
- Re: [Cfrg] Hardware requirements for elliptic cur… Watson Ladd
- Re: [Cfrg] Hardware requirements for elliptic cur… Mike Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Lochter, Manfred
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Dirk Feldhusen
- Re: [Cfrg] Hardware requirements for elliptic cur… Lochter, Manfred
- Re: [Cfrg] Hardware requirements for elliptic cur… Ilari Liusvaara
- Re: [Cfrg] Hardware requirements for elliptic cur… Watson Ladd
- Re: [Cfrg] Hardware requirements for elliptic cur… Peter Gutmann
- [Cfrg] Trusting government certifications of cryp… D. J. Bernstein
- Re: [Cfrg] Trusting government certifications of … David Jacobson
- Re: [Cfrg] Trusting government certifications of … Torsten Schütze
- Re: [Cfrg] Trusting government certifications of … Watson Ladd
- Re: [Cfrg] Trusting government certifications of … Dirk Feldhusen
- Re: [Cfrg] Trusting government certifications of … Michael Hamburg
- Re: [Cfrg] Trusting government certifications of … Dirk Feldhusen
- Re: [Cfrg] Trusting government certifications of … Lochter, Manfred
- Re: [Cfrg] Trusting government certifications of … Mike Hamburg
- Re: [Cfrg] Primes vs. hardware side channels David Leon Gil
- [Cfrg] Primes vs. hardware side channels D. J. Bernstein
- Re: [Cfrg] Primes vs. hardware side channels Alyssa Rowan