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

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

Но что обращает внимание, так это использование. Если есть публичные файлообменники и сайты, где можно размещать ссылки, и всё это без регистрации, то при использовании анонимных сетей почта, да ещё привязанная к одному псевдониму, не нужна.

Если tinyurl перестанет работать, то Алиса может взять пару «вычисленный хэш от текста — url» и инструкции по вычислению логина и пароля, а затем анонимно выложить на любой сайт, наподобие pastebin. Поскольку большинство поисковиков индексируют то, что выглядит как md5-суммы, то Боб может анонимно через поиск найти ресурс, где лежат указания для связи.

Алиса и Боб договариваются о ключе из секретной фразы по безопасному каналу:

$ echo -n "password: Alice and Bob" | openssl md5 | sed -e 's/^.* // 5bc49e846cc42cfeda958875bd343c47

Из этого ключа вычисляется ключ шифрования:

echo -n "5bc49e846cc42cfeda958875bd343c47 0" | openssl md5 | sed -e 's/^.* // d3207bc818ea66dec5c012a84514b735

и ключ вычисления индекса:

echo -n "5bc49e846cc42cfeda958875bd343c47 1" | openssl md5 | sed -e 's/^.* // 625f14c64d0967978a161c773ec55849

Алиса публикует безобидное сообщение и вычисляет его индекс:

echo -n 'Многие пользователи интернета думали о том, как организовать для себя неотслеживаемый канал связи. При этом приходит в голову два решения: стеганография и сети анонимной связи.' | openssl dgst "-sha256" -hmac "625f14c64d0967978a161c773ec55849"| openssl md5 | sed -e 's/^.* // 5bb1d24d22edbb894e94708dc006b812

Затем Алиса идёт на https://tinyurl.com и создаёт ссылку на свой адрес ymnhndy1yjbjzjy5.onion c алиасом 5bb1d24d22edbb894e94708dc006b812

На onion-адрес Алиса кладёт файл, зашифрованный ключом d3207bc818ea66dec5c012a84514b735.

Боб, увидев сообщение Алисы, проводит вычисления аналогичным образом и идёт по ссылке: http://preview.tinyurl.com/5bb.....edbb894e94708dc006b8

Оттуда он узнаёт адрес для скачивания файла http://ymnhndy1yjbjzjy5.onion

Алиса может составить и более сложную ссылку, в которой указать, как Бобу расшифровать адреса скрытой аутентификации Tor. Например, в конфиге своего скрытого сервиса она может разместить опцию HiddenServiceAuthorizeClient stealth Bob. Тогда для Боба на сервере Алисы автоматически создасться cookie-файл вида YmNhNDY1YjBjZjY5ZTZkMm. Алиса не должна публиковать его в ссылке открыто, а зашифровать:

echo "YmNhNDY1YjBjZjY5ZTZkMm" | openssl enc -a "-aes-256-cbc" enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: U2FsdGVkX19imL4Yrp23xFZ9vW/9fneTg7GrEKhDyHU0m0kSmXXT64s1z9HDEVHr

После расшифрования Боб должен будет поместить в свой тор-конфиг опцию

HidServAuth ymnhndy1yjbjzjy5.onion YmNhNDY1YjBjZjY5ZTZkMm

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

Ещё более надёжным является постинг всех url в tinyurl также в шифрованном виде. Чтобы владельцы сервера tinyurl не знали, какие адреса для связи они размещают. А если Алиса поднимет свой скрытый сервис или какой-то другой адрес, то он не будет засвечен специфическими ссылками в tinyurl или в каких-то других сервисах в вебе. Это ещё больше затруднит отслеживание противником связей Алисы и Боба.

После того как Боб аналогичным образом подтвердит скачивание, расшифровку и прочтение файла от Алисы, она может уничтожить свой одноразовый скрытый сервис.

Jun 12 15:18:34.587 [Warning] Onion address has wrong format: 'ymnhndy1yjbjzjy5.onion'
Jun 12 15:18:34.587 [Warning] Failed to parse/validate config: Failed to configure client authorization for hidden services. See logs for details.
Jun 12 15:18:34.587 [Error] Reading config failed--see warnings above.

Unable to connect
Firefox can't establish a connection to the server at ymnhndy1yjbjzjy5.onion.

Обманываете нас, господин unknown. Мы уже собирались запустить torsploit_0day.exe, узнать ваш IP и выслать пативен.

Чтобы не расстраивать в следующий раз буду писать в примерах http://0123456789abcdef.onion/

По идее, как я уже упомянул, сами ссылки и короткие инструкции тоже лучше шифровать, представляя их в форме ссылок вида: http://www.existingfakesite.co.....7hBHXI6WD3.index.htm

Тогда, даже если станет известно, что кто-то размещал ссылки по такой схеме, то их нельзя будет вытянуть поиском. Так, если есть подозрение, что сервер http://0123456789abcdef.onion/ принадлежит Алисе, нельзя будет сказать, что она выкладывала на него ссылки на tinyurl — ведь ссылки зашифрованы неизвестным противнику ключом.

Если действовать осторожно, то вариаций схемы можно придумать множество. Например, два человека встречаются и пишут фразу на бумаге, разучивают, бумагу уничтожают. Затем по первому хэшу (с нулём) от этой фразы находят поиском узел для связи (адрес в твиттере), с твиттера — вычисляя HMAC от сообщения первой ссылкой получают шифрованные инструкции, далее разворачивают скрытые каналы связи.

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

А разгадка проста:

This work was also supported by the Research Council KU Leuven: GOA TENSE (GOA/11/007) and by the IWT SBO SPION project.

Грибы — они такие, да.


Приумножение сущностей без необходимости. С учётом того, что аккаунты в указанных сетях делать анонимно становится всё труднее (требуют авторизацию по телефону, блокируют Tor и т.д.), не вижу смысл завязываться на них; если же такой аккаунт заведён неанонимно на реальное имя, то первый же Боб сможет сделать полный деанон, слив все ключи, кому надо, и тем самым доказав вовлечённость человека в определённые виды коммуникаций.

Есть публичные PGP-ключи на серверах ключей. На них есть uid'ы, где можно прописать любую контактную информацию. Чем это хуже? Если боитесь, что противник заподозрит ключ и начнёт его блокировать, то, с тем же успехом, он может заблокировать и аккаунт в твиттере или ещё где. Наконец, самое главное — как стороны будут искать друг друга, если противник уничтожит все их связные данные? Сервера ключей пока не заподозрены в цензуре, но если считать, что противник может уничтожить всё, то и сервера ключей могут быть отцензурированы или закрыты.

Если на один и тот же ключ вешать некую случайную строку-уведомление, из которого стороны могут вывести, что появилось новое сообщение по такому-то адресу, то такие часто обновляемые ключи с понавешанными уидами будут выглядеть подозрительно. Да и все уведомления будут связаны с ключом-псевдонимом. Можно даже смотреть корреляцию между такими ключами: какой псевдоним предположительно какому отвечает. Это проще, чем блоги и форумы перелопачивать, пытаясь установить закономерность появления сообщений.

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

У сторон есть общий симметричный пароль-ключ k. Если контакт пропадает (у Алисы закрыли бложик), то сторона A может выложить в интернет хэш вида H (k ║ 1 ║ "Alice call Bob trying count 0001").

Когда Боб видит, что с Алисой нет контакта, он ищет в поисковиках этот спасательный хэш. И находит его на какой-нибудь очередной файлопомойке, где рядом лежит шифрованное сообщение от Алисы с инструкциями для связи и адресом нового бложика.

Если и с новым блогом не выйдет, то тогда Боб будет пробовать искать H (k ║ 1 ║ "Alice call Bob trying count 0002") и т.д.

Интересный способ.
Непонятно только как шифровать сами ссылки (неизвестным противнику ключом).

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

Выше приводился код для постинга шифрованного файла-инструкции, но его же можно использовать и для ссылки:

echo "http://[адрес, который надо зашифровать]" | openssl enc -a "-aes-256-cbc" enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: U2FsdGVkX19imL4Yrp23xFZ9vW/9fneTg7GrEKhDyHU0m0kSmXXT64s1z9HDEVHr

Тогда на адресе, вычисленном в предыдущем примере:
http://preview.tinyurl.com/5bb1d24d22edbb894e94708dc006b8

Можно разместить ссылку вида:
http://fake-adress.com/U2FsdGVkX19imL4Yrp23xFZ9vW/9fneTg7GrEKhDyHU0m0kSmXXT64s1z9HDEVHr/decrypt_me.html

Мысль понятна, остаётся лишь вопрос практичности. Всегда ли легко найти нужную случайную строку, не привязанную ни к чему? Хорошо ли поисковик будет такое индексировать? Я часто сталкиваюсь с тем, что даже зная, что я примерно писал, где писал, зная ключевые слова... я, тем не менее, не могу найти соответствующий пост. ☹

MD5-суммы все поисковики собирают специально настроенными ботами и похожие на них последовательности индексируются поисковиками автоматически. Так что при условии их заведомой уникальности, найти их не составит труда. D.J. Бернштейн уже давно метит так все свои работы и они отлично ищутся.

I choose fairly long random IDs, by typing

head /dev/urandom | md5

on BSD or

head /dev/urandom | md5sum

on Linux, to avoid accidental collisions.

Он пользуется BSD? Первый раз слышу. Честно говоря, раньше я почему-то всегда думал, что этот ID — md5-хэш от файла, и публикуется он для того, чтобы иметь возможнсть сразу детектировать, битый файл скачался или цельный.

Как можно хэш от файла разместить внутри этого же файла? :)

Это задача по криптографии «со звёздочкой». Я ранее не знал, что этот хэш ещё и где-то внутри записан. :) Строго говоря, в некоторых случаях это якобы решается, если запись идёт в самый конец файла (зная хэш строки, можно вычислить хэш от "строка+ещё_одна_строка", так сказать, «досчитать хэш»).

P.S. Напомнило классическую задачу «напишите программу, которая распечатывает свой исходник на экран».

@unknown, ты не знаешь? Асики посмотри какие есть https://products.butterflylabs.com То ли ещё будет...