VirusTotal seems to be cool with the file too, so that's how it should be.
It doesn't read as well as the PDF because there's a ton of illustrations and _something_ has to render them.
I don't know what I was doing clicking on it to begin with, usually a surefire way to get a fresh copy of MacKeeper or something
PS: Thanks for your work ! Watched your talk and it was a nice quick primer. Glad you turned it into a book with more detail.
Also: I'm not sure org-mode -> TeX was a great idea.
As a bonus, using pandoc to convert my org sources to markdown worked reasonably well.
Do you intend to complete this book at some indeterminate point in the future?
Is there anything that any of us can do to help make it happen?
Yessss! Utterly selfishly: things like 'Noise Protocol Matrix' or 'Nonce misuse resistance 101' are actually closer to your target than XOR diagrams that people can already find on wikipedia.
I know the “what” of this but not the “how”. If this teaches me what I need in order to go and actually implement it myself then I am interested.
BTW why is EPUB mentioned but not available?
Because it's not a priority for me and I never got the org -> epub generation flow working correctly. In particular, the book has a lot of illustrations, and getting illustrations right across a ton of ebook readers is quite complicated. To wit: they all support different formats and to get it more or less compatible you have to guess what the approx DPI is for most of those devices and then rasterize the vector imagery.
If someone gets it to work I'd be much obliged, it just hasn't been a priority for me :)
> what the approx DPI is for most of those devices and then rasterize the vector imagery
As far as I know you can use SVG illustrations in EPUB.
Alternatively you probably could rasterize to a redundant resolution and rely on the viewer app to downscale the pictures to fit the page width.
The concepts are as I remember from my cryptography course in college, and is a great refresher!
Serious Cryptography is also good and modern.
No Starch's "Serious Cryptography", the JP Aumasson book, is strong.
Do you recommend Serious Cryptography over that?
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, 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.
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 :)
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.
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...
Your feedback isn't really actionable. How is the author supposed to use anything about your feedback to "improve that version"?