ricochet
ricochet copied to clipboard
ricochet-im
Layer stronger cryptography on top of hidden services
As an extra layer of security, I would find it very useful to have the option of using public-key encryption with perfect forward security in Ricochet.
The hidden service connection is already decently encrypted, authenticated by public key (RSA 1024, with the public key authenticated by 80 bits of SHA1), and forward-secret at the connection level (DH during rendezvous).
I think it is a good idea to add another layer of cryptography beyond what hidden service connections provide, especially if it allows us to provide stronger key and forward secrecy guarantees. I'm also interested in separating "identity" keys from "transport" keys (hidden services).
The details get more complicated. My requirements for considering options are:
- Any additional cryptography provides a clear benefit over what we have now
- Applies to arbitrary protocol data, not just chat messages; e.g. file transfers
- Implementation doesn't add an unmanageable security/exploitation risk
For example, OTR is intended to secure message content, not an entire protocol. Deniability is not a useful trait here. It would be reasonable easy to implement, and is generally trusted, but I don't see much clear benefit in having it. Out-of-the-box OTR would be hacked on top of the protocol, rather than being part of it.
This task needs a good survey of what we stand to gain and how existing options in the field could be used. The situation is different from most IM software, because we have "direct" peer-to-peer communication and decent cryptography at the transport layer.
Relevant reading: https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2
more relevant reading: https://pond.imperialviolet.org/ https://pond.imperialviolet.org/threat.html https://pond.imperialviolet.org/tech.html https://github.com/WhisperSystems/libaxolotl-java
;)
hi!
stumbled upon your considerations, you might find this project useful: https://github.com/cossacklabs/themis
we've designed secure messaging scheme (called Secure Session) with PFS and some other strong features exactly for securing chats / session-based rpc (the latter was our main subject of interest, but security model equally works for the former). we already have accumulated some knowledge in helping other people building secure human communications with it, so apart from code we'd be glad to share knowledge :)
it's free and open-source and if you find the model interesting, ping me or any of the project contributors and we might find the way to make your life easier.
and, btw, we have c++ wrapper in the works, too (we're doing PNaCl port of the library now).
Axolotl is the best choice here as it's vastly stronger than afaik all other forward secrecy approaches. Axolotl even becomes post-quantum if the adversary ever misses even a pair of message in a round trip, say due to Tor protecting their route.
It's fun to implement yourself, but if you want another library for it, as mistakes are easy to make, then I'm sure you'll find some C++ ones : https://github.com/CODeRUS/libaxolotl
If you are aiming for multi device usage in the future, OMEMO might be an even better choice: http://conversations.im/omemo/ Also backwards compatibility to OTR should remain. So when communicating, the client should first try establishing a Axolotl/OMEMO session, if it fails, fall back to OTR, kinda like it's done with SSL, where Browser and Server try to agree on a common cipher
I don't think it's a very good idea to optionally fall back to weaker/older crypto. It's not like there will be clients that somehow support OTR but not axolotl if the spec says axolotl, and supporting weaker schemes is just asking for downgrade attacks. SSL is an excellent example of why things should NOT be done this way.
Here is a resource https://www.eff.org/secure-messaging-scorecard to find well vetted, open-source messengers which you might want to pull protocols from. Signal (Open Whisper Systems mentioned above) is well rated.
I think the next release of OtR will address it's current shortfalls relative to Axolotl, mostly by incorporating Axolotl, while keeping some non-Axolotl features the designers like, and replacing the key exchange with something fancier than TripleDH.
Ricochet does not do multiple devices per se, but as that came up. OtR will continue to handle multiple devices well, but probably not with the same model at OMEMO. OMEMO shares all your messages with all your devices, a nice convenience, but also an MitM attack vector. The next OtR should target the "most-recent most-trusted device".
I do not know when this will happen, nor even if the initial reference implementation will still be in C. I gather the current libotr is not necessarily a good guide for the API, and that support for OtR v2 will be dropped.
If nothing happens here for long enough, then this probably become a good option. It's certainly heavier than just rolling in an Axolotl ratchet, but it still might offer some advantages.
Interesting reading: http://www.noiseprotocol.org/
Particularly some good points to think about in http://www.noiseprotocol.org/noise.html#payload-security-properties and http://www.noiseprotocol.org/noise.html#identity-hiding
TFC uses XChaCha20-Poly1305 end-to-end encryption with deniable authentication. The symmetric keys are either pre-shared, or exchanged using X448, the base-10 fingerprints of which are verified via out-of-band channel. TFC provides per-message forward secrecy with BLAKE2b based hash ratchet. All persistent user data is encrypted locally using XChaCha20-Poly1305, the key of which is derived from password and salt using Argon2d. Key generation of TFC relies on Linux kernel's getrandom(), a syscall for its ChaCha20 based CSPRNG.
https://github.com/maqp/tfc
This sounds pretty good to me, or perhaps ed25519 for key exchange and signature to provide authenticity and integrity, with xsalsa20 for stream cipher to provide confidentiality.
For the record, you can use BLAKE2 as a prefix-MAC instead of HMAC.
https://blake2.net/blake2.pdf
Additionally, I have not checked the code but I sure hope it does an explicit_bzero() consistently immediately after the confidential data is no longer needed. Keep mlock() in mind as well to avoid swapping it to disk. We may need assembly to zero relevant CPU registers (but highly unlikely).
