Subject: [TLS] Include Speck block cipher?

From: Efthymios Iosifides <[email-masked]>
Date: Thu, 17 Mar 2016 08:35:42 +0200

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.

Thank you!

Yours sincerely,
Efthimios Iosifides

---

From: Mike Hamburg <[email-masked]>
Date: Thu, 17 Mar 2016 18:37:25 -0700

No.  The goal should be to remove ciphers, not add new ones, unless we have a really compelling reason.  Short source code is not a compelling reason in a protocol so complicated as TLS.

Cheers,
— Mike

> On Mar 16, 2016, at 11:35 PM, Efthymios Iosifides <[email-masked]> 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 <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. 
> 
> Thank you!
> 
> 
> Yours sincerely,
> Efthimios Iosifides 
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Mar 2016 01:40:08 +0000

There is no serious proposal to use Speck in TLS 1.3.  One major reason is that there is insufficient cryptanalysis of it.

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 17 Mar 2016 18:51:24 -0700

On Thu, Mar 17, 2016 at 6:37 PM, Mike Hamburg <[email-masked]> wrote:

> No.  The goal should be to remove ciphers, not add new ones, unless we
> have a really compelling reason.
>

+1

-- 
Tony Arcieri

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Mar 2016 13:09:04 +1100

On 18 March 2016 at 12:37, Mike Hamburg <[email-masked]> wrote:
> No.  The goal should be to remove ciphers, not add new ones, unless we have
> a really compelling reason.

A necessary, but sufficient set of reasons might include:

1. thorough cryptanalysis
2. advantages over existing ciphers on important metrics like security
and speed, though this would likely need to be significant at this
point
3. interest in implementation

Speck is 0 from 3.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Mar 2016 19:47:04 -0700

Piling on, I can't see why we would want to do this

-Ekr

---

From: Tom Ritter <[email-masked]>
Date: Fri, 18 Mar 2016 09:46:00 -0500

> 3. interest in implementation

I might make it .5 for 3. Speck is specifically designed to be a
lightweight cipher for constrained devices. With RC4 dead in the water
- we don't have one of those. (Unless ChaCha20 is better than
Speck/Simon/related...)

That said, we'd still need the other 2.5 - and no, I'm not supporting it either.

-tom

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 18 Mar 2016 18:49:18 +0100

Hi,

> On 17 Mar 2016, at 07:35, Efthymios Iosifides <[email-masked]> wrote:
> 
> Hello all.
> 
> It's reference is below :https://www.ietf.org/mail-archive/web/tls/current/msg13824.html
> 

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

---

From: Joachim Strömbergson <[email-masked]>
Date: Mon, 21 Mar 2016 09:21:39 +0100

Aloha!

Tom Ritter wrote:
>>> No.  The goal should be to remove ciphers, not add new ones,
>>> unless we have a really compelling reason.
>> 1. thorough cryptanalysis 2. advantages over existing ciphers on
>> important metrics like security and speed, though this would likely
>> need to be significant at this point 3. interest in implementation
>> 
>> Speck is 0 from 3.
> 
> lightweight cipher for constrained devices. With RC4 dead in the
> water - we don't have one of those. (Unless ChaCha20 is better than 
> Speck/Simon/related...)

ChaCha20 was not explicitly designed to be lightweight. That said, it is
fairly compact and get good performance on smaller architectures. Even
though the internal variables ate 64-bit, the ARX operations are easy to
map to smaller registers. The closely related Salsa20 cipher requires
about 5 cycles/byte on ARM:

https://www.hyperelliptic.org/tanja/vortraege/20121129.pdf

But if we wanted algorithms optimized for embedded, small architectures
we could look at the ECRYPT eSTREAM profile 2 ciphers:

http://www.ecrypt.eu.org/stream/

AFAIK they did get a fair amount of analysis.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          [email-masked]
========================================================================

---

From: Efthymios Iosifides <[email-masked]>
Date: Mon, 21 Mar 2016 16:07:22 +0200

>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 <[email-masked]>:

> 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
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Mar 2016 14:24:58 +0000

> other hand we shall evaluate if the SPECK could be actually used
> what about the future specifications
> what if we could prove that ..

Those are all great questions.  But in the current state of things, they are unanswered questions.

If someone wants to see SPECK adopted by IETF protocols, the first thing that will have to happen is papers analyzing it.

---

From: Sean Turner <[email-masked]>
Date: Mon, 21 Mar 2016 10:27:13 -0400

If we’re going to get into the cryptanalysis of SPECK then this thread should move off the TLS list and possibly to the CFRG list.

spt

> On Mar 21, 2016, at 10:07, Efthymios Iosifides <[email-masked]> wrote:
> 
> >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.
> 
> 
> 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
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 21 Mar 2016 17:07:04 +0000

Hi

I think Rich Salz already said exactly what CFRG would say:

> If someone wants to see SPECK adopted by IETF protocols, the first thing
>that will have to happen is papers analyzing it.

There's some analysis already, but not that much.

Regards,

Kenny 

On 21/03/2016 14:27, "TLS on behalf of Sean Turner" <[email-masked]
on behalf of [email-masked]> wrote:

>If we’re going to get into the cryptanalysis of SPECK then this thread
>should move off the TLS list and possibly to the CFRG list.
>
>spt
>
>> >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.
>> 
>> 
>> 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
>> 
>> > 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
>>

---

From: Joachim Strömbergson <[email-masked]>
Date: Tue, 22 Mar 2016 10:14:39 +0100

Aloha!

Efthymios Iosifides wrote:
> 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.

Hold on here. There is imho a fairly big difference of how AES came
about with an open competition compared to how Simon and Speck has been
developed. Yes, NSA was an important part in the selection of Rijndael
as AES. But that is not the same thing as they actually designed it. Right?

Also, there has been tens of ciphers proposed the last few years aiming
for the ultralight space. Some of them are as complex in terms of code
and data requirements as Speck and sports about the same performance.
See for example:

https://eprint.iacr.org/2013/295.pdf
http://www.ijsce.org/attachments/File/v3i5/E1933113513.pdf

Most of these are Feistel based and some of them uses S-boxes. But there
are really quite a few alternatives. And besides, as is shown in those
links AES can be implemented to not hog resources. The internal
operations operates on Bytes. The big issue is the S-box and the extra
space needed if you need to expand the key (which is only really needed
if you need to decrypt. If you use a good cipher mode, it i not needed.)

> performance than other algos without sacrificing the security.

Start by proving that.

Based on what is published I think it will be hard to show significant
gains with Speck compared to other ciphers. The two papers published so
far on the cryptanalysis does not give me a good warm feeling for long
term security of Speck.

And the last point is really the thing, right? We are talking about a
cipher for embedded stuff, Internet of Things devices. These things are
deployed and will be doing their chores for 20-30+ years without much
love and maintenance. The communication are typically low bandwidth and
with good delay resilience. So what is needed is something cheap
(compact in terms of resources) and good, well proven security. I don't
see Speck shining much brighter than others in this respect, on the
contrary in fact.

If you look at what MCUs are used for IoT today and moving forward it is
quite probably an ARM based device (Cortex M0, M0+ for example). AES can
be implemented very compact and give good performance on this
architecture. And even better, for well under 1 USD you can get an ARM
based MCU with AES in HW.

I fail to see why anyone would be interested in Speck and would never
recommend anyone to use it. But hey, write a draft and try to get an
informational RFC for it if it scratches your itch. There are several
other RFCs describing ciphers not being used very much.

- --