Re: [TLS] Include Speck block cipher?

Efthymios Iosifides <iosifidise@gmail.com> Mon, 21 March 2016 14:07 UTC

Return-Path: <iosifidise@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E15312D84E for <tls@ietfa.amsl.com>; Mon, 21 Mar 2016 07:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 u8syNqIoszPB for <tls@ietfa.amsl.com>; Mon, 21 Mar 2016 07:07:23 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A852712D844 for <tls@ietf.org>; Mon, 21 Mar 2016 07:07:23 -0700 (PDT)
Received: by mail-ob0-x233.google.com with SMTP id ts10so175415781obc.1 for <tls@ietf.org>; Mon, 21 Mar 2016 07:07:23 -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; bh=YcwuiaKNaCeHwut0dyMBayUPvRU3K6HbJCAyS+Dobgc=; b=M6alz7brmzEQEsPi/Nu5Hrgf0MttEJW+jTf7qcKr2A/xzSWfSna3vCFw2TLe/YeN61 xwzMyWXM0N2r7pSbcdSeBqki2uK8APyUrxL2p2ioXoEnY8LNQjlJM8F9l4Ep4LxiylkJ s7Smtm6HA/uYweJwg2tAi6Jp7YoRcZdbECP2Fm9L2HSiai0j0gowwtr/XAhQRHCLlA8J k7BhkpITFQ3d7UkA8bi27haBDdGszDjgkSjwBpSlbSitvmIcob0q9Tw24b/FbZnZoBVo fVp9PB1TuXQnhfpkUpswKj3Lry/+naxuyEKuh851T/2qYjhI5C4QUtFKL3kWs50Lxzpl MOgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YcwuiaKNaCeHwut0dyMBayUPvRU3K6HbJCAyS+Dobgc=; b=YBkB/dY8AY4bA89eUkWTzdrKNw+xaJTHacEi9qMSYyqRES18shcUmRpzGojcPECiXs l9AZiWHE/Nd1pkiuB2TF7SJBagJ/zCe0pdCKLQYHC3DCY/9pNqAA9YwzzqAIMewM/0s4 vS6wN8xxOaQ7x/dnAP3yp/R9OxX5TWXAwzC5plCT6r4JPzCnefYGLOFyOfqKs83ooSc0 R+y4cAQ3AaAtrgggA8QN70saYONKKzTUDhrZMhWrqAhooHTbBUWtVwbAOxF+/LfNW5Lv vn9Q6YXIijya2HA529DlkrFRZ0D4ghJne9fpiIPKNiv5QM91QjbJxVtUm7ly3Rhm9WuD fsNw==
X-Gm-Message-State: AD7BkJIeHY14EiSMF+fsdsnl4j7i7rPWnQmOPTi82DaUuTc/lhe4hA6lIaE24Fti2fH3RG3FkjEwl+K99rni7A==
MIME-Version: 1.0
X-Received: by 10.182.158.42 with SMTP id wr10mr17080431obb.37.1458569243014; Mon, 21 Mar 2016 07:07:23 -0700 (PDT)
Received: by 10.157.3.4 with HTTP; Mon, 21 Mar 2016 07:07:22 -0700 (PDT)
In-Reply-To: <690C4271-64DE-4F61-8283-C5BE7A575BFC@azet.org>
References: <CADBJ=uRVC_2ttFXcdgTRamQkrL=EL3hJ7z1xmTGcW_dX01FhZw@mail.gmail.com> <690C4271-64DE-4F61-8283-C5BE7A575BFC@azet.org>
Date: Mon, 21 Mar 2016 16:07:22 +0200
Message-ID: <CADBJ=uR0=Kj-68yojXYyqfKJoEncOXV1c-ia3=Az7s_7WqyWYQ@mail.gmail.com>
From: Efthymios Iosifides <iosifidise@gmail.com>
To: Aaron Zauner <azet@azet.org>
Content-Type: multipart/alternative; boundary="089e01537ea29c3fdd052e8f9d3c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0MaySfzA85nLmegzqxe9tEfAnuA>
X-Mailman-Approved-At: Mon, 21 Mar 2016 07:22:24 -0700
Cc: klimn@di.uoa.gr, tls@ietf.org
Subject: Re: [TLS] Include Speck block cipher?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 21 Mar 2016 14:07:25 -0000

>I don't see any compelling argument for the inclusion of SPECK? Not only
would the affiliation with NSA give the >TLS-WG a bad rep. in the public,
more importantly, it makes one of our main problems worse: combinatorial
explosion >of possible cipher-suites in TLS. This problem is so bad that it
needs multiple blog posts, an effort by Mozilla and >bettercrypto.org
<http://bettercrypto.org> to get sys-admins to configure their services.


Hi all.

The reputation aspect is not necessarily and strictly correlated with it's
provenance, but with it's actual security and performance. And the SPECK we
shall note that performs quite well. Also we shall not forget that even the
infamous AES has been approved by the NSA before the widespread use of it.
In any case i wouldn't like for us to stand on the popular press. On the
other hand we shall evaluate if the SPECK could be actually used. For
example, the fact that it lacks extensive cryptanalysis is a serious
argument for not using it today, but what about the future specifications.
On top to that what if we could prove that the SPECK can have better
performance than other algos without sacrificing the security.


BRs,
Efthimios Iosifides

2016-03-18 19:49 GMT+02:00 Aaron Zauner <azet@azet.org>:

> Hi,
>
> > On 17 Mar 2016, at 07:35, Efthymios Iosifides <iosifidise@gmail.com>
> wrote:
> >
> > Hello all.
> >
> > I have just found on the ietf archives an email discussion about the
> inclusion of the SPECK Cipher
> > in the tls standards.
> > It's reference is below :
> https://www.ietf.org/mail-archive/web/tls/current/msg13824.html
> >
> > Even though that this cipher originates from the NSA one cannot find a
> whitepaper that describes it's full cryptanalysis. In the above discussion
> Mr. Strömbergson somehow perfunctorily presents two whitepapers that
> describe the SPECK's cryptanalysis. Although we shall keep in mind that
> these papers describe a limited round cryptanalysis. Also we shall not
> forget that a similar cryptanalysis has taken place for the famous AES.
> Therefore i personally do not see any actual arguments apart from the facts
> that concerns the algorithm's  provenance for not including it in a future
> tls specification. In conclusion even by this day the SPECK cipher has not
> been yet fully cryptanalyzed succesfully.
>
> I don't see any compelling argument for the inclusion of SPECK? Not only
> would the affiliation with NSA give the TLS-WG a bad rep. in the public,
> more importantly, it makes one of our main problems worse: combinatorial
> explosion of possible cipher-suites in TLS. This problem is so bad that it
> needs multiple blog posts, an effort by Mozilla and bettercrypto.org to
> get sys-admins to configure their services.
>
> Aaron
>