

The SIMON and SPECK Families of Lightweight Block Ciphers - sweis
http://eprint.iacr.org/2013/404

======
andrewcooke
is it unusual to use "bitwise and" inside the feistel function? i thought that
normally xor or modular addition or shifts or permutations (nx1 s-boxes) were
used, which keep all the information (in some sense). "bitwise and" isn't like
that (i don't have the right word for this distinction, sorry. maybe
"invertible" is the word?) but is used here. anyone know why? or is this a
distinction i've invented that has no basis in fact?

obviously it doesn't matter (decryption still works) as long as it's inside
the feistel function itself. so i guess maybe i am just muddling that with how
things must be outside that?

~~~
pbsd
There are 2 separate aspects here: AND (the instruction itself) and
invertibility.

Indirectly, every decent round function ever created has had AND. At the bit
level, you can't have a nonlinear function without AND. The carry bit in
additions, for example, is given by a_i&b_i ^ a_i&cin ^ b_i&cin. Using AND
directly, though, is pretty rare though not unheard of, since as CPU
instructions go AND is doing relatively little work compared to more powerful
instructions such as ADD, SUB, MUL, or table lookups. You see AND, though not
bitwise, a lot more in hardware-friendly designs that employ NLFSRs as
primitives.

As for invertibility, in Feistel ciphers it is not really a requirement, as
you point out, f only really needs to be a PRF. That being said, I have heard
the argument that making f invertible does preserve information before; I do
not know where this argument comes from, and as far as I know it's not
formalized anywhere. DES and Blowfish are Feistel ciphers without invertible
f, and don't have that bad of a security record.

~~~
andrewcooke
i was just thinking about this in the shower and came up with this handwaving
justification:

if you have two random values, using AND biases the number of set bits on
average (you get 3/4 zeroes in the output). in other words, it lowers the
(shannon) entropy in the circuit, on average, while an invertible function
preserves entropy (it has to, right?).

entropy sounds like a smart thing to preserve in a PRF so this would seem like
an argument for invertibility.

BUT it's only preserving entropy on average, and what you really care about is
the entropy in the difference between input and ouptut in any single round.
which is not the same thing at all (identity function is great for the former,
not so good for the latter). so you could imagine there's some trade-off...

forgive me if this makes no sense. it just seemed interesting when i thought
of it :o)

------
jlgreco
What are some other examples of "lightweight" block ciphers? Is AES considered
lightweight, or are these far "lighter"?

~~~
pbsd
They're a dime a dozen these days. Incomplete list, block ciphers only: HIGHT
[1], PRESENT [2], KLEIN [3], PRINTcipher [4], KATAN [5], TWINE [6], LED [7],
PRINCE [8], Piccolo [9].

AES is generally known to be doable in around 2500 gates, or gate-equivalents.
These lightweight ciphers aim lower, towards the 1000 or so.

[1]
[http://www.iacr.org/cryptodb/archive/2006/CHES/04/04.pdf](http://www.iacr.org/cryptodb/archive/2006/CHES/04/04.pdf)

[2]
[http://homes.esat.kuleuven.be/~abogdano/papers/present_ches0...](http://homes.esat.kuleuven.be/~abogdano/papers/present_ches07.pdf)

[3]
[http://doc.utwente.nl/73129/1/The_KLEIN_Block_Cipher.pdf](http://doc.utwente.nl/73129/1/The_KLEIN_Block_Cipher.pdf)

[4]
[http://www.iacr.org/archive/ches2010/62250016/62250016.pdf](http://www.iacr.org/archive/ches2010/62250016/62250016.pdf)

[5]
[http://www.cs.technion.ac.il/~orrd/KATAN/CHES2009.pdf](http://www.cs.technion.ac.il/~orrd/KATAN/CHES2009.pdf)

[6]
[http://www.nec.co.jp/rd/media/code/research/images/twine_LC1...](http://www.nec.co.jp/rd/media/code/research/images/twine_LC11.pdf)

[7] [http://eprint.iacr.org/2012/600.pdf](http://eprint.iacr.org/2012/600.pdf)

[8] [http://eprint.iacr.org/2012/529.pdf](http://eprint.iacr.org/2012/529.pdf)

[9]
[http://link.springer.com/chapter/10.1007%2F978-3-642-23951-9...](http://link.springer.com/chapter/10.1007%2F978-3-642-23951-9_23)

~~~
tptacek
Do you see anything interesting in the design of SIMON? Apart from how
parsimonious it is with mathematical operations.

~~~
pbsd
The design looks very elegant, and they manage to avoid using sboxes at all,
departing from most known lightweight ciphers. It also has decent performance
in 64-bit hardware, without having to recur to bitslicing, which is nice.

The whole round has algebraic degree 2, like Keccak, which makes things easier
to analyze when it comes to differential and linear cryptanalysis. Hard to say
much more at this point.

~~~
e3pi
Elegance and speed optimization is inconsequential for any non-real time, sub-
TB? sub-GB file size. Or, what am I missing?

~~~
tptacek
The point of the design, which is intended for microcontrollers, not your
desktop.

------
dfc
For a more accessible introduction to SIMON and SPECK take a look at this IETF
mailing list message[1] especially the video with introduction by the NSA
developers:

 _" Today at the MIT Media Lab Legal Hack-a-thon on Identity we had a great
presentation from a couple of designers from the NSA regarding their new
lightweight ciphers called SIMON and SPECK. These ciphers are designed for
low-power limited gate devices (such as RFID and similar devices).

The MIT Media Lab Hack-a-thon page is here:
[http://iauth.org](http://iauth.org)

The NSA presentation is here (You Tube):
[https://www.youtube.com/watch?v=vtyo4nWGBwk](https://www.youtube.com/watch?v=vtyo4nWGBwk)

Their paper (PDF) is here: [http://iauth.org/legal-hack-a-
thon/simonspeckperformance-2/](http://iauth.org/legal-hack-a-
thon/simonspeckperformance-2/) "_

Note: I changed the youtube video from a tinyurl link to the actual link. If
you want to tell tinyurl that you visited the youtube video click here:
[http://tinyurl.com/bf6fbju](http://tinyurl.com/bf6fbju)

[1] [https://www.ietf.org/mail-
archive/web/cfrg/current/msg03274....](https://www.ietf.org/mail-
archive/web/cfrg/current/msg03274.html)

------
oleganza
Recent events raised never ending question of "could the government place a
backdoor in DES/AES/SHA/etc.?"

My personal perception (based on available evidence) is that government crypto
is as strong as possible, but is weakened where needed via policies. A decade
ago during crypto export limitation, there were no backdoors, but a _policy_ :
you may export only keys _that long_ [so we can bruteforce them cheaper].

Another example: SSL is technically secure, but its biggest weakness is trust
in a limited list of certificate authorities (CAs) like VeriSign. Then, there
is _policy_ that certificate authorities should give up their private keys
when FBI/CIA asks for them.

Another example: you may encrypt your files, but must give away your password
to a court.

Also, it makes sense economically. Government people need strong crypto like
everyone else and the best way to test and verify it is by opening it up and
deploying as widely as possible. So mistakes are noticed sooner than later.
Then, people with guns will make sure you give up your secrets when they need
you to.

I believe crypto systems are alright. It is policies and violent coercion we
should be afraid of.

~~~
doe88
However it seems to me that to this day there is no proof they intentionally
tried to weaken a standardized crypto algorithm, they seem to have instead
relied in the past on imposing reduced sizes of keys. But even that seems to
have changed nowadays, AES 256 bits despite all the scrutiny seems to still be
a safe choice. Of course, I don't know what are their plans concerning crypto
but the backlash will be huge if it appeared they rigged an algorithm. Of
course, if they happened to honestly find a significant flaw or make a
breakthrough in quantum computing for instance I doubt they would tell the
public either.

------
csense
It's ironic that the PDF download is called 404.pdf. When I saw the name, I
thought the link was broken and their error page was a PDF.

------
vertis
I must be paranoid now. My first reaction was "It's a trap!".

~~~
csense
People have had that reaction to NSA-endorsed cryptosystems ever since they
withheld the derivation of the DES S-boxes for a number of years. Wikipedia
states [1]:

"The 8 S-Boxes of DES were the subject of intense study for many years out of
a concern that a backdoor -- a vulnerability known only to its designers --
might have been planted in the cipher. The S-Box design criteria were
eventually published (in Coppersmith 1994) after the public rediscovery of
differential cryptanalysis, showing that they had been carefully tuned to
increase resistance against this specific attack."

[1]
[http://en.wikipedia.org/wiki/Substitution_box](http://en.wikipedia.org/wiki/Substitution_box)

~~~
vertis
I was too young to be a participant, however I do remember reading about all
the happenings around crypto in the 80s and 90s.

It's healthy to suspect crypto systems because of their role in protecting us.

