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