Obol 0.2007.01.19

Obol is part of a project to investigate properties of security protocols, what they are, how they behave, how they interact, how to deal with them. The Obol language grew out of a desire to escape the distractions of low-level implementation efforts, and the need to experiment and express security protocols as independent programs, closer to the level on which security protocols are analysed.
Whats it all about?
Obol is a specialized high-level programming language for security protocols. The idea is to program closer to the abstractions used to describe and analyze security protocols, and leave all the nasty details to the runtime. The runtime will then handle "mundane" issues such as message representation, communication, cryptographic transformations and so on.
Whats the point of that?
By focusing on the security aspects of the protocol being implemented, one avoid the typical entanglement of security protocol code, low-level cryptographic functions, and application logic. Obol keeps these three aspects separate, resulting in a clean, highly modular and very flexible security protocol framework.
Think of it as trying to do for security protocols what SQL did for databases.
Whats it implemented in?
The most mature (and actively developed) runtime version is implemented in Java, using ANTLR for the parsing. Earlier prototypes were implemented in Common Lisp and Python.
What can it be used for?
Security protocols, or any protocol structure that involve composition and transformation. Obol is interpreted, and protocols can very easily be upgraded. The runtimes modular structure allows for new message representation formats, cryptographic primitives, communication technology and so on, to be added dynamically.
What does it look like?
As an example, consider the typical way a message in a security protocol is described:
A → B: A, B, {A, B, Na}Kab
The above means that A sends B a message consisting of the senders name, the intended recipients name, and then encrypts a repetition of the names along with a nonce Na(random value) using the shared-key Kab. We have not made the assumption that Obol must run on both protocol endpoints, so we must implement both sides (both A and B):
A side (send B A B (encrypt Kab A B Na)
B side (receive A A B (decrypt Kab A B *Na))
In the above example we assume that A and B know about each other, and that share the key Kab. However, the nonce Na is unknown to B, so B cannot recognize it, but can assign the unknown datum to a symbol, which is what the *Na construct does.
How can Obol be used?
An application must connect to the Obol runtime and request that it starts an Obol protocol, or script. The application receives a handle which it can use to communicate with the script instance, i.e. starting and stopping the protocol execution, setting and retrieving values the script requires and provides.
Enhancements:
Fixes:
- Jar file trouble
- robustness issues
- symbol property dereferencing