Tor at the Heart: Tor Messenger

by arlo | December 14, 2016

During the month of December, we're highlighting other organizations and projects that rely on Tor, build on Tor, or are accomplishing their missions better because Tor exists. Check out our blog each day to learn about our fellow travelers. And please support the Tor Project! We're at the heart of Internet freedom. Donate today!

Tor Messenger

Tor Messenger is a cross-platform chat program that aims to be secure by default and sends all of its traffic over Tor. It supports a wide variety of transport networks, including XMPP, IRC, Twitter, and others; enables Off-the-Record (OTR) Messaging automatically; has an easy-to-use graphical user interface; and has a secure automatic updater.

Tor Messenger builds on the networks you are familiar with, so you can continue communicating in a way your contacts are willing and able to do.

It's based on Instantbird, an instant messaging client developed in the Mozilla community, and leverages both the code (Tor Launcher, updater) and in-house expertise that the Tor Project has garnered working on Tor Browser with Firefox.

It was launched in Oct. 2015 and has since been receiving steady security and stability releases. However, there remain a few important items on the short term roadmap,

Making the build reproducible on more platforms (so far only Linux)
Porting some Tor Button-like features (security slider, new circuit for site)
Taking advantage of Yawning's sandboxing work
Translations and documentation
Engaging an independent audit

This summer, the team participated in GSoC, helping to mentor a project implementing CONIKS. CONIKS is a key verification system with the goal of easing the burden of key management for end-users, while at the same time not asking users to trust their communication providers to act in their interest. An alpha release was recently tagged.

At the Tor developers' meeting in Seattle this past September, we held several sessions on messaging. One of the goals was to help determine where to take Tor Messenger in the future. The consensus was that we should be focused on eliminating metadata, both in the currently supported networks (where this might materialize as rosterless communication or having temporary identities), or incorporating new networks with architectures like those found in other onion messaging systems. There are many unsolved problems here, like balancing serverless communication with presence detection and asynchronous messaging, and we're excited to help push the field forward.

Comments

Please note that the comment area below has been archived.

I'm glad Tor Messenger is

I'm glad Tor Messenger is based on Instantbird! <3 Mozilla

> yes, an independent audit

> yes, an independent audit (i read that voip leaks and tor messenger is still in alpha stage like a lot of projects relied on tor).

Yes, an independent security

Yes, an independent security audit is very important.

Things are so desperate I want to use TM even before an audit is published.

Is this viable for Tor

Is this viable for Tor Project's donations campaign? http://smile.amazon.com/about

Not only is it viable, but

Not only is it viable, but we are signed up for smile!

https://sedvblmbog.tudasnich.de/donate/donate-options

Is Tor Messenger in Tails?

Is Tor Messenger in Tails? And if not, what will it take to get it there? If so, where do I find it?

It's being considered to

It's being considered to replace Pidgin in Tails.

See https://tails.boum.org/blueprint/replace_Pidgin/

That is great

That is great news!

Reporters, please consider using TM at Calyx!

Thanks. I'm looking forward

Thanks. I'm looking forward to it! I use Tails as my primary platform, but it's inconvenient to install third party apps in it every time. I think a lot more people will use it and report bugs once it's pre-installed in Tails.

Yes indeed!

i would ike Ricochet added

i would ike Ricochet added to Tails as well 'wish list' -_-

Tor Messenger is what I use

Tor Messenger is what I use everyday, I'm so happy with it :)

Is it theoretically feasible

Is it theoretically feasible for Tor Messenger to support fundamentally unique protocols like Ricochet under its pluggable API for chat protocols? I think it would be advantageous for protocols like Ricochet to be part of Tor Messenger so that Tor Messenger can benefit from the security properties of the protocol, and the protocol can benefit from the portability, UI, sandbox, ControlPort API, third-party plugins, etc. already provided by Tor Messenger. I don't see any reason to duplicate all that work for each protocol. It would be the best of both worlds.

Great idea!

hear hear

> Is it theoretically

> Is it theoretically feasible for Tor Messenger to support fundamentally unique protocols like Ricochet under its pluggable API for chat protocols?

Should be, that's what we're alluding to at the end of the post.

On order to be truly user

On order to be truly user friendly and take actual advantage of cross platform capabilities, you just and simply need something like OMEMO encryption. Without it there just won't be wider adoption. OTRs days are over.

Is OMEMO on roadmap?

OTR is a safe & secure

OTR is a safe & secure option by 3 steps :
1° usage (default)
2° trust (updated & tested)
3° analyse (the protocol is strong & verified)
OMEMO is another option (unknown !)
a) who is using OMEMO ?
b) who have confidence in this new protocol ?
c) who have audited/tested and in which app ?
Do you really think that a secure communication is a tool for geek just for the fun ?
OMEMO like your comment is immature.

There's no need to start

There's no need to start throwing anonymous insults here. Had you done your homework you would know that for eg. the best xmpp android chat app Conversions has implemented OMEMO successfully long time ago. Also chatsecure with full OMEMO support is already in beta stage.

What we need is equally well functioning desktop counterpart, and TOR messenger could be just that.

It is a strange opinion that asking for user friendliness (brought by OMEMO) is considered "fun" or not needed. That's the typical geek view preventing any serious wider adoption.

And here's your audit: https://conversations.im/omemo/audit.pdf

> misunderstood : nobody is

> misunderstood : nobody is insulting you & immature is the right term.
1° - android chat is for android user and if the app with omemo is used successfully by yourself ; that's fine (is otr obsolete or broken ? - implemented does not mean no-broken_without leaks_perfect_by the way EFF should give us his opinion : a new comparison is coming soon about this subject : why do you not contact them to be on the list ?).
2° - chatsecure = beta stage = immature = phase test = experimental
3° - a lot of project are focused on chat/voip/encryption but yes, most are for the fun (look at the number which were dropped year by year) rare can be considered seriously as trust tool or at least secure option.
4° i do not pretend that omemo will not be the future : otr still sounds like a safe option.
Please, do prove us that omemo will be the new standard and we will follow you & support you.!

I guess if it finds it way

I guess if it finds it way into instantbird, it will find it's way into tor messenger too. btw there isn#t even an xep for omemo yet (ie it's not even a standardized xmpp extension yet).

It is on the roadmap:

It is on the roadmap: https://trac.torproject.org/projects/tor/ticket/17457

Make Tor Stealth Again !!

Does Tor Project really

Does Tor Project really wants this "Tor Messenger" to fly to most people? If it stays this way almost no one will use it.

Make "Tor Messenger" to: normal people... to make it mass used and then it becomes more easy to protect people that really need the protection since they will be "few in millions"... much harder to pinpoint has priority target... and gives the platform legit use has its main base of users.

Some ideas... I'm sure there are lots of necessary features I will forget, but should still be a good start!

I would like to see "Tor Messenger" more in the "Threema App" direction... just one protocol, good encryption and authentication always ON from the very start (no possibility to turn encryption/ authentication off).

Cross platform (desktop, laptop, smartphone, tablet...) always with unified GUI over all platforms.
The most important feature is the GUI and having lots and lots of icons and themes to make people happy... that is what people care the most... that, and to be easy to verify they are talking to the right person (with some sort of red, yellow, green check-mark or other thing similar)... and let people define photo of the other person obtain from their own device... not from the other person to prevent bad taste/ fake photos.
Also for example delayed messages to send birth date happy messages and things like that.

Of course everything should go trough the ONION network end-to-end without ever surface out of it... this would be one more additional layer of protection, besides the encryption to the server(s) and the end-to-end encryption it self of the application.

Association to phone numbers* (the person may have more then one!)/ e-mails*/ web site URL* (in URL only dns change validation should be accepted... and the only thing that every domain registrar seems to allow is "Glue records" so maybe require the user to create for example tormessenger81295815.[sub-domain.sub.domain.-and-or-domain].tld and pointing it to for example to some random none public like 10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255 or 192.168.0.0 - 192.168.255.255... with 17,891,328 random IP address to choose from, it seems a good way to validate, plus the "tormessenger81295815" that should also be unique, and once validated the user should be able to remove from the glue record) should be optional to increase its level from Red to Yellow [the green only scanning some QR code or entering some HMAC-Whirlpool (128 numbers) hash of the public key, to make it very hard to spoof].

*It must not be used to anything else other than verify the user has access to that thing. You may require re-validation of the information every 3 years to make sure user still has access to that thing. Any one else should be able to register the same thing has long they proof access to it (so if someone changes its phone number, e-mail, web site URL without deleting it first the new person is not blocked from using it, but the previous account should have that detail removed from the confirmed things).

The ID should be some random generated 40 numbers (to be universally accepted on all the Earth in any language, and since there are less than 8,000,000,000 people this should be plenty. It may (or not) be some derivation of the public key.
40 numbers?? Yes, ~128 bits. It should make pretty much impossible to guess someone ID, and also avoids collisions of ID's (but if it happens the server should instruct the client to generate a new ID).
Most people should exchange that from smartphone to smartphone (QR code), but they can also see the information in a web site, e-mail, business card and all this can contain the QR code to make it easier (including clinking ones online to add directly to the program)... and what is really personal to them is the name and photo they associate in the client application.
QR code could provide a pre-define name to be used, to be user friendly (but changeable by the user).

The IDs must be revocable so that the legit user can cancel the ID if it no longer wants to use it or it has been compromised... and that should make the ID to disappear in everyone's contact lists (and be blocked from being add again in the servers) although previous messages can stay available until the user decides to remove them.

It should be available interfaces to allow web sites easily communicate into "Tor Messenger" users.
The use cases for interfaces from web sites are almost "endless"! And make the adoption rate potentially go up if it is adopted by major players like banks, has one more option to communicate with their costumers.
Some things possible: new messages received; second factor authentication; confirm operations; recover access to online accounts; communicate directly with the server from the App; send weather warnings; send missing children alerts; I need help!; Home Alarm alerts; You will receive a delivery package at: 12h15; and much more.
It should be made available for most CMS (Content Management Systems) like Drupal, Wordpress, Joomla!, TYPO3, and forum software: phpBB, Simple Machines Forum, vBulletin, in at least some kind of plugin form... to make the average Joe be able to easily add support for that. Remember, the easier to integrate in existent software the quicker it will be adopted world-wide.

Of course should allow the removal of existing contacts, block contacts permanently (black list), only allow some contacts that the person adds (white list), and/ or a mixed mode where some contacts are always authorized, others are always not authorized and others are in the grey area where they are authorized to communicate when the person is open for everybody (and not just the white list... and the white list may have groups so that the user can allow for example just is direct family and no one else, even if it may also allow closed friends at most occasions).

Server keys should be pinned and fully verified to prevent machine-in-the-middle attacks.

Post Quantum resistant algorithms:
And because it wouldn't be necessary to support legacy in any way (brand new messenger) it should already offer Quantum Resistant algorithms like the ones suggested in PQCrypt ( https://pqcrypto.eu.org/docs/initial-recommendations.pdf ):

- Symmetric encryption (a or b):
a) Salsa20 with a 256-bit key
b) or maybe (I suggest Threefish-256)

- Symmetric authentication: Poly1305

- Public-key encryption (a, b or c):
a) McEliece with binary Goppa codes using length n = 6960, dimension k = 5413 and adding t = 119 errors.
b) Quasi-cyclic MDPC codes for McEliece with parameters at least n = 216 + 6, k = 215 + 3, d = 274 and adding t = 264 errors.
c) The Stehl´e–Steinfeld version [17] of the NTRU lattice-based cryptosystem.

- Public-key signatures (a or b):
a) XMSS using some 512 bit hash (XMSS requires maintaining a state.) (https://www.ietf.org/id/draft-irtf-cfrg-xmss-hash-based-signatures-07.p…)
b) SPHINCS-256 (SPHINCS is stateless).

- Public Key Exchange (not covered, but one suggestion):
a) The Supersingular Isogenous Diffie-Hellman Protocol (http://blog.coinfabrik.com/wp-content/uploads/2016/10/quantum_resistant…)

Not Post Quantum Resistant algorithms.
If quantum resistant algorithm are not even to be considered, then at least:

- Symmetric encryption: ChaCha/20 (rounds) (https://cr.yp.to/chacha.html)
- Key derivation: Elliptic Curve Diffie-Hellman (ECDH) over the curve M-511 or E-521 (https://safecurves.cr.yp.to)
- Authentication and integrity protection: Poly1305-AES (https://cr.yp.to/mac.html)
- Where needed, hash: HMAC-Whirlpool
- Padding: PKCS#7 padding to each message before end-to-end encryption.

This:
- Should be able to provide high security while providing deniability (with ECDH).

Thanks for the suggestions.

Thanks to the commentator

Thanks to the commentator for writing so many detailed suggestions, and thanks to the moderator for posting it.

And now Roger's worst nightmare: I want to comment on the comments.

> Does Tor Project really wants this "Tor Messenger" to fly to most people? If it stays this way almost no one will use it.

This puzzles me somewhat, since in my experience, TM is the only chat program I could ever get to work well enough to communicate with an authenticated journalist.

> I would like to see "Tor Messenger" more in the "Threema App" direction... just one protocol, good encryption and authentication always ON from the very start (no possibility to turn encryption/ authentication off).

I think you are arguing here for adhering to the KISS principle (keep it safe and secure by keeping it simple), and as a general principle that makes good sense.

> Cross platform (desktop, laptop, smartphone, tablet...) always with unified GUI over all platforms.

Cross platform is very desirable for usability, but could conflict with the desire to keep the code base simple.

> The most important feature is the GUI and having lots and lots of icons and themes to make people happy... that is what people care the most...

Also why security professionals moan that the user is his own worst enemy. I want enough usability to encourage broad adoption of TM, especially by journalists and activists, but would be happy to sacrifice eye candy for better security. For example, email was not designed to be "secure", but it make much more insecure in the real world after some people decided it would be a good idea to include http markup and image files inside emails.

> that, and to be easy to verify they are talking to the right person (with some sort of red, yellow, green check-mark or other thing similar)...

I doubt there is any magic bullet which makes authentication easy.

> and let people define photo of the other person obtain from their own device... not from the other person to prevent bad taste/ fake photos.

Come again? It almost sounds like you are asking for some sort of photo-doxing capability here, but I probably misunderstand.

> Also for example delayed messages to send birth date happy messages and things like that.

I'd love to see torified delayed remailers for encrypted emails; they'd be abused by a few, but they'd go a long way to better protect the masses of good citizens who need protection from their own (and foreign) governments.

> Of course everything should go trough the ONION network end-to-end without ever surface out of it... this would be one more additional layer of protection, besides the encryption to the server(s) and the end-to-end encryption it self of the application

As mentioned above, Tails Project is apparently working (maybe not as fast I would like!) on getting TM into a future edition of Tails. I think this would effectively address your concern. But if I misunderstand something, I would welcome correction.

> QR code

You lost me, but I am glad to see that others are eager to exploit existing utilities such as QR codes for securely passing short messages. (It would help if Shamir Secret Sharing System and QR codes were more compatible.)

> (cipher suggestions)

I share your enthusiasm for the latest and bestest, but one important point we need to bear in mind is that many of these have not yet been made available within the Linux ecosystem, and we'd be asking a very great deal from the TM developers if we asked them to write their own implementations of novel cryptosystems from scratch. That is an activity which one well respected and broadly experienced cryptographer, Bruce Schneier, has (consistently over two decades) argued is a bad idea.

But even so, yes, quantum safety is a very serious issue. Here's hoping that the funding drive is such a fabulous success that Tor Project can hire one or more of the world's best cryptographers (among those who do not work for NSA or another hostile agency of the US or any other privacy-hostile government).