[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[freehaven-dev] paper outline

This is a draft off the top of my head. Comments appreciated as always.
It's sketchy towards the end. 

"Freee Haven : Towards the Specification, Design, and Modelling of a 
Robust Anonymous Storage System"

1. Introduction

1.1 Short summary of project ("We present the Free Haven project...") 
1.2 Motivation for Anonymity 
1.3 Short Description Of Why This Is Really Hard
1.4 Organization of the Paper

2 Definitions

2.1 "Storage System" 

2.1.1 Intuitive idea -- examples of storage systems Hard Drive RAID Broadcast Disks 

2.1.2 Definition of Storage System "Add" "Retreive" 

2.1.3 Requirements for Storage Systems Robustness Integrity Efficiency Access Control 

2.1.4 Distinction between "Storage" and "Publication" Publication implies high availability Publication implies high update capability (fresh data)

2.2 "Anonymous or Pseudonymous communication channel" 

2.2.1 Intuitive idea and motivation Voting protocols Spycraft Distinction between Anonymity and Pseudonymity
	(hereafter conflated as "Nymity" for discussion until
	we reach the point where one is easier than the other)

2.2.2 Examples of *nymous Channels Chaum MIXes Dining-Cryptographer Nets Onion Routing / ZKS Public Bulletin Boards

2.2.3 Requirements For *nymous Communication Channel Reliability Low Latency Integrity Anonymity (but what's that?)

2.2.4 Pinning Down / Defining Nymity Intuitive notion - "Can't link message to sender." Parties Involved
???  as we found out, this part may be a little tricky. Adversaries Computationally Bounded vs. Computationally Unbounded "Active" vs. "Passive" adversaries Pseudonymity vs. Anonymity Pseudonymity at least as hard as Anonymity, maybe harder

2.2.5 General Attacks and Possible Countermeasures Traffic Analysis Message Pools, Reordering Heartbeats "Latency vs. Nymity" Usage Patterns ("intersection attack") Stupid User Tricks (e.g. "ask browser for user's name. gee.") Which Attacks Can and Probably Can't Be Prevented

2.2.6 Extant Formal Definitions of Anonymity For Communication Channels Chaum's Definition and Proofs "Probabilistic Anonymity" from SG-MIXes Quantified Anonymity - Crowds (and Roger)
	-i.e. "You are 50-anonymous" Reasoning About Quantified Anonymity - Syverson

2.2.6 Where Definitions Need More Work (if anywhere) 

2.2.7 Cool Ideas Which No One Has Really Analyzed Yet Garlic Routing -- address "robustness" Constantly Changing Addresses (suggested by us, also seems by this
	Dogan Kesdogan guy) "Alien Conspiracy" routing "Variable Implicit Addresses" (Dogan Kesdogan again)
whatever else...

2.3 "Anonymous Protocol" 

2.3.1 Distinction between an anonymous channel and anonymous protocol
	(similar to the distinction between a "secure channel" and 
	a "secure protocol" for multiparty computation)

2.3.2 The "Ideal Model" (suggested by Anna. Thanks, Anna!) Motivation : Secure Multi-Party Computation Problem and Definitions of Secure Multiparty Computation
	(just a sketch. no need to add 300 pages for this section) Towards A Definition of Ideal Anonymous Protocol "Let's Play A Game : Who Wants To Be An Adversary?"
	we don't have nice formal defintions here. but we can 
	sketch more or less what they might look like and cite it
	as an open problem. with the major caveat that bad definitions
	will allow you to prove true things which are useless.
	(maybe make a straw man bad definition and show how it fails

3 Specification of the Free Haven System 

<see Roger's Thesis> 

3.1 Goals of Free Haven (in terms of previous definitions)

3.2 Outline of Free Haven
3.2.1 Servnet
3.2.2 Nodes and Their Properties

3.3 The Communications Module 

<all class responsibility diagrams and whatever go here> 
<yes, I know, we don't have classes>

4. Modelling the Free Haven System 

<see model.tex> 

5. Attacks on Free Haven

6. Evaluation of Free Haven 

6.1 Free Haven as Storage System
6.2 Free Haven as Anonymous Protocol

<Roger's chart goes in here>

7. Comparison to Related and Alternate Work

7.1 Freenet
... and everything else .

8. Future Directions and Open Problems