Cothority Web-Frontend – Interacting with Blockchains (Bachelor/Master)
We built a decentralised cryptography framework called Cothority, that we use for testing as well as for deployment of our distributed, decentralised cryptographic algorithms. The current web-frontend is able to interact with the some of the cothority services: http://status.dedis.ch. As time goes by, new services are added and need to fit into the frontend.
- Blockchains: Add features to our skipchain explorer. Add a mechanism to send arbitrary transactions via the web interface.
- Anonymity sets: Make a web-side application of the badges from a PoP service
- Use the ByzCoin ledger to store a password manager backup key in a threshold encryption scheme
- Implement e-voting in ByzCoin
Contact: Jeff Allen
Decentralising a Mobile Application (Semester/Bachelor/Master)
The Cothority is a platform for experimenting with decentralised technologies. Your task would be to identify a category of application (i.e. note taking, podcasting, password manager, messaging, e-mail, etc) and adapt an open source application to operate in the decentralised context. You will identify the parts of the app where data is stored into centralised systems, and then find a way to store that data in Cothority instead.
You should be experienced with Java. Previous experience with Android is not required. If you would like to adapt an existing iOS app, you will need previous experience with Swift or Objective-C.
Contact: Jeff Allen
Know Thy Neighbour: Approximate Proof-of-Location (Semester/Bachelor/Master/Thesis/PhD)
Applications such as the sharing economy would become more efficient with a ‘proof-of-location’. Relying on GPS coordinates, however, is not secure, because nodes could provide fake information. What if we simply instruct each participant to specify its location with respect to other participants? For example, Alice says she is 30 ms round-trip time from Bob and 50 ms from Carol, and publishes this information on the blockchain. Alice could still lie, but Bob and Carol can verify Alice’s claim and thus reinforce the information, or, on the contrary, infirm it. Alice chooses her reference nodes herself and, the closer they are, the tighter her location bounds and the more confident other nodes are about her location. Although latencies do not exactly map to geographical distances, very small latencies are, with high probability, between nearby nodes.
Your goal is to implement and assess the accuracy of such a system when an adversary’s nodes collude with each other. For the implementation we’ll use DEDIS’s Cothority platform, specifically its overlay network, written in Go. Experience with Go is a plus, though not required.
Locality-Preserving and Disaster-Resilient Blockchains (Bachelor/Master/Thesis/PhD)
In a scenario where you’re paying for your daily coffee with a cryptocurrency, does the merchant really require world-wide consensus to accept your payment? We believe the merchant should be able to choose: If he already knows you, then he probably trusts you and is ready to accept the transaction with a local consensus, for example within Switzerland. The global consensus on payment confirmation will arrive later, with a higher latency, and would still expose any double-spending to the merchant. When selling a car, however, the merchant will most probably wait for global consensus.
Our system, called Nyle, has three advantages: it survives WW3 scenarios where the global network is partitioned and cannot reach global consensus, speeds up local transactions and capitalizes on existing trust relationships between the transaction parties.
We already have implemented the consensus layer of Nyle; your task is to help implementing the blockchain layer on top. As a first step, you’ll implement a very basic blockchain from scratch. For the implementation we’ll use DEDIS’s Cothority platform, specifically its overlay network, written in Go.
How Local Are Ripple Transactions? (Semester)
We already know that economic activity is strongly-correlated with distance: the closer two companies are, the higher the flow of transactions between them (all else equal). The question is, do blockchain transactions show the same pattern? In this project, we’ll analyse Ripple transaction data. We’re interested in fine-grained location analysis, as much as possible. This project is for you if you enjoy working with data, like to find correlations with real-world events and think outside the box. There’s no programming language imposed.
Browser Plugin for Anonymous and Secure Email Communication (Semester/Thesis/Master)
Emails are still one of the most dominant ways for business and academic communication nowadays, but the email protocols do not provide any data protection by default. While OpenPGP is currently a de-facto standard for encrypting email content, it leaks important metadata in plain text, such as identities of recipients, encryption algorithms used and an actual length of the content. In addition to deanonymizing the communicating parties, it can lead to various problems, as breaking archived-for-years emails due to a discovered vulnerability in an encryption algorithm or inferring the results of an email exchange by the content length.
In DEDIS, we have designed a novel technique that enables encoding encrypted data and its related metadata as a uniform random string, only comprehensible by the intended recipient. The goal of this master project is to develop a browser plugin for anonymous and secure email communication using the designed technique. The starting point can be an open-source PGP plugin, like Mailvelope or E2Email, where the PGP part will be substituted.
Contact: Kirill Nikitin
Hide the network location of blockchain committees (Master Thesis/PhD Semester)
A promising scaling solution for blockchains is based on electing committees that run consensus. A serious drawback however in these solutions is that the committee members’ network position is easily identifiable which can lead to DDoS attacks on them.
In this project we want to look into anonymity networks in order to design and implement a “hidden committee” protocol that hides the network location of the committee members within the larger peer-to-peer gossip network.
How Susceptible are Blockchains to Network Partitioning? (Semester/Bachelor/Master)
Network partitioning is a serious problem for blockchains: a partitioned network cannot reach consensus on the state of the chain. But how likely is such an attack? Research has already shown evidence in the case of Bitcoin, but most other protocols ignore such attacks. In fact, most blockchain protocols analyze the traffic patterns in the gossip network, but disregard the actual BGP (Border Gateway Protocol) path taken by traffic, on an ISP level. That’s precisely what we want to look at first. We then want to see whether restricting the set of communicating blockchain peers greatly diminishes the consequences of an attack.
In this project, we will first look at real Internet traffic traces from CAIDA, to see whether traffic between two nearby peers stay local. For example, if both peers are in Switzerland, does their traffic transit only Swiss ISPs (Internet Service Providers) or does it cross the border? Perhaps this sounds surprising, but economic incentives of ISPs make such scenarios likely. Building on this analysis, we’ll devise a blockchain protocol that preferentially keeps traffic at the edge of the network and enables consensus in smaller areas (e.g., in Switzerland, between Swiss participants) in case of a global network partitioning.
Explorations of Clock-based Consensus (Semester/Master)
The goal of this project is to explore concepts around simplifying design and analysis of consensus algorithms by assuming the existence of a logical clock. Your task will be to make an algorithm to implement a logical clock that only advances when a threshold of the membership agrees, and then to specify and implement a consensus algorithm based on this logical clock. You will then extend your algorithms from the non-Byzantine case to the Byzantine fault-tolerant case. By measuring the behaviour of your implementation against existing algorithms you will prove or disprove that this decomposition of the problem is a useful direction to pursue.
You will choose the software tools to use according to your familiarity, to existing work you will leverage, and to the needs of the project. This project will start with a strong algorithmic and theoretical component, followed by a prototyping phase.
Contact: Jeff Allen