A high level summary (and paraphrasing) of Zed Shaw’s talk at DEFCON 15 (in 2007) because I couldn’t find a good text version.

Utu is the Maori word for a system of revenge used by Maori society to provide social controls and retribution. Utu is also a protocol that uses cryptographic models of social interaction to allow peers to vote on their dislike of other peer’s behavior. The goal of Utu is to experiment with the effects of bringing identity, reputation, and retribution to human communications on the Internet. A secondary goal is wiping out IRC because apparently nobody really likes IRC.

The Utu project is now dead, but its source code can be found on Github. While reading this keep in mind that the core idea is a centralized chat server.

Part 1: The Idea

Philosophical Foundations

• Strong Identity
• Reputation
• Retribution

If you have and combine those, you can start to implement some controls available in human communications.

Strong Identity

In order to have strong identity everyone has a cryptographic key, but because keys are so easy to create you have to be invited, and you have to have a handshake as part of the invitation because you need to care about who the invitee is. This doesn’t work if any jerk can invite any other jerk without consequence.

1. Zed certify that he wants to invite Joe.
2. Joe certifies that yes, that invite is from Zed.
3. Joe takes action to assert that they actually want the invite
4. Zed says yup, I really did want Joe to join us.

Reputation

Rather than associating likes with an identity or posts you associate “hate” with an identity, and over time that hate builds up from many people.

“Wouldn’t it be great to punish the dickheads?”

Retribution

(Keep in mind that Utu was intended as a chat network)

As a person builds up hate they have to do some cryptographic proof of work before they can do anything. The more hate they have the more work their computer has to do before they can say anything.

This accretion of hate gives you a weighted social network that you can crunch numbers on. You can figure out who “hates” who, who talks to who, where they come from, and we can start looking at the social problem.

You can say “Hey, if we change the hate model to be this way, or we change the hate model to be that way, how does the social network change? Do the jerks go further away?”

Another alternative to hate is distance, because people aren’t prevented from talking to you it just takes them longer.

Part 2: The Implementation

Geeky Details

The Protocol

• Sends 2 bytes for size (htons(size)) (for framing)
• Sends the data structure (“Stackish”)
  • S-expressions with netstrings in a FORTH stack order
  • [['4:test' 1234 child root is equivalent to this lisp (root (child (1234 '4:test')))
• That’s it.

Semantics

• Determined by the Hub (everyone talking to hub)
  • routes things to different chat rooms
• One Stackish node for header
• Another for body

Data Encoding

• Always ASCII text, but you can put anything you want in BLOBs.

Simplicity is Key

• 2 bytes for frame
• Stackish for header and body
• easy to implement

Security Preventions

Zed believes that you need to design your software with the assumption

..that everyone on the internet is a fucking ass hole and they need to be taken down…If it goes on the internet it’s social software. It shouldn’t be designed assuming everyone likes you… Eventually some person is going to hack it. Eventually someone is going to try and abuse it.

I’m not going to be able to stop everyone…but if the server and the protocol, like from the base of the protocol on up is designed to make it so it’s harder… it’s not making it impossible, just harder… then what I’m banking on is the predator concept. A predator, when picking two different types of prey, will pick the weakest one.

• Client does all the crypto work to prove identity first and the server just validates it. If it’s wrong the server puts the identity in a blacklist and then boots them.
• Client is considered hostile
• Booted immediately
• A Finite State Machine controls

The Cryptography

• Never write your own. Let the pros do it.
• Follow the rules
• Use standard stuff

Details on exactly what it uses are at 20:48 in the talk.

Secure Coding Practices

• All code “ruthelessly” run through a test suite on a loop, with running stats used to compare releases.

Statistical Quality Control

• Collect Information on
  • Valigrind erros
  • Unit test errors
  • Logged Errors
• Analyzed the changes over time

Code Auditing

• Review my code repeatedly.
• Consistent “rules” I follow.
• Assume it’s always broken.

C Coding Practices

• Bstring library for strings
• All functions have valiadtions
  • Assert
  • Preconditions / postconditions
  • Extensive Unit Testing.

Secure Unix Server Practices

• The Server Always chroots ALWAYS
• Leave minimum resources open.
• Minimum configuration.

Practical Demonstration

This starts at 30:41 in the talk and involves a fair number of geeky commentary. For non geeks a) why did you read this far b) it’s just a really simplistic chat client.