Discussion is an important part of life on the internet. Much happens in public, for example through established media or through social media. However, there's also a subset of discussions that need to happen confidentially. There are all sorts of scenarios in which people need to be able to express themselves, their opinions, and information that mustn't leak into the public domain, or otherwise be at risk of disclosure.

Confidentiality is a difficult property to guarantee online, especially if one takes the view that there can't be a trusted intermediary that could be hacked or subject to force majeure by government. How do we ensure that only the intended group of participants can engage in the discussion and see its content? How is this group formed and managed? What are the threats and attack vectors, and how can we address them?

(For a good discussion of these issues, you might want to read a recent interview with the CEO of Signal, Meredith Whittaker.)

One approach is to treat the system as being zero-knowledge and zero-trust. In zero-knowledge storage, any central exchange (such as the server holding the discussion) stores all the information encrypted using keys it doesn't possess, forcing all the cryptographic information to the participants. A zero-trust system takes the view that every interaction between machines needs to be encrypted and verified to catch malicious actors. (We will be discussing zero-knowledge and -trust in more detail in the W08 lectures.)

2. The assignment

Build a secure discussion system: a "secure Reddit", that can host discussions between groups of individuals in a way that maximises the confidentiality and privacy of the participants.

There are a lot of choices to make here, from the initial architecture, through the threat model, to the technologies you will deploy to counter the threats – and which you will then put together to form your final system.

You may use any implementation language and technologies you wish, as long as those technologies are "components" that you put together and not a ready-made solution that you copy. It's acceptable to use a crypto library; it isn't acceptable to use a discussion server someone else built.

3. Deliverables

You should submit the following two elements:

The code for your system

A short (5 pages max, plus any diagrams and references) justification of your design and technological choices. You should include evidence of your system working, and an argument of how it meets the brief.

This is an individual project, and you should submit both elements on MMS.

4. Housekeeping

Grading will follow the School's usual mark descriptors (https://info.cs.st-andrews.ac.uk/student-handbook/learning-teaching/feedback.html) The usual penalties for lateness will apply (https://info.cs.st-andrews.ac.uk/student-handbook/learning-teaching/assessment.html)

5. Hints

There are lots of possible solutions to this challenge, some completely different to the ones I mentioned above. An obvious alternative is to forego a central server and do everything peer-to-peer. This gives rise to a different threat model and different technological choices.

The spec says that the service needs to support "discussions". This strongly suggests that it can create and manage groups; it may imply that it manages joining and leaving, although there are other ways one could manage this.

Any design needs to start from an architecture (server based, peer-to-peer, ...) and then develop an understanding of the threats that the system faces. Only then can you select technology that's appropriate to tackle those threats.

Remember: you can't reveal what you don't know. Think very carefully about what a service actually needs to know, bearing in mind that anything it does know, it can potentially reveal.

There are many technological choices that matter – and many that really don't. The choice of where and how to use encryption is an example of a choice that matters; the exact elliptic curve used is an example of a choice that almost certainly doesn't matter very much. Focus on what matters.

Key exchange is always the biggest challenge in a secure system. And don't forget that keys can be lost or stolen, which is something an even minimally usable system has to deal with.