Re: [Cfrg] When in doubt, err on the side of security

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 20 October 2014 20:01 UTC

Return-Path: <hallam@gmail.com>
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 F28981ACDB0 for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 13:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 iHkx8nLAZxUt for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 13:01:48 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE471ACDA9 for <cfrg@irtf.org>; Mon, 20 Oct 2014 13:01:47 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id w7so4500233lbi.23 for <cfrg@irtf.org>; Mon, 20 Oct 2014 13:01:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h4ZU6YmVgYCbfrgLD22lNjlcD0ubDax6RjptSLM4/cI=; b=ZwYm31pbIH55H1IkIx+ORL/CXD8uXUesT9+xiwzBjvsCUgFLt3/DTqi1sD/tCIutsD iwZ/9dslgkvwO/biRyt/dL8Pv7OGng7y4V3LC26p7852/Cp0ghC81qARxx1KJ9d2NGBH DVgdejVbu6qXJkaMetobOZgOK9OfYQ0ddXuKL+70NfyyALhiHwglx2zbz01tNkeqgbyD HZCRNAkIK3Keg/R3lozXnIuxuXzOJ5n7SRB80JW/jzQGPH2uNuX+uw8afqt757QEDMFi z+l1K34ywfxxwq2ORg08nGD4OTyJyAokG8SXBzwc5jQUOXPBcDAWIwyZYwoXzA3sste0 D3oA==
MIME-Version: 1.0
X-Received: by 10.112.221.226 with SMTP id qh2mr30004533lbc.5.1413835304556; Mon, 20 Oct 2014 13:01:44 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.66.196 with HTTP; Mon, 20 Oct 2014 13:01:44 -0700 (PDT)
In-Reply-To: <CACsn0ckp_qvc0gzYbDR94hC4Gbf4iXW0g2b-UQ4vfy_NWPVMow@mail.gmail.com>
References: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov> <CACsn0ckp_qvc0gzYbDR94hC4Gbf4iXW0g2b-UQ4vfy_NWPVMow@mail.gmail.com>
Date: Mon, 20 Oct 2014 16:01:44 -0400
X-Google-Sender-Auth: P3Rs1PC7V0P9IxLGPs_tMTuzqaE
Message-ID: <CAMm+LwhaCfGysKYS-PRjx9rrFvwex5uhgc_9smCHEd+tVZZ7+A@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="001a1135ecb81960330505e02ff6"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/YJNDAyjdqGkPjcR2y24hJodCBaQ
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] When in doubt, err on the side of security
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: Mon, 20 Oct 2014 20:01:51 -0000

On Mon, Oct 20, 2014 at 3:22 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

>
> On Oct 20, 2014 11:37 AM, "Igoe, Kevin M." <kmigoe@nsa.gov> wrote:
> >
> > Once a security primitive has been selected, Moore’s law will naturally
> improve its
> >
> > performance with the passage of time.   But Moore’s law and advances in
> >
> > cryptanalysis will only erode its security (measured in the money needed
> to run
> >
> > the attack).  Bottom line: err on the side of security.
>
> Truisms like that are rarely helpful, and this is no exception. First,
> Moores law amplifies, not erases, performance issuses: users want to do
> more with cheaper crypto. How much this matters is an economic question.
> Sadly we've already ruled out the fastest options for somewhat decent
> reasons, as a glance at eBATS will show.
>
> The second issue is that the choice between performance and security is
> made worse by the absence of intermediate options. An organization that
> strained and strained to get adequate performance out of ed448goldilocks
> isn't made more secure by a standard only offering a 521 bit and 256 bit
> curve, as they will reduce security to get adequate performance. The
> tradeoff doesn't need to be that extreme for this to happen.
>
> I haven't seen good arguments for approving two curves at the far ends of
> the performance scale, instead of picking inflection points where a small
> increase in time yields a large increase in security. What I've seen is
> arguments that ignore the revealed preferences of users.
>

We didn't. We picked one point that was comfortably above being broken
using any current or future computer or network of computers built using
conventional computing gates using known algorithms. Then we picked another
point that gave roughly the square of the work factor of the first.

There is no security/performance tradeoff above the ~256 bit level. The
point of going for those extra bits is to put the question beyond any
feasible doubt.

So this argument would make sense if we were talking about something faster
than Curve25519. But I don't think anyone is.