Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 133
Зачем так все усложнять? Вот эти парни уже придумали, запустили и оно отлично работает telegram.org/
Потому что архитектура телеграма — это клиент-серверная архитектура, которая ведет к тому, что все сообщения элементарно перехватываются и заносятся в архив.
См. secure чаты
Они тоже работают через сервер. Это ведет за собой массу проблем. Поскольку никто не знает, что в действительности происходит на сервере, никто не может гарантировать, что на сервере не происходит MITM и полный перехват ваших сообщений.
А как вы гарантируете отсутствие MITM в своей архитектуре? Для установки защищённого соединения требуется хоть какое-то подтверждение подлинности. Если соединение устанавливается в первый раз, это мне представляется серьёзной проблемой — неясно, кто на другом конце провода без каких-нибудь методов аутентификации (видимо, подойдут только сертификаты).
Использовать в качестве идентификатора пользователя хеш его публичного ключа или сам публичный ключ. Чтобы оно было человекочитаемым, можно подключить namecoin.
Я предлагаю использовать аутентификацию в своей архитектуре. Но помимо этого я также предлагаю использовать TOR + P2P, что существенно, на порядки усложняет MITM. Понятно, что 100% защищенности и это не дает, но уже становится очень близко к абсолютной защищенности. Собственно, цель топика — не навязать эту архитектуру, а попытаться привлечь внимание специалистов к проблеме и вместе порассуждать над возможными решениями.
Вы знаете, на самом деле tor предоставляет достаточно мнимую безопасность. 4 года назад одному провайдеру пришли сотрудники… и попросили поставить свое оборудование. Принцип работы обопудования был феерически прост, а весь траффик tor абонентов провайдера был виден как на ладони.
Работало все очень просто… минутку… в дверь стучат…
Работало все очень просто… минутку… в дверь стучат…
Можно гарантировать. Ключ, которым шифруются передаваемые на сервер сообщения, визуализируется в виде цветной у картинки у участников диалога — если они сравнят изображения и убедятся, что они совпадают, то смогут полагаться на то, что подмены ключа не происходит. (Кроме как подменив ключ, расшифровать сообщения сервер не может)
Нет, вы серьезно?
Я тут сегодня дурацким вопросом задавался, но не отвечают(
habrahabr.ru/company/blippex/blog/199336/#comment_6925862
habrahabr.ru/company/blippex/blog/199336/#comment_6925862
отвечу тут
ничего и никого
разве создать что-то на подобие ISO для IT
типа инициативной групы состоящей из кул-хацкеров которых нельзя купить :)
Так а кто мешает собирать из «чистого» публичного кода, а не доверяться бинарникам?
А компилятор вы будете самостоятельно из исходников в исполняемый код компилировать? ;-)
Как раз недавно была статья по этому поводу.
Я бы предложил сначала в маш. кодах набить простейший ассемблер, затем собрать им компилятор простейшего подмножества языка Си, и т.д. В общем почти как в bootstrapping'е :)
Я бы предложил сначала в маш. кодах набить простейший ассемблер, затем собрать им компилятор простейшего подмножества языка Си, и т.д. В общем почти как в bootstrapping'е :)
Если написать приложение например на питоне, то гарантом станут сами исходники.
TOR — не панацея. Относительно легко создать десятки подконтрольных выходных узлов, что приведет к значительному снижению анонимности. Особенно на «странном» траффике.
Выходной узел — это случайный параметр. Учитывая то, что в сети TOR выходных узлов сотни тысяч (поправьте, если ошибаюсь), создать значтительное количество новых подконтрольных узлов может быть довольно проблематично.
Тем не менее, я согласен, что TOR — не панацея, поэтому и предлагая в своей схеме использовать P2P, чтобы существенно увеличить анонимность.
Тем не менее, я согласен, что TOR — не панацея, поэтому и предлагая в своей схеме использовать P2P, чтобы существенно увеличить анонимность.
К сожалению, всего узлов меньше 5000. Выходных и того меньше. Есть несколько узлов со скоростью за сотни мегабайт в секунду, которые внушают подозрения.
P2P + Tor(onion) = TorChat.
P2P + Tor(onion) = TorChat.
Абсолютной анонимности не бывает, но бывает абсолютная защита от прослушки, включая атаку «человек посередине».
Абсолютная? Точно? А что с генерацией ключей?
TorChat, безопасность уровня onion-сайта. Используется асимметричное шифрование, а в качестве идентификатора пользователя используется хеш публичного ключа. Если обе стороны точно знают 16-символьные идентификаторы друг друга, то вклиниться между ними никак не получится. К слову, мой идентификатор: puwjcszo4pgbxa6m.
Так все-таки как генерятся ключи шифрования? CryptGenKey?
Генерируются обычные RSA ключи. Какие функции вызываются, тем более под Windows, не смотрел. Я глубоко не понимаю людей, пекущихся о безопасности и прослушки и при этом использующих Windows.
Есть возможность генерировать ключ, дающий ник, подходящий под паттерн, например, начинающийся определенной последовательностью символов.
RSA используется для аутентификации, а шифрованный канал создается посредством Diffie-Hellman.
Схема установления onion-соединения.
Описание протокола.
Есть возможность генерировать ключ, дающий ник, подходящий под паттерн, например, начинающийся определенной последовательностью символов.
RSA используется для аутентификации, а шифрованный канал создается посредством Diffie-Hellman.
Схема установления onion-соединения.
Описание протокола.
А теперь представим что возможно всего 255 ключей в силу косяка алгоритма генерации…
TorChat сам никаких ключей не генерирует, он «просит» Tor сделать для него onion-сайт и Tor генерирует ключи. Была бы такая дырка, все onion-сайты были бы под угрозой. Да попросту бу имён для них не хватило. Исходники открыты, найдите этот косяк. Ключи можно проверять при помощи функции RSA_check_key из OpenSSL и Tor это делает.
RSA_check_key не проверяет качество P и Q, не проверяет что они не связаны между собой, что они не связаны с чем-то еще и так далее. Она проверяет простоту P и Q и что они при умножении дают N. Длина P и Q и невозможности их предсказать — разные вещи.
Вы не можете ничего сказать о собственно генерации ключей, поэтому не говорите об абсолютности, ОК?
Вы не можете ничего сказать о собственно генерации ключей, поэтому не говорите об абсолютности, ОК?
Хорошо, если предположить, что в RSA, генераторе ключей и генераторе случайных чисел нет уязвимостей, то защита от MiTM абсолютна. Если MiTM не используется, то для абсолютной защиты от прослушки достаточно уверенности в надёжности обмена ключей Diffie-Hellman.
Если исключить маловероятные вещи вроде багов в реализации RSA, то слабым звеном остается только генератор случайных чисел.
Если исключить маловероятные вещи вроде багов в реализации RSA, то слабым звеном остается только генератор случайных чисел.
Даже если вы уверены в корректном обмене ключей, возникают все равно другие проблемы приватности.
Например, я могу помечать трафик специальным образом (например, задерживая его) и таким образом определять, ведете ли вы беседу с определенным пользователем или нет.
Интересно, а как много времени уйдет на то, чтобы расшифровать зашифрованные копии сообщений, которые прошли через сервер, имея в арсенале небольшой датацентр?
Например, я могу помечать трафик специальным образом (например, задерживая его) и таким образом определять, ведете ли вы беседу с определенным пользователем или нет.
Интересно, а как много времени уйдет на то, чтобы расшифровать зашифрованные копии сообщений, которые прошли через сервер, имея в арсенале небольшой датацентр?
В этой ветке обсуждается защита от прослушки, а не анонимность.
Повторюсь: абсолютной анонимности не бывает.
Длины ключей в Tor.
Для симметричного шифрования используются 128-битные ключи, для Diffie-Hellman 320 бит (!), RSA 1024 бита.
Меня смутило, что для Diffie-Hellman используется всего 320 бит. Такого малого варианта даже нет в табличке рекомендованных размеров ключей. Минимум 1024.
Повторюсь: абсолютной анонимности не бывает.
Интересно, а как много времени уйдет на то, чтобы расшифровать зашифрованные копии сообщений, которые прошли через сервер, имея в арсенале небольшой датацентр?Если у вас будет в распоряжении самый эффективный суперкомпьютер, потребляющий ресурсы всей солнечной системы, Вы не сможете перебрать все 256-битные ключи.
Длины ключей в Tor.
Для симметричного шифрования используются 128-битные ключи, для Diffie-Hellman 320 бит (!), RSA 1024 бита.
Меня смутило, что для Diffie-Hellman используется всего 320 бит. Такого малого варианта даже нет в табличке рекомендованных размеров ключей. Минимум 1024.
Symmetric | ECC | DH/DSA/RSA
------------+---------+-------------
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Table 1: Comparable Key Sizes (in bits)
Примерно это я и пытаюсь показать :-) Есть работа израильских маньяков, которые показали что в WinXP количество состояний ГПСЧ около 2^48, если я правильно понял матан. Что много ниже 2^4096 которое как бы следует из vfrcbvfkmyjq (???) длины ключа RSA. Да и даже RSA в теории ломается. Если начать копать в глубь выяснится, что реальное число возможных ключей много меньше чем 2^4096. Ограничения на годность P и Q дополнительно снижают их число.
Длина ника в TorChat (=длина доменного имени в onion) равна 16 символов в base32, это будет 10 байт или 80 бит. Если бы был найден очень быстрый способ генерации ключей и вычисления хеша, то можно было бы подобрать пару ключей под данный ник. Проект Shallot как раз это и делает, перебор ключей под ник, подходящий под заданный паттерн. На странице проекта написано, что для генерации ника из 14 символов из 16 потребуется 2.6 миллиона лет работы 1.5Ghz процессора. Для 16 символов из 16 потребуется ещё в 16^2=256 раз больше времени. (Кстати, почему знаменатель 16, а не 32?) Итого 666 млн лет. Если собрать суперкомпьютер из 666 млн процессоров, то ключ сгенерируется за год. Можно по-другому оценивать: положим, что 1.5Ghz соответствует 4 GFLOPS. Мощность первого суперкомпьютера из top500 за июнь 2013 составляет примерно 56 PFLOPS. Можность сети bitcoin составляет 41819 PFLOPS, что, несомненно, больше. Это 41 млн GFLOPS, то есть примерно в 10 млн раз мощнее 1.5Ghz. Значит, если мощнейшая распределенная сеть вместо работы по поддержанию bitcoin начнет подбирать ключи под чей-то ник, то она подберет этот ключ за 66 лет. Этого можно не опасаться, живя в стране с меньшей продолжительностью жизни, чем 66 лет. Кроме того, за это время ник не раз сменится.
Вычисления верны для случаев, когда в качестве исходных берутся действительно случайные данные. Если в ГПСЧ имеется 2^N внутренних состояний и на основе этого ГПСЧ детерминированным образом генерятся ключи длиной M бит (то есть 2^M возможных ключей), то если N<M не надо перебирать ключи, достаточно перебрать внутренние состояния ГПСЧ.
Есть работа израильских маньяков, которые показали что в WinXP количество состояний ГПСЧ около 2^48, если я правильно понял матан.OpenSSL will attempt to seed the random number generator automatically upon instantiation by calling RAND_poll. RAND_poll seeds the random number generator using a system-specific entropy source, which is /dev/urandom on UNIX-like operating systems, and is a combination of CryptGenRandom and other sources of entropy on Windows.
Генератор псевдослучайных чисел в OpenSSL используется свой, поэтому баги реализации генератора псевдослучайных чисел Windows, уменьшающие его период, не должны влиять. Даже если в CryptGenRandom есть баги, то помимо него используются и другие источники энтропии для сида.
Мне кажется, для генератора случайных чисел достаточно 2^256 (а не 2^4096) бит для периода и начального состояния. 256 бит уже нельзя перебрать и составить какие-либо таблицы, какое число за каким следует. Ключи большей битности (например 4096 > 256) для RSA всё равно будут получаться, так как далеко не каждое сочетание бит в ключе RSA будет корректным ключом. Там же простые числа вовлечены в ключ, а их — подавляющее меньшинство. Поэтому битность RSA ключей больше битности ключей соответствующей стойкости AES или ECDSA, где ключ это почти любое натуральное число. Тогда 256 бит ГПСЧ соответствует 15360-битному RSA (см. таблицу комментарием выше).
И снова встает вопрос о количестве возможных вариантов для seed'а. В любом случае, их число конечно и сдается мне будет меньше числа возможных P или Q. А раз число конечно — значит в теории вскрываемо и ни о какой абсолютности речи быть не может.
When seeding your generators, you should use at least 256 bits (32 bytes) of material. You can verify the required number of bits by grepping the source files for #define ENTROPY_NEEDED.Видимо, сами они тоже используют как минимум 256-битные сиды. Кроме того, OpenSSL может «подмешивать» энтропию по ходу процесса. Ещё PID подмешивается. Кстати, из-за этого в OpenSSL не выйдет использовать сид в качестве бекапа ключа(ей), как это сделано в Electrum.
Так как перебрать 2^256 вариантов нельзя, то даже если возможных вариантов пар ключей RSA всего 2^256, это уже можно считать абсолютно неприступной защитой в солнечной системе. Если спуститься с неба на Землю, то и 128 честных бит уже не по зубам никаким суперкомпьютерам.
Теоретически — можно, это не бесконечное число :-) Вот перечислить все целые числа нельзя, потому что их число бесконечно.
Ладно-ладно. Ключей бесконечной длины не бывает, значит любой ключ можно подобрать, значит абсолютной криптографии не бывает. Поэтому я уточнил, что абсолютным это всё будет только на нашей планете с нашей физикой и нашими временными ограничениями. Если предположить, что против нас выступает эдакий маг, который может узнавать приватный ключ из публичного, то всё это ничего не стоит. А если выступает Бог, способный читать мысли? А если маги и боги работают на КГБ?
А зачем ключ бесконечной длины? Достаточно длины передаваемого сообщения. Вполне себе абсолютная криптография, одноразовый блокнот.
Одноразовый ключ длины сообщения или больше — это было бы абсолютным шифрованием, если бы не вылезала исходная проблема, но только в форме проблемы передачи ключа.
Исходная проблема — передать сообщение непрочтённым и неизменным. Новая — передать его просто неизменным.
Неизменности можно достичь, добавив хеш открытого текста в его конец. Но всё равно использовать такой ключ можно только 1 раз и то только для шифрования, но не для цифровой подписи.
Не понял, как хэш спасёт от намеренных изменений?
Я думаю под хешем имелся в виду MAC (имитовставка).
Я имел в виду sha1sum text >> text
Что мешает МитМу исправить и текст, и хэш?
Он не видит ни текста, ни хеша. Он видит (текст+хеш) XOR одноразовый ключ. Если он поменяет что-то в шифрате, то при вычитании XOR'ом того же одноразового ключа на другой стороне получится текст, не соответствующий хешу. Подправить хеш он не сможет, так как не может прочитать текст или записать хеш. Это защита по большей части не от активного противника, а от потери части сообщения в процессе передачи.
SHA1 не поможет. Злоумышленник, сидящий посередине, может заменить text на eviltext и сделать sha1sum eviltext >> eviltext, на приёмной стороне всё сойдётся. Поэтому и нужен MAC, он же keyed hash.
Проблема передачи ключа остаётся как в симметричном шифровании, так и в случае с одноразовым блокнотом. Разница только в размере ключа, на математику это никак не влияет.
torchat?
Я согласен, Torchat — классная штука. И я её тоже довольно серьезно рассматривал.
Но что меня смущает в нем, что он довольно вяло развивается и, похоже, нет никакой надежды на то, что в нем появится поддержка аудио-звонков.
Технологически я поддерживаю, очень неплохое решение.
Однако моя цель — создать безопасный мессенджер для ежедневного использования, в т.ч. и для простых смертных. Torchat — это все-таки для гиков, согласитесь?
Но что меня смущает в нем, что он довольно вяло развивается и, похоже, нет никакой надежды на то, что в нем появится поддержка аудио-звонков.
Технологически я поддерживаю, очень неплохое решение.
Однако моя цель — создать безопасный мессенджер для ежедневного использования, в т.ч. и для простых смертных. Torchat — это все-таки для гиков, согласитесь?
Не соглашусь. Да, аудиозвонков и других важных фич нет. Но для переписки 1 на 1 подходит идеально, даже для простых смертных.
Для аудиозвонков есть Mumble, который можно пускать через onion или подключаться к обычным серверам через Tor.
Для аудиозвонков есть Mumble, который можно пускать через onion или подключаться к обычным серверам через Tor.
А вот интересно, насколько геморройно реализовать групповые чаты и звонки в TorChat. Кто-нибудь рассматривал такое?
Про групповые чаты есть кое-какие намёки в исходниках TorChat. По крайней мере, автор о таком думал. В принципе, ничего сложного не вижу. Создается отдельный «пользователь», который пересылает все полученные сообщения вместе с ником автора сообщения всем остальным своим контактам. Хочешь подключиться к чату — добавляешься в контакты к этому пользователю-конференции. Такая штука будет даже совместима со старыми версиями торчата. В jabber, кажется, идея конференций похожая.
Про аудиозвонки не знаю. Видимо, можно вкрутить mumble+murmur, а передачу вести через отдельный канал. Можно даже групповые аудиочаты сделать, как в скайпе. Вот только пинг будет побольше…
Что улучшить в торчате, понятно. Найти бы того, кто это сделает.
Про аудиозвонки не знаю. Видимо, можно вкрутить mumble+murmur, а передачу вести через отдельный канал. Можно даже групповые аудиочаты сделать, как в скайпе. Вот только пинг будет побольше…
Что улучшить в торчате, понятно. Найти бы того, кто это сделает.
Одно слово: torchat. Работает через onion. Ничего проще и надежнее нет.
Второе место: jabber+OTR+Tor, но с сильным отставанием, так как можно запросто проколоться, забыв включить Tor или OTR. В torchat проколоться на техническом уровне просто негде.
Третье место: любой чат + noref.org. Мой open-source аналог для развёртывания у себя.
Если бы мне платили биткоин каждый раз, когда я советую torchat, я был бы богат.
Второе место: jabber+OTR+Tor, но с сильным отставанием, так как можно запросто проколоться, забыв включить Tor или OTR. В torchat проколоться на техническом уровне просто негде.
Третье место: любой чат + noref.org. Мой open-source аналог для развёртывания у себя.
Если бы мне платили биткоин каждый раз, когда я советую torchat, я был бы богат.
Про torchat я чуть выше ответил.
Вторая схема очень близка к тому, что я пытаюсь реализовать, за тем лишь исключением, что я предлагаю еще внести сюда P2P, чтобы в конечном итоге схема выглядела как jabber+OTR+Tor+P2P. Согласен, что не очень удобно пользоваться, это вторая проблема, которую я хочу решить, чтобы было не только безопасно, но и удобно.
Вторая схема очень близка к тому, что я пытаюсь реализовать, за тем лишь исключением, что я предлагаю еще внести сюда P2P, чтобы в конечном итоге схема выглядела как jabber+OTR+Tor+P2P. Согласен, что не очень удобно пользоваться, это вторая проблема, которую я хочу решить, чтобы было не только безопасно, но и удобно.
Вторая схема сильно уступает первой, как я писал. Jabber — сложный протокол, который не разрабатывали с оглядкой на анонимность. В Jabber есть куча ненужных и вредных для анонимности вещей вроде заполнения реальных ФИО и местоположения, которые нужно будет отключить. TorChat — простой протокол, в котором нет ничего лишнего.
OTR не нужен, если будет onion. А если не будет onion, то не будет гарантии, что мой человекочитаемый ник кто-нибудь не отнимет.
OTR не нужен, если будет onion. А если не будет onion, то не будет гарантии, что мой человекочитаемый ник кто-нибудь не отнимет.
Автор совершенно не разбирается в вопросе, нашел самую попсовую вещь в плане атак на мессенджеры и сказал — везде есть man in the middle.
А как насчет того, что исключить MIM невозможно без второго средства связи любого для проверки ключей? как все и делают, в общем-то?
В телеграме для этого есть изображение отпечатка ключа, которые можно сверить как угодно. К слову, достаточно надежно уже будет отправить скрин с отпечатом ключа через вк/почту/встретиться живьем. Даже через тот же телеграм скрин отправить и что бы он быстро дошел и автоматизировать подмену ключа было бы сложно — пришлось бы на лету распознавать изображения и подменять ключи и тд, слишком умно для 98%. Остальные 2% могут встретиться живьем и проверить ключи или наговорить их на телефон, к примеру.
Когда были зафиксированы безопасные ключи, то можно ничего не бояться в плане безопасности связи. P2P вообще нужен лишь для того что бы не могли помешать обмену сообщений, но крааайне сомневаюсь, что это затронет этот проект (если он вообще будет пользоваться больше чем одни человеком), для этого правительства различных стран должны начать вас прессинговать. А анонимизация специальная вообще не нужна — покупайте симки без паспорта и краденые смартфоны.
На кой черт людям нужны тормозные xmpp с навернутыми избыточными шифрованиями всякими. В телеграме помимо шифрования объем данных — считанные байты, а тут жирный xml в конце концов, да и сам xmpp его еще утяжеляет.
Выглядит отпечаток вот так (включена арабская локаль): pp.vk.me/c412223/v412223998/9095/FxEOZkE1_LI.jpg
А как насчет того, что исключить MIM невозможно без второго средства связи любого для проверки ключей? как все и делают, в общем-то?
В телеграме для этого есть изображение отпечатка ключа, которые можно сверить как угодно. К слову, достаточно надежно уже будет отправить скрин с отпечатом ключа через вк/почту/встретиться живьем. Даже через тот же телеграм скрин отправить и что бы он быстро дошел и автоматизировать подмену ключа было бы сложно — пришлось бы на лету распознавать изображения и подменять ключи и тд, слишком умно для 98%. Остальные 2% могут встретиться живьем и проверить ключи или наговорить их на телефон, к примеру.
Когда были зафиксированы безопасные ключи, то можно ничего не бояться в плане безопасности связи. P2P вообще нужен лишь для того что бы не могли помешать обмену сообщений, но крааайне сомневаюсь, что это затронет этот проект (если он вообще будет пользоваться больше чем одни человеком), для этого правительства различных стран должны начать вас прессинговать. А анонимизация специальная вообще не нужна — покупайте симки без паспорта и краденые смартфоны.
На кой черт людям нужны тормозные xmpp с навернутыми избыточными шифрованиями всякими. В телеграме помимо шифрования объем данных — считанные байты, а тут жирный xml в конце концов, да и сам xmpp его еще утяжеляет.
Выглядит отпечаток вот так (включена арабская локаль): pp.vk.me/c412223/v412223998/9095/FxEOZkE1_LI.jpg
Вы очень правильно заметили, что аутентификация посредством сверки ключа — очень полезная вещь, поэтому я включил её в предлагаемое решение (OTR используется для дополнительного шифрования всех сообщений между пользователями и целей аутентификации). Однако моя позиция заключается в том, что наличие аутентификации еще не гарантирует вам 100% защищенности.
Как правильно отметили выше в комментариях, абсолютной анонимности добиться очень сложно, но моя позиция заключается в том, что она может быть существенно улучшена. Так в качестве значительного повышения анонимности я рассматриваю P2P и TOR. Возомжно, что-то еще следует сюда добавить.
Как правильно отметили выше в комментариях, абсолютной анонимности добиться очень сложно, но моя позиция заключается в том, что она может быть существенно улучшена. Так в качестве значительного повышения анонимности я рассматриваю P2P и TOR. Возомжно, что-то еще следует сюда добавить.
В телеграме для этого есть изображение отпечатка ключа, которые можно сверить как угодно. К слову, достаточно надежно уже будет отправить скрин с отпечатом ключа через вк/почту/встретиться живьем. Даже через тот же телеграм скрин отправить и что бы он быстро дошел и автоматизировать подмену ключа было бы сложно — пришлось бы на лету распознавать изображения и подменять ключи и тд, слишком умно для 98%. Остальные 2% могут встретиться живьем и проверить ключи или наговорить их на телефон, к примеру.
сказка «Царевна-лягушка»:
…нелегко с Кощеем сладить: смерть его на конце иглы, та игла в яйце, то яйцо в утке, та утка в зайце, тот заяц в сундуке, а сундук стоит на высоком дубу, и то дерево Кощей как свой глаз бережёт.
Сверить, отпечатки, вживую, надиктовать, переслать по почте/вк
Ваша параноя как кот Шредингера :)
На мой взгляд всегда забывается главная деталь — человеческий фактор. Ты хоть обанонимизируйся, а собеседник может тупо синхронизировать всё с гуглом или троянца словить по дурости. Кейлоггер, скриншотер. Что угодно. И тут уже ничего не поделать, вообще.
От кейлоггера/скриншотера защита в принципе может быть, но это намного больше работы чем создание месенджера.
Можно договориться вести переговоры через tails, тогда нужно сильно постараться, чтобы словить что-либо.
В сериале «Прослушка» наркобизнес был построен на пейджерах и таксофонах, которые прослушивали полицейские. Тогда, в 2002 году им давалось это со скрипом, а сейчас прослушка точно поставлена на поток. С другой стороны, сложно представить, как бороться с наркобизнесом, если все участники будут переговариваться через torchat или подобное средство. Могут ведь и Tor запретить…
В сериале «Прослушка» наркобизнес был построен на пейджерах и таксофонах, которые прослушивали полицейские. Тогда, в 2002 году им давалось это со скрипом, а сейчас прослушка точно поставлена на поток. С другой стороны, сложно представить, как бороться с наркобизнесом, если все участники будут переговариваться через torchat или подобное средство. Могут ведь и Tor запретить…
Можно. Можно много чего придумать со степенью надёжности под сотню процентов, если стоит цель приватности для одноразового сеанса связи. Именно по этой причине тотальная прослушка неэффективна против терроризма и преступности. Но когда ты просто хочешь пообщаться с друзьями, родственниками или девушкой — получается досада
Интересно, а если реализовать подход когда каждое сообщение, дополнительно шифруется ключом который меняется при каждой отправке сообщения? (генерируется на основе предыдущего значения, а первое значение генерируется при занесении в список контактов).
Тогда получится что перехватить одно сообщение — не имеет смысла, т.к. его нельзя расшифровать не имея полной истории пересланных до него сообщений — что является дополнительной защитой.
Такой авто-ключ может быть очень длинным (больше чем максимальное сообщение). Тогда при простой перестановке его будет не взломать.
Еще хорошо бы добавить «прозрачный» режим работы (для продвинутых). В этом режиме пользователь видит во что шифруется его сообщение перед отправкой. Тогда он может просто взять такую шифровку и отправить по другому каналу связи (хоть бумажным письмом) и тогда все последующие сообщения будет невозможно расшифровать не если не отслеживать второй канал тоже. Если так использовать несколько разных каналов — то отследить их все будет нереально. А каждое сообщение само по себе не будет иметь смысла…
Тогда получится что перехватить одно сообщение — не имеет смысла, т.к. его нельзя расшифровать не имея полной истории пересланных до него сообщений — что является дополнительной защитой.
Такой авто-ключ может быть очень длинным (больше чем максимальное сообщение). Тогда при простой перестановке его будет не взломать.
Еще хорошо бы добавить «прозрачный» режим работы (для продвинутых). В этом режиме пользователь видит во что шифруется его сообщение перед отправкой. Тогда он может просто взять такую шифровку и отправить по другому каналу связи (хоть бумажным письмом) и тогда все последующие сообщения будет невозможно расшифровать не если не отслеживать второй канал тоже. Если так использовать несколько разных каналов — то отследить их все будет нереально. А каждое сообщение само по себе не будет иметь смысла…
Хорошие предложения.
А какой смысл делать ключ зависимым от предыдущего сообщения?
Это лучше, чем генерить случайный ключ каждый раз?
А какой смысл делать ключ зависимым от предыдущего сообщения?
Это лучше, чем генерить случайный ключ каждый раз?
Чтобы ключ зависел от всей цепочки сообщений, а не от некого мастер-ключа на основе которого генерируются все прочие.
генерируется на основе предыдущего значения, а первое значение генерируется при занесении в список контактов
Получается, что мастер-ключ в Вашем предложении — это «первое значение» ключа, а также все промежуточные.
Я сам слегка запутался. Вроде получается так.
Т1 — ключ случайно сгенерированный при добавлении пользователя в список контактов (первое сообщение) — уникален для каждого контакта.
Тn — ключ случайно сгенерированный для n-го сообщения.
Кn — ключ с помощью которого шифруется n-е сообщение. Не пересылается
При первом сообщении:
1. генерируется ключ Т1 и пересылается второму участнику.
2. Сообщение шифруется ключом Т1 и пересылается
При n-м сообщении:
1. генерируется ключ Тn и пересылается второму участнику.
2. Вычисляется ключ Кn = К(n-1) * Tn
3. Сообщение шифруется ключом Кn и пересылается
Получается что только имея в наличии все ключи T1..Tn — можно вычислить ключ Кn для n-го сообщения и его расшифровать.
Т1 — ключ случайно сгенерированный при добавлении пользователя в список контактов (первое сообщение) — уникален для каждого контакта.
Тn — ключ случайно сгенерированный для n-го сообщения.
Кn — ключ с помощью которого шифруется n-е сообщение. Не пересылается
При первом сообщении:
1. генерируется ключ Т1 и пересылается второму участнику.
2. Сообщение шифруется ключом Т1 и пересылается
При n-м сообщении:
1. генерируется ключ Тn и пересылается второму участнику.
2. Вычисляется ключ Кn = К(n-1) * Tn
3. Сообщение шифруется ключом Кn и пересылается
Получается что только имея в наличии все ключи T1..Tn — можно вычислить ключ Кn для n-го сообщения и его расшифровать.
Или я читал Вас невнимательно, и Вы предлагаете делать доп. ключ действительно зависимым от содержимого ещё и предыдущих сообщений, а не только ключей?
У Вас получается нечто вроде схем по обеспечению «forward secrecy», только наоборот (и в смысле свойств тоже) :)
Случайно не туда написал.
Идея правильная. Хорошо, что он интегрирован с namecoin для получения человекочитаемых ников.
В bitmessage проблема с тем, что он не передает больших сообщений, в т.ч. файлов.
Тогда вы с получателем будете видеть IP-адреса друг друга. Безопасней загружать на файлообменник в зашифрованном виде.
Можно попробовать torrent в I2P. С файлообменником безопаснее, чем напрямую, так как нужно сотрудничество с АНБ и получателя, и файлообменника. Для файлообменника это просто зашифрованный файл, нет повода стучать в АНБ. Для собеседника известна только ссылка на файлообменник, из которой он без АНБ и файлообменника ничего не узнает об отправителе.
Кроме того, если оба собеседника друг другу доверяют, но один из них уже под колпаком, то если он будет передавать напрямую что-либо кому-то, то тот человек тоже попадёт в расстрельный список. А с файлообменником им ещё возиться придется, он может и заартачиться. Если файлообменник использует https, то АНБ не будет знать даже конкретной ссылки на этом файлообменнике, а только время и примерный размер файла. Думаю, не все файлообменники просто так выдадут IP по такой входной информации. А можно ведь и по частям загружать на разные файлообменники вперемежку с мусором.
Кроме того, если оба собеседника друг другу доверяют, но один из них уже под колпаком, то если он будет передавать напрямую что-либо кому-то, то тот человек тоже попадёт в расстрельный список. А с файлообменником им ещё возиться придется, он может и заартачиться. Если файлообменник использует https, то АНБ не будет знать даже конкретной ссылки на этом файлообменнике, а только время и примерный размер файла. Думаю, не все файлообменники просто так выдадут IP по такой входной информации. А можно ведь и по частям загружать на разные файлообменники вперемежку с мусором.
Можно добавить щепотку n2n и толку от IP-адресов мало. Это при условии, что собеседник не хочет атаковать компьютер друга) И то только в момент передачи файла, дальше можно n2n отключить или сделать «очистку» ip-адреса.
Плюс, как вы написали ниже, можно использовать для передачи данных файлов торренты. Даже если это уникальный файл, его можно разбить на N частей и разослать по всем пирам в равных долях. Со временем они все соберутся у собеседника. Но скорость…
Плюс, как вы написали ниже, можно использовать для передачи данных файлов торренты. Даже если это уникальный файл, его можно разбить на N частей и разослать по всем пирам в равных долях. Со временем они все соберутся у собеседника. Но скорость…
Кстати, torchat умеет передавать файлы.
Bitmessage всем хорош, единственное, его легко зафлудить если у вас есть быстрая хэшесчиталка.
А чем тут многим не угодил телеграм? У него открытый исходный код github.com/DrKLO/Telegram изучайте сколько душе угодно. Сообщения шифруются.
p2p и tor это хорошо, не спорю, но у Дурова больше ресурсов для разработки — далеко вы уедете на голом энтузиазме?
Вы все крутые наркоторговцы и оружейные бароны, что боитесь прослушки и перехвата сообщений?
p2p и tor это хорошо, не спорю, но у Дурова больше ресурсов для разработки — далеко вы уедете на голом энтузиазме?
Вы все крутые наркоторговцы и оружейные бароны, что боитесь прослушки и перехвата сообщений?
p2p и tor это хорошо, не спорю, но у Дурова больше ресурсов для разработки — далеко вы уедете на голом энтузиазме?TorChat сделан на чистом энтузиазме и вполне неплохо. Если вдруг станет не хватать пропускной способности Tor, то нужно будет создавать новые ноды. Ещё возможна, хотя и маловероятна, блокировка Tor верховной властью в том числе в цивилизованных странах. Других проблем я не вижу.
Вы все крутые наркоторговцы и оружейные бароны, что боитесь прослушки и перехвата сообщений?«Когда они пришли…»
Смотри, у тебя в душе/параше не прозрачные стены. Не потому что ты там продаешь оружие или наркотики, а потому, что тебе неприятно, когда на тебя голого кто-то смотрит. Аналагочно и с информацией. Я не терорист или преступник, я не полит. деятель, но есть информация, которую я не хочу, чтоб кто-либо знал, кроме определенных людей.
Если вами заинтересуются — даже подобные чаты вас не спасут. Только спрятаться в глубокой деревне в доме без электричества.
Ульбрихтом интересовались и поймали вовсе не сразу и вовсе не через взлом Tor, а на простых общеизвестных проколах. И это при том, что его поимку давно уже требовал сенатор.
Если всё делать правильно и исключительно в сети, то эти средства Вас спасут.
Если всё делать правильно и исключительно в сети, то эти средства Вас спасут.
Исходный код открыт только для Android, нет ни сервера, ни iOS.
У них клиент-серверная архитектура, это ведет за собой множество проблем.
1) Никто не знает, что у них происходит на сервере.
2) Весь трафик через сервер логируется и по первому запросу на флешке выезжает в ФСБ.
3) Трафик идет через сервера, это означает, что его можно помечать (например, задержками) и таким образом сказать, ведете ли вы беседу с определенным пользователем или нет.
4) Вообще взять и изобрести с нуля «супер безопасный» протокол, отбросив все протестированные и документированные наработки в этой области — довольно странное решение. Поле для ошибок существенно увеличивается.
У них клиент-серверная архитектура, это ведет за собой множество проблем.
1) Никто не знает, что у них происходит на сервере.
2) Весь трафик через сервер логируется и по первому запросу на флешке выезжает в ФСБ.
3) Трафик идет через сервера, это означает, что его можно помечать (например, задержками) и таким образом сказать, ведете ли вы беседу с определенным пользователем или нет.
4) Вообще взять и изобрести с нуля «супер безопасный» протокол, отбросив все протестированные и документированные наработки в этой области — довольно странное решение. Поле для ошибок существенно увеличивается.
Вы думаете трафик не оседает на серверах операторов? Или по-вашему сообщения передаются мистическим образом в обход операторов связи с одного телефона на другой?
Про задержки и пометки трафика. Чтобы это делать, скажем, в Tor, нужно отслеживать всех пользователей Tor, а это значит и все ноды тоже. В Tor не скрывают, что если следить за сетью целиком, то анонимность исчезнет. От такой масштабной слежки спасут только сети с флудом, например I2P. Тогда, помечая трафик задержкой, Вы не найдёте единственного подозреваемого, а найдёте пол-сети подозреваемых. В принципе, любая анонимность так работает, поэтому она всегда коллективная, не бывает индивидуальной.
Про задержки и пометки трафика. Чтобы это делать, скажем, в Tor, нужно отслеживать всех пользователей Tor, а это значит и все ноды тоже.Разве недостаточно иметь доступ для слежения за трафиком только узлов, через которые проходит туннель пользователя? Судя по Wiki, их всего-то три на туннель, и имея доступ к более-менее крупному пулу узлов, останется только подождать, пока все три окажутся из этого пула.
Да, это так. Можно даже не следить за нодами, а самим запустить сотню-другую своих узлов и вести на них полные логи. Возможно, самые быстрые узлы это и есть их узлы. Вот почему анонимности, даже близкой к абсолютной, не бывает. Слухов ходит масса. Если забивать в гугл имена самых быстрых нод, можно много интересного про них найти. Можно усложнять и усложнять им задачу, но пока они могут творить, что захотят, они всегда будут сильнее.
Ну, в i2p задачка по отслеживанию посложнее, например, как я понимаю.
Аргументы
Но это уже не «скачал→запустил→попользовался→закрыл».Мало того, что длина туннеля настраиваемая и вообще рандомизируемая, так ещё и чесночная маршрутизация пакетов, раздельные туннели на вход и выход, несколько туннелей для доступа к одному и тому же узлу и т.д., плюс каждый клиент = роутер, так что даже тайминг-атаки становятся чуточку сложнее.
Нужно сделать «скачал→запустил→попользовался→закрыл». И желательно без Java.
Тогда кто-то должен будет содержать за вас постоянно действующую инфраструктуру. И угадайте, кто будет готов давать деньги за то, чтобы её контролировать? В конце концов, приучили же пользователей скачивая c торрент-трекеров с рейтингами оставаться на раздаче, а в i2p-роутере Torrent-клиент встроенный (I2PSnark), неплохой стимул держать роутер включенным, если будет контент.
Насчёт «без Java» — процесс идёт (зеркало(?)). Надо бы за него награду назначить, как за Bitcoin-I2P была.
Насчёт «без Java» — процесс идёт (зеркало(?)). Надо бы за него награду назначить, как за Bitcoin-I2P была.
Здесь легко реализуется атака Man In The Middle, когда сервер притворяется клиентом, которому предназначается сообщение и получает сообщение в незашифрованном виде, хотя клиент думает, что сообщение может быть прочитано только конечным получателем
Не понятно как это должно работать если закрытый ключ, необходимый для расшифровки, находится только у получателя.
Главное — убедится что открытый ключ тоже от получателя, а не от посредника.
del
Иногда сообщения пытаются шифровать и отправить их на сервер уже шифрованными, но работает ли это в действительности? Здесь легко реализуется атака Man In The Middle, когда сервер притворяется клиентом, которому предназначается сообщение и получает сообщение в незашифрованном виде, хотя клиент думает, что сообщение может быть прочитано только конечным получателем.
Что за бред Вы пишите? Уже всё давно придумано. Асимметричное шифрование. Каждый клиент генерит публичный и секретный ключ. Публичный передаётся другому пользователю. Этим ключом будут шифроваться сообщения получателю. Перехват такого сообщения (даже зная публичный ключ) не даёт возможности восстановить зашифрованное сообщение. Ну, если не рассматривать случай попыток некоего суперкомпьютера взламывать именно Ваше сообщение в течение определённого (возможно, довольно длительного) времени. Поставьте себе ассиметричный ключ длинной 2048 бит и успокойтесь.
Публичный передаётся другому пользователю.Вот на этом этапе MitM-атака и производится.
В надежных схемах публичный ключ (или его хеш) передается через надежный или хотя бы независимый канал.
Приведите пример такого надёжного канала для интернет-мессенджера, пожалуйста.
Лично я переписываюсь в основном с теми людьми, кого знаю лично (в реальной жизни). У меня есть возможность позвонить им и продиктовать ключ или встретиться и передать его на бумаге. Другой вариант — продиктовать ключ в любом голосовом чате, который разворачивается в пять-десять комманд на своей VPS-ке.
Конечно, этот опыт нельзя экстраполировать на все отношения, но с другими людьми у меня пока нет необходимости шифровать сообщения.
Конечно, этот опыт нельзя экстраполировать на все отношения, но с другими людьми у меня пока нет необходимости шифровать сообщения.
Мм, понятно. Все варианты подразумевают уже имеющиеся средства по идентификации вас (вашего голоса, внешности, etc)? И в любом случае не подразумевают вашей анонимности (псевдонимности) для собеседника.
Кстати, бывает так, что имя человека никто не знает, а записи с его голосом находятся в общем доступе.
Да, но и топик как бы о защищенном от третьих лиц, а не о анонимном сервисе. Топикстартер в списке ведет речь именно о личных сервисах переписки, где, так или иначе, известен получатель и отправитель (Viber, Skype, SMS, WhatsApp), хотя бы на уровне индетификатора.
Для анонимных чатов индентификаторы, имхо, лишнее, если они не являются результатом работы белого шума, т.е. случайной величиной.
Для анонимных чатов индентификаторы, имхо, лишнее, если они не являются результатом работы белого шума, т.е. случайной величиной.
Другой чат, SMS (не успеют подделать, если заранее не знают номеров телефона), аудио-звонок (голос пока тоже не умеют подделывать, по крайней мере на лету), внешний pastebin-like сайт. Суть в том, чтобы автоматический MiTM был сбит с толку (не будут же туда забивать все сайты с UGC), а ручной бы не успел просечь фишку и быстро внести нужные изменения.
Если собеседник вас не знает, то голос и подделывать не нужно — на ваш звонок ответит один сотрудник, а другой позвонит вашему собеседнику.
Вообще идея с использованием неожиданного канала хороша, но, почему-то, напоминает мне security through obscurity.
Вообще идея с использованием неожиданного канала хороша, но, почему-то, напоминает мне security through obscurity.
Если собеседник вас не знает, то голос и подделывать не нужно — на ваш звонок ответит один сотрудник, а другой позвонит вашему собеседнику.Мне кажется, что на лету вклиниться в телефонный разговор они не могут даже сейчас. По закону им нужно заранее получать ордер даже на прослушку. На практике они не соблюдают закон, это понятно, но даже технически такой перехват звонка мне кажется невозможным.
security through obscurityОно и есть.
Нужно всегда ещё как-то проверять. Например в OTR есть возможность подтвердить через секретный вопрос, ответ на который знает только собеседник (девичья фамилия паспорта не подойдет, разумеется). Если же Вы и собеседник не знаете друг о друге ничего, то даже услышав его голос, остаётся только надеяться, что он не является сотрудником АНБ.
А почему именно Tor, а не i2p?
В такое приложение скорее всего мало кто поверит даже мало кто будет ковырять исходники… а на голом энтузиазме вообще мало кто узнает о его существовании.
Тем кому нужна высокая степень приватности и отлично обходятся разными способами, например для комфортной постоянной приватной работы в ставится свой Jaber сервер, VoIP сервер, с открытым кодом (asterisk) и работают с ним через VPN/IPSec, так работают многие компании, даже банки.
Есть масса других простых и надежных сбособов, типа как всяческие анонимайзеры, прокси, и т.п., зависит от глубины параноидальности!
Тем кому нужна высокая степень приватности и отлично обходятся разными способами, например для комфортной постоянной приватной работы в ставится свой Jaber сервер, VoIP сервер, с открытым кодом (asterisk) и работают с ним через VPN/IPSec, так работают многие компании, даже банки.
Есть масса других простых и надежных сбособов, типа как всяческие анонимайзеры, прокси, и т.п., зависит от глубины параноидальности!
Скажите, пожалуйста, а вы смотрели в сторону en.wikipedia.org/wiki/Cryptocat?
Я не уверен насчёт p2p архитектуры, а в остальном вполне сносно.
Кроме того в нём уже реализован групповой чат.
Если там всё построено на клиент-серверной архитектуре, то проще будет добавить поддержку p2p прямо в этот проект.
Я не уверен насчёт p2p архитектуры, а в остальном вполне сносно.
Кроме того в нём уже реализован групповой чат.
Если там всё построено на клиент-серверной архитектуре, то проще будет добавить поддержку p2p прямо в этот проект.
Если вам действительно нужна секретность, то создайте свой язык общения и только вы поймёте друг-друга. (феня, навахо, одним вам известные объекты иносказательно
А вот если вам постоянно со всеми собеседниками надо вести защищенные переговоры — то как то даже страшно такому персонажу подсказывать.
А вот если вам постоянно со всеми собеседниками надо вести защищенные переговоры — то как то даже страшно такому персонажу подсказывать.
Обменяться PGP-фингерпринтами проще и надежнее, чем придумывать свой язык общения. И можно общаться не только с одним человеком, а со всеми желающими.
А вот если вам постоянно со всеми собеседниками надо вести защищенные переговоры — то как то даже страшно такому персонажу подсказывать.В реальной жизни ведь можно сказать на ухо человеку, и никто не пугается, когда люди так делают. Вправо «сказать на ухо» в Интернете или по телефону такое же естественное. Я думаю, дело в том, что в Интернете или по телефону прослушивать намного проще, чем в реальной жизни, и они не хотят лишиться прослушки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проектируем вместе защищенное приложение для обмена сообщениями