Berty: Privacy-first messaging app
berty.tech
berty.tech
> Be resilient against mass surveillance by minimizing metadata leakage
While that's an admirable goal, it's also a really difficult-to-solve problem in the context of P2P, so simply mentioning a goal says nothing about the actual state of security of Berty or about whether it's achievable in the first place.
By default (i.e. without any countermeasures like onion routing), a p2p network will expose more metadata to the 3-letter agencies than a centralized app with Sealed Sender[0] like Signal. The people at GNUnet have spent more several man decades trying to solve this issue and last time I checked they were still not happy with their solution.
I have never understood how that works in practice. The server knows the IP addresses (and source ports) of where they are sending and receiving things. How can the server not know who is talking to who?
Also, Signal Messenger Protocol requires a server to store and forward prekeys. Why can't that server just record who shows up to pick up who's prekeys?
The message would arrive at a server and tell the server "I'm going this way." and the server forwards the message in a direction rather on a specific path to some destination.
I'm not sure how one would apply the concept of "direction" to a communications graph.
Also some means of discerning arrival would need to be provided for.
In any case, your description
> The message would arrive at a server and tell the server "I'm going this way." and the server forwards the message in a direction rather on a specific path to some destination.
pretty much matches the idea of the IP protocol built on top of point-to-point connections. The problem is that you still need to specify a direction and that helps an attacker identify and track messages from sender to receiver.
Look at it from a different angle:
The most extreme version of a "one ticket west" algorithm would be one where your message would get broadcast to (or eventually pass by) all participants of the network and all of them would check whether the message is meant for them (e.g. by trying to decrypt it). Needless to say, this doesn't scale well at all, especially not for sending anything bigger than pure text. OTOH this is certainly the broadest sense of direction one could possibly think of and there would be no possible way for Eve to discern to whom Alice is sending her message.
Contrast this with direct 1-to-1 connections between Alice and Bob. Any eavesdropper would immediately see Alice's and Bob's IP address.
Now in between these two extremes lie "semi-direct" messages where the path that the message takes is – at the word says – not direct but instead gets obfuscated by some algorithm. (Your idea being one version of that.) Unfortunately, coming up with a good algorithm is anything but simple and the danger is that a nation state actor with sufficient power would still be able to "hack" the algorithm and undo the obfuscation. This is precisely what the people at Tor and GNUnet are concerned with.
Tor has a much harder job, it's trying to handle full TCP communications, low latency, variable packet sizes, efficiency (no fake traffic), and high bandwidth all compound to make it very challenging.
However you can make the challenge much simpler. First nix TCP, variable packet sizes, and low latency. Pick a packet size like 256 bytes, send packets every 300 ms, and use any spare traffic to maintain the health of a DHT.
Then clients would use the same onion approach, decide the number of hops, and encrypt for those hops like an onion.
So each node would receive messages, decrypt it, if it's a DHT update handle that, if they are the intended recipient decrypt, if it's a forward request decrypt it and queue it for sending on the next free 300ms boundary.
Suddenly it's much harder to track traffic through the network, even with perfect knowledge of each packet's source and destination. Timing attacks don't work because everyone sends 256 bytes ever 300ms. Using packet size to watch traffic go through relays doesn't work.
So much less useful than Tor, but also more resistant to traffic analysis, and plenty of bandwidth for chat.
> Just like blockchain technologies, Berty doesn’t pass your data through central servers - the place where internet service providers, hackers, and governments can intercept your data. Instead, Berty’s network is distributed, based on P2P direct messaging.
I know it's just marketing spiel, but kind of funny to read, as if "just like blockchain technologies" actually means anything to 99% of google play store users beyond "uhh bitcoin?" (or really means anything in this context too).
Maybe it does incorporate some shared ledger, but sounds like its just plain old P2P (which is fine!).
What do you mean by that? Is there a ban on independent mining? Or has starting a new pool become forbidden?
Being centralized is not just being unique, it's being so powerful you get to decide your users' experience, instead of users being in control.
The proliferation of mobile-only apps is making me sick.
I love Discord, but you know... Discord isn't really... anything privacy at all.
On the subject of rendezvous, some years ago I came across a personal P2P project where the author provided an unusual, additional, alternative method for a peer to succinctly and confidentially provide another peer with their address via any arbitrary web page, e.g., a pastebin. Unfortunately I cannot seem to find this project again. Running one's own rendezvous server that only serves up peer addresses and passes no traffic between peers is relatively easy and inexpensive, but it does involve some maintenance. This author had thought about other possible means of exchanging addresses over the public internet. IME that is unusual in P2P projects.
https://retrosharedocs.readthedocs.io/en/latest/user-guide/f...
I have to say that while this dismissal is shallow, it is ...not entirely incorrect... . There is certainly a lot of room for improvement in the current state of ipfs.
We would love to change your mind about ipfs performance and reliability. Once we got a version of iroh that is ready for production, we would be quite happy to let you try it out and get your feedback.
As far as I can see there is no fundamental reason why a set of protocols for content-addressed storage like ipfs can not be fast and reliable.
I really hope your project can improve things, I'd be glad to try it out.
Not before.
What prevents anyone from registering thousands of accounts and send messages to a single user until the account becomes unusable?
Personally, I find the "Stargazers over time" graph on the README to be a massive turn off. Why are so many people obsessed about Github stars.
The site clearly states that a security audit hasn’t been done and that it’s planned in the future. The makers caution people not to trust it completely at this point, especially in war situations.
If only RCS wasn’t such a mess…
It wasn't an easy decision to delete my WhatsApp account because I feared losing access to several friends.
Here's what I did. I checked who my friends were that I couldn't find on Signal or Telegram. I had sent them a message explaining that I would stop using WhatsApp and the reasons why I preferred to avoid using it. I also mentioned on which other platforms I was available and if they would consider being available there too. To my great surprise, most of these people made the move. (Particularly the ones I had often contact with.) For the rest, I'd sent another message in a few weeks saying that I'm uninstalling the app and asking them to send me an email to my email address so that I'd have their addresses.
I find that it's our responsibility to help non tech-savvy people understand their digital choices and set a good example through our very own choices.
I don't trust the large closed hardware blobs on my smartphone.
ps: does anything technically prevent berty from being used as an application on a computer?
Here's what they write about BLE (Bluetooth Low Energy) that they use for connection:
> BLE has the advantage of being compatible between different platforms, but it is extremely slow. It may be suitable for sending small text messages, but it is totally unsuitable for exchanging photos, let alone videos. However, alternatives exist. We will develop this point below.
Node on VM with VPN server let cliens conenct communicate then kill it and there would be no trace of anyhting, and it all takes literally no time.
doesnt france have laws to undermine cryptography? i seem to remember something in this direction
> privacy-first
Thanks, but no.
Open Source. ... read it, fork it, improve it.
Maybe we need to change our behavior, like not needing to talk to each other all the time, or saving our personal conversations for times when we are sitting next to the other in person.
Is this a solution in search of a problem? Or even a solution that is causing a problem?