3 ms·

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

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.

aaachilless 8y ago
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...
lvh 8y ago
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 :-)
throwawaymath 8y ago
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.
- blattimwind 8y ago
  > 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.
  - CiPHPerCoder 8y ago
    > 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.
  - pbsd 8y ago
    Most of the eSTREAM finalists (http://www.ecrypt.eu.org/stream/index.html http://www.ecrypt.eu.org/stream/index.html) are not block-based. I think only Salsa20 matches that description. 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.
    - lvh 8y ago
      > 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 :)

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.

aaachilless 8y ago

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...

lvh 8y ago

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 :-)

throwawaymath 8y ago

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.

blattimwind 8y ago
> 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.
- CiPHPerCoder 8y ago
  > 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.
- pbsd 8y ago
  Most of the eSTREAM finalists (http://www.ecrypt.eu.org/stream/index.html http://www.ecrypt.eu.org/stream/index.html) are not block-based. I think only Salsa20 matches that description. 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.
  - lvh 8y ago
    > 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 :)