Written Assignment  -  Extra Credit Question.   You don't have to answer it !

Citizens of the island of Kafku (in the south pacific) adopted a bizarre voting scheme. Each citizen's vote v(i) is a bit (either zero or one). To decide which of the two competing parties wins the election the election committee computes 
            v(Alice)    xor   v(Bob)   xor   ....   xor   v(Zorba)
The result identifies the winning party.  The individual votes must remain secret. The inhabitants of the island of Kafku are famous for their mental calculation powers as well as their total unwillingness to use paper.  They agreed to use the following protocol:

1. On election day the election committee announces certain information (public key) using the loud speaker system.

2. Alice decides on her vote.  She then tells Bob some value, A, based on her vote, A=F(1,v(Alice)).  To keep her vote secret the value A should not reveal her vote to Bob.

3. Bob decides on his vote. He computes some function of his vote and the value he received from Alice, B=F(A,v(Bob)). He tells the result, B, to Charlie.

4. This process continues until Zorba computes the final value, Z=F(Y,v(Zorba)). He then gives the result, Z,  to the representative of the election committee (who is not a citizen of the Island).

5. The representative uses some secret information known only to her to determine the outcome of the election.

Design the cryptographic mechanism to enable the denizens of Kafku to carry out the election while not revealing their private votes. Base the security of your mechanism on the hardness of distinguishing quadratic residues modulo a composite from non-residues with Jacobi symbol +1. You must describe the public key published on election day as well as the function F(x,y) used by the inhabitants.

This is an example of a private computation: a number of parties wish to compute a function of certain private values. The results of the computation should be made public, however no other information should be revealed about the private inputs. Another example of such a computation is the billionaires problem: two billionaires wish to decide who is richer without revealing their wealth. The solution to the billionaires problem is much harder. In general, it has been shown that (in principal) any function can be computed privately.

Programming Assignment

In this assignment, you need to implement a client-server application that handles electronic money. Once again we use the spellchecker. However now the client needs to pay the spellchecker for the services. The client will send words to the server who will spellcheck them and reply to the client with the result. The server will charge the client according to the number (and length) of the words it spellchecked.

The main security requirements are as follows: the client should be assured that the server cannot over charge. That is, the server should not be able to claim that the client spell checked words it did not. The server should be able to prove (to a judge) that the client indeed spell checked as many words as it did.

You will work with more or less the same skeleton client and server programs as you did in the first programming assignment. The client is still the same, the server has an added cleanup routine which is called when you try to kill it by pressing ctrl-C or using 'kill -2 processid'. Your job is to modify the client and server to add the money exchange functionality. You are strongly encouraged to work in pairs for this assignment. There will be no difference in the grading standard if you choose to work individually.

Getting Started

The directory /afs/ir/class/cs255/p2 on the Leland machines contains all the files you will need. They are:

1. Makefile
2. spellc.c
3. spellc.h , all these are same as what you had in programming assignment 1
4. spelld.c - Has an added routine cleanup(), which gets fired up during termination.

Copy these files to your directory and run make to create spellc and spelld. And you can check these in the same manner as you did in case of assignment 1. When you quit the spelld by pressing ctrl-C the server should print Server terminating.. and terminate.

What You Need To Do

You will maintain the current interface for spellc and spelld. You need not and should not change any of the code in the main() functions. You will add provisions for money exchange. You will have to change the init security() and process() functions both in spellc and spelld, plus the function cleanup() in the server spelld. cleanup() will print how much money the client used.

The client pays for spell checking services using tokens of various denominations. To avoid the need for a client signature on each spellchecking request, token lists are stored as stalks (see below). Spending a token amounts to revealing an element on the stalk. To implement coins of different denominations we use multiple stalks. Each stalk holds coins of a single denomination.

The implementation will require you to use signatures, one-way hash and MACs (for integrity).

• Hash chains - an efficient implementation of coin stalks.
  You will use hash chains to set up the currency. The clients selects a random seed S and hashes it N times to get a sequence of numbers S1, S2, ... SN such that Si = h(Si-1). Then you send over the pair (SN, N) to the server with the client's signature on it. The first time the client needs to use a token, it will send SN-1 to the server, the server will compute h(SN-1) and check that it matches SN. The next time the client will send SN-2, and server will validate it by testing that h(SN-2) = SN-1. Once the client spends k tokens, the server will have SN-k and SN. The signed SN and plain SN-k are used by the server as proof that the client paid it k tokens.

  The server must store the client's signature on SN to validate the hash chain (stalk). This is the only signature the server needs to store. There is no need for the client to generate a signature for each spell checking request. Note that without the client's signature on SN this mechanism can be easily defeated by both the server and client.

  Assuming h() is a one-way hash function, the server cannot recover SN-1 from SN unless the client hands SN-1 to it. Consequently, the client is assured that the server cannot falsely claim the client spent more tokens than it did. Conversely, possession of SN-k (and the client's signature on SN) can be used by the server to prove (to a judge) that the client spent k tokens.

• Rates and Denominations
  The cost of spellchecking a word is equal to the number of characters in the word. And we will use tokens of different denominations 1, 5 and 10 units. So in order to check the word disambiguate, the client will have to pay 12 units which he will pay by sending one token of denomination 10 units and 2 of denomination 1 unit.

• Change
  Your client should begin with a total credit of 1000 units beings divided as 50 tokens of 1 unit, 50 tokens of 5 units and 70 tokens of 10 units. Every once in a while, the client will run out of the small denomination tokens, and so it will need to exchange the 10 unit tokens for tokens of smaller denomination. You need to decide the exchange protocol to get this done. The client may communicate with the server for this exchange.

• Integrity
  The client is sending the server the word and an element in the hash chain. If the hash chain element is corrupted, the server ignores the request. However, if some intruder corrupts the word in transit, the server will charge the client for a word which the client was not interested in. Hence, to preserve the integrity of the message you need to append a MAC to it. The MAC can be generated using the session-key exchanged between the server and client during session startup.

The way the system works is as follows:

• Setup:
  1. Exchange the public keys.
  2. Client picks up the random seeds for different denominations, generates the hash chains and sends the signed terminal values (SN's for each of the denominations) to the server and sets up a credit.

• Normal use:
  1. Do key exchange to setup a symmetric session key. All communication is encrypted using the session key.
  2. Client sends a word to spellcheck to the server. The message includes the word and the money (as tokens of appropriate denominations). This exchange is protected  by a MAC.
  3. When the client runs out of tokens of a specific denomination, it needs to exchange tokens of different denomination.

• Termination:
  1. When the server quits , it prints a statement billing the client for the usage along with a proof of spending, i.e the SN and SN-k values for the different denominations, plus the signature on SN's.

You need to decide on the message formats and the protocol for exchanging different denominations (i.e. exchanging a 10 unit token with 10 single unit tokens).

How You Should Do It

There are three steps to making the source code changes you need to make. The first step is to decide (at a high level) what cryptographic algorithms and what security protocols you will use. You have considerable freedom in this matter. The only restriction is that your algorithms/protocols must not require a third-party. You may reuse your code from the first programming assignment.

Having decided what schemes you will use, the next step will be to fix the details of the protocols. You will also need to design the message formats and the protocol flows to support your schemes.

Finally, you will need to implement your schemes and your implementation is subject to certain constraints:

1. spellc and spelld were designed for use on the Leland epic and elaine machines. You should ensure that your submissions work on those machines as we will test submissions on those machines.
2. You must use ANSI C (not C++ and not Java) for coding.
3. You need to modify the process() and init_security() functions (and cleanup() in the server), but you should not change any other code. Of course, you are free to add other, supporting functions. You should also not change the Makefile.

Again you have full access to the cryptolibrary. Do not use other crypto toolkits available on the Web. In addition to coding, you will also need to submit a writeup. The writeup should consist of three parts corresponding to the three design phases described above. It should describe the algorithms and protocols that you used and provide a justification for your choices. In addition, it should provide a description the message formats and flows that you actually implemented. This description needs to be detailed enough to allow someone to independently implement spelld and have it work with your spellc (or vice versa). Note that your writeup must be in plain ascii text format.

Submission

Put your source code (spell.h, spellc.c, spelld.c) and your writeup (writeup.txt) in a directory called ,/cs255 handin/p2. Make sure that this directory is readable by the course staff. If you are on AFS, give the group "cs255-admins" access using the following commands:

% fs sa , cs255-admins lr
% fs sa ,/cs255 handin cs255-admins all
% fs sa ,/cs255 handin/p1 cs255-admins all

When you have done this, send email to ajain@webclass.stanford.edu providing us with your (and your partner's) names, leland logins, and Stanford ID numbers. (Only one partner needs to send email.)