Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-04-03 Thread Felipe Dau 
Here is an update with the final proposal I submitted to GSoC.

Thanks,
-Felipe

# unMessage: an anonymity enhanced instant messenger

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.

## Technologies

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

## Contributions

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.

## Tasks

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.

### Improve setup script (T1)

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].

### Use attrs (T2)

[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].

### Support file transfer (T3)

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].
 
### Add a logger (T4)

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].

### Make functions/methods asynchronous (T5)

unMessage's initial implementation did not use Twisted

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-04-02 Thread Felipe Dau 
On Sun, Apr 02, 2017 at 04:51:40PM +, dawuud wrote:
> 
> Hi. I registered with Google to be a GSoC mentor for Tor Project.
> Hopefully Meejah will agree to be the backup mentor for this
> and register today or tomorrow before the deadline on Monday.
> 
> Let me know if there's anything else timely that I must do for this.

Thanks David!

Here is the proposal I have so far. Please let me know what you think.
(It is also hosted at
https://gist.github.com/felipedau/8b48c6fde875e673f62d7569a27f254a)

I intend to upload to the GSoC website tonight and add updates until
the deadline.

Thanks,
-Felipe

# unMessage: an anonymity enhanced instant messenger

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 on
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.

## Technologies

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

## Contributions

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] became
interested in contributing and mentoring it and assisted me on making
this proposal.

## Tasks

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.

### Improve setup script (T1)

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].

### Use attrs (T2)

[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].

### Support file transfer (T3)

unMessage is able to support various elements of a conversation such
as requests, messages

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-04-02 Thread dawuud 

Hi. I registered with Google to be a GSoC mentor for Tor Project.
Hopefully Meejah will agree to be the backup mentor for this
and register today or tomorrow before the deadline on Monday.

Let me know if there's anything else timely that I must do for this.


Cheers,
David


On Wed, Mar 29, 2017 at 12:03:44AM +, Felipe Dau wrote:
> On Tue, Mar 28, 2017 at 11:08:29PM +, dawuud wrote:
> > 
> > 
> > I suggest making sure your UI follows the pricinples outlined here:
> > 
> > User Interaction Design for Secure Systems
> > http://zesty.ca/pubs/icics-2002-uidss.pdf
> > by Ka-Ping Yee
> > 
> > 
> > for example:
> > "Path of Least Resistance.  The most natural way to do any task should
> > also be the most secure way."
> 
> Thanks David, that is a good suggestion. We did design it with
> security in mind, but there is certainly room for improvement and I am
> going to review the UIs.
> 
> > Does your client support revocation?
> > Ka-Ping Yee says:
> > 
> > "Revocability.  The interface should allow the user to easily revoke
> > authorities that the user has granted, wherever revocation is
> > possible."
> 
> That will also be included in the review. An example of something that
> unMessage does similarly is enabling presence. By default you do not
> tell your contacts when you are online (i.e., you do not connect to
> all of your contacts on startup), but it is possible to enable which
> contacts you wish to notify (as well as disable).
> 
> Do you think the tasks for the project should be a mix of
> code/structure and UI improvements?
> 
> P.S. I opened issues for all your suggestions and mentioned you on
> all of them. I just realized that is probably very annoying - I'm
> sorry for that. Let me know if you would like to copied though.
> 
> Thanks,
> -Felipe



> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev



signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-04-01 Thread dawuud 

Dear Damian Johnson,

i presume you are the one i should be sending this e-mail to.
i can be the mentor for this unmessage project.


~david


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-04-01 Thread Felipe Dau 
And here is the issue [0].

[0]: https://github.com/AnemoneLabs/unmessage/issues/40


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-04-01 Thread Alan S 
Delete my accountf

On Apr 1, 2017 9:45 AM, "Felipe Dau"  wrote:

> On Thu, Mar 30, 2017 at 02:48:45AM -0400, grarpamp wrote:
> > It's suggested and welcome that all overlay networks publicly
> > review, audit, analyze, each others work and offerings. Unfortunately
> > that hasn't develop much yet in a formal dedicated as responsibility
> > manner among even the larger opensource community, or even
> > discussion if that is a good idea. (But there is some good work in
> > some projects out there lately of their own work... automated code
> > linting, and the rarer procured third party audit.)
> >
> > Then shall we presume all our networks are equivalently secure?,
> > or equivalently flawed, as each network happens to advertise now and
> then.
>
> Makes sense.
>
> > This may leave the matter of partitioning up to the user to consider
> > pursuant to any note about that in the app documentation.
>
> I agree. Giving power of choice to the users is ideal.
>
> > The app could enable simultaneous multihome based on commandline
> > options... --tor --i2p --cjdns --other, default [whatever] .
> > And of course all the ports / addresses / bindings would need to
> > be flexible.
> >
> > On equivalent networks, presence is maybe a bigger issue than
> partitioning.
> > This includes concept to drop the network identity off the network
> itself,
> > or use new ID, not just managing announces to buddy list entries.
>
> Interesting! I opened an issue [0] to discuss this feature (copied
> your post there). It might take a while to work on that as we have
> other tasks with a higher priority, but I intend to get back to it at
> some point.
>
> Thanks,
> -Felipe
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-04-01 Thread Felipe Dau 
On Thu, Mar 30, 2017 at 02:48:45AM -0400, grarpamp wrote:
> It's suggested and welcome that all overlay networks publicly
> review, audit, analyze, each others work and offerings. Unfortunately
> that hasn't develop much yet in a formal dedicated as responsibility
> manner among even the larger opensource community, or even
> discussion if that is a good idea. (But there is some good work in
> some projects out there lately of their own work... automated code
> linting, and the rarer procured third party audit.)
> 
> Then shall we presume all our networks are equivalently secure?,
> or equivalently flawed, as each network happens to advertise now and then.

Makes sense.

> This may leave the matter of partitioning up to the user to consider
> pursuant to any note about that in the app documentation.

I agree. Giving power of choice to the users is ideal.

> The app could enable simultaneous multihome based on commandline
> options... --tor --i2p --cjdns --other, default [whatever] .
> And of course all the ports / addresses / bindings would need to
> be flexible.
>
> On equivalent networks, presence is maybe a bigger issue than partitioning.
> This includes concept to drop the network identity off the network itself,
> or use new ID, not just managing announces to buddy list entries.

Interesting! I opened an issue [0] to discuss this feature (copied
your post there). It might take a while to work on that as we have
other tasks with a higher priority, but I intend to get back to it at
some point.

Thanks,
-Felipe


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-03-30 Thread grarpamp 
On Wed, Mar 29, 2017 at 3:38 PM, Felipe Dau  wrote:
> Thanks for the suggestion. It should be possible to support multiple
> kinds of transport, but we still need to do some research on that
> because it might make some attacks
> possible/easier (e.g., partitioning attacks)? It would be great to
> have a discussion about that.

It's suggested and welcome that all overlay networks publicly
review, audit, analyze, each others work and offerings. Unfortunately
that hasn't develop much yet in a formal dedicated as responsibility
manner among even the larger opensource community, or even
discussion if that is a good idea. (But there is some good work in
some projects out there lately of their own work... automated code
linting, and the rarer procured third party audit.)

Then shall we presume all our networks are equivalently secure?,
or equivalently flawed, as each network happens to advertise now and then.

This may leave the matter of partitioning up to the user to consider
pursuant to any note about that in the app documentation.

The app could enable simultaneous multihome based on commandline
options... --tor --i2p --cjdns --other, default [whatever] .
And of course all the ports / addresses / bindings would need to
be flexible.

On equivalent networks, presence is maybe a bigger issue than partitioning.
This includes concept to drop the network identity off the network itself,
or use new ID, not just managing announces to buddy list entries.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-03-29 Thread Felipe Dau 
On Wed, Mar 29, 2017 at 03:57:29AM -0400, grarpamp wrote:
> You may want to link unmessage into the I2P network as well.

Hi grarpamp,

Thanks for the suggestion. It should be possible to support multiple
kinds of transport, but we still need to do some research on that
because it might make some attacks
possible/easier (e.g., partitioning attacks)? It would be great to
have a discussion about that.

Thanks,
-Felipe


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-03-29 Thread grarpamp 
You may want to link unmessage into the I2P network as well.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-03-28 Thread Felipe Dau 
On Tue, Mar 28, 2017 at 11:08:29PM +, dawuud wrote:
> 
> 
> I suggest making sure your UI follows the pricinples outlined here:
> 
> User Interaction Design for Secure Systems
> http://zesty.ca/pubs/icics-2002-uidss.pdf
> by Ka-Ping Yee
> 
> 
> for example:
> "Path of Least Resistance.  The most natural way to do any task should
> also be the most secure way."

Thanks David, that is a good suggestion. We did design it with
security in mind, but there is certainly room for improvement and I am
going to review the UIs.

> Does your client support revocation?
> Ka-Ping Yee says:
> 
> "Revocability.  The interface should allow the user to easily revoke
> authorities that the user has granted, wherever revocation is
> possible."

That will also be included in the review. An example of something that
unMessage does similarly is enabling presence. By default you do not
tell your contacts when you are online (i.e., you do not connect to
all of your contacts on startup), but it is possible to enable which
contacts you wish to notify (as well as disable).

Do you think the tasks for the project should be a mix of
code/structure and UI improvements?

P.S. I opened issues for all your suggestions and mentioned you on
all of them. I just realized that is probably very annoying - I'm
sorry for that. Let me know if you would like to copied though.

Thanks,
-Felipe


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-03-28 Thread dawuud 


I suggest making sure your UI follows the pricinples outlined here:

User Interaction Design for Secure Systems
http://zesty.ca/pubs/icics-2002-uidss.pdf
by Ka-Ping Yee


for example:
"Path of Least Resistance.  The most natural way to do any task should
also be the most secure way."


Does your client support revocation?
Ka-Ping Yee says:

"Revocability.  The interface should allow the user to easily revoke
authorities that the user has granted, wherever revocation is
possible."



cheers,

David


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-03-28 Thread Felipe Dau 
On Tue, Mar 28, 2017 at 09:43:12PM +, dawuud wrote:
> 
> Hey,
> 
> Cool project.

Thanks!

> Yes... write unit tests with pytest. Sounds good but I would
> suggest writing tests earlier in the development process next time.

I completely agree (and I feel bad for that).

> Does your project have a specification for this software?
> Otherwise I have to read the code to learn how it works.

I would not call that a specification, but we have written a few
pages of documentation. I totally forgot to add these references to
the post. There are currently usage instructions for the GUI [0] and
the CLI [1], and also its protocol [2]. The latter basically tells how
conversations are established and how the packets look like. That's
what we have written so far... That does not tell everything about
the app, but a very important part of it. Are there any specific
aspects you would like to see? I will start writing a bit about its
functioning.

> Using automat for the fsm sounds like a great idea. You probably
> will end up making several finite state machines and connecting them
> together in a graph. If you end up doing that you should probably first
> draw a picture... it helps to clarify.
> 
> I've recently started to experiment with automat myself and I've heard
> good things about it from my associates.
> 
> also you could add :
> 
> - hypothesis tests (fuzzing/property based tests)
> https://hypothesis.readthedocs.io/
> - changes to setup.py and add a requirements.txt
> - use python attrs to eliminate boiler plate code in your classes
> https://attrs.readthedocs.io/
> 
> as an example here's my fork of sphinx, a mixnet crypto library with
> 100% unit test coverage, hypothesis fuzzing, usage of attrs and a
> proper setup.py and requirements.txt file:
> 
> https://github.com/applied-mixnetworks/sphinxmixcrypto

Thanks! Those are great ideas! Very interesting!

> I'd be interested in collaborating with you and mentoring this project.

Thanks for the interest! From your suggestions, I believe the project
would be more "developer centered" and I think that is the right way
to go. The earlier we do that, the less we are going to regret when
things start to grow and get more complex. That is also a great
improvement to prevent bugs which can harm the UX as well as
anonymity/privacy/security. Do you think that's the approach we should
use for this proposal then? I am asking that because I do not know if
people would expect more features than "just" code improvements for a
project, if that makes sense.

> I'm not sure how much time I'll have in the coming months... we'll see.

Well, let me know if there is anything I can do about that.

Thanks David!
-Felipe

[0]: https://unmessage.readthedocs.io/en/latest/gui/gui.html
[1]: https://unmessage.readthedocs.io/en/latest/cli/cli.html
[2]: https://unmessage.readthedocs.io/en/latest/protocol.html


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-03-28 Thread dawuud 

Hey,

Cool project.

Yes... write unit tests with pytest. Sounds good but I would
suggest writing tests earlier in the development process next time.

Does your project have a specification for this software?
Otherwise I have to read the code to learn how it works.

Using automat for the fsm sounds like a great idea. You probably
will end up making several finite state machines and connecting them
together in a graph. If you end up doing that you should probably first
draw a picture... it helps to clarify.

I've recently started to experiment with automat myself and I've heard
good things about it from my associates.

also you could add :

- hypothesis tests (fuzzing/property based tests)
https://hypothesis.readthedocs.io/
- changes to setup.py and add a requirements.txt
- use python attrs to eliminate boiler plate code in your classes
https://attrs.readthedocs.io/

as an example here's my fork of sphinx, a mixnet crypto library with
100% unit test coverage, hypothesis fuzzing, usage of attrs and a
proper setup.py and requirements.txt file:

https://github.com/applied-mixnetworks/sphinxmixcrypto


I'd be interested in collaborating with you and mentoring this project.
I'm not sure how much time I'll have in the coming months... we'll see.


Cheers,

David



On Tue, Mar 28, 2017 at 07:23:16PM +, Felipe Dau wrote:
> Hello,
> 
> I am a Computer Engineering student at the Federal Technological
> University of Parana in Brazil and I would like to present you a
> peer-to-peer privacy enhanced instant messenger called unMessage [0].
> I have been working on it for a while with David Andersen [1] (my
> advisor) and we have recently released an alpha version which should
> be easy for developers to install and test.
> 
> It uses the Double Ratchet Algorithm [2] for encryption, Onion
> Services for transport metadata minimization, its own protocol for
> application metadata minimization, and as a result, provides private
> and anonymous conversations. It currently has basic features such as
> message exchange, user authentication and we very recently enabled
> voice chat using the Opus codec [3] for constant bitrate encoding.
> unMessage is a Python application that mainly uses pyaxo's [4]
> implementation of Double Ratchet Algorithm and txtorcon's [5]
> implementation of the Tor Control Protocol.
> 
> Since its current (alpha) release, we have been discussing it with
> Patrick Schleizer [6] and HulaHoop [7] from Whonix [8], 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 also allow it to be run on Tails) with help from
> meejah [9] by adding a new feature to txtorcon to make unMessage (and
> all the apps that use txtorcon) "Control Port Filter friendly".
> 
> As we believe unMessage has potential to become a great privacy
> enhancing app with a code that is simple, readable and therefore easy
> to maintain, Patrick suggested that I submitted a proposal to have
> unMessage as one of the GSoC projects. We expect to implement fixes,
> improvements and features from our discussions in order to turn it
> into a maintainable, feature-rich and useful app which the community
> can benefit from.
> 
> There are currently some "developer centered" tasks I can work on
> such as:
> 
> - Create a test suite (with pytest)
> - Make unMessage's own functions/methods behave like a Twisted API
>   should
> - Use automat for its finite-state machines
> - Make use of a logging tool
> - Improve comments/document the code
> 
> As well as some "user centered" tasks:
> 
> - Whonix/Tails support
> - Improve the GUI and CLI
> - File transfer
> - Use a friendlier approach for users to handle keys instead of
>   the current base32/64 encodings
> - Connect/launch Tor automatically depending on what is available
> - Offline messages
> 
> (All the other ones can be found in the issue tracker [10])
> 
> My intention with this post is not only to present unMessage to
> tor-dev but also see if someone is interested in mentoring me as it
> is not one of the official ideas but hopefully sounds like a good
> project. If someone gets interested, please let me know so that we can
> discuss which tasks would be interesting for this project and I am
> able to write a proposal.
> 
> Thanks!
> -Felipe
> 
> [0]: https://github.com/AnemoneLabs/unmessage
> [1]: https://github.com/rxcomm
> [2]: https://whispersystems.org/docs/specifications/doubleratchet
> [3]: https://opus-codec.org
> [4]: https://github.com/anemonelabs/pyaxo
> [5]: https://github.com/meejah/txtorcon
> [6]: https://github.com/adrelanos
> [7]: https://github.com/HulaHoopWhonix
> [8]: https://whonix.org
> [9]: https://github.com/meejah
> [10]: https://github.com/AnemoneLabs/unmessage/issues



> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

2017-03-28 Thread Felipe Dau 
Hello,

I am a Computer Engineering student at the Federal Technological
University of Parana in Brazil and I would like to present you a
peer-to-peer privacy enhanced instant messenger called unMessage [0].
I have been working on it for a while with David Andersen [1] (my
advisor) and we have recently released an alpha version which should
be easy for developers to install and test.

It uses the Double Ratchet Algorithm [2] for encryption, Onion
Services for transport metadata minimization, its own protocol for
application metadata minimization, and as a result, provides private
and anonymous conversations. It currently has basic features such as
message exchange, user authentication and we very recently enabled
voice chat using the Opus codec [3] for constant bitrate encoding.
unMessage is a Python application that mainly uses pyaxo's [4]
implementation of Double Ratchet Algorithm and txtorcon's [5]
implementation of the Tor Control Protocol.

Since its current (alpha) release, we have been discussing it with
Patrick Schleizer [6] and HulaHoop [7] from Whonix [8], 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 also allow it to be run on Tails) with help from
meejah [9] by adding a new feature to txtorcon to make unMessage (and
all the apps that use txtorcon) "Control Port Filter friendly".

As we believe unMessage has potential to become a great privacy
enhancing app with a code that is simple, readable and therefore easy
to maintain, Patrick suggested that I submitted a proposal to have
unMessage as one of the GSoC projects. We expect to implement fixes,
improvements and features from our discussions in order to turn it
into a maintainable, feature-rich and useful app which the community
can benefit from.

There are currently some "developer centered" tasks I can work on
such as:

- Create a test suite (with pytest)
- Make unMessage's own functions/methods behave like a Twisted API
  should
- Use automat for its finite-state machines
- Make use of a logging tool
- Improve comments/document the code

As well as some "user centered" tasks:

- Whonix/Tails support
- Improve the GUI and CLI
- File transfer
- Use a friendlier approach for users to handle keys instead of
  the current base32/64 encodings
- Connect/launch Tor automatically depending on what is available
- Offline messages

(All the other ones can be found in the issue tracker [10])

My intention with this post is not only to present unMessage to
tor-dev but also see if someone is interested in mentoring me as it
is not one of the official ideas but hopefully sounds like a good
project. If someone gets interested, please let me know so that we can
discuss which tasks would be interesting for this project and I am
able to write a proposal.

Thanks!
-Felipe

[0]: https://github.com/AnemoneLabs/unmessage
[1]: https://github.com/rxcomm
[2]: https://whispersystems.org/docs/specifications/doubleratchet
[3]: https://opus-codec.org
[4]: https://github.com/anemonelabs/pyaxo
[5]: https://github.com/meejah/txtorcon
[6]: https://github.com/adrelanos
[7]: https://github.com/HulaHoopWhonix
[8]: https://whonix.org
[9]: https://github.com/meejah
[10]: https://github.com/AnemoneLabs/unmessage/issues


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev