Click here to return to the main page

Cryptology Details

WebRTC already mandates encryption over DTLS, and this website does not disable that functionality. However, there is no authentication scheme built into this DTLS implementation.

While javascript cryptology is less than ideal in the browser, this website uses OTR(or Off The Record) in order to add an additional layer of security, as well as verify the authorization of the other users in the room.

How does OTR verify identity of other users?
OTR offers a feature called SMP which, once an OTR connection has been established, can be used check if other users entered the same password, without sharing any information about that password.

Why not just use a third party to verify authorization?
Then we would be trusting a third party's login system, which this implementation aims to avoid.

I don't trust this site. What can I do?
Don't trust it. Host at least the client portion of this site yourself. You are free to use the node.js server (used to setup and manage rooms and user connections) on in order to facilitate connections and hold room information. The server does not ever get sent or store the OTR password (see Privacy section in "About" above) and users would be able to connect between versions of this site hosted on multiple websites (even over OTR), as long as the same node.js server is used.

Why not just verify authorization with OTR, then send everything over the DTLS connection?
A malicious third party could just blindly forward the OTR packets back and forth after establishing a DTLS connection with both users. If the OTR traffic is then sent in the clear, they would not be authorized, but would be able to see all plaintext traffic.

OK, so how is OTR implemented?
When OTR is enabled:
- We use OTR's SMP in order to verify password both parties entered is the same.
- Everything besides file data is sent & received over the OTR channel (that includes messages & file meta data) only after SMP is successful.
- A quick note about file transfers - with OTR enabled, a user requests a single chunk at a time, that request also contains a nonce and a hash of the previous chunk.
- File data is encrypted using Rabbit(stream cipher) with a shared random secret negotiated during OTR setup + the nonce received in the chunk request. This is done for speed as the OTR channel would create a more significant bottleneck with a slower cipher (ie. AES).
- The sender receives the hash from the previous chunk and verifies that. If it does not match, the sender stops the download.
- to reiterate - ALL information (besides Rabbit'd file data) is sent over the OTR channel.
OTR library used -
Rabbit(stream cipher) library used -

Feel free to ask!