Voice over TOR

Но по вашему описанию не смог понять, сколько экземпляров Tor у Вас запущено и сколько HS поднято

тор разумеется один, HS – два. Но существенно не это, а то что невозможно дозвониться до онионфона на нестандартном порту.

работает ли тест звука (без соединения) на онионфоне?

Как тест сделать, просто в порт (17447) звук направить?

статически линкованный бинар работает на x86_64, и что собирается корректно на этой платформе в gcc в режиме 32

Напишите, как собирали для Linux 32-бит. Пробовал

env CFLAGS=-m32 make

выдаётся ошибка

ld: Relocatable linking with relocations from format elf32-i386 (b64.o) to format elf64-x86-64 (builtin.o) is not supported

Я собираю make, т.к. у меня платформа 32 бит. Как отписал мне коммитер, переделавший сборку, в вашем случае собирать так:
CC="gcc -m32" LD="ld -melf_i386" make

невозможно дозвониться до онионфона на нестандартном порту

Проверю, пока не могу ничего утверждать.

HS – два.

Надеюсь, в torrc так:

HiddenServiceDir /usr/local/etc/tor/oph0 HiddenServicePort 17447 127.0.0.1:17447 HiddenServiceDir /usr/local/etc/tor/oph1 HiddenServicePort 17448 127.0.0.1:17448

в каждой из папок Tor-ом будет создан файл hostname, где находится онион-адрес каждого из HS.

Как тест сделать

Запустите онионфон и выполните комманду -RV. (Если используете Web-GUI, то подключитесь и установите флажок голосового теста). После этого передача включается/оключается нажатием клавиши Ввод или удержанием клавиши Tab. В Web-GUI – ужержанием кнопки "Раговор/пауза".

ПС: Обратите внимание: после установки соединения режим передачи отключен! Для получения голосовой связи оба абонента должны нажать Ввод или удерживать Tab.

ППС: до меня дошло – вы пытались тестировать 64-битный бинар? Забудьте, я вообще не понимаю, как он мог работать. Позже дойдут руки и до 64, но пока что я по глупости (по аналогии с разницей 16 и 32) посчитал, что тип int в 32 и 64 разный, а long – одинаковый (32). Оказалось в точности наоборот. Кроме того, надо перепроверить всю арифметику указателей. По уму такие штуки надо держать в уме еще на этапе проектирования, но я тогда о сборке на 64 вообще не подумал. Позже поправлю, но сейчас даже не стоит и пытаться так собирать.
Собирайте в 32-битном режиме, он будет корректно работать и на 32, и на 64 платформе.

С указанными опциями для 32 собирается на 64, хотя и не без труда. Пришлось установить библиотеки glibc, libgcc и alsa-lib для архитектуры i686. А для расшаривания звуковых устройств требуются также библиотеки alsa-plugins-pulseaudio и pulseaudio-libs, тоже для i686. Кстати, не уверен, что для готовой сборки на 64 можно будет обойтись без последних зависимостей (и тех от которых они сами зависят).

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

В общем программа на Linux x86_64 рабочая и в принципе решает проблему безопасного голосового общения посредством Tor. Для более простой установки лучше чтобы нормально собиралась на 64-битной системе. По-моему мнению, имеет смысл довести до ума движок, а не тратить силы на GUI. Если получится законченный демон с продуманным командным интерфейсом, может кто-нибудь поможет в написании GUI.

Пришлось установить библиотеки

Вот за что я люблю Виндоус...

проблема с дозвоном на онионфон на нестандартном порту остаётся

ОК, поправлю: скорее всего, где-то жестко прописал 17447 и опустил из виду, когда лепил конфигурирование.

лучше чтобы нормально собиралась на 64-битной системе

Этим сейчас товарищ и занимается.
На сколько я в курсе (сам не пробовал), статически слинкованный на 32-битной платформе бинарник работает на 64-битной платформе без дополнительных зависимостей. Как будет готова V02a, соберу и представлю в пакете. По идее, достаточно будет разархивировать и запустить (по аналогии с TBB).

имеет смысл довести до ума движок

А этим как раз сейчас я занимаюсь. Тестирую, убираю мелкие баги и т.д. Пока релиз V02a чуть отложил из-за бага в верификации онион-адреса отправителя (не запускалась автоматически на старте после изменения в IKE), поправил, сейчас тестирую.

а не тратить силы на GUI

Это было, скажем так, временное шатание. Если и тратить время, то на Qt-версию TorChat GUI, в которую встраивать онионфон + видео.

статически слинкованный на 32-битной платформе бинарник работает на 64-битной платформе без дополнительных зависимостей.

Собранный мной бинарный файл тоже работает с дефолтными настройками. Но если указать plug:default в audiocfg, то при запуске oph выдаст сообщение об ошибке. Чтобы расшарить звуковое устройство, т.е. пропускать через pulseaudio, а не напрямую, нужна соответствующая библиотека, которая при сборке не используется.

достаточно будет разархивировать и запустить (по аналогии с TBB)

Многим приверженцам анонимности запускать готовый бинарник религия не позволяет. Самая лучшая установка это make. Тем более что на 64 нормально собирается и на вид работает также как 32, только звука нет. Если основная сложность в портировании кодеков, то не обязательно наличие их всех, пусть будет хотя бы один.

Ещё немного потестировал программу, несколько наблюдений

1. При отправке текстовых сообщений не печатаются кириллические символы. И кстати, если онионфон может работать как IM, то зачем нужен торчат?

2. Задание в conf.txt кодека VoiceCodec никак не учитывается при запуске. Например, указал VoiceCodec=3, а в oph -С? выдаёт 7 (по умолчанию). Номер вокодера вроде учитывается.

Для опций лучше сделать комментарии в файле, смысл не всех из них ясен. В описании не сказано, что означают -Q{0,1,2} – программа на них реагирует, но совсем понятно поведение.

Раз распознавателя речи нет, то какой вокодер лучше использовать, чтобы создать максимальные сложности для идентификации говорящего. В PDF-файле написано, что самый безопасный это безголосый (шёпот). Не могли бы перечислить их в порядке убывания безопасности? Если субъективно судить по выложенным тут образцам, я бы их упорядочил так: шёпот – низкие – робот – высокие.

На Linux было бы привычней (да и на Windows наверное тоже), если исполняемые файлы можно было поместить в каталог PATH, а конф. файл при их запуске читался из домашнего каталога пользователя который запустил программу. Лог-файл, содержащий список вызовов и их статус (принятые/непринятые) тоже бы не помешал. Например $HOME/.onionphone/{onionphone.conf,onionphone.log} (audiocfg и conf.txt можно в один файл объединить).

Разве представляет какую то сложность наклепать пару формочек с кнопками?

нужна соответствующая библиотека

Да, нужен alsa-plugins-pulseaudio, эмулирущий alsa-интерфейс (используемый онионфоном) на установленном в системе pulseaudio. Но это в любом случае, не зависимо от сборки в 64 или 32. Многие программы (особенно более старые, не работающие напрямую с pulseaudio) используют такой подход.

Тем более что на 64 нормально собирается и на вид работает также как 32, только звука нет.

Работаем над этим, думаю, все будет.

При отправке текстовых сообщений не печатаются кириллические символы.

Есть такое, и я пока не могу сказать, как это побороть. Дело в том, что я переключаю консоль в raw-режим для возможности перехвата стрелок с целью навигации по меню, Tab в качестве тангенты (иначе удержанием не получится). Без ncurse пришлось извращаться и писать собственную обработку сырых кодов клавиш. Конечно, можно это отключать (тогда не будет работать тангента и консольное меню, но будет кириллица), подумаю.
Через GUI киррилица, кстати, проходит (браузер кодирует строку в юникоде, и с него же отображает). Но максимальная длина строки вдвое меньше – 126 символов вместо 252 в латинице.

зачем нужен торчат

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

Задание в conf.txt кодека VoiceCodec никак не учитывается при запуске.

Поправлю. Заодно посмотрю проблему с нестандартным портом. Надеюсь, при дозвоне на нестандартный порт вы его явно указывали после адреса через двоеточие:
-Osomeonionadress:17448

Для опций лучше сделать комментарии в файле

Не совсем понял, что сделать: отдельно в текстовом файле описание комманд или же смысл параметров в conf.txt?

что означают -Q{0,1,2}

См. oph.pdf, раздел 5.3.Sound management: управление авторегулировкой усиления микрофона и подавителем шумов

в порядке убывания безопасности

Наверное, скорее так (если исходить из особенностей обработки в LPC-транскодере):
шёпот=робот, низкие=высокие
Шепот и робот содержит меньше исходной информации о голосе, чем низкие и высокие. Но субъективно лучшим вариантом мне показался шепот.

конф. файл при их запуске читался из домашнего каталога пользователя

Это противоречит принципу портейбельности: все мои программы принципиально не лезут за пределы своей папки, ни на запись, ни на чтение.

Лог-файл, содержащий список вызовов и их статус (принятые/непринятые) тоже бы не помешал.

Ну да, а кое-кому даже очень помог :). Хотя опционно лог можно сделать, но опять же в папке онионфона. Учту.

audiocfg и conf.txt можно в один файл объединить

Уже сделал, будет в V02a. Так и планировалось, просто забыл.

Спасибо за тщательное тестирование. Если в процессе заметите еще баги, или будут еще пожелания, буду весьма благодарен и устраню/добавлю при первой же возможности.

Разве представляет какую то сложность наклепать пару формочек с кнопками?

При таком подходе – нет, но вот наклепать так, чтобы потом меня не материл каждый пользователь – наверное, да. Web-GUI я делал на скорую руку, и уже сейчас мне за него немного стыдно, хотя это всего лишь тест.

Но это в любом случае, не зависимо от сборки в 64 или 32

Если пользователь укажет опцию plug:default, то ваша готовая 32-битная сборка oph_lin.zip без установки 32-битной версии этой библиотеки (libasound_module_pcm_pulse.so) работать не будет. На 64-битной системе эта библиотека как правило уже установлена, но тоже 64-битная.

Надеюсь, при дозвоне на нестандартный порт вы его явно указывали после адреса через двоеточие

Упустил этот момент, с указанием порта через двоеточие работает.

Не совсем понял, что сделать: отдельно в текстовом файле описание комманд или же смысл параметров в conf.txt?

Стандартые комментарии, принятые в конфигурационных файлах. Как например в файле gpg.conf, созданном после первого запуска gpg.

# Mode of vocoder: 3 - whisper, 4 - high, 5 - deep, # 6-255 - robot with different pitch. Default is 0. #Vocoder=0

Это противоречит принципу портейбельности: все мои программы принципиально не лезут за пределы своей папки, ни на запись, ни на чтение

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

[root@localhost oph01a_221014]# ldd ./oph linux-gate.so.1 => (0x00384000) libm.so.6 => /lib/libm.so.6 (0x00f70000) libasound.so.2 => /lib/libasound.so.2 (0x0093a000) libc.so.6 => /lib/libc.so.6 (0x003ed000) /lib/ld-linux.so.2 (0x003cb000) libdl.so.2 => /lib/libdl.so.2 (0x00b60000) libpthread.so.0 => /lib/libpthread.so.0 (0x00c1c000) librt.so.1 => /lib/librt.so.1 (0x00c3b000)

Во-вторых, наверное пользуется системным резолвером и читает /etc/resolv.conf при прямом дозвоне не через Tor (предполагаю что своего у онионфона нет). В третьих обращается к звуковым устройствам. В-четвёртых, читает /etc/passwd и /etc/group, т.к. даже для файлов в каталоге онионфона установлены системные права доступа. В-пятых, использует настройки времени /etc/localtime. Может что-то ещё.

Ну да, а кое-кому даже очень помог :). Хотя опционно лог можно сделать, но опять же в папке онионфона

Не обязательно всё протоколировать, достаточно записывать непринятые вызовы, чтобы знать кто звонил.

На 64-битной системе эта библиотека как правило уже установлена, но тоже 64-битная.

Я почему-то считал, что 32-битный статически линкованный бинар должен работать с 64-битной системой, в т.ч. библиотекой эмуляции alsa для pulse: онионфон использует лишь интерфейс, и по идее он должен бы быть универсальным. Но проверить не могу – сейчас нет подходящей платформы.

Стандартые комментарии, принятые в конфигурационных файлах.

ОК, напишу.

Такое вряд ли возможно

Несомненно, в такой интерпретации Вы правы. Я имел в виду – явно не пишут/читают конфигурационные файлы.И все же мне не хотелось бы выносить конфиги и логи за пределы папки, т.к. я рекомендую к использованию TC-контейнер.

и пишет в фс

Я не особо фамилярен с линукс, хотелось бы знать, какие следы ониофон оставляет при запуске, скажем, с флешки.

наверное пользуется системным резолвером

Кстати, ресолвер я могу прикрутить и свой на нижнем уровне (UDP) через 8.8.8.8, если это что-то дополнительно даст в плане безопасности.

достаточно записывать непринятые вызовы

ОК, сделаю.

ПС: По поводу вашего замечания: пожалуйста, перепроверьте установку кодера по умолчанию в параметре VoiceCodec в conf.txt. У меня все работает. Обратите внимание: в этом параметре указывается кодер (для исходящего аудиопотока). Декодер же используется в зависимости от актуального входящего потока (задается противоположной стороной). Причем кодер и декодер могут использоваться разные. Получатель не может выбрать декодер сам, разве что попросит абонента переключиться.

заметил в последнее время увеличение ping 8.8.8.8 в 2 раза.

хотелось бы знать, какие следы ониофон оставляет при запуске, скажем, с флешки

При такой постановке вопроса, ничего существенного. Проверяется поиском файлов, которые менялись за последние, например, 3 минуты

find / -cmin -3

Можно опцию -mount добавить, чтобы исключить поиск в примонтированных фс. Меняется время модификации каталогов /tmp/{.esd-PID,pulse-XXXXXX}. Если при запуске oph выводились предупреждения, то добавляются записи в других журнальных файлах (/var/log/{messages,Xorg.0.log} и т.п.). Если используется sudo, то остаётся запись о запуске oph в /var/log/secure.

ресолвер я могу прикрутить и свой на нижнем уровне (UDP) через 8.8.8.8, если это что-то дополнительно даст в плане безопасности

Вряд ли это хорошая идея – дублировать существующее решение, ещё и с привязкой к сервису google.

перепроверьте установку кодера по умолчанию в параметре VoiceCodec в conf.txt

Может я не замечаю изменение кодека на слух, но независимо от того, какую цифру указываю для VoiceCodec, команда -C? выдаёт одно и тоже

Current encoder: 7. Avaliable are 1-18

Изменить можно только командой -C в запущенном онионфоне.

Какой кодек лучше или безопасней использовать – LPC10?

При тесте звука -RV отображается кодек, соответствующий значению VoiceCodec, значит кодек видимо меняется. Но вывод команды -C? вводит в заблуждение.

вывод команды -C? вводит в заблуждение

Понял: не инициализируется переменая на старте. Поправлю.

Какой кодек лучше или безопасней использовать – LPC10?

В сборке 3 "военных" кодека: MELPE, MELP и LPC10. Они, по идее, тщательно проверены на невозможность исполнения данных при подаче фатальных фреймов. Остальные "гражданские" кодеки могут иногда валится, если на них слать рандом. Причем ничто не мешает на этапе разработки заложить в такой кодек специальные фреймы, прием которых приведет к заранее запланированному эффекту, причем обнаружить это будет чрезвычайно трудно: код весьма специфичный и сложный в плане математики, кроме того, обычно просматривают криптокод, но не аудио.
По соотношению качество/битрейт лучше всего AMR (его я использую по дефолту на минимальном битрейте + DTX), но в документации к его рефференс-коду честно предупреждают, что при подаче рандома может валиться. Наверное, действительно, для особых случаев лучше всего LPC10 – он наиболее старый и военный, поэтому вряд ли туда что-то специально было введено.

На github представил V02a (нет совместимости с V01a !!!). Бинарники пока не обновил, т.к. неожиданно всплыла проблемка с быстродействием кодека MELPE после старых коммитов: потребляет в 1.5 раза больше вычислительных ресурсов, затыкается на процессоре 700 MHz, а ведь работал нормально. Наверное, что-то с inline-функциями (либа стала существенно меньше), разбираюсь.

В новой версии оптимизировал загрузку ЦП на Windows и Linux отдельно, изменил IKE, ну и много мелких коррекций.

По поводу IKE:

1. Сделал протокол полностью симметричным: 3 шага с обменом одинаковыми по размеру, выглядящими рандомно пакетами на каждом шаге (см. в обновленном oph.pdf), раздел 7.4.

2. Блокировал возможность зондировать абонента на предмет наличия определенного контакта в его книге: теперь в случае отсутствия контакта в книге, в случае неверного получателя и в случае отбоя со стороны получателя для данного отправителя протокол не прерывается, а передается рандом. Протокол будет прерван лишь на следующем этапе, и инициатор не сможет различить причину прерывания, тем более если не имеет приватного ключа того, кем пытается представиться.

3. Блокировал возможность тайминг-атаки: перенес ответ вручную в другое место IKE, теперь невозможно оценить затраты времени на математику с публичными ключами при выполнении IKE (на нее накладывается время реакции пользователя).

4. Самое главное: добавил wPFS к защите ID инициатора соединения. Это поучительный пример различия теории и практики: увлекшись теоретической отрицаемостью, пропустил практический изъян, который в используемой модели отрицаемости таковым и не является. А именно:
при использовании предыдущего IKE злоумышленник некоторое время пишет трафик абонента, затем получает доступ к его приватному ключу и видит, кто и когда ему звонил. Это вполне реальная ситуация, тем более с учетом СОРМ и т.п. В теоретической модели отрицаемости абонент, конечно, может правдоподобно отрицать факт контакта с указанными абонентами (любой мог иммитировать их вызовы без знания соответствующих приватных ключей), таким образом информатор не сможет математически убедить судью в факте контакта. Но эта фраза уже вызывает улыбку в наших реалиях. Поэтому переделал протокол: сначала абоненты анонимно выполняют DH и согласовывают вспомогательный секрет, а затем защищают им свои ID и согласовывают рабочий секрет, уже с аутентификацией.

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

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

Ближайшее ToDo:
– Пофиксить крипто, транспорт и пакетайзер, и можно будет собирать весь проект на 64.
– Ну, и безопасность кода отдельно для Windows и Linux, в т.ч. контроль эффектов оптимизации.

На сайте проекта термин

Java-скрипты

несколько озадачивает – то ли там используется Java, то ли JavScript :)