Cutlass Developers' Journal

The Recon organizers have now posted all the presentations from that conference. There were a lot of good talks there, so it’s well worth checking out. Videos will supposedly be coming (for free!) in September.

Well, the Grokster ruling from the supreme court is in, and regardless of what I’d hoped, feared, or otherwise, it is what it is. We all have to live with it now. Thankfully, it doesn’t seem to change my plans for Cutlass in any major ways.

Essentially, the court ruled that if I intend for you to violate copyright with my software, I am partially liable for your copyright infringement. Now establishing that intent is somewhat sticky, and there will likely be much legal wrangling over where a court can draw that line. (Hopefully the burden of proof will lie with the plaintiff, but I’m not going to hold my breath on that one).

So, here I declare, publically, by all that I hold dear, please don’t use Cutlass for copyright infringement. Seriously. You’re pissed at the RIAA? Get your music somewhere else! I’ve had people in all honesty tell me that:
1: They were pissed that Metallica was going after Napster
2: That P2P actually helped music sales, as awareness of bands contributed to overall band revenues
3: That they were so pissed, that they were going to go download a bunch of Metallica MP3s.

Err, hello? 1 and 2 I agree with, but 3 does not follow. If you really believe that P2P helps bands (as I do), and that you’re pissed off at a band (as I have been), the solution is to go find alternatives, who actually want their music to be heard, and go download their songs, and perhaps even buy an album or see a show.

If you want to know where to go to find Free Culture, Downhill Battle has a good collection of links at the bottom of the page.

Cory Altheide from the SANS Internet Storm Center posted a review of several presentations at Recon, including mine.

Thanks for the link!

I’m in Michigan for a wedding this weekend, so it’s been a slow zone for coding. I fixed a couple of bugs in the transport layer that were causing channel leaks (where channels would transmit all their data, but never free up), and I also removed some redundant code in channel initiation.

I also noticed that the new page didn’t have directions as to how to get anonymous subversion access to the latest checkins. Oops. It’s now a link up in the “Download Cutlass” box on the left.

So, we’re going to revise the handshaking protocol. It was under revision already, to support negotiation of crypto primitives, but I realized we had some additional requirements for NAT, and some people at Recon mentioned DoS resiliance as something that should be addressed up front. So, I figure we should take a step back, look at what other requirements we should address, and hopefully get the handshaking protocol stable so we can focus on other things, rather than have it be a moving target.

In some situations where we are NAT punching, we’ll be issuing initiation packets from both sides. If we’re doing that, we need a way to clean up the state so that we can sync up and complete handshaking by determining who becomes the initiator and who becomes the initiatee.

While we’re at it, we ought to harden handshaking to DoS attacks, and make the protocol capable of cipher primitive negotiation. And, hey, let’s clarify how the protocol tears down cleanly as well, so we can lose the quick-disconnect-restart class of bugs as well.

So, the following is a proposed set of requirements for the handshaking protocol. Feel free to propose additions or deletions to them:

- Cutlass must offer the ability to not answer to remote scanners that do not have a preshared secret
- Cutlass must not allow network observers to distinguish between an initial key exhange (where both sides do not know the other’s public keys), and subsequent key exchanges (where both sides are merely verifying the other’s public keys).
- Cutlass must offer the ability to exchange previously unknown public keys, offering usability no worse than that of ssh.
- Cutlass must require that initiators perform expensive computations before initiatees perform expensive computations
- Cutlass must require that the initiator prove receipt of initiatee information before the initiatee performs and expensive computations
- Cutlass must allow both sides to initiate connections simultaneously, over identical port pairs, and still be able to select disparate roles for each side (”initiator” and “initiatee”).
- Cutlass must allow one side to drop, and reconnect over identical port pairs, and still be able to take sensible action (Do we want to require the ability to renegotiate? Can we better define “sensible?”)

Now, I’m thinking that a great way to detect a potential drop-reattach situation is to have an undersized initiation packet. Since it’s hard right now to detect the difference between an invalid checksum and a reconnection attempt, if we detect a short packet, we could interpret that as a reconnection attempt.

How to prevent people from turning that into a DoS? We could start holding incomplete connections in a kind of kex purgatory, rather than in the connection hashtable proper. (This also makes it easier to allocate smaller amounts of memory until full handshake completion).

So once we detect a short packet of the proper format (whether or not we have an open connection), we can open a purgatory entry. From then on, incoming packets on that port pair get checked first to see if they kex properly. If they do, then we kill the purgatory connection.
If not, then we drop them down to the handshaking code to see if it can make sense of it. If we renegotiate a connection over the same port pair with the same public key, then we update the ephemeral keys and go forward from there. If it’s a different public key, tell the other side to kindly shove off.

A new code rev is in, 545, which fixes some old bugs with info propogation (Only one connection was getting updates to things like file server status, which was really irking since I’ve added the ability to switch that status on the fly), and new bugs with the directory server.

I’ve also stubbed out some calls for the ALSA module. I ran into two sets of audio problems at Recon, one involving a failure in the ALSA-OSS compatibility layer. Since those bugs are out of my control, I figure I’d better write a native ALSA driver to avoid them.

The other bug I suspect is an instability introduced with some new code in 543 intended to prevent race conditions. I’ll certainly have to fix those before I roll an 0.3 tarball (which I’d like to do, it’s been rather a while).

The updated slides for the Recon 2005 presentation are now online. It’ll show up on the Recon site as well, shortly, but you got it here, first!

Wow. A 9:30 AM talk, and we had an almost-full room. And most of the people there had never heard of Cutlass before. People were interested and excited, and overall the vibe was pretty good.

We actually sold out of all of our large T-shirts before the talk even started. Note to self: Large T-shirts are by far the most popular size, and we need far more of those than even Mediums or XLs.

The demo didn’t happen, due to my stupidity. I forgot my video port replicator at home, and thus couldn’t use my laptop with the projector. A friendly bystander, name of Cory, kindly lent me his laptop for a demo, but for whatever reason every time I’d open the /dev/dsp device on his laptop the process would hang. So, I’m guessing that I can’t depend on the ALSA->OSS compatibility layer to work every time, and I have to write an ALSA-native sound plugin.

Thanks much to the Recon organizers, first for organizing a great conference, second for providing free breakfast, which I think was a key factor in the good turnout this morning. Also special thanks to Hugo for helping me pimp out the T-shirts, and thanks again to everyone that bought a T-shirt this morning.

So, I’m about to head to the airport for Recon, where I’ll be speaking Saturday morning on the hopes, dreams, and state of the project. If you’ll be there, come on up and say hi!

So, in order for Cutlass to be popular, it’s gotta support Windows. That’s the reality in today’s world. So I figured I should talk about how Cutlass intends to accomplish that.

First, and most importantly, we’re trying to stay away from platform-specific calls, at least in the library layer. (Cutlass is divided into libcutlass and clients, if you haven’t been playing along up until now). The two areas that we haven’t been able to avoid platform specifics we wrap. Those two areas are threads and time.

Luckily, those really aren’t that hard to wrap. While Windows threads are slightly different from pthreads, we’re not using any of the pthreads functionality that Windows has no equivalent for. So pretty much we’ve created our own cutlass_thread_handle and cutlass_mutex_handle structures, which we #define at compile time to contain the platform-specific structures.

Then we wrap all of the thread creating, detatchment, etc. functions. pthread_create and CreateThread get merged into cutlass_thread_create. pthread_mutex_lock and EnterCriticalSection get merged into cutlass_mutex_lock, and so forth. All of this happens in wrap_thread.c, with the structure definitions in <cutlass/wrap_types.h>.

Time is a bit more complicated. Sadly, Windows only offers millisecond timers by default, while Linux now gives you access to nanosecond-aware functions (Whether they’re accurate to nanoseconds is unlikely, but the interfaces are there). Right now, we’re defining a cutlass_time structure that can support nanosecond accuracy, and under Windows we just multiply milliseconds by one million in order to get nanosecond-equivalence. I suspect we’ll find some issues when we start testing the transport layers under Windows that we’ll need to tune, probably by bunching packets together if we’ve slept for too long.

Anyways, time checking and sleep functions are all wrapped up in wrap_time.c, following the same strategy as for threads.

Using these wrappers, most of the code compiles under both Linux and Windows (using MinGW). Still having a few linking issues in Windows, and one issue with the crypto module not locating some headers. We’ll get it hammered out, though.