11/16/00 --- mix-net - Last two lectures discussed how to proof identity. Today we talk about how to keep confidential the identity of the sender. This problem appears difficult, since one today Internet we can in principle trace transmissions to its origin. - Why hide your identity? - privacy - to do something bad - One approach: mix-nets [chaum 1981] - A message with data is forwarded through a series of independently operated nodes (called a mix); 1 through n. Lets say s is source and d is destination. The sender picks mix 1 through n from a large collection of nodes. - Each messages contains a set of instructions and data. The instructions tell the mix to which mix to forward the message to and which key to use to encrypt the remaining instructions and data. - Each mix has a public/private key pair (Kipub, Kipriv) - The instructions for each mix are encrypted with Kipub---thus only mix i can read them. - Assumption: Mixes don't collude. In practice, pick mixes in different places in the world, run by different administrators under different laws. - The idea is to recursively encrypt instructions with Kipub: s encrypts with Knpub "Please forward message to d" = C. s encrypts with Kn-1pub "Please forward message to node n and encrypt with Kn; C" etc. Thus, message to mix 1 is E(K1pub, "Please forward message to mix 2 encrypted with K1pub" + E(K2pub, "Please forward message to mix 2" + ....)) Mix 1 decrypts with K1priv and finds "Please forward message to mix 2 encrypted with K2pub + ...". mix 1 cannot read "...", since it is encrypted with K2pub. It encrypts the "..." and a header new header that contains the addres of mix 2; and outputs the resulting message. - The main purpose of a mix is to hide the correspondance between its sealed input and its unsealed output. To make the above scheme better we want: - process a batch of input messages at the same time and reorder them. - make each message really different. the mix could add a random number and encrypt it with the rest of the instruction and data. - message should have a fixed-length. the sender should fragment data if it doesn't fit in a single message. - intermix cover traffic among regular traffic - remove duplicate messages - protecting against abuse (e.g., hashcash) - encrypt data with a symmetric key each time it passes through a mix. - etc - Implementation - special fields in email headers. for example, type-1 remailer: Anon-To: ... Latent-Time: Encrypt-key: followed by a marker line - Other approaches: - Onion routing (for IP routing) - Crowds (for web browsing)