The important thing to remember is that all Telegram messages
are always securely encrypted. The difference between messages
in Secret Chats and ordinary Telegram messages is in the
encryption type: client-client in case of Secret Chats,
client-server/server-client for ordinary chats.
Where "securely encrypted" means that the Telegram server has full access to message contents for ordinary chats. All chats should be "Secret Chats", not the other way around.
Came here to say this. I also don't understand why "secret chats" can't be kept in the cloud. Why can't they store encrypted messages and give them to me to decrypt when I want to?
I guess, that the problem is in encryption key exchange. Cloud chats are easy to synchronize between devices. Secret chats require unique encryption key for each chat.
If this get popular and the people behind it can be trusted, this could replace sms and e-mail. The iOS, Android and CLI clients are open source, but I they need to open source the backend too. I also like the idea of giving the noun "telegram" a new meaning.
Replacing SMS I can see, since whatsApp/GroupMe/iMessages/whatsoever is already doing so, but replacing e-mail? Why would it replace e-mail in your opinion? I think IM/chats have a completely different purpose compared to e-mail, which unfortunately is often times used wrongly imho.
What is the point for server side open source? You can never trust that this code is launched on the instance which answers to your client' requests.
If you don't trust the backend in some particular way, nothing can help you to trust cloud storage. You should better take a look at end-to-end encrypted chats [1]. In theory they don't allow server to get access to any user data, except the fact of sending messages.
Is HTTPS not secure channel for communication between client-server? What is the reason behind using an entirely different protocol for client-server communication[0] over HTTP?
I also don't get this. If we stopped trusting HTTPS, how are we supposed to make sure that we get an unmodified app from the play store, or the original source code from GitHub in the first place? Am I missing something?
The fact that we have to trust TLS to deliver software doesn't automatically mean that we should trust it for secure messaging.
Also, I think App Store software delivery doesn't depend on only TLS, but also on Apple's signature. And you can visually verify that the source code downloaded from GitHub doesn't contain backdoors.
My knowledge on cryptography is next to nothing. Would you mind explaining to me what makes the case for secure messaging different than any other transfer through a secured HTTP connection? I also read a bit on OTR Messaging and the "Socialist Millionaires' Protocol" but just got even more confused.
It's not that messaging can't use TLS, of course, it can. I'm objecting to the absolute (if we don't trust TLS for messaging, we shouldn't trust it one-time download), e.g. see https://en.wikipedia.org/wiki/Threat_model
The main reason is speed. MTProto is designed to work fast on weak mobile connections.
Another reason is security, with HTTPs you need to trust more parties.
>Very secure. We are based on a new protocol, MTProto, built by our own specialists from scratch, with security in mind. At this moment, the biggest security threat to your Telegram messages is your mother reading over your shoulder. We took care of the rest.
Oh good, a bunch of randoms have rolled their own crypto. I stopped reading at this point.
And the only reason the critical bug was found is because it was open source. This, as far as I can see, isn't.
So we have a perfect storm of problems here: An author who has rolled his own crypto, isn't a cryptographer, and whose product is closed source. Trust Telegram at your peril.
It's worth noting that there's an app which already does what Telegram claims to do. It's called TextSecure, and it was written by Moxie Marlinspoke and several other big-name cryptographers: https://whispersystems.org/
EDIT: Telegram is open source, so I was wrong about that and it'd be unfair of me not to mention it. But the other observations still apply. Until Telegram is verified to be secure, I don't think it's a good idea to trust it, especially when secure alternatives like TextSecure exist.
So those are bugs, though I'm not sure if documentation or code. Most importantly to me, there are very few comments in the code, and the few there are are incorrect. One might infer that this code has been written either in haste, or by someone who believes that comments are not needed in this sort of systems code.
There are also writeInt() and readInt() method which seems to be little-endian, which seems odd for a network program. No comments near them.
Finally, there's a "Package" class which is just a byte array and a flag. And there's a method which writes it after a cute encoding for the length divided by 4. But there is no code which checks that the length is evenly divisible by 4. This may lead to incomplete Packages being written, with what effect I am not sure.
In summary, I wouldn't trust this program, having reviewed one of its source files mostly at random.
Oh, and despite its README saying that it is designed for mobile, it uses TCP Keep-Alive, which seems like a bad idea for mobile specifically (due to keeping the radio alive and draining the battery). Again, no comments explaining why.
5ms * 1000 != 15s. It's unclear whether the comment is outdated, and 5s is in fact intended, or whether 15s was intended and the 5 is a typo (therefore a bug, although unlikely a critical one). Either way, it's certainly sloppy programming, and the kind of thing that can lead to more serious problems.
> "For the moment we are focusing on open sourcing the things that allow developers to quickly build something using our API. We started with Android and Linux, since these platforms are the most open, recently we published the iOS app code as well. We will be releasing more code eventually." -- http://telegram.org/faq#q-why-not-open-source-everything
It looks like TextSecure encrypts your actual texts, for which you still pay, while Telegram also takes care of delivery, for free, and does it faster and better than SMS (which should be pretty darn easy, what with SMS doing such a very bad job indeed).
I scratched my head after reading your comment, and waited to see if anyone else would say something.
Colin's problem was that his (hand-written, from the looks of it) crypto primitives allowed him to use AES-CTR with a non-incrementing counter. I'm not sure if it's appropriate to say that in relation to a comment about "rolling your own protocol." I see that as a low-level problem.
Further, you've pulled a misdirection talking about TextSecure (which looks great, by the way). They don't roll their own crypto algorithms, but they have definitely tweaked and modified the OTR protocol for their own purposes in order to make it more secure. I'm left wondering why TextSecure is held up in contrast to someone who uses their "own" secure messaging protocol.
Whether or not this Telegram app is trustworthy (the lack of full source is suspicious), I have no idea. I would personally pick TextSecure over it.
The extension you're thinking about is Trevor Perrin's Axolotl ratchet, which is (a) the product of an actual cryptographer, (b) used in more than one system (it's also incorporated into Adam Langley's Pond), (c) has been reviewed by experts, and (d) is entirely specified, with a public domain spec.
It is not in fact reasonable to compare Telegram's ad-hoc protocol to the "extensions" TextSecure has.
The only point I wanted to make is that someone using a protocol (variant or original) that someone hasn't seen before is not inherently damning in and of itself. Mine was a general point, and yours is a practical one, which I mostly agree with.
The parent comment seems to imply that there is a pre-written solution for all cryptographic problems that can be dropped into place, and I also felt they were conflating high-level protocol problems with low-level cryptographic primitive problems (i.e., "rolling your own crypto" being used in a general sense). I think it is reasonable to compare two "non-standard" systems in that context, especially given how modifying an already-trusted protocol can go haywire if something is done wrong.
Whether or not an extension or protocol is reviewed, has a public spec, comes from a cryptographer, started from a more trustworthy protocol or has other practical elements that make it appear trustworthy on the surface, is another matter entirely. It 100% matters in practice, but not for a more general point.
I understand that Telegram is doing everything from the ground up and that TextSecure started with OTR, and that the ratcheting extension wasn't pulled out of thin air. I am not claiming in practice that Telegram and TextSecure are comparable (I did not mean to take anything away from TextSecure or the ratcheting scheme), and I personally would not touch Telegram in light of further snooping about and comments posted in this HN thread.
I don't care if it was written by Eric A. Young -- I think history has shown that crypto takes a long time and many iterations to get to a point where it's secure and trustworthy. No single person is going to come down from the mountaintop with a working, secure and correct protocol from scratch. That just doesn't seem to be how it works.
It's just an advertisement like any other. I'm sure the people responsible for the content of the FAQ know their target audience, so they know the wording will work for those whose attention they care about.
It is good that we, technical people, understand how completely worthless those words are. It begs for the "citation needed" label.
The question for me is this: do ordinary people (non-programmers in this case) really believe in most of the things ads tell them?
In this case, even if you remove the ad-hominem attack (a bunch of randoms), a valid point remains: implementing crypto is already notoriously difficult, let alone designing cryptographic protocols.
Still, there are sometimes valid reasons for not re-using existing solutions.
In our case, we needed something that is both secure and competitive in comparison to mass market solutions in terms of speed, working on weak connections and usability.
It is a really bad idea to compromise security for speed and connection stability. Processing power is a question of scaling the hardware, communication speed is hardly affected by a proper encryption scheme, neither is reliability of the application-layer protocol.
Usability, however, is a different beast. You must compromise security to make a chat application appeal to "regular" users. Still, this is a trade-off that can be clearly communicated to the user and to developers, and does not require a custom crypto protocol. You can achieve the same effects with using existing and tested libraries.
Edit: Disclaimer: I am the developer of the yaxim Android XMPP client and the operator of the public yax.im XMPP server (both available at http://yax.im).
Thank you for the plug for yaxim. I've been searching around for a "good enough" jabber client for android, and while yaxim isn't there yet (for me: no otr support, single server) it looks like it's headed in the right direction!
Have you looked at ChatSecure? It has OTR, multiple servers, all that good stuff. It's not wonderful but it ain't bad (curious to hear what others have to say, I haven't really used much else)
I have it installed, but not really looked at it. My last "burst" use of xmpp was via facebook -- as most of my contacts don't use "plain" jabber right now. Before that I used it a bit for work -- but then rarely on my phone.
Now that google is killing talk in favour of proprietary hangouts, I predict it'll be a while before I'm a serious xmpp user again.
Sadly it's very hard to push process changes when one are in the minority in a group... Thanks for the reminder though, it does look like it full-fills most of my needs (and fixes annoyances I've encountered with other android clients).
MTProto still uses RSA, AES + DH. So I would disagree that what we have here means 'compromising security for speed and stability'. It is rather optimizing for speed and stability, while staying secure.
Absolutely, just trying to point out that the original poster raised some valid points that didn't deserved to be dismissed as "ad hominem". I haven't had a chance to dissect your work (but appreciate that you have made that possible in the first place) and I believe extraordinary claims require extraordinary scrutiny :)
You're assuming that the average HN is in a position to audit crypto code.
We use well audited crypto primitives with formal proofs because they're known safe, or at least orders of magnitude safer than whatever these fools cooked up.
tl;dr provide proof or gtfo. We're not here to audit you.
If there is one place where an appeal to authority argument can hold place and not be seen as a fallacy is security. (it's not ad hominem btw)
When you're rolling out a secure system + implementation you want to use algorithms that have been proven, tested and certified as correct. It's a delicate field that can't be approached like your standard software development field. Yes, being a "random" and developing your own encryption algorithm out of the box is bad. Never trust anything like that. Period.
With all the revelations of built in weaknesses and such with existing encryption schemes... I don't know. I think we need a new one.
That said, it should probably be developed by a panel of experts. I would love to see something by Bruce Steiner et al, where 'et al' is a group that he selects. As you pointed out a group without heavy crypto experience can't realistically roll their own and have it actually be secure.
Designing new protocols and constructions using primitives like AES and DH is exactly what cryptographers are talking about when they refer to "rolling ones own crypto".
Look at the description of their protocol, particularly the handshake, which negotiates number-theoretic parameters, and try to make a list of all the checks they'll need and the additional protocol that they'd need to specify just to make the handshake secure.
Not only that, but the crypto in Telegram is idiosyncratic; for instance, this is the only system I've ever seen that used IGE mode.
We have not 'rolled our own crypto'. We still use RSA, AES and DH.
I've changed the part in the FAQ that seems to be one of major sources of this controversy, so that it no longer reads "built from scratch". This was poorly applied marketing language — we do use time-tested security algorithms. Even though Telegram doesn't uses MTProto instead of HTTPS due to mobile speed and trust issues.
AES in what mode? IGE? Why are you using an authenticated cipher mode from the 1970s that predates every modern AEAD construction?
DH with what group? How do you authenticate the exchange? How does forward secrecy work?
Saying "we didn't roll our own: we use RSA, AES, and DH" is extremely worrying; it suggests that you're not aware of where the complexity in a cryptosystem lives. Anybody on HN can write the trivial code to ask the JCE for an RSA or an AES. You have to do better.
What do you mean exactly? According to the FAQ, Threema offers perfect forward secrecy:
Yes, Threema provides forward secrecy on the network connection. Client and server negotiate temporary random keys, which are only stored in RAM and replaced every time the app restarts (and at least once every 7 days). An attacker who has captured the network traffic will not be able to decrypt it even if he finds out the long-term secret key of the client or the server after the fact.
* 'delivers messages faster than any other application' - any application? Hmmm. They must be using magic.
* 'messages are heavily encrypted and can self-destruct' - but like every system, the self-destruction is not assured since it's impossible to enforce.
* 'keeps your messages safe from hacker attacks' - a bold claim. Maybe they do some stuff to protect messages, but it's not the perfect safety that this statement implies.
Have you tried the app? I've moved my top-5 chats from WhatsApp just because of speed! The messages are sent really fast. But if you know any other messenger apps for iOS, which are just about so fast, I'll definitely give them a try.
Anyway yep, these marketing stuff is a bit too dubious, but what should they write?
* is rather fast, faster than some applications
* can self-destruct, but sometimes can not (Ha!)
* etc
That's not the thing that happens in real world nowadays.
The replay protection is overly complicated and doesn't kick in after the message is decrypted. This makes it possible to DoS the server with forged messages.
Key derivation uses a custom scheme. Typically there's no reason NOT to piggy-back on existing schemes and there's plenty to choose from - from TLS to IKE.
Also, as already mentioned, there's again NO reason not to use TLS in Anonymous DH mode with an app-level authentication of the session handshake.
Designing your own crypto protocols is a very interesting challenge, but for practical purposes you just have to recycle existing designs. There's really no other way about it. A custom crypto doesn't make any difference for those who doesn't know/care about it, but it certainly will not make you any friends between those who does. Unless, of course, you can explain and prove why your design is better than those that exist already, and these guys don't do this.
You can drop the first two. And the third can have different motivations: I think here we just have a mathematician with sufficient time on their hands who enjoyed coming up with this. I think the primary valid complaint is: overly complex for its task.
it's not just overly complex, the use of 'dependent types' for this indicates that the author doesn't understand how they are really useful. neither he seems to know what serialization is, he apparently wants to serialize linked lists.
The reason for designing something new was this: in order for really secure messaging to catch on among the masses today — it needs not only be secure. When you want to compete with the likes of WA, you also need be fast and reliable on weak mobile connections.
TLS/HTTPS is slow and takes a lot of time to restore connection on fragile networks.
MTProto was born as a result of an experiment: whether it would be possible to create something that is both secure and fast.
Disclaimer:
Unfortunately, I'm not Nikolay.
But I do work for Telegram.
>MTProto was born as a result of an experiment: whether it would be possible to create something that is both secure and fast.
I'd like to see some papers/surveys/case studies on the matter. Yes, it's an "experiment", doesn't mean it's a good idea to roll out your own implementation before performing (and publishing) extensive tests.
Not saying you're doing something wrong, just that security-oriented people (usually who'd be interested in your product) may want to know more than just "yes guys it's secure, trust us".
This is all great, but it reads like a marketing speak. There was this imperfect world full of idiots, slow, ugly and dim lit and then we came along and lifted the gloom.
Sorry, you have to do better than "TLS/HTTPS is slow". Anything over TCP is slow on congested and lossy networks. That's given, but that's hardly a reason to reinvent the whole crypto stack.
How is your protocol superior / faster / better than DTLS with session resuming? Is it faster than IKE in Quick Mode or IKE v2, which are both datagram protocols designed to work over lossy networks? What are the inherent problems with adopting DTLS or IKE to your purposes? This is dead easy to do without touching original crypto design and it instantly removes all questions pertaining to the quality of your crypto design. So why not?
I'm not a professional cryptographer, but I know applied crypto well and I've seen my share of custom crypto designs. Virtually ALL of them are is a result of thinking that it's better and easier to invent something new than to diligently learn what exists and understand how it works. It's fine for some areas, but it is decidedly not a way to go in the cryptography domain.
Looks like they kept the interface exactly the same as What's App to attract users. The smiley selection has the entire list of What's App smileys in exactly the same order. What's App is going to be upset, but it might help users.
>Durov holds libertarian economic and political views and says he is a vegetarian and identifies as a Taoist. He published anarcho-capitalist manifestos describing his ideas on improving Russia. On his 27th birthday, he donated a million dollars to the Wikimedia Foundation.
Well, I think I'd rather trust them than Google or Facebook, after all, you've got to trust somebody.
The brothers do have some money, I suppose, from their company.
However, I'm not sure if they are using the data gathered from this service, thus resulting in revenue somehow (maybe in their social network).
> Telegram servers are spread worldwide for security and speed.
So this is what they mean by decentralized....
> As a result, Telegram is the fastest and most secure messaging system in the world
And this has exist for how many years?
I can probably say everything except private message, google hangout or Facebook chat is already doing it. They have some of the top-notch security, network and distributed system developers and they have their own cable delivering more volume than your new service can combine together. and if I want true privateness? I'd one-time pad everything. in reality, I guess PGP is good enough.
> I can probably say everything except private message, google hangout or Facebook chat is already doing it. They have some of the top-notch security, network and distributed system developers
As an American I fear the NSA but at the same time to be fair, NSA is not the only intelligence doing this sort of work. Let's be fair, every other governments are doing similar things anyway, so maybe we should say no thanks to every other website.
People here are complaining a lot about this app, and rightfully so.
However, this is definitely the best encrypted communications app there is for ios and therefore also the only app that is cross platform and able to reach a wide audience.
I know they didn't do it completely right, but it definitely seems to be the best option that is currently available.
An "encrypted communications app" that is not using secure encryption is worse than an unencrypted one - the users get a fake feeling of security, and might reveal sensitive information to whoever is listening.
Regarding real security, have a look at ChatSecure, which is available for iOS and Android, uses standard encryption protocols (XMPP with TLS, OTR), is open source, and was developed by the Guardian Project (who have a track record of developing security software):
but it is almost unusable on ios because it can not run in background
Unfortunately, the only way around that is to integrate with Apple's Push Service, which means you need to run a server-side component which notifies Apple (and which in turn notifies your app). This is not specified for XMPP, so most "XMPP clients" for iOS instead store your credential on the app developer's infrastructure. However, this problem is being worked on:
I am working on a protocol-agnostic, federated push messaging layer for ChatSecure-iOS but it will be interesting to see if anything else pops up in the meantime.
I've been using Threema for a while, it's available for both iOS and Android and while it isn't open source, you can verify the encryption used (they are using NaCl).
Wow, there are so many cryptography experts with world names in this thread!
And interesting why you think that it's not possible to read most of cryptography/cryptanalysis books and check common mistakes of implementation afterward? Do you really think that this is THAT hard?
Your scepsis would be understandable if they used OWN cryptoalgorithm. However their protocol is based on well known strong crypto.
There is a lot more to secure protocol design than just stringing together commonly accepted standards, unfortunately.
There are a great many ways you can all gaps which mean a hacker can circumvent your security arrangements, and we are sceptical because we've seen it done wrong so many times before that it is healthier to take the pessimistic view (assume it is wrong and be pleasantly surprised if it isn't, rather than unpleasantly surprised if/when it turns out not to be).
230 comments
[ 3.3 ms ] story [ 242 ms ] threadThe real issue is that they could just make a lever that would still store "secret chats," unless if they're being delievered p2p.
https://whispersystems.org/blog/advanced-ratcheting/
If you don't trust the backend in some particular way, nothing can help you to trust cloud storage. You should better take a look at end-to-end encrypted chats [1]. In theory they don't allow server to get access to any user data, except the fact of sending messages.
[1] http://core.telegram.org/api/end-to-end
[0] - http://core.telegram.org/mtproto
https://en.wikipedia.org/wiki/Transport_Layer_Security#Attac...
https://community.qualys.com/blogs/securitylabs/2013/03/19/r...
Also, I think App Store software delivery doesn't depend on only TLS, but also on Apple's signature. And you can visually verify that the source code downloaded from GitHub doesn't contain backdoors.
No, you don't. Use a self-signed certificate that is hardcoded in the app.
>Q: How secure is Telegram?
>Very secure. We are based on a new protocol, MTProto, built by our own specialists from scratch, with security in mind. At this moment, the biggest security threat to your Telegram messages is your mother reading over your shoulder. We took care of the rest.
Oh good, a bunch of randoms have rolled their own crypto. I stopped reading at this point.
That's a very bold and yet to be proven statement. Probably any crypto expert would know better than to say that.
This paragraph exactly pin points the problem with being a cryptographic nobody.
PS. I do like their icon designer.
He is one of most legendary math/programming champions of all time.
Colin Percival is similarly decorated, along with being a cryptographer (he's the FreeBSD security officer): http://www.daemonology.net/papers/
... yet even his crypto app Tarsnap was broken for over a year before he noticed, due to a typo during an innocent-looking refactoring change. http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...
And the only reason the critical bug was found is because it was open source. This, as far as I can see, isn't.
So we have a perfect storm of problems here: An author who has rolled his own crypto, isn't a cryptographer, and whose product is closed source. Trust Telegram at your peril.
It's worth noting that there's an app which already does what Telegram claims to do. It's called TextSecure, and it was written by Moxie Marlinspoke and several other big-name cryptographers: https://whispersystems.org/
... and it's open source: https://github.com/WhisperSystems/TextSecure/
... and they don't try to roll their own crypto: https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2
These aren't coincidences. It's basic necessity.
EDIT: Telegram is open source, so I was wrong about that and it'd be unfair of me not to mention it. But the other observations still apply. Until Telegram is verified to be secure, I don't think it's a good idea to trust it, especially when secure alternatives like TextSecure exist.
TextSecure has been a work in progress for two years: https://github.com/WhisperSystems/TextSecure/commits/master?...
Telegram seems to have been in progress for two months: https://github.com/ex3ndr/telegram-mt/commits/master?page=2
Telegram also seems to be the work of a single author. While TextSecure was written mostly by Moxie, there were several other contributing members.
TcpContext.java[1] says:
So those are bugs, though I'm not sure if documentation or code. Most importantly to me, there are very few comments in the code, and the few there are are incorrect. One might infer that this code has been written either in haste, or by someone who believes that comments are not needed in this sort of systems code.There are also writeInt() and readInt() method which seems to be little-endian, which seems odd for a network program. No comments near them.
Finally, there's a "Package" class which is just a byte array and a flag. And there's a method which writes it after a cute encoding for the length divided by 4. But there is no code which checks that the length is evenly divisible by 4. This may lead to incomplete Packages being written, with what effect I am not sure.
In summary, I wouldn't trust this program, having reviewed one of its source files mostly at random.
Oh, and despite its README saying that it is designed for mobile, it uses TCP Keep-Alive, which seems like a bad idea for mobile specifically (due to keeping the radio alive and draining the battery). Again, no comments explaining why.
[1] https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j...
* Uses unpadded RSA in its authentication protocol
* Uses a novelty mode (IGE) for its bulk transport
* Does not appear to authenticate messages (other than by using IGE)
* Or, at least, what authentication it is doing must be happening after it decrypts data, not before
I could be wrong about any of these things, because again, 4 minutes. But this design does not look sturdy.
EDIT: Oeps, sorry.
https://github.com/WhisperSystems/TextSecure-iOS
Looks like the programme is open source: http://telegram.org/source
Colin's problem was that his (hand-written, from the looks of it) crypto primitives allowed him to use AES-CTR with a non-incrementing counter. I'm not sure if it's appropriate to say that in relation to a comment about "rolling your own protocol." I see that as a low-level problem.
Further, you've pulled a misdirection talking about TextSecure (which looks great, by the way). They don't roll their own crypto algorithms, but they have definitely tweaked and modified the OTR protocol for their own purposes in order to make it more secure. I'm left wondering why TextSecure is held up in contrast to someone who uses their "own" secure messaging protocol.
Whether or not this Telegram app is trustworthy (the lack of full source is suspicious), I have no idea. I would personally pick TextSecure over it.
It is not in fact reasonable to compare Telegram's ad-hoc protocol to the "extensions" TextSecure has.
The only point I wanted to make is that someone using a protocol (variant or original) that someone hasn't seen before is not inherently damning in and of itself. Mine was a general point, and yours is a practical one, which I mostly agree with.
The parent comment seems to imply that there is a pre-written solution for all cryptographic problems that can be dropped into place, and I also felt they were conflating high-level protocol problems with low-level cryptographic primitive problems (i.e., "rolling your own crypto" being used in a general sense). I think it is reasonable to compare two "non-standard" systems in that context, especially given how modifying an already-trusted protocol can go haywire if something is done wrong.
Whether or not an extension or protocol is reviewed, has a public spec, comes from a cryptographer, started from a more trustworthy protocol or has other practical elements that make it appear trustworthy on the surface, is another matter entirely. It 100% matters in practice, but not for a more general point.
I understand that Telegram is doing everything from the ground up and that TextSecure started with OTR, and that the ratcheting extension wasn't pulled out of thin air. I am not claiming in practice that Telegram and TextSecure are comparable (I did not mean to take anything away from TextSecure or the ratcheting scheme), and I personally would not touch Telegram in light of further snooping about and comments posted in this HN thread.
https://news.ycombinator.com/item?id=6913705
For further reference:
https://news.ycombinator.com/item?id=1852560
It's just an advertisement like any other. I'm sure the people responsible for the content of the FAQ know their target audience, so they know the wording will work for those whose attention they care about.
It is good that we, technical people, understand how completely worthless those words are. It begs for the "citation needed" label.
The question for me is this: do ordinary people (non-programmers in this case) really believe in most of the things ads tell them?
An ad-hominem attack. This is Hacker News and their work is open, how about making a statement after researching the actual code instead?
In our case, we needed something that is both secure and competitive in comparison to mass market solutions in terms of speed, working on weak connections and usability.
Disclaimer: I work for Telegram.
Usability, however, is a different beast. You must compromise security to make a chat application appeal to "regular" users. Still, this is a trade-off that can be clearly communicated to the user and to developers, and does not require a custom crypto protocol. You can achieve the same effects with using existing and tested libraries.
Edit: Disclaimer: I am the developer of the yaxim Android XMPP client and the operator of the public yax.im XMPP server (both available at http://yax.im).
Now that google is killing talk in favour of proprietary hangouts, I predict it'll be a while before I'm a serious xmpp user again.
Sadly it's very hard to push process changes when one are in the minority in a group... Thanks for the reminder though, it does look like it full-fills most of my needs (and fixes annoyances I've encountered with other android clients).
Knowing this, I hope you can appreciate why the burden of proof on your unproven team and approach is fairly high.
We use well audited crypto primitives with formal proofs because they're known safe, or at least orders of magnitude safer than whatever these fools cooked up.
tl;dr provide proof or gtfo. We're not here to audit you.
When you're rolling out a secure system + implementation you want to use algorithms that have been proven, tested and certified as correct. It's a delicate field that can't be approached like your standard software development field. Yes, being a "random" and developing your own encryption algorithm out of the box is bad. Never trust anything like that. Period.
We know that writing crypto is hard and experienced crypto programmers make mistakes.
The possibility of a naive programmer creating a sturdy piece of crypto software with no previous experience is vanishingly small.
That said, it should probably be developed by a panel of experts. I would love to see something by Bruce Steiner et al, where 'et al' is a group that he selects. As you pointed out a group without heavy crypto experience can't realistically roll their own and have it actually be secure.
You can now argue whether that's still "from scratch". (Is building something on top of TCP "from scratch"?)
[0] http://core.telegram.org/api/end-to-end
Look at the description of their protocol, particularly the handshake, which negotiates number-theoretic parameters, and try to make a list of all the checks they'll need and the additional protocol that they'd need to specify just to make the handshake secure.
Not only that, but the crypto in Telegram is idiosyncratic; for instance, this is the only system I've ever seen that used IGE mode.
I've changed the part in the FAQ that seems to be one of major sources of this controversy, so that it no longer reads "built from scratch". This was poorly applied marketing language — we do use time-tested security algorithms. Even though Telegram doesn't uses MTProto instead of HTTPS due to mobile speed and trust issues.
AES in what mode? IGE? Why are you using an authenticated cipher mode from the 1970s that predates every modern AEAD construction?
DH with what group? How do you authenticate the exchange? How does forward secrecy work?
Saying "we didn't roll our own: we use RSA, AES, and DH" is extremely worrying; it suggests that you're not aware of where the complexity in a cryptosystem lives. Anybody on HN can write the trivial code to ask the JCE for an RSA or an AES. You have to do better.
technical description here : http://core.telegram.org/mtproto/description
Yes, Threema provides forward secrecy on the network connection. Client and server negotiate temporary random keys, which are only stored in RAM and replaced every time the app restarts (and at least once every 7 days). An attacker who has captured the network traffic will not be able to decrypt it even if he finds out the long-term secret key of the client or the server after the fact.
They do use forward secrecy on SSL, but not on the messages themselves.
* 'delivers messages faster than any other application' - any application? Hmmm. They must be using magic.
* 'messages are heavily encrypted and can self-destruct' - but like every system, the self-destruction is not assured since it's impossible to enforce.
* 'keeps your messages safe from hacker attacks' - a bold claim. Maybe they do some stuff to protect messages, but it's not the perfect safety that this statement implies.
Anyway yep, these marketing stuff is a bit too dubious, but what should they write?
* is rather fast, faster than some applications
* can self-destruct, but sometimes can not (Ha!)
* etc
That's not the thing that happens in real world nowadays.
How about some benchmarks to support this claim?
The replay protection is overly complicated and doesn't kick in after the message is decrypted. This makes it possible to DoS the server with forged messages.
Key derivation uses a custom scheme. Typically there's no reason NOT to piggy-back on existing schemes and there's plenty to choose from - from TLS to IKE.
Also, as already mentioned, there's again NO reason not to use TLS in Anonymous DH mode with an app-level authentication of the session handshake.
Designing your own crypto protocols is a very interesting challenge, but for practical purposes you just have to recycle existing designs. There's really no other way about it. A custom crypto doesn't make any difference for those who doesn't know/care about it, but it certainly will not make you any friends between those who does. Unless, of course, you can explain and prove why your design is better than those that exist already, and these guys don't do this.
[1] http://core.telegram.org/mtproto/description
http://core.telegram.org/mtproto/TL-dependent
look like a great parody to me? can't tell if they are serious with these 'dependent types'
> TL Language (Type Language or Time Limit)
So it is a partially applied acronym with a branch in it!
There is something seriously messed up in this project.
TLS/HTTPS is slow and takes a lot of time to restore connection on fragile networks.
MTProto was born as a result of an experiment: whether it would be possible to create something that is both secure and fast.
Disclaimer: Unfortunately, I'm not Nikolay. But I do work for Telegram.
I'd like to see some papers/surveys/case studies on the matter. Yes, it's an "experiment", doesn't mean it's a good idea to roll out your own implementation before performing (and publishing) extensive tests.
Not saying you're doing something wrong, just that security-oriented people (usually who'd be interested in your product) may want to know more than just "yes guys it's secure, trust us".
Sorry, you have to do better than "TLS/HTTPS is slow". Anything over TCP is slow on congested and lossy networks. That's given, but that's hardly a reason to reinvent the whole crypto stack.
How is your protocol superior / faster / better than DTLS with session resuming? Is it faster than IKE in Quick Mode or IKE v2, which are both datagram protocols designed to work over lossy networks? What are the inherent problems with adopting DTLS or IKE to your purposes? This is dead easy to do without touching original crypto design and it instantly removes all questions pertaining to the quality of your crypto design. So why not?
I'm not a professional cryptographer, but I know applied crypto well and I've seen my share of custom crypto designs. Virtually ALL of them are is a result of thinking that it's better and easier to invent something new than to diligently learn what exists and understand how it works. It's fine for some areas, but it is decidedly not a way to go in the cryptography domain.
[1]http://en.wikipedia.org/wiki/VK_(social_network)
Win https://tdesktop.com
>Telegram is supported by Pavel and Nikolai Durov.
I would not trust social network owner with my messages.
>Durov holds libertarian economic and political views and says he is a vegetarian and identifies as a Taoist. He published anarcho-capitalist manifestos describing his ideas on improving Russia. On his 27th birthday, he donated a million dollars to the Wikimedia Foundation.
Well, I think I'd rather trust them than Google or Facebook, after all, you've got to trust somebody.
[0] http://en.wikipedia.org/wiki/Pavel_Durov#Personal_life
Better the devil you know?
The brothers do have some money, I suppose, from their company. However, I'm not sure if they are using the data gathered from this service, thus resulting in revenue somehow (maybe in their social network).
Are they using something standard or do they want to lock-down users to their own proprietary servers ?
Firefox gives me "The certificate is only valid for the following names: *.stel.com , stel.com" for https://telegram.org/
Yeah, ok. Decided not to use it right there.
Great. Then...
> Telegram servers are spread worldwide for security and speed.
So this is what they mean by decentralized....
> As a result, Telegram is the fastest and most secure messaging system in the world
And this has exist for how many years?
I can probably say everything except private message, google hangout or Facebook chat is already doing it. They have some of the top-notch security, network and distributed system developers and they have their own cable delivering more volume than your new service can combine together. and if I want true privateness? I'd one-time pad everything. in reality, I guess PGP is good enough.
... and they are based in US of NSA - no thanks.
Regarding real security, have a look at ChatSecure, which is available for iOS and Android, uses standard encryption protocols (XMPP with TLS, OTR), is open source, and was developed by the Guardian Project (who have a track record of developing security software):
https://itunes.apple.com/de/app/id464200063
https://play.google.com/store/apps/details?id=info.guardianp...
As for the false sense of security, you're probably right.
Unfortunately, the only way around that is to integrate with Apple's Push Service, which means you need to run a server-side component which notifies Apple (and which in turn notifies your app). This is not specified for XMPP, so most "XMPP clients" for iOS instead store your credential on the app developer's infrastructure. However, this problem is being worked on:
http://legastero.github.io/customxeps/extensions/push.html
If you actually cared about security then you wouldn't be using iOS.
And interesting why you think that it's not possible to read most of cryptography/cryptanalysis books and check common mistakes of implementation afterward? Do you really think that this is THAT hard?
Your scepsis would be understandable if they used OWN cryptoalgorithm. However their protocol is based on well known strong crypto.
BTW, IGE cipher mode isn't well known for being strong.
There are a great many ways you can all gaps which mean a hacker can circumvent your security arrangements, and we are sceptical because we've seen it done wrong so many times before that it is healthier to take the pessimistic view (assume it is wrong and be pleasantly surprised if it isn't, rather than unpleasantly surprised if/when it turns out not to be).