The creator here. Thanks for pointing out the lack of documentation here. At the moment, the security is RSA for the handshake and AES for the data once a connection is established. The security at the moment has obvious problems, so don't use it where your life depends on it. I have a plan to switch to using telehash for the com layer instead of my own hand rolled protocol. In the meantime, I invite any security experts to help improve what I have. The first obvious improvement is to sign messages. So please help if you can.
Very cool, and I love your project. I've read your blog and your approach is very admirable and I love the extensible approach you've taken.
If you're still considering protocols, I'd consider the TextSecure V2 protocol. The documentation isn't crazy in-depth, but it's a really neat protocol that offers forwards and future security.
It's definitely worth looking into - TextSecure's Axolotl is best-in-class for dealing with text messaging or other scenarios with occasional one-shots.
If you want another, simpler transport that works better for more connected scenarios, like this one, ask trevp who did that: he has a very promising-looking one in the design phase.
If I can give any advice: security doesn't make a good afterthought, especially when encryption was the first word you mentioned. It's a foundational feature; treat it as one. Pick primitives that make the best, most solid foundations you can get, and do your best to make sure you can rely on them. As for the rest, extensibility needs careful thought: it can be easy to extend yourself into vulnerabilities.
Best of luck. You have an interesting project. I might keep an eye on it.
Thanks! Yes, this is great advice. security should not be an afterthought and it certainly has not been here. Also, I did not post this on HN, so those were not my words.
There are some aspects to security that I took that extend to the code. It is written using design by contract, where if a contract fails, the program quits immediately. Security should extend beyond the protocol.
As I mentioned previously, long term I won't be using a handrolled protocol, which has obvious problems. This software is alpha and I hope to migrate before 1.0
I was looking into making a similar application a while ago and was really interested in OTR. Not only does it provide encryption and authentication, it also provides deniability. Have you guys looked into using it? If you have and rejected it, what were the reasons?
OTR is definately an inspiration here. I need to add the HMAC signing and key ratcheting. When I started there was no good OTR implementation that I could find.I was also concerned with performance. I am looking to use telehash now. What is your opinion of telehash vs stock OTR?
I wasn't too familiar with telehash until you mentioned it. I read the docs and it looks like it's a pretty complete framework whereas OTR is more of a handshake to establish a secure channel. If you're only using telehash to secure a channel it seems like overkill. If you use its peer resolution and asynchronous messaging features it seems pretty nice.
libotr is a very good implementation of OTR (in c) [1]. I don't think performance would be a big issue on modern hardware. OTR does offer future deniability in case one of the parties gets compromised. I didn't see the same guaranty in telehash (I might have missed it).
I think they are both fine platforms but I'm far from being an expert. For anyone who is interested in the documentation I was referring to: telehash [2] and OTR [3].
