Can I safely replace XOR with ADD in a stream cipher?

Question

In a stream cipher, the bytes of the plaintext are usually XORed with the keystream to produce the ciphertext. Would there be anything wrong with adding the bytes instead (with overflow), if adding happened to be faster than XORing on a particular system?

Answer 1

On software platforms, bytewise adding will not be faster than bitwise XORing. It may be a bit slower, though, also this will be negligible with regards to the process which generated the stream (and, for that matter, will probably also be negligible with regards to the memory bandwidth).

On hardware platforms (FPGA, dedicated ASIC), addition is slower than XOR because of the need to propagate carries. A XOR is a simple layer of XOR gates, so it has minimal depth and minimal area; an addition requires more gates (so more area) and carry propagation over $n$-bit words requires a circuit of depth at least $\log n$, so the addition will induce more latency as well. The overhead will be probably limited for mere bytes, but it will never be as efficient as a XOR.

The only kind of architecture where adding would be somewhat faster than XORing would be an architecture which offers addition/subtraction primitives, but not XOR, or not as efficiently. This may be the case for some DSP, or possibly for some Javascript interpreters (in Javascript, numbers are thinly-disguised IEEE 754 floating-point values, and bitwise operations entail conversions to and from integer types). I still think that for most platforms (including recent JIT-able Javascript interpreters), the XOR will not be slower than bytewise addition.

As for security, bytewise addition is as good as XOR. Indeed, XOR is bitwise addition (XOR is the addition in $\mathbb{Z}_2$).

Answer 2

You can use any invertible operation to apply the key stream to the plaintext for encryption (and use the inverse to apply the key stream to the ciphertext for decryption).

Addition/subtraction are such a pair, but you have to take care for the carry - either use it $\bmod 256$ (i.e. byte-wise), or use it $\bmod 2^n$ with $n$ some block size in bits. Make sure you use the same block size for encryption and decryption. (Use the block size that is native for your platform for optimal performance.)

It does not change anything about security, just the interoperability is more complicated (for XOR it does not matter how many bits you XOR at once, since there is no carry), and performance might differ.

Addition/subtraction might be preferable when your "blocks" are not multiples of whole bits (i.e. where you couldn't do XOR at all), but representable as numbers modulo some value. E.g. in many classical ciphers, which work on a small alphabet, we would have addition modulo 26.

Answer 3

consider you have a key $K$ and plaintext $P$.

then,

$P \oplus K = C$ (cipertext)

$C \oplus K = P$ (plaintext)

Here, algorithms for encryption and decryption are same (thats not true for addition). Also, $\oplus$ (X-OR) is faster than addition on most of the platforms. Additions generates carry forwards, X-OR operation does not.