Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Fedor Brunner <> Tue, 01 July 2014 08:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F3BAA1A005E for <>; Tue, 1 Jul 2014 01:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.746
X-Spam-Status: No, score=-0.746 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, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ueM4hzgiV9Me for <>; Tue, 1 Jul 2014 01:36:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A73F71A001D for <>; Tue, 1 Jul 2014 01:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=azet; t=1404203808; bh=fB1NMV4vm7YTYvVI8oynwzgfSFEUvLx7TKfnx3Bvceo=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hTn1tbBKG28L0KllRGUEXqEiz9whg3amuHdthMwE0pumwaVyffisFpRZ3f3fW9AxB KQ70DL1UThMZj5TYX/gC16ARkis7BBT+QkWUMGvzlM3kOAMkWUGoI5JTM8lbnp/3Iy opR6zSWiFP7F06H4fjl7/pSPUyeOAmFnadt273kI=
X-Virus-Scanned: by AntiSpam at
Received: from [] (unknown []) (Authenticated sender: by (Postfix) with ESMTPA id 69AA47D for <>; Tue, 1 Jul 2014 10:36:40 +0200 (CEST)
X-SenderID: Sendmail Sender-ID Filter v1.0.0 69AA47D
Authentication-Results:; sender-id=fail (NotPermitted); auth=pass (PLAIN); spf=fail (NotPermitted)
Message-ID: <>
Date: Tue, 01 Jul 2014 10:36:37 +0200
From: Fedor Brunner <>
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Jul 2014 08:36:53 -0000

Hash: SHA512

On 30.06.2014 23:20, Michael StJohns wrote:
> On 6/30/2014 3:16 PM, Nigel Smart wrote:
>> What's the difference between defining a cryptographic protocol
>> (i.e. TLS 1.3) which could have lots of problems/be cracked/have
>> a back door; and defining a cryptographic algorithm which could
>> have lots of problems/be cracked/have a back door? Experience
>> shows us that defining cryptographic protocols (key
>> agreement/secure channels) is more prone to problems than
>> defining cryptographic primtives (AES, ECC).
> If the math is insecure then the cryptographic standard is insecure
> as is everything that depends on it.

Because some algorithms have been published as cryptographic standard
doesn't mean the algorithm is without a backdoor. For example:

1. ANSI X3.92, NIST SP 800-67 and ISO/IEC 18033-3, DES cipher
 The key was shortened to 56-bit

2. ANSI X9.82  NIST SP 800-90A, ISO/IEC 18031:2005, Dual_EC_DRBG

D.J.Bernstein writes: In the past decade NIST has been rushing so many
cryptographic standards out the door that the quality of review has
obviously been compromised.

Because of possible backdoors some companies are moving away from NIST
cryptographic standards

Also Adam Langley thinks that NIST continually pick algorithms that
aren't suited to software implementations.

> If the cryptographic standard is insecure then the cryptographic 
> protocols are insecure (but hopefully you can plug in something
> else - e.g. DES vs AES).
> If the cryptographic protocol is insecure then the applications
> are insecure (but hopefully you can plug in something else e.g.
> TLS1.0 vs TLS1.1 vs TLS1.2 vs ??).
> Oh yeah - if the implementation is insecure, it doesn't really
> matter whether or not you got everything else right.
> So the difference is really about what depends on the protocol vs
> the standard vs the math, and you get more dependencies the closer
> you are to the math.
> I tend to agree with you about the problems with defining crypto 
> protocols, but at least they are*protocols* which is somewhat
> within the IETF's scope of expertise.  They're also a lot easier
> for the non-crypto-math people to get their heads around.  Crafting
> a cryptographic protocol is still a specialty expertise though.  At
> least TLS13 will have *lots* of eyes on it.  Given the huge set of
> plugin cryptography in TLS, hopefully at least some of it will be
> secure enough.
> Mike
> _______________________________________________ TLS mailing list