Re: [TLS] Include Speck block cipher?

[Joachim Strömbergson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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


> On top to that what if we could prove that the SPECK can have better
> 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.

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

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          [e-mail]
========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJW8Qz+AAoJEF3cfFQkIuyN2eoQAK85EwmpLc2iqAMkA/I2ogB+
DsCvYl7ZxwpBgWzTfHSeVwccclC0FwcGvPIvCegAU5Barv58Mc5L+7mLnJ1hn8LR
qTfQYz9yXyipn/6L0PDca2gpoSi/QqbJtlBRWfNYdmaqb1K8X5A8qgljtJMHNDEP
eSHgmLFKLVpJFQbp2aGlqSwysEwaseTvLWfbWLBeA6itBivwxm2LtN1GT9ZTHlD9
/NfZockKF3bLOYaachtS84tIA8CKUhmRvf2/5e1MVDEZ53JivoSNZuNAjeMAlCED
NMG6IfsKrEWisQaBliUaE3OzGxh2y1AGpw72/Fx2MmduaroR4nhiYWnMfvk2PRue
ALEx0qFmBqverSTK78NzseGQBGu+iER7mQl2wK7d+1NDoNTNiijqB4aYNZeGwRc9
IeeVIKo/qTbZBH5qoI5nQRKsCdvsN36Sw7kSy1oCw5NMBMQBnk9vOZeAna7TUMas
jnAF1ReH3dc2XeKJ9GdomZk60eHambIQBrPVlkziXcfECQo9CtXHK/OvYtGDHCmr
Owb5ftgqojWKZdp+IA0hHWQe01x1nwrwE95G2VtWfN+ZqpSTcE21GBDRRL6TcogQ
gfRMfcSMrggSE3BH/i+Bmaloee9vvo13t1SS7YpxJjjMZgCtngaWbtgS8xlcf0TQ
ioZfyFBxQMckohswjyWp
=s6MB
-----END PGP SIGNATURE-----