Discussion Telegram

Discussion in 'Security Discussion' started by RSX, Dec 31, 2016.

  1. RSX

    RSX Member

    (Draft - will be edited shortly)

    First of all, yes, this is starting due to this almost slanderous thread, whereas one of the admins seems to think telegram is insecure due to 'personal beliefs' and 'trust'. Nothing against Derp, I just find it a little bit silly. This is the article in question. As one can see, it's pretty stupid in a sense of some special snowflake professors, who for the record should be teaching kids about cryptography, is condemning people from writing their own crypto algorithms, or even implementations, (this part is unclear)(*1). Although, what is clear is that none of those clowns have actually looked into the source and algorithms before commenting, which lead gizmodo on to slandering telegram on the bases of their quotes and 'omg online presences are public info'. Whilst nobody's denying there may or may not be issues that existed when that article was first published, it's almost a year old, and I've found pretty much nothing that seems to be a sensible issue back then. That said, let's ignore ignorant professors who haven't looked at it, and do something noteworthy for the r4p3 community in this year of 2017.

    Deprecated research:
    Most of these claims and documents are vastly out of date (over a year old deprecated), and as telegram is an actively developed application, they SHOULD have moved on and fixed said issues. Empathizes on 'should' as I don't want any of y'all to be getting upset when you find that an old issue is still a critical occurrence that remains to date.

    The goal:
    Let's take a look at what telegram is, it's an 'encrypted' instant messaging platform, so let's find something that hurts such claim. Either obtain something that shouldn't be in the public eye within the protocol OR break the encryption algorithms in place, authentication flow, or otherwise to get plain text messages. Let's not mindlessly slander a platform we can't break :(

    Ideal (and no so ideal) POCs:
    > MITMS (don't worry about how traffic flows to them yet. once a virus or w/e get's on someones machine/network, that isn't an issue)
    > Nothing that requires user interaction
    > Nothing that requires (physical or not) access to the computer that has the telegram target client
    > Something small that can lay on someones network without being detected

    F$ck you, wheres teamspeak stuff?
    I'll post a traffic decrypter that gives you raw waves, commands, and crypto keys later this week.

    *1: https://reece.sx/goCvUnouihBnPuF Granted, he does say considerable experience, but I doubt any student of his falls in that category, and you've gotta start somewhere. Whilst you will be laughed at for pushing rubbish into production, there's zero reason for him to condemn such academic behaviors.

    Legal note: sending malicious payloads may be illegal. blah blah blah. the fbi party van might be outside
    Some sources that may be of help: https://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/, TODO
    Misc notes: this post is subject to change. it's more or less a draft with a fair few grammatical errors
  2. RSX

    RSX Member

    Reserved for links to noticeable sources and posts (if any)
  3. Derp

    Derp TS3 Dev-Team WebApp Dev-Team Contributor

    Note: Long reply

    1) Backstory
    Okay, I'm going to call this straight up manipulation of what I actually said, so let's give some real context. (Ref: Forum Chat)

    So, Let's address some things here

    a - 1)
    That's indeed one of the reasons, home-brew crypto is indeed bad, It's untested, and it can not be trusted, This is a very well known fact in the crypto world. However, that's not the only reason.
    • a) Telegram defaults are insecure,
    • b) Telegram's protocol is known to be vulnerable to side channel attacks
      Their protocol is based on AES-IGE, Which doesn't provide message integrity. The message integrity is being verified through the use of SHA1, and their approach to 'Authenticity and Integrity" is based on the MtE Schema, which is considered an unsafe implementation practice.
    • c) It has suffered from padding length attacks in the past, not only this, but IGE Is proven to be vulnerable to bitflip attacks Which, again, shows how far telegram is from their approach to 'very secure'. Also, Telegram's 'Home-brew' DH Modification used third party parameters (server nonce) that allowed the server to mitm connections and intercept messages, which, on itself is simply frightening.
    As for the 'some twat' part, I'm going to assume you were referring to Prof. Matthew D. Green. I demand that you do not refer to people, especially professors in such disrespectful ways, if you want to keep this discussion on a mature enough level.

    a - 2)
    'Teaching about crypto' and 'Teaching how to crypto' are 2 very different things. Teaching about crypto means that you get to know how crypto primitives work and what's the best way to implement them. Nobody is saying that people should stop making algorithms better, maybe develop new cryptosystems that someday will be mature enough to be called, primitives. However, going so far as to roll your own closed source implementation of a 'home-brew cryptographic algorithm' on a production environment of such scale, is very immature. You could argue that their protocol has been designed by competent mathematicians and that it's secure, however that doesn't prove anything as far as the online community is concerned.

    a - 3)
    Well, Since
    • 1- Bruce M. Schneier
      an American cryptographer, computer security, privacy specialist and writer. He is the author of several books on general security topics, computer security and cryptography. Schneier is a fellow at the Berkman Center for Internet & Society at Harvard Law School, a program fellow at the New America Foundation's Open Technology Institute. He has been working for IBM since they acquired Resilient Systems where Schneier was CTO. He is also a contributing writer for The Guardian news organization
    • 2- Matthew D. Green
      a cryptographer and security technologist.An Assistant Professor of Computer Science at the Johns Hopkins Information Security Institute. He specializes in applied cryptography, privacy-enhanced information storage systems, anonymous cryptocurrencies, elliptic curve crypto-systems, and satellite television piracy. He is a member of the teams that developed the Zerocoin anonymous cryptocurrency and Zerocash. He has been involved in the groups that exposed vulnerabilities in RSA BSAFE, Speedpass and E-ZPass.
    are 'untrustworthy' as security auditors, I'd be more than glad to hear about trustworthy security auditors that you personally trust. Although I don't think any sane security expert would make any claim promoting home-brew crypto implementations of such scale, I'd be more than glad to be proven wrong.

    a - 3)
    Will be added at the end of this post

    a - 4)
    My beliefs are being based on actual crypto analysis / community opinion / and security expert's opinion. I'm quite sure that proves way more than what a techfaq page and 6 mathematicians would. Assuming that we're slandering tg in the first place, is incorrect. What really is being claimed is: Telegram is known to disobey to one of the fundamental security rules, never use your own crypto algorithm on production environments, especially if you decide to use closed source implementations of it. What follows is research and proof that demonstrates those claims.
    You are very wrong, contrary to your beliefs, the online security community (especially the cryptographic enthusiast one) is very far from anything near the 'SSS' Syndrome you are referring to. The main reason people are advised not to use their own algorithms is to keep them on the safe side, as such algorithms can not be proven to be secure without proper in depth analysis, which is simply way too complicated to be carried alone by 6 mathematicians, keep in mind, 'Mathematicians'. As for the 'crypto implementation' part, what was really being addressed in the article was the fact that, unsafe practices were being applied in telegram's crypto implementation, which I did list above.​
    rofl cake likes this.
  4. Derp

    Derp TS3 Dev-Team WebApp Dev-Team Contributor

    Addressed above, still, going to address this one more time. Showing disrespect towards the security experts that audited and expressed their opinions on telegram proves absolutely nothing on your end, if you want to disclaim any claims and keep this discussion mature, moderate your language. Regarding the 'none of them actually looked into the source and algorithms before commenting' part, that's the whole culprit of the story, the fact that the community does not have the source code and can not make sure it is secure.
    As for the 'metadata' part, I do partially agree, metadata is scary however online presence can be considered a borderline insignificant threat. On the other hand, it can be said that it could be a potential threat in the eyes of sensitive user-groups, such as whistle-blowers, journalists etc. The main reason that the specific 'online presence' metadata is being mentioned is due to the fact that telegram claims to be a fully secure solution towards communication and data exchange, which attracts said sensitive user-group. Such sensitive groups need to be aware of any minor issue there is with the software they're using as their life could be endangered, thus the need for the seemingly insignificant issue statement.

    You are choosing to believe in the fact that 'said data is 1 year old and it's probably fixed right now', completely disregarding the severity and impact that such issues had on the end user. If you deem that such issues are insensible to you then, go ahead and use telegram, nobody is stopping you from doing it, Still, do recall that such issues existed and that their severity was high. I can't really say more in this case since you're stating that you weren't able to find any sensible issue back then... ( 'DH Key Agreement MITM' attack ) included. As for the last part ('let's ignore ignorant professors who haven't looked at it'), I addressed that above.[/INDENT]

    2- Deprecated Research
    I addressed this above, as I said, that doesn't fix things up. Security can not be based on principles on the line of 'SHOULD have moved on and fixed said issues'.

    3- The Goal & 4- Ideal (and no so ideal) POCs
    Since this was also addressed above, I'll limit my response to adding a very, very interesting essay by Bruce Schneier on How security should be evaluated: Link

    Defaulting to statements on the line of: 'Telegram as a platform can not be judged because it's closed source and these professors have not seen the source code, and no 'SENSITIVE' Issues have been found', is wrong. Research, although outdated shows that their protocol isn't as secure as they claim to be. Is telegram safe for the most users that don't really care about security and only care about the functionality telegram provides? Yes, It can be said so. Should we base assumptions on telegram's security over the claim that such research is deprecated and everything 'should' be fine now? I personally wouldn't, and I'm pretty sure I'm not the only one. That said, I hope I haven't repeated myself too much :3, looking forward to other r4p3 member's input on this.​

    Useful Links

    1- Bruce Schneier essay > "How to Evaluate Security": https://www.schneier.com/essays/archives/1999/01/security_in_the_real.html
    2- Interesting Reddit discussion > "Has the telegram encryption been broken?": https://goo.gl/KKxll3
    3- Telegram FAQ > https://core.telegram.org/techfaq#q-why-did-you-go-for-a-custom-protocol
    4- Telegram FAQ > https://core.telegram.org/mtproto
    5- Interesting article > "A 264 Attack On Telegram, And Why A Super Villain Doesn't Need It To Read Your Telegram Chats": https://goo.gl/7l0pzp
    6- Crypto analysis > http://cs.au.dk/~jakjak/master-thesis.pdf
    7- Interesting DJB Article on Entropy Attacks > https://blog.cr.yp.to/20140205-entropy.html
    8- EFF Comparison > https://www.eff.org/node/82654
    9- Interesting input on the telegram's cryptanalysis contest > https://moxie.org/blog/telegram-crypto-challenge/
    10- Some more input on the cryptanalysis contest - > http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest
    rofl cake likes this.
  5. RSX

    RSX Member

    I'll keep it short as I don't necessarily want to stand by what I said on the shoutbox that night, and yes I was too harsh, however, there is some stuff I'd like to say in response to that.

    A - 1: If there's defaults that are insecure, then they can be altered, which doesn't exactly hinder telegram an insecure platform. That's like saying we shouldn't trust companies that develop routers as some of them had insecure authentication methods enabled by default. Yes, I called them twats as I don't trust them and they did a lot of talking on a subject they admitted to have done zero work on. They can neither provide a proof of concept or even an idea in regards to how they would be able to crack telegram, when talking publicly. All they've mentioned is that they personally wouldn't trust some 'home brewed' implementation. Also, do note, I don't really care about message integrity, I only care about encryption, and some attacker being able to circumvent that.

    A - 2:
    > Nobody is saying that people should stop making algorithms better, maybe develop new cryptosystems that someday will be mature enough to be called, primitives.
    Really? I recall some professor saying something along the lines of if you don't have enough experience (of which no silly degree will give you), you shouldn't touch implementing your own algorithms. (do note, I don't agree with them being pushed into production, but in development and in academic environments, there's zero reason for him to be saying such a thing. it's like saying you can't get internship as you don't have any experience doing said job. )

    A - 3: I don't trust people just because they teach at a certain place, or getting education at a certain place, or even graduated at a certain place. If he, someone who should be able to do an audit, just says "it may not be secure" and "I haven't investigated it" in the same paragraph, of course I'm not going to trust a single word that comes out of his mouth in regards to this (telegram) subject.

    A - 3 (??): Perhaps that should have been brought up that night or when you made that reply

    B: No, it's not about security, history, and beliefs. I simply do not care about their distant (over a year old) history.

    C: Let's not start an Android vs iOS security war. Whilst we all know closed source limits peer review, I strongly believe that security by obscurity in some cases can limit the amount of issues known. Keyword, known. Even though the unknown are still issues, I much prefer them to be never found to be blasted around the black hat community because some 'researcher' found an issue in their source.

    C/D - A - I'm not going to stop using a platform as it had issues in the past. https://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74 Damn, look at all those code execution exploits. let's no longer use php and drop the forum and all these teamspeak bots.
    D - B - Sue, sue, sue. I'm not here to be some party's protester and shield just because they were hurt by a product a few years ago. I've seen mcdonalds employees get burnt by broken fryers in the past, but I'm not going to quit eating fast food because of someone else's misfortune.

    2 - Same as d. I'm not someone elses protester nor was I hurt by these issues nor are there any better solutions. Skype allowed you to edit other peoples messages, view their history, and crash them by sending 50 emojis in one message, and lord knows people still use that lump of garbage. Likewise discord, we all know how shit it is, how shady and idiotic the developers are. Yet, all these solutions are still deemed safe enough to use. :/

    > Defaulting to statements on the line of: 'Telegram as a platform can not be judged because it's closed source and these professors have not seen the source code, and no 'SENSITIVE' Issues have been found', is wrong.
    A) we don't really need the server. it's not that big of a deal
    B) Wrong? I never such a thing nor would I as it can be used against me (like how you're doing right now)
    The other rubbish I said can be assumed a deprecated view and no longer what I actually think thanks to tired ramblings.
    Last edited: Jan 4, 2017

Share This Page