That 70's Crypto Show (Remailers, science and engineering)

[dmolnar]

On Thu, 28 Dec 2000, Ray Dillinger wrote:

> Not enough energy by half has been focused on protocols. 
> I think there's probably a good set of programs to be 
> written here.  

While we're at it, check out this web page

http://www.cs.nyu.edu/cs/dept_info/course_home_pages/fall96/G22.3033.02/

Avi Rubin and Matt Franklin's course on crypto protocols.

> Basically, I'm thinking in terms of the old unix philosophy -- 
> "A good program does exactly one thing, and does it well.". 
> If somebody designs a good set of command-line programs, which 
> produce output usable by each other so that they can be piped 
> together in useful ways on a unix command line, then protocols 
> should be easy to implement as shell scripts.  But a proper 

First you need to identity a set of common building blocks! I thought
about this briefly a year or two ago. Then realized that many protocols
for, say, "digital cash" do not actually share many components with
each other. Sure, all of them may have a public-key cryptosystem, but
the exact requirements are different...and sometimes a protocol needs
specific properties of a cryptosystem in order to work.

My programming languages professor recently pointed me to a paper
describing a library for doing smart contracts and options in Haskell.
(I'll post the reference later; I'm having trouble finding it). They put
together a library of combinators, which together could be used to write
real contracts. Even have a semantics for this beast. It seems that the
reason they could do that is that the contracts they're looking at
decompose nicely into distinct parts. It's not clear to me how to do that
for crypto protocols. 

Maybe a place to start would be to go through a bunch of papers on crypto
protocols and analyse the all the "Alice sends to Bob" messages. See what
commonalities pop out. 

-David