IETF Logo Mail Archive

Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

Andrey Jivsov <crypto@brainhub.org> Wed, 09 April 2014 15:57 UTC

Return-Path: <crypto@brainhub.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B75E1A0389 for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 08:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level:
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 X7bQjG3_iTOt for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 08:57:38 -0700 (PDT)
Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id B2BF01A035C for <tls@ietf.org>; Wed, 9 Apr 2014 08:57:38 -0700 (PDT)
Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta01.emeryville.ca.mail.comcast.net with comcast id nqar1n0051Y3wxoA1rxePQ; Wed, 09 Apr 2014 15:57:38 +0000
Received: from [192.168.1.8] ([71.202.164.227]) by omta15.emeryville.ca.mail.comcast.net with comcast id nrxd1n0074uhcbK8brxdnZ; Wed, 09 Apr 2014 15:57:38 +0000
Message-ID: <53456DF1.7080904@brainhub.org>
Date: Wed, 09 Apr 2014 08:57:37 -0700
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <CACsn0cmFLO2n8d-FVVb4wu=G5T88E7rRd8b=eYo-1uMZnMxkOQ@mail.gmail.com> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> <CACsn0ckyaGO9hqn7pDVE2VR-TWs5v+Y6NsnCqCvrwFGyUGfZ3A@mail.gmail.com>
In-Reply-To: <CACsn0ckyaGO9hqn7pDVE2VR-TWs5v+Y6NsnCqCvrwFGyUGfZ3A@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397059058; bh=kgwDCrgdGBZX1DQ0PiqkwDwiHnpTkI6CSpczL9E5f+Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JDPzziaAJCyxqdOSc4EUGPgYglHsV1IWyEnYZBrzwLrCYRd6eZlyXDxfRKHr/moXw Dzi9lRfdLZdnUeQZo7nW77nbYXRVBpNHEp3yCUFdUtF+rTLkG9JA2al7VtncMPp9V9 KQm+k48/9RkjCAoQvJXAUjYuzDddAZ62ZIKwBTMdBTA5dlR7Mq+Hmv+zGJ3oVImxnk tAgSY6mzukGoRBscMYn7d8JojxcrO5jWjMpzZZHjUngTaDGBP1b5e4x4BwBRQ0pzzx gqnTWZLnoskN2KB5bzg4YylCLsetdlfJi+Zsgk205DIoRqzY2IyW/uIZ1jq8+b+dnY RCTSpm2EFvLjg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AIhWCiyUDBk0lS13MW2aUyqw8xg
Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2014 15:57:40 -0000

Re endianess,

shouldn't the decision here be based on the current distribution of 
little v.s. big endian architecture on CPUs that are likely used in TLS 
servers and accelerators?

( It doesn't matter much for end-clients, I suppose. One may argue that 
this doesn't matter for the rest either. But then the argument goes that 
the big endian is the traditional canonical representation. )

v2.23.0 | Report a Bug | By Email