Project Ideas

moba edited this page Feb 9, 2018 · 19 revisions

GSoC 2018

This is a page showing all proposed ideas for our application for the Google Summer of Code.

About Katzenpost

Katzenpost is a framework for message anonymization: Its goal is to hide communication metadata from third parties, allowing two parties to communicate securely. This is a specialized area of research, and we expect potential students to be familiar with Mixnets. A good starting point is the Loopix Anonymity System paper. More reading material can be found in the Mixbib.

Katzenpost's core components are written in Go. We have experimental bindings for Python and Java/Android.

"One patch" rule

We require one accepted patch (pull request) from each potential GSoC student, before accepting the student for GSoC participation. The reason for this requirement is that you can show us that you have succeeded in building Katzenpost, and that you have understood a little piece of Katzenpost's code and are able to improve it.

Keep in mind that mentoring is about providing guidance to help you solve your task, but we don't have the resources at this point to keep holding your hand. It's important for us to know that you can code and solve technical challenges on your own, while also maintaining a constructive dialogue of relevant design decisions with us.

Contribution Guidelines

  1. Get familiar with our various repositories on Github. If you want help with that, come and ask on our IRC channel!
  2. Join the development mailinglist.
  3. Fork our code, try kimchi and start contributing (the best part ;) ).
  4. If you have questions ask on the mailinglist, or on IRC.
  5. Open a pull request on Github. We will help with occurring problems and merge your changes back into the main project.

Google Summer of Code Registration Procedure

  1. Have one patch accepted in any of the Katzenpost code repositories.
  2. Lookout for interesting tasks on this page, then choose one you would like to work on. If you have an interesting task of your own in mind, you can also propose your own ideas - if you do, make sure to leave enough time to discuss it with us!
  3. Apply officially on the Google Summer of Code page (Registration opens on March 12th 2018). In your proposal, outline your understanding of the task you picked. This should include a description of the task from your perspective, challenges and design decisions you expect to encounter along the way, and a rough timeline for your implementation ideally based around four milestones (i.e., one every three weeks). Make sure to allocate some time for writing tests and code review!


GSoC has two formal evaluation points, at the mid-term and at the end. These evaluations determine if you receive the stipend from Google. In order to receive a pass for the evaluations you will need to show adequate progress toward your project's goals. We have a number of mechanisms to help you meet your goals and get in touch with us and other developers:

  • We have a weekly developer meeting on IRC, where all students talk about their last week's progress, challenges and milestones. We will also inform you about our own progress and current plans during this meeting.
  • You need to have a public branch for your code to which you commit regularly. To this end, you will be granted write access to our repository after we accept your first larger pull request.
  • Students are encouraged to track their progress and milestones on our Github issue tracker.
  • You are encouraged to write blog posts for our website.

Remember: we want you to succeed and we'd like you to stick around.


This is a list of larger tasks which we have on our roadmap, and which we feel are well suited for GSoC projects. This is not an exhaustive list, if you have a great feature in mind feel free to suggest your own! We are always up for discussion.


Task description: Implementation of auto-responding clients that a provider can offer and announce to the network. See This project would involve becoming familiar with our other [](specification documents). Autoresponding clients which are always online can be used for a variety of purposes such as:

  • keyservers
  • remote message retrieval for stronger location hiding properties (as compared to the Loopix provider model)
  • bulletin board systems and mailing lists

Potential mentor: David

Improve Integration Test Framework

Task description: Make improvements to kimchi, our mix network testing framework which essentially runs the entire mixnet in a single go process. You can find the source code to our kimchi tool at Some of the possible improvements would be:

  • Make kimchi work well with travis or other integration testing systems. Currently kimchi does not halt unless it receives a control-c from stdin.
  • Add some well defined tests to kimchi.
  • Configuration file for kimchi.

Potential mentor: Yawning

Improve Detection of Broken Network States

Task description: Anomalies on the network, like downtimes of mixes, are likely to be detected quickly by some party. The authorities will learn about a class of these problems only around the next epoch. We currently have no design to propagate information about various other failing states (disappearing ACKs, broken loops). Even something as simple as a user's provider disappearing is not something that users (or other providers) can easily learn about. The first step here may be to create a test environment, potentially using our nix packages and nixops, to be able to then mess with the test environment to identify the various failed states a component can be in. Then, we can think about how to propagate that information quicker towards users and/or administrators. This is especially interesting since the Loopix design allows us to detect misbehavior of nodes and certain active attacks.

Potential mentor: Moritz


Task description: We want our mixnet framework to be useful for research, and at the same time we want mixnet operators to be able to monitor the state of their nodes. It would be cool to think of all the data we can gather for diagnostics purposes, separate them into two categories (sensitive and only for debugging and research purposes vs. public), how to expose and collect that data, and how to feed it into one of these modern monitoring dashboards.

Potential mentor: Moritz


Task description: Playing with a Katzenpost mix network for testing purposes currently requires fiddling with configuration files spread across multiple machines. We are interested in using a modern deployment management console to make this easier. (nix, ansible, puppet, chef).

Potential mentor: Moritz

Automated Builds

Task description: We want the different Katzenpost components to be packaged nicely for various target platforms and distributions.

Potential mentor: Moritz

Link Layer SCTP

Currently we use a noise based cryptographic link layer (see ), that is, the protocol that all the mix network components use communicate with each other. However katzenpost currently uses TCP to transport these wire protocol commands. Using a different transport protocol could be more efficient for a number of reasons include possibly avoiding head-of-line blocking problems by sacrificing some reliability. Partial reliability on the link layer could possibly be acceptable due to our end to end reliability protocol, a Stop and Wait ARQ that the client and the Provider use as specified in

Task description: Investigate using SCTP with the partial reliability extension as a internal transport. There's advantages to using something like this, but the security aspect of it is non-trivial.

Potential Mentor: Yawning

Message Queue: Support datasets larger than available system memory

Task description: See core#11.

Potential Mentor: Yawning

Alternative Wide Block Ciphers

Task description: Investigate alternative wide-block ciphers to AEZv5. Might not be fast enough because AEZv5 is obnoxiously fast with hardware support, but the decrease in performance may be acceptable for the extra benefits (primarily higher security level).

Potential mentor: Yawning

Network Simulations with NS-3

Task description: ns-2 and ns-3 have been used by network protocol designers for many years. Often, new network protocols or changes to existing protocols are published in an academic paper and accompanied with ns-2 or ns-3 source code of a network simulation. See for more information. Mix network simulations using ns-3 can be used to accomplished a variety of goals such as:

  • measure network performance
  • measure quality of service
  • measure resistance to DoS attacks
  • observe congestion control algorithms in different scenarios
  • testing the viability of using ECN/source quench to pass the congestion information to the client in less time than the round trip time of their forward message. This is significant because normally congestion control algorithms use packet loss as a signal of upstream congestion.
  • determine if our congestion control algorithm can prevent congestion collapse

Potential mentor: David

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.