maqp

What's the ideal route for someone familiar with 3ds Max to learn Blender? I feel a bit stuck with my proprietary skillset.

What's the vulnerability they injected into DES?

Very secure servers are openly documented (Kerckhoff's principle).

Snake oil purporting itself as secure is always very hush hush and comes with claims of security.

Besides, other messengers like Signal have already made the server open source, and they have native clients that end-to-end encrypt everything, so you don't even have to trust server.

Durov requiring you to trust the server shows he has no idea how to build secure systems. He and his team are amateurs in security engineering.

Telegram offering bells and whistles that leaks everything to the service provider is not an argument for Telegram the same way "it launches the video game" isn't an argument for video game cracks that carry ransomware.

Both are called Trojan Horses and are considered malware.

The bigger issue is Telegram advertises it as more private option to WhatsApp although Telegram collects more metadata, and also the message content. People think Telegram is more private, they don't use it as a public forum replacement. Also, institutions running Telegram have people form closer working groups that become groups for friends, who don't necessarily realize they should be moving to Signal the moment the members start sharing things they don't want everyone to know.

Too bad he gave the job of company cryptography team to his brother, Nikolai who's an expert in geometry, not cryptography.

Yup but the issue is Telegram already has two separate groups, normal groups (3-200 users), and supergroups (200-200,000 users). For end-to-end encrypted groups, Threema supports 256 members, Signal 1000, Wire 2000, and Matrix has no upper limit. Surely Telegram could deploy E2EE for normal groups. Nobody assumes groups with more than 200 members are private anyway.

Durov who supposedly lives in exile has visited Russia over 50 times

Durov's exile marketing makes him look like he's Alexei Navalny. Navalny was a true dissident and critic and he was first poisoned, and then later arrested when he returned. He was was then imprisoned and he died in prison.

Durov has been visiting Russia more than I've been visiting my friends over the same period. Him returning to Russia that many times shows he isn't really living in exile. He's not on the run, and he's not getting arrested when he visits Russia. The disparity between the stories forces one to ask, is he working with the Russian government instead. He can prove he isn't by deploying ubiquitous end-to-end encryption, until then there's very little reason to suspect he isn't, again given the mismatch between what's claimed (the exile) and what's happening behind the scenes (the visits the public doesn't know about).

and regarding the cracking contests — one of the telegram bugs was actually uncovered this way, see https://habr.com/ru/articles/206900/

That article doesn't even mention the cracking contest. The XOR-nonce bug was also found by Valsorda in 2021 https://words.filippo.io/telegram-ecdh/ so looks like that 2013 post you linked to never even led to a fix during the EIGHT years. No idea if it still exists.

Also, you can't be racist towards Russian government that's OBVIOUSLY evil. From Navalny, to Bucha, to bombing hospitals, to kidnapping children, to the illegal war in the first place.

Ukrainian military has literally relied upon it in the past

Well they realized their mistake and banned Telegram's use on state issued devices in 2024 https://www.bbc.com/news/articles/c78dwepw95do

I'm not going to speak for the author of that article. But I agree with his conclusion. Telegram is indistinguishable from a honeypot.

In the world of infosec, stuff isn't secure until someone proves you wrong (which you reject assuming racism). Stuff is secure when you prove it's secure.

Practically every major secure messaging app vendor has proven they can not be a honeypot, by end-to-end encrypting their communications, offering open source clients with public key fingerprints to verify that end-to-end encryption is working correctly.

Telegram hasn't done that. Telegram's lack of end-to-end encryption, paired with zero effort for metadata protection (not even stuff like sealed sender) shows they don't give a damn about actual security.

But what they do is also what an FSB op would do.

* It would advertise "heavily encrypted" and bash WhatsApp day after day convincing average Janes and Joes about it being really really secure, and confuse readers who take a closer look, with claims of all chats using MTProto but also calling both client-server and end-to-end encryption protocols MTProto.

* It would construct a narrative that the face of the app is a rebel dissident in exile.

* It would be banned temporarily or poorly

* It's role would be obfuscated by releasing an obviously backdoored app like Max, to make Telegram seem safe compared to it. Like Russian intelligence really believed they could use Max to monitor Russian dissidents. FSB isn't dumb. Russian military deception is world famous. https://en.wikipedia.org/wiki/Russian_military_deception

The backdoor sits in the fact nothing is end-to-end encrypted, groups can't be E2EE, but troll army can still defend it, claiming it does have 1:1 E2EE if you want. Yes, it does, if you really want the highest friction UX possible. People try and drop secret chats when they want to be able to alt-tab into the conversation instead of digging into their phones 100 times a day. This backdoor is ingenious because the users can only blame themselves when their 1:1 messages end up to the server.

A good messaging app creator knows this, so they make E2EE default so that users don't encounter such friction. E.g. Signal allows you to have E2EE 1:1 and group chats between all of your devices. That's what proper privacy by design looks like. Would Telegram do that, they would've proven they stand for their users, and I'd actually recommend them.

Data is a toxic asset. Even if Telegram isn't a honeypot, it's a massive data collecting apparatus, that has all that data sit on its servers, from which the hacking team of any major intelligence agency can access it en mass. That's the life of 1B users worldwide. So ultimately, it doesn't even matter if Telegram is a honeypot, it's equally usable to https://en.wikipedia.org/wiki/Fancy_Bear or NSA TAO or whoever.

Also, https://dfrlab.org/2018/02/15/putinatwar-how-russia-weaponiz... shows Russian troll army is using russophobia as a narrative online.

This isn't about hating on Russians. This is about Durov not passing the minimum bar of what modern secure communication is about.

You've so far claimed telegram is the best with nothing to back that claim, ignored every counter argument, attacked argument of someone other than me, and you're now replaying Russian government shill tactics to try to rally people behind you for emotional reasons, when I'm explicitly giving technical critique.

telegram is the safest encrypted messaging app. Period, full stop.

Yes, let's see

* Not end-to-end encrypted by default

* No end-to-end encrypted groups

* No end-to-end encryption on any desktop client by the vendor, forcing cross-platform users to drop secret chats. This includes 81% of working age people who sit on their computer during work day, and 100% of college students and IT workers.

* No post-quantum key exchange

* No future secrecy

* No per-message forward secrecy

* Bullshit claims about distributed keys https://security.stackexchange.com/questions/238562/how-does...

* Lacks ALL metadata protection from server like phone number, IP-address and thus geolocation, contact list, group memberships, quantity and schedule of communication, data types. In fact --

* Secret chats leak additional metadata about intent to hide content from TG as the vendor.

Also,

History of poor encryption implementation

* 2013: A cracking contest https://news.ycombinator.com/item?id=6932648

* 2013: Telegram, AKA "Stand back, we have Math PhDs!" http://unhandledexpression.com:8081/crypto/general/security/...

* 2015: IND-CCA issues https://eprint.iacr.org/2015/1177.pdf,

* 2015 64-bit complexity MITM attack https://web.archive.org/web/20160425091011/http://www.alexra...

* 2021 Valsorda "The Most Backdoor-Looking Bug I've Ever Seen" https://words.filippo.io/telegram-ecdh/,

* 2021 https://mtpsym.github.io/ and https://mtpsym.github.io/paper.pdf

Some analysis:

* 2025 Matthew Green analysis https://blog.cryptographyengineering.com/2024/08/25/telegram...

* 2025 "Telegram is indistinguishable from an FSB honeypot" https://rys.io/en/179.html

Also,

They employ volunteering sockpuppets https://tsf.telegram.org/

Durov who supposedly lives in exile has visited Russia over 50 times https://eutoday.net/pavel-durovs-secret-visits-to-russia/

I can't scream "drop & run" loud enough.

There's nothing slow about AES.

In this context "heavily" means "we can't legally claim it's end-to-end encrypted because it's not".

Also it's not even post quantum, so it's not heavy. Telegram's Diffie-Hellman breaks instantly with a quantum computer large enough to run Shor against it.

Also, the keys sit on the servers' RAM, no matter what they lie. There is no global distributed RAM system, especially one that encrypts data in distributed fashion and works at the negligible latencies that Telegram boasts.

https://docs.cwtch.im/ has P2P Onion Service based messaging.

Probably not. It's been ~13 years when Snowden said what the NSA is doing is going around the encryption by hacking endpoints. Post quantum cryptography doesn't change any of that. You can still lift TLS keys with exploits for transparent MITM. I'd imagine it's much better ROI to look for vulnerabilities with Mythos, than to attack the algorithms.

PSA: https://dr.loudness-war.info/ is a great place to look for info on dynamic range of releases, and also, a great place to find new music with excellent dynamic range.

What are you hinting here? Surely you can make a positive claim with evidence to back it? A CEO of a big project like SimpleX wouldn't stoop as low as Pavel Durov?

Same guy, always pretending we've never had the same discussion over and over here, Reddit and privacyguides, for years. You're always running away.

The protocol is designed to provide packet-level anonymity

Anything you do to harden SimpleX on server side does not matter to user. Unless the client protects the user it's not really helpful. The user only has your word that the server is stripping the IP address from the package.

so that neither of the servers can see which IP address talks to which IP address

Two computers that could be run by the same entity. Also, the entire public infrastructure is again either Akamai or Runonflux. 50% of SimpleX chats' metadata is accessible by a single company, which is not even you so you have no control over it.

always choose server operated by another operator, to mitigate collusion risks.

How does Alice, Bob and Charlie choose a third VPS provider when there's only two?

My problem with Tor is that after all these years it takes zero steps to prevent collusion and data sharing by Tor node operators [...] that independent parties run relays in the circuit - is simply untrue

I don't know how to tell you this, but 10,000 Tor relays is absolutely more diverse than two VPS provider companies.

You're already supporting Tor. You're already running Onion Service servers.

How about you stop running to the mountains once again, go visit what I wrote to you in the PrivacyGuides threads on Cwtch vs SimpleX and actually consider that.

If people want to use Tor, it's their choice, and the app supports it. But we won't be integrating it.

Then maybe it's time to strip the "no identifiers" bullshit from your marketing language. If you can't be open upfront about the client leaking the IP-address and you're not fixing the leak, I have zero problems referring to you as the snake oil you are.

The point is there is no public key capability in BB84 that requires pre-sharing a symmetric key.

You absolutely do get forward secrecy with pre-shared keys. You just need to make the protocol derive the next key with a cryptographic hash function, and deliver the iteration count with the packet so the recipient knows which key is the correct one. This is called a SCMIP or hash ratchet, and it's used e.g. in Signal protocol.

(As implementation details, you'll also want to hash the hash ratchet counter with the key to prevent theoretical loops, and you'll probably want to encrypt the ratchet counter during delivery with static header key, or the very least authenticate it.)

QKD is interesting from the PoV of perfect secrecy. But AFAIK with e.g. BB84, the basis orientation communication (used to detect OTP delivery eavesdropping) is done with Wegman-Carter (unconditionally secure) authentication using... a pre-shared key.

So if you're only interested in computational security that is post-quantum, why not pre-share a symmetric key for some AEAD scheme? You'll get forward secrecy with hash ratchet and neither provides future secrecy in principle.

Neither solves the bootstrap and QKD requires a really, really expensive and complex infrastructure just to provide perfect secrecy which we're fine without.

In 2006?

Plus the company likes to advertise their product as more metadata-private than Tor Onion Service based messaging apps like Cwtch.

They lie by omission when they say that the service doesn't have any user IDs. What they really mean is, the application does not add its own long term identifiers. But by default, the application takes zero steps to anonymize your IP address from the server, meaning the server can very probably tell users apart.

It's also ridiculous that the entire public server infrastructure is hosted under two companies: Akamai and Runonflux. Roughly 50% of your conversations can be end-to-end correlated by a single VPS company.

Thank goodness. Finally. Yeah I'm just not comfortable with 80-bit complexity against Grover, even if it's practically infeasible.

Could we finally get SHA256 fingerprints. Or BLAKE2, or SHA3-256, or SHAKE256, or BLAKE3, or LITERALLY ANYTHING BUT SHA-1, pretty please?

Some DJs use this principle when they need a hacky stage mic. They plug their headphones to the mixer's mic input, and shout to the speaker element.

and many LEDs are weak photo-diodes, i.e. you get weak current when you shine a light to them.

The sad part is, Instagram is exceptionally damaging to kids for a disjoint set of reasons.

A lot of bug fixing relies on some mental model about the code. It manifests as rapid "Oh 100% I know what's causing" -heureka moments. With generated code, that part's gone for good. The "black box written by a black box" is spot on on, you're completely dependent on any LLM to maintain the codebase. Right now it's not a vendor lock thing but I worry it's going to be a monopoly thing. There's going to be 2-3 big companies at most, and with the bubble eventually bursting and investor money dying, running agents might get a lot more expensive. Who's going to propose the rewrite of thousands of LLM-generated features especially after the art of programming dies along with current seniors who burn out or retire.

Loading your messages on Signal can take quite a while.

Yeah if you have to go through hundreds of ratchet steps, yeah it will take time. That's expected. The only way to make it faster than that is to deploy it without privacy. That's cheating.

Why are you ignoring the fact Signal actively prohibits third-party clients?

Because it's not a problem for security.

Yes, Telegram is far from perfect, and inferior to Signal when it comes to E2EE.

Telegram's lack of ubiquitous E2EE is a blocking issue. Signal's wait times is a problem that goes away with 5G, 6G etc., and with them nanometers going down.

But what makes you reject the proprieatry blob claim when it's true?

What blobs? Firebase? I have bad news for you wrt Telegram https://github.com/DrKLO/Telegram?tab=readme-ov-file#compila...

Because your favorite messenger is being attacked?

Not my favorite messenger. Nor is it my messenger. Signal is the best messenger for day-to-day use though.

The server IPs are hard-coded into the Telegram client's source:

https://github.com/DrKLO/Telegram/blob/d7deedfa33ddfa51c72a5...

You know you can just run

$ git clone https://github.com/DrKLO/Telegram.git && cd Telegram && FILE="TMessagesProj/jni/tgnet/ConnectionsManager.cpp" && git log --reverse --format='%ad %h %s' --date=short -S'149.154.175.50' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:b28:f23d:f001:0000:0000:0000:000a' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'149.154.167.51' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'95.161.76.100' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:67c:4e8:f002:0000:0000:0000:000a' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'149.154.175.100' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:b28:f23d:f003:0000:0000:0000:000a' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'149.154.167.91' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:67c:4e8:f004:0000:0000:0000:000a' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'149.154.171.5' -- "$FILE" | head -n 1 && git log --reverse --format='%ad %h %s' --date=short -S'2001:b28:f23f:f005:0000:0000:0000:000a' -- "$FILE" | head -n 1

To get when the IPs first appeared, right? :D

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2020-06-04 dceccae0b Update to 6.2.0 (1984)

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

2015-09-24 6bb7547f5 Update to 3.2.2

They've been the same IP addresses for ELEVEN years, and they precede the article you linked by THREE YEARS.

They're not playing the catch-up with Russian government. Either Russian government is completely incompetent in that they're blocking 3,000,000 IP addresses and failing, or they are LYING about attempting to block it, which would indicate Telegram is a Russian op.

Nice touch with the IP :D

The ratchets would have different state yes. The MITM would mix in different entropy into the keys' states. It's only detectable if the MITM ever stops. But since the identity key exfiltration only needs to happen once per lifetime of installation (longer if key is backed up), the MITM could just continue forever since it's just a few cycles to run the protocol in the server. You can then choose whether to read the messages or just ignore them.

One interesting way to detect this would be to observe sender's outgoing and recipient's incoming ciphertexts inside the client-to-server TLS that can be MITM'd by users. Since the ratchet state differs, so do the keys, and thus under same plaintext, so do the ciphertexts. That would be really easy way to detect MITM.