In an age where spying, surveillance and censorship evidently became regular practices by various kinds of attackers, it is sensible to be concerned about instant messaging applications, which are very popular communication tools that handle private and identifying information. Such a scenario demands solutions to prevent users from harm these attacks might cause.
There are currently good solutions such as Signal, Wire and OMEMO apps that make end-to-end encrypted conversations possible. Although such apps successfully provide privacy, they have a great dependency on servers and metadata in order to work and they are not able to provide anonymity. An app that solves this problem is Ricochet, by not having such dependencies. However, it heavily relies on the transport it uses and does not offer its own encryption layer.
unMessage is also one of those solutions: a peer-to-peer anonymity enhanced instant messenger written in Python that I have been working on for a while with David Andersen - my advisor. unMessage uses its own end-to-end encrypted protocol to maintain conversations, focusing in not depending on servers, metadata and transport. We have recently released an alpha version which should be easy for developers to install and test its current features such as message exchanges, authentication, and voice chat, but there is still a lot of work to do in order to achieve a mature state where users can trust it due to its properties and usability. As we believe unMessage has potential to become a great anonymity enhancing app with a code that is simple, readable and therefore easy to maintain, I propose to work on it during this year's Google Summer of Code with the support of the Tor Community to to make it closer to maturity. We expect to implement fixes, improvements and features from our discussions (on its tracker and tor-dev) in order to turn it into a maintainable, feature-rich and useful app which everyone can benefit from.
unMessage's features were possible with the use of the following technologies:
-
Transport makes use of Twisted, Tor Onion Services and txtorcon
-
Encryption is performed using the Double Ratchet Algorithm implemented in pyaxo - which uses PyNaCl
-
Authentication makes use of the Socialist Millionaire Protocol implemented in Cryptully
-
Transport metadata is minimized by Tor and application metadata by the unMessage protocol
-
User interfaces are created with Tkinter for the GUI and curses for the CLI
-
Voice chat uses the Opus codec for constant bitrate encoding
Since its current (alpha) release, we have been discussing it with Patrick Schleizer and HulaHoop from Whonix, who are making great contributions to help us test it, as well as suggesting new features and improvements. We are also working to run it on Whonix (which will allow it to be run on Tails as well) with help from meejah by adding a new feature to txtorcon to make unMessage (and all the apps that use txtorcon) "Control Port Filter friendly".
Since the introduction of this project for GSoC, dawuud and meejah became interested in contributing and mentoring it and also assisted me on making this proposal.
The project is split into tasks, each assigned an ID (in parenthesis) that is used to compose the timeline. I have been generous with how much time each task will demand and I am also leaving the whole week of each evaluation to review and make sure the deliverables meet expectations. Therefore, it is possible that I am able to work on additional tasks in case they consume less time than planned.
This task will improve unMessage's setup.py by removing redundant
package metadata, use files for the requirements and offer development
requirements. This task will be tracked in issue 35.
attrs is used to simplify the code by removing boilerplate, make it more concise, and consequently improve its quality. Classes definitions will be modified to use attrs' declarations so that attributes have default types and values, as well as validation. This task will be tracked in issue 34.
unMessage is able to support various elements of a conversation such as requests, messages and authentication. New elements to transmit file requests and the actual files will be added and handle by the elements parser. This task will be tracked in issue 12.
There is currently no logging being done and in order to debug, the only possible approach is using the UIs. A module will be added to send logs to the terminal and a file. This task will be tracked in issue 30.
unMessage's initial implementation did not use Twisted and it had
pre-defined callbacks in order to continue the path of the action it
was performing. It later migrated to Twisted but the pre-defined
callbacks are still used. Such callbacks will be removed and the
functions that are part of these asynchronous actions will return
Deferreds to make an actual callback chain. This task will be
tracked in issue 21.
This task will be split into two (T5A and T5B) as it poses a higher level of complexity. I intend to deliver its first version, receive feedback from mentors and make another iteration so that it meets our expectations.
There is not a single test written for unMessage and that is crucial
to continue its development. The test suite will be made with pytest
and will also use hypothesis for fuzzing/property tests. Not only
tests will be written, but some parts of the code will be refactored.
I do not expect to achieve 100% converage, but test the most important
parts of unMessage (mainly the peer module). Also, as I am not
familiar with User Interface tests, these will not be part of the task
(we are also planning to use a different framework for the GUI, so its
tests will only be created after there is a decision). This task will
be tracked in issue 33.
This task will be split into two (T6A and T6B) as it poses a higher level of complexity. I intend to deliver its first version, receive feedback from mentors and make another iteration so that it meets our expectations.
- Mid-term 1: Tasks 1, 2, 3 and 4
- Mid-term 2: Tasks 5A and 6A
- Final: Tasks 5B and 6B
| Tasks/Weeks | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| T1 | X | ||||||||||||
| T2 | X | ||||||||||||
| T3 | X | X | |||||||||||
| T4 | X | X | |||||||||||
| T5A | X | X | |||||||||||
| Mid-term 1 | X | ||||||||||||
| T6A | X | X | |||||||||||
| Mid-term 2 | X | ||||||||||||
| T5B | X | ||||||||||||
| T6B | X | X | |||||||||||
| Final | X |
As mentioned in the previous section, depending on how the development of each task it is possible that there will be more time avaialable to work on other ones. We would like to prioritize the following tasks in case that happens.
There are certain objects in unMessage that are state machines. Their implementation are very simple and limited as initially they were not designed as state machines. In order to turn them into real state machines, automat will be used. This task will be tracked in issue 26.
As part of unMessage's design, no servers are used to establish and maintain conversations. As a consequence, peer-to-peer communication requires users to only be able to chat while both are online. Although unMessage's protocol supports asynchronous communication, this limitation forces conversations to be synchronous. In order to solve this problem, a Tahoe-LAFS grid will be used to temporarily store unMessage's packets for peers that were not available when they were sent and can be retrieved later once the peers are online. This task will be tracked in issue 32.
I am a Senior studying Computer Engineering at the Federal Technological University of Parana in Brazil. In January of 2014 I went to the U.S. for an exchange program, which lasted until December. During the Summer of that same year, I joined a research project lead by David Andersen where I learned about Anonymous Communication and became so attracted to the field that I continued to be part of the project since then. We have mostly worked on nymphemeral, pyaxo, nymserv and recently, unMessage.
I have a few repositories on my GitHub profile and I recommend taking a look at the ones referenced above, but specially unMessage and nymphemeral, which are the ones I have mostly worked on.
As I mentioned, I have been studying Anonymous Communication for almost three years now and I intend to keep doing it not only because I enjoy it, but because it is an important field capable of helping millions of people around the world.
In my opinion, The Tor Project is the biggest organization of its kind and working with people responsible for software I run everyday is a dream of every developer.
The Tor community continues to grow every day and I believe that participating in the Google Summer of Code will also contribute to that.
Since I joined the research project, I have been mostly working with David Andersen on the projects I mentioned previously and git/GitHub make our work a lot easier to work in parallel on the same code, manage tickets to help us keep track of the development and interact with contributors interested in what we do.
Whenever I see a project which I can contribute to, even if a it is a small change, I open a ticket or make a pull request if I am able to. My GitHub profile lists all my contributions.
PyNaCl is one of the recent projects I contributed to. While working on pyaxo I noticed some of the encryption calls could be improved to simplify their usage by making an argument optional. The developer who reviewed the pull request was very positive about it and assisted me while updating the docs to cover this new change.
While working on unMessage I asked Patrick Schleizer and HulaHoop for help as it would be great to have it running on Whonix. We have had great discussions and contributed to both projects in order to provide this feature. Along with the development, some changes to txtorcon were appreciated and we have also been working with meejah on that.
I have concluded all classes for my degree and I am currently an industrial IT intern at an Engineering and Software company, which is the only commitment I will have besides GSoC throught the duration of the program. I intend to work on unMessage 5~6 hours on weekdays and the remainder of the workload on weekends.
The tasks we picked to work on GSoC are a subset of all the ones we have been discussing during unMessage's development, which means that there will be more work to be done after GSoC. Also, unMessage is quite a big project. There are lots of possibilities to explore in the instant messaging field as well as many challenges to overcome when offering an application with usability and features as good as the popular ones, while protecting users' privacy and anonymity. I intend to keep working on unMessage until we have an application that accomplishes our goals as well as maintain it to fix bugs and add features demanded by the community.
Also, as I have been working with anonymous communication for a while, I do not see myself going somewhere else soon, so the chances of keeping contributing the Tor community are high.
I intend to use IRC to discuss with my mentor and other tor devs (who wish to contribute to the project) about ideas and actions to be taken.
To formalize what is discussed on IRC, I will use unMessage's tracker on GitHub to manage features/enhancements/issues to keep records and maintain an organized environment for the development of the project, as well as interact with contributors. I am suggesting this tracker as we have already been using it for a while, but I can migrate to Tor's Trac if needed.
To summarize everything, I will do what seems to have worked well for previous students: regular reports on the mailing list to keep people updated with what is happening on the project from a higher level.
OFTC: dau
Email: dau@riseup.net
PGP: 0xC5A49047572A0D47
I am only applying to this one.
I encourage you to take a look at the git logs and issue trackers from unMessage, nymphemeral and pyaxo. I think I am a very organized developer and I have been trying my best to follow the gitflow model and take advantage of the features offered by GitHub.
attrs: https://attrs.readthedocs.io
automat: https://github.com/glyph/automat
cli: https://unmessage.readthedocs.io/en/latest/cli/cli.html
cryptully: https://github.com/shanet/Cryptully
curses: https://docs.python.org/2/library/curses.html
david andersen: https://github.com/rxcomm
dawuud: https://github.com/david415
documentation: https://unmessage.readthedocs.io
double ratchet algorithm: https://whispersystems.org/docs/specifications/doubleratchet
github profile: https://github.com/felipedau
gui: https://unmessage.readthedocs.io/en/latest/gui/gui.html
hulahoop: https://github.com/HulaHoopWhonix
hypothesis: https://hypothesis.readthedocs.io
issue 12: AnemoneLabs/unmessage#12
issue 21: AnemoneLabs/unmessage#21
issue 26: AnemoneLabs/unmessage#26
issue 30: AnemoneLabs/unmessage#30
issue 32: AnemoneLabs/unmessage#26
issue 33: AnemoneLabs/unmessage#33
issue 34: AnemoneLabs/unmessage#34
issue 35: AnemoneLabs/unmessage#35
meejah: https://github.com/meejah
nymphemeral: https://github.com/felipedau/nymphemeral
nymserv: https://github.com/rxcomm/nymserv
omemo: https://conversations.im/omemo
opus codec: https://opus-codec.org
patrick schleizer: https://github.com/adrelanos
protocol: https://unmessage.readthedocs.io/en/latest/protocol.html
pyaxo: https://github.com/rxcomm/pyaxo
pynacl: https://github.com/pyca/pynacl
pytest: http://docs.pytest.org
ricochet: https://ricochet.im
signal: https://whispersystems.org
socialist millionaire protocol: https://en.wikipedia.org/wiki/Socialist_millionaire
tahoe-lafs: https://github.com/tahoe-lafs/tahoe-lafs
tkinter: https://docs.python.org/2/library/tkinter.html
tor onion services: https://www.torproject.org/docs/hidden-services.html
tor-dev: https://lists.torproject.org/pipermail/tor-dev
tracker: https://github.com/AnemoneLabs/unmessage/issues
twisted: https://twistedmatrix.com
txtorcon: https://github.com/meejah/txtorcon
unmessage: https://github.com/AnemoneLabs/unmessage
whonix: https://whonix.org
wire: https://wire.com