Hi title says it all.
Not much information on publicly available topic in the FAQ section :
We use TLS 1.3 with a perfect forward secrecy requirement for the negotiated ciphers for calls and file transfers. Messages are encrypted with an RSA key.
1 Like
It’s always more reassuring to do tests, but you can’t force it at the moment. 
This interests me and I’ve just gotten started with Jami, so I will take a look at this. I have some cryptography background but have not looked at all at the Jami source code and don’t yet even know if it’s in a programming language that I understand ;).
I think besides the encryption itself, the DHT scheme also has to be examined, there should be some consideration of resistance to traffic analysis, and (I haven’t checked) but text chat should by default include padding in active conversations, to not reveal when someone is typing. For very low bandwidth (e.g. satellite text) communications there should be a way to disable the padding at a cost in security.
Followup: I’ve looked a little bit at the code and docs now, and I think the group chat protocol which uses git to move keys around is also suspect. Doing group chat crypto properly is surprisingly complicated. There is a standard now, RFC 9420 (Messaging Layer Security, MLS) that is fairly new, so the Jami protocol existed earlier. Maybe Jami should be updated to use MLS, which at least at the protocol level has undergond a lot of security analysis.
Jami itself also uses a lot of C and C++ code, much of it such as media codecs come from other projects. When I downloaded an old version of the Jami source code from the Debian repo (“apt source jami”), I got a string of messages about the package manager applying patches for a dozen or so CVE’s. That is sort of a bad sign.
I’m new to Jami and I like the idea of using it because it’s a GNU project, but I wonder if alternatives like Matrix are more mainstream now.
1 Like