HackerTrans
TopNewTrendsCommentsPastAskShowJobs

sillysaurus2

no profile record

comments

sillysaurus2
·13 лет назад·discuss
As for KDF, going for slower provable algorithms used for each incoming\outgoing packet may be a preferred solution for projects aimed at the relatively small security crowd. But we don't really compete in this area, our competition is WhatsApp and other mass market messengers.

What's this mean? You've created your own KDF, and the questions were: why is it secure, and why didn't you use an already-proven KDF? Unless I'm misreading something, it sounds like you've responded, "It's not that important, because our target market isn't people who care about their security." Is that correct?

EDIT: Judging by the upvotes, at least 5 other people are interested to hear your thoughts on this. Considering this submission is almost off the frontpage, that's a lot. As a security product, you should consider clarifying your position on this, because your statement currently sounds like, "We don't think security is a big deal since it's not a big deal to our target market."
sillysaurus2
·13 лет назад·discuss
Ah. In case anyone else was wondering why this works, it's because IGE has the property that if you corrupt the ciphertext, the plaintext is corrupted all the way from that point forwards. Therefore, appending the SHA1 of the message body is enough to check the integrity. (Appending a block of zeroes would be enough, too.)
sillysaurus2
·13 лет назад·discuss
There are certain data (session, message ID, session message, server salt) that are contained in the initial part of the unencrypted message; the message key must be the same as the 128 lower-order bits of the SHA1 of the message body (including session, message ID, etc.)

Not even HMAC-SHA1, just "SHA1"? So you leave yourself open to length extension attacks? http://en.wikipedia.org/wiki/Length_extension_attack
sillysaurus2
·13 лет назад·discuss
Interesting. Some observations:

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.
sillysaurus2
·13 лет назад·discuss
He's done nothing in crypto, and he's rolled his own protocol. That's historically been recipe for disaster regardless of how many honors you hold.

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.