Brain To Paper

For those of you keeping score, I have been wandering around in the world of cryptography lately. It is a brain-melting endeavor. The people who come up with cryptographic methods have my deepest respect. That is, my deepest respect when it come to thinking this stuff up. When it comes to their ability to tell the rest of the world what they thought up, well...

Some of them don't do a bad job considering what they are up against. Cryptography is hard. It's hard on purpose. Making it hard for the bad guys to figure out what you're doing is pretty much the purpose of cryptography. If it was just a matter of jumbling up all the letters and rearranging them, it would take the processor in your watch less than a second to decipher any message. Cryptography consists of complex algorithms applied to a wide variety of data.

One of the methods cryptographers use to publish their brain droppings is called a Request For Comments (RFC). This mechanism was set up by the Internet Engineering Task Force (IETF). It's as old as the Internet itself. The most basic protocols for getting information from one end of the net to the other are described in RFCs. It was envisioned as a mechanism for people to propose standard behavior on the Internet and get peer feedback. For the most part, it works. Almost all of the early RFCs have been revised based on incoming comments and questions to the originator(s) of the RFCs.

One of the things I recently did was to implement the CAST5 cipher. I won't go into the details of it, but it only took me a couple of evenings to code it, and another couple of evenings to test and debug it. The cipher is described in RFC-2144. While it is far from perfect, it is coherent enough to translate it from a mathematical function to a computer function. I am currently wading through RFS-2437, which describes the RSA encryption system. It is a heavy load, mathematically speaking, but following it isn't that hard. RSA is the basis for secure protocols like HTTPS which is the way that Amazon (and others) keeps the bad guys from being able to see your credit card number when you are ordering your yoga mats and Cryptography for Dummies book.

This brings us to the RFC for Open PGP. PGP, which stands for Pretty Good Privacy, is a very strong cryptography system (note the irony on "pretty good"). It gives the NSA fits. Imagine you wanted to let your Uncle Bob into your house when you're not home. You could leave the key under the mat, but then any old bad guy could come along and look under the mat. So, to prevent this, you hide the key in plain sight in such a way that it doesn't look like a key and no one who doesn't know how to look for it can see it. But, you need to let Uncle Bob know how to figure out where it is, so you send him a message in a secret language that only he knows how to read, telling him that the key is hanging on the third rhododendron bush from the left, 11-1/2 inches from the ground. The bad guy could technically find the key, but he wouldn't know where to start looking and he would have to get lucky to find it in any reasonable amount of time.

Open PGP is described in RFC-4880. The number is burned into my brain. It is the godawfulest mess I've ever run across. Imagine your autistic nephew trying to write instructions on how to build a house. He could probably build the house, but it would be nearly impossible for him to tell you how he did it. Everything is Open PGP happens in packets. One of the things that would be nice to know is how big are the packets. It starts off well enough, telling you that the first thing in the packet is a number telling you what kind of packet it is, and another number telling you how big the packet is. It goes straight to Hell in a handbasket from there. They use something called partial packet body lengths. Yes, that's right, a number that tells you that here is a number that represents how big the packet is, maybe. Well, it's at least this big, but it might be bigger. And there might be more packets hiding inside this one, but we can't tell you where they might be:

Each Partial Body Length header is followed by a portion of the packet body data.  The Partial Body Length header specifies this portion's length.  Another length header (one octet, two-octet, five-octet, or partial) follows that portion. The last length header in the packet MUST NOT be a Partial Body Length header.  Partial Body Length headers may only be used for the non-final parts of the packet. Note also that the last Body Length header can be a zero-length header.

Wut?

In another part of the RFC, they made a decision to use a bastardized version of a cipher called Cipher Feedback (CFB). It turns out that this bastardized version ended up being a vulnerability that no one has fixed. But I don't know how anyone would be able to figure that out from the RFC. Worse yet, the RFC describes how this mode works for encryption but is silent on decryption. Isn't that helpful? I think the authors need to either back up and take another shot at it or hire a ghost writer.

Well, I've bitched about this enough to get it off of my chest. Thanks for listening.