Using Ricochet concurrently?

Question

Is it safe to run two ricochet instances on the same system; side-by-side? Is there anything that might conflict (listening ports, etc) that could cause issues? Would you recommend against it for any reason?

Answer 1

Maybe under certain circumstance.

There shouldn't be port conflicts, by default Ricochet binds to a random high numbered port for it's listening address, the Tor SOCKSPort and ControlPort which should stop conflicts.

The only thing that might result in conflicts is two ricochet instances trying to use the same directory to store their configuration/keys/contacts. To avoid this you can launch ricochet with an explicitly directory path to use, e.g. ricochet /path/to/config_a and ricochet /path/to/config_b.

Other things to consider are the usual problems of running two identities from a single system, e.g. if there is a power outage or an internet outage or your system crashes then both identities will go offline at the same time and potentially be linked by an entity with visibility of both.

Answer 2

Well, technically there's no limit/prohibition/impossibility to run multiple instances of ricochete on teh very same machine. But here's another side - as in general hidden service case - you need to take care of anonymity. Here are some points you do need to consider and - maybe - implement a proper configuration:

• Running Tor and hidden service on the same tor process - even if you'll start a Tor just with a hidden service in it and with ORPort and DirPort reachable(which you should do, if you want a good speed for your messengers) - Tor will give you a warning like this:

  [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742

  Which is a very good reminder to take an extra care for your anonimity. A solution here can be a separate Tor instances: one acts like a relay and the bridge, but not publishing it's descriptor and it's bridge functionality is used by a second instance that will be a "hidden service container". It will use only the first instance as a bridge and have only one purpose - to host the Ricochete's hidden service. I do recommend you to do so - it is quite a simple task and you need to do it only once!

• Running multiple hidden services on one Tor instance - OK, you have utilized the warning in a previous topic, but... There is something more to concern. Tor's command&control protocol can set only an authentication(by password or a cookie file), but it can not distinguish/separate different clients, in another word there's no username+password combos for tor control protocol that can be isolated from each other. Problem is that - if compromised - one Ricochete can list/deanonymize/compromise all the other hidden services. So - my good advice for you here is to make a HS container one per each ricochete and bridge it through the one instance like I've said before. And - of course - use different passwords for it, or - if using a cookie files - distribute them by different directories so no "guessing" will be possible. Like making some mountpoints and mounting tmpfs just for cookiefile - simple script, no RAM wasted, secure.

If you have further questions or need more information - feel free to ask, I'd love to help!