@l29ah > Combinator is a function that takes arguments of certain types and returns a value of some other type. We normally look at combinators whose argument and result types are data types (rather than functional types).
Я полтора года назад писал пост об этом, может с тех пор чего и поменялось.
Сообщение шифруется на ключе, порождаемом от фиксированной секретной части и SHA1 от самого сообщения. Коллизии в SHA1 научились делать еще в 2005 году, причем в полном, а не в младших 128 битах. Это не катастрофа, но если найдутся слабости в других уровнях - может получиться неприятность с подменой сообщений без знания ключа.
Используется режим шифрования IGE, прямо скажем непопулярный. Придуман он был, чтобы дешево делать аутентификацию сообщений вместе с шифрованием. Вообще, на такие режимы в последние годы принято смотреть косо: в них часто встречаются неприятные дырки. IGE не исключение: некоторые модификации сообщений он отловить не может, и до кучи в описании протокола нигде не сказано, как его свойством аутентификации пользоваться. Ну и зачем было выпендриваться?
Хранение ключа на устройстве... Я просто оставлю это здесь: "Для озабоченных безопасностью пользователей можно предлагать защитить авторизационный ключ паролем, примерно так же, как это делает ssh. Для этого к ключу спереди добавляется SHA1 от него, после чего все это шифруется AES в режиме CBC с помощью ключа, равного (текстовому) паролю пользователя." Ведь какой-нибудь разработчик возьмет и последует совету, карму отчистить никакого Гоа не хватит. Выработка ключей тоже необычная: по DH создается общий ключ в 2048 бит, после чего сервер использует из них только 1024, а из оставшихся 512 даже не хранит, "под честное слово" разумеется. И предлагается эти 512 бит использовать для шифрования локальных данных, тогда-де нельзя будет их расшифровать даже расковыряв сервер. А почему просто не взять случайный ключ для локальной копии? А зачем 2048 бит, если используется только половина? А сервер правда ничего лишнего не хранит?
@4da Это вот, еще на пруф оф форк посмотри. Ну возможно это и работает, но довольно странный способ когда есть нормальные. Еще там адовый PFS, который нихуя не PFS потому что ключи неделю вроде хранятся (впрочем, в первых версиях и такого не было).
@anonim http://arkanoid.livejournal.com/416693.html?thread=18095797#t18095797
Например использование SHA-1 и IGE.
Я полтора года назад писал пост об этом, может с тех пор чего и поменялось.
Сообщение шифруется на ключе, порождаемом от фиксированной секретной части и SHA1 от самого сообщения. Коллизии в SHA1 научились делать еще в 2005 году, причем в полном, а не в младших 128 битах. Это не катастрофа, но если найдутся слабости в других уровнях - может получиться неприятность с подменой сообщений без знания ключа.
Используется режим шифрования IGE, прямо скажем непопулярный. Придуман он был, чтобы дешево делать аутентификацию сообщений вместе с шифрованием. Вообще, на такие режимы в последние годы принято смотреть косо: в них часто встречаются неприятные дырки. IGE не исключение: некоторые модификации сообщений он отловить не может, и до кучи в описании протокола нигде не сказано, как его свойством аутентификации пользоваться. Ну и зачем было выпендриваться?
Хранение ключа на устройстве... Я просто оставлю это здесь: "Для озабоченных безопасностью пользователей можно предлагать защитить авторизационный ключ паролем, примерно так же, как это делает ssh. Для этого к ключу спереди добавляется SHA1 от него, после чего все это шифруется AES в режиме CBC с помощью ключа, равного (текстовому) паролю пользователя." Ведь какой-нибудь разработчик возьмет и последует совету, карму отчистить никакого Гоа не хватит.
Выработка ключей тоже необычная: по DH создается общий ключ в 2048 бит, после чего сервер использует из них только 1024, а из оставшихся 512 даже не хранит, "под честное слово" разумеется. И предлагается эти 512 бит использовать для шифрования локальных данных, тогда-де нельзя будет их расшифровать даже расковыряв сервер. А почему просто не взять случайный ключ для локальной копии? А зачем 2048 бит, если используется только половина? А сервер правда ничего лишнего не хранит?
@lexszero Уже один потенциальный вектор нашли http://www.alexrad.me/discourse/a-264-attack-on-telegram-and-why-a-super-villain-doesnt-need-it-to-read-your-telegram-chats.html