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
- [Cfrg] Upcoming competition deadlines Watson Ladd
- Re: [Cfrg] Upcoming competition deadlines Hanno Böck