[HN Gopher] Cryptographers unearth vulnerabilities in Telegram's...
___________________________________________________________________
Cryptographers unearth vulnerabilities in Telegram's encryption
protocol
Author : wglb
Score : 282 points
Date : 2021-07-17 16:36 UTC (1 days ago)
(HTM) web link (www.cyberscoop.com)
(TXT) w3m dump (www.cyberscoop.com)
| [deleted]
| Amin699 wrote:
| Good job
| JanisErdmanis wrote:
| Being in the academia and kn knowing it's culture I will help to
| translate. The cryptographers studied the Telegram protocol and
| did not find practical vulnerabilities. So to pay their "academic
| debts" they published a paper on a vulnerability which can mess
| up senders messages in a random way.
| maqp wrote:
| Were you in the academia, you'd know Telegram should've hired a
| cryptographer when they started, almost a decade ago. They have
| never done that, because to them pride is more important than
| doing things right. You, an academic, spending your Sunday
| defending some random messaging app company online a, and doing
| it for free, is almost as stupid as the parent company's
| decisions to favor grass-roots damage control over secure-by-
| default design.
| martinralbrecht wrote:
| Since you know the culture in academia so well you may also be
| familiar with that custom where you glance over the actual
| paper before making assertions about it. Not even asking you to
| read it, just glance at it.
| _huayra_ wrote:
| I'm really curious how Telegram makes money. Signal had (has?)
| their crypto thing, Whatsapp snarfs up the user graph /
| interactions, but Telegram just supposedly shows adds on large
| groups.
|
| I really don't know how that is enough to support half a billion
| users, just in terms of hardware cost.
|
| Are they spying on some group of crypto whales to get insider
| info?
| WilTimSon wrote:
| Here's a source from TC. TL;DR Non-targeted ads in channels,
| which are like RSS feeds or blogs, no ads anywhere else. Also
| considering "premium" animated stickers:
|
| > The service, which topped 400 million active users in April
| this year, will introduce its own ad platform for public one-
| to-many channels -- "one that is user-friendly, respects
| privacy and allows us to cover the costs of server and
| traffic," he wrote on his Telegram channel.
|
| > "If we monetize large public one-to-many channels via the Ad
| Platform, the owners of these channels will receive free
| traffic in proportion to their size," he wrote. Another way
| Telegram could monetize its service is through premium stickers
| with "additional expressive features," he wrote. "The artists
| who make stickers of this new type will also get a part of the
| profit. We want millions of Telegram-based creators and small
| businesses to thrive, enriching the experience of all our
| users."
| owlbynight wrote:
| It took me like 5 seconds to get an answer for this with a
| search. Please don't posit wildly speculative scenarios in
| public forums.
| tester756 wrote:
| ?
|
| Article 1:
|
| >How does Telegram make money?
|
| >Telegram doesn't make money, or at least it doesn't generate
| revenues, as of 2019. Durov pointed out on a blog post that
| he "believes in fast and secure messaging that is also 100%
| free."
|
| >On the same blog, post, Telegram notes that if it were to
| run out of money, it might introduce "non-essential paid
| options" to supplement developers' salaries.
|
| Article 2:
|
| >All the features that are currently free will stay free. We
| will add some new features for business teams or power users.
| Some of these features will require more resources and will
| be paid for by these premium users. Regular users will be
| able to keep enjoying Telegram - for free, forever.
|
| >In addition to its messaging component, Telegram has a
| social networking dimension. Our massive public one-to-many
| channels can have millions of subscribers each and are more
| like Twitter feeds. In many markets the owners of such
| channels display ads to earn money, sometimes using third-
| party ad platforms. The ads they post look like regular
| messages, and are often intrusive. We will fix this by
| introducing our own Ad Platform for public one-to-many
| channels - one that is user-friendly, respects privacy and
| allows us to cover the costs of servers and traffic.
|
| >If Telegram starts earning money, the community should also
| benefit. For example, If we monetize large public one-to-many
| channels via the Ad Platform, the owners of these channels
| will receive free traffic in proportion to their size. Or, if
| Telegram introduces premium stickers with additional
| expressive features, the artists who make stickers of this
| new type will also get a part of the profit. We want millions
| of Telegram-based creators and small businesses to thrive,
| enriching the experience of all our users.
|
| so... they don't?
| maqp wrote:
| >Telegram doesn't make money, or at least it doesn't
| generate revenues, as of 2019. Durov pointed out on a blog
| post that he "believes in fast and secure messaging that is
| also 100% free."
|
| Durov might as well be paying lip service here. Telegram
| reserves the right to change its ToS. Facebook didn't spy
| on 100% of its users actions when it started. It was a
| picture rating service. The business model came after.
| Durov still has money left after he was forced out of
| VKontatke. He's in no rush to cash in. There's no telling
| when Telegram will be sold: it's not a non-profit and can
| be sold any moment.
|
| I can understand philanthropy, but given how Durov has paid
| zero dollars over the past 8 years to cryptographers to
| design a protocol that ACTUALLY locks him out of terabytes
| of insanely valuable user data, I find it hard to believe
| his motives are pure.
|
| With Moxie and Signal I can trivially say it's not a CIA
| front despite any money from Radio Free Asia, because I can
| check the end-to-end encryption works and protects every
| message. Given Durov's background in information warfare
| and disinformation, connections to Russia etc. and him
| having access to almost 100% of users' content and
| metadata, I can't say with confidence Telegram isn't an SVR
| (Russian NSA) front.
| Dah00n wrote:
| >I can check the end-to-end encryption works and protects
| every message.
|
| You would be a fool and a poor spook if you created
| Signal as a honeypot and made it insecure from the get go
| to anyone looking. It would be made insecure either later
| on or by an extremely hard to find "bug". We know from
| Snowden that the NSA secretly weakens encryption products
| to make them vulnerable. All your case proves(?) is that
| Signal is a better made honeypot than Telegram if any of
| them are actually a trap.
| maqp wrote:
| "You would be a fool and a poor spook if you created
| Signal as a honeypot and made it insecure from the get go
| to anyone looking. It would be made insecure either later
| on or by an extremely hard to find "bug". We know from
| Snowden that the NSA secretly weakens encryption products
| to make them vulnerable. All your case proves(?) is that
| Signal is a better made honeypot than Telegram if any of
| them are actually a trap. "
|
| You can't be serious. Anyone can show that vulnerability
| in the codebase. Signal has internal code review
| processes, and the git log is public. There is no better
| process out there, or if there is, you'll have to explain
| it. There is no perfect process but if you're trying to
| argue that justifies Telegram doing nothing wrt e.g.
| group chat end-to-end encryption, you're out of your
| mind.
|
| Here's the thing: There's nothing that indicates Signal
| has a backdoor. OTOH, Telegram doesn't have to be
| converted into one, it ALREADY DOES IT. All that the NSAs
| of the world have to do, is hack the server. And since
| you're so intimately aware of Snowden's output, might I
| remind you of his SXSW talk from 2014 where he said NSA
| hacks systems all the time?
| C19is20 wrote:
| ....then show your 'like' 5 seconds of results? * like -
| apart from grammatical comparisons, and 'to enjoy,', does it
| like mean anything anymore, er....innit?
| strogonoff wrote:
| It doesn't matter much what vulnerabilities there are when a
| large chunk of your users don't even use e2e encryption. For a
| while recently I had used Telegram to communicate with a few
| people, and as an experiment I did not turn on e2e myself. Well,
| neither did any of my counterparts (even the more security
| conscious ones). I suspect people are inclined to use it only in
| special cases, as the UX rather gives off the vibe of pulling
| your counterpart into the cover of a dark side alley at night
| (rather than being the default of a presumably secure messenger).
| noxer wrote:
| It has severe drawbacks if you use e2e. The default is without
| because that's what most people want.
| lucb1e wrote:
| Telegram's implementation has severe drawbacks that people
| don't want; e2ee in general does not have to have those
| drawbacks.
| noxer wrote:
| Maybe try telegram someday? Because you dont seem to know
| what it can do? The features is has are NOT possible with
| e2e. Its not an implementation flaw its a implementation
| decision they made on purpose and clearly explained in
| their FAQ why they made it.
|
| >e2ee in general does not have to have those drawbacks.
|
| How come no other messenger simply copies telegrams feature
| but with e2e? Also what exactly is the point of e2e chats
| if every user that joins gets a key to decrypt the whole
| chat. Its completely useless "security".
| lucb1e wrote:
| > The features is has are NOT possible with e2e. Its not
| an implementation flaw its a implementation decision they
| made on purpose
|
| Oh don't be so vague, go on and name one!
|
| > How come no other messenger simply copies telegrams
| feature but with e2e?
|
| I've been wondering the same thing, especially for
| something as young as Matrix that didn't (at the time
| Telegram was already good) have a decent client
| themselves yet.
|
| I've also been thinking myself of doing exactly that, but
| then it's basically a full-time job to get something
| halfway decent. People worked on reverse engineering a
| server at all, not an encrypted server but just any
| working self-hostable server at all. I don't remember the
| repository name but it's on GitHub. Even this was
| abandoned because it's just a ton of work that very few
| people are going to use. Additionally modifying the
| clients to work with a different protocol is even more
| work.
|
| So I can see why people aren't doing this because I'm one
| of them, but yeah what I don't get is why the folks at
| Signal/Matrix/Threema/etc. would rather start from
| scratch than do this.
|
| It might be easier to have some sort of plugin that
| overlays encryption on top of Telegram and uses the
| existing servers. On F-Droid there's this project called
| OverSec <https://f-droid.org/en/packages/io.oversec.one/>
| that I've been meaning to try, though presumably it hooks
| on an input field level and so it couldn't decrypt images
| before decrypting so it's not a full solution. You'd need
| to really modify the client (every one of them) and
| everyone needs to use your custom clients.
| maqp wrote:
| >The features is has are NOT possible with e2e.
|
| Which feature?
|
| >clearly explained in their FAQ why they made it.
|
| They absolutely did not.
|
| >How come no other messenger simply copies telegrams
| feature but with e2e?
|
| Which feature isn't being copied? Signal just implemented
| effin stickers with end-to-end encryption.
|
| >Also what exactly is the point of e2e chats if every
| user that joins gets a key to decrypt the whole chat.
|
| Firstly, new users in e.g. Signal groups don't get access
| to group message history. Secondly, overwhelming majority
| of Signal groups are not public. Your claim that E2EE in
| groups is useless assumes anyone can join any group.
| That's not the case, therefore your argument is
| completely baseless and thoughtless.
| strogonoff wrote:
| Part of my point. I use WhatsApp and Signal, both using the
| Signal protocol, and experience no drawbacks whatsoever.
|
| In any case, for a messenger that advertises as secure,
| placing security after convenience seems pretty unusual.
| noxer wrote:
| No drawbacks over what? Over WhatsApp before they got e2e?
| Compared to telegram both of these are 5+ years behind. And
| have a different use case for a lot of users. Telegram
| being some kind of social media IM with a focus on public
| content and pubic messaging where the whole security thing
| is moot anyway. Personally >99.9% of my messages on
| telegram are public or at least accessible by strangers
| which I have zero reason to trust. There is no point
| encrypting such messages. They are similar to HN comments.
| I consider these messages public but still like the fact
| that neither google nor FB indexes or analyses them to send
| me spam/ads.
|
| >for a messenger that advertises as secure
|
| Its p much PR nonsense but to be fair it also come from the
| early days when telegram was the only IM with any e2e that
| had a relevant market share. I think its understandable
| that they will not remove "secure" from the description
| after all those years, it would raise some eyebrows if they
| would suddenly no longer say is secure ryt?
| Laarlf wrote:
| No drawbacks? Whatsapp requires your phone to be on and
| have Whatsapp running in the background if you want to use
| it over Whatsapp Web. Also the amount of Messages and Media
| that Telegram delivers to me would not fit on my Phone.
|
| Also let's not forget what a bad user experience Whatsapp
| offers apart from that. No bots, no channels, no hiding
| your phone number, no polls, limited permission system in
| groups,... i could continue for 20 minutes. But what is
| most infuriating to me is the backup system. It never works
| and you can only store it in iCloud/Google Drive.
| beermonster wrote:
| See https://www.theverge.com/2021/7/14/22577594/whatsapp-
| multi-d...
| Laarlf wrote:
| Still all the other points. And i am REALLY not sure if
| switching from a company that is known to try to not give
| data to governments to facebook, which makes it's money
| by analysing and selling data would make a lot of sense.
| strogonoff wrote:
| Ah. I'm not using any of those features, I just use it
| for text messaging.
| theshrike79 wrote:
| If you use Whatsapp as a SMS replacement, then you'll be
| fine.
|
| Many Telegram users use them for chats with large groups
| of people (hundreds or thousands) with native bot support
| being a huge thing.
|
| Whatsapp and Signal don't give many tools for handling
| groups that big, with Telegram you can actually manage
| it.
| maqp wrote:
| "It has severe drawbacks if you use e2e. The default is
| without because that's what most people want."
|
| I would suspect majority of users would disagree with the
| question "are you ok with Telegram keeping a plaintext copy
| of your messages"
|
| The most technical answer you can expect is "All Telegram
| chats use MTProto encryption. Their End-to-end encryption
| protocol is called MTProto. Ergo, they can't see my
| messages".
|
| Ask any user if they want privacy or no privacy. 0% will tell
| you, oh I explicitly want no privacy.
| c7DJTLrn wrote:
| When you really think about it, almost nobody can be sure that
| their conversations are end-to-end encrypted. The only way you
| can be is to verify the fingerprint on both ends, provided you
| have exchanged fingerprints over a medium known to be secure or
| in person. Nobody does that.
| maqp wrote:
| You make this idiotic assumption that chat companies are MITM
| attacking users. Sure, the only way to be sure there is no
| MITM is to check the fingerprints. But that's aching to false
| dichotomy. You're not actually choosing between
|
| 1. 100% verified E2EE chat and
|
| 2. 100% MITM attacked insecure chat
|
| When you don't check the fingerprints, when you are choosing
| between E2EE and client-server encryption, you're actually
| choosing between
|
| 1. Chat vendor having to commit felony with mandatory minimum
| sentences, to read your messages
|
| 2. You voluntarily sending EVERY SINGLE MESSAGE to the vendor
| without any expectation of privacy, and thus waving your
| legal right to privacy.
|
| So no, opportunistic end-to-end encryption is definitely not
| equivalent to cloud encryption.
|
| Sure, if your personal threat model is that there must be
| zero chance of some messages ending in wrong hands (maybe
| you're a lawyer sending private info to client, or naughty
| pics to your SO), then sure, you will want to perform the
| fingerprint check. But for majority of communication, it's
| enough that there is a significant threat of users verifying
| the fingerprints: Getting caught doing MITM against users is
| extremely damaging for the company, and again, will land you
| jail time with very high probability.
| strogonoff wrote:
| It's verifiable, though.
| templarchamp wrote:
| One day, as the nature of hardware changes, these cryptos will be
| exposed.
| isatty wrote:
| While bashing on Telegram is basically HNs favorite past time,
| there aren't many other alternatives that work just as well in
| the area that I care the most about: being a great chat app.
| Telegram is fast, has native clients instead of a garbage web ui
| (or electron based app), has better stickers than the
| alternatives, is easy to write bots for and has a larger user
| base where I'm at than any of the alternatives other than
| WhatsApp.
| maqp wrote:
| >Telegram is fast
|
| It's fast because it's insecure. Would they deploy end-to-end
| encryption for their groups, it would be as slow as the
| competition.
|
| >has native clients instead of a garbage web ui
|
| The "native clients" are used to manage data stored on remote
| server over an encrypted tunnel. The data that sits on Telegram
| servers is plaintext. The security benefits of the native
| clients (e.g. handling E2EE in a secure way) don't really play
| out when the desktop application doesn't feature end-to-end
| encryption at all, not even for 1:1 chats.
|
| >has better stickers than the alternatives,
|
| My Signal client has 1:1 match of my Telegram sticker packs.
| This is a non-issue. Porting them is trivial.
|
| >has a larger user base
|
| Sure, which means, larger amount of your data is hoarded by the
| Mark Zuckerberg of Russia who will take zero responsibility if
| his servers are hacked.
|
| Just a thought: You should probably refrain from advertising
| features of an app the glaring security issues of which you can
| ignore out of your privilege. There's a LOT of oppressive
| regimes in the world, and people living there shouldn't take
| your advice.
| isatty wrote:
| I don't understand your first two rebuttals. I didn't want to
| keep talking about the fact that Telegram is not secure by
| default (there are plenty of other comments that go into
| this); I understand this, thank you.
|
| It doesn't have anything to do with the competition being
| unable to provide a fast _native client_ that I can use. I
| dislike web based apps, and I refuse to use them whenever a
| native alternative is available.
|
| > It's fast because it's insecure. Would they deploy end-to-
| end encryption for their groups, it would be as slow as the
| competition.
|
| Doubtful - it would increase the amount of compute required
| on their side, sure, but if done properly it will have close
| to 0 impact on the end users in terms of latency.
|
| > Mark Zuckerberg of Russia who will take zero responsibility
| if his servers are hacked.
|
| As opposed to _x_ from country _y_ that WILL take
| responsibility if their servers are hacked? Please.
|
| I will continue to talk about what I like about the user
| interface and what it does better than the competition
| because I want to.
| maqp wrote:
| >I dislike web based apps, and I refuse to use them
| whenever a native alternative is available.
|
| I agree with you, I'd use native Signal desktop client
| written on Rust if there was an option. But there isn't,
| thus I'm using the Electron app. It's not lightweight, but
| it's secure by default.
|
| I wouldn't use Telegram native client written in C over
| Signal Electron client, because Telegram doesn't offer E2EE
| on that fast client.
|
| >Doubtful - it would increase the amount of compute
| required on their side, sure, but if done properly it will
| have close to 0 impact on the end users in terms of
| latency.
|
| AFAIK, there is no efficient group DH key exchange
| mechanism, especially not one that's forward secret. Signal
| will always do effectively a for-loop over group member
| list and send message to each contact encrypted with the
| key used to send 1:1 messages. Sure, it has some cool
| optimizations like encrypting attachments with symmetric
| key that is multicasted to each party. But still, this
| can't beat Telegram in speed.
|
| The nice thing is, AES doesnt' have to get slower, neither
| does X25519, smartphones and computers are getting faster,
| as are networks, especially with the advent of 5G. In a few
| short generations, they will be indistinguishable in speed,
| even with groups so large expectation of privacy can hardly
| be assumed.
|
| >As opposed to _x_ from country _y_ that WILL take
| responsibility if their servers are hacked? Please.
|
| This is a really stupid time and place to play the game of
| whataboutism. The point clearly is, vendors that use
| ubiquitous E2EE, don't have to worry about messages leaking
| from server.
|
| >I will continue to talk about what I like about the user
| interface and what it does better than the competition
| because I want to.
|
| Yeah sure, you do that. But perhaps also check your
| privilege before you make recommendations to others wrt the
| nice UX being worth the massive security trade offs. You
| can't say you haven't been warned.
| Laarlf wrote:
| Matrix or IRC if you hate yourself.
| theshrike79 wrote:
| IRC is really hard to do well, since it requires a consistent
| TCP connection to really be useful :/
| Siira wrote:
| I use a self-hosted web client (thelounge). It's still not
| good for casual IM usage IMO, but it's pretty painless.
| joecool1029 wrote:
| Combine the parent's suggestions and use IRC over a Matrix
| bridge. It checks all the boxes when it works and as their
| comment mentioned you'll learn to hate things when it
| doesn't!
| isatty wrote:
| I'm a long time user of IRC, but none of my irl friends are
| on it (anymore).
| Laarlf wrote:
| IRC for me is a way to seek support for OSS projects and
| nothing else. It is not really designed to be a IM for
| phones...
| Andrew_nenakhov wrote:
| Most of Telegram's advantages come from it not being end to end
| encrypted by default. They've proven that simply claiming to be
| the most secure app is better for most users than actually
| being the most secure. Because true security comes with
| drawbacks, and users don't like drawbacks.
| Siira wrote:
| A good app offers options. While most HN folk don't like
| Telegram's default, it at least gives you somewhat of a
| choice (and the user can force the E2E option even if the
| other party doesn't like it)(though they do not give the
| option to make all chats by default E2e, which is indeed a
| dark pattern). The other apps just shove possibly backdoored
| E2E down people's throats with no choice at all.
| maqp wrote:
| >The other apps just shove possibly backdoored E2E down
| people's throats with no choice at all.
|
| You can check e.g. Signal is not backdoored by reading the
| source code. You can find it here
| https://github.com/signalapp/
|
| You can vefify the client you downloaded from Play Store
| hasn't been tampered with. Instructions for that are here:
| https://github.com/signalapp/Signal-
| Android/tree/master/repr...
|
| Your post is slightly ironic, considering Telegram doesn't
| give you any choice on using E2EE for groups or any chats
| for that matter, on majority of desktop clients. Know this:
| when you're not using end-to-end encryption, i.e. when
| you're using Telegram cloud chats, those chats are by
| definition as private as a backdoored E2EE chat would be.
| So one could argue they are front-doored by design.
| einpoklum wrote:
| But Signal won't allow federation and is hostile to
| independent client development.
|
| Also, what about the server source code?
| t-writescode wrote:
| Most of Telegram's advantages come from:
|
| * anonymous accounts. You need a phone number to set up an
| account, but you don't need to share your phone to talk to
| people on it
|
| * network effects. The sticker game is great on Telegram
| _because_ there are so many people on it making stickers.
|
| * the secure chat *option*. It has an option of being secure
| and so therefore people think it's secure and when they find
| out it's not secure all the time, they're still happy that it
| has the option of being secure.
| andy_ppp wrote:
| I often wonder if it's just easier to crack at the phone level
| and just get data from memory as it's unencrypted on the device
| rather than the quite good protocols that may have some problems.
| Are we all looking in the wrong place? Personally I'm sure if
| state actors want they can read your messages, one way or
| another.
| martinralbrecht wrote:
| This is a write-up of our research presented here:
| https://mtpsym.github.io/paper.pdf
|
| We give a high-level overview of what we found here:
| https://mtpsym.github.io/
|
| We also include a discussion of how to interpret our attacks.
| gerdesj wrote:
| This is pretty short and to the point: https://mtpsym.github.io/
| krick wrote:
| Given how bashing on MTProto is a favourite cryptographers'
| activity from the day-0, I'm actually kinda encouraged by the
| fact that's all they found. It's especially nice, that htey could
| fix all of them without breaking back-compatibility, which isn't
| really a given for crypto protocols. Would appreciate more
| technical and less dumbed down responses from the Telegram team,
| though. I have no idea what the fuck "counting grains in the bags
| of sound" is supposed to mean.
|
| (Also, it's funny, but being accustomed to SMS and such I always
| somehow assumed Telegram messages can be reordered by chance too,
| if I send them fast. I never really thought about it, obviously,
| but simply didn't expect it to be otherwise.)
| maqp wrote:
| >I have no idea what the fuck "counting grains in the bags of
| sound" is supposed to mean.'
|
| They have been doing this since the beginning. Their strategy
| of downplaying every attack against their protocol serves to
| mask the fact their team has absolutely no qualifications to
| implement cryptography. Like the original article stated,
| Telegram did not even file for CVEs, simply because they look
| bad. CVEs have been filed for much smaller things than these.
|
| Their security game isn't on the side of secure-by-design, but
| grass-roots-damage-control to justify protocol designed by the
| owner's brother (who is a geometrician, not a cryptographer)
| and insecure-by-default. The nepotism and Russian pride should
| never go before the users' security. But they've never cared
| about it.
|
| Slightly related, you should see /r/telegram on Reddit, that
| outright censors articles that criticizes the app or discuss
| its vulnerabilities. From the looks of it, Telegram is more a
| cult these days than a collective of users. Its users are
| willing to spend hours arguing over semantics, and Telegram
| shamelessly makes use of them having no life, by recruiting
| them to something known as Telegram Support Force
| https://tsf.telegram.org/
| dogorman wrote:
| Russia has been mentioned 7 times in this discussion now,
| every time by you. I don't have any stake in this fight; I
| don't use or recommend any of these applications. But you do
| seem to have a bone to pick.
| tester756 wrote:
| In Russia it's "legal" to hack other countries or their
| citizens, so it's not weird take.
| dogorman wrote:
| The weird part is being the only guy bringing it up half
| a dozen times in one conversation.
| maqp wrote:
| With Russia? No it's just useful to remember Durov's
| background, and since he's Russian, there aren't many
| countries he'd be secretly collaborating with.
|
| When the vendor is intentionally collecting and defending
| the collection of such vast amounts of data, you have to
| ask, who might benefit if Telegram was a front.
|
| I'm not specifically against Russia or US, I'm just someone
| who'd prefer people to have the right to their privacy.
| Mass surveillance isn't healthy for society, and Telegram
| is enabling it with their silo of user data.
|
| So ultimately, it doesn't matter if Durov is directly
| playing for any big party, the problem is there's not
| enough tech in place to prove he isn't and when that's the
| case, Telegram servers and the user data that sits there,
| is a free for all. A server in UK is not legally, (or
| technically) protected from the NSA, CCA, Fancy Bear, Unit
| 8200, Iranian Cyber Army etc.
|
| The only bone to pick here is any vendor who'd claim to be
| fighting for privacy when their privacy-by-design
| architecture is indistinguishable from honey pots and
| surveillance capitalistic companies.
| Dah00n wrote:
| >A server in UK is not legally, (or technically)
| protected <snip> a free for all
|
| So exactly like servers from Facebook, Signal, Google,
| German police, etc. anywhere on earth. Just ask NSA (or
| Snowden). This is the whole China debate over again: Who
| would you rather that have access to all your old data
| the day something you did years ago suddenly become a
| danger to you because some fascist person became a
| dictator? China, who likely cannot touch you if you are
| outside Mainland China or the US, who will happily kidnap
| you from almost any place on earth if they dislike you
| enough (often with local help)? I'd rather put my eggs in
| a Chinese (or Russian) basket than a US/UK one if I had
| to pick only between those options.
| maqp wrote:
| What are you talking about :D This isn't about who's
| basket you'd dump your eggs into. The point is, Telegram
| isn't deploying end-to-end encryption, therefore there is
| a basket in the first place. Had they used E2EE, it
| wouldn't matter where the server is located, because the
| server never ever built a massive trove of messages,
| regardless of where the server is physically located.
|
| I'm equally against everyone reading my private messages.
| I don't want to have to choose a country who has my
| messages, I choose my computer, and the computer of my
| peer, where ever they are.
| Dah00n wrote:
| If they have "absolutely no qualifications to implement
| cryptography" then they are doing an _insanely amazing job_
| since such few vulnerabilities were found. All that other
| crap of russia, censorship, reddit threads, russia, cult,
| russia, is beside the point here. It makes no difference on
| the quality of the cryptography. If they suck at cryptography
| then post code that show why at least (and a fix).
| maqp wrote:
| >then they are doing an insanely amazing job since such few
| vulnerabilities were found.
|
| If they are doing amazing job, then
|
| 1. Why isn't desktop chats end-to-end encrypted?
|
| 2. Why aren't group chats end-to-end encrypted?
|
| 3. Why isn't any chat end-to-end encrypted by default?
|
| If they're so good, why does SO MANY vendors like Signal,
| Element, Wire, WhatsApp, Threema, Briar, Cwtch manage to
| pull ubiquitous end-to-end encryption off?
|
| They have the money, why can't they pay a cryptographer to
| design protocol with best practices, and modern primitives?
|
| >cult, russia, is beside the point here. It
|
| They're not beside the point. When the E2EE is practically
| non-existent, the project becomes practically
| indistinguishable from honeypots like the recent Anom, you
| have to ask whose honey pot operation would it be. As for
| the cult aspect, if you're not part of the cult fanbase,
| surely you can stop defending a random company, and take a
| rational stance and condemn Telegram for not deploying
| ubiquitous E2EE? It's not like them doing so would hurt you
| in any way? Surely they in their infinite wisdom can
| implement it?
|
| Also, I don't need to fix their crappy protocol to be able
| to criticize it. I don't need to show you the line of code
| for you to agree there is no E2EE for group chats etc. As
| for my job, I managed to implement ubiquitous end-to-end
| encryption for my project, TFC, even for groups, on an
| extremely constrained split TCB HW architecture. If a CS
| major can pull it off in such circumstances, why the f
| can't a multi-millionare with award winning mathematicians?
| WilTimSon wrote:
| For the grains of sand thing, here's a technical explanation of
| that: https://core.telegram.org/techfaq/UoL-
| ETH-4a-proof#4-attacki...
|
| This document seems like a better response to the theoretical
| problems the researchers found.
| ufmace wrote:
| That's my takeaway here as well - no serious issues found, and
| Telegram actively worked with them to fix their minor
| theoretical issues, and did all of the fixes before the paper
| was published and without breaking any clients.
| Siira wrote:
| Telegram messages do sometimes randomly go out of order,
| especially under bad network conditions.
| kiryin wrote:
| I would avoid Telegram even not having read this. Their homegrown
| encryption and secretive nature of the back-end creep me out. The
| irrational part of me is also wary of the developers' background.
| At the same time I also can not bring myself to trust the other
| popular options either. Whatsapp should be a pretty obvious case
| of facebookiness, and signal suffers from the same lack of back-
| end transparency and decentralization as Telegram. And, believe
| me I don't want to bring this up, but Moxie is just such an
| incredibly untrustworthy figure I wouldn't be able to sleep at
| night trusting his thing.
|
| The only option with any real adoption (still not at the scale of
| the previously mentioned though) is Matrix. Having familiarized
| myself with Olm and their implementation of it for the purpose of
| building clone for educational purposes, I feel safe trusting it.
| You can't go much more open and transparent than Matrix does.
| tester756 wrote:
| Maybe this reddit comment will make you less worried /s
|
| >The lead Telegram dev is a 3x International Math Olympiad gold
| medalist, won another gold in the informatiks olympiad, went on
| to earn two Ph.D.'s in algebraic geometry, all while working
| full-time as a programmer?
|
| >Him rolling his own encryption algorithm is not the same as
| your copy-paste StackOverflow code monkey who scraped by with
| C's at his community college rearranging the alphabet letters
| in a caesar cipher.
| maqp wrote:
| >The lead Telegram dev is a 3x International Math Olympiad
| gold medalist
|
| The lead dev
|
| * doesn't have ANY qualifications as a cryptographer (he got
| his position through nothing other than nepotism) and thus
|
| * thought AES-IGE was best practice
|
| * used SHA-1 10 years after SHA256 was published
|
| * didn't understand the importance of DH parameter pinning
|
| * left in a 64-bit pre-computation MITM attack vector
|
| * initially implemented crappy QR-code like fingerprint for
| secret chats without understanding the need for hex-decimals
| that could be compared over authenticated channels
|
| * couldn't implement IND-CCA secure protocol
|
| * didn't prevent these FOUR new vulnerabilities
|
| But most importantly:
|
| * doesn't have the know-how on how to implement E2EE for
| groups
|
| * doesn't have the know-how on how to implement E2EE for 1:1
| on Win/Linux desktop clients
|
| * doesn't understand E2EE needs to be enabled by default
|
| They are literally just winging it. Their Russian Pride would
| take too large a hit from publishing a CVE wrt the most
| recent issues, thus they downplayed the issues and wiggled
| out to maintain the prestigious image in front of the cult
| that is their users.
| [deleted]
| traveler01 wrote:
| People here failed to realize Telegram made a clear choice
| between usability and security. Cloud messages make it very
| useful and their groups are awesome.
|
| And you can always turn on E2E if you really want to use it. It
| works only on smartphones (probably they should add an option...)
| but it's there and works pretty fine.
| traveler01 wrote:
| And let's not forget. People are studying their encryption
| protocol and they're not finding anything special. It's not
| like you can actually decrypt messages.
| maqp wrote:
| There is nothing to break when the cloud chats are a backdoor
| by design. Imagine a vendor selling bullet proof glass.
| They're arguing the glass itself is extremely durable. These
| jabs at Telegram protocol are like attempts to break the
| glass. Here's the problem, that glass has a three meter hole
| in the middle of it. That hole is called cloud encryption.
| Telegram leaks
|
| * 100% of messages by default to server. This is the same as
| if Signal had a backdoor for all of its messages.
|
| * 100% of group messages with no chance to opt out. This is
| the same as Signal had backdoor for all of its group
| messages.
|
| * 100% of all messages for Windows/Linux desktop clients.
| This is the same if Signal desktop client for Windows / Linux
| had a backdoor that leaked all messages to Moxie.
|
| Telegram's strategy is to exploit that three meter hole. They
| published a bounty for 100,000 dollars for anyone who could
| break the glass. But the competition didn't award any points
| for pointing at the massive hole in the glass.
|
| So no, nobody's finding anything special in Telegram's
| encryption, because EVERYONE got bored of pointing at the
| hole back in 2013 when Telegram was released.
|
| Telegram's backdoor is the front door. It's so absurdly
| obvious it's insane anyone would ever have to point it out.
| But it's right there, if you just bother to look.
| egberts wrote:
| Wow, zero protection against character transposition.
|
| That's like an intentional weakening of "secured-ness".
| lucb1e wrote:
| Where do you read character transposition?
| egberts wrote:
| swapping words is a form of character transposition but on a
| larger scale.
| karpierz wrote:
| It's not swapping words, it's swapping message ordering. To
| swap words, each word would need to be sent in a separate
| message.
| ilrwbwrkhv wrote:
| Telegram is still the fastest,easiest to use,secure messaging
| platform today and its only getting better.
| eingaeKaiy8ujie wrote:
| It's not even possible to use it without a phone number.
| theshrike79 wrote:
| You can't use Signal or Whatsapp without a phone number
| either.
|
| But what's different is that Telegram doesn't share your
| phone number to everyone on the same group chat.
| hirako2000 wrote:
| And the phone number is shared with the provider and if I
| lose my phone number it can be a serious pain to recover
| stuff quickly. Signal, telegram and WhatsApp are
| abomignities. Matrix doesn't tie accounts to cellular
| numbers (God we still are in a world where those cellular
| are a requirement to sign up to most things). The matrix
| network is as transparent as it can be, Element is a decent
| client that runs on iOS, Android and a Web browser.
|
| Element is such a good alternative that the app store
| appears to be stubly demoting it in the search result, and
| never seem to show it as a related messaging client.
| Strange world we live in.
|
| Edit: furthermore, Matrix tech both for the server and
| clients is entirely open source, and one can spin up its
| own network.
| maqp wrote:
| Whataboutism.
|
| Also, 1) you generally don't need end-to-end encryption
| with people you're afraid to share your phone number to,
| and 2) Signal is already working on usernames.
| atatatat wrote:
| Dunno about all that, but I still haven't seen someone decrypt
| a message.
| 0xdeadb00f wrote:
| Lol
| IntelMiner wrote:
| Telegram is definitely the most convenient one with mass
| adoption, especially among the furry community
|
| But let's not mistake ease of use for security
| maqp wrote:
| But that's just the thing now is it. It's NOT secure, that's
| the problem.
|
| * It leaks 100% of messages to server by default.
|
| * It leaks 100% of Win/Linux desktop chats with no chance to
| opt out
|
| * It leaks 100% of group message content with no chance to opt
| out.
|
| * It leaks 100% of metadata with no chance to opt out.
|
| * It always leaks the intention to hide messages from telegram
| chats, Telegram knows with whom you are sending secret chats,
| it knows when, it knows the message size etc. This metadata is
| extremely valuable
|
| Telegram is not in the process of fixing these, thus its
| security isn't reaching the bare minimum. Thus every feature it
| is implementing is another way for the company to collect data
| about you.
|
| It's just another Facebook, masquerading itself as "private app
| for the people". It's run by the man who is literally called
| "The Mark Zuckerberg of Russia". That man has military
| education on information warfare / disinformation: He knows how
| to create a literal cult around his product.
|
| There's almost nothing we know about the company like who it
| employs, how it makes money, what it does with its data.
| Journalists who tried to get an interview with Durov travelled
| to Dubai, only to find empty offices. The office workers next
| door said they had never seen anyone enter Telegram offices.
| They suspected Telegram was using the office for tax evasion,
| which is not a good sign. Telegram's been very enthusiastic
| about a story where they're evading foreign intelligence. If
| that's the threat model, why is their security strategy "store
| all messages on one server" (like the NSA et. al. didn't have
| zero day exploits);
|
| The claims about how the data stored on servers is protected,
| are outright lies a first year computer science student whose
| taken Computer Organization 101 can disprove[0]
|
| Telegram is a dumpster fire and I'd LOVE to be able to say it's
| security is getting better, but it's NOT. They just implemented
| group video calls, are those end-to-end encrypted? No, they f'n
| aren't. Not even NEW features in Telegram are secure by
| default. You know, the features no-one asked for, that they
| were in no rush to deploy. It's especially condemnable as the
| major competition like Zoom, Signal and Jitsi all have end-to-
| end encrypted group video chats. Telegram staff don't care
| about me, you or any other user one bit. The only thing they
| seem to be interested in is "move fast break things" or "move
| fast f** security".
|
| No matter how you put it, Schneier is right when he says data
| is a toxic asset[1]. Telegram can't give any guarantees data
| that sits in their server is forever protected, so they
| shouldn't be collecting it in the first place. WhatsApp is in
| the process of deploying client-side encrypted cloud backups.
| This completely shreds Durov's BS claim that Telegram has to
| have access to your data. There can only be two reasons they
| collect it: Either they don't care about your security, or they
| are actually interested in your data.
|
| [0] https://security.stackexchange.com/questions/238562/how-
| does...
|
| [1]
| https://www.schneier.com/blog/archives/2016/03/data_is_a_tox...
| lucb1e wrote:
| Do Signal, Wire, or Matrix do this transcript consistency thing,
| or is there some other way by which they prevent message
| reordering? From what I know, encrypted messengers almost never
| implement that. At least in Wire I noticed reordering at some
| point and it uses an implementation of what is now called the
| Signal protocol.
|
| And that's the most severe vulnerability from the article. The
| second one is "mostly of theoretical interest" according to the
| researchers themselves, the third requires "an attacker [to] send
| many carefully crafted messages to a target, on the order of
| millions of messages", and the fourth "requires sending billions
| of messages to a Telegram server within minutes". So while this
| is not bad research, not at all (it's really great that people
| take this close a look!), the title sounds rather more severe and
| people will obviously jump to the conclusion that "See, MTproto
| is bad like we said all along!" without reading anything. Good
| research, bad article?
|
| <<Obligatory notice in Telegram comment threads: the real issue
| in Telegram is that end-to-end encryption is optional and made
| extremely inconvenient to use: no implementation at all in
| TDesktop, can't use it across multiple devices, doesn't work for
| group chats at all... _That_ is the main reason Telegram isn 't
| secure: they can read all your chats except when you use this
| stupid inconvenient mode.>>
| alerighi wrote:
| > can't use it across multiple devices
|
| The reason is that. You have to choose between something you
| can use from whatever device you want, that you can simply log
| in into a web interface on whatever computer, or end2end
| encryption.
|
| Telegram made a choice of usability, you are able to use
| Telegram from whatever device, mobile app, desktop app, web
| app, smartwatch app, command line client, third party clients,
| without any problem, notifications arrive on every device, you
| can start a conversation on one device and continue it on
| another, they are synchronized in real time.
|
| It's in theory less secure? Yes, since whoever has access to
| Telegram servers can in theory read your messages. Is it in
| practice a problem? No, it's not. Telegram doesn't, as far as
| we know, give access to government or other third parties to
| the data of the users. WhatsApp does for example, not for the
| message content but for the metadata (that they can read). What
| is more secure, in the real world and not in theory?
|
| Signal is more secure, yes, but it's more inconvenient that
| both Telegram and WhatsApp. I prefer a convenient and slightly
| less secure messaging service than a super secure one (in
| theory) but inconvenient to use.
| LordDragonfang wrote:
| >You have to choose between something you can use from
| whatever device you want, that you can simply log in into a
| web interface on whatever computer, or end2end encryption.
|
| >Telegram made a choice of usability
|
| Bullshit. Plenty of services have e2ee _and_ cross-device
| usage. All you need for multi-platform e2ee is to sync an
| encryption key across devices. Either through a "trusted"
| party (like iMessage) or by literally syncing the key locally
| (Signal). You can even have one device act as the message
| store so you don't even keep store the encrypted messages in
| the cloud.
|
| Telegram did not choose usability, they chose the opposite.
| snotrockets wrote:
| iMessage doesn't share private keys between devices. Each
| device has its own secret key, and when you send a message
| to a person with multiple devices, you encrypt multiple
| copies, one for each (source:
| https://support.apple.com/guide/security/how-imessage-
| sends-...)
|
| An issue here is that the software doesn't show the user
| the list of keys used to encrypt a given message. If an
| attacker can inject their own keys into the identity
| service records for a given user, they would then receive a
| copy of all messages sent to that user.
| maqp wrote:
| It's true iMessage is not safe from such attacks, but you
| don't have to look further than Signal to see it's
| possible to create multi-device E2EE with seamless sync.
|
| iMessage and its bad design can only serve the function
| of red herring here, let's leave it out from the
| discussion.
| maqp wrote:
| >You have to choose between something you can use from
| whatever device you want
|
| You're being disingenuous. End-to-end encrypting every 1:1
| chat by default, as well as end-to-end encrypting <1000
| member groups have already been shown to be possible by
| Signal, WhatsApp, Wire, Element etc.
|
| Telegram is saying "fuck security" to gain competitive edge
| with message latency. They have no idea how dangerous game
| that is.
|
| >Telegram made a choice of usability
|
| Insecure features are not usable features because security is
| the fundamental attribute of EVERY feature. Telegram has
| footguns, nothing more.
|
| >"Is it in practice a problem? No, it's not"
|
| And what credentials do you have to make such assertions?
|
| >Telegram doesn't, as far as we know, give access to
| government or other third parties to the data of the users.
|
| Considering the fact Telegram lacks the know-how to implement
| secure protocols (see OPs article) what chance is there they
| can defend against EVERY zero day exploit against their
| server infrastructure? Telegram most likely would never even
| know they were hacked. And the intelligence agencies that
| have owned their systems aren't bragging. And even IF
| Telegram would detect such attacks, would they disclose it,
| when they know they lack the know-how to prevent the next
| exploit, i.e. the know-how on how to deploy E2EE for
| everything.
|
| >Signal is more secure, yes, but it's more inconvenient that
| both Telegram and WhatsApp.
|
| You can't be serious. Let's take the most basic possible
| convenience feature. I chat with my buddy over E2EE 1:1 chat
| while riding the bus to work. At work, I sit down in front of
| my computer, and want to continue the conversation using
| keyboard. Signal allows me to do that with zero hassle,
| Telegram forces me to drop end-to-end encryption.
|
| Telegram's convenience is an outright joke. The moment you
| want flexibility without losing security, it's garbage. We
| can thus argue Telegram strongly incentivizes insecure use
| (come on, just let us see your messages), because nobody, is
| going to unlock their phone hundreds of times a day to reply
| to the chats.
| lucb1e wrote:
| If you can have encrypted group chats, then clearly you must
| be able to join and synchronize an encrypted conversation
| with more than one device. Encrypted group chats exist in
| Signal and other applications, so clearly this is possible.
|
| (There are other mechanisms (to have encrypted group chats)
| than just pretending each device is a separate chat member,
| but I thought this was an intuitive way to understand how
| that could securely work.)
|
| Regarding giving metadata to governments: I want that. If
| someone commits a crime, then sure the government should be
| able to request the data on this person (it might exonerate
| them or implicate them, though of course it's only ever
| supportive and never a sole reason to convict). The
| governments that most people here chose are not evil. Dragnet
| surveillance is not good, but individual data requests for
| individual persons after a judge approved it? That makes
| sense to me, at least from the perspective of the
| Netherlands. If Telegram doesn't comply with these requests
| (and that's a big _if_ , because I heard otherwise), it would
| be a reason why democratic country might rightfully ban
| Telegram.
|
| But anyway that's perhaps a more political discussion rather
| than technical. Telegram has the data, just like every other
| centralized platform either collects or can be forced to
| collect it.
| jjav wrote:
| > Is it in practice a problem? No, it's not.
|
| This is not an assertion you can make. Because:
|
| > Telegram doesn't, as far as we know, give access to
| government or other third parties to the data of the users.
|
| Approximately every country (probably every, but haven't
| researched them all) has various court order types to go get
| this information and force secrecy on whoever is involved.
| Thus any information which is available to a company is
| equally available in secret via court orders. Nothing they
| can do to prevent it or tell you.
| thayne wrote:
| > Telegram doesn't, as far as we know, give access to
| government or other third parties to the data of the users.
|
| Just because we don't know that they do doesn't mean that
| they don't, or won't in the future.
|
| And even if they do do their best to keep messages private,
| what if their servers are compromised, or they are served a
| warrant?
| enkid wrote:
| From what I've seen of this type of research, a vulnerability
| like these may be worked on and some one will refine it to make
| it exploitable, so even if it's not possible to use it in it's
| current form, it's important to be aware to prevent future
| attacks.
| okdjnfweonfe wrote:
| https://signal.org/docs/specifications/doubleratchet/#out-of...
| lucb1e wrote:
| i.e. messages can be out of order, so no transcript
| consistency, is that what you're saying?
| tsegers wrote:
| I think that the linked article described that messages
| that arrive out of order can still be decrypted despite the
| decryption keys being generated in a strict order. As far
| as I know, the order of the keys that are used to decrypt
| incoming messages also indicate the order in which the
| decrypted messages were sent.
| joecool1029 wrote:
| So would a potential fix be just to add some metadata in
| the message somewhere that says when it was sent?
| stryan wrote:
| >Do Signal, Wire, or Matrix do this transcript consistency
| thing, or is there some other way by which they prevent message
| reordering?
|
| Rooms in Matrix are directed graphs[0], so if I'm understanding
| right, transcript consistency should be the default.
|
| [0] https://matrix.org/docs/spec/#id14
| perardi wrote:
| Mm-hmm.
|
| iMessage and WhatsApp are encrypted "out of the box"--it's the
| default. Telegram requires an explicit choice.
| codedokode wrote:
| Unlike Telegram, iMessage and WhatsApp are closed source
| apps. How can you verify that they really encrypt the
| messages?
| maqp wrote:
| Here's the thing. There's perhaps a 0.0001% chance that
| iMessage or WhatsApp contains a backdoor that does not
| really encrypt a message.
|
| There's a 100% chance that every cloud message, every
| Windows/Linux desktop message, and EVERY message by
| default, is sent to Telegram servers, where the vendor, and
| any intelligence agency, organized crime unit etc., can
| steal them from. Telegram is a for-profit company. It can
| also be sold, and that will include billions of messages
| stored on their server. The only thing stopping them from
| selling out is "they don't feel like it".
|
| Telegram is not backdoored, but, it is proven to be
| frontdoored, and this is extremely dangerous because "it's
| nothing new, we knew this, it's obvious". Yes. It's
| blindfully obvious to your average crypto anarchist who's
| spent a year reading about cryptographic protocols. It's
| anything but obvious to your average user.
|
| To give some idea, I did a survey at my university computer
| science department: the students have lots of Telegram
| users. These students study cryptography as part of their
| network course, number theory course, and there's even a
| grad-level cryptography course run by Valtteri Niemi.
| Here's what I found: less than 20% even knew what secret
| chats were, let alone used them. Everyone just winged it,
| assumed Telegram was safe by default. Now, if a computer
| science student body whose field this is don't know about
| it, what chance is there a hair stylist, a political major,
| a dissident/activist, or journalist, knows about it.
|
| But I can't blame them: I've long since lost the count of
| how many times I've seen news media bundle apps together:
| "Signal, Telegram, Threema ... are secure replacements for
| WhatsApp". This kind publishing is incredibly
| irresponsible, and it's no wonder people get the wrong
| idea.
|
| So yes, Telegram is open source with reproducible builds.
| But that confirms nothing but the existence of the front
| door to technical people, that the app doesn't end-to-end
| encrypt anything, by default.
| BelleOfTheBall wrote:
| A 0.0001% chance that a Facebook product has backdoors to
| spy on people? I see that you have a real hatred of
| Telegram but come on, this is such a biased take. You are
| willing to protect a closed-source app from Facebook just
| because you hate the alternative so much. You are not
| helping anyone with this.
| maqp wrote:
| >A 0.0001% chance that a Facebook product has backdoors
| to spy on people?
|
| Yeah, I have never ever heard anyone MITM attacked WA
| user, and I have never seen any claims the app leaks
| plaintext data or keys to server or third parties. If you
| have some factual information instead of "hunch", then by
| all means, lets hear it. I'm not arguing Facebook isn't
| abusing WhatsApp metadata like there is no tomorrow. They
| absolutely are, and often metadata is more revealing than
| the content. I'm not saying WhatsApp is secure enough,
| I'm saying it's better than Telegram. Consider group
| messages:
|
| Telegram spies on user's group messages with 100%
| probability. Therefore, WhatsApp can be at most as
| insecure as Telegram. But if even if there's 99.9999%
| probability that WA is backdoored, it's still better odds
| than Telegram.
|
| If you think WhatsApp can't be trusted because it's
| proprietary and you have to trust the vendor, then you
| absolutely can't say Telegram is safe, because you have
| to trust the vendor not to look at the group messages.
|
| So it boils down to what is the actual probability that
| WA is backdoored, the number is not zero, but it most
| certainly is not 100%. If you have useful factual
| information that overrides Moxie personally telling me
| that he oversaw WA implement the Signal protocol, I'm
| willing to update my threat probability estimates, but
| until then, I'm going to stick with saying it's highly
| improbable.
|
| >I see that you have a real hatred of Telegram but come
| on, this is such a biased take.
|
| I have nothing personal against Telegram. I've researched
| private messaging apps for closer to 10 years, and I'm
| only interested in all apps improving. But Telegram isn't
| in the process of locking themselves out of user data,
| but on the contrary, even the new features, like the
| group video calls, are collecting 100% of metadata AND
| content. Telegram isn't helping the world, it's amassing
| terabytes of data into a silo that's one zero-day away
| from the biggest breach in modern history.
|
| Here in Finland we've recently had some taste of it when
| the Vastaamo psychotherapy center was hacked.
| https://www.wired.com/story/vastaamo-psychotherapy-
| patients-... Read it. Then realize Telegram private chats
| can contain messages people wouldn't share with their
| therapists. Imagine tens of millions of extortion cases
| (that never end, even if you pay), ruined lives,
| relationships etc.
|
| The Telegram Hack of 20** is not going to be just another
| hack, it's going to be the scandal of the century.
|
| > You are willing to protect a closed-source app from
| Facebook
|
| No, I'm not protecting anyone here, I'm making the
| distinction that the backdoor is very improbable, because
| a) Facebook doesn't need it due to the metadata and b)
| Eavesdropping on your users via backdoor is a felony.
| Compare that to Telegram where the users send practically
| everything to the server willingly. There is zero
| expectation of privacy the user can ask.
|
| >you hate the alternative so much
|
| Telegram is not "the alternative", it's "out of the
| frying pan, into the fire". As you can see my every post
| here argue.
|
| There are plenty of open source, secure alternatives like
| Signal, Element, Wire, Threema, Briar, Cwtch, OnionShare
| Chats etc.
| meowface wrote:
| I wouldn't quite put it at 0.0001% like that poster did,
| but I think I'd put it at 0.001%. I think backdooring
| end-to-end encryption would be going too far, even for
| them.
|
| If discovered, I think it would hurt them far more than
| any other scandal. Legally, financially, and PR-wise. You
| might say: "they've had a bajillion scandals and no one
| gave a shit and nothing happened to them; why would this
| one be any different"? Because it's a different category
| of deception and malevolence. I'm not sure if it'd kill
| the company, but it'd be one of the biggest tech scandals
| in decades, I think.
|
| I have never used Facebook and never will (and have used
| WhatsApp a few times but wouldn't do so again), but I'd
| bet almost anything that that poster is absolutely right
| and that by any standard measure, 90 - 99% of people
| would be _much_ more secure using WhatsApp than Telegram,
| despite that conclusion being the exact opposite of one
| would otherwise expect (Facebook-owned closed source app
| vs. some random company 's open source app).
|
| Of course, the true recommendation is Signal, which is
| surely much more secure than both, but if we're just
| comparing purely relatively, then I think WhatsApp is
| extremely likely to be far more secure than Telegram.
|
| Yes, that's how utterly absurd this situation is. That's
| why security experts and cryptographers have shat on
| Telegram non-stop for so many years. The story here isn't
| that WhatsApp is some secure thing you should use. It's
| that Telegram is so shitty it's actually somehow managed
| to be way less secure than fucking _WhatsApp(r) by
| Facebook(r)_ from 2016 until now. The outrage should be
| directed at Telegram. Not at people who point out that,
| unbeknownst to most users, it 's actually less secure
| than a closed source Facebook app, of all things.
|
| "Zoom lied and explicitly, falsely labeled their calls as
| end-to-end encrypted in the UI, their site, and their
| whitepaper despite the fact that they weren't E2EE
| whatsoever, and they were just given a warning by the FTC
| and not even fined." True. But, while this certainly was
| incredibly shady, it seems to me more like shitty
| marketing/misleading advertising. When journalists asked
| them about it, they said calls weren't actually end-to-
| end encrypted between users, and only between "Zoom
| servers". It's not really a backdoor if they immediately
| give you all the real details when you ask them.
|
| Meanwhile, Facebook have been very adamant about the fact
| that WhatsApp messages are supposedly truly end-to-end
| encrypted. This wouldn't be misleading advertising or
| misuse of technical terminology; it would be pure
| skullduggery, and probably felonious.
|
| And, again, I am truly not trying to defend WhatsApp, and
| I hate Facebook and will never use them. I'm just
| surprised that anyone would defend Telegram on this
| point. WhatsApp isn't good; Telegram is just so bad that
| it's actually worse than a closed source Facebook app.
| Retric wrote:
| Decompile and read the resulting source code, then snuff
| the network traffic to make sure it's matching what's
| expected. Trusting the Hardware and OS is a larger issue.
| faeyanpiraat wrote:
| *sniff
| lucb1e wrote:
| People always take that lightly, as if it's trivial to
| read bytecode (tptacek takes that stance a lot if I
| recall correctly, and his being him, people take it for
| gospel). Just looking at the underhanded C (style)
| contests, it's not trivial to spot backdoors in the
| source code, let alone the code that a machine is meant
| to interpret after it ran through a compiler. If it were
| so trivial to find the flaws that allow attacks in the
| easiest-to-read of code (open source, docs available,
| mitigations applied, nice choice of language,
| everything), we would not have security issues in good
| software in the first place.
| martinralbrecht wrote:
| See Appendix C of https://mtpsym.github.io/paper.pdf (the
| underlying research paper). Reordering of messages (in one
| direction) and "causality preservation" (both directions) are
| two different things.
| eitland wrote:
| > Obligatory notice in Telegram comment threads:
|
| Sadly, obligatory notice in Telegram threads:
|
| Telegram is encrypted by default and has always been unlike a
| certain big competitor that has been pushed here.
|
| The issue isn't if it is encrypted but if it is end to end
| encrypted and also the quality of the encryption.
|
| Saying it is not encrypted is directly misleading.
|
| Your point that they can read your messages if they want still
| stands.
|
| This however is also true for mail, banking and about
| everything else except the most secure instant messaging
| networks.
| axaxs wrote:
| Encrypted, as it's used with messengers, means E2E encrypted.
| Anyone who is calling Telegram 'encrypted by default' while
| technically correct, is being very, very misleading.
| eitland wrote:
| Well, calling it "unencrypted" is equally misleading
|
| ... and technically wrong as well.
|
| In a somewhat technical community we should strive to
| communicate correctly and not invent new meanings for well-
| defined terms.
|
| By all means come up with a new nasty sounding term, but
| don't lie and excuse it with "it means something else now",
| that is borderline childish/sleazy salesman-ish.
| maqp wrote:
| > Well, calling it "unencrypted" is equally misleading
|
| Encryption implies it protects message content from third
| parties. Show me someone who agrees its bad if the third
| party is some random guy from ISP, but it's good if its
| some random guy from Telegram LLC.
|
| Telegram is effectively unencrypted, because the messages
| are by default readable by someone else, like is the case
| if there was no encryption at all.
|
| Third parties are not just your average script kiddie
| capturing packets at your internet cafe, third parties
| are also everyone who hacks Telegram server, every
| intelligence agency that hacks Telegram servers, and a
| possible parent company that buys Telegram.
| lucb1e wrote:
| > Show me someone who agrees its bad if the third party
| is some random [girl] from ISP, but it's good if its some
| random [girl] from [service operator].
|
| DoH
| maqp wrote:
| Oh apologies, I didn't want to be gender exclusive here.
| lucb1e wrote:
| > Saying it is not encrypted is directly misleading.
|
| Sorry, that's my bad. I edited the message to clarify that I
| meant end-to-end encryption, since Telegram's implementation
| (mtproto) of e2ee is the topic of this submission.
|
| > also true for mail, banking and about everything else
| except the most secure instant messaging networks
|
| That is indeed the state of things. People like the
| convenience though: imagine you could only retrieve your data
| from Protonmail by knowing the encryption password. People
| would irrecoverably lose all their emails on a regular basis.
| Banking makes less sense though, since the bank needs to know
| how much money you have to be able to give some of that money
| (per your instruction) to e.g. merchants. Websites can be end
| to end encrypted, if the endpoint is owned by the person
| you're trying to reach. Cloudflare's "TLS MITM as a service"
| (and similar offerings) undermine that, but if you go to
| https://lucb1e.com then your traffic is end-to-end encrypted
| to me. If you want, we can also verify fingerprints out of
| band, just like you should with encrypted chats to make sure
| you're not trusting the server (or in this case the signing
| authorities)!
| toast0 wrote:
| > Do Signal, Wire, or Matrix do this transcript consistency
| thing, or is there some other way by which they prevent message
| reordering? From what I know, encrypted messengers almost never
| implement that. At least in Wire I noticed reordering at some
| point and it uses an implementation of what is now called the
| Signal protocol.
|
| If I'm reading this right, the issue is that a network MITM can
| reorder the messages in the client to server connection
| (without being able to read them). This would likely reorder
| messages in the chat transcript too, but that's a different
| issue.
|
| TLS or Noise protocol are open alternatives here, and IIRC both
| require that you have received all previous packets in order to
| validate a new packet, which means either you've received all
| the packets in order or the MITM has compromised the handshake.
|
| Signal protocol is the end to end protocol between clients;
| those messages do not require reception in order. Because the
| messages go through a server and may be retried, there's lots
| of ways things could go wrong and some messages may be dropped
| or delayed and can arrive out of order. You could refuse to
| display message N until you've displayed N - 1, but if the
| server dropped N for whatever reason, you need to get the
| sender to resend it, and that depends on availability of the
| sender which is limited (their phone may be off, out of
| coverage, or execution may be denied/delayed by the OS, or the
| user may have removed the app by the time the receiving app
| notices the message is missing, etc).
| JulianMorrison wrote:
| Generally, the thing with cryptography is the first breaks tend
| not to be useful. Crafted messages, terabytes of data, a
| compromise in one round of several in the key, etc. Theoretical
| stuff.
|
| But they then tend to get worse rapidly, building on those
| useless cracks to drive the wedge deeper. And so in general
| it's best to assume that if something's slightly broken, soon
| it will be all the way broken.
| api wrote:
| AES has been broken for over a decade. 256 bit AES is
| actually only 255 bits strong. It has not progressed any
| further, and AES is the most popular algorithm globally and
| has had over two decades of eyes on it.
|
| This definitely is not generally true, especially for
| "academic breaks" that don't even approach feasibility.
|
| I really think security people fear the wrong things. Unless
| they are fundamentally flawed very few actual crypto breaks
| happen in practice. Most real world breaks are the result of
| implementation bugs, side channel attacks, and social
| engineering.
|
| If I had to choose between a buggy code base implementing
| Noise with the latest hipster crypto and a well written
| memory safe audited code base and protocol using RSA-1024 and
| RC4, I would feel safer with the latter. (Unless my adversary
| were the NSA or someone else at that level, in which case I
| would layer three or four systems for defense in depth.)
|
| This is not an argument for the use of weak crypto. It's an
| argument for fearing the implementation, deployment, and
| users more than the crypto.
|
| Big blobs of C are scary regardless of what they implement,
| especially if they are messy and have not had many eyes on
| them. The meat bag in front of the computer is usually the
| least secure component. If you look at real world breaks it's
| usually bad opsec or phishing. The hipsterest crypto won't
| help you if you are tricked into running malware or you have
| an insecure PHP script on a web server.
| martinralbrecht wrote:
| RC4: https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
| #Weak_...
| api wrote:
| Point taken. I may have reached for too extreme an
| example, but AFAIK there were other issues with the WEP
| construction besides just RC4 being weak.
|
| I think the point still stands though. When I read about
| breaks (and when I saw them back when I did infosec) it
| was phishing most of the time. Someone would be tricked
| into running malware. That's how most organizational
| compromises happen. The rest were memory errors like
| buffer overflows in non-security application code and
| bugs in bespoke code exposed to the Internet.
|
| My point was that people are afraid of the things that
| are sexy to be afraid of, and tend to ignore the more
| mundane but more commonly attacked vectors.
|
| The same applies to firewall obsession in netsec. People
| will obsess over the firewall and then type "npm install"
| on production systems. It's not sexy to worry about that.
|
| Package managers scare the shit out of me...
| Siira wrote:
| Care to give some sources for this claim? Even with some
| examples, it seems very vulnerable to the survival bias
| (examples where small flaws did not lead to a big blowdown
| are not paid attention to).
| lucb1e wrote:
| They're not wrong in principle: attacks do often start as
| implausible and then some other shortcut or weakness is
| found and bam, there is a realistic exploit out of
| something that was deemed completely infeasible.
|
| I think in this context, it's a bit more nuanced. These
| shortcomings are fixed (I can't personally vouch for the
| correctness of the fix as I haven't looked at the source
| diff, but let's assume it's solid), so they're not left to
| linger and build on. There was also a more serious bug in
| the past though I forgot the details. If this is the worst
| they're finding now, I'm not so worried. What I hear of
| mtproto doesn't sound like bugs are compounding but rather
| like they're ironing our small (but not completely
| unimportant, of course) flaws. But of course we won't truly
| know if it's secure until someone finds a devastating
| attack.
| martinralbrecht wrote:
| > As an aside, Jakobsen and Orlandi wrote: "We stress that
| this is a theoretical attack on the definition of security
| and we do not see any way of turning the attack into a full
| plaintext-recovery attack." Similarly, the Telegram "FAQ
| for the Technically Inclined (MTProto v.1.0)" provides the
| following analogy: "A postal worker could write 'Haha'
| (using invisible ink!) on the outside of a sealed package
| that he delivers to you. It didn't stop the package from
| being delivered, it doesn't allow them to change the
| contents of the package, and it doesn't allow them to see
| what was inside." In hindsight, we think that this is
| incorrect. As explained above, our timing side channels
| essentially exploit this behaviour in order to do message
| recovery (but we need to "chain" two "exploits" to make it
| work, even ignoring practicality concerns).
|
| https://mtpsym.github.io/
| kortilla wrote:
| That isn't really the case. Sha1 still isn't broken in a
| particularly useful way. Md5 is still basically safe from
| pre-image attacks.
| maqp wrote:
| This is quite disingenuous, as with hash functions there's
| infinite preimages that map to each digest.
| martinralbrecht wrote:
| https://shattered.io/
| woodruffw wrote:
| SHAttered is a collision attack on SHA-1, not a pre-image
| attack. There is no known pre-image attack for SHA-1.
| wizzwizz4 wrote:
| Yet. We get closer every time a new vulnerability is
| discovered.
| tyrion wrote:
| It is tiring that this keeps happening. These media outlet
| publish misleading titles and abstracts implying that Telegram is
| not secure, knowing very well that most people don't even read
| the articles. I assumed good faith for the first ~100 times, but
| it is always the same :D
|
| Anyway, wouldn't it be better to link to the academic source (
| https://mtpsym.github.io/ ), or at least to remove click bait
| titles?
| maqp wrote:
| It's tiring to see people claim Telegram is Secure e.g.
| "because it hasn't been hacked yet" :D These people don't
| realize Telegram is front doored by design, it leaks 100% of
| your chats to Mark Zuckerberg of Russia, just like Facebook
| Messeger leaks 100% of its messages to Mark Zuckerberg of USA.
| tyrion wrote:
| I did not claim Telegram to be secure. It has nothing to do
| with what I said. Moreover, saying that something "is secure"
| does not make too much sense, without specifying secure
| against what.
|
| Assuming you are in good faith, I will try to explain better:
| The title of the article states there are _vulnerabilities_
| in the _encryption protocol_.
|
| According to RFC 4949 a vulnerability is:
|
| > A flaw or weakness in a system's design, implementation, or
| operation and management _that could be exploited to violate
| the system 's security policy_.
|
| Clearly stating that there are vulnerabilities in Telegram's
| encryption protocol raises concerns, a lot of confirmation
| bias among Telegram haters, and leaves people who only read
| the titles with the feeling that Telegram encryption is
| vulnerable to attacks.
|
| However, among the 4 flaws reported by the researchers, 3 are
| not exploitable ("This attack is mostly of theoretical
| interest", "Luckily, it is almost impossible to carry out in
| practice", "Luckily, this attack is also quite difficult to
| carry out, as it requires sending billions of messages to a
| Telegram server within minutes") and the other one is about
| reordering encrypted messages.
|
| Therefore, a more fair headline which would undoubtedly raise
| less interest could be "Researchers found a way to change the
| order of your Telegram messages, even if they still cannot
| read them", or "Researchers found some purely theoretical or
| almost impossible to carry out vulnerabilities in Telegram's
| encryption protocol".
|
| And don't even get me started about the fact that literally
| everybody, including expert security researchers, feel
| entitled to bash Telegram for having rolled their own crypto
| at every chance they get.
| maqp wrote:
| >leaves people who only read the titles with the feeling
| that Telegram encryption is vulnerable to attacks.
|
| I agree with you these attacks are not so severe the
| completely broke Telegram. But it is living proof Telegram
| authors don't have the know-how on how to implement secure
| protocols. If you heard some bridge builder had replaced
| every third bolt with fifty zip-ties, you wouldn't be
| defending the bridge, you'd want to know who the f is
| overseeing that project, and ensure the entire design was
| being reconsidered, and that qualified engineers were
| working on the fixes.
|
| This set of vulnerabilities isn't an indication that
| Telegram's encryption is bound to have a breaking
| vulnerability. It's saying they don't have the
| qualifications to protect the data we know sits in their
| server effectively plaintext. And I'm saying effectively,
| because sure, it's encrypted, but the database key sits in
| the RAM, 4cm away from the CPU, and is one privilege
| escalation vulnerability away from compromise.
|
| You using the term "Telegram hater" does disservice to
| everyone, because your lumping together people with no tech
| background parroting headlines, and legitimate concerns
| from people who've actually spent time looking into this on
| a technical level.
| tyrion wrote:
| > But it is living proof Telegram authors don't have the
| know-how on how to implement secure protocols
|
| I strongly disagree with this claim. Can you back your
| claim with some evidence? The vulnerabilities shown here
| are mostly purely theoretical, I don't see how this goes
| to show that Telegram engineers are incompetent.
|
| What I see is that Telegram engineers chose to ignore
| what the Computer Security academic community regards as
| best practices, and this has led to an infinite amount of
| criticism (including by the authors of the
| vulnerabilities we are discussing). Despite this, in ~8
| years since launch, the only serious vulnerability which
| I am aware of, has been discovered and immediately
| patched right after Telegram was first launched.
| maqp wrote:
| >I strongly disagree with this claim. Can you back your
| claim with some evidence?
|
| Absolutely. Telegram isn't end-to-end encrypted by
| default. The author admits so here:
| https://telegra.ph/Why-Isnt-Telegram-End-to-End-
| Encrypted-by...
|
| Q.E.D.
|
| This set of 4 vulnerabilities isn't the issue with
| Telegram. Vulnerabilities can often be patched. The issue
| is the fundamental way Telegram functions.
|
| Also, since you're obviously going to claim the article
| justifies it as a design decision, read my refutal here
| before replying https://telegra.ph/Why-you-should-stop-
| reading-Durovs-blog-p...
|
| Finally, I'm a bit puzzled, you seem to be "open minded"
| yet your post didn't even touch on this massive issue of
| failure to provide E2EE for groups, desktop clients, or
| anything by default. Were you unaware of it? Or would you
| argue the endless list of competition that actually does
| E2EE properly (Signal, Wire, Threema, Element...), over-
| do security?
|
| You're also not even remotely interested in agreeing with
| the academic community, but instead just observe and
| basically imply: "no breaches have been made public,
| therefore it must be secure". How familiar are you with
| the field of computer security, do you know how security
| is quantified?
| raziel2p wrote:
| The Telegram team's response to this isn't very encouraging:
| https://telegra.ph/LoU-ETH-4a-proof-07-16
|
| They don't seem to go into technical details, relying on
| analogies like bags of sand - maybe this is comforting enough to
| the general public, but I'm skeptical.
|
| I didn't read the technical details of the exploits though, so
| Telegram might be entirely in the right to be so dismissive.
| capableweb wrote:
| Here is the comments from the Telegram team for the technically
| inclined: https://core.telegram.org/techfaq/UoL-ETH-4a-proof
|
| Linked in the third paragraph of the submission:
|
| > The researchers also highlighted several traits of MTProto
| that were changed as the result of our discussions before the
| paper was published. This document provides an accessible
| overview of these changes. For more technical details, see
| here.
| mirekrusin wrote:
| Why you're saying this? Bags of sand is fantastic analogy, no?
| eitland wrote:
| I don't like the way they communicate regarding security, but
| for context: So far there has been an extreme amount of FUD
| thrown their way from people who pushed WhatsApp and Signal.
| teawrecks wrote:
| > from people who pushed WhatsApp
|
| So Facebook?
| eitland wrote:
| No, I'm thinking about well meaning security people who
| focused a bit too much on E2E-encryption and forgot that
| WhatsApp sent metadata in bulk to Facebook and uploaded
| backups unencrypted to Google and/or iCloud.
| Ar-Curunir wrote:
| As opposed to Telegram, where chats are unencrypted by
| default, and synced to the cloud?
| eitland wrote:
| are we a community of technical people or sleazy sales
| people?
|
| What you say about being synced to the cloud in a way
| that can be decrypted is correct and can be problematic
| for some people but calling it unencrypted is wrong and
| detracts from your message.
| maqp wrote:
| Saying the database is encrypted when the database key
| has to sit in the RAM of the server is as disingenuous as
| saying this is proper way to lock up gems:
| https://i.imgur.com/0gBOPoQ.png
|
| You're basically arguing that "you can't say it's not
| locked when the lock is right there"
| Dah00n wrote:
| Your comment says nothing about what GP actually stated.
| maqp wrote:
| Calling Telegram unencrypted isn't practically wrong when
| the key is stored right next to the data.
| maqp wrote:
| >forgot that WhatsApp uploaded backups unencrypted to
| Google and/or iCloud.
|
| This might finally get fixed:
|
| https://www.theverge.com/2021/7/16/22580800/icloud-
| google-dr...
|
| Great news because it disproves Durov's BS that claims
| you can't have backups without giving the vendor the
| access.
| joecool1029 wrote:
| > I don't like the way they communicate regarding security
|
| In general they are cocky but in an expressive way. It is
| heartening that when papers like this are published they fix
| the issues despite the PR spin. I've had one email thread
| interaction with Telegram and it was to unban my account that
| got banned for messing around with old clients, I can't say
| they were pleasant but they did answer many of my questions.
|
| >So far there has been an extreme amount of FUD thrown their
| way from people who pushed WhatsApp and Signal.
|
| Signal's people did not inform their Android users of the
| potential for backdoored IME's in places like China for over
| a year (thankfully their site does mention it now). It was
| telling that the app was available and usable there until
| word got out that this was a very obvious/easy surveillance
| target for such regimes. Personally I think it's possible the
| Signal Foundation was under a gag order and could not report
| on this. But I would not rule out cockiness in their own way,
| to date I've never received a single response to the most
| basic of questions (back when I was an active user/promoter
| of their apps) from any of their team dating all the way back
| to Textsecure days.
|
| HN discussed the IME issue around 6 months ago:
| https://news.ycombinator.com/item?id=25758995
| isatty wrote:
| I would like you, or someone more knowledgeable in the field to
| argue that the response is not accurate:
|
| > Re-ordering
|
| Exposed no information about the plaintext and needs additional
| work to become a fully fledged exploit, patched anyway.
|
| > Re-sending: This is a purely theoretical point that has no
| bearing on the security of messages but is inconvenient for
| researchers who want to formally analyze the protocol.
|
| Researchers being able to analyze the protocol to find faults -
| good thing. But can't this also work against people trying to
| break the protocol?
|
| > Implementation problems - "For an analogy, imagine a door
| with multiple locks, one of which could be unlocked -- the door
| to your messages could still not be opened because it had more
| than one lock"
|
| I think this contradicts with the summary above, which is
| "recover some plaintext", which does not make sense given the
| analogy. Can someone explain? Possibly the only serious issue
| found.
|
| > RSA Decryption: "This may sound scary but was not possible in
| practice"
|
| If it's not possible in practice that seems like a bunch of
| other well established crypto protocols I know where it's just
| infeasible to brute force with currently available non state
| resources.
| martinralbrecht wrote:
| 1. Re: "needs additional work to become a fully fledged
| exploit": We have verified this attack in practice, see the
| paper.
|
| 2. We give an example application where it has some "bearing
| on the security of messages" at the end of
| https://mtpsym.github.io/ under the heading "Did we really
| break IND-CPA?" and in the paper.
|
| 3. Perhaps a better analogy is: the remaining door requires
| the date of birth but luckily they kept that secret. But
| analogies aside: "Luckily, it is almost impossible to carry
| out in practice. In particular, it is mostly mitigated by the
| coincidence that certain metadata in Telegram [a salt and an
| id] is chosen randomly and kept secret."
| https://mtpsym.github.io/
|
| 4. By cryptographic standards the strongest attack as it
| would imply full compromise if successful. It costs in the
| order of 2^32 noise-free queries within minutes where it is
| not clear how many noisy queries are needed to get "one
| noise-free query" since we didn't want to test it against
| Telegram's servers. This falls significantly short of "well
| established crypto protocols [...] where it's just infeasible
| to brute force" NB: these provide guarantees also against
| state resources. This does not mean it is a practical
| concern.
|
| The key contribution of our paper, however, is that we prove
| that MTProto's symmetric cryptography (with some fixes and
| when implemented carefully) can give you something comparable
| to TLS (well, it's Record protocol) which is it's closest
| "competitor".
|
| This proof comes with some caveats, though: MTProto is tricky
| to implement correctly (as highlighted by our attacks on the
| official clients). Secondly, MTProto relies on unstudied
| assumptions that you do not need to make if you use just TLS.
| See "A Somewhat Opinionated Discussion" at
| https://mtpsym.github.io/
___________________________________________________________________
(page generated 2021-07-18 23:00 UTC)