🌐 Website Issue | Jami is missing a warning about metadata

[Mikaela]

• https://www.privacytools.io/software/real-time-communication/

Jami (formerly Ring/SFLphone) - Gives you full control over your communications and an unmatched level of privacy. Jami has text messaging, video and audio calls, file transfer, video conferencing. [VoIP]

I am under impression that a network observer can see whom you are discussing with even while there is E2EE, but citation is needed and a warning should be added.

[Mikaela]

I cannot find a direct quote, just two parts that need someone wiser to take a look:

Ring uses OpenDHT (a distributed hash table) to connect users instead of a centralized SIP server system such as Asterisk. OpenDHT is an implementation of the same decentralized, peer-to-peer system used in BitTorrent's distributed tracker, as well as the Coral Content Distribution Network. For comparison, the founders of Skype originally worked on the Kazaa filesharing application. Skype initially utilized a derivative of the FastTrack protocol used in Kazaa, though this has changed somewhat since the program was first introduced. Additionally, components now use MSNP24, a derivative of the protocol used in the now-defunct MSN Messenger.

OpenDHT allows Ring to bypass the server-client methodology by passing along user information to each user. According to an interview on the Savoir-faire Linux blog with Guillaume Roguez, the Ring project director:

With Ring, each account is identified on the network by a personal digital footprint commonly called hash — a unique code of 40 letters and numbers linked to an identification certificate and a pair of asymmetric keys for encrypted communications. It registers itself by distributing its identity not to one but multiple equivalent servers — each machine acting in fact as an identity server for others. These machines can appear, disappear and be replaced by others at any time. The table of hashes containing all the identities of connected users and their IP addresses at a given time is distributed to all their machines.

Adrien Beraud provides further insight into the construction of Ring, noting that OpenDHT is itself not an inherently secure design; as with BitTorrent, it relies on the trust of all parties to the network to store and transmit data properly. For this reason, the encryption layer is added on top of OpenDHT, rather than trying to modify DHT to resist interference. As such, Ring utilizes PKCS asymmetric keys to ascertain the validity of the data in transit.

• https://www.techrepublic.com/article/privacy-focused-skype-alternative-ring-shows-promise/

• https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/Protocol#contacting-another-account

I guess it's implied that your Jami usage is announced wide and this leads to the concluion that someone monitoring the network can see where a connection comes from and where it's going to.

[Mikaela]

See also:

• https://git.jami.net/savoirfairelinux/ring-project/issues/495 - Stream Isolation + Tor
• https://git.jami.net/savoirfairelinux/ring-project/issues/501 - I2P
• https://git.jami.net/savoirfairelinux/ring-project/issues/509 - Privacy issues of linking pictures and videos from third party sources
• https://git.jami.net/savoirfairelinux/ring-project/issues/622 - Tor
• https://git.jami.net/savoirfairelinux/ring-project/issues/630 - I2P

[lrq3000]

From this link you posted above, they say the ICE offering (ie, the message sent to the OpenDHT network to signal that the client is listening for incoming calls) is hashed: SHA1("callto"+deviceID). So if you have the target deviceID you want to call, you can compute the SHA1 and initiate the call, but otherwise an external observer will only get the SHA1 hash and not directly the deviceID.

[blacklight447]

From this link you posted above, they say the ICE offering (ie, the message sent to the OpenDHT network to signal that the client is listening for incoming calls) is hashed: SHA1("callto"+deviceID). So if you have the target deviceID you want to call, you can compute the SHA1 and initiate the call, but otherwise an external observer will only get the SHA1 hash and not directly the deviceID.

wouldn't it be possible for the observer of the openDHT to calculate the same hash valua and correlate it?

[lrq3000]

Yes but since the deviceID is randomly generated, it's akin to cracking a password from its SHA1 hash, it can take a very very long time. I think the deviceID is never directly exposed on the OpenDHT, but it would be better to ask directly the devs for confirmation, as, if I understand correctly, @aberaud seemed to write that is the case since at least 2016 (in the predecessor Ring), with the caveat that IP addresses were still exposed (I don't know if this changed?):

Ring developer here. Ring is a distributed communication platform, its nodes are part of a DHT network, so their IP are indeed exposed.

That's a downside of using a distributed network: DHT nodes IP addresses are exposed on the distributed network, which is a valid privacy concern. The current design doesn't allow to cryptographically link DHT nodes with Ring public keys and we work to make this separation as strong as possible.

[aberaud]

I am under impression that a network observer can see whom you are discussing with even while there is E2EE, but citation is needed and a warning should be added.

Since we establish peer-to-peer connexions between contacts, network operators could see the p2p TCP channel and infer who you're talking to. I guess this is true for most IP communication systems (even centralized) as network operators could infer source/destination IPs from the traffic flow, unless a specific strategy is deployed to hide the source/destination IP (like Tor). Currently the media channel is UDP-only which doesn't work over Tor but that might change (however the real-time communication experience might not be great by going over Tor).

Yes but since the deviceID is randomly generated, it's akin to cracking a password from its SHA1 hash, it can take a very very long time. I think the deviceID is never directly exposed on the OpenDHT, but it would be better to ask directly the devs for confirmation, as, if I understand correctly, @aberaud seemed to write that is the case since at least 2016 (in the predecessor Ring), with the caveat that IP addresses were still exposed (I don't know if this changed?):

Device and account public keys are published on the DHT. This is used for the user lookup and multi-device feature. Knowing the device ID or public key doesn't allow to know who's calling who, however a network observer could infer some meta-data.

[lrq3000]

Thank you very much @aberaud for taking the time to clarify this issue!

[lrq3000]

PR #2293 addresses this issue for all P2P networks, they all share the same issue of non anonymity of senders and receivers.

(PS: Given the discussion above, it doesn't appear that Jami leaks any more metadata than any other secure P2P network, it's normal that the nodes IDs are propagated through the network via a DHT for a distributed P2P system.)