LINUX.ORG.RU
решено ФорумTalks

В Telegram, Kontalk, OTR End-to-End шифрование есть (а на самом деле нет)

 , ,


1

2

автор принял вещества и покинул тред

Ведь в общем случае явно не сравнив ключи клиентов, нельзя гарантировать, что не осуществляется MitM. Вот взять Bitmessage, tox и подобное. Там адрес уже содержит ключ, и его не подменить не подменяя адреса.

Но в таком случае случае доверять End-to-End шифрованию в таких мессенджерах нельзя. Нельзя безопасно обменяться ключами по номеру телефона или домену сервера.

Но тогда с чего всякие EFF подтверждают безопасность? И что стоят слова Сноудена, который сам пострадал от того, что недооценивал необходимость приватности и анонимности?

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



Последнее исправление: Esteban_Garcia (всего исправлений: 2)

Ответ на: комментарий от multihead

MITM - мне в бровзер всобачили левый ключ, весь трафик который идёт ко мне расшифровывают изменяют TOX ID и зашифровавают. Я у сябя в профиле ЛОР вижу свой ИД, но ты уже совсем другой...

Но от меня ты в этом случае ответа не получишь. Соединение установить не получится. Нужен MiTM в двух местах.

Esteban_Garcia
() автор топика
Ответ на: комментарий от Esteban_Garcia

А вот был бы ты не multihead, а 1BQ9qza7fn9snSCyJQB3ZcN46biBtkt4ee, то личной встречи не потребовалось бы. Более того, она была бы даже вредна.

Да, держать открытую часть ключа в идентификаторе плюс.

На счёт вреда встречи, палка с двух концов:

1 Если ключ в ID и интересен абстрактный человек владелец ID, то да ты прав.

2 Если Васе надо именно Маша, то необходима предварительная личная встреча для обмена публичными ключами или ID их содержащими.

multihead
()
Ответ на: комментарий от Esteban_Garcia

Но от меня ты в этом случае ответа не получишь. Соединение установить не получится. Нужен MiTM в двух местах.

Получу, хватит одного MITM, оно два соединения откроет, одно к тебе другое ко мне. Само посредине будет не только шпионить но и изменять содержимое, включая ID.

multihead
()
Ответ на: комментарий от Esteban_Garcia

В TOX MITM не возможен. Там нет удостоверяющего центра который можно нагнуть и идентификаторов которые можно подменить.

Если два пользователя TOX обменялись TOX ID который содержит открытую часть ключа MITM не возможен в принципе! ТОХ не разрешает коннектится двум устройствам с одинаковым ID!!!

Речь шла о ЛОРе, с использованием ssl и удостоверяющего центра, для обмена информацией. В этом случае MITM легко реализуемая.

multihead
()
Ответ на: комментарий от Esteban_Garcia

Это в оригинальной, канонической реализации TOX! Когда идентификация идёт по TOX ID.

Если пользоваться сторонними сервисами tox-DNS то их уже можно нагнуть, подменить TOX ID и сделать MITM...

Вот почему только личный обмен публичными ключами (ID содержащими открытую часть ключа) гарантирует Васе что он общается с Машей и отсутствие MITM!

multihead
()

И что стоят слова Сноудена, который сам пострадал от того, что недооценивал необходимость приватности и анонимности?

Как он пострадал? По-моему, вполне успешно убежал из пиндосии.

pacify ★★★★★
()
Ответ на: комментарий от Esteban_Garcia

Ещё по теме шифрования, можешь глянуть используемую в TOX «Совершенная прямая секретность» (Perfect forward secrecy) и протоколы с помощью которых она реализована:

  • curve25519 для обмена ключами;
  • xSalsa20 для симметричного шифрования;
  • Poly1305 для MAC.

Совершенная прямая секретность - гарантирует что если Вася с Машей пообщались, их сесию бит в бит записали шпионы АНБ, потом пришли к Васе и Маше, изъяли профиль TOX (содержит секретные ключи), с помощью методов ректального крыптоанализа узнали пароль Васи и Маши, защищающие их профили TOX и секретные ключи, то все равно расшифровать записанный разговор не удастся! Так личная жизнь и общение Васи и Маши останутся в тайне.

multihead
()
Ответ на: комментарий от kinik

Может этот список понятен: sha256, sha512 вот Poly1305 тоже хеш функция.

multihead
()
Ответ на: комментарий от kinik

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

multihead
()
Ответ на: комментарий от kinik

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

multihead
()
3 июля 2017 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.