University of Hamburg
Department of InformaticsWorking group Security in Distributed Systems
architecture

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

[back to top] [report bug]

News

06.27.2015
New gMix VM and Tutorials are online [URL]

05.01.2015
New version of gMix framework available on GitHub [URL]

05.01.2015
New website is online

02.13.2015
Paper accepted for Elsevier Computers & Security journal :-)

10.22.2014
Experiment descriptions, executables and source code for the paper Workload Modelling for Mix-based Anonymity Services are online now [URL]

06.13.2014
Paper about EncDNS accepted at ESORICS 2014 :-)

See more...