Re: [Cfrg] ECC reboot (Was: When's the decision?)

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 17 October 2014 09:48 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 3C2231AC3AC for <cfrg@ietfa.amsl.com>; Fri, 17 Oct 2014 02:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 w0e1tBtL1up4 for <cfrg@ietfa.amsl.com>; Fri, 17 Oct 2014 02:47:59 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4051AC3AB for <cfrg@irtf.org>; Fri, 17 Oct 2014 02:47:58 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id DA5491887B9; Fri, 17 Oct 2014 12:47:55 +0300 (EEST)
Date: Fri, 17 Oct 2014 12:47:55 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Johannes Merkle <johannes.merkle@secunet.com>
Message-ID: <20141017094755.GA29915@LK-Perkele-VII>
References: <D065A817.30406%kenny.paterson@rhul.ac.uk> <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <5440DFA7.80208@secunet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <5440DFA7.80208@secunet.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7aKTWfwW0n6O2Td_1v6WOhEZ3Mw
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?)
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: Fri, 17 Oct 2014 09:48:01 -0000

On Fri, Oct 17, 2014 at 11:21:43AM +0200, Johannes Merkle wrote:
> 
> Alyssa Rowan wrote on 16.10.2014 19:38:
> > I can see why they might want that, if VPR is the most convenient
> > for their implementations - but from what I see from the hesitant
> > adoption of Brainpool in the wider community,
> 
> this assertion is only true for software implementations. Brainpool
> curves are used by more than 50 million smart cards rolled out and
> several vpn solutions (e.g., based on IPSec) widely used within
> German and EU public authorities.

And what's wrong with just using Brainpool for implementations that
need random primes for extended side channel resistance? Not rigid
enough? Not standard enough?


For software implementations only needing defenses against software
attack (including attacks from different process in the same host/VM)
there is plenty wrong with using Brainpool.

If attacker can get enough access to pull off EM attacks against most
of the endpoints, one has more severe problems than software vulernable
to EM attack.

There is a good reason (singular!) why NIST/NSA curves are used far far
more in TLS than Brainpool, despite there being codepoints for both:
Performance.


-Ilari