Re: [Cfrg] Trusting government certifications of cryptography
Dirk Feldhusen <dirk.feldhusen@src-gmbh.de> Wed, 08 October 2014 08:05 UTC
Return-Path: <dirk.feldhusen@src-gmbh.de>
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 B9F871A00D0 for <cfrg@ietfa.amsl.com>; Wed, 8 Oct 2014 01:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 oztpVLWaJyEL for <cfrg@ietfa.amsl.com>; Wed, 8 Oct 2014 01:05:00 -0700 (PDT)
Received: from apfel.src-bonn.de (apfel.src-bonn.de [78.35.41.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E204C1A00BA for <cfrg@irtf.org>; Wed, 8 Oct 2014 01:04:59 -0700 (PDT)
Received: from imail (imail.src-gmbh.lan [192.168.8.3]) by apfel.src-bonn.de (Postfix) with SMTP id C5EAF959B; Wed, 8 Oct 2014 10:04:57 +0200 (CEST)
Message-ID: <5434F025.5020301@src-gmbh.de>
Date: Wed, 08 Oct 2014 10:04:53 +0200
From: Dirk Feldhusen <dirk.feldhusen@src-gmbh.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Michael Hamburg <mike@shiftleft.org>
References: <20141003111024.20324.qmail@cr.yp.to> <trinity-5e384bba-2edd-4ee2-a511-c8dc1caa173a-1412669702907@3capp-gmx-bs29> <CACsn0cm1jw6v0gFu0uwYmgqxVFes8y2AyW26eRGhCt8xmTyr6Q@mail.gmail.com> <54341010.8050207@src-gmbh.de> <CB8D38CD-55A1-4F04-9AA1-59A6556E30E4@shiftleft.org>
In-Reply-To: <CB8D38CD-55A1-4F04-9AA1-59A6556E30E4@shiftleft.org>
Content-Type: multipart/alternative; boundary="------------020504060808060406090606"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/T-dNEx9dGg5cbCY7Lin_neTZcOg
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: [Cfrg] Trusting government certifications of cryptography
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: Wed, 08 Oct 2014 08:05:05 -0000
Am 07.10.2014 18:55, schrieb Michael Hamburg: > >> On Oct 7, 2014, at 9:08 AM, Dirk Feldhusen >> <dirk.feldhusen@src-gmbh.de <mailto:dirk.feldhusen@src-gmbh.de>> wrote: > >> To exclude the possibilty of power or EM side channel you need the >> assumption that the attacker has no physical access to the device. >> As I understand Torsten the main problem here are special primes which >> are harder to secure against such side channel leakage. > > Are they actually harder to secure (eg, requiring new > countermeasures), or just slower on hardware which doesn’t accelerate > the special prime (eg, by requiring longer blinding factors)? > > — Mike I agree to both. First, additive point (and scalar) blinding doesn't work properly for a special prime ie adding a small multiple of the prime leaves most parts of the binary representation of the point coordinate unchanged (depends on the kind of the leakage, here it is assumed that the Hamming weight of single words leaks through the multiplication). Of course other blinding methods could work. Second, hardware designed for general primes doesn't accelerate special primes as far as I know and inserting large blinding factors would slow it further down. But this depends on the blinding method. — Dirk
- [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