Hacker News new | past | comments | ask | show | jobs | submit login

abcd_f, I'm not part of the Telegram team, nor am I a cryptographer. However, I do support these guys, and for the last 3 days I saw the Telegram team diligently reply tech questions in Twitter, HN and blogs. I saw them collect questions from security experts and put up FAQs based on them http://core.telegram.org/techfaq or http://core.telegram.org/contestfaq as well as update the obscure parts of their documentation.

>> Perhaps consider offering an alternative crypto suite based on standard protocols? In parallel with what you have. Just reuse an existing crypto framework and redo transport layer to your needs.

Again, I am not cryptographer. But as a person who wants his data to be secure I don't see anything wrong with different teams trying different approaches. I 100% agree that people crave a good encrypted communication system, but I'm not sure it can be achieved in a world where everybody uses similar methods. What if some of the common "best practices" are intentionally promoted in the crypto-community as the best ones exactly because they contain flaws and backdoors?

Please allow me to give you an example of something that could be just that.

The Telegram team was criticized by some NH critics for their custom auth key exchange protocol. People asked – why take a random value from server and a random value from client and combine both with a creepy function? Why not, e.g., just generate a random value on the client and use RSA instead? Well, the answer is simple – the Telegram guys did not trust that the random value generated on the client-side was really random.

In August 2013 it turned out that their custom approach to protocol enabled Telegram to stay more secure when multiple other secure apps using more conventional solutions were hacked (http://android-developers.blogspot.ru/2013/08/some-secureran...). Many Bitcoin apps were cracked and people lost money, Open Whisper Systems (I noticed these guys are aggressively promoted here in the NH community as the epitome of best security) had to hasten to patch their RedPhone app to avoid that vulnerability.

So I'm kind of suspicious when I see strong pressure to enforce the use of common techniques and get rid of uncommon ones just because they are uncommon. I think the Telegram guys have the right to choose their own path, and I'm sure our society will only benefit from it.

Of course, building custom solutions is no easy task and requires a lot of effort. But I've seen some of the Telegram guys (yes, the "6 ACM champions") create things that I'd thought were impossible. Maybe I am wrong in putting my trust in their abilities, and I will be fined $200K+ for my naivete. However, I am willing to continue financing such contests, and I do hope that eventually we'll all get something much more valuable than $200K.




Well, to prove my point of you guys coming across as cocky know-it-alls. Here you just did it again, perhaps without realizing it -

> People asked – why take a random value from server and a random value from client and combine both with a creepy function?

People well-versed in applied crypto would never ask this question, because all standard key exchange protocols most certainly use both sides as a source of randomness. Furthermore - "creepy"? That's all you got away from all those comments that said your KDF was unproven, not peer-reviewed and weak in comparison? You basically cherry-picked a dumb question (I assume you haven't made it up) and then proceeded to demonstrate how clever you are. Guess what? You just reiterated basic facts, but assigned them to yourself.

Let me repeat what I said. Your problem is not your crypto. Your problem is the attitude.


> Your problem is not your crypto. Your problem is the attitude.

OK, now I can see your point. Thank you for taking the time to reply and share advice.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: