Started reading it, pretty good so far!
Only thing, why did you choose to introduce block cipher modes in the stream cipher chapter? This makes little sense to me.
Only thing, why did you choose to introduce block cipher modes in the stream cipher chapter? This makes little sense to me.
In point of fact, there isn't as significant a difference between the two in active research and industry. Many (most?) stream ciphers actually use blocks internally. For example, Salsa (and its spiritual successor, ChaCha) both use blocks and rounds. From one legitimate perspective, a block cipher mode enabling streaming encryption is a generalization of a stream cipher.
When you develop a stream cipher without a block system internally[1], you're trying to remove the versatility of block cipher modes in exchange for (hopefully significant) improvements in speed and efficiency. This is very difficult to do while maintaining security. At the end of the day there are only so many ways to do confusion and diffusion.
_______________________________
1. For example see Sosemanuk, which internally uses a linear feedback shift register and finite state machine.
I don't think there have been any new designs for a good while that didn't. RC4 is, I think, the last actual stream cipher that saw widespread use (apart from designed-as-broken telco crypto). The same observation can be made for classified crypto, where they used to use bit-stream ciphers like Walburn or Saville (efficient, relatively low gate count hardware implementation) but pivoted to block ciphers since the ~80s.
Every entry in CAESAR that I've studied is either based on a block cipher or a hash function. A lot of them use AES internally, but others (MORUS, NORX) used their own designs.
There are no RC4-esque stream ciphers being taken seriously these days, for good reason.
More generally, I think the distinction between a "block-based stream cipher" and a block cipher (or permutation) mode is the degree to which you abstract away the block cipher. Personally I wouldn't put them together. Counter mode completely abstracts away the cipher, assuming it is an idealized pseudorandom function; sponge-based modes also abstract away the permutation as ideal in most cases; stream ciphers usually do not do this, and use weaker (but still sometimes block-based) primitives to generate output. There are, for example, sponge modes that use very few rounds past the initialization, which makes them more streamy than spongy. So their cryptanalysis is often different.
Just to make sure I understand you correctly, for example:
- CTR: definitely a stream cipher, and a synchronous one at that
- CBC: maybe a little like a stream cipher (you're e.g. exposed to the block width, and also less like most stream ciphers because asynchronous)
- AEZ: extremely not (because you're exposed to round counts)
That makes perfect sense to me, since that's where I felt the analogy started getting tenuous :)
I suppose you could design a cipher that worked on partial bits... But it's difficult to see why...
Also, the first lines in chapter 7: Let’s try to build a stream cipher using the tools we already have. Since we already have block ciphers, we could simply divide an incoming stream into different blocks, and encrypt each block...