If you and your group chat friends can meet up in person once to input an agreed upon a ~1Gb one-time-pad then you can exchange uncrackable text messages for years on any insecure channel I’ve long felt that this is the ideal solution for anything super super secret

Everyone in that group also has to manage to keep that 1 GB secret.

I mean if a Roman general could…

1 GB?

The size is fairly irrelevant. 1 GB fits on a microSD card many times smaller than a Roman General's hand-written cypher.

True, but it can be copied and returned quickly without the victim knowing, and you have to trust every device you put that SD card into to read the pad.

How do you handle that SD card in practice to do your communication?

My point is, if anyone is on to you and can physically get to you (or anyone else in the group), there is a high risk they can get hold of the data.

That's why you put it behind a secret menu in an iPod https://tidbits.com/2020/08/17/the-case-of-the-top-secret-ip...

also how do you ensure the messages haven't been corrupted in transit

You can never ensure that your communication channel isn’t corrupted. But with a one time pad you’ll just receive unreadable garbage then. You‘re also free to sign or checksum messages before encryption.

if an adversary xors their guess of part of your message and what they want it to say with the one-time-pad ciphertext, they can make it say what they want if the guess is right; this is a general vulnerability with stream ciphers

if they guess wrong, there's a little unreadable garbage in the message, but in many scenarios they only have to guess right once

so you need some kind of message authenticator like hmac

Good point I guess that’s the same as the “heil h**er” vulnerability

Maybe some kind of low density salting would make messages hard to guess but not too hard to read

1. For each letter of the plaintext, concatenate "dontcorruptmebro"

2. Grab 17 letters from the pad (I'm assuming pad means the randomly chosen letters that make up the 1 gigabyte of shared secret among the participants)

3. Convert the first letter of the pad to a number (let's say 1-26)

4. Right-shift the message by that amount and let the letters wrap around: e.g., if the plaintext letter is g and we're shifting by 1 the plaintext becomes "ogdontcorruptmebr"

5. Encrypt with pad (not a cryptographer, but I'm assuming this means adding a character of the shared secret with a character of the plaintext, and wrapping around if it goes past the end)

6. Send

7. Decrypt with pad

8. Left-shift and wrap by $first_pad_letter_value (i.e., the same value we used to right-shift and wrap above)

9. Remove the "dontcorruptmebro" part to concatenate the plaintext letters to reveal the original message

10. Rinse and repeat, and do whatever secure messengers do if/when you receive a part of the "dontcorruptmebro" that isn't "dontcorruptmebro"

I only thought about this for a few minutes, and I'm not a cryptographer. So I'm honestly asking-- did I solve the corruption-in-transit problem without screwing up anything?

Edit: just to be clear-- I'm not trying to be efficient, or to authenticate, or do anything whatsoever other than a dead simple thing that can be implemented easily.

Edit 2: clarification

not sure; i think this just means the attacker has to guess one letter of the pad in addition to the crib, so (with your example alphabet) they need 26× as many tries to get a corrupted message through

That actually makes a lot of sense. Matrix should add it as a feature.

There's too many practical drawbacks. For example you have to send the OTP without getting it intercepted. How do you do that? It also has to be truly random. You can't pick a page from a book or anything, that undermines the whole model and makes cryptanalysis possible.

It's useful but only in very specific cases. Mostly it's just a paradigm in cryptography.

Note that for all its fame as unbreakable it does lack perfect forward secrecy so anyone getting a hold of it from any of the participants can read their intercepts from all the way back.

Sitting in a cafe almost an entire week later: oh, but it does have perfect forward secrecy, as long as you discard the beginning of the pad as soon as you use it (which is actually strictly better than passing a temporary key over a potentially decryptable channel, and then discarding it after session ends). If I correctly understand what perfect forward secrecy is.

> Telegram accounts of opposition were hacked by belarus police as well. It's known and documented.

No, not really _hacked_. You give your phone unlocked to the police, and they access your Telegram account. You can't refuse, and you probably can imagine why.

Actually really hacked. What you said also happens of course, but hacks are routine as well. Happened to 2 people I know personally. They do it by intercepting the sms code at the cell operator level.

I do not use Telegram: what SMS code?

The default authentication method is 5-digit login code received via SMS. You can enable 2FA with password being the second method, but you have to know how to do it. Worse there are 2 things called "password" there: the "cloud password" which is the 2FA password and the "password code" (that's what it's called in Russian, maybe the English interface uses a better name) which is merely a pin code for locking the Telegram app on your device. So some less tech-savvy people after hearing they need to set up a password set the latter and falsely assume they are now safe.

Only if you have one device: once you have authenticated on two devices the code is sent over Telegram to other devices you have. In that case there is no option to fall back to SMS when authenticating. I think if you lose all your devices then you're locked out, unless you have a recovery email set up.

In addition, if login succeeds, an authentication warning that a new device has connected is sent to every other device, and contrary to other Telegram chat messages cannot be deleted from another device, even previously authenticated ones. The message does not show up on the new device anyway, and it has to be deleted manually, once per other device. So an attacker that would gain access cannot hide its tracks unless it has access to all Telegram-known devices simultaneously.

> In that case there is no option to fall back to SMS when authenticating.

That's not true. The option is there. (Edit: at least for now, some changes in that area are upcoming)

> In that case there is no option to fall back to SMS when authenticating.

The attack usually happens at night. By the time you wake up, all your chat histories are already downloaded and the secret police is on its way.

> That's not true. The option is there.

I tried it before I wrote the comment to be 100% sure, the option was not there, and it still is not.

I am not sure why it is the case but I am quite sure it was the case way before as I was making sure of this back then.

the Two Factor auth to validate is really you after guessing/knowing your pass from a previous leak

It's worse. 2FA is optional and SMS code is the first (and default) auth method.

> It's worse. 2FA is optional and SMS code is the first (and default) auth method.

This will be changed on Saturday.

Got the following message about API changes last week: https://telegra.ph/Telegram-API-Changes-02-16

That announcement seems to be concerned with unofficial clients only. But it does sound like the change is a part of some bigger package.

But given the choice, isn't SMS a stronger first authentication factor? It's temporary and randomized, whereas users don't change passwords that frequently. So a password is much more susceptible to keyloggers/malware/brute-force than an SMS code.

I actually wrote to Telegram’s support team to get more info about this, and it seems the article has a lot of errors. The support rep linked me to this, https://telegra.ph/Wired-Errors which is Telegram’s response to all of it.

> as no app can defend against direct access to a device.

Of course you can't protect the local data from all the possible attacks but there are many ways to prevent some attacks and complicate others. So this article isn't honest.

I kinda don't understand why people trust telegram. Regular messages aren't even encrypted. SMS authentication. Contact harvesting. Mandatory background run permissions (the app would constantly complain if it can't run its background tasks). Then some strange people selling users' metadata. One time I've purchased my location history for ~30 euros in TRX and it was accurate.

> No, not really _hacked_.

I see a number of comments similar to yours on HN, and I am legitimately curious and do not mean to offend: Why did you think Belarusian police do not hack phones? Was your comment based on any source or personal experience, or did it feel right?

I ask because I have observed a number of times where HN comments are wrong on things (on have personal or professional experience in) but get upvoted because the comments look reasonable, but the correct comment gets downvoted.

It's an interesting failure mode of HN discussions. I thought I'd ask you because the topic is not contentious, and hopefully this comment does not cone across as underhanded.

Because to beat up someone and order them to unlock their phone is faster, does not require trained staff, can be done anywhere and is fun for the cops.

In some cases they use israeli hardware (forgot the name of the company), if you are fooled into giving your phone away for some period of time, like entering a police building, where they have a "no-phone zone" for visitors.

Obligatory XKCD: https://xkcd.com/538/

Cellebrite and GrayKey are prominent providers of cellular DFIR hardware used by government agencies.

> Because to beat up someone and order them to unlock their phone is faster, does not require trained staff, can be done anywhere and is fun for the cops.

The implicit assumption is that the states always go for the faster solution. I'd argue that intercepting an SMS/call is easier/faster for nation-states, than arrest and torture; most carriers worldwide have interception capabilities mandated by law: using the secret police to subvert those capabilities is not rocket science - especially when coordinating with hacking-as-a-service companies like "Team Jorge".

What really grinds my gears, when someone confidently state their thought experiment/"derivation from (idealized) first principles" as a rebuttal to empirical evidence. Incidentally, the wording is sometimes absolute, which cloaks the speculative (and wrong) nature of such comments ("No, not really hacked." Implying hacking doesn't happen, and yet it does).

I've seen such 'truthy' but wrong comments voted to the top on HN, because the up-voters share the same blindspot and think "Yeah, that sounds right"

> The implicit assumption is that the states always go for the faster solution.

That’s what cops in Belarus did to me twice since 2020 when I declined to unlock my phone. That’s what they did to many of my friends and colleagues. Hacking happens but it is a more of an exception as it requires planning and effort, which is hard. Blackmail and threats are much easier.

Just because B happened to you personally doesn't mean A never happens to anyone.

When a person says "A happens", and another responds by saying "A doesn't really happen - rather B happens", their assertion is insufficient to refute the existence of A, whether based on a cost analysis thought experiment or personal experience with B. It is far more accurate for the second person to make an addition rather than a refutation by saying "B also happens more frequently than A"

Really cool

> My takeaway is that for truly private chat one should write his own software

That's the only way to make sure you're using software you trust, but rolling your own crypto implementations is often not so secure (because of the many pitfalls).

You don't have to roll your own crypto. You can e.g. just use libsodium which is designed to be easy-to-use and not possible to use incorrectly.

Using libsodium is good advice, but all crypto libraries can be used incorrectly.

I'd have no idea where to start securing an app against side channel hacks.

Is the memory encrypted? Should it be? Can other apps access it?

E2E might be working fine, its the ends I'd be concerned about.

Narcs did this and alas the FBI ended up turning the guy who wrote their software to turn on them all.. so hard for a criminal mastermind to also be a good programmer I think

you could run your own xmpp or matrix instances.

telegram isn't e2e encrypted (unless you use secret chats which nobody does (and those do not support more than 2 participants))

Not only that but they've made suspicious ties with the Kremlin that resulted in it being unblocked in Russia and have a mysterious source of funding after TON collapsed.

I'd love to hear more about this.

I thought Pavel Durov (founder) isn't really welcome in Russia. He seems to have a left a lot of money on the table with his previous company (VK) to get out of there.

The interpretation of events with telegram I've always heard has been that Russia tried to block telegram but doing so blocked most of the rest of useful services as telegram was hosted on e.g. AWS. This meant that real work was slowed. In the end, they gave up because continuing the block would mean crippling their access to the internet.

I have found it weird that pro-putin russians still use telegram. But it seems like a lack of discipline which is quite the plague of russian military.

I'd genuinely love to get good information on this as I use telegram as it is a great piece of technology and wouldn't if it were collaborating with russian government. I think a lot of rumors do not distinguish between russian people and russian government. And that's pretty damaging.

as a counter point, here's telegram's answer to this article https://telegra.ph/Wired-Errors

While very long, it doesn't look like that article provides anything but speculation. What would you say is the key point? Where's the meat?

I know that it would be hard to get good evidence here but I still think the burden of proof lies on the more extreme claim. Which to me is that a company founded by someone fleeing oppression would work directly with the oppressor.

The example of messages appearing as 'read' does not imply to me that telegram is working with them - rather that the her app was compromised by other means. Otherwise, why create such a flaw in your monitoring?

Meduza - news organization criminally charged in russia operating in latvia - is mostly accessed in russia via telegram. It's hard but not impossible to imagine that the russian government would allow it to remain uncensored.

The agreement with the Russian Government over "Terrorism" cases is not just speculation, but announced by both parties.

That would be damning if I could find a statement by telegram about how they are working with the russian government to deal with 'terrorism'.

I'm seeing quoted statements by the russian government in the article that I cannot verify elsewhere but I'm unable to see telegram making a statement from their side of working with the russian government.

I'm truly interested in getting to the bottom of this. This wired piece doesn't inspire a lot of confidence in it's trustworthiness but I'm unable to find something with more concrete sources or at least a better reputation.

Interesting. Where can we read more?

Can you read russian or translate it via google translate?

https://medium.com/@anton.rozenberg/friendship-betrayal-clai...

while the whole store is about on how Durov tried to sleep with authors wife and tried to put pressure on him using his work position, author did expose facts which very interesting:

- telegram office in sankt petersburg sharing same office that mail ru does (and mail ru basically is pro government org)

- telegram team still contributes to vkotankte and they do share some software components connect to online messaging

- most interesting russian oligarchs has very big influence on the products (vkontakte and telegram). While both productions trying to tell its not true, behind the doors they do have well established process of giving data when certain criterias are met

Curious how good chatGPT is at translation. Tried it on Russian?

Have you tried?

Not yet but will next time I login.

I wouldn't say nobody. My parents, SO, and some of my friends all use the encrypted chats. It would be nice if the client made the differences more clear though. Although if it is a honeypot, then they obviously wouldn't want to advertise the workaround.

Is there a e2e chat program that actually supports encrypted chats with more than 2 people?

We've used telegram e2e but its frustrating since you can't see those chats on desktop at all. (for obvious reasons)

Yes, WhatsApp and Signal. Both use the Signal Protocol.

I say again: Jitsi Meet (Open source, self-hosted) has voice/video E2EE (it has text, but is not yet encrypted).

No login. No password. No app. All WebRTC. Chrome required since Firefox does not yet seem to support encryption over WebRTC (I think).

I set it up from scratch with Debian Linux and Virtualbox in about 30 minutes here: https://www.youtube.com/watch?v=4rlffwHUchk

Before doing anything related to security, you should always understand what your threat profile is. If you don't have a real probability that a state actor will go after you, most likely your threat model will include scams and criminals. And unless you're a wealthy individuals, most of these scams will be automated, not hand-tailored.

Look into Briar

I don't think anyone can whatsapp chat. Somehow, whats app is the most reliable end-to-end encrypted messaging service today and many just don't know.

WhatsApp is closed source. For what it's worth, the protocol itself might be impenetrable, but the client itself has access to your decrypted messages and can still decide to send them back to Facebook without your knowledge.

The system that depends on a good will and "trust me bro" is not secure by default, even if Meta/Facebook were the most trustworthy company in the world under the most honest legislation.

Open vs. closed source is a completely moot point in the context of iOS and Android if your threat model includes vendor/supply chain attacks.

If you have reproducible builds and you can verify the digest of the app on your phone, difference is like night and day in open-source vs. closed-source projects.

But you can’t have reproducible builds at least in the App Store.

Apple can implement to show pre-encrypt hash if they want. I cannot see anything negative impact for them if we just give some pressure.

Oh, don't get me wrong, I think it would be phenomenal if Apple were to allow reproducible builds on the App Store!

But given both the existing encryption as you mention, and Bitcode (mandatory for at least the Apple Watch for now), I think it's unfortunately pretty unlikely to happen.

Software can be reverse engineered even if it doesn't have source available (and WhatsApp has been extensively reverse engineered). Similarly, software might be impractical to audit even if it does have source available.

> Signal might be safe, but I think it's a honeypot.

Telegram smells a lot more like a honeypot than Signal

Both could be, just from different queen bees

Moxie Marlinspike is a lot of things but I'm pretty confident the queen bee of a honeypot is not one of them.

Confused by this; Moxie did eventually concede and provide a signed APK.

Drew DeVault took the time to write it up: https://drewdevault.com/2018/08/08/Signal.html

> Truly secure systems don’t require trust.

This blatant absolutist statement is completely false. It exactly means, that there is no computer which is secure today. It also means, that it’s pointless to care about security on any phone in existence, because it cannot be achieved that currently.

Yeah moxie is diametrically opposed to me. This is why I don't promote signal and only use it through matrix for those two people who don't use anything else. Which is also in contravention to his highness' wishes because he hates third party clients.

Moxie believes in security above everything even if it takes choices away from the user and forces you to trust a third party (in this case him, but also the mobile vendor and Google because he doesn't trust custom firmware either). Basically what he calls the mobile security model. And the reason I hate mobile devices with their closed model and attestation crap to make sure I play by the vendor's rules.

I believe a user should always have the final say in everything. If the user makes it insecure that's their business. Basically the desktop security model. And the reason I don't like working on mobile devices if I can avoid it.

I'm as principalled as he (and other people like him) is so I wouldn't even enter an argument, there's no point.

Haha I'm sorry but a name like Moxie Marlinspike seems designed by professionals to tickle the so quirky so he must be safe button in the nerd community.

Despite the "trustless" credo that gets passed around in cryptography, it's actually often very important to know the people that work in this space and I invite you to read more about this particular person, his background and roots and make a determination as to his intentions in this space and the level of trust you are willing to put in his work (and/or the stuff he previously worked on) and not just make a base judgement on his name alone. FWIW, I've been familiar with his work since before I even used or cared about cryptography.

Signal is funded by the US State Department[1]. I'm sure you can trust it to send messages to your drug dealer, your mistress, or the competitor you are selling you company's secrets to. I wouldn't trust it if I wanted to keep secrets from american 3 letter agencies, though.

[1] https://www.mintpressnews.com/the-open-technology-fund-makes...

DARPA was going to contribute money to the OpenBSD project (which also maintains OpenSSH) before Theo said some things critical of the Iraq war and they retracted it. I wonder how many people would have accused them of being CIA plants if they took the grant money. Regardless, there are many competing interests and bureaucracies in the US government and it's not a safe assumption that they are in cahoots with each other on encryption they can break on demand. It's usually a more complicated picture than just "the government". Some of this funding is likely with the well meaning intention and goal of strengthening the security and privacy of communication between Americans.

Also see the history of "window" (chaff) in World War II. R&D people for both the Allies and the Germans realised, as improvements of the new "radar" continued, that radar doesn't see a difference between an aeroplane and a suitably sized radio-reflecting object, say a strip of foil. So, if you chuck a bunch of these foil strips out of a plane, now the enemy radar is full of "planes" that don't really exist.

Both sides stalled deployment of this trivial yet effective countermeasure because they believed once they used it their opponents would immediately understand how it was done ("Gee, immediately after the German bombers did that trick which messed up our radar we found loads of metal strips in trees all over the area they attacked...") and so copy it - and both had "official" estimates made which said their opponents would surely benefit more than they would once it came into use.

Moxie Marlinspike - and Whisper Systems - have assumed a variety of concerning positions over the years. Concerning, because their flaws are obvious, yet Moxie - a very smart guy - pretends not to notice them.

For example, Moxie defended discontinuing encrypted SMS on the grounds that it leaked metadata to telcos - yet failed to emphasize that this was merely the same metadata leaked to Whisper Systems, or justify why we should trust Whisper Systems more. "Just trust us" policies are worrying.

Moxie's defense of failing to provide any alternative to downloading Signal/TextSecure from Google Play also contained a number of very eye raising frank admissions, including that Whisper Systems was motivated by the ability to silently push updates and monitor its users (there's that "just trust us" again). Followed by the very weird assertion that "Avoiding Play alone is not a privacy win", which is a bit like saying there's no point wearing a seatbelt because you might get injured in other ways.

Whisper Systems is notoriously hostile to any use of Signal that doesn't involve their official client, going through servers they administrate (servers which run code they release infrequently if at all). Signal has made no attempt to bootstrap a federated system, even though this would save them money. They are extremely keen to maintain ironclad control over both the app and the server, and are willing to take unusual security postures in service of this.

I've read enough stuff from Moxie that makes me say "what, that doesn't make sense" to make me very suspicious.

The SMS support that was discontinued was for plain SMS to/from other plain SMS numbers from within the Signal app - it was not encrypted.

Nope: https://signal.org/blog/goodbye-encrypted-sms/

Ah, right. I thought OP was referring to https://www.signal.org/blog/sms-removal-android/ , my bad.

I'm not necessarily agreeing with his positions you mentioned, except to note that his focus on Signal was making an encrypted messenger that was easy enough to use that normal people would actually use it, which is a different goal than being the most secure possible and that does inevitably involve compromises and tradeoffs. He has written extensively on the problems with decentralized systems and the added complexity that makes people not adopt them, and as someone that's done extensive work in the dweb space, his arguments are quite sound and not suspicious to me in the slightest. https://moxie.org/2022/01/07/web3-first-impressions.html

If someone wants to send encrypted messages in a decentralized way I suppose they can use PGP with Tor (a project that has also received US government funding btw) on top of a P2P network or something similarly strange, but good luck getting the non ultra tech literate friends to use any of it. They will just resort to going back to SMS because they can't figure it out, or because it's slow and doesn't work, or because a malicious actor figures out how to blast the entire network with spam messages, and then we're right back to the original problem with no improvements.

As a thought experiment here to make this conversation more constructive, what is the actually most secure way to send messages between two parties, and how many of the non tech friends has someone convinced to actually use it?

Even assuming Moxie is beyound doubt, that won't help much today, as he resigned as Signals CEO.

"https://www.bbc.com/news/technology-59937614"

(He is still part of Signals board, though).

If you use group chats or unencrypted individual chats, then it's absolutely not secure. I don't use those for the security though. It's just a really nice messenger that's not Messenger. But it does also have E2E encrypted chats, and that's what you should use if you're trying to keep your conversation secret. Unfortunately many people aren't aware of that, and just assume Telegram is secure by default.

Even Telegram's encrypted chats have not had nearly enough analysis to be trusted. They used to use some bad home-grown techniques, now it's just "probably secure enough".

Their client code also isn't really open source, even though they claim it is. While Signal has reproducible builds.

Huh? Their client code isn't just fully open-source, it also has reproducible builds both on Android and iOS, has been for a while. Doesn't Signal only have them on Android? It's a great app either way but if RBs matter, that's a little knock against it.

Where did you get that idea from?

Their client code is not usable because they don't provide working instructions for compiling it. If you can't compile it, they can't have reproducible builds.

For example, see this issue from 2019 which the developers still haven't replied to:

https://github.com/TelegramMessenger/Telegram-iOS/issues/97

There are a lot more issues about people not being able to use the code, none of which get any replies from the owners.

From their official announcement of reproducible builds. And this seems to be the instructions: https://core.telegram.org/reproducible-builds

GitHub builds directly from their source code just fine: https://github.com/TelegramMessenger/Telegram-iOS/actions/ru...

(uses this script: https://github.com/TelegramMessenger/Telegram-iOS/blob/maste...)

And here are few recent examples of them helping people to solve build issues: https://github.com/TelegramMessenger/Telegram-iOS/issues/968... https://github.com/TelegramMessenger/Telegram-iOS/issues/986... https://github.com/TelegramMessenger/Telegram-iOS/issues/992...

How were you digging to find an irrelevant issue yet omitted all of this? I really don't see the picture you're trying to paint.

It certainly is usable. I'd used Telegram FOSS from F-Droid for quite long before switching to Nekogram (also on F-Droid), a third-party Telegram client with some extra features.

Incidentally, Signal is still not available on F-Droid, and Signal developers are known to be hostile towards third-party clients (for "security reasons." Almost like I've heard that argument before from a certain smartphone manufacturer...)

Yep, I also use Nekogram. I like how open the client aspect is of Telegram.

> My takeaway is that for truly private chat one should write his own software using simple crypto without all those fancy clients.

That‘s actually pretty secure in practice, because you won‘t be communicating with anybody.

> Ideally just use one time keys and xor everything.

How do you generate the keys? How do you share them? And you only care about encryption, authentication does not matter to you at all?

The chance of getting this right as an individual developer, especially given this level of understanding of cryptography, is next to zero.

OTP one time pads are uncrackable if is random enough. Hard part is transporting that decoder to someone.

Textbook one-time pads are trivially malleable. Sometimes non-malleability matters just as much or more than privacy.

("This is POTUS, do$ÿ} launch the nukes!!!")

If you are a developer working for the government and in charge of this, please do not make this mistake. If you are the President of the United States and need to send a message like this, please make it completely unambiguous. Maybe repeat it several times and provide a justification.

I'm fairly confident that the US government, given that it runs the NSA, has access to a textbook or two on applied cryptography and cryptanalysis and does not need to source input on their cryptographic designs from HN :)

> That‘s actually pretty secure in practice, because you won‘t be communicating with anybody.

Nice. In all seriousness though, there has to be a way to make a hand-rolled but secure channel. E.g. use standard crypto libraries, hand-exchange keys or key phrases, etc?

>How do you generate the keys? How do you share them?

https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...

Reasonable choice, but then you're doing something completely different from what GP suggested already:

> Ideally just use one time keys and xor everything.

Good old pgp (in the form of using gnupg to send encrypted emails) is safe. Make sure that you trust the correct keys though.

Non standard solutions are a recipe for disaster.

> Telegram accounts of opposition were hacked by belarus police as well. It's known and documented.

These were cases when cops either were able to access the device, or were able to intercept sms messages. Notice that that did not happen to those belarus related channels whose admins left the country. For example an ongoing issue [1][2] with one of the admins who left the country, but his identity was found out and now cops are using his brother, who was still in the country, as a lever to make him delete the channel.

They can't delete/hack your channel unless you let them.

[1] https://mediazona.by/article/2023/02/15/blackmail

[2] https://mediazona.by/news/2023/01/22/belzd

There’s no need to “hack” anything in Belarus. They simply resort to torture.

https://www.themoscowtimes.com/2022/12/23/critics-slam-16-ye...

They do both. Source: am Belarusian, both things happened to my friends (specifically with respect to Telegram account access).

I’d prefer to be hacked, given a choice.

Did you friends that were hacked had the PIN set for their Telegram accounts? I'm curious whether there is actually a Telegram "hack" or yet another SMS hijacking (via ss7 or by just directly co-opting the telco).

Both hacking victims I personally know didn't have the 2FA password set and were hacked via SMS hijacking. I'm following this pretty closely and so far haven't heard of successful attacks of any other type. One semi-exception is [1], but here the victim's device was captured and most likely used to receive the password reset email.

[1] https://habr.com/ru/post/598939/

Isn't Signal open source? How could it be a honeypot? The community should be able to verify e2e encryption fairly easily.

Bugs and backdoors are indistinguishable. No software is bug-free. App stores make repeatable builds hard to achieve. Another vector to introduce changes. Might just be convenient target to attack via other means (e.g. rogue android update targeted for this special app).

I'm just a bit paranoid recently, I don't have any proofs or something like that. I, personally, would use Signal today as off-the-shelf easy-to-use solution. But for something that's absolutely must not be disclosed I'd use age (write message in text file, encrypt it via age, send base64. Supports symmetric and asymmetric encryption, schemes are simple enough, software is popular enough and super-focused.

"Signal might be safe, but I think it's a honeypot."

Based on what?

Signal documents its own encryption process, and you can check the app source code to verify it. https://signal.org/docs/specifications/doubleratchet/

Signal is the best choice I know of when I'm looking for the union of 1. True e2e encryption, and 2. Ease of use by non-technical people.

The fact that it locks you into using their servers, does not distribute on F-Droid (only Google Play OR an APK with an insecure update mechanism), and has a completely closed-source "abusive message filter" module server side, that could functionally be used for censorship, storing messages for future decryption, or any other number of nefarious purposes - we have no idea since it's not open source (https://github.com/signalapp/Signal-Server/blob/main/.gitmod...).

Additionally, you cannot distribute branded forks or Signal, and if you do fork it, your fork is not allowed to connect to Signal's "official" OWS (open whisper systems) servers - hostility to federation should be viewed with prejudice and suspicion at the very least, it suggests a vested interest in a single point of failure (or control), which goes against user interests.

Further reading: https://drewdevault.com/2018/08/08/Signal.html

Signal uses Curve25519, AES-256, and HMAC-SHA256 for its e2e encryption. So unless you believe those algorithms are insecure, there's no reason to think that their server setup is a compromise on your messages' security.

Fear of "future decryption" applies equally to all forms of encrypted communication, regardless of which servers the messages go through. And since AES-256 is known to resist quantum computing decryption, there's no actual reason to think future decryption will be an issue.

Signal has actually been approached by governments for whatever user data they have, and exactly none of it included messages - encrypted or otherwise. https://www.dailydot.com/debug/signal-grand-jury-subpoena-da...

As for everything you said about F-Droid and forking, see https://molly.im/ . It's not a "branded" fork but it does connect to Signal's servers.

You don't need to break encryption to engage in censorship based on unencrypted metadata.

OWS is based in San Francisco. The US federal government has compelled providers to introduce backdoors or start logging information that was not being logged before for certain IP addresses or user identifiers - phone numbers in this case, and done so under gag orders that prevent companies from disclosing it. Judges can rule that use of a warrant canary as intended can violate these gag orders as well.

Just because Signal can share 1 or 2 instances of cases where information was requested and they did not comply does not mean they never have, weren't able to in the past, or aren't able to in the future.

As others have stated, using Signal is putting a lot of trust into the OWS legal entity, and proper cryptosystems should not rely on trust.

I hadn't heard of Molly and am checking it out now, thank you for sharing.

Just use a open protocol that doesn't lock you into a specific server or client, like XMPP with OMEMO.