It actually makes a lot of sense for practical purposes. This probably looks strange to you because most introductory cryptography texts strictly segregate stream and block ciphers. The standard pedagogical style bifurcates modern symmetric encryption into one of these two categories and talks about things like synchronization, on-the-fly encryption, speed, error correction, etc. between the two.
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.
> Many (most?) stream ciphers actually use blocks internally.
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.
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.
> 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.
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 don't think there have been any new designs for a good while that didn't.
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.
Well, technically it's a question of block size? I'm not aware of any cipher with less than single bit size... And often you'd want byte size at least?
I suppose you could design a cipher that worked on partial bits... But it's difficult to see why...
Because the book tries to produce a narrative where new features are introduced out of obvious necessity: in this case, encrypting more than a block. And you can do that with modes of operations or "native" stream ciphers. Essentially I'm handwaving and pretending that e.g. AESCTR is just a stream cipher :-)
Chapter 6 is block ciphers, Chapter 7 is stream ciphers.
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...
It’s worth pointing out that even the author admits that the newer Stingray II has 3G/4G support. I think this is probably related to known insecurities in the AKA protocol, as researchers have recently found [1]. It looks like call interception isn’t so straight forward anymore, but IMSI capture and approximate location capture are alive and well.
So unless you can verify that only Stingray I is deployed in the vicinity, I think it’s a stretch to say that the Stingray product “doesn’t care” about anything other than 2G.
As a pen tester, I wholeheartedly disagree. It’s probably more common to see unsafe YAML deserialization, rather than directly deserializing marshaled Ruby objects, but both are impactful and these types of vulnerabilities do exist. Just recently I assessed an application that used unsafe serialization to pass around an object encoded in the value of a cookie. It contained transient data related to the user’s session (e.g. what page they last visited). Last year I assessed an application that allowed users to upload YAML files, which would get parsed and deseralized as Ruby objects. Unfortunately I didn’t have a universal gadget chain then, so I had to note it as theoretically exploitable in my report. That’s troublesome because some clients may take it less seriously.
I’m personally very impressed with this research and I think it does a net good, demonstrating that deserialization of Ruby objects in any form is unsafe when you can’t trust the input.
That is fully captured in the notion of a universal deserialization gadget chain. However, for those not familiar with the concept of gadgets, yes, I can see how it might be a bit confusing at first.
Only thing, why did you choose to introduce block cipher modes in the stream cipher chapter? This makes little sense to me.