The project is now scraped. What I was trying to do with QOTR is inherently what makes it insecure. When I say encryption happens in the browser, and the servers can't read the text. This tries to give you a assurance that the server getting compromised will mean that the text you send couldn't be decrypted by it. But when we are allowing for a server to be compromised, it also means the static files it servers could be compromised hence making the encryption in the browser idea irrelevant.
What will work instead is distribution of a signed plugin which talks to a chat server. The chat server being compromised here doesn't impact the client's integrity. A great implementation of this already exists as cryptocat.
Go off-the record, quickly.
QOTR is a application through which you can quickly spawn a encrypted chat with your friends. The messages are encrypted before they leave your browser. The QOTR servers cannot understand what is being said.
For chats 256 bit AES-CBC encryption is used. The key generation happens in the browser. To keep it easy to share a chat room, the password is provided as a location hash. Browsers do not send a location hash to the server.
Try it out at the demo server.
QOTR is a alpha quality software, not vetted by cryptography experts. Please use it carefully. Avoid sending sensitive data over this.
Based on various comments on public forums, I realize that the name `QOTR` is confusing. This project doesn't actually implement the OTR protocol. If this is too big of a concern, I'll try to come up with a better name. Suggestions are welcome.
How it works
A fairly detailed description of how the encryption works is available here.
Using OTR with current common chat clients is difficult. It cannot be trivially done over common platforms. All encrypted chat services require you to install a new client or a plugin. This may be a turn-off for a friend who isn't concerned about privacy and encryption. QOTR's goal is to make it convenient (as simple as opening a URL) for them to use.
QOTR is a combination of a server and a browser based client. Both of them need to be built separately.
The server is based on tornado web framework. As of now, the channels are stored in memory, hence QOTR can only have a single server for a endpoint.
To launch a development server:
$ pip install -r requirements.txt $ python -m qotr.server
Run tests via:
$ QOTR_ENV=test nosetests --with-coverage --cover-package=qotr
QOTR Client (Ember.js)
You will need the following things properly installed on your computer:
$ npm install $ bower install
Running / Development
$ ember server
Visit your app at [http://localhost:4200](http://localhost:4200). The QOTR development server should be running locally.
There are some tests in the frontend, but the coverage is not good. This is partially due to difficulty in testing a few things and partially my inexperience with
ember-cli based testing.
The tests require you to have a development QOTR server running locally.
$ python -m qotr.server
Execute the tests:
$ ember test $ ember test --server
$ ember build # development build $ ember build --environment production # production build
QOTR hosting has been tested on heroku. Add the git remote provided in your heroku application to your local clone:
$ git remote add heroku https://git.heroku.com/qotr.git
It requires multiple build packs. First, the ember application needs to be built and then the sever requires a python based buildpack to run tornado. To enable those, run:
$ heroku buildpacks:add https://github.com/tonycoco/heroku-buildpack-ember-cli.git $ heroku buildpacks:add https://github.com/heroku/heroku-buildpack-python.git
Set the QOTR environment variable:
$ heroku config:set QOTR_ENV=production
$ git push heroku master
Probably lots. Please send us reports on the Github issue tracker. Patches are welcome too.