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

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 20 October 2014 20:38 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 72D091ACE53 for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 13:38:18 -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 l5CWTHbKHmTW for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 13:38:17 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0CE1ACE41 for <cfrg@irtf.org>; Mon, 20 Oct 2014 13:38:16 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id w7so4598029lbi.36 for <cfrg@irtf.org>; Mon, 20 Oct 2014 13:38:14 -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=yQBD/f3c1J0fEIERxt911y1QLdRDyLGG64dWaKytM9I=; b=P8g8Zkpuv/tEgbYopY8gxpuzkdF8ip22huMhvKNAlp4aaclX6UNDPzYZzugbrMxb1h b1Oa9zFbJ5TUak9YXXrbjmns6vG3DvmWaWI/V6aUtfHVZAlOXCQZ4bau044zTP46gGn+ 25GQ/EgtUCUUl9kPbgBZ0UyOsVEpBgx3LKWcACy7/NLdBuvA1N5RJOzS8rFgZbxmNHMR ZcJ2rc+ut4cCwhA1+a3hmm6poDti7PESKRHol2hfAHgcZvSnxy3V7U2QkceqO6k/w5SH PPwizYsqnz4CUhsBfD+UsyT75uqenkxtZgiYIPsDLT5W3xyZClz680CLtkKuxEMQBOi2 rOZA==
MIME-Version: 1.0
X-Received: by 10.112.134.39 with SMTP id ph7mr29963630lbb.45.1413837494740; Mon, 20 Oct 2014 13:38:14 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.66.196 with HTTP; Mon, 20 Oct 2014 13:38:14 -0700 (PDT)
In-Reply-To: <CAA7UWsVL1bcXqAEjPHBB7Z0wg8Vb55wtWxbRJB_V4NfV3mfmVg@mail.gmail.com>
References: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov> <CACsn0ckp_qvc0gzYbDR94hC4Gbf4iXW0g2b-UQ4vfy_NWPVMow@mail.gmail.com> <CAA7UWsVL1bcXqAEjPHBB7Z0wg8Vb55wtWxbRJB_V4NfV3mfmVg@mail.gmail.com>
Date: Mon, 20 Oct 2014 16:38:14 -0400
X-Google-Sender-Auth: DSOvaseijpFsEfL8FJc27_-zc88
Message-ID: <CAMm+LwgiAaheQbuGjc=omto8FF8uh+Y08Su7p=Lt1MVcDAgyeg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: David Leon Gil <coruus@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b344184a4eec20505e0b161
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/MO0KUVr1C9xjChao8MehHXNeEjQ
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:38:18 -0000

I don't understand the constraint suggested.

In practice the performance of public key is not particularly critical. If
you want really fast then use symmetric key. The only time that you ever
need public key is to establish a trust relationship. Other than the Web,
which is a far outlier, what synchronous protocol do we have where
negotiating keys synchronously is a hard requirement?

Certainly not email, nor chat. And if we get into money then we can solve
problems by spending our way out.

On Mon, Oct 20, 2014 at 4:32 PM, David Leon Gil <coruus@gmail.com> wrote:

> On Mon, Oct 20, 2014 at 3:22 PM, Watson Ladd <watsonbladd@gmail.com>
> wrote:
> > 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
>
> What organization has strained and strained to get more performance out
> of Ed448? Or Curve25519, for that matter?
>
> On Mon, Oct 20, 2014 at 2:37 PM, 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 [ . . . ]
>
> Proposal: Pick curve bit-length based on a fixed latency budget; say, 1 ms.
> Each semiconductor node, increase bit-length as much as necessary to
> keep latency the same.
>
> Security is asymptotically guaranteed.
>
> The CFRG could start by recommending a curve over Fq(2^4062-17), rather
> than
> any of this nonsense about Fq(2^414-17) etc.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>