|
|
|
|
|
|
by abcd_f
4572 days ago
|
|
|
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 because people think you cannot design a crypto protocol. The contest doesn't help a bit, it only further enforces the impression of arrogance on your end. This is not what you would've done if you in fact allowed for the existence of flaws in your design. You would've released an RFC instead. I have all the sympathy for you. I don't doubt your motives, but you are setting yourselves up against skilled technical crowd. It has already started off on the wrong foot and this unfortunate dynamic will continue. 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. |
|
|
>> 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.