Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
Could somebody explain what is the difference between "word-based" stream ciphers and the regular ones? Those last ones use pseudo-random sequences XOR'd bit by bit with the message, as far as I know. How does that change when it comes to "word-based" ciphers?
Examples of word based keystream ciphers include SNOW, PANAMA, SOBER, ORYX. I also read that word based keystream ciphers "allow greater efficiency in software than most bit based stream-ciphers".
A word-based stream-cipher produces the pseudo-random sequence one word (of several bits) at a time. For example RC4 is a word-based stream cipher, with the word size a byte. By contrast, a typical bit-based stream cipher such as one using the ASG produces the pseudo-random sequence one bit at a time.
Word-based stream ciphers may be better suited to fast software implementations than are bit-based stream ciphers, since CPUs typically process one word no slower than one bit.
As D.W. notes, the distinction made between "bit-based" and "word-based" stream ciphers in the source you cite is irrelevant to the end-user. For both kinds of stream ciphers (as well as for block ciphers in streaming modes like CTR or OFB), the manner in which the keystream is combined with the plaintext is always the same: bitwise XOR, which operates at the bit level but is easily parallelized both in hardware and in software.
In any case, the actual distinction they seem to be making is between LFSR-based stream ciphers, which sequentially output one bit per iteration, and ciphers such as RC4 (and, presumably, block ciphers in streaming modes) which generate their output bitstream in larger chunks.
LFSR-based stream ciphers have generally been designed for direct hardware implementation, where they have the advantage of simplicity, but they've traditionally suffered from poor performance in software; whereas in hardware it's easy to shuffle single bits around and combine them using simple logic gates, typical CPUs are designed for carrying out higher-level operations on chunks of 8, 16, 32, 64 or 128 bits in parallel. Running a cipher that operates on single bits in software thus wastes most of the CPU's power, unless the algorithm can be reformulated to operate on many bits in parallel, something that many older LFSR-based cipher designs haven't been very well suited for.
On the other hand, ciphers like RC4 were designed for software implementation from the beginning, and do very well there. (Although RC4 itself operates on 8-bit bytes, which is arguably suboptimal for modern high-end CPUs, its simplicity still keeps is competitive there. Besides, there are still plenty of 8-bit processors around in embedded devices and such.) However, they often make use of features that are difficult and costly to implement in hardware, such as access to relatively large amounts of RAM (e.g. 258 bytes for RC4, accessed in an essentially random order).
In recent years, though, the trend in stream cipher design has been towards ciphers that blur these lines, being efficient to implement in both hardware and software. Good examples can be found e.g. in the eSTREAM portfolio: the Trivium cipher, for example, is fundamentally a "bit-based" shift register design, and can indeed be implemented as such if desired; however, it is designed such that up to 64 bits of the output can be computed in parallel, which allows very efficient software implementations using any word length of up to 64 bits. (Conveniently, the same parallelizability also allows Trivium to be made very fast in hardware, by essentially duplicating the circuitry up to 64 times, as long as available space permits this.)
From your perspective as a user of stream ciphers, the distinction is irrelevant.
As a driver of a car, you don't need to care the details of how the car's engine was built. What you care about is whether the car gets you there safely and rapidly.
Similarly, from your perspective as a user of a stream cipher, what you care about is whether the stream cipher is secure and how fast it is. If you measure those two things, you don't need to care about which type the stream cipher is.
Generally speaking, word-based stream ciphers are often built that way because operating on a word at a time can potentially be faster in software (on the other hand, bit-based stream ciphers can potentially be better in hardware, e.g., use less power and less silicon). However, rather than worry about this detail, you should just measure how fast the stream cipher actually is, and make your decision based upon that -- as well as whether the stream cipher offers sufficient security.
