Block and Stream Ciphers
Last time, I talked about the difference between symmetric and asymmetric ciphers, and said the symmetric ones were further divided into block and stream ciphers. I’ll say a little about what that means, without getting too deeply into it, since it’s not really that important.
Well, I say symmetric, but I can’t think of a conceptual reason asymmetric ciphers also couldn’t be divided into those two classes. In practice, though, I don’t know of a single asymmetric cipher that isn’t basically a block cipher.
Block Ciphers
Most modern ciphers are block ciphers. They take the text as a whole, divide it into blocks (if necessary; sometimes the entire text is a single block), and encrypt those blocks. Most modern ciphers also use those encrypted blocks to encrypt the other blocks and things, in a type of cascade effect, though this is by no means necessary.
The important part is that they require the entire text before they can start encrypting.
Probably all of the symmetric ciphers you’ve heard of are block ciphers. DES is one that uses 64-bit blocks. So is Blowfish. AES, Twofish, and Serpent use 128-bit blocks.
Stream Ciphers
Stream ciphers, on the other hand, treat their input as a data stream (hence the name) and encrypt it on the fly, as it were. They don’t need entire blocks, and certainly don’t need the entire set of data before they can start encrypting, which has a lot of advantages, but also some disadvantages.
To understand how they generally work, we need some background on how computers generate random numbers.
The simplest type of (software) random number generator isn’t actually “random” at all. It’s a function that takes a starting number (the seed), and subjects it to a series of mathematical functions to obtain a result, which is the output. When the function is called again, it will use this output as the seed and repeat the process, obtaining another function.
Typically, the original seed is some representation of the system time in microseconds, ensuring that the output is sufficiently unpredictable.
This is the earliest type of pseudo-random number generator still commonly in use1, and a stream cipher is conceptually just that. The output of the pseudo-random number generator is used to encrypt bits or bytes of the stream (depending on the cipher), for instance through a simple XOR operation.
The cipher key is the RNG’s seed, as using the same key again will produce the exact same sequence of numbers.
There are obvious uses for stream ciphers. One is encryption of telephone conversations, where block ciphers couldn’t possibly be used. Secure wireless internet is another example.
There are also disadvantages, though. One is that stream ciphers are perceived to be less secure, since cascade effects will necessarily be more subtle, and can only work in the forward direction (you can use byte 1 to XOR byte 2 and byte 2 to XOR byte 3, for example, but you can’t work backwards, which many block ciphers do do).
If the output of the random number generator function is sufficiently random, this wouldn’t be an issue (and brute-forcing would essentially be the only way to crack it, and only if you knew what kind of message to expect and there’s a limited key length, as the key is basically used to generate a giant one-time pad; if the function can take a key of any length, it would be uncrackable), but designing a good PRNG is, of course, quite challenging.
Though stream ciphers are conceptually easy to understand, potentially very secure, and very useful, I’m ashamed to admit I couldn’t name a single one off the top of my head, and I have no idea why this is the case. I’d like to think that this is because most of them are proprietary algorithms developed by shitty cell phone companies, but probably I just suck.
You could say simple things like Caesar substitution and Vigenère ciphers are stream ciphers, I guess, since they can be applied to streams, but I’d say they don’t really fit neatly into either category.
Go go gadget Wikipedia.
1 There are other kinds. If you use the Lunix, /dev/random and /dev/urandom both rely on entropy in the system to generate random numbers of a higher quality, and there is specialised hardware that will, for example, generate random numbers based on thermal noise. Neither of these are suited to stream ciphers, though, as the sequences of numbers they generate aren’t (supposed to be) reproducible.
Post a Comment
RSS feed for comments on this post · TrackBack URL