@nhu
Did you even look at Jami? It doesn’t require any great amount of skill to use. It’s user friendly.
Did you not go to the website and see the user interface at all? I suggest you do. It looks a lot like anything people already use. And Jami has all the desirable features that qualify it for GNU security and freedom. Have a look around Jami’s website. You may find some of your concerns answered.
3 Likes
Oh, for some reason I was thinking wrong and assumed their was some type of binary signature that you were seeing on their site. Sometimes I wonder how I put my shoes on while alone.
1 Like
You truly believe that server to device encryption means only data leaving the server is encrypted, and data going from the device back to the server is not encrypted? So by your rationale, exactly half of every conversation is encrypted. This is also in spite of the fact the article you’d quoted states itself that telegram encrypts by default, btw.
I have neither the wherewithal nor the time to go into everything wrong with your logic, but I’ll grant that you indeed didn’t put words in my mouth and I apologize for that, though that would have at least made sense. I dunno, man, you’ve got me at a total loss for words.
Lol that’s an interesting interpretation of the device-to-server encryption concept 
What is meant instead is that you cannot guarantee encryption of the data after it hits the server. SO if your leg of communication is using encryption, but the other side is not - it means your conversation is not encrypted.
Even if both sides use encryption - it is still not encrypted on the server, so if server2server communication is involved that may be unencrypted. And even if s2s is encrypted - you may only trust the encryption if you own the keys (thus own the server).
That’s exactly the model I use - I own my XMPP server, i own encryption keys and data stored on the server, therefore to ensure secrecy/privacy/integrity it is sufficient for me to rely on c2s encryption. If I don’t own the server - i don’t own the encryption keys, I don’t have the encryption without c2c encryption.
1 Like
It’s enabled by default, so both sides are using encryption. He hadn’t said anything about server to server so I hadn’t considered it, though it seems very will that it wouldn’t be encrypted in that case, especially for telegram who says they’re all about privacy and security and have a bounty for whomever can break their encryption. Where did you see that it’s not encrypted on the server?
well, it is obvious, if you encrypt the transport but not data, the data is received in clear text. Even if you immediately encrypt the data - it is still re-encryption which means there is an airgap with unencrypted data.
That means - anyone with access to the server may eavesdrop your data. Which is the point I’m making - if you don’t own the server it’s safe to consider your data in not encrypted on the server.
1 Like
This is what I was talking about way back when I mentioned data at rest. So you mean it’s not standard practice to just pass along the encrypted message and leave it encrypted once it’s left the device? If so, why the hell not, or is my understanding lacking?
Just so we’re on the same page, the way I understand ist is that the server generates the encryption keys and passes them to the devices, which then use those keys to encrypt and decrypt messages passed back and forth between the devices. The server is then receiving, storing, and passing messages to/from the devices, but I thought they would remain encrypted once they left device A until they arrived at device B. Whatever the server was storing would still be encrypted. I guess this is incorrect, from what you’re saying?
No I specifically did not use term data at-rest because I’m pretty sure officially it is encrypted. The problem is really in key ownership. Do you know who else has access to the keys? When I generate pgp/pki key I know exactly where it is stored and which measures I’ve put to safeguard it. If i need to trade conveniece/availability for security it will be my conscious decision based on my risk estimate.
Do I know how third party stores the key it sent to me?
Do I know whom else that key was sent?
Do I know when exactly data is encrypted/decrypted/re-encrypted?
And this is second porblem - re-encrypted. Apparently the keys sent to me and respondent are different, that means re-encryption, airgap and unencrypted data in-motion.
Working in security area I know it’s not an easy task (because it’s a big rsik) to get the air-gapped solution for end2end encryption approved (basically to move one end from the app to security edge). Because it requires very tight control on who has access to the airgap. You then have PCI-DSS, ISO270001, controls, audits, full set of nightmarish headache. Do you really believe those guys are doing all of that? For you to chat privately securely and for free?
1 Like
Hi everyone. I have a question concerning GNU Jami. I installed a GNOME client and noticed in pfSense firewall that my computer communicates with a UDP port of 5916. Does Jami use UDP port 5916 for end-to-end encryption? What other ports does Jami use besides SIP/SIP over TLS (5060/5061)? Yes, I know SIP is a different technology from Jami, but it does not hurt to know which TCP and UDP ports Jami use.
I’ve been taking a lot of time to secure my own network using pfSense, so knowing what ports applications use is crucial to me. I use egress filtering.
(Update: Decided to change the link for egress filtering.)
You’re obviously more knowledgeable than I am, but that’s what data at rest meant to me. Since you brought up PCI-DSS, ISO270001, etc, telegram does have end to end encryption built in, so it ought not be an issue, right? I can’t say why it’s not default to end to end encrypt, but it can be done in telegram. And are you saying that apparently your telegram key is different from your respondent?
Okay. I did a netstat in my machine with the port number of 5916 and the process that’s making so many connections is “dring,” so I did some more research and Jami uses a GNU Ring daemon (dring).
$ sudo netstat -tulpn | grep 5916
udp 0 0 0.0.0.0:5916 0.0.0.0:* 65721/dring
udp6 0 0 :::5916 :::* 65721/dring
According to my firewall log in pfSense, the dring daemon (UDP port 5916) is making between 2 to 13 connections to different IP addresses and even over 20 connections. Is this how decentralized nature works?
Over time, the UDP/5916 process seems to be talkative. As I continue to watch for traffic leaving my network from my computer, the dring process is sending 200 kilobytes of data over the Internet and counting while idling. Why is the dring process doing this?
so i see the discussion has moved to a more specific and technical focus.
i’ll just say this … do you use only RYF hardware/software ? do you know for certain that that RYF certification that your computer came with at he beginning has NOT changed.
can you verify that ? i mean to say that even IF your hardware/software carries that certification when it is IN the box how do you know that has REMAINED so throughout your use period until this point ?
like ruff said above - it’s just a matter of someone else gaining access to your encryption keys. end to end encryption can then be made null from the one that has access to your keys.
example: your carefully watching the network traffic for weird activity but if the NIC firmware is compromised then it could be that you are seeing (with your eyes) fake traffic …
@GraysonPeddie
@AmarOk1412
Very good question to ask. @AmarOk1412 would be the person on this forum to ask as they are the developer of Jami. You can also post that question on Jami Mastadon site as well.
2 Likes
Is whatsapp no longer banning users of non-official apps? It used to be a big issue 2-3 years ago when people wrote apps for jolla/maemo, no longer the case?
Would be a good question on the Gitlab in fact (git.jami.net), I don’t think this topic is the right place to do that but there is some answer here: https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/0.-Introduction + articles on the blog
But yeah, actually each account runs a DHT node (https://en.wikipedia.org/wiki/Distributed_hash_table) (UDP, with random bind at start) from https://opendht.net and that node is continuously syncing with the rest of the network. And yeah, the DHT node will periodically connect to other nodes to maintain its state. Also, because each node works as a server, it will actually open/get connections for file transfers and SIP calls.
The DHT can eat “a lot” of data, this is why there is an option to use what we call a DHT proxy (you basically ask another node of the network to sync and listen the DHT for you), mainly used on mobiles and avoid all the sync process.
I know it is tough to demand both security and general usefulness at the same time.
In fact I agree. But clearly sending SMS and syncing with the contact list of the system is a nice have. For the Librem, I think we are more talking about the Gnome client. And that client had the feature to sync with evolution in the past (I removed it because it was bugguy, but it’s not really difficult). But syncing with the system or SMS is only a client feature (aka not difficult, it just takes time). Integrations with other systems is more complex but also interesting.
In fact I would like to encourage work like GNU/Jami while reminding that the ultimate goal is to have any not-so-skilled user to be able to use it
I hope it’s what we think.
3 Likes
Is there a jami cli client or qt client, or anything actually outside electron/gtk lol? The DHT thing sounds pretty cool
The windows client is a qt one (and easy to cross compile, info are in the README)
I did a quick dirty poc for a cli client here: https://github.com/AmarOk1412/ruring but it’s really dirty
@AmarOk1412
Would crowd funding help with you funding more developers to help you be worth a shot?
1 Like
- Telegram — is it really safe?
Telegram is based on MTProto encryption. Entering the market, it has become prominent very soon. Let’s clarify whether it worth it or nor!
Firstly, you should keep in mind that Telegram doesn’t encrypt chats. Moreover, a social graph is not secured, which means that your contacts are stored on the central server.
End-to-end encryption is not working for the group chats. E2EE is supported only on the mobile version but not desktop.
Moreover, Telegram doesn’t allow anonymous registration for its users.
So, if your goal is secure messaging, the only way out is secret chat. Secrets chats are encrypted but are not available from all Telegram versions — some desktop clients lack it. When using mobile activate secure messaging by clicking New Secret Chat.
Remember, that safe data transmission and encryption is working only via the secret chat tool. Data is not stored on the central server.
Also, screenshots are prohibited when using a secret chat. By the way, the secret chat is available only on one of the user’s device; on the other devices, it won’t be seen.
No question Telegram is popular. However I would want potential users to know exactly how Telegram works before using it. If this is the only option on the Librem 5 then we will see but Jami one option that is far better. Jami addresses all the above concerns mentioned in the use of Telegram.
3 Likes
One of your other sources said it WAS encrypted by default. Make up your mind.
I’m not arguing Jami’s merits, nor that Telegram has flaws. I just want you to keep your facts straight.