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

Watson Ladd <watsonbladd@gmail.com> Mon, 20 October 2014 19:22 UTC

Return-Path: <watsonbladd@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 5CA9F1A9218 for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 12:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 25GzkhcNufN6 for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 12:22:48 -0700 (PDT)
Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF581AC3C3 for <cfrg@irtf.org>; Mon, 20 Oct 2014 12:22:47 -0700 (PDT)
Received: by mail-yh0-f45.google.com with SMTP id b6so3770212yha.18 for <cfrg@irtf.org>; Mon, 20 Oct 2014 12:22:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XFNTj//lnhTAitfhL6gPEV4hrmYcYTFiSRU8kTvEhWg=; b=H2E2vzOWR8Rb36dbLGbSlH4Z9S25Nz5OsNKBNUt98EZ1SlhHRkgMd3b4fFCEm8hOpU WTCVdlK4CPykwAxXUVvAnfoCyCzPH0KSItiWXB4U7TiNbGrE94lDznkxTwLHSFCJ4QMa xFBLFeC4/GaN+1qdhHBV3LhvvhrQ55hlqtvF+2mPoTe5iYdgIn/1abWKEKO2i9IMH8JN +eAhH54f0sfYy+CqIQPMb8WZ0Fv9Uhoh74JYTYCromEe423ADxkGJECNk+XhHk/DfmSw 7QfIObNtv4lu6JqjHZLqXxj/kHKI1uiXc04UCQKnteU2tL3cT/WnB+Tx16cXZVbelRBq SByA==
MIME-Version: 1.0
X-Received: by 10.236.22.37 with SMTP id s25mr6006575yhs.138.1413832966985; Mon, 20 Oct 2014 12:22:46 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 12:22:46 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 12:22:46 -0700 (PDT)
In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov>
References: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov>
Date: Mon, 20 Oct 2014 12:22:46 -0700
Message-ID: <CACsn0ckp_qvc0gzYbDR94hC4Gbf4iXW0g2b-UQ4vfy_NWPVMow@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Kevin M. Igoe" <kmigoe@nsa.gov>
Content-Type: multipart/alternative; boundary="e89a8f642b46c4e1640505dfa302"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BYCFtKSmna6MZKl0yPgWqGNVI9o
Cc: 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 19:22:55 -0000

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.

Thirdly, I recall more Z80 processors are produced today then in the days
of the microcomputer. Moore's law can be used to increase performance or
reduce price.

Interestingly, the NSA is no stranger to this issue. Suite B did not use
the highest security for everything, presumably for performance reasons. In
some cases the US Army uses very breakable ciphers, because the alternative
is no cipher and the material isn't that sensitive.  (If the message is
"Attack at dawn", decrypting at 9 am isn't terribly helpful to the enemy)

In conclusion performance still matters.

Sincerely,
Watson Ladd
>
>
>
>
>
> ----------------+--------------------------------------------------
>
> Kevin M. Igoe   | "We can't solve problems by using the same kind
>
>kmigoe@nsa.gov  | of thinking we used when we created them."
>
>                 |              - Albert Einstein -
>
> ----------------+--------------------------------------------------
>
>
>
>
> _______________________________________________
> Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg
>