Re: [Cfrg] Upcoming competition deadlines

Hanno Böck <hanno@hboeck.de> Thu, 06 March 2014 09:58 UTC

Return-Path: <hanno@hboeck.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 1244D1A01D3 for <cfrg@ietfa.amsl.com>; Thu, 6 Mar 2014 01:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 mk2eRSLpuy71 for <cfrg@ietfa.amsl.com>; Thu, 6 Mar 2014 01:58:13 -0800 (PST)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 598611A01C8 for <cfrg@irtf.org>; Thu, 6 Mar 2014 01:58:13 -0800 (PST)
Received: from localhost (91-64-48-103-dynip.superkabel.de [::ffff:91.64.48.103]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 06 Mar 2014 10:58:08 +0100 id 00000000000200C9.00000000531846B0.00007351
Date: Thu, 06 Mar 2014 10:57:38 +0100
From: Hanno Böck <hanno@hboeck.de>
To: cfrg@irtf.org
Message-ID: <20140306105738.65e922dd@hboeck.de>
In-Reply-To: <CACsn0c==kKAWD=hhWoMb0r2VK5nx2GRHX_LemwyeuToCEsM6LQ@mail.gmail.com>
References: <CACsn0c==kKAWD=hhWoMb0r2VK5nx2GRHX_LemwyeuToCEsM6LQ@mail.gmail.com>
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-29521-1394099888-0001-2"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/PcvZV6tpQ-mUejqw2DnleffVTUk
Subject: Re: [Cfrg] Upcoming competition deadlines
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, 06 Mar 2014 09:58:16 -0000

On Wed, 5 Mar 2014 18:10:06 -0800
Watson Ladd <watsonbladd@gmail.com> wrote:

> I think it's clear that we need a side-channels draft: since people
> seem to vehemently disagree about ladd-safecurves, and there are some
> open technical questions about what formats are good, I'm going to
> redirect my efforts to getting the side-channels draft further along.
> Comments on what would make it useful/scarier would be greatly
> appreciated.

Just some quick thoughts on that: I think this is remarkably
challenging. Because you're faced with a pretty tough question: What
exactly is a "side channel"?

We can probably come up with a formal definition of a timing side
channel easily. But "side channels" in general are an almost infinite
amunt of things. You could probably sum them up as "every information
about keys and encrypted messages that leaves a cryptosystem through
any kind of channel, including physics".

It's probably just plain impossible to build any kind of system that
does calculations without affecting its surrounding physics based on
the content of the calculation. That said: We probably have to face the
fact that a side channel-free system is impossible.

So any kind of side channel protection can only work with some kind of
heuristics. We can lower the information impact on the outside world
(this is what RSA blinding does for example).

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42