I recently took a flight with family- on a budget airline that did not have Wifi, so we could not hop on WiFi and message each other using Signal. I wondered what other options there would be in the air- and remembered Bluetooth Communication apps- and had everyone install Briar- it came in haandy!
I like the built in Bridge option as well, (when the app communicates over the internet) to help avoid revealing the traffic is Tor traffic.
I have been impressed by the range of Briar- with a clear line of site, easily hundreds and hundreds of feet- i tested it to well over 500 outside- and on the plane , my family was scattered, but that was no issue at all. (More recently though i've detected my own Bluetooth MotoTag trackers from my luggage in Cargo holds while on planes, so Bluetooth indeed works well on planes.)
-I have heard of but have never used BridgeFy, which I know was a well known famous Bluetooth app that competed with Briar in the past. To my understanding it isn't quite as secure or open source.
There is a informative post here
https://old.reddit.com/r/Briar/comments/gxiffy/what_exactly_...
where a developer noted Briar's capabilities at that time- it seems due to some changes on the OS/phone Hardware end, and whatnot- and due to the phones only passing messages to contact nearby - Briar is not a true mesh networking app. It is a shame- i feel a true Bluetooth mesh networking app would be unstoppable in availability -though it might be a bit of a battery drain.
It is a shame Briar isn't on iOS also -
I also wish Signal would eventually consider communicating over any medium accessible- they would probably run into similar issue Briar has.
What will it take to get a Peer-to-Peer capable Bluetooth/Wifi/Celluar network using/(more possibly in the future)- proper optional mesh networking, Tor capable, VPN friendly, wholly end to end encrypted ,perfect forward secrecy including, fully open source App providing messaging (with the 'accounts' that Briar uses?), for Android and ios?(And Let's throw in PC Mac and Linux, so laptops could have a extremely user friendly user accessible way of doing this as well.)
Better yet, add Calling capability- i don't know how rough doing video calls would be over some methods like modern day Bluetooth- but even a rough capability would be used a little and be worth adding to the collection of things one could do(Briar is only Messaging at the time of this post- which is something notable for sure,as very few apps let you transmit solely thru Bluetooth<I have not heavily looked into the shared Wifi communication abilities of Briar at this point in time> - but more could be added in some form...I observe apps do exist that allow for Bluetooth calling or act like "Bluetooth" Walkie Talkies)
Unfortunately, iOS simply does not allow apps like Briar to run reliably in the background[1]. Unless Apple changes its thinking about iOS, Briar or other similar apps would never work reliably.
Switching ecosystems is a huge pain, I started with iPhone and eventually moved to Android and back again to iPhone. When you use a lot of the Apple/Google Services, it's not really easy to just switch over
No larger screen has ever had issues with permanent damage from regular use. They just aren’t a good fit for most people in their current durability state. Anyone who totally baby’s their phone can use them, but that’s about it. Also, they’re pretty much all in an extreme price bracket. You could buy a small tablet and a regular flagship phone for the price of one of the galaxy folds.
I don’t blindly trust Apple either, but I believe enough of what they say and consider the gaps when they don’t say something. They fight things like the UK E2E encryption requests… but also, having owned both Android and Apple devices, and managing my own iOS devices and the Android devices my parents own, I definitely feel like the iOS devices are more secure and less prone to bad actors via App Store. I think safari is more anonymizing than chrome.
The (US) government already has too much access to us, and I think Android is more open to them than iOS. The government has cameras in public and access to our banking data, I’m not gonna protect myself from them by choosing one platform more than the other, or one bank more than the other.
What I don’t want, though, is to be annoyed to death or scammed. My choice is more front loaded by that consideration. If I find out that Apple accedes to backdoors though, I’d have to live without both Android and iOS.
Android isn't AOSP, and Android isn't open source.
It's safe to assume that every large tech company is spying on everything you do - including Apple. (Remember they're legally required to do so in the UK, and probably in more countries but it only leaked in the UK)
Android is more trustworthy not because of that but because it lets you install apps that haven't been approved by corporate overlords first.
Whether you want to call it a “restriction”, “a lack of permission without being X type of activity”, or “it works because the app exhibits Y behavior”, it’s all functionally a restriction.
You can run some background activities that are not audio apps, but you’re at the mercy of iOS’s decision to keep your task active or not. If you’re off the charger, all bets are off. iOS’s dev docs make this very clear.
I said NOT(rule in "fundamental restrictions") AND (rule is XXX). You showed (XXX in "restrictions"). It would have been sufficient to prove my statement false if "fundamental restrictions" === "restrictions", but it is not.
I am not here to debate meaning of words. If LLaMA 3.1 8B can understand the difference between a fundamental restriction and a restriction in general on its own, so can you. If you feel like this topic is worth your time for intellectual pursuit, feel free to debate with it: https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct I don't feel that it is worth mine. See if you can convince it the definition your are implying is more accepted than the one I am.
You say that, but then you dedicate a whole paragraph to my potentially (I’m not a native speaker, so it’s very possible) incorrect word usage :)
But also, I took your advice and had a chat with an LLM – seems like it's pretty much in agreement with my understanding of the meaning of "fundamental" as a plausible one.
In this context, fundamental just means something inherent to the system, like a thing that can’t happen because of the way the system was defined. A boat fundamentally can’t fly, because it wasn’t made in a way that would allow it to fly. This is different from a plane which is restricted from flying because of a no-fly order. There’s no fundamental restriction (the plane was designed to fly, after all) but there is something keeping it from flying. And maybe one plane get special permission to fly despite the no fly order—that’s a carve out.
So with iPhones, they are built in such a way as to allow background execution (there is no fundamental restriction) but Apple has made it so they cannot do so, with certain carve outs for things that people will want to be able to do while the app is in the background, like listening to audio or tracking the phone’s movements with gps. So there isn’t a fundamental restriction to background execution, it’s just a rule Apple makes (and then makes some exceptions to).
There are other ways you could use the word fundamental, as in something that is important because other things rely on it. But that’s not the way it was being used here.
Hope that helps!
Not sure what you mean with fundamental. As mentioned in the thread parent comment links to, the issue lies in enforced limits and lack* of general mechanism available to developers to allow background execution for any kind of app or/and purpose. No one said iOS itself lacks the functionality for background execution.
*In the same thread, it is noted that this lack is by choice and special-purpose mechanisms are preferred instead to prevent abuse.
It's not an issue of sideloading or censorship in iOS. It's a product decision related to background apps (they kill the running process with no recourse to bring it up again on its own).
In Europe it's been ruled that since Apple makes no pretense of being competitive, they don't have to be, while Google has to actually deliver on their open platform promises.
> so we could not hop on WiFi and message each other using Signal.
I have a feature request for this actually. I think if it got a harder push they would consider it. It's not full decentralization but does still prevent the concerns that Moxie and Meredith have stated.
It is like you say: I too wish Signal would allow for communication over any available medium.
Have you seen Meshtastic (https://meshtastic.org/)? It seems like a similar concept but using dedicated devices and unlicensed ISM frequencies, and it's a proper mesh network (so you can even setup repeaters to provide better coverage for an area). I guess they wouldn't work too well if you're travelling to another country since you'd have to get the right radios for the country but it's a neat idea.
Furthermore, the latest build of Meshtastic mentioned some LAN networking, so nodes that don't have radios can still exchange messages if they're connected by some other means.
That seems just a hop skip and a jump from having a Bluetooth WPAN/WLAN that lets many phones share one or zero Meshtastic radios but still be able to talk to each other...
How was your actual UX with Briar? I tried to get family to use Briar during a flight and it was pretty poor. Messages wouldn't show up and we were worried about disconnecting from personal Bluetooth headphones while keeping using Briar. It worked okay and at one point my partner and I chatted about landing plans when the person next to us was asleep. But we found that just passing the phone around with typing worked just as well. It worked okay for the other family but again, was a pain.
It worked well! Most messages did go through! The caveat- I don't think anyone was also using Bluetooth headphones
500 feet outside was the test i did with a clear sightline- the inside of the plane was not quite as far, but the messages did go through - and we couldn't have passed the phone around when one family member was 5 seats behind me, the next was about 20 rows in front of me
I've really been trying to get Signal to get some decentralization[0] but unfortunately I pissed off some mods. I do understand their reasoning for staying away from full decentralization, both Moxie and Meredith have made good arguments. But I think this is something where there's a really good middle ground. Where both parties highly benefit.
Users get a lot of added utility, "fun", and not to mention a huge upgrade in privacy and security (under local settings), while Signal gets to reduce a lot of data transfer over the network. There's a lot of use cases for local message and file sharing (see thread) and if the goal is to capture as little data as possible about the users, well let's not capture any network traffic when users are in close proximity, right? It's got to be a lot harder to pick up signals that only are available within a local proximity than signals traveling across the internet. The option of expanding to a mesh network can be implemented later[1] but I don't understand how an idea like this doesn't further the stated goals.
The big problem with things like Briar is that you can't install it after the internet has been turned off AND it is already unpopular. But if an existing app with an existing userbase implements even some meshing then this benefits all those users when an event like that happens. Not to mention there's clear utility in day-to-day life.
[1] I think a mesh network maintains the constraints both Moxie and Meredith have discussed, concerns about ensuring servers are up to data. But then again I'm not sure why that can't be resolved in the same way it is already done where if you let Signal fall too far behind in updates then it will no longer communicate with the servers.
Secure Scuttlebutt can do similarly. A wandering node can ferry messages to another cluster of nodes; it's used by sailboats where someone visits shore to run errands and exchanges messages as they go.
Do you know of any documentation to get SSB bootstrapped? I tried several times, but I hit a wall of not being able to find any active communities, plus there were old-style, technically obsolete communities and new-style communities, and half the available documentation referred to each, so it was impossible to figure out what to do.
I find it fascinating to read about, but it seems to have a steep and very slippery social hill to climb before the technical parts of the network do anything.
Other phones with Briar installed can carry your (encrypted) messages, as in a game of whisper. This works best if enough people between you and the recipient had Briar installed ... but most people don't.
But I see how this feature could be very helpful if a state shuts down internet connectivity or during war or a natural catastrophe. The nifty thing is that the app can be shared from one device to another, so you are not dependent on having the app in advance of an emergency.
Ideally, everyone should have this installed as an insurance :)
This is not true, unless you are all in one big fourm or you have a chain of shared blogs. I think they are woried about metadata privacy or people using this to do a DoS.
DoS by local users on local networks? This is that thing where you solve the cryptography problem with the $5 wrench but only slightly different, right?
Someone not participating in briar or the DoS can use fing (android app) or a signal strength meter (handheld, I have 2, personally) to direction find and triangulate the person sending the traffic. Hence $5 lead pipe.
A bunch of countries turn off the internet at the first sign of protests, hell sometimes they just turn it off to stop "a bunch of college kids from cheating during test week"
> It does if you consider that everyone can act as a relay.
Let's think this through. Imagine civil war breaks out in Australia, and communications infrastructure is destroyed or shut off. I'm in Sydney and want to transmit a message to a friend in Perth.
How exactly is "everyone acts as a relay" going to work? In particular, how is it going to scale when everyone in the country is trying to do the same things?
> This is also how apple airtags can be find anywhere there's an iphone users nearby.
This is incorrect. Airtags (and the Google version) communicate with nearby Internet-connected devices, via Bluetooth and NFC I think. Those nearby Internet-connected devices send the airtag's location to a server.
Nothing about this would work without the Internet.
Yeah, I think current tech assumes a server relay. However imo, and if I were to imagine a solution, in this case I think a message would need a ttl, say 24 hours. In a local mesh/hive everyone would store a copy of the undelivered messages. When people move between hives they would sync these undelivered messages where ttl didn't expire. With perhaps a storage limit of say 1k undelivered messages. Undelivered means a destination user that didn't show in a hive. Wdyt?
> With perhaps a storage limit of say 1k undelivered messages.
If you want this to scale you'd need a scheme to deal with limited cache per device. Something like having each device assign a random priority to each message it has in transit. That way everyone culls a different set when things fill up.
> would need a ttl, say 24 hours
Probably better off scaling priority by age. That way you deliver if at all possible, until it eventually falls out of cache. Some people will be able to dedicate much more storage than others.
> Airtags (and the Google version) communicate with nearby Internet-connected devices, via Bluetooth and NFC I think
Yes, exactly (BLE, UWB, NFC).
First, Airtags only have a coin-cell battery. It is not remotely viable for them to be doing any sort of serious "communicating" because the battery would die in seconds.
Second, making the Airtag effectively a dumb device means you gain the various security and privacy benefits, and means everything needed to make the magic happen can be transmitted in a single BLE/UWB/NFC packet (bringing us back to the battery life aspect already mentioned).
> I haven't studied the protocol but that seems like it has some...obvious routing issues.
Yes indeed. I don't understand how the peer-to-peer relaying can possibly scale without some directed routing algorithm.
If my phone running Briar is literally handing off every as-yet-undelivered message to every other phone running Briar, we're going to pretty quickly become overwhelmed.
Parent didn't say all the internet at once, it could just be a matter of telling telecoms to block connections within certain geofences when protests start to flare up, Egypt 2011 style.
Could even bring down 4G services while whitelisting POS terminals, keep the Starbuckses up and running.
It's kind of interesting to see P2P coming back! I'm happy to see more P2P projects popping up. When the Snowden leaks came out, there was a brief interest in P2P encrypted messaging. I wonder if the political climate now is bringing interest back.
Back in 2014 (I believe briar started in 2015) I wrote a realtime P2P application platform. Not only could you send encrypted messages between people, but you can also send files, play games, and write and share programs together, all within the application. The use case for mine is different than briar's.
Briar is really interesting from the PoV of its forum and blog features, that try to use the messaging platform as infrastructure to build private services.
There's a lot of discussion about alternatives here so I'm going to drop one more: https://cwtch.im
It has wider range of clients and some unique features, like the ability to run multiple, password protected identities trivially, to appear online selectively.
I just wish one could delete or edit on briar's forums. Without that, I feel like I have to be super careful not to make a mistake, if I want an orderly forum. Also in latest versions the ability to fold forum threads is gone? Makes forums annoying to read. The indentation for a sublevel being sooo thin also doesn't help at all.
Sounds like a cool project, but the name is such a bad idea, despite the cleverness of word choice. An app for a niche use case has it hard enough, doesn’t help that nobody can spell correctly even when reading it.
Why invent wheel when we already have Reticulum network which provides integrity and confidentiality on OSI Layer 2 ? So for every packet. It is not better to build "apps" on top of a secure network? That way even if "app" does accidental bad thing, your private content is not exposed to anyone who listens to your network traffic. By default not by "just use another VPN with exit nodes full of network inspection tools, dns redirection services etc" ?
Reticulum seems to be by far the most interesting project in this space.
I would invite anybody to explore it for a few hours at least, it is fascinating.
Now the only thing that scare me about it is that it is really a "one man" project [0].
I am not sure why, I do not know if anybody else look or understand what he is doing, but hell it doesn't make me feel confident to rely on it.
I thought this was sarcasm, but it isn't. Seems like a very weird choice to me to build network infra on top of Python. C/Rust would have been the more obvious choice since you can then bind to that from any language (at least with C).
you mean how everyone built on top of ipv4 and can't abandon it now, even after 3 decades of it's replacement being available and more secure? Or how everyone uses TLS now, not because it's the best way but because like 'Reticulum' it became the best bloated compromise?
General purpose systems aren't always ideal, they're just ideal to gain mass adaption. For applications who target smaller sets of users and prioritize security guarantees, being able to fix bugs at any 'layer' and not depend on external entities is crucial. How I'd wish they'd even use their own Layer 2/3 stack if it were practical.
As someone familiar with networking and Reticulum, I felt confused by reading this thread. I felt the need to explain Reticulum in the networking stack. So here goes.
You can think of Reticulum as a mix of the internet layer and a message-semantics oriented transport layer. Reticulum is focused on trustless, encrypted data transfer with message-oriented semantics suitable for devices with small MTUs.
In current IP-based stacks these are separated at great compromise. First of all, the internet layer is unencrypted. Any actor listening to internet layer traffic can intercept and track or modify IP packets (and indeed this is used for things like NAT.) Secondly, link layers are disparate and fragmentation is used to make sure that IP packets can run atop the link layer. Most modern networking stacks are (UDP|TCP)/(IPv4|IPv6)/(Ethernet|802.11). Ethernet and 802.11 ("WiFi") frames are large enough to comfortably deliver IP packets with minimal fragmentation.
Applications on the internet often send/receive messages but do this at a level above TCP. TCP fragments data atop IP but has stream-oriented semantics. UDP can be used for message-oriented semantics if used very carefully, but UDP packets are delivered with best-effort and UDP packets are often delivered out-of-order or dropped due to congestion and other reasons. There have been several attempts to add message-oriented semantics onto the net. SCTP is in heavy telecom use but seems to be mostly dead in the consumer space. (I recently ran iperf on a recent Linux kernel build and was able to get 8 Gbps on loopback TCP but only 600 Mbits on loopback SCTP. Unsure if I needed to do something different than what iperf does.)
TLS can be layered atop TCP to add security, but that security is only available at the TLS layer and involves trusting Certificate Authorities. QUIC goes atop UDP but also uses the same CA style trust model of TLS. Both QUIC and TLS+TCP are stream-oriented. QUIC has unreliable datagrams which allow message-oriented semantics but this is unreliable. Moreover, all of these protocols rely on delegated authority. Your ISP will give you an IP address that it will route packets for and often this address lives as long as your ISP connection does and will reset when your connection does. If there's NAT involved on IPv4 then you don't even get end-to-end connectivity with your address. Your ISP also has a block of IPs and there's a huge governance structure involved in deciding which entities have which IPs and announcement protocols which announce IP routing tables. Reticulum doesn't rely on delegated authority or governance as much.
Then the other side of the problem is MTUs. Ethernet and 802.11 frames are large enough that IP and TCP can sit atop them well with minimal fragmentation. Fragmentation adds header overhead. However when you get to links like LoRa or TNCs, your MTUs are much smaller. Running IP on these links may be doable but TCP will probably be flooding the link with mostly fragmentation overheat. Reticulum is designed to work better with low MTUs allowing you to bring in links that are associated usually with much higher latency or lower bandwidth such as LoRa or TNC.
For our wold as-it-is, the current state of TCP/IP works fine. ISPs are built out with this model, the governance remains robust, and we rely on utilities to build out the high-MTU links that our comms infrastructure rely on. But if you find yourself dealing with situations with low-MTU, smaller links or low-trust situations, then Reticulum could be of interest. Ad hoc networks are great deployments for Reticulum, for example. There's a lot of innovation going on in this space. See Yggdrassil for a solution with stable-addressing based on key-derived IPv6 addresses and P2P routing which works well when you don't have low-MTU links.
I just read through the documentation for Reticulum but I'm not sure what the point of it is. It looks like a Tor like network written in Python? As far as I can tell the entire thing runs virtually over TCP.
The manual says something about physical networks (is this intended to replace ethernet?) but it also mentions a current throughput of 40mbps so surely that's not what you're supposed to use it for.
Reticulum supports multiple interfaces to transport data, TCP is just one of them. Other are ethernet, packet radio TNCs (think ham radio), LoRa, stdio/pipes, I2p, etc. More details on some of the supported interfaces http://reticulum.network/manual/interfaces.html
None of the given descriptions have been too clear about what it is, though.
It appears to not be a drop-in solution for communication like Briar, so why make a comparison here in the first place?
Instead, it appears to be physical layer-agnostic (it doesn't care if it's run over internet or HAM-radio) infrastructure to build tools on top of. So,
* Is it an end-to-end encrypted overlay network like corporate VPN/Tailscale/Hamachi?
* Is it an end-to-end encrypted protocol between two or more endpoints like SSH?
* Is it an end-to-end encrypted messaging protocol between two or more users like OTRv3?
The entire documentation returned zero results for "Tor" or "onion" (routing), so what's the improvement over Briar+Tor?
Those "journalists" they claim to protect could get into serious trouble for merely using Tor. From there it's a trivial matter of rubber hose cryptanalysis to defeat the rest of the "protection". The danger with such tools is someone without proper training thinks they're a super spy, and then they draw attention of the people who actually understand such things, and can put a bag over their head and deliver them to a black site.
Briar is a nice idea, but last time I used it I couldn't find peers, if memory serves. I tried adding a friend who was interested and we sat and waited for our messages. They never arrived.
PGP stopped being the recommendation in 2004 when OTR became a thing with its forward secrecy. I really do not get the charm of repackaging PGP as a messenger, especially when it still has no forward secrecy: https://delta.chat/en/help#pfs
I mean, if you're not using Tor, your IP and thus identity will leak to the server anyway. So you should probably just use Signal that has double ratchet giving you forward secrecy and break-in key recovery.
Today, PGP's safest use-cases are digital signatures and airgapped comms. But, you'd probably do the latter with TFC as it has much better key/pt exfiltration guarantee.
There's a lot going on in the space. It is more innovative than you're giving it credit for, especially around double ratchet. Not there yet, but there's a good reason why I don't mind: control. Multi client support (DeltaChat desktop, hallelujah) and the fact that email remains federation-first.
My identity definitely leaks to my server because I pay it's bill. Not only that, but most of my contacts run their own email or borrow it from me or someone else. Our data does not leave any EU countries apart from the UK. We have IM that doesn't involve any Americans.
Some might imagine we feel terribly smug about that right now :)
I have tried it and it is very usable, if a little bare-bones. Unfortunately, Bluetooth doesn't work for me, but everything else works fine.
Development seems to have slowed down a little, which is a shame. There is still no good widespread application for peer-to-peer communication.
In terms of functionality, I miss a "one to many" feature. For activism, disaster management, or even just organising a slightly larger group, it would be immensely useful to have a channel that people can subscribe to (but not write to) and that syncs via trusted contacts, without having to manually reblog everything. Forums are also a bit problematic without moderation and when anyone can invite new users.
The idea is great, but the adoption rate is way to low for any P2P thing to actually work (unless with agreed upon meetings).
Meshtastic is a better option, because it uses LoRa (thus requires additional hardware), but with a good location, many kilometers can be covered and mesh networking extends this a lot further. Meshcore is supposedly the next "generation" of meshtastic, but not popular enough over here to actually test it.
iOS doesn't allow apps to stay active in the background to listen for messages like Android can. And since Briar very much does not rely on the vendor push services that is a showstopper.
Indeed, this is very much a limitation for all apps on iOS that don't want to rely on centralised services, such as a push notification server other than Apple's.
I’m not sure where you’re pulling “backdoored” from, but if Apple markets their devices as private then it seems reasonable that end users expect a private device.
The last time I checked, a lot of the nodes are just run in Hetzner's data centers meaning there's not too many actors. I can't even find that list anymore so if anyone has one, I'd like to update my knowledge.
Not seriously, no. But I was completely amazed by the UX: get the app, create an account by clicking a button: no email/phone nor any other "verification". Back up the seed phrase so as not to lose your account. It just works!
It used to be the case you could only exchange keys in person, but X25519 was introduced in 2016, and it was bumped to X448 in 2019. You can of course still exchange PSKs as it's currently the only post-quantum key exchange it can offer. QR-codes are not used, instead, imported strings are split into small segments that are typed manually. The program then does what it can do, to help the user identify typos.
The threat model is excellent, except: “The adversary can’t break standard cryptographic primitives”
Let’s assume they can and you can swap in non standard crypto models to frustrate and vex ‘the adversary.’ (Lol: “the adversary”… religious)
More info, the threat model:
All long-range communication channels (internet, phone network, etc) are comprehensively monitored by the adversary.
The adversary can block, delay, replay and modify traffic on long-range communication channels.
The adversary has a limited ability to monitor short-range communication channels (Bluetooth, WiFi, etc).
The adversary has a limited ability to block, delay, replay and modify traffic on short-range communication channels.
The adversary can deploy an unlimited number of devices running Briar.
There are some users who can keep their devices secure - those who can’t are considered, for the purposes of the threat model, to be controlled by the adversary.
The adversary has a limited ability to persuade users to trust the adversary’s agents - thus the number of social connections between the adversary’s agents and the rest of the network is limited.
The adversary can’t break standard cryptographic primitives
>The threat model is excellent, except: “The adversary can’t break standard cryptographic primitives”
>Let’s assume they can
Let's not.
The weak key sizes (<90 bits), broken primitives (SHA-1, MD5, DES), and weak modes of operation (ECB, unauthenticated CBC) are all known.
We know the Grover cuts symmetric key sizes in roughly half, and we know Shor will break classical asymmetric algorithms, so the industry is upping key sizes and moving into hybrid schemes that add post-quantum algorithms.
>non standard crypto models
Here's a thought: Submit your primitive (the rainstorm hash function) into the SHA-4 competition whenever it's due, and win it, or at least become a finalist. Then you don't have to sell it to serious projects as security through obscurity.
Surely you realize Briar is open source so the implementation of your hash function will be available to the attacker, and they can perform cryptanalysis on it to their heart's content? So you can't really get over the fact it needs attention from the professionals.
If you want to be taken seriously, maybe start by improving on attacks over existing algorithms? That distinguishes you from the random cranks who think they've come up with improved schemes.
It seems insufficiently secure to just trust that the people who designed the ciphers you use, and who also are responsible for breaking ciphers at state-level, would tell you if they could break those ciphers. Hahaha :)
Ok so you have no idea who's vetting the algorithms at competitions. It's the other participants. That's going to be you among others. You get to break apart all the competing algorithms that claim to be better than yours. And they get to show you if yours is the weaker one, as they also want to win the competition.
Sure, you can't put fox to guard the henhouse that's how you get stuff like DUAL_EC. But that's not the case in modern competitions. They are open to the public, and academic in nature. Everyone gets to analyze them.
We don't know who you are, what are your credentials, and we don't have any proof of you showing you have what it takes to analyze current standards, let alone create new primitives resistant to cryptanalysis. Until you decide go the long way, you'll find yourself treated as yet another Crown Sterling.
Even better, it's the general public. Anyone who wants to can publish an analysis at any time, even after the competition ends. If someone published a practical attack against SHA-3 tomorrow the recommended standards would change overnight.
"The adversary" is standard terminology in analyzing cryptographic security.
It would be interesting to figure out who introduced it. I looked briefly on Google Scholar, and I see it's used in the modern sense as early as Yao (1982), but it might have been used much earlier. It doesn't appear in the Diffie-Hellman (1976) or RSA (1977) papers.
"Adversary" is simply a standard English word. It is neither religious or jargon. My assumption is that the reason it is often used in cryptography papers is because "attacker" rings a bit harshly when you repeat it over and over again.
Attacker rings harsh, and very limp. "The Adversary" is a common occult, religious and Biblical term for the Devil, Satan. The Hebrew word Satan means "the adversary". That's why it's funny and appropriate, lol!
Briar runs a Tor Onion Service on your device. I'm unsure how well Tor supports having multiple devices acting as the server. One option could be to have a main program that's always on, to which your messages are received, and other clients can then use the Onion Service to fetch a copy of the conversation. It would add another link in the chain and increase latency so I'm not surprised if that's not being done.
The BT MAC is shared with peers so they can find you (as well as a list of your IP addresses) but I don't think identity is tied to it. Identity seems entirely tied to a public certificate. But I could be wrong.
I spent a little time ~2012 trying to think how to create a system like this that would work with iPhones at burning man. Never really got anywhere with the idea, but I’m excited to try this!
Even now, when I see Briar's name anywhere, I think of this as "ah, that Android only app" and that imho is saying something for a privacy messaging app. I am not saying it has not reason (Apple's unsound, unfair, and consumer hostile tight control is the reason! [1]) to be Android only, I am just saying - it's very unfortunate and unfortunately defeating.
[1] In the name of privacy theatre which they have actually been able to defend by spending both on PR and lawyers.
iOS vs Android is a bit like ChromeOS vs Windows/MacOS/most Linux distros.
There are benefits to more restrictive operating systems. For example, iOS not allowing apps to run in the background essentially stops any apps with malware from doing stuff in the background, but it also stops apps like Briar, Syncthing, etc, from working well.
I assume Android isn't a problem for most Briar's users. They're likely running a deGoogled Android version (GrapheneOS, LineageOS, etc) and downloading/updating the app via F-Droid or something like that. They don't rely on Google (or Apple) to run anything.
The problem is the networking effect. Since so many people use iOS, even Android users often have to contact people on iOS devices, resulting in Briar likely remaining very niche.
Yup, from what I hear, the problem is Apple doesn't allow process forking which means Tor would have to run inside the same process as the messaging app which is ridiculous.
I haven't heard this particular rumor, not like they have In-Q-Tel connections a la Wickr, but they do take funding from the Open Technology Fund [0] which some of the more righteously paranoid take issue with, being US State Department and all. Same parent as Radio Free Asia, Radio Free Europe, Voice of America [1].
Serious question for whoever actually understands this: what is the legal status of true, peer-to-peer, attack-resistant encrypted messaging in the "western" world? I'm particularly interested in the USA, the UK, Australia, New Zealand, and whatever European countries you care to throw into the mix.
I've occasionally tinkered with building software (but never released said software) that uses encrypted peer-to-peer connections as the _sole_ way of communicating, because it seemed like the most natural way to build said software _and_ the most interesting technically. (And I have zero interest in hosting servers for FOSS side projects.) If I were to actually release one of these projects and it were to become popular, should I expect to be shut down by law enforcement on the grounds that it's already unambiguously illegal? Or would I likely receive a "Technical Assistance Notice" at some point, effectively requiring me to sneak a back door into the software? Or is it actually fine?
I seem to recall all sorts of stories about law enforcement and "TLA agencies" pressuring vendors of secure messaging software to make the software unavailable or to add back doors, including at least one who chose to shut down their business rather than lying to their users about the security of the product. But somehow in all this I failed to glean whether or not it's actually meant to be legal, even on paper.
I know of no law here in Germany that would make it illegal, heck, Germany allows me to sign my PGP Key with my National ID. There has been some conservative resistance over the years but it's still legal and in practice for the normal user simply not an issue. Unless you are using things like Anom or other messengers that are like exlusively used by criminals and even it's not illegal in itself you might at worst get caught up in a sting operation when they take down the central servers.
Fun fact most Tor exit nodes are in Germany. Hosting those is more risky.
Heard from where? How would they do that? Tutanota doesn’t have the key, the end user does. I keep hearing weird things about Turanota that sound like the types of rumors intelligences agencies who really don’t want people to use the service would start.
Encryption for end users is de facto legal almost everywhere except for UK. For vendors it's illegal almost everywhere maybe except for USA, but that's just how the law works in USA: you receive a subpoena, then it's up to your luck.
It's not illegal for vendors, they just have to colaborare with law enforcement when a subpoena is received, and this collaboration can entail attacking their own users as long as a technical capability to do so exists.
If you think about it, it's more or less the only way this could work in any democratic society.
> Encryption for end users is de facto legal almost everywhere except for UK.
Encryption is legal in the UK.
But if the government turns up asking for your decryption keys, "you can't have them" is not an option unless you wish to enjoy the luxurious surrounds of a prison cell until you change your mind.
Which, to be fair, is basically the case worldwide, as per the famous XKCD cartoon[1].
If you don’t have they keys, you can’t hand them over, for one thing.
Also, the wrench treatment is extremely unlikely in most democracies. Now, deplatforming such as seizure of DNS names and such, is another matter and varies, often orthogonally to the risk of wrench treatment.
We're talking about "if the government turns up asking for your decryption keys, ...".
> Where has this happened?
Pretty much everywhere. Even in the US you can only avoid it if you're careful; if you admit to knowing the keys then you can't. Either way you're dealing with the "criminal prosecution process" as GP pointed out.
> There's deniable encryption to counter the wrench attack
The trouble with deniable encryption is its viable use-case is very narrow.
It is, for example, not viable to use deniable encryption when exchanging messages with others.
If the authorities, through whatever means, get the a copy of an encrypted message you sent, and they have done sufficient metadata homework to link it back to you, find your address and come knock on your door, then you are going to seriously struggle with a deniable encryption defence.
I would look into wassenar if I were you, an artifact of the cold war, encryption can be treated like a munition. Nothing stricter than that from what I’ve seen. Yet.
end-to-end encrypted messagess, when the end-points (Android, iOS, Windows, etc) are basically spyware?
On top of that it runs through servers running who knows what, closed source stuff. So who knows if they're somehow decrypting everything on there before forwarding re-encrypted stuff?
In the Five-eyes jurisdiction, it is legally allowed to use strong end-to-end encryption. Any potential laws that are contrary to that would come up against some serious 4th amendment issues. The idea of cryptography as a munitions was largely set aside in the name of capitalism.
Tor was funded by the U.S. Department of State. Signal and WhatsApp are end to end encrypted.
We, as a society, are under constant attacks on our ability to maintain our privacy. As we've seen in large political and technological shifts, it only becomes more important to maintain your privacy. Deep fakes used in scamming relatives is one good example.
Please do release your software and ideas that make information more secure.
I recently took a flight with family- on a budget airline that did not have Wifi, so we could not hop on WiFi and message each other using Signal. I wondered what other options there would be in the air- and remembered Bluetooth Communication apps- and had everyone install Briar- it came in haandy!
I like the built in Bridge option as well, (when the app communicates over the internet) to help avoid revealing the traffic is Tor traffic.
I have been impressed by the range of Briar- with a clear line of site, easily hundreds and hundreds of feet- i tested it to well over 500 outside- and on the plane , my family was scattered, but that was no issue at all. (More recently though i've detected my own Bluetooth MotoTag trackers from my luggage in Cargo holds while on planes, so Bluetooth indeed works well on planes.)
-I have heard of but have never used BridgeFy, which I know was a well known famous Bluetooth app that competed with Briar in the past. To my understanding it isn't quite as secure or open source.
There is a informative post here https://old.reddit.com/r/Briar/comments/gxiffy/what_exactly_... where a developer noted Briar's capabilities at that time- it seems due to some changes on the OS/phone Hardware end, and whatnot- and due to the phones only passing messages to contact nearby - Briar is not a true mesh networking app. It is a shame- i feel a true Bluetooth mesh networking app would be unstoppable in availability -though it might be a bit of a battery drain.
It is a shame Briar isn't on iOS also -
I also wish Signal would eventually consider communicating over any medium accessible- they would probably run into similar issue Briar has.
What will it take to get a Peer-to-Peer capable Bluetooth/Wifi/Celluar network using/(more possibly in the future)- proper optional mesh networking, Tor capable, VPN friendly, wholly end to end encrypted ,perfect forward secrecy including, fully open source App providing messaging (with the 'accounts' that Briar uses?), for Android and ios?(And Let's throw in PC Mac and Linux, so laptops could have a extremely user friendly user accessible way of doing this as well.)
Better yet, add Calling capability- i don't know how rough doing video calls would be over some methods like modern day Bluetooth- but even a rough capability would be used a little and be worth adding to the collection of things one could do(Briar is only Messaging at the time of this post- which is something notable for sure,as very few apps let you transmit solely thru Bluetooth<I have not heavily looked into the shared Wifi communication abilities of Briar at this point in time> - but more could be added in some form...I observe apps do exist that allow for Bluetooth calling or act like "Bluetooth" Walkie Talkies)
Unfortunately, iOS simply does not allow apps like Briar to run reliably in the background[1]. Unless Apple changes its thinking about iOS, Briar or other similar apps would never work reliably.
[1] https://developer.apple.com/forums/thread/685525
People have the power to not use iPhones, and should exercise it.
Switching ecosystems is a huge pain, I started with iPhone and eventually moved to Android and back again to iPhone. When you use a lot of the Apple/Google Services, it's not really easy to just switch over
It's only Apple that does this lock-in thing, IME. Google also has services, but they're not as important or inseparable.
Honestly with Apple not producing folding phones I think in a few generations everybody will have naturally moved to Android
This is such a weird take. Folding phones are a tiny market and they all have considerable durability downsides.
Also, if the market did shift Apple could easily build one. I’m sure they’ve prototyped a few already.
People said the same thing about bigger screens years ago
No larger screen has ever had issues with permanent damage from regular use. They just aren’t a good fit for most people in their current durability state. Anyone who totally baby’s their phone can use them, but that’s about it. Also, they’re pretty much all in an extreme price bracket. You could buy a small tablet and a regular flagship phone for the price of one of the galaxy folds.
If only folding phones weren't prohibitively expensive, fragile, and most notably completely pointless...
They're basically going to replace your phone and tablets. But people have a hard time seeing into the future
Will that be before or after flying cars?
I don’t trust Android.
What do you not trust of AOSP? How can you trust a proprietary closed-source OS more than an open-source one?
I don’t blindly trust Apple either, but I believe enough of what they say and consider the gaps when they don’t say something. They fight things like the UK E2E encryption requests… but also, having owned both Android and Apple devices, and managing my own iOS devices and the Android devices my parents own, I definitely feel like the iOS devices are more secure and less prone to bad actors via App Store. I think safari is more anonymizing than chrome.
The (US) government already has too much access to us, and I think Android is more open to them than iOS. The government has cameras in public and access to our banking data, I’m not gonna protect myself from them by choosing one platform more than the other, or one bank more than the other.
What I don’t want, though, is to be annoyed to death or scammed. My choice is more front loaded by that consideration. If I find out that Apple accedes to backdoors though, I’d have to live without both Android and iOS.
Accedes is a good word, I don't think I've ever seen it before.
the root of accede makes "Accessible", too; that which enables one "to enter".
Android isn't AOSP, and Android isn't open source.
It's safe to assume that every large tech company is spying on everything you do - including Apple. (Remember they're legally required to do so in the UK, and probably in more countries but it only leaked in the UK)
Android is more trustworthy not because of that but because it lets you install apps that haven't been approved by corporate overlords first.
Okay, buy me an Android then.
If you bought an iPhone you could buy an Android.
But I don't want an Android. So if you desire for me to use Android, buy me an Android.
Advice is not desire. I advise you to keep batteries in your fire alarm, but I don't personally care enough to buy you any.
Didn't really sound like advice.
And thats we are different. I would.
I actually have an app in iOS store that completely executes in the background: https://itunes.apple.com/app/id6737482921?mt=8
Never had it stopped by iOS. So not only there's no fundamental restriction, the App Store itself allows some apps to do that.
What API are you using to keep running in the background? Most likely you are misusing it on some manner and have yet to get caught by App Review.
I've seen this bypassed via background audio and background location.
The app does background audio, and its use is legitimate. It is an audio app.
But the point is - there's no fundamental restriction from the OS itself.
You contradicted yourself.
Whether you want to call it a “restriction”, “a lack of permission without being X type of activity”, or “it works because the app exhibits Y behavior”, it’s all functionally a restriction.
You can run some background activities that are not audio apps, but you’re at the mercy of iOS’s decision to keep your task active or not. If you’re off the charger, all bets are off. iOS’s dev docs make this very clear.
No, basic set theory: not every restriction is a fundamental restriction.
Elaborate?
I said NOT(rule in "fundamental restrictions") AND (rule is XXX). You showed (XXX in "restrictions"). It would have been sufficient to prove my statement false if "fundamental restrictions" === "restrictions", but it is not.
Another way of phrasing this: There is a fundamental restriction, with a carve out for a few specific things, including audio playback.
I don't think you understand the difference between a fundamental restriction and a restriction in general.
What’s not fundamental about the OS pausing any background thread that doesn’t have an excuse to continue running from a relatively short list?
I am not here to debate meaning of words. If LLaMA 3.1 8B can understand the difference between a fundamental restriction and a restriction in general on its own, so can you. If you feel like this topic is worth your time for intellectual pursuit, feel free to debate with it: https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct I don't feel that it is worth mine. See if you can convince it the definition your are implying is more accepted than the one I am.
> I am not here to debate meaning of words
You say that, but then you dedicate a whole paragraph to my potentially (I’m not a native speaker, so it’s very possible) incorrect word usage :)
But also, I took your advice and had a chat with an LLM – seems like it's pretty much in agreement with my understanding of the meaning of "fundamental" as a plausible one.
In this context, fundamental just means something inherent to the system, like a thing that can’t happen because of the way the system was defined. A boat fundamentally can’t fly, because it wasn’t made in a way that would allow it to fly. This is different from a plane which is restricted from flying because of a no-fly order. There’s no fundamental restriction (the plane was designed to fly, after all) but there is something keeping it from flying. And maybe one plane get special permission to fly despite the no fly order—that’s a carve out. So with iPhones, they are built in such a way as to allow background execution (there is no fundamental restriction) but Apple has made it so they cannot do so, with certain carve outs for things that people will want to be able to do while the app is in the background, like listening to audio or tracking the phone’s movements with gps. So there isn’t a fundamental restriction to background execution, it’s just a rule Apple makes (and then makes some exceptions to). There are other ways you could use the word fundamental, as in something that is important because other things rely on it. But that’s not the way it was being used here. Hope that helps!
Plausible is not more common/more accepted.
Not sure what you mean with fundamental. As mentioned in the thread parent comment links to, the issue lies in enforced limits and lack* of general mechanism available to developers to allow background execution for any kind of app or/and purpose. No one said iOS itself lacks the functionality for background execution.
*In the same thread, it is noted that this lack is by choice and special-purpose mechanisms are preferred instead to prevent abuse.
There's AltStore sideloading, would that enable it?
It's not an issue of sideloading or censorship in iOS. It's a product decision related to background apps (they kill the running process with no recourse to bring it up again on its own).
As I understand it, only Apple's own apps get the magical blessing to run in the background whenever they want.
Hmm, seems anti-competitive.
In Europe it's been ruled that since Apple makes no pretense of being competitive, they don't have to be, while Google has to actually deliver on their open platform promises.
Anti trust enforcement was tried briefly at the turn of the century but was deemed unprofitable for oligarchs, so it is no longer in fashion.
Eh, it has seen a mini resurgence recently
This affects other Bluetooth-using apps too, like the Fitbit app needs to be periodically restarted in order to get data synced from a tracker.
It is like you say: I too wish Signal would allow for communication over any available medium.
https://community.signalusers.org/t/signal-airdrop/37402
Have you seen Meshtastic (https://meshtastic.org/)? It seems like a similar concept but using dedicated devices and unlicensed ISM frequencies, and it's a proper mesh network (so you can even setup repeaters to provide better coverage for an area). I guess they wouldn't work too well if you're travelling to another country since you'd have to get the right radios for the country but it's a neat idea.
Furthermore, the latest build of Meshtastic mentioned some LAN networking, so nodes that don't have radios can still exchange messages if they're connected by some other means.
That seems just a hop skip and a jump from having a Bluetooth WPAN/WLAN that lets many phones share one or zero Meshtastic radios but still be able to talk to each other...
How was your actual UX with Briar? I tried to get family to use Briar during a flight and it was pretty poor. Messages wouldn't show up and we were worried about disconnecting from personal Bluetooth headphones while keeping using Briar. It worked okay and at one point my partner and I chatted about landing plans when the person next to us was asleep. But we found that just passing the phone around with typing worked just as well. It worked okay for the other family but again, was a pain.
It worked well! Most messages did go through! The caveat- I don't think anyone was also using Bluetooth headphones
500 feet outside was the test i did with a clear sightline- the inside of the plane was not quite as far, but the messages did go through - and we couldn't have passed the phone around when one family member was 5 seats behind me, the next was about 20 rows in front of me
> If the Internet’s down, Briar can sync via Bluetooth, Wi-Fi or memory cards
I'd like to see more "peer to peer" projects take things this seriously.
I've really been trying to get Signal to get some decentralization[0] but unfortunately I pissed off some mods. I do understand their reasoning for staying away from full decentralization, both Moxie and Meredith have made good arguments. But I think this is something where there's a really good middle ground. Where both parties highly benefit.
Users get a lot of added utility, "fun", and not to mention a huge upgrade in privacy and security (under local settings), while Signal gets to reduce a lot of data transfer over the network. There's a lot of use cases for local message and file sharing (see thread) and if the goal is to capture as little data as possible about the users, well let's not capture any network traffic when users are in close proximity, right? It's got to be a lot harder to pick up signals that only are available within a local proximity than signals traveling across the internet. The option of expanding to a mesh network can be implemented later[1] but I don't understand how an idea like this doesn't further the stated goals.
The big problem with things like Briar is that you can't install it after the internet has been turned off AND it is already unpopular. But if an existing app with an existing userbase implements even some meshing then this benefits all those users when an event like that happens. Not to mention there's clear utility in day-to-day life.
[0] https://community.signalusers.org/t/signal-airdrop/37402
[1] I think a mesh network maintains the constraints both Moxie and Meredith have discussed, concerns about ensuring servers are up to data. But then again I'm not sure why that can't be resolved in the same way it is already done where if you let Signal fall too far behind in updates then it will no longer communicate with the servers.
> The big problem with things like Briar is that you can't install it after the internet has been turned off AND it is already unpopular
Sideloading an .apk is supported in all Android versions, right? Even without internet access? Is something more needed to install Briar?
Sure, but this doesn't really scale very well. Distributing those APKs without internet access is pretty hard.
Briar already has this built in via the "Share this app offline" feature. It starts a wifi hotspot from which people can download the apk.
Also Fdroid has support for local distribution and discovery for offline scenarios.
you can distribute it via the same mechanism which distributes your messages
Firechat did meshed WiFi during 2014 Hong Kong protests
https://www.theguardian.com/world/2014/sep/29/firechat-messa...
China went to hard mode to kill the app.
Secure Scuttlebutt can do similarly. A wandering node can ferry messages to another cluster of nodes; it's used by sailboats where someone visits shore to run errands and exchanges messages as they go.
Do you know of any documentation to get SSB bootstrapped? I tried several times, but I hit a wall of not being able to find any active communities, plus there were old-style, technically obsolete communities and new-style communities, and half the available documentation referred to each, so it was impossible to figure out what to do.
Nope, same issue myself.
I find it fascinating to read about, but it seems to have a steep and very slippery social hill to climb before the technical parts of the network do anything.
I'm fairly certain there is not a working implementation of ssb in it's original form anymore.
But yes, it had local wifi sync.
What's the use case? I'm assuming one is trying to send a message to someone far away so it seems like the alternatives wouldn't necessarily help.
Other phones with Briar installed can carry your (encrypted) messages, as in a game of whisper. This works best if enough people between you and the recipient had Briar installed ... but most people don't.
But I see how this feature could be very helpful if a state shuts down internet connectivity or during war or a natural catastrophe. The nifty thing is that the app can be shared from one device to another, so you are not dependent on having the app in advance of an emergency.
Ideally, everyone should have this installed as an insurance :)
> This works best if enough people between you and the recipient had [...] installed ... but most people don't.
Which is why it would be nice if operating systems already included such functionality
This is not true, unless you are all in one big fourm or you have a chain of shared blogs. I think they are woried about metadata privacy or people using this to do a DoS.
> Other phones with Briar installed can carry your (encrypted) messages
Sounds like an excellent target for DoS
DoS by local users on local networks? This is that thing where you solve the cryptography problem with the $5 wrench but only slightly different, right?
Someone not participating in briar or the DoS can use fing (android app) or a signal strength meter (handheld, I have 2, personally) to direction find and triangulate the person sending the traffic. Hence $5 lead pipe.
and by "someone" i mean "any android cellphone"
A bunch of countries turn off the internet at the first sign of protests, hell sometimes they just turn it off to stop "a bunch of college kids from cheating during test week"
Coming to a country near you soon
Right but Bluetooth and local Wi-Fi are very short range so it doesn't actually solve that problem
It does if you consider that everyone can act as a relay.
This is also how apple airtags can be find anywhere there's an iphone users nearby.
> It does if you consider that everyone can act as a relay.
Let's think this through. Imagine civil war breaks out in Australia, and communications infrastructure is destroyed or shut off. I'm in Sydney and want to transmit a message to a friend in Perth.
How exactly is "everyone acts as a relay" going to work? In particular, how is it going to scale when everyone in the country is trying to do the same things?
> This is also how apple airtags can be find anywhere there's an iphone users nearby.
This is incorrect. Airtags (and the Google version) communicate with nearby Internet-connected devices, via Bluetooth and NFC I think. Those nearby Internet-connected devices send the airtag's location to a server.
Nothing about this would work without the Internet.
Yeah, I think current tech assumes a server relay. However imo, and if I were to imagine a solution, in this case I think a message would need a ttl, say 24 hours. In a local mesh/hive everyone would store a copy of the undelivered messages. When people move between hives they would sync these undelivered messages where ttl didn't expire. With perhaps a storage limit of say 1k undelivered messages. Undelivered means a destination user that didn't show in a hive. Wdyt?
> With perhaps a storage limit of say 1k undelivered messages.
If you want this to scale you'd need a scheme to deal with limited cache per device. Something like having each device assign a random priority to each message it has in transit. That way everyone culls a different set when things fill up.
> would need a ttl, say 24 hours
Probably better off scaling priority by age. That way you deliver if at all possible, until it eventually falls out of cache. Some people will be able to dedicate much more storage than others.
> Airtags (and the Google version) communicate with nearby Internet-connected devices, via Bluetooth and NFC I think
Yes, exactly (BLE, UWB, NFC).
First, Airtags only have a coin-cell battery. It is not remotely viable for them to be doing any sort of serious "communicating" because the battery would die in seconds.
Second, making the Airtag effectively a dumb device means you gain the various security and privacy benefits, and means everything needed to make the magic happen can be transmitted in a single BLE/UWB/NFC packet (bringing us back to the battery life aspect already mentioned).
30,000ft view of how it works: https://support.apple.com/en-gb/guide/security/sece994d0126/...
I haven't studied the protocol but that seems like it has some...obvious routing issues.
Airtags have a totally different architecture than what this protocol is describing, I think.
> I haven't studied the protocol but that seems like it has some...obvious routing issues.
Yes indeed. I don't understand how the peer-to-peer relaying can possibly scale without some directed routing algorithm.
If my phone running Briar is literally handing off every as-yet-undelivered message to every other phone running Briar, we're going to pretty quickly become overwhelmed.
It'll have all the routing issues of a Wi-Fi mesh network, except at a vast scale. https://en.wikipedia.org/wiki/Wireless_ad_hoc_network#Briar
It is very much in the bingo cards that internet gets shut off in America as an extension of strong-arm policies.
You mean the substrate of our entire economic engine? I think that's a bit dramatic.
Parent didn't say all the internet at once, it could just be a matter of telling telecoms to block connections within certain geofences when protests start to flare up, Egypt 2011 style.
Could even bring down 4G services while whitelisting POS terminals, keep the Starbuckses up and running.
What, like free trade?
I dunno why you're getting downvoted so much.
This sort of thing seemed unthinkable a decade ago, or even in the first Trump admin, but definitely doesn't now.
Other similarly-inclined regimes like Modi in India have proven the effectiveness of targeted Internet shutdowns.
It's kind of interesting to see P2P coming back! I'm happy to see more P2P projects popping up. When the Snowden leaks came out, there was a brief interest in P2P encrypted messaging. I wonder if the political climate now is bringing interest back.
Back in 2014 (I believe briar started in 2015) I wrote a realtime P2P application platform. Not only could you send encrypted messages between people, but you can also send files, play games, and write and share programs together, all within the application. The use case for mine is different than briar's.
https://firestr.com/
https://github.com/mempko/firestr
P2P is really fun but also important and I'm happy to see interest in P2P apps coming back!
G'day mempko, I remember firestr! Very nice! You might remember around the same time (2013) I started Peergos. We're still working on it!
https://peergos.org
Briar is really interesting from the PoV of its forum and blog features, that try to use the messaging platform as infrastructure to build private services.
There's a lot of discussion about alternatives here so I'm going to drop one more: https://cwtch.im
It has wider range of clients and some unique features, like the ability to run multiple, password protected identities trivially, to appear online selectively.
I just wish one could delete or edit on briar's forums. Without that, I feel like I have to be super careful not to make a mistake, if I want an orderly forum. Also in latest versions the ability to fold forum threads is gone? Makes forums annoying to read. The indentation for a sublevel being sooo thin also doesn't help at all.
Sounds like a cool project, but the name is such a bad idea, despite the cleverness of word choice. An app for a niche use case has it hard enough, doesn’t help that nobody can spell correctly even when reading it.
Oh Cwtch is like Cutch, and like the project says, the word rhymes with "butch".
I guess the current thread and this other ongoing one are duals:
Cwtch – Privacy Preserving Messaging - https://news.ycombinator.com/item?id=43367012 - March 2025 (21 comments)
Why invent wheel when we already have Reticulum network which provides integrity and confidentiality on OSI Layer 2 ? So for every packet. It is not better to build "apps" on top of a secure network? That way even if "app" does accidental bad thing, your private content is not exposed to anyone who listens to your network traffic. By default not by "just use another VPN with exit nodes full of network inspection tools, dns redirection services etc" ?
> Why reinvent the wheel when we already have Reticulum network
Assuming README is among the first files created in a project, here's the date of the first commit for each:
Briar is actually even older than that!
2011: https://sourceforge.net/p/briar/mailman/message/27393146/
Reticulum seems to be by far the most interesting project in this space.
I would invite anybody to explore it for a few hours at least, it is fascinating.
Now the only thing that scare me about it is that it is really a "one man" project [0]. I am not sure why, I do not know if anybody else look or understand what he is doing, but hell it doesn't make me feel confident to rely on it.
- [0] https://github.com/markqvist/Reticulum/graphs/contributors
I built my own p2p software back in 2014 (https://firestr.com) and briar came out in 2015. Reticulum started in 2018.
Timing is the reason.
Briar started in 2011: https://sourceforge.net/p/briar/mailman/message/27393146/
Kind of funny that you think running python on your smartphone is easier than the "reinvented" app. (Also, briar is older and had several audits)
I thought this was sarcasm, but it isn't. Seems like a very weird choice to me to build network infra on top of Python. C/Rust would have been the more obvious choice since you can then bind to that from any language (at least with C).
> Reticulum network
https://reticulum.network/index.html
https://github.com/markqvist/reticulum
you mean how everyone built on top of ipv4 and can't abandon it now, even after 3 decades of it's replacement being available and more secure? Or how everyone uses TLS now, not because it's the best way but because like 'Reticulum' it became the best bloated compromise?
General purpose systems aren't always ideal, they're just ideal to gain mass adaption. For applications who target smaller sets of users and prioritize security guarantees, being able to fix bugs at any 'layer' and not depend on external entities is crucial. How I'd wish they'd even use their own Layer 2/3 stack if it were practical.
As someone familiar with networking and Reticulum, I felt confused by reading this thread. I felt the need to explain Reticulum in the networking stack. So here goes.
You can think of Reticulum as a mix of the internet layer and a message-semantics oriented transport layer. Reticulum is focused on trustless, encrypted data transfer with message-oriented semantics suitable for devices with small MTUs.
In current IP-based stacks these are separated at great compromise. First of all, the internet layer is unencrypted. Any actor listening to internet layer traffic can intercept and track or modify IP packets (and indeed this is used for things like NAT.) Secondly, link layers are disparate and fragmentation is used to make sure that IP packets can run atop the link layer. Most modern networking stacks are (UDP|TCP)/(IPv4|IPv6)/(Ethernet|802.11). Ethernet and 802.11 ("WiFi") frames are large enough to comfortably deliver IP packets with minimal fragmentation.
Applications on the internet often send/receive messages but do this at a level above TCP. TCP fragments data atop IP but has stream-oriented semantics. UDP can be used for message-oriented semantics if used very carefully, but UDP packets are delivered with best-effort and UDP packets are often delivered out-of-order or dropped due to congestion and other reasons. There have been several attempts to add message-oriented semantics onto the net. SCTP is in heavy telecom use but seems to be mostly dead in the consumer space. (I recently ran iperf on a recent Linux kernel build and was able to get 8 Gbps on loopback TCP but only 600 Mbits on loopback SCTP. Unsure if I needed to do something different than what iperf does.)
TLS can be layered atop TCP to add security, but that security is only available at the TLS layer and involves trusting Certificate Authorities. QUIC goes atop UDP but also uses the same CA style trust model of TLS. Both QUIC and TLS+TCP are stream-oriented. QUIC has unreliable datagrams which allow message-oriented semantics but this is unreliable. Moreover, all of these protocols rely on delegated authority. Your ISP will give you an IP address that it will route packets for and often this address lives as long as your ISP connection does and will reset when your connection does. If there's NAT involved on IPv4 then you don't even get end-to-end connectivity with your address. Your ISP also has a block of IPs and there's a huge governance structure involved in deciding which entities have which IPs and announcement protocols which announce IP routing tables. Reticulum doesn't rely on delegated authority or governance as much.
Then the other side of the problem is MTUs. Ethernet and 802.11 frames are large enough that IP and TCP can sit atop them well with minimal fragmentation. Fragmentation adds header overhead. However when you get to links like LoRa or TNCs, your MTUs are much smaller. Running IP on these links may be doable but TCP will probably be flooding the link with mostly fragmentation overheat. Reticulum is designed to work better with low MTUs allowing you to bring in links that are associated usually with much higher latency or lower bandwidth such as LoRa or TNC.
For our wold as-it-is, the current state of TCP/IP works fine. ISPs are built out with this model, the governance remains robust, and we rely on utilities to build out the high-MTU links that our comms infrastructure rely on. But if you find yourself dealing with situations with low-MTU, smaller links or low-trust situations, then Reticulum could be of interest. Ad hoc networks are great deployments for Reticulum, for example. There's a lot of innovation going on in this space. See Yggdrassil for a solution with stable-addressing based on key-derived IPv6 addresses and P2P routing which works well when you don't have low-MTU links.
Thanks, this was a nice read
I just read through the documentation for Reticulum but I'm not sure what the point of it is. It looks like a Tor like network written in Python? As far as I can tell the entire thing runs virtually over TCP.
The manual says something about physical networks (is this intended to replace ethernet?) but it also mentions a current throughput of 40mbps so surely that's not what you're supposed to use it for.
Reticulum supports multiple interfaces to transport data, TCP is just one of them. Other are ethernet, packet radio TNCs (think ham radio), LoRa, stdio/pipes, I2p, etc. More details on some of the supported interfaces http://reticulum.network/manual/interfaces.html
None of the given descriptions have been too clear about what it is, though.
It appears to not be a drop-in solution for communication like Briar, so why make a comparison here in the first place?
Instead, it appears to be physical layer-agnostic (it doesn't care if it's run over internet or HAM-radio) infrastructure to build tools on top of. So,
* Is it an end-to-end encrypted overlay network like corporate VPN/Tailscale/Hamachi?
* Is it an end-to-end encrypted protocol between two or more endpoints like SSH?
* Is it an end-to-end encrypted messaging protocol between two or more users like OTRv3?
The entire documentation returned zero results for "Tor" or "onion" (routing), so what's the improvement over Briar+Tor?
It's on F-Droid. I hadn't realized it supported message-passing over Bluetooth like FireChat! Not just Tor.
Those "journalists" they claim to protect could get into serious trouble for merely using Tor. From there it's a trivial matter of rubber hose cryptanalysis to defeat the rest of the "protection". The danger with such tools is someone without proper training thinks they're a super spy, and then they draw attention of the people who actually understand such things, and can put a bag over their head and deliver them to a black site.
Briar is a nice idea, but last time I used it I couldn't find peers, if memory serves. I tried adding a friend who was interested and we sat and waited for our messages. They never arrived.
In the end, we went back to using DeltaChat.
PGP stopped being the recommendation in 2004 when OTR became a thing with its forward secrecy. I really do not get the charm of repackaging PGP as a messenger, especially when it still has no forward secrecy: https://delta.chat/en/help#pfs
I mean, if you're not using Tor, your IP and thus identity will leak to the server anyway. So you should probably just use Signal that has double ratchet giving you forward secrecy and break-in key recovery.
Today, PGP's safest use-cases are digital signatures and airgapped comms. But, you'd probably do the latter with TFC as it has much better key/pt exfiltration guarantee.
People have thought about how to do forward secrecy with PGP:
https://sequoia-pgp.org/talks/2018-08-moving-forward/moving-...
https://sequoia-pgp.gitlab.io/openpgp-dr/openpgp_dr/index.ht...
https://github.com/stealth/opmsg
https://github.com/autocrypt/autocrypt/issues/444
There's a lot going on in the space. It is more innovative than you're giving it credit for, especially around double ratchet. Not there yet, but there's a good reason why I don't mind: control. Multi client support (DeltaChat desktop, hallelujah) and the fact that email remains federation-first.
My identity definitely leaks to my server because I pay it's bill. Not only that, but most of my contacts run their own email or borrow it from me or someone else. Our data does not leave any EU countries apart from the UK. We have IM that doesn't involve any Americans.
Some might imagine we feel terribly smug about that right now :)
Not immediately apparent to me: does Briar use a double-ratchet these days?
I'm not sure, a quick search of the specs don't mention "ratchet". But it does claim to have forward secrecy so it should be good anyway.
I have tried it and it is very usable, if a little bare-bones. Unfortunately, Bluetooth doesn't work for me, but everything else works fine.
Development seems to have slowed down a little, which is a shame. There is still no good widespread application for peer-to-peer communication.
In terms of functionality, I miss a "one to many" feature. For activism, disaster management, or even just organising a slightly larger group, it would be immensely useful to have a channel that people can subscribe to (but not write to) and that syncs via trusted contacts, without having to manually reblog everything. Forums are also a bit problematic without moderation and when anyone can invite new users.
The idea is great, but the adoption rate is way to low for any P2P thing to actually work (unless with agreed upon meetings).
Meshtastic is a better option, because it uses LoRa (thus requires additional hardware), but with a good location, many kilometers can be covered and mesh networking extends this a lot further. Meshcore is supposedly the next "generation" of meshtastic, but not popular enough over here to actually test it.
this seems interesting and I (very briefly) installed to check it out but never actually used.
I just noticed there is no IOS version? bit strange no?
also no update on their blog since 2023?
would be interested to read whats going on recently, is there another place to look?
They explain the iOS situation here: https://code.briarproject.org/briar/briar/-/wikis/FAQ#will-t...
Is there an iOS alternative?
iOS doesn't allow apps to stay active in the background to listen for messages like Android can. And since Briar very much does not rely on the vendor push services that is a showstopper.
Indeed, this is very much a limitation for all apps on iOS that don't want to rely on centralised services, such as a push notification server other than Apple's.
See also: https://developer.apple.com/forums/thread/685525
I noted that as well.
Honestly given the target audience and the limited dev resources I (as an iOS user) do think focusing on Android is probably the right choice here.
[flagged]
I’m not sure where you’re pulling “backdoored” from, but if Apple markets their devices as private then it seems reasonable that end users expect a private device.
There's probably not a backdoor in the device. At least I haven't seen any news about that. But.
Apple has been an NSA PRISM-partner since 2012: https://en.wikipedia.org/wiki/PRISM#/media/File:Prism_slide_...
Also, apparently they had 100% success rate installing malware on the devices: https://www.forbes.com/sites/erikkain/2013/12/30/the-nsa-rep...
It's been close to 12 years since Snowden. Who knows how the defense has improved. Who knows how the offense has improved.
> if Apple markets their devices as private then it seems reasonable
Not really.
Anyone tried https://getsession.org/ seriously?
- desktop and mobile clients, cross-platform (with an AppImage that installs on old systems)
- end to end encryption
- onion routing, based on the Oxen Service Nodes [0], which also propels Lokinet that allows to anonymously browse the web
- no phone number or email required
- group chats, voice messages, voice and video calls (webRTC), attachments, emojis
https://docs.oxen.io/oxen-docs/about-the-oxen-blockchain/oxe...
https://lokinet.org/
No forward secrecy in 2025.
Lokinet is tiny compared to Tor's 9229 nodes https://nusenu.github.io/OrNetStats/w/misc/all.html
The last time I checked, a lot of the nodes are just run in Hetzner's data centers meaning there's not too many actors. I can't even find that list anymore so if anyone has one, I'd like to update my knowledge.
Not seriously, no. But I was completely amazed by the UX: get the app, create an account by clicking a button: no email/phone nor any other "verification". Back up the seed phrase so as not to lose your account. It just works!
Yes, Session seems nice. For hard-core privacy people, use Ricochet Refresh, other than that, Briar and Session are great.
I once built a version of this that strictly allowed you to add contacts via QR code only.
The idea was simple: you can only exchange keys in person, therefore no central server involvement at all.
Tin Foil Chat is in this variety - mailboxes are tor hidden services identified by their public key.
https://github.com/maqp/tfc
Well not quite :) Wrt what upper post said:
It used to be the case you could only exchange keys in person, but X25519 was introduced in 2016, and it was bumped to X448 in 2019. You can of course still exchange PSKs as it's currently the only post-quantum key exchange it can offer. QR-codes are not used, instead, imported strings are split into small segments that are typed manually. The program then does what it can do, to help the user identify typos.
I did something similar, share contact via QR code, offline, but with a dedicated encryption/decryption device to realize the airgap: www.qryptr.com
The threat model is excellent, except: “The adversary can’t break standard cryptographic primitives”
Let’s assume they can and you can swap in non standard crypto models to frustrate and vex ‘the adversary.’ (Lol: “the adversary”… religious)
More info, the threat model:
>The threat model is excellent, except: “The adversary can’t break standard cryptographic primitives”
>Let’s assume they can
Let's not.
The weak key sizes (<90 bits), broken primitives (SHA-1, MD5, DES), and weak modes of operation (ECB, unauthenticated CBC) are all known.
We know the Grover cuts symmetric key sizes in roughly half, and we know Shor will break classical asymmetric algorithms, so the industry is upping key sizes and moving into hybrid schemes that add post-quantum algorithms.
>non standard crypto models
Here's a thought: Submit your primitive (the rainstorm hash function) into the SHA-4 competition whenever it's due, and win it, or at least become a finalist. Then you don't have to sell it to serious projects as security through obscurity.
Surely you realize Briar is open source so the implementation of your hash function will be available to the attacker, and they can perform cryptanalysis on it to their heart's content? So you can't really get over the fact it needs attention from the professionals.
If you want to be taken seriously, maybe start by improving on attacks over existing algorithms? That distinguishes you from the random cranks who think they've come up with improved schemes.
It seems insufficiently secure to just trust that the people who designed the ciphers you use, and who also are responsible for breaking ciphers at state-level, would tell you if they could break those ciphers. Hahaha :)
Ok so you have no idea who's vetting the algorithms at competitions. It's the other participants. That's going to be you among others. You get to break apart all the competing algorithms that claim to be better than yours. And they get to show you if yours is the weaker one, as they also want to win the competition.
Sure, you can't put fox to guard the henhouse that's how you get stuff like DUAL_EC. But that's not the case in modern competitions. They are open to the public, and academic in nature. Everyone gets to analyze them.
We don't know who you are, what are your credentials, and we don't have any proof of you showing you have what it takes to analyze current standards, let alone create new primitives resistant to cryptanalysis. Until you decide go the long way, you'll find yourself treated as yet another Crown Sterling.
> It's the other participants.
Even better, it's the general public. Anyone who wants to can publish an analysis at any time, even after the competition ends. If someone published a practical attack against SHA-3 tomorrow the recommended standards would change overnight.
I love your enthusiasm for this, have a good weekend!
"The adversary" is standard terminology in analyzing cryptographic security.
It would be interesting to figure out who introduced it. I looked briefly on Google Scholar, and I see it's used in the modern sense as early as Yao (1982), but it might have been used much earlier. It doesn't appear in the Diffie-Hellman (1976) or RSA (1977) papers.
"Adversary" is simply a standard English word. It is neither religious or jargon. My assumption is that the reason it is often used in cryptography papers is because "attacker" rings a bit harshly when you repeat it over and over again.
Attacker rings harsh, and very limp. "The Adversary" is a common occult, religious and Biblical term for the Devil, Satan. The Hebrew word Satan means "the adversary". That's why it's funny and appropriate, lol!
brief bibliography - https://web.archive.org/web/20250316045952/https://pastebin....
Well either way it's an appropriate name, lol!
"Can I use the same account with several devices?"[1]
[1]: https://code.briarproject.org/briar/briar/-/wikis/FAQ#can-i-...
SimpleX has the same limitation. I hate how all those apps with modern networking or modern crypto can't get those important usability things right.
Briar runs a Tor Onion Service on your device. I'm unsure how well Tor supports having multiple devices acting as the server. One option could be to have a main program that's always on, to which your messages are received, and other clients can then use the Onion Service to fetch a copy of the conversation. It would add another link in the chain and increase latency so I'm not surprised if that's not being done.
Briar offers a companion ”mailbox” app for the exact reason you describe (i assume)
where did you read that it hosts an onion service? i guessed that's how it worked but couldn't find anything in their docs that said so.
Identity is tied to the physical Bluetooth MAC if I recall correctly.
The BT MAC is shared with peers so they can find you (as well as a list of your IP addresses) but I don't think identity is tied to it. Identity seems entirely tied to a public certificate. But I could be wrong.
can't that be spoofed/overwritten?
I spent a little time ~2012 trying to think how to create a system like this that would work with iPhones at burning man. Never really got anywhere with the idea, but I’m excited to try this!
Related:
Confronting Briar with Disasters - https://news.ycombinator.com/item?id=39174518 - Jan 2024 (2 comments)
Briar Mailbox released to improve connectivity - https://news.ycombinator.com/item?id=36541798 - June 2023 (11 comments)
Indian government bans 14 messenger apps including Element, Briar and Threema - https://news.ycombinator.com/item?id=35769203 - May 2023 (78 comments)
Briar: Peer-to-Peer Encrypted Messaging - https://news.ycombinator.com/item?id=33686094 - Nov 2022 (141 comments)
Briar Project – Secure messaging, everywhere - https://news.ycombinator.com/item?id=33412171 - Oct 2022 (7 comments)
Briar has been removed from Google Play - https://news.ycombinator.com/item?id=30498924 - Feb 2022 (85 comments)
Briar Desktop for Linux - https://news.ycombinator.com/item?id=30023169 - Jan 2022 (84 comments)
Briar 1.4 – Offline sharing, message transfer via SD cards and USB sticks - https://news.ycombinator.com/item?id=29227754 - Nov 2021 (110 comments)
Briar Project - https://news.ycombinator.com/item?id=24031885 - Aug 2020 (185 comments)
Briar and Bramble: A Vision for Decentralized Infrastructure - https://news.ycombinator.com/item?id=18027949 - Sept 2018 (11 comments)
Briar Project - https://news.ycombinator.com/item?id=17888920 - Aug 2018 (10 comments)
Darknet Messenger Briar Releases Beta, Passes Security Audit - https://news.ycombinator.com/item?id=14825019 - July 2017 (85 comments)
Is Briar really the next step of the crypto messenger evolution? - https://news.ycombinator.com/item?id=11690607 - May 2016 (1 comment)
The main rason for me to like vriar over other stuff is its insane privscy focus, and the bluetooth relay stuff for fully offlibe communication
Are the typos on purpose for opsec reasons?
Does this still require signup to their server before using p2p app ? Meaning it cant be shared offline and used ?
As per their website, the account is local to the phone.
It just cannot be backed up, unfortunately.
love briar!!! please add p2p discovery / pairing without qr-code
Logo reminds me of the old slack logo
Even now, when I see Briar's name anywhere, I think of this as "ah, that Android only app" and that imho is saying something for a privacy messaging app. I am not saying it has not reason (Apple's unsound, unfair, and consumer hostile tight control is the reason! [1]) to be Android only, I am just saying - it's very unfortunate and unfortunately defeating.
[1] In the name of privacy theatre which they have actually been able to defend by spending both on PR and lawyers.
The simple fact that you generally need to have Apple hardware to make iOS apps is a reason enough
Looks like a lot of it is JVM based, which makes it hard for iOS since they disallow running JITs.
iOS vs Android is a bit like ChromeOS vs Windows/MacOS/most Linux distros.
There are benefits to more restrictive operating systems. For example, iOS not allowing apps to run in the background essentially stops any apps with malware from doing stuff in the background, but it also stops apps like Briar, Syncthing, etc, from working well.
I assume Android isn't a problem for most Briar's users. They're likely running a deGoogled Android version (GrapheneOS, LineageOS, etc) and downloading/updating the app via F-Droid or something like that. They don't rely on Google (or Apple) to run anything.
The problem is the networking effect. Since so many people use iOS, even Android users often have to contact people on iOS devices, resulting in Briar likely remaining very niche.
Very few people in my country use iOS devices. Maybe 5%.
Yup, from what I hear, the problem is Apple doesn't allow process forking which means Tor would have to run inside the same process as the messaging app which is ridiculous.
I always think "Ah, that one E2EE chat app that made a cameo on Mr. Robot"
Briar was funded by the CIA. Partly.
If this is about OTF, do you also distrust Let's Encrypt, Quad9, Tails, F-Droid, Signal, and Tor?
Yeah Signal is fucking rotten. You think its just allowed to exist in the USA? come on man!
Source?
I haven't heard this particular rumor, not like they have In-Q-Tel connections a la Wickr, but they do take funding from the Open Technology Fund [0] which some of the more righteously paranoid take issue with, being US State Department and all. Same parent as Radio Free Asia, Radio Free Europe, Voice of America [1].
[0] https://briarproject.org/news/2018-1.0-released-new-funding/
[1] https://en.m.wikipedia.org/wiki/U.S._Agency_for_Global_Media
Do we have any reasons for concern?
The source code is available here: https://code.briarproject.org/briar/briar/tree/master
Serious question for whoever actually understands this: what is the legal status of true, peer-to-peer, attack-resistant encrypted messaging in the "western" world? I'm particularly interested in the USA, the UK, Australia, New Zealand, and whatever European countries you care to throw into the mix.
I've occasionally tinkered with building software (but never released said software) that uses encrypted peer-to-peer connections as the _sole_ way of communicating, because it seemed like the most natural way to build said software _and_ the most interesting technically. (And I have zero interest in hosting servers for FOSS side projects.) If I were to actually release one of these projects and it were to become popular, should I expect to be shut down by law enforcement on the grounds that it's already unambiguously illegal? Or would I likely receive a "Technical Assistance Notice" at some point, effectively requiring me to sneak a back door into the software? Or is it actually fine?
I seem to recall all sorts of stories about law enforcement and "TLA agencies" pressuring vendors of secure messaging software to make the software unavailable or to add back doors, including at least one who chose to shut down their business rather than lying to their users about the security of the product. But somehow in all this I failed to glean whether or not it's actually meant to be legal, even on paper.
I know of no law here in Germany that would make it illegal, heck, Germany allows me to sign my PGP Key with my National ID. There has been some conservative resistance over the years but it's still legal and in practice for the normal user simply not an issue. Unless you are using things like Anom or other messengers that are like exlusively used by criminals and even it's not illegal in itself you might at worst get caught up in a sting operation when they take down the central servers.
Fun fact most Tor exit nodes are in Germany. Hosting those is more risky.
I heard tutanota collaborates with German law enforcement for decryption.
Heard from where? How would they do that? Tutanota doesn’t have the key, the end user does. I keep hearing weird things about Turanota that sound like the types of rumors intelligences agencies who really don’t want people to use the service would start.
Encryption for end users is de facto legal almost everywhere except for UK. For vendors it's illegal almost everywhere maybe except for USA, but that's just how the law works in USA: you receive a subpoena, then it's up to your luck.
It's not illegal for vendors, they just have to colaborare with law enforcement when a subpoena is received, and this collaboration can entail attacking their own users as long as a technical capability to do so exists.
If you think about it, it's more or less the only way this could work in any democratic society.
Not illegal in Finland at least.
Oh and proton mail brags that Swiss allows it too.
Mullvad is Swedish and they run no logs VPN so not illegal there
Curious as to whether Mullvad will respond the same way Signal did to Sweden's assault on E2EE.
https://www.theregister.com/2025/02/26/signal_will_withdraw_...
> Encryption for end users is de facto legal almost everywhere except for UK.
Encryption is legal in the UK.
But if the government turns up asking for your decryption keys, "you can't have them" is not an option unless you wish to enjoy the luxurious surrounds of a prison cell until you change your mind.
Which, to be fair, is basically the case worldwide, as per the famous XKCD cartoon[1].
[1] https://xkcd.com/538/
That’s a huge simplification.
If you don’t have they keys, you can’t hand them over, for one thing.
Also, the wrench treatment is extremely unlikely in most democracies. Now, deplatforming such as seizure of DNS names and such, is another matter and varies, often orthogonally to the risk of wrench treatment.
> the wrench treatment is extremely unlikely in most democracies
If you prefer ... substitute "wrench treatment" for the democratic wording: "jail time and the associated criminal prosecution process"
Where has this happened? For using encryption? Or what are we talking about here?
> what are we talking about here?
We're talking about "if the government turns up asking for your decryption keys, ...".
> Where has this happened?
Pretty much everywhere. Even in the US you can only avoid it if you're careful; if you admit to knowing the keys then you can't. Either way you're dealing with the "criminal prosecution process" as GP pointed out.
There's deniable encryption to counter the wrench attack
> There's deniable encryption to counter the wrench attack
The trouble with deniable encryption is its viable use-case is very narrow.
It is, for example, not viable to use deniable encryption when exchanging messages with others.
If the authorities, through whatever means, get the a copy of an encrypted message you sent, and they have done sufficient metadata homework to link it back to you, find your address and come knock on your door, then you are going to seriously struggle with a deniable encryption defence.
I would look into wassenar if I were you, an artifact of the cold war, encryption can be treated like a munition. Nothing stricter than that from what I’ve seen. Yet.
end-to-end encrypted messagess, when the end-points (Android, iOS, Windows, etc) are basically spyware?
On top of that it runs through servers running who knows what, closed source stuff. So who knows if they're somehow decrypting everything on there before forwarding re-encrypted stuff?
fair point, when someone's using google push notification service and gboard, that's both ends of the pipe, for the most part
In the Five-eyes jurisdiction, it is legally allowed to use strong end-to-end encryption. Any potential laws that are contrary to that would come up against some serious 4th amendment issues. The idea of cryptography as a munitions was largely set aside in the name of capitalism.
Tor was funded by the U.S. Department of State. Signal and WhatsApp are end to end encrypted.
Sign up for EFF's mailing list and donate money to them. Check out their Secure Messaging Scorecard: https://www.eff.org/pages/secure-messaging-scorecard
We, as a society, are under constant attacks on our ability to maintain our privacy. As we've seen in large political and technological shifts, it only becomes more important to maintain your privacy. Deep fakes used in scamming relatives is one good example.
Please do release your software and ideas that make information more secure.
[dead]
[flagged]
Well, it's kind of the same thing with P2P money exchanges.
Legitimately you may need to exchange crypto into fiat, since there's no "regular" exchange that does that.
The trick is that for it to escape regulation just have to do it in a way looks like money-laundery.
Legit use cases that (unfortunately) also enable criminals.