В мессенджере без контроля ключей,шифрование E2E (в т.ч.Telegram?)-фикция?

WhatsApp, который достаточно приятный, имеет единственное назначение, не занимается bullshit-маркетингом, т.е. не считает меня за быдло, и, наверное, относительно безопасный.

Как можно называть телегу быдлограмом и верить в безопасность васапа, принадлежащего фейсбуку ? Васапом пользуется больше миллиарда хомячков там НЕ МОЖЕТ не быть зондов.

Роскомнадзор VS DeltaChat (комментарий)

если вкрации по той ссылке, британский майор попросил фейсбук встроить в васап бэкдор, который позволит незаметно подключаться к беседе выбранных хомячков ДО е2е шифрования, сначала тебя прочитают, проанализируют, а потом будет секурно секурно е2е))

насчет телеграма +/- та же шляпа вид сбоку - почему нет секретных чатов в десктоп клиенте ? видимо потому что в десктопах зондами не настолько удобно пользоваться и вообще можно допотопный thinkpad взять без IntelME.

забугорные красноглазики сейчас агитируют за Signal, а совсем красноглазые за Session

Как ты умудрился ответить на комментарий, который даже не читал?

https://sporaw.livejournal.com/678790.html Тут говорят, что Session без GApps не пашет.

а как тогда десктопный клиент работает без гапсов ?

Взял две лопаты без gaps, поставил туда этот sessions, добавить контакт через сканирование qr можно, но при отправке сообщения пишет, что ждет подтверждение от собеседника и на этом все. Может не в GAPPS конечно дело.

А насчет десктопного,даже не смотрел...если там как у Signal - electron поделие, которое работает только в паре с мобильным клиентом, то нафиг оно такое надо?

WhatsApp

относительно безопасный

Сервис, который палит личную информацию через телефонный номер это не просто дырарешето, это позор ящитаю.

Да какая разница в чём с девчонками общаться или скинуть брату фотку новой шикарной бороды?

Как я выше написал, важные контакты у меня в jabber.

Тут даже не про безопасность, а про отношение к пользовательским персональным данным. Тебя по посту в вк любой дядя майор может вычислить даже будь у тебя европейский тел. номер. Это яхз как надо и кому банально продаться, чтобы так подставлять своих юзеров.

Но я не пользуюсь ВК, Фейсбуком тоже. В вотсапе у меня только телефон, имя и ничего важного. Вообще проблем не вижу.

А кто-то пользуется вк. Даже имя/фамилия через номер это огромная, а главное, международная утечка данных. Если тов майор раньше мог узнать о тебе всё через российский номер (что нормально), то теперь ему и европа не запретит тебя разыскать и закрыть при первом пересечении границы снг за репост вконтактике.

Раз уж я не пользуюсь вконтактиком, бояться мне нечего.

DH предназначен для формирования общего секрета, если нет доверия каналу.

DH без подписи ключевого обмена защищает только от пассивного наблюдателя, а mitm - это активная атака.

И да, телега может митмить.

И да, телега может митмить.

Чтобы клиенты секретных чатов не заметили? Как?

А что мешает сделать скрин сторонним приложением и подменить ключ?

Блин в нашем мире анонимны только те кто не пользуются ни интернетом, ни телефоном, ни банковской карточкой, а так же не общаются с людьми которые это делают, так что расслабтесь и не переживайте по этому поводу )))

Я и не переживаю, у меня всё ок. Просто не пользуюсь всяким мусором. Анон, вон, переживает.

Я немного совсем не понял о чём речь?

В официальном клиенте вы можете посмотреть отпечаток и графическое представление общего ключа секретного чата. Сделать скриншот или скопировать в буфер обмена отпечаток вы не можете, чтобы у вас не было соблазна для сверки использовать тот же самый секретный чатик.

Т.е. вы можете созвониться и диктуя буковки сверить отпечатки или сфоткать и отправить графическое представление другим смартфоном. Или просто, находясь рядом, сравнить на экранах двух смартфонов.

Как и что вы собрались подменять, какие ключи?

Да недопонимаю поэтому и спрашиваю. т.е. если мы передаем ключ по открытому каналу который скомпрометирован это не является дырой?

ПыСы про асинхронное шифрование в курсе.

ПыСы про асинхронное шифрование в курсе.

Его здесь нет.

т.е. если мы передаем ключ по открытому каналу который скомпрометирован это не является дырой?

Ключ никуда не передаётся.

Так как мы недоверяем каналу, то для создания общего секретного ключа используем DH.

Там математика простая, в вики доступно описано. Используя открытые всем параметры (в том числе Мелиссе и Махмуду) Алиса и Боб, каждый на своём устройстве вычисляет ключик, который никогда не покидает клиент.

Опасаясь, что Мелисса и Махмуд всё-таки поучаствовали в процессе (активный митм), Алиса и Боб должны убедиться в том, что у них получился один и тот же результат. Естественно они не будут сличать 256 бит ключа, а сверяют отпечаток (хеш) или иное представление этого секрета (по ним нельзя восстановить сам ключ), которые формируются у каждого на клиенте без всякого участия сервера.

И сверять они это должны по другому каналу, не по тому по какому они обменивались параметрами. Секретный ключ нигде не светится.

Так я и говорю имея хэш дешифровать ключ нельзя?

Спасибо что разжевали.

так тебя рядом нет. я только на таких как ты это делаю - "так иди поблюй

Так иди поблюй на таких как я, кто рядом. Не видать? Выходи на блёвохоту — стереги и нападай на них своей оперой рыголета.

Для deep-purple

https://www.youtube.com/watch?v=OorZcOzNcgE Deep Purple - Child In Time - 1970

Показывать одному клиенту свой ключ и говорить, что это ключ другого клиента и наоборот. То есть вместо одного сквозного DH иметь два - от каждого клиента к точке MitM. Говорить клиентам показывать одинаковый хеш. Всё.

Показывать одному клиенту свой ключ и говорить, что это ключ другого клиента

Ключ один - общий. И «показывается» свой, а не собеседника.

Говорить клиентам показывать одинаковый хеш

Клиенты открытые, проверяется.

Собеседники не сверяют ключ по тому же каналу, по какому они его создают, это не автоматическая операция. Точка.

Клиенты открытые, проверяется.

Я не нашёл реализации e2e в тех исходниках, которые были опубликованы. Покажете ссылку на код e2e в телеграме?

Ключ один - общий. И «показывается» свой, а не собеседника.

Для того, чтобы DH работал для защиты от активного атакующего, ключевой обмен должен быть подписан. Как правило, он подписывается ассиметричным крипто. Вот этот публичный ключ и можно показать в случае MitM.

Покажете ссылку на код e2e в телеграме?

Навскидку - https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/messenger/SecretChatHelper.java

Описание словами - https://core.telegram.org/api/end-to-end

Для того, чтобы DH работал для защиты от активного атакующего, ключевой обмен должен быть подписан

Можно же просто сверить результат, без подписанного обмена:

https://telegram.org/faq#q-what-is-this-encryption-key-thing

Q: What is this ‘Encryption Key’ thing?

When a secret chat is created, the participating devices exchange encryption keys using the so-called Diffie-Hellman key exchange. After the secure end-to-end connection has been established, we generate a picture that visualizes the encryption key for your chat. You can then compare this image with the one your friend has — if the two images are the same, you can be sure that the secret chat is secure, and no man-in-the-middle attack can succeed.

Newer versions of Telegram apps will show a larger picture along with a textual representation of the key (this is not the key itself, of course!) when both participants are using an updated app.

Always compare visualizations using a channel that is known to be secure — it's safest if you do this in person, in an offline meeting with the conversation partner.

за Signal И привязка к номеру телефона их не смущает никак?

)))

Ты давно из вконтакта выполз?

Можно же просто сверить результат, без подписанного обмена:

я вот тут писал: Говорить клиентам показывать одинаковый хеш.

Навскидку - https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/messenger/SecretChatHelper.java

я посмотрел. вот это - DH: https://github.com/DrKLO/Telegram/blob/f120800a7f6ba6b6d83bed42e1c8d662170b58cc/TMessagesProj/src/main/java/org/telegram/messenger/SecretChatHelper.java#L1671

и он странный. почему основание и модуль секретные? почему в https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/messenger/SecretChatHelper.java#L1681 он посылает соль, которая передаваться не должна?

зачем вот тут усекается сообщение https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/messenger/SecretChatHelper.java#L1675 которое и так по модулю?

как можно вообще разбираться в этой портянке, где нет ни одного комментария, кроме заголовка?

как можно вообще разбираться в этой портянке

А что не так?

Алиса начинает чатик.

Смотрим startSecretChat

1. Обоим абонентам известны некоторые два числа g и p

 TLRPC.messages_DhConfig res = (TLRPC.messages_DhConfig) response;

В res параметры DH - g, p и! случайная серверная строка random

If the client has an inadequate random number generator, it makes sense to pass the random_length parameter (random_length> 0) so the server generates its own random sequence random of the appropriate length. Important: using the server’s random sequence in its raw form may be unsafe. It must be combined with a client sequence, for example, by generating a client random number of the same length (client_random) and using final_random := random XOR client_random.

2. Оба абонента генерируют большие случайные числа: Алиса — число a (salt)

final byte[] salt = new byte[256];
for (int a = 0; a < 256; a++) {
    salt[a] = (byte) ((byte) (Utilities.random.nextDouble() * 256) ^ res.random[a]);
}

Нюанс с XOR скорее вызывает недоумение, чем подозрение.

3. Затем Алиса вычисляет остаток от деления A и пересылает его Бобу

BigInteger i_g_a = BigInteger.valueOf(getMessagesStorage().getSecretG());
i_g_a = i_g_a.modPow(new BigInteger(1, salt), new BigInteger(1, getMessagesStorage().getSecretPBytes()));
byte[] g_a = i_g_a.toByteArray();
if (g_a.length > 256) {
    byte[] correctedAuth = new byte[256];
    System.arraycopy(g_a, 1, correctedAuth, 0, 256);
    g_a = correctedAuth;
}
...
chat.a_or_b = salt;

Переходим к processAcceptedSecretChat

4. Алиса на основе имеющегося у неё a (salt) и полученного по сети B вычисляет ключ

BigInteger i_authKey = new BigInteger(1, encryptedChat.g_a_or_b);
...
i_authKey = i_authKey.modPow(new BigInteger(1, encryptedChat.a_or_b), p);
byte[] authKey = i_authKey.toByteArray();

почему он посылает соль, которая передаваться не должна?

По контексту смотрите.

Потому что это забивание мусором протухших данных, ничего никуда не передаётся.

я вот тут писал: Говорить клиентам показывать одинаковый хеш

Я тоже писал: сервер не участвует в генерации a и b и вычислении секрета, хеш тоже высчитывается на стороне клиента.

Как вы представляете «Говорить клиентам показывать одинаковый хеш»?

я посмотрел. вот это и он странный

Потому что это подготовка к вычислению нового ключа, когда старый протух.

ok, убедил

Оно реально рандом для генерации ключей с сервера запрашивает?

Оно реально рандом для генерации ключей с сервера запрашивает?

нет. оно генерирует его локально, но вот тут у меня ощущение, что он отправляет секрет куда-то: https://github.com/DrKLO/Telegram/blob/f120800a7f6ba6b6d83bed42e1c8d662170b58cc/TMessagesProj/src/main/java/org/telegram/messenger/SecretChatHelper.java#L1681