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

Fedor Brunner <fedor.brunner@azet.sk> Tue, 01 July 2014 08:36 UTC

Return-Path: <fedor.brunner@azet.sk>
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 F3BAA1A005E for <tls@ietfa.amsl.com>; Tue, 1 Jul 2014 01:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.746
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueM4hzgiV9Me for <tls@ietfa.amsl.com>; Tue, 1 Jul 2014 01:36:51 -0700 (PDT)
Received: from smtp-01-out.s.azet.sk (smtp-06-out.s.azet.sk [91.235.53.31]) by ietfa.amsl.com (Postfix) with ESMTP id A73F71A001D for <tls@ietf.org>; Tue, 1 Jul 2014 01:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; 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 azet.sk
Received: from [0.0.0.0] (unknown [77.109.139.87]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 69AA47D for <tls@ietf.org>; Tue, 1 Jul 2014 10:36:40 +0200 (CEST)
X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 69AA47D
Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk
Message-ID: <53B27315.4010407@azet.sk>
Date: Tue, 01 Jul 2014 10:36:37 +0200
From: Fedor Brunner <fedor.brunner@azet.sk>
MIME-Version: 1.0
To: tls@ietf.org
References: <53B1B77C.2060201@cs.bris.ac.uk> <53B1D49D.10404@nthpermutation.com>
In-Reply-To: <53B1D49D.10404@nthpermutation.com>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/np9bkiNh5Kr6t2cql04QohljvbI
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
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: Tue, 01 Jul 2014 08:36:53 -0000

-----BEGIN PGP SIGNED MESSAGE-----
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
https://web.archive.org/web/20140423082937/http://cryptome.org/0001/nsa-meyer.htm

2. ANSI X9.82  NIST SP 800-90A, ISO/IEC 18031:2005, Dual_EC_DRBG
https://projectbullrun.org/dual-ec/vulnerability.html
https://eprint.iacr.org/2006/117

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.
http://blog.cr.yp.to/20140411-nist.html

Because of possible backdoors some companies are moving away from NIST
cryptographic standards
https://blog.silentcircle.com/nncs/

Also Adam Langley thinks that NIST continually pick algorithms that
aren't suited to software implementations.
https://www.imperialviolet.org/2012/10/21/nist.html

> 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 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 


-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTsnMVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2
RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOtXMIQAKD9hmWHVflit4tAukqaJ9tz
FHUoTAThAwnf1DxjkacVfddiX7Q42DUAsPruadc1xmdiux35foz9oGFLo1rVqLNZ
XFCvoMzkLK9IvXyf/RiE4vtfXBQSx+bgKLQlRa/TlkC5vqC0U8NMgiSqT41M6xd3
u5ar2O0S9VrEFLXzxPwIQEphn9x+ixu2gJAsu0c7EWshpY1M0a8acSSxk1AQqRJm
KmN+TIYMsOpnJShTmulB5EoHoszEzH1bfzFl5wcK15RFPEhsWf2Bps0q+V1E5mX3
RWIyT2Xctbj6ISMcpbd7sAh3eC9Sdf8pmDzhBd5qvwzMPip+tkIbQsH0BZYdfvCb
PaXj3LqeXIpQVMYDdjIR9M77AmREkw0JucZXBpeY4ncOYESu/JvgiOwJW1cmhgaq
DsSJFBDBsTB6yPpCfrOHaIB0hKZ81qBAAJihE15E3pBTI9FDExnOYMXCUHtjJIfH
qNLLmHcjAjceTcUSrwzdOoHfVO0mWRqd8tmuGaQNiK1o4AmThzXM5HuPoRZwZJqN
a63tvtaNl2DQGjBhk+26YhsrzzOLo4QZpDay6+3mUSvXEKcp2497Ng9lRztjsVh6
ZJbPGn8SKCTg166xrH2FQdfJ0Ay4BVDWZavPPxVIFA2HAiqf8WpieuaicuaRf5df
wERmz00efrw6ar4+9rMp
=Rmfy
-----END PGP SIGNATURE-----