The Rubaiyat of MATSUMOTO Yukihiro

I am participating in the development, in Ruby on Rails, of a generic Content Management System (CMS) and a library that lets administrators edit documents that use styles and can be displayed to the public (or a smaller audience) over the Web. My current task is to make sure that when a server using this library exchanges the identifiers of documents and components with the browser, it encrypts the identifiers so that no user can falsify her right to see and edit those documents and components.

Am I the only CTC VISTA who uses the Ruby programming language?

The rest of this posting could be regarded as an appendix for those who want to look in some depth at what I have done so far.

I attach code that unit-tests a module I wrote to encrypt and decrypt IDs. The testing code uses a package called "rspec", that promotes a style where your testing code is also a description in almost plain English of what the module under test is supposed to accomplish from the viewpoint of its callers.

Here is some explanation about the code I attached.

I wrote a class called CapabilityKey. An instance is a randomly chosen key that can be used to encrypt and decrypt identifiers. The code reflects my use of a jargon that refers to an encrypted identifier as a "capability", because, when you (a person or a process on some computer) have it in hand, it denotes your capability or right to access or edit some resource. This jargon occurs in the literature.

In this context, the type of an identifer is simply integer, and it is what is stored in the database to identify the records representing the resources we are protecting. The simple and naive way to identify the resources in interactions between the server and the browser would be simply to send the id.

Maybe I will rename the class as CapabilityLock because a lot of what it does is make sure that the "capability", when used actually as a key, fits the lock, that is, is valid in the context in which someone is attempting to use it. Really, the term "key" refers better to the capability than to the thing I called a key in this code, which is really more the lock. In fact, some of the literature about capabilities refers to them as keys. They function very much like a car key. You shouldn't be able to drive a given car anywhere unless you have the key.

The testing code that I attach refers to the fact that my class or one of its instances should satisfy the following "shoulds", each of which I now try to make a little plainer as to its meaning than the code does:

it "Should support instances being marshaled."

This means that the regular "marshaling" facility included with Ruby should be able to save off a representation of an instance of my class to a file and should be able to correctly recover a usable copy from such a saved copy.

it "Should supply a capability that is a string."

This means that when we give an instance an identifier and say we want back an encrypted version of that identifier, the data type of the resulting "capability" should be String.

it "Should recover the correct id and tag from a valid capability."

This says that when I give an instance an identifier and ask it for a capability, and if I give the same instance back the capability and ask it for the id that that capability denotes, it should give me back the correct id. (Another piece of data, a "tag", is also tagging along with the id in these operations, but we don't need to get into that here).

it "Should detect invalid capabilities in the vast majority of cases."

This test case is an attempt to see whether it is, as it should be, very unlikely that someone dinking around could generate some string that would look like a valid capability to the lock. The way I test that is by creating 1000 locks and trying one key (or "capability") in them that they didn't generate, but that another lock did generate. Each creation of a lock uses the pseudorandom number generator to determine the characteristic of the lock. I consider this test quite equivalent to generating 1000 keys at random and testing them in one lock, although I am really doing the other way around. So, it's at least some way to give confidence that the wrong key won't fit the wrong lock, and this in turn gives some confidence that it would be hard to carve a key and get it to work in a given lock. No doubt a cryptologist would say that such a test is far from perfect. The cryptologist could argue, for example, that for all she can tell from the test cases, the locks might be generating capabilities that all begin with "foo", and the locks might be accepting any string starting with "bar:" as a valid capability, for example, "bar:33" as a capability to ID=33. Testing can't test everything, when it comes to cryptographic strength. But this test at least gives some rudimentary indication that the locks won't take each others' keys.

Comment from Morgan Sully on October 31, 2007 - 6:02pm

Hey Jack,
This looks like completely obscure work to me, but I am glad that you can find poetry in Ruby's coding. In my own work with CSS I have come to appreciate simple, shorthand ways to instruct browsers to render styles for a webpage. I'm no code novelist but it's certainly fascinating (to me) to see the output of what I write (or sometime copy and paste;).

Any visible finished products up online? The code looks cryptic to me (pun intended).

Comment from Jack Waugh on October 31, 2007 - 6:18pm

"Any visible finished products up online?" Not including this code that I am working on. It is new stuff under development. I could point you to sites built by CTSS before I arrived, however, if you want.