171–176 of 176 posts
Pavel, since you are here, Don't you think that you are basically fighting a needless uphill battle here? I mean, people crave a good encrypted communication system and you have the intent and the infrastructure in place, but you are shooting yourselves in the foot with your cryptographic design indulgence. This animosity will continue, because Telegram crew comes across as cocky and arrogant know-it-alls, and not be…
Pavel, since you are here, Don't you think that you are basically fighting a needless uphill battle here? I mean, people crave a good encrypted communication system and you have the intent and the infrastructure in place, but you are shooting yourselves in the foot with your cryptographic design indulgence. This animosity will continue, because Telegram crew comes across as cocky and arrogant know-it-alls, and not be…
>> 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.
Earlier quoted context omitted.
From that page: > [...] the contest is fair because 1) the algorithm is completely specified, 2) there are no arbitrary definition of what winning means, and 3) the algorithm is public domain
Somewhat sad to see people on HN posting the Schneier link to counter the post without even bothering to read what it is about. I mean, it's almost like people have already formed opinions without giving the Telegram people a try. This is not how science works.
Not satisfied at leaving it there, they then claimed that their crypto system doesn't need to be justified, because their customers aren't concerned about the specifics of their implementation of known broken algorithms.
Finally, they placed the burden of proof on the public, which doesn't work when it comes to cryptography.
They were given the opportunity to explain their design decisions in an environment of mutual respect, and they responded to this offer by stonewalling two of HN's resident security gurus.
Pavel, since you are here, Don't you think that you are basically fighting a needless uphill battle here? I mean, people crave a good encrypted communication system and you have the intent and the infrastructure in place, but you are shooting yourselves in the foot with your cryptographic design indulgence. This animosity will continue, because Telegram crew comes across as cocky and arrogant know-it-alls, and not be…
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…
> 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.
Earlier quoted context omitted.
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…
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 random…
OK, now I can see your point. Thank you for taking the time to reply and share advice.
Earlier quoted context omitted.
Your challenge isn't at all hard. An attacker could get into your server using some other method besides breaking SSH then simply look at your bash history.
Break into his house, install a key logger. Real world security is fun.