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

"Lochter, Manfred" <manfred.lochter@bsi.bund.de> Wed, 22 October 2014 12:05 UTC

Return-Path: <manfred.lochter@bsi.bund.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 ED3481A900A for <cfrg@ietfa.amsl.com>; Wed, 22 Oct 2014 05:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.859
X-Spam-Level:
X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 5AmQxIVJtXeb for <cfrg@ietfa.amsl.com>; Wed, 22 Oct 2014 05:05:05 -0700 (PDT)
Received: from m1-bn.bund.de (m1-bn.bund.de [77.87.228.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6141A90B3 for <cfrg@irtf.org>; Wed, 22 Oct 2014 05:05:03 -0700 (PDT)
Received: from m1.mfw.bn.ivbb.bund.de (localhost.mfw.bn.ivbb.bund.de [127.0.0.1]) by m1-bn.bund.de (8.14.5/8.14.5) with ESMTP id s9MC51wC031993 for <cfrg@irtf.org>; Wed, 22 Oct 2014 14:05:01 +0200 (CEST)
Received: (from localhost) by m1.mfw.bn.ivbb.bund.de (MSCAN) id 5/m1.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Wed Oct 22 14:05:01 2014
X-P350-Id: 223ceb2a2e01730a
X-Virus-Scanned: by amavisd-new at bsi.bund.de
From: "Lochter, Manfred" <manfred.lochter@bsi.bund.de>
Organization: BSI Bonn
To: cfrg@irtf.org
Date: Wed, 22 Oct 2014 14:04:36 +0200
User-Agent: KMail/1.9.10 (enterprise35 20140205.23bb19c)
References: <D065A817.30406%kenny.paterson@rhul.ac.uk> <201410211027.13608.manfred.lochter@bsi.bund.de> <DA102AD0-54CF-4BEC-86AA-7568A05D964A@akr.io>
In-Reply-To: <DA102AD0-54CF-4BEC-86AA-7568A05D964A@akr.io>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID: <201410221404.36477.manfred.lochter@bsi.bund.de>
X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.3.24.38; VDF: 7.11.180.138; host: sgasmtp2.bsi.de); id=11769-gxS0gj
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/NPINi8mPLPhDOjxJkw5Z9Zc3gaI
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: Wed, 22 Oct 2014 12:05:10 -0000






>
> If you wanted another Brainpool: why, and what is stopping Brainpool from
> doing it? You didn't need to do it here before. You seem to be worried the
> BADA55 paper discredits the Brainpool curves by showing a plausible way
> they could have been rigged. It doesn't prove that they actually were
> rigged (indeed, Brainpool is listed on Safecurves as "somewhat rigid" and
> still has a tick in that box). Where's the fire?

For examle here:
Andy Lutomirski wrote on 16.10.2014 20:06:
> Are the Brainpool curves really VPR?  They're certainly far better in
> that regard than the NIST curves, but the BADA55 paper points out
> correctly that the "verifiably" part is weak.

And for me the reasoning from the BADA55 paper does not appear to be 
plausible.


>
> I'm relatively new, but my understanding is that Stephen is correctly
> pointing out that mandatory-to-implement anything is way out-of-scope here.
> We make suggestions, recommendations; downstream WGs in IETF decide whether
> they have rough consensus to adopt them, and then implementers decide
> whether they actually care to.

Where did I suggest to make anything mandatory? I searched all my postings 
for "mandatory" without finding that source.

> >As the cfrg  also discusses parameter lengths I would like to add that it
> > is completely adequate to use 384 bit curves even for highest security
> > demands.
>
> I agree, although there aren't any convenient special primes around that
> area. (I also think 256 is fine.)
>
> >So, 384 bit curves must be included in any proposed set of curves.
>
> Um, how does that follow? Do you propose just 256 and 384, then? Or...?
>
> Why is 384-bit a must? What's so magical about it? Why not 417? 448? 512?
> 521? 607? 31337?

You can see this statement as a direct answer to your own posting from 
September 14, where you stated "If it's optional, I definitely say drop 192 
from requirement SE6". There you did not write about 31337, did you?

To make it perfectly clear: If the group is going to only propose curves for 
two security-levels I'm opting for 128 and 192. 

Manfred



-- 
Lochter, Manfred
--------------------------------------------
Bundesamt für Sicherheit in der Informationstechnik (BSI)
Referat K21
Godesberger Allee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Telefon: +49 (0)228 99 9582 5643
Telefax: +49 (0)228 99 10 9582 5643
E-Mail: manfred.lochter@bsi.bund.de
Internet:
www.bsi.bund.de
www.bsi-fuer-buerger.de