Re: [Cfrg] likelihood that someone has a quantum computer

arne renkema-padmos <arne.renkema-padmos@cased.de> Tue, 14 January 2014 22:49 UTC

Return-Path: <arne.renkema-padmos@cased.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 94E811AE2BD for <cfrg@ietfa.amsl.com>; Tue, 14 Jan 2014 14:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level:
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 Je97C-UzQ6di for <cfrg@ietfa.amsl.com>; Tue, 14 Jan 2014 14:49:04 -0800 (PST)
Received: from lnx503.hrz.tu-darmstadt.de (lnx503.hrz.tu-darmstadt.de [130.83.156.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA4B1ADFF3 for <cfrg@irtf.org>; Tue, 14 Jan 2014 14:49:03 -0800 (PST)
Received: from mail.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.167.6]) by lnx503.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id s0EMmpH0021383; Tue, 14 Jan 2014 23:48:51 +0100 (envelope-from arne.renkema-padmos@cased.de)
Received: from localhost.localdomain (gate.cdc.informatik.tu-darmstadt.de [130.83.167.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTPSA id 745EC23A56; Tue, 14 Jan 2014 23:48:51 +0100 (CET)
Message-ID: <52D5BED3.1090407@cased.de>
Date: Tue, 14 Jan 2014 23:48:51 +0100
From: arne renkema-padmos <arne.renkema-padmos@cased.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: William Whyte <wwhyte@securityinnovation.com>, cfrg@irtf.org
References: <52C755AA.70200@cisco.com> <33E0BF53-A331-4646-B080-FD4F6E13916E@ieca.com> <810C31990B57ED40B2062BA10D43FBF5C1BF54@XMB116CNC.rim.net> <52D29B10.4030401@cisco.com> <CACz1E9rsLRwqpA0fS2RNOcpsn7DMqaN=7dcJDQqEi8HDMKKonQ@mail.gmail.com> <CACsn0c=mYv7v3fGCHCe9D5w2j+gRWWsmoUA7NQ=AsczTMP1rDw@mail.gmail.com> <d4d82e7c3988ce4908202185921ed7bb@mail.gmail.com> <52D3FEC2.4080602@cased.de> <94153160f9ff12c3f2171a240bd9855f@mail.gmail.com>
In-Reply-To: <94153160f9ff12c3f2171a240bd9855f@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2014.1.14.223914
X-PMX-RELAY: outgoing
Subject: Re: [Cfrg] likelihood that someone has a quantum computer
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: Tue, 14 Jan 2014 22:49:06 -0000

On 14/01/14 03:04, William Whyte wrote:
> So is the idea that all devices have to implement both algorithms? Is
> there a mechanism in place for declaring one broken and requiring that the
> other is used at all times?

>From what I could find KASUMI (UEA1,UIA1) and SNOW 3G (UEA2,UIA2) are
the "preferable HW [hardware] profile for UMTS", whatever that means:

http://docbox.etsi.org/workshop/2008/2008_securityworkshop/s8_2_taizo_shirai.pdf

I'm not sure what mechanism is in place for fallback and would
appreciate if others could chime in.

> TBH I'm less concerned about catastrophic failure of symmetric algorithms
> than public-key algorithms, but I'm very interested in processes to
> replace algorithms.

I agree that this is more of a general problem that is not algorithm
bound. It's not even a problem bound to cryptography, although I guess
we might be able to identify best practices (or whatever you'd like to
call them) specific to cryptography in informing algorithm roll-out.

Cheers,
arne

-- 
Arne Renkema-Padmos
@hcisec, secuso.org
Doctoral researcher
CASED, TU Darmstadt