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