Speck with signed math

Question

I find myself implementing Speck in an industrial controller that only does signed math.

What cryptographic ramifications would there be if the Speck algorithm was implemented using signed math?

Answer 1

There are a number of things to watch due to signed arithmetic:

• If the hardware was not using 2's complement arithmetic (representing range $[-2^{k-1},2^{k-1})$ on a $k$-bit word, with negative integer $x$ represented as $x+2^k$ is in binary), then it would be difficult to use the full word width $k$. It would then likely be a better idea to keep everything non-negative and less than $2^{k-2}$.
  That is easy for Speck-$n$ (where $n$ is the block width) when $k\ge n/2-2$. E.g. for Speck-32, $k\ge18$ allows to compute $(x+y)\bmod 2^{16}$, as required, using (x+y)&0xFFFF, without depending on the representation of negative numbers.
  Or, another option is using multiple-word arithmetic. That's what a compiler does on an 8-bit CPU to implement wider arithmetic types, and how large integers are usually implemented in asymmetric cryptography. It reduces speed and increases code size by a factor like 3 when going from one to two native words, thus is best avoided.
  Fortunately, 2's complement arithmetic is common. That would make Speck-$n$ with $k=n/2$ feasible without multiple-word arithmetic, baring the next issue.
• Some industrial controllers detect overflow (e.g. when $2^{k-2}+2^{k-2}$ is attempted). When using words to their full width, overflow will occur often, and its detection should be disabled. An alternative is to avoid overflow by keeping everything non-negative and less than $2^{k-2}$ as above.
• Speck requires rotation by constants, often implemented with a combination of left and right shift followed by bitwise OR, e.g. For Speck-32 (x>>13)|(x<<3). Right shift by $b$ positions on signed variables sometime replicates the sign bit $b$ times rather than introduce $b$ zero bits. That would require extra masking, e.g. ((x>>13)&7)|(x<<3). With $k>16$ make that ((x>>13)&7)|((x&7)<<3) when needing to avoid negatives and overflow.

To watch also, but not directly related to signed arithmetic:

• Speck is a block cipher, thus needs an operating mode to become a cipher, and for more than a single use a True Random Number Generator to generate its IV (or at least persistent storage for a counter), before it can be used to encrypt arbitrary data.
• Most of the time, when encryption is thought, integrity/proof of origin is functionally needed also (sometime, only). That's authenticated encryption, and while it can be implemented with a block cipher, there are a few catches.
• Industrial controllers need to be reliable, not fast. Speed might be an issue, especially if multiple-word arithmetic has to be used due to signed arithmetic.
• For security, the implementation should have execution time independent of data if an adversary can time execution (which should be the default assumption), and a number of things (like overflow detection, and more) could introduce timing dependencies.
• Industrial controllers are usually not designed to keep secret the data they manipulate; I've met one (emulating relay logic) that blinked a led according to the state of its (one-bit wide) data register! And there could be much more subtle side-channels.

Answer 2

As long as the signed arithmetic your microcontroller implements is two's complement, I see no significant implementation issues.

Speck is an add-rotate-XOR (ARX) cipher: at the bit level, signed two's complement addition is identical to unsigned addition, and rotation and XOR are the same anyway. You may have to do some extra masking to implement rotation if you only have sign-preserving right shift available.

In any case, as long as you implement the algorithm correctly, it will (by definition) produce the same output as any other correct implementation of Speck (modulo some unfortunate endianness issues in the original Speck specification). So whatever you end up doing "under the hood" to implement the cipher can only have cryptographic ramifications if those implementation details somehow become observable through some side channel such as execution timing or power analysis.

While specific methods of hardening your implementation against side-channel attacks are kind of outside the scope of this answer, you should be aware that they exist. (We even have a whole side-channel-attack tag here for them.) Just looking at the instruction timings for your microcontroller, and avoiding instructions with data-dependent timing (as well as things like conditional jumps that depend on sensitive data) is a good start.