Implementations
Please note that this list is NOT updated on a regular basis. See the github repository for all currently avaialble plug-ins: [URL1] [URL2]
Plug-ins available on Layer 4 (transport layer - the socket types hide the anonymization process from Layer 5 applications):
| Name | Description | Code |
|---|---|---|
| Stream Socket | A Socket with interfaces almost equal to those of normal TCP/IP sockets (containing java.io.OutputStreams and java.io.InputStreams and a ServerSocket class vor mixes). Stream Sockets can be configured to be simplex or (full-)duplex. They are always connection-based, reliable and order-preserving. | github |
| Datagram Socket | A Socket with interfaces almost equal to those of normal UDP/IP sockets. Datagram Sockets can be configured to be (full-)duplex, reliable and order-preserving and are thus more flexible than normal UDP/IP sockets. Datagram Sockets are implicitly not connection-based. | github |
| Connected Datagram Socket | Connection-based variant of the Datagram Socket above. Features connect() and disconnect() methods. Connected Datagram Sockets can be configured to be (full-)duplex, reliable and order-preserving. | github |
Plug-ins available on Layer 3 (The purpose of Layer 3 (output strategy/flushing algorithm) is to hide the true sender of a message among other senders (build an anonymity set) by delaying and reordering messages):
| Name | Description | Reference | Code |
|---|---|---|---|
| Binomial Pool | A timed pool that tosses a biased coin for each message (every x ms) to decide whether to forward a message or not. Uses the normal cumulative distribution. | Diaz et al. 2003 | github |
| Binomial Plus Pool | A timed pool which is similar to the Binomial Pool (see above), but can be adapted so that it has a pool of at least n messages (Section 4.1 of the paper on the right). | Serjantov 2007 | github |
| Logarithmic Pool | A timed pool that tosses a biased coin for each message (every x ms) to decide whether to forward a message or not. Probability to forward a message: 1-((log(M)/M))), where M is the number of messages in the pool. See Section 4.2 of the paper on the right. | Serjantov 2007 | github |
| Square Root Pool | A timed pool that tosses a biased coin for each message (every x ms) to decide whether to forward a message or not. Probability to forward a message: 1-((1/sqrt(M)))), where M is the number of messages in the pool. See Section 4.2 of the paper on the right. | Serjantov 2007 | github |
| Basic Cottrell Pool | Waits until x messages are collected. For every successive message, chooses one of the collected messages (including the newly arrived one) at random and forwards it. | Cottrell 1995 | github |
| Cottrell Random Delay | Delays incoming messages at random. | Cottrell 1995 | github |
| Timed Cottrell Pool | Forwards x (x = "number of messages in pool" - "minimum pool size") messages every "output interval" ms (if x >= 1; messages are chosen at random). Note that the plug-ins "Timed Cottrell Pool", "Timed Dynamic Pool" and "Mixminion Pool" are basically the same thing, implemented slightly different. | Cottrell 1995 | github |
| Timed Dynamic Pool | Output strategy used in Mixminion according to Mixminion spec v1.31 2007/04/21 (last checked on 31.08.2012). Note that the actual Mixminion implementation (31.08.2012) is slightly different. A Java port of the actual (29.08.2012) Mixminion implementation can be found below. Also note that the plug-ins "Timed Cottrell Pool", "Timed Dynamic Pool" and "Mixminion Pool" are basically the same thing, implemented slightly different. | Cottrell 1995, Mixminion spec v1.31 | github |
| Mixminion Pool | Java port of the actual Mixminion implementation (31.08.2012). Note that the plug-ins "Timed Cottrell Pool", "Timed Dynamic Pool" and "Mixminion Pool" are basically the same thing, implemented slightly different. | Cottrell 1995, Mixminion source code | github |
| Threshold Pool | Waits until x + y messages are collected and than forwards y messages (chosen at random). When "y = 1", same as the "Basic Cottrell Pool" | Serjantov et al. 2002 | github |
| Proportional Method Pool | Proportional scheduling method applied to mixes. A "Basic Cottrell Pool" for connection-based mixes. Gurantees that messages belonging to the same user are forwarded FCFS (First Come First Serve). | Mishra et al. 2012 | github |
| Basic Batch | Waits until x messages are collected and than forwards all in random order. | Chaum 1981 | github |
| Timed Batch | Forwards messages every "output interval" ms. | Serjantov et al. 2002 | github |
| Threshold And Timed Batch | Forwards all messages every "output interval" ms, if at least x messages are batched. | Serjantov et al. 2002 | github |
| Threshold Or Timed Batch | Forwards all messages whenever x messages are batched or every "output interval" ms. | Serjantov et al. 2002 | github |
| Stop-And-Go | Clients draw random delays for a set of SG-Mixes from an exponential distribution and store theses delays (together with a time window) in the layered headers of the mix messages. If a messages arrives at a SG-Mixe befor or after the specified time window, the message is dropped. Otherwise, the message is forwarded after the specified delay. | Kesdogan et al. 1998 | github |
| Constant Rate | Simplified version of the ISDN-mixes. Output strategy for channel-based mixes with constant dummy traffic. Will forward messages only if every user has provided exactly one message (or an optional timeout is reached). Does NOT link send and receive channels through implicit addresses and broadcast as in the ISDN-mixes paper. | Pfitzmann et al. 1991 | github |
| Wait For Reply | Output strategy for channel-based full-duplex mixes with constant dummy traffic. Will forward messages only if every user has provided exactly one message (or an optional timeout is reached). Users will wait for a reply packet before sending the next message. | none | github |
| DLPA | The Dependent Link Padding Algorithm. An output strategy for channel-based mixes. Provably finds the minimum joint sending rate for a given set of connections and a global maximum message delay bound. Requires clients to send no dummy traffic as the first mix will add dummies. Requires the (final) receiver to be able to receive dummy messages to be "secure" against traffic analysis. Implemented as described in Fig. 3 of the paper on the right, i.e. none-heuristic. | Wang et al. 2008 | github |
| No Delay | Forwards messages immediately as with Crowds, Tor or JonDonym. Does NOT provide any anonymity. Useful for baseline measurements when evaluating output strategies and for low latency anonymous communication (assuming only "local" attackers). May also be used as basis for implementing a new plug-in. | none | github |
Plug-ins available on Layer 2 (recoding scheme - Layer 2 plug-ins are responsible to make it cryptographically difficult to link messages entering and leaving mixes (bitwise unlinkability), pad messages to equal length and discard replays):
| Name | Description | Code |
|---|---|---|
| Sphinx | Sphinx [Danezis et al. 2009] is optimized for services with typically short messages (e.g. e-mail). It uses a blinding logic, key derivation and Bernstein's Curve25519 to minimize overhead. Its security is proven in the random oracle model (what doesn't mean this implementation can't be faulty). Our implementation is a Java port of the Python reference implementation provided here. The plug-in can take advantage of multi-core/CPU systems. | github |
| Sphinx_Channel | A plug-in for long-lived anonymous channels. Uses Sphinx (see above) to establish anonymous channels and AES for the following messages. The plug-in can take advantage of multi-core/CPU systems. | github |
| RSA_AES_Channel | A plug-in for long-lived anonymous channels. Uses RSA (in OAEP mode with configurable key size) to establish anonymous channels and AES (in OFB mode with configurable key size) to send data in cells (again of configurable size). Uses HMAC-SHA256 for message integrity. This scheme uses the same crypto primitives as JonDonym (as described in [Westermann et al. 2010]), but is not compatible (it is optimized for flexibility, e.g. different key sizes or header fields). The plug-in can take advantage of multi-core/CPU systems and is order-preserving. Requires a Layer 1 plug-in that offers reliable transfer (e.g. the TCP plug-ins below). | github. |
| RSA_AES_LossTolerantChannel | A plug-in for long-lived anonymous channels. Uses RSA (in OAEP mode with configurable key size) to establish anonymous channels and AES in CBC mode with explicit initialization vectors (IV) to send data in cells (again of configurable size). Uses the same mechanism as DTLS to tolerate dropped cells (prepends IVs to the cells' encryption layers). Uses HMAC-SHA256 for message integrity. The plug-in can take advantage of multi-core/CPU systems. | github |
| RSA_OAEP_AES_OFB | A plug-in for message-based communictaion (like e-mail). The RSA_OAEP_AES_OFB plug-in is pretty close to the original work of David Chaum, but uses different crypto primitives (RSA-OAEP and AES-OFB). Uses HMAC-SHA256 for message integrity. The plug-in can take advantage of multi-core/CPU systems and supports Reply Addresses. The plug-in is built for cascades, i.e., it is not length-preserving. | github |
| RSA_OAEP_sourceRouting | A length-preserving variant of the RSA_OAEP_AES_OFB plug-in above. | github |
| No Delay (null cipher) | Forwards messages WITHOUT applying any cryptographic operations. Useful for debugging and to perform baseline measurements in evaluations. May also be used as basis for implementing new plug-ins (understanding interfaces etc.). | github |
Plug-ins available on Layer 1 (Layer 1 (network layer) provides point-to-point connections between anon nodes (mixes and clients) and thus hides the details of the underlying communication channels):
| Name | Description | Code |
|---|---|---|
| Cascade TCP | Contains several TCP/IPv4 connection handlers for mix cascades (fixed routes): A synchronous, Round Robin handler for client connections. A multiplexd, synchronous connection handler for communication between mixes. Several asynchronous (First Come First Serve) handlers implemented with different frameworks (Netty, MINA, Grizzly, NIO) for client connections. Most handlers are duplex, offer reliable transfer and are connection-based and order-preserving. | github |
| Cascade UDP | Contains asynchronous First Come First Serve UDP/IPv4 connection handlers for mix cascades (fixed routes). The handlers are simplex only, offer none-reliable transfer and are not order-preserving. | github |
| Source Routing TCP | Contains two TCP/IPv4 connection handlers for mix networks (source routing and dynamic routing): A synchronous, duplex, Round Robin handler for client connections. A multiplexd, duplex, synchronous connection handler for communication between mixes (maintains static connections to all other mixes). Both handerls are duplex, offer reliable transfer and are connection-based and order-preserving. | github |