So, you want to crypto

I feel like it's quoted from somewhere else, but the reference escapes me. At any rate, it's a great quote.

People who try the iterated design approach are especially frustrating. It ends up becoming a game of whack-a-mole with vulnerabilities, wherein an experienced cryptanalyst will point out an issue, the designer will say "oh! of course! let me apply a patch!", and then this continues to infinity. (This scenario doesn't necessarily indicate a bad approach, but it's certainly a symptom of iterated design.)

There's a particularly lovely story in Schneier's "Memo to the Amateur Cipher Designer" [1]:

> A cryptographer friend tells the story of an amateur who kept bothering him with the cipher he invented. The cryptographer would break the cipher, the amateur would make a change to "fix" it, and the cryptographer would break it again. This exchange went on a few times until the cryptographer became fed up. When the amateur visited him to hear what the cryptographer thought, the cryptographer put three envelopes face down on the table. "In each of these envelopes is an attack against your cipher. Take one and read it. Don't come back until you've discovered the other two attacks." The amateur was never heard from again.

Part of what makes it so frustrating, though, is that usually we want to be genuinely helpful. Building cryptosystems is fun (dangerously so!), and it's really crappy to end up saying "just scrap the whole thing" or what have you. But if you want to keep your sanity...

[1] https://www.schneier.com/crypto-gram-9810.html#cipherdesign

This is a good choice. One of the challenges had me stuck for months because I hadn't realised that you really need fine-grained control over bitshifting that e.g. Ruby doesn't appear to give you. Taking twenty minutes to re-write my solution to that challenge in C sorted it out straight away.

Well, it would be, except the pipeline seems to be clogged. I'm waiting weeks and months to get a response. Which is frustrating because the early problems are already really interesting, and I want more!

But how many people are going to be interested in a crypto product which is unproven? Sure, perhaps a few technical types will give it a whirl, but most people just want something that works. If I'm in the market for something like this I'm certainly not going to use a product with a big disclaimer stating "Hey, we don't really know if this works yet, but help us test it out!" This is mission critical stuff, not some new URL routing framework.

Two things.

First, while "playing around with cryptography" may be the only way to learn it, building cryptographic systems is just about the worst way to learn. Professional cryptographers start by cryptanalyzing targets and use that experience to inform their future designs. On the other hand, veteran implementors who have never taken the time to learn how to break crypto turn out protocols and designs that are repeatedly broken. You can see that right now with TLS and the TLS working group, which still hasn't fixed MtE block ciphersuites because veteran implementors can't get it through their heads that MtE is a design flaw.

Don't learn by building. You need to learn by breaking.

Second, more than one project has done the tightrope walk of telling their users "this isn't really safe" but then misleading (innocently or not) non-savvy users into trusting them. One project made it clear that their system wasn't "ready" to defend against nation-state adversaries... but then suggested that maybe it would be good enough for journalists, and even promoted it at an event for teaching journalists cryptography. It was later comically broken.

Be honest with yourself. Crypto doesn't get beta-tested into resiliency. Strong systems start out strong. If you're building something because its your dream to thwart the NSA, don't kid yourself into thinking that you'll get there by first protecting people's Warcraft clans.

I had this same textbook for the Crypto course I just completed this semester. It's a very good textbook, in my opinion, as the descriptions and examples are really informative. Usually if I couldn't get the material through my professor's lectures, it was sufficient to look it up in the book. However, we did only briefly touch on cryptographic hashes and only a little on Legendre and Jacobi symbols, and not at all on the elliptic curve and other special topics towards the end of the text, so I can't comment on those.

The book does very good job of talking about different algorithms and concepts, often times with a very brief historical introduction, and includes thorough descriptions of various popular/important attacks of those concepts. In general it's a book I'd recommend for an introduction to cryptography. You also learn a fair introductory bit of number theory which I really enjoyed.

I also met Dr. Washington, one of the co-authors of this book, who was a very pleasant and energetic person who really enjoys the topic of cryptography.

By the way, where are you taking this course?

I took an Intro to Crypto course offered through my University's Mathematics department and we used that exact text. I'm the kind of person that requires a very good text in order to do well in a course, and the book in question was of high enough quality that I did quite well.

Although I thoroughly enjoyed the Mathematical focus of the course, my particular teacher spent a good deal of the course discussing semi-related Number Theory topics at the expense of introducing some of the more interesting cryptography concepts. That said, we still learned the theory behind the important ones: DES, AES, RSA, and ElGamal, in addition to "classical" forms such as Caesar, Vigenère, and Hill.

Another downside of the course being a Math course and not a CS course: we used Mathematica for all of our "programming" projects, which felt awkward and clunky. I remember coding my solutions in Python first, making sure they were correct, and then translating them to Mathematica after the fact.

Good luck in the course! It'll be hard work, but its absolutely worth the effort.

Dr. Washington (one of the authors, I believe the other was a grad student of his) seems to be a really decent guy and cares a lot about teaching. He goes to middle and high schools fairly regularly to introduce kids on these topics.

That concern is reflected in the textbook and his course. It's a very approachable treatment and it seems like a lot of emphasis is placed on making it fun.

The downside to a math listed CS crypto course (as it is where Washington teaches) is that there may be less emphasis on flaws that occur in actual real word implementations. A professor in the CS department also teaches crypto at Maryland and actually uses a different book (one he wrote). My understanding is that there is a bit more attention paid to implementation there, but that's coming second-hand.

Most of Matthew Green's course is avail online http://spar.isi.jhu.edu/~mgreen/650.445/650.445__Main.html

A world full of brilliant cryptographers outraged at the NSA, trying to get the NSA off the IETF crypto review board, working on publishing results about NSA-sponsored crypto... and you want to talk about the MD2 and RC2 constants? What's the largest system that ever relied on MD2? Let's start there.

AFAIK the only "crypto" in git is GPG used to sign tags.

The content addressable data store where all the objects are kept is basically a filesystem where every filename is the SHA1 of its contents.

If you were to generate an object that was a SHA1 collision of an existing object and inject it via a commit (without access to filesystem, otherwise the point is sort of moot) then git won't overwrite the original object with that SHA1[1].

Maybe there's some other mechanism in Git that you're referring to that uses SHA1 as a MAC that I'm perhaps unaware of?

[1]: http://stackoverflow.com/questions/9392365/how-would-git-han...

You can use hashes for security but you can also use them in non-security critical systems to get a unique (with a very high probability) number for use as an ID. Git uses them for this I believe.

Attacks like mentioned can be prevented by a number of mechanisms and checks for changes. If a hash being secure helps that is great but that isn't why git uses hashes. Or by separately signing commits.

git does use crypto but reuses existing crypto (https and ssl to communicate between repos and someone mentions you can use GPG to sign commits) rather than developing it's own secure protocol.

A Git commit history is a Merkle tree. The hash is not used for authentication.

Yes! This is exactly what I was going to post. The article's recommendation to read Applied Cryptography and the HAC to "learn the theoretical background" left me dejected, since neither is particularly that great in the area of theoretical underpinnings. (The HAC is a reference book, for Chrissake!) Both are great books in their own right, but they're not what I'd recommend for the theoretical background.

Katz and Lindell's Introduction, on the other hand, is absolutely fantastic for the task (this was its design goal...). It introduces theoretical cryptography from the bottom-up and uses it to motivate the various primitives and constructions from the applied realm. It's really a great mix. The book has become my go-to recommendation for those who are serious about cryptography but have had relatively little exposure to it. It also doesn't assume the reader is an expert in all things computer science, which is nice.

Goldreich's Foundations of Cryptography is more of a treatise on theoretical cryptography... it goes much deeper and starts out assuming the reader is pretty familiar with concepts from theoretical computer science and probability theory. The optional sections of Katz and Lindell's work end up being the opening chapters of the first volume --- and they're not optional. Block ciphers aren't even treated until the second book. It's a seriously theoretical series, which makes it great in its own right, but I would postpone reading it until well-after Katz and Lindell's book. (And a book on computational complexity, at minimum, for those not familiar with it.)

Yes. Recommending Applied Cryptography is usually a warning sign that the person doesn't know what they are talking about. In this case the rest of the advice is reasonably sound for an engineer that wants to start learning the fundamentals of modern cryptography.

For Joe Public, you say "Bank Level Security", for hackers you drill down into the details. There's no reason why your marketing material can't give the visual security imagery that people want and then walk through the exact countermeasures you're taking on your security page.

N.B. Patrick also says to use your powers for good rather than for evil :)

Part 1 begins again in January and part 2 begins right after it's done.

It definitely does reduce the strength of the MAC, but it is okay if your security requirements require it. Keeping in mind that some generic birthday attacks already reduce HMAC strength to n/2 bits (IIRC), and SHA-256 has you down to 128 bits of security (with an online attack though).

Truncation is mentioned in RFC 2104. I quote:

5. Truncated output

   A well-known practice with message authentication codes is to
   truncate the output of the MAC and output only part of the bits
   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
   analytical advantages of truncating the output of hash-based MAC
   functions. The results in this area are not absolute as for the
   overall security advantages of truncation. It has advantages (less
   information on the hash result available to an attacker) and
   disadvantages (less bits to predict for the attacker).
   Applications of HMAC can choose to truncate the output of HMAC by
   outputting the t leftmost bits of the HMAC computation for some
   parameter t (namely, the computation is carried in the normal way
   as defined in section 2 above but the end result is truncated to t
   bits). We recommend that the output length t be not less than half
   the length of the hash output (to match the birthday attack bound)
   and not less than 80 bits (a suitable lower bound on the number of
   bits that need to be predicted by an attacker).  We propose
   denoting a realization of HMAC that uses a hash function H with t
   bits of output as HMAC-H-t. For example, HMAC-SHA1-80 denotes HMAC
   computed using the SHA-1 function and with the output truncated to
   80 bits.  (If the parameter t is not specified, e.g. HMAC-MD5, then
   it is assumed that all the bits of the hash are output.)

Most practitioners would recommend Nacl now.

Keyczar --- and other cryptographic libraries, mostly --- don't solve the issue of protocol design. They do let you choose the primitive you want, but it's still up to you to pick a mode of operation, make sure you use authentication (AEAD mode / MAC), initialize IVs/nonces/counters correctly, etc.

NaCl is very much a step in the right direction, but it's not an end-all solution either. Key management alone is a huge issue, for example, but virtually no library helps you out there beyond providing a basic toolkit. Of course, key management is very much in the realm of policy, so that's to be expected.

Did you have an actual opinion about what he was saying in the essay, or do you just want to talk about how he chose to write it?