Internet telephony is now an important part of human people communications and should be protected from intruders collecting information about you. I had an idea to use the old PGPFone designed by Philip Zimmermann for these purposes by adding the ability possibility to use The Onion Router anonymizer for to ensure anonymity of callers. I did some tests to adapt adopt VoIP transport to TOR tunnels and eventually made acceptable alpha release.

As a result, the TORFone was designed to voice communicate voice via Internet (make phone calls to the addressee) similarly as to Skype but with the following differences:

1. TORFone is an open source project, therefore it which guarantees the absence of "backdoors" and the quick elimination fixing of potential vulnerabilities.

2. TORFone is fully portable (it can be run from a flash carrier or virtual TrueCrypt-disk and leaves no residue in the system) and works with all versions of Win32 from Windows 98, has very low system requirements (above PI 233 MHz 32M RAM), is economical in traffic (at least 20 kbit/s which corresponds to the GPRS Class 10).

3. TORFone decentralized ie does not use an external server and does not require pre-registration number.

4. TORFone provides complete full confidentiality (used by using DH-4096 to match the session key and 3-DES for to encryption of the voice traffic). The attacker is mirrored who mirrors the traffic is unable to listen to the conversation and is not be able to decode it later even if he gainsing access to the computers of participants.

5. As cCaller and callee are completely anonymous to each other and to outside observers (a call is made on hidden TOR-service user).

6. Calls using TORFone is hidden to the outside observer as since TOR traffic with not differsence from the usual https-connection.

I think now that TORFone is one of the most anonymous and confidential means for the Internet telephony. The payment for anonymity is voice latency up to 2-4 seconds (because traffic goes through a chain of 6 nodes located around the world). If anonymity is unnon-important Torfon can perform work as a direct connections "point to point" using IP-adress / domain name which fully keeps the privacy. Also Torfon also provides subscriber voice authentication to avoid attack "people man on in the middle" and, therefore, it can be used to safe exchange by of personal data (such as files or short text messaging) safely. (such as files or short text messaging)

Win98-XP-7-8.

При связи между скрытыми сервисами [HS-Tor-HS] дополнительная аутентификация и шифрование м.б. не нужны, т.к. канал шифруется и аутентифицируется посредством самого Tor, а т.к. никаких исходящих узлов нет, то генерация сеансовых ключей окончательно установленного канала остаётся в ведении компьютеров самих абонентов.

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

Ага и на точке встречи (RP) тогда сидел бы человек-посредине, слушал в открытую весь трафик и всё бы знал о скрытых сервисах. Нет уж, фиг ему. Внутри Tor весь трафик шифрован как узлами, так и самими клиентами.

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

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

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

Имелось в виду не тор, а разговор от перехвата на исходящем узле между тором и незащищённой сетью. В отличие от разговора только внутри тора. Ведь программа ТС предполагает оба варианта использования?

сейчас Торфон генерирует всего 2Kбайт/сек трафик

Очень интересны отзывы с результатами ваших тестов – попробовать дело 5 минут...

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

Кроме http://www.cryptophone.de есть еще супернее: http://www.speakfreely.org

есть еще супернее: http://www.speakfreely.org

Это ж какая-то совсем ископаемая архаика. Если говорить о проприетарщине, то silentcircle.com пару дней назад объявили выход версии под Android.

тем не менее, TORFone реально рабочий получился :)

https://tails.boum.org/todo/VoIP_support/

Preliminary testing showed OnionCat^[link3] + Mumble^[link4] to be a working and relatively easy to setup Tor-enabled VoIP solution; the 1/2s – 1s delay is only slightly annoying.

+ ещё много других потенциальных вариантов.

The worst case occured only once with 8 chains where the latency rised over 10.000 msecs,but it was also peak time of traffic for Europe.

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

я с этого как раз и начинал :) Но запуск OnionCat под Win32 – это было что-то! Вобщем, хомячки отдыхают.

К сожалению, наверное, я все ж тупой, т.к. в итоге так и не удалось :(

мультиплатформенный, но консольный.

но зачем еще этот реверанс в сторону иностранщины? Настораживает...

я пока не владею ситуацией, какие алгоритмы мутации применить и насколько они надежны (невосстановимы и некоррелируемы)

А подскажите как эти Torfone или Pgpfone находят друг друга? Ведь связующих серверов для них вроде нет, имхо.

В рассылке ещё и по-более принципиальным техническим моментам раскритиковали, чем просто неверное использование имени.

Помимо нарушения правил использвания имени проекта в официально неодобренном софте, ещё и переврали принятое сокрашение:

Note: even though it originally came from an acronym, Tor is not spelled "TOR". Only the first letter is capitalized.

Кстати, к торчату вроде бы такие же претензии из-за имени, плюс ещё какие-то, на фоне множества форков того проекта на сомнительных языках программирования.

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

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

Мне кажется, что VoIP-over-Tor или PTT-over-Tor м.б. востребовано, но с другим определением анонимности. Не для того, чтобы оставаться анонимным от собеседника. А для того, чтобы скрыть факт того, кто с кем общается от третьей стороны (наблюдателя), скрыть и сам круг общения, время сеансов связи и сам факт их существования. Или для того, чтобы скрыть друг от друга, откуда совершается звонок в данный момент, но при этом оба говорящих в остальном друг другу доверяют, знают друг друга и перед собой неанонимны, а наоборот аутентифицированы. Т.е. анонимный канал для неанонимных между собой пользователей.

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

Пусть аноним письмо пишет или чат устраивает, если у него какие-то поводы привлечь внимание к своей информации.

http://www.cvedetails.com/cve/CVE-2000-0678/ ... Я никогда не считал себя асом в криптографии, но какое отношение это имеет к криптографии PGPFone???

LikelyTMViolators

Прошу пардону, а эта штука "Voice over TOR" способна работать в обычном Интернете, без Тора?

Так это концептуально, а практически кто нибудь пробовал, есть какието отзывы?

Конечно, будет работать. Смотрите руководство по тестированию в картинках в части "неанонимный режим": http://torfone.org/download/testingru.pdf

При этом работа программы ничем не отличается от PGPFona
https://www.pgpru.com/forum/ob.....hanizmrabotyiprochee^[link7]
за исключением того, что используется TCP вместо UDP.

Собственно, имеется настраиваемый слушающий интерфейс (IP-адрес и порт), а как Вы к нему подключитесь – без разницы: напрямую из интернета, через роутер, из ТОР (настроив скрытый сервис) или из I2P (настроив туннель на IP и порт интерфейса), или из ВПН и т.д.
Что касается исходящего вызова, то при звонке создается исходящий интерфейс, работающий по выбору или напрямую (на IP – порт входящего интерфейса получателя), или же через SOCKS5 прокси.

ПС: по многочисленным просьбам
http://sourceforge.net/p/advto.....d/9d735faa/?limit=50^[link8]
скомпилировал сырцы SpeakFrealy, разбираюсь с их "торификацией" (по наличию вдохновения). Хотя лично мне PGPFone больше нравится и кажется элегантнее.

ListenAddr:Prt=192.168.50:17447

на самом деле оно было так

netcat, speex (желательно в режиме CBR), aplay и вот вам самопальный VoIP^[link9]. Iptables и настройку скрытых сервисов Tor добавлять по вкусу.

Вот такой уютный чат^[link10]. Возможно, хорошо бы в нём заменить алгоритм симметричного шифрования или ввести асимметричные ключи. Или вообще заменить openSSL на OpenPGP. Хотя, нужно ли какое-то дополнительное шифрование, если вы будете пускать его только между двумя скрытыми сервисами Tor — решать вам.

Есть ещё socat со встроенным openssl (кому охота пообщаться вне тора). А можно и в нём. Вот пример^[link11].

А вместе с torsocks^[link12] должно быть совсем хорошо. Возможно даже что-то соорудить и под виндой и без прозрачной торификации файрволлом.

1. Убогий функционал. Сервер чата отваливается при выходе из него клиента, хотя может это и настраивается.
2. Только чат двусторонний. А передача голоса — в одну сторону. Или надо городить два встречных потока на двух портах.
3. Это система для связи только двух абонентов. Нет списка доступных юзеров в сети, не форум, не конференция, не портал.

if you're concerned about anonymity, you can try piping tcp through tor to a hidden service.

Наглядно показано как взламывают голосовое шифрование^[link14] в стандартных программах, которые используют сжатие голоса.

Всё-таки для VoIPoTor пока лучше всего подходит mumble^[link15], ссылка на который^[link16] в форуме уже была^[link17].

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

Именно для этого эти опции и предназначены. Более того, там есть два варианта: "не знает пароль, но сможет узнать, что сервер запущен, но не сможет туда попасть" и "не знает пароль и без этого даже не сможет определить, запущен ли этот скрытый сервис в Tor или нет".

Обсуждалось здесь^[link18].

Виноват, невнятно написал. По умолчанию создается ini с параметром ListenAddr:Prt=127.0.0.1:17447, что дает возможность слушать только HS и защищает от деанонимизации путем обнаружения TORFone напрямую извне. А значение 0.0.0.0 (INADDR_ANY) на скриншоте в инструкции – уже отредактированное, а не требующее редактирования.
Т.е. там просто рекомендуется сменить 127.0.0.1 на 0.0.0.0

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

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

Mumble? Это оригинальный вывод, учитывая, что она вобще не шифрует трафик. Конечно, ТОР все сам шифрует до HS, но зачем тогда говорить об уязвимостях PGPFone? Кроме того, она использует внешний сервер murmur (т.е. не p2p): если его запускать в открытой сети, то без шифрования никак, если на HS, то между абонентами уже не 6, а 12 нод. Да и контролирующий сервер слушает все. На guardianproject.info ее просто используют для тестов, но, судя по постам n8fr8, задумывают они совсем другой вариант.

Да идея, изначально положенная в архитектуру Tor, даёт возможности делать многие более сложные вещи несколько проще и красивее. VoIP просто частный пример. Который концептуально хорошо бы намертво привязать к тору и не давать возможности прямых звонков через интернет из-за опасности смешивания контекстов анонимности и раскрытия круга контактов от внешнего наблюдателя.

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

Рассмотрим приём звонков Алисы от Боба.

1. Алиса запускает локально на своей машине скрытый сервис (HS) с возможностью авторизации Боба (HS authorization protocol).
2. Алиса запускает локально на своей машине VoIP-сервер. С помощью файрволла она его "заторивает", так чтобы он работал только через свой скрытый сервис Tor и был невидим из обычного интернета. Для доп. защиты виртуалки, псевдовиртуалки, SELinux и пр. — добавлять по вкусу, но вообще-то Алиса и Боб другу другу более-менее доверяют и рассчитывают, что друг друга они ломать не будут. А посторонний в их канал вклиниться не может. Так что уязвимости в запускаемых сервисах, конечно нежелательны, но не столь критичны и определяются доверием между абонентами.
3. Боб использует заторенный VoIP-клиент, чтобы сделать звонок на HS и VoIP-сервер Алисы. Для инициализации звонка ему не нужен свой сервер. Сервер нужен только стороне, принимающий звонок (в данный момент Алисе).
4. Алиса принимает звонок из тора на свой HS и локально запущенный VoIP-сервер.
5. У Алисы запущен VoIP-клиент, который принимает сообщения с локального хоста (127.0.0.1) только от своего VoIP-сервера и общается только с ним. VoiP-клиент Алисы может быть на всякий случай ещё и заторен, когда ей понадобиться не только принимать звонки от собственного локального VoIP-сервера, но и звонить кому-то ещё. Но в данном примере используется только связь с локальным хостом для приёма звонка.
6. Алиса принимает звонок по цепочке [Bob] — [VoIP-client]_Bob — [Tor] — [HS]_Alice — [VoIP server]_Alice — [localhost 127.0.0.1]_Alice — [VoIP client]_Alice — [Alice]. Если Боб хочет принимать звонки от Алисы, то он проделывает весь описанный процесс, начиная с п.1, запуская свой локальный скрытый торифицированный VoIP-сервер и подставляя себя во все пункты вместо Алисы и наоборот.

Как видим, не через какие лишние узлы цепочек трафик не идёт.

Mumble скорее всего выбрали потому, что там легко настраиваемый VoIP-сервер и клиент. Плюс push-to-talk (режим рации), экономный кодек для TCP, встроенный чат и пр. Безопасность этого сервера на первом этапе малоинтересна, это вообще игровая поделка, которая удачно подходит для экспериментов.

Доп. шифрования данных не нужно, т.к. всё и так завязано на безопасность шифрования внутри самого Tor, но при желании такие решения могут быть навешены в более общих случаях.

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

1. По этой схеме двум сторонам можно запустить локальным скрытым сервисом любой сервер: чат, почту, веб, wiki, блоги и пр.
2. Можно вынести сервер и скрытый сервис на домашний, корпоративный сервер в пределах помещения (связь в пределах своей подконтрольной локалки), чтобы обращаться к нему с разных компьютеров и гаджетов.
3. Можно прописать в авторизации скрытого сервиса более одного доверяемого пользователя (Боб, Кэрол, Дейв и далее по стандартному списку имён по алфавиту). Получается, что запуская различные сервисы для ограниченного круга лиц и невидимые посторонним, пользователи создают F2F-сеть — Friend to Friend^[link20].

Доп. свойства и соображения по поводу F2F-сетей на базе Tor:

1. В отличие от готовых решений для F2F-сетей, такая сеть гибка, универсальна, псевдонимна (не путать анонимность с псевдонимностью), скрыта от постороннего наблюдателя (неотслеживаемость).
2. Децентрализованность в пределах Tor.
3. Отсутствие возможности не только внешнему, но внутреннему наблюдателю для выявления всего круга контактов и построения графа социальных связей (скрытость сегментированности и связности): Алиса знает Боба и включает его в свой круг авторизованных контактов на скрытом сервисе. Боб знает ещё Кэрол и включает в свой авторизационный список Алису и Кэрол. Алиса и Кэрол ничего не знают друг о друге и о том, что Боб общается с ними обеими, пока Боб это сам не захочет раскрыть. Любой член сети может сам управлять доверием, раскрывать часть своих контактов, искать нужных людей, распространять информацию, запрашивать помощи через своих знакомых. Но никакой внешний наблюдатель или внутренний "предатель" не сможет раскрыть всю сеть без получения согласия её участников. Даже сам участник не может легко обойти круг своих социальных контактов дальше первого звена.
4. Эфемерность данных. Данные, передаваемые по сети, хранятся только у её участников (если они хотят их хранить или уничтожать — каждый сам волен распоряжаться хранением полученных/отправленных данных).
5. Возможность управления эфемерностью контактов и связей. Достаточно удалить или сменить авторизационный ключ и/или адрес персонального скрытого сервиса, как сведения о ранее переданных/полученных контактах с этого адреса теряются. Скрывается факт раннего участия в контактах, сетях и пр.
6. Наперёд заданная секретность. В случае взлома или конфискации сервиса агента сети (в случае его провала) можно просмотреть только неудалённые персональные контакты и контролировать только будущие передаваемые данные. Сведения о ранее переданных данных и удалённых контактах принципиально невосстановимы, если пользователь грамотно осуществлял их уничтожение.
7. Лёгкость бесследной самоликвидации сети при отсутствии в ней дальнейшей необходимости. Тут уж правда как участники договорятся: если они все друг друга знают по общему делу — всем разойтись или прерывать контакты по одиночке. Опять же — саморегуляция на основе собственных желаний пользователей без возможности контроля и надзора третьей стороны.
8. Относительная лёгкость повторного разворачивания сети после компрометации: достаточно исключить недоверяемых лиц и сменить список адресов скрытых сервисов и авторизационных ключей.
9. Лёгкость завязывания временных полуанонимных контактов. Можно временно подключить любого человека к своему скрытому сервису для приватного общения и затем сразу же удалить следы контакта с ним.
10. Возможность образования скрытых сообществ, социальных сетей и получения мостов между ними за счёт шлюзов, посредников и пр.

В принципе, зачатки этого всего есть в сетях, подобных Freedom/I2P за счёт наличия встроенных сервисов из коробки. На базе Tor можно организовать более мощные, правда труднонастраиваемые и пока малоисследованные решения.

Хотя какую-нибудь простую штуку такого типа^[link21] могли бы включить в отдельную Tor-сборку для использования "из коробки".

The developer of TOR Fone recommends against using TOR Fone. Quote: "I did not think this project as a finished product for practical use." The project got overall a pretty bad review in the mailing list thread.

Шо ж с этой mumbl-ой так носятся... Наверное, naif не совсем равнодушен :) Главное, что расшевелились немного. Я ж не вчера родился, и все это прошел на других своих проектах. Жизнь покажет. Крутые парни сами решат, что им пользовать, не особо слушая такие рекомендации, а хомячки все равно на Скайпе останутся... В общем, собака лает, а караван идет :)

"Mumble скорее всего выбрали потому, что там легко настраиваемый VoIP-сервер и клиент. Плюс push-to-talk (режим рации), экономный кодек для TCP, встроенный чат и пр. Безопасность этого сервера на первом этапе малоинтересна, это вообще игровая поделка, которая удачно подходит для экспериментов."

: вот я тоже думаю, что все это в точности есть в TORFone и еще в десятке приложений, но они все плохие. А хороший жавовский Jitsi после дефолтной инталляции сразу лезет на сервер обновляться... Так может, просто гранты оправдать надо?

To alex_10 & michel_25: сейчас именно SpeakFreely и занимаюсь. Архитектура там немного другая, так что не сразу сделаю, тем более, что занимаюсь в свободное время. Можно также попробовать опционно прикрутить к SpeakFreely DH4096 от PGPFone (т.к. изначально там только Preshared key или PGP). И еще можно попробовать добавить "ручной" обход NAT для неанонимного режима (получая данные от любого STUN и предварительно обмениваясь ими например через любой мессенжер на Tor c OTR).

В руководстве поправил рисунок на первой странице и подпись к нему, смотрите внимательно. Если что-то еще желательно изменить, уточните – сделаю.

To unknown: полностью согласен и поддерживаю. Но в реале это не только не развивается, а, наоборот, сдерживается. Например, тот же TorChat – прекрасное приложение, предельно простое и востребованное. Добавить голос, видео – вполне решаемо даже для одного разработчика. И не надо ни мумбл, ни локального сервера. Но похоже, играют роль совсем другие маркетинговые интересы, о которых можно только догадываться.

Лишний слой шифрования еще никому не вредил. Если сервер аутентифицируется сертификатом, то это исключит Человека-по-средине.
Но PGPFone и сам по себе создает весьма защищенное соединение, что бы о нем не писали в плане "устаревший", "уязвимый" и т.п. Сначала надо попробовать взломать или хотя бы указать реальный путь взлома, а потом уже делать выводы.

Вопрос: будет ли востребовано, если прикрутить к Циммермановскому PGPFone (использующему UDP) возможность ручного прохода NAT?
Идея такова: задаем любой публичный STUN-сервер в ini-файле и по чекбоксу периодически (скажем, раз в 10 сек) шлем запрос. Ответ (свой внешний IP-порт) выводится в инфополе. Для установки соединения между двума клиентами (оба за NAT) они обмениваемся по другим каналам (скажем, по ICQ ч/з Pidgin+OTR – Tor или же по TorChat) своими адресами. Затем оба вводят полученный адрес в поле дозвона, и звонящий жмет "Connect", а принимающий ставит чек "Listening". В итоге должны проходиться NAT, вплоть до PortRestricted.
Смысл в том, что STUN-сервер не знает, с кем вы планируете соединиться (в отличие от SIP), а ICQ не знает ни вас (Tor), ни вашей беседы (OTR), т.о. нет возможности централизовано контролировать абонентов.

будет ли востребовано, если прикрутить к Циммермановскому PGPFone (использующему UDP) возможность ручного прохода NAT?

Идея такова

есть ли утилита, позволяющая записывать разговор собеседников TorFone?

Некоторые люди предлагали более прямые протоколы для IP discovery, но их уместность и универсальность под вопросом в силу там же озвученных замечаний.

Такой IP-discovery, как и SIP-сервер, необходим для того, чтобы сообщить о желании установить p2p и о внешних адресах/портах друг другу. В нашем случае уже имеем предварительно установленное защищенное соединение через Tor на HS. Достаточно создать UDP-сокет, получить свой внешний адрес на любом публичном STUN и передать инвайты друг другу через защищенное TCP-соединение, и затем установить p2p (просто переключиться с TCP на UDP трансорт), даже если оба абонента за NAT (конечно, кроме симметричных). Таким образом снимается проблема доверия к внешнему SIP, т.к. его функцию (нахождение и согласование абоненов) выполняет распределенная сеть Tor. Кроме того, PGPFon-овский Диффи-Хеллман первоначально выполняется внутри Tor-канала, что снимает вопрос MitM.
Если это подцепить к TorChat (просто добавив дополнительный HS-порт в torrc), получится очень неплохое дополнение.

Конкретику для конкретно какой звуковой системы? Для ALSA например вот так^[link23].

Зачем повторять мои же слова?

в PTT режиме

Push To Talk^[link2] — режим рации. "Перехожу на приём, теперь можете отвечать".

можно добавить в TORFone как опцию дополнительного ключа параллельно c DH.

Их лучше всего вместе использовать: с помощью GPG аутентифицировать параметры DH, которыми потом согласовывать ключ. Тогда и forward secrecy будет, и подтверждать подлинность канала с помощью одинаковых слов на обоих концах будет не нужно.

Виндовс, если ее подпереть специальными патчами и прочими костылями, безопаснее Линукса.

М.б. 56-битным?

Сорри, описка. 56, конечно!

Можно посмотреть, как организован OTR в XMPP.

Я смотрел: OTR достаточно сложен в основном за счет Plausible deniability. Если к этому не стремиться, то можно, как вариант, сделать почти "детскую" АУ:

в начале Алиса и Боб выполняют DH, в итоге имеют расшаренный секрет: AES-ключ 256 бит (да, я уже добавил AES, будет в TORFone 0.3 вместо Blowfish), общий отпечаток 32 бит и ники друг друга. Оба абонента инициализируют АУ, вводя ау-фразу, уникальную для каждого своего контакта и предварительно с ним согласованною любым способом. Фраза собеседника аналогична, но последние два символа меняются местами.

Этап 1: после ввода фразы Алиса считает SHA1 от строки "отпечаток + ау-фраза без посл. двух символов + свой ник" и отправляет Бобу открытым текстом. Аналогично Боб.
Получив такой пакет, TORFone сверяет с хешем своих данных, и сообщает о ошибке АУ, если не совпадает.

Если все ОК, то считается хеш от ау-фразы без последних двух символов и его 64 бита используются как nonce (дописываются в счетчик, увеличенный мною для AES-блока с 64 до 128, добавленные биты изначально 0). Это изменяет шифрование, вводя дополнительную зависимость от текущей ау-фразы.

Этап 2: тотчас после успешного завершения этапа 1 абонент отсылает текстовое сообщение по шифроканалу, содержащее последний символ своей ау-фразы. Получив такое сообщение, абонент сравнивает его с предпоследним символом своей ау-фразы (он должен совпадать с последним символом ау-фразы абонента, т.к. они изначально переставлены). Если совпадают, то выводится сообщение о полной АУ, иначе – "под принуждением".

Идея такова: абонент под принуждением выдает ау-фразу, меняя последний символ на другой. При аутентификации с его стороны все выглядет как обычно, и шифрование согласовано, но второй абонент получает предупреждение.

Просьба к крипто-гуру покритиковать, предложив реальный способ выдать себя за Боба, или предложить более подходящее решение. И еще: можно ли доверять SHA1 при описанном использовании в плане вычисления ау-фразы или подмены хеша выдавая себя за Боба или при MitM?

- Сколько максимально бит доступно на выходе DH в AuthenticationFifo, я не готов сказать точно. Повнимательнее просмотрю исходники. Наверное, можно использовать и хеш от ключа (DH использует expSize 458 бит для 4096 прайма, ключ для AES256 обеспечивается "с натяжкой").
– Ау-АУтентификация, конечно. Речь то о ней :)
– Конечно, это будет опционально. Устанавливается соединение без АУ, и может длиться сколько угодно. В процессе разговора по договоренности оба могут ввести АУ-фразу. Криптография изменится только после того, как оба введут одинаковую (за исключением последних двух символов) – дополнительно защита от MitM.

Или может есть более удачные и менее затратные по ресурсам решения?

Даже при моем желании сделать платным p2p-приложение с уже открытым кодом нереально.

По поводу анонимизации голоса – уже обсуждалось выше. Можно добавить синтезирующий кодек типа LPC10, он существенно искажает речь (попробуйте в SpeakFreely). Но в любом случае голос – штука индивидуальная. А хорошего распознавателя нет пока, да и в любом случае он к языку привязан будет, это уже совсем другой проект.

PS: добавил AES256 и аутентификацию + анти-MitM на базе hmac_sha1 с использованием заранее согласованной фразы и возможностью тихого уведомления о прессинге, будет в новой версии.

ToDo:
– оперативное переключение с TCP over Tor на UDP direct и обратно со средствами прохождения NAT без помощи SIP-сервера и т.п. (TORFone как добавка к TorChat);
– добавить новый современный codec2 (сжатие в 4.7 раза больше, чем у gsm).
Также есть идея попробовать задавать несколько HS слушающим абонентом в torrc и выполнять несколько независимых подключений к ним звонящего, дублируя пакеты по каждому каналу. В PGPFone уже есть механизм восстановления последовательности и исключения дублей (остался от UDP). По идее, латентность связи через Tor с параллельным использованием нескольких независимых цепочек будет ощутимо ниже.
И еще есть задумка сделать консольную версию под вин32 и линукс с опциональным управлением через отдельный Control port с другого GUI-приложения: компромисс между простотой кода/портируемостью и юзерофильностью.

будет в новой версии.

Добавил (вместо Blowfish) и проверил, но пока V03a не релизил – еще потестирую и исправлю несколько мелких багов (например, при снятии флажка Unencrypted на вкладке Phone, т.е. блокировке передачи ника открытым текстом при конекте (до ответа абонента) виснет при работе через Tor). Также не до конца согласован по времени момент смены nonce (Анти-MitM) после аутенификации уже в процессе разговора при соединении через Tor (из-за возможных больших задержек).
Скорее всего, выдам уже вместе с поддержкой UDP, чтобы не плодить много промежуточных релизов.

Не лучше ли вместо Triple-DES ?

И как это скажется на анонимности?

Не все любят AES

Так то оно так, только каскадирование многократно увеличит потребности в мощности, к тому же тут realtime – голос, который не может (долго) ждать.

Для тех, кто подзабыл: AES — чисто бельгийский шифр родом из Католического универститета в Лёвене.

AES — чисто бельгийский шифр родом из Католического универститета в Лёвене

миллионами ездят в египты и турцию

Советское мышление... оно ещё даст о себе знать.

Эти миллионы ездят отдыхать, причем коллективно через турфирмы.

Основополагающее право на неприкосновенность частной жизни, гарантированное пятой и четырнадцатой поправки к Конституции США, защищает от необоснованного вторжения в частную жизнь федеральных, государственных или военных служб.

а можете встроить в Torfone также и симметричные алгоритмы?

симметричные алгоритмы – когда у отправителя и получателя ключи одинаковые. Их нельзя передавать по открытому каналу.

3DES, AES — это, по-вашему, что?

В ТОРФоне используется Деффи-Хеллмана (асииметричный), но он не для шифрования, а для согласования ключей. А для шифрования используются симметричные алгоритмы. Наверное, вы имели ввиду ввести возможность использования симметричного шифрования ключем, заранее согласованным пользователями. Так делает, например, SpeakFreely. Плюс такого решения – невозможность MitM, но большой минус – один из пользователей может позднее выдать ключ, и подставить тем самым второго. Лучше уже накладывать статический ключ на ключ, согласованный DH. А еще лучше ввести продуманную аутентификацию с анти-MitM.
Что и сделано в TORFone V0.3 – уже доступна на http://torfone.org
Как и обещал, добавил:
– AES256 вместо Blowfish. Получился уровень защиты около 220 бит (ограничен длиной DH-прайма (4096 бит) и экспоненты (458 бит).
– опционную аутентификацию на базе HMAC_SHA1 (фразу можно ввести при инициализации звонка, в любой момент разговора или заранее задать в адресной книге для ника абонента);
– возможность скрытого уведомления о прессинге при аутентификации (для этого надо изменить последний символ фразы, с вашей стороны все будет выглядеть ОК, но абонент получит предупреждение);
– защита от человека-по-средине (после успешной аутентификации изменяется nonce, т.о. фраза используется как дополнительный пароль шифрования);
– добавлены низкобитрейтные кодеки: MELP 2400bps и новый CODEC2 1200 bps. Первый жмет 180 семплов 8000КГц-голоса (22.5 ms) до 7 байт, второй – 320 семплов 8000КГц-голоса (40 ms) до 6 байт.
Для компенсации задержки в одном пакете накапливается по 40 таких фреймов, при этом дополнительная задержка составляет 900 ms и 1600ms соответственно. Такие задержки неприменимы для обычного VOIP, но прекрасно компенсирую життер при Tor-соединении без дополнительной буферизации.
– также скорректирован режим PTT (как в SpeakFreely): нажатие/отжатие кнопки Mute сопровождается звуковыми сигналами и обеспечивает доставку всей сказанной фразы.

Пакет для Win32 и исходные коды по ссылке на основной странице, описание – на странице помощи.

AES256 – просто превосходно, супер!!!

обеждена ли в версии 0.3 досадная ошибка, которая жутко мешает работать?

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

TorFone использует сторонние библиотеки? Если да, то как вы думаете, насколько мала вероятность нахождения в них "закладок"?

Сторонние библиотеки все в исходниках. Источники:

Оптимизированный AES взял тут: http://sourceforge.net/projects/libobfuscate/
А они использовали источник: http://www.efgh.com/software/rijndael.htm
Вектора сходятся. В исходника ничего, кроме AES, нет.

SHA1 отсюда: https://polarssl.org/sha-1-source-code
Надежный источник.

CODEC2 взят тут: http://codec2.org/ Приаттачен в виде статической либы, собираемой с исходников. Исходники просматривал, ничего, кроме математики, там нет.

MELP отсюда: h**p://health.tau.ac.il/Communication Disorders/noam/speech/melp/Download/Download.htm
Он упорно не хотел становиться, поэтому я его коды до последней строчки перелопатил, переделав с либы в include
Кроме математики, там ничего нет.

PS: просьба может, у кого есть исходники MELP1200, поделитесь, плиз. Они появлялись в паблике пару лет назад, но ссылку прибили, а на наш фтп не могу достучаться. У китайцев нашел, но без одного ключевого с-файла :(

Остальные исходники родные. Надеюсь, Цммерманновскому DH-прайму можно доверять: сначала я хотел заменить его на прайм с rfc3526, но передумал – не будет совместимости.

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

Абсолютно согласен. Поэтому и оставил классический tDES 168bit – в те времена о бекдурах точно не думали.

1. В режиме CTR. Счетчик имеет статическую часть (nonce) и изменяющуюся: 32-битный счетчик пакетов и 16-битный счетчик блоков в пакете (т.е. период оборота 9 лет при отправке пакета каждые 70 мс). Т.к. симметричный ключ (общий секрет DH) новый на каждый разговор, то этого более чем достаточно. Счетчик пакетов синхронизируется на обеих сторонах с помощью 16-битного ID пакета, передающегося в начале пакета в нешифрованном виде и восстанавливающегося до 32-битного значения.
2. Сперва я вообще думал Keccak использовать, но потом посмотрел реально: стойкость хеш-функции определяет время, необходимое только для подбора аутентификационной фразы. А время, необходимое для дешифровки разговора, определяется DH и симметричным шифром.
Поэтому, если фразу менять хотя бы раз в год, то стойкости 160 бит SHA1 по идее, достаточно.

PS: если интересна реализация остальной криптографии (DH, аутентификации) – спрашивайте, опишу, чтобы в исходниках не рыться. И дам ссылки на конкретные места в файлах. Мне кажется, что именно реализация определяет криптостойкость, а не математика используемых алгоритмов, поэтому уделил внимание тщательной ревизии кода, и в который раз преклоняюсь перед Циммерманном! SpeakFreely с ее DES-56 в CBC с постоянно нулевым IV для каждого пакета отдыхает :)

3. Есть и такая идея. И еще http://www.speex.org/ Хотя их преимущества в вариабельном битрейте, что не совсем подходит в плане криптостойкости.

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

И еще http://www.speex.org/

Хотя их преимущества в вариабельном битрейте

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

При всём уважении к программерскому энтузиазму.
Но это показывает наколеночность дизайна. Как будто HMAC не изобрели и методы аутентификации в каналах, хотя бы например как в SSL. И даже те, навороченные методы, периодически атакуют из-за того, что программеры не понимают, как надо реализовывать аутентификацию. Всякие теоретические оракулы вылезают в практические атаки. А программеры-шифрпанки по прежнему просто думают: "а давайте-ка воткнём CRC-32 в шифртекст и получим аутентификацию".

Притензии не ко мне – лично к Циммерманну :)
Мне кажется, глупостей он не делал даже в то время.
Так, например, ключевой момент DH защищен SHA.

Собственно, аутентификацию для исключения MitM уже я реализовал lege artis на базе HMAC, могу детально описать релизацию.

Но все же, не используя шаблонные утверждения и догмы, покажите мне конкретно, где уязвимость, и как ее можно использовать в данном случае, если crc32 пакета передается вместе с пакетом в шифрованном виде? (шифрование в режиме CTR).
Возмем, к примеру, пакет с текстовым сообщение. Я так понимаю, хотим сделать подмену. Да, можно побитно манипулировать с текстом и с crc ( т.к. CTR), а дальше как???

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

Вот чего люди стандарты пишут^[link31], головы ломают^[link32]. Взяли бы AES-CTR + CRC-32 и не мучались.

Для построения стойкого аутентификационного канала обе функции должны быть криптостойкими, как шифрующая, так и аутентифицирующая. Причём это необходимое, но ещё даже недостаточное требование. Полностью достаточный набор требований я даже не решусь назвать. Для этого ещё только разрабатываются спецрежимы шифрования (часть уже стандартизирована и внедрена, но их безопасность недостаточно доказана), прорабатываются решения на основе Keccak. Пока проверенная классика: связка KDF для получения двух разных ключей из одного + HMAC для аутентификации + шифрование.

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

Да, сходу метод взлома не скажу, где-то это обосновано в теоретических работах с кучей выкладок и формул, но шифрпанкам это всё неинтересно же. Им интересно, когда через n лет кто-то заинтересуется их продуктом и найдёт способ практического взлома.

Возмем, к примеру, пакет с текстовым сообщение. Я так понимаю, хотим сделать подмену. Да, можно побитно манипулировать с текстом и с crc ( т.к. CTR), а дальше как???

Подменить один известный текст на другой, делать атаки переотправкой, перебивать таймштампы, строить оракулы на анализе отбрасывания/прохождения ошибок. Я ж не знаю, как там у вас всё реализовано.

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

При всём уважении ко всем, кто, что-то реальное делает (К Циммерману, к команде OpenSSL, к вам и вашему проекту и др.), просто первый способ из этих двух откровенно достал уже:

The classical cryptography approach:

Problem -> Proposed solution -> Bug! -> Revised Solution ... -> Implement -> Bug! -> ... -> ad infinitum

The provable security paradigm:

Problem -> Definition -> Protocol -> Reduction -> Implement -> DONE

Я так понимаю, хотим сделать подмену. Да, можно побитно манипулировать с текстом и с crc ( т.к. CTR), а дальше как???

Если номер и timestamp в вычислении хэша не участвует, то совсем беда. Номер и timestamp можно подделать. Если участвует, что уже сложнее, хотя тут возможно получится особенностями crc воспользоваться.

Притензии не ко мне – лично к Циммерманну :)
Мне кажется, глупостей он не делал даже в то время.

Все делают ошибки. :) Кстати, в PGP была одна слабость в механизме защиты секретных ключей, когда там crc32 использовалась. Её нашли и исправили уже в пост-Циммермановское время. Я деталей не помню, но вдруг аналогичный подход и тут сработает?

А вообще да, истории последних лет (SSL/TLS – ярчайший пример) как-то не вдохновляют: теоретические слабости часто вырастают в чудесные практические уязвимости.

Как понять готовый? Доказано, что, к примеру в CBC, IV должен быть строго рэндомный, из CS(P)RNG. IV-счётчик или IV-функция не прокатит — это позволяет строить различители блоков. Смутно припоминаю, что и для других режимов скорее всего также, иначе бы не изобретали заумных схем с SIV (синтетическим IV для детерминистического шифрования).

Советую не изобретать свой протокол, тем более без умения его формализовать, возьмите что-то готовое. Ну хотя бы внутри SSL/TLS-каналов пустите.

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

Как понять готовый?

Счетчик, к сожалению... Я не особо профи в криптографии, но не хотелось прикручивать готовый SSL/TLS. Если будет возможность, дайте ссылку для повышения образованности на

это позволяет строить различители блоков

(или в двух словах об этом).
Поищу по OCB, может, там IV-счетчик и допускается.

PS: немного погуглил и почерпнул знаний из Ваших же постов на форуме.
По ходу вопрос: а стоит ли на это обращать внимание, учитывая, что симметричный ключ для каждого сеанса новый? По подсчетам, за 1 час связи вряд ли будет больше 500 000 AES-блоков. Думается, это не совсем то, что нужно для практического использования описанной уязвимости, даже предполагая знание незашифрованных данных.

Так IV по определению известный, зачем его угадывать. Другое дело, что он должен быть уникальным на каждый пакет, и, как указал unknown, рандомным, иначе, я так понял, облегчается дифференциальный криптоанализ.
Я выше уже описывал работу программы: в начале пакета PGPFone передает 2 байта инрементируемый ИД, восстанавливамый до 32-битного счетчика. Счетчик работает только вперед: пакеты с меньшим ИД будут отвергаться.
Конечно, это создает почву для DDoS, но не уязвимость криптографии.
А вот касательно IV-счетчика при наличии небольшого количества пар зашифр.-расшифр. блоков хотелось бы услышать мнение.

Другое дело, что он должен быть уникальным на каждый пакет, и, как указал unknown, рандомным, иначе, я так понял, облегчается дифференциальный криптоанализ

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

Если вы претендуете на конструирование системы, скажем, со 128-битным уровнем безопасности, то каждый её кирпичик тоже должен обеспечивать такой уровень. Исключения надо обосновывать технической невозможностью включить что-то стойкое по уровню (высокие накладные расходы, а не "я не осилил правильный протокол, сойдёт и так") и считать, как это влияет на результат. Кое-какие вещи даже НИСТ не может осилить и допускает ляпы в стандартах.

Но если постараться, то может быть, у вас будет доказуемо безопасный протокол в некоем далёком приближении. Специалисты из АНБ говорили в интервью и в каких-то документах, что им не нужно взламывать 128-битные шифры или делать закладки. Реальная стойкость большинства программ бывает катастрофически низкой из-за некачественной реализации. Хотя там гордо красуются большие ключи и стойкие алгоритмы, но провалены протоколы.

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

Конкретно по этому вопросу читайте признанных специалистов:

Evaluation of Some Blockcipher Modes of Operation, Mihir Bellare^[link33].

Это только режимы, но не протоколы.

Здесь ещё смотрите: Lecture Notes on Cryptography, Shafi Goldwasser, Mihir Bellare^[link34]. С примерами, как взломать CBC и CTR с неправильно используемым IV за одну операцию — запрос к оракулу. Такой модный криптоанализ с параллельными мирами, в которых сидят разные оракулы, тоже представлен, куда же без него-то теперь.

Дело ваше, набирайтесь знаний и опыта. Но я бы лично не взялся в одиночку конструировать протокол построения защищённых каналов связи с нуля, без посторонней помощи. У меня такой квалификации нет. В лучшем случае внедрить готовый стандарт. И там есть поле для наступания на грабли с фатальными ошибками и подкладыванием самому себе таких бэкдоров, от которых любое АНБ помрёт со смеху.

Ну и выкиньте из головы вопрос: "как это можно взломать?" Построение безопасной системы начинается с других вопросов: "как это можно отличить от идеальной модели?", "есть ли хоть какие-то самые абстрактные различители?", "как можно формально обосновать стойкость?".

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

Let N be the 96-bit nonce—for example, a counter that gets incremented with each message you encrypt.

Рэндомное только стартовое значение, дальше обычное приращение по счётчику.

Спасибо за замечание, исправление ошибки по авторству и тонкий комментарий :) Согласен с каждым словом.

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

Согласно Рогвею, смайлик, обозначающий случайного оракула, выглядит вот так: $(·,·). Gegel, вы уже вывели формулу с учётом IV для Adversary Advantage в своём протоколе: Adv_ε^IND$ (A) = Pr[A^ε_K(·,·) ⇒ 1] − Pr[A^$(·,·) ⇒ 1] ?

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

Неиспользуемые биты? Вот так просто взять?

Я имел ввиду: взять половину бит уже ключа. Но Вы опять натолкнули на размышления:
почитав rfc2631, а затем просмотрев код PGPFone в части DH (я раньше туда не смотрел), я нашел, что в качестве битов ключа используются непосредственно биты общего секрета (результата ExpMod). Это тоже можно считать уязвимостью?

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

Я подразумевал взять НЕИСПОЛЬЗУЕМУЮ половину бит: они по идее рандомны и никак не коррелируют с другими элементами протокола.

в чём проблема сделать чистую рэндомизацию без синтетического IV

собственно, в синхронизации его у обоих абонентов. Потребуются дополнительные элементы протокола. В описанном выше варианте оба абонента уже имеют одинаковый и рандомный (причем рандомизированный обоими абонентами) IV, не связанный с другими криптоэлементами.
ПС: просьба не пинать, это не моя отрасль, но хочется разобраться. Посоветуйте, если что не так. С ув.

=== ППС: Вопрос по IV снят, но вопрос по DH актуален, посоветуйте, плз.

От Rogaway, слайд 9:
http://csrc.nist.gov/groups/ST.....resentations/ocb.pdf^[link36]

What is OCB?
...
Lots of nice characteristics designed in:
...
Uses any nonce (needn’t be unpredictable)

Они хоть похэшированы как-то? Результат сырого согласования по DH — не рэндомный и подвержен утечке битов через символы Якоби. Вот думаете, почему подписи RSA ломались в своё время? Из-за кривого стандарта дополнения в симметричной части. Для чего был придуман OAEP?

Для выведения общих секретов из одного используются PRF на хэшах.

Вот собрались как-то^[link37] криптографы и ковырятели кода и почти поломали PGP. Не удивлюсь, если в спецагентствах команды из криптографов и кодокопателей давно ведут работу, выявляя на потоке большой массив уязвимостей по всевозможным VPN-ам и SSL, так что их суперкомпьютерам не нужно перебирать весь массив ключей.

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

Результат сырого согласования по DH — не рэндомный и подвержен утечке битов через символы Якоби.

SHA-256 — это хорошо. Но в строгом смысле — оно не PRF. Изучайте, где в протоколах и почему используется HMAC вместо просто хэшей.

Я не утверждаю, что это обязательно нужно всегда. Просто ставлю обратный вопрос — достаточно ли простого хэширования вместо PRF на HMAC, чтобы не развалить протокол пусть даже на уровне теоретических уязвимостей?

Вы же спокойно ле'пите (я без негатива и критиканства, с лёгкой доброжелательной иронией только) свой протокол из обрывочных знаний, даже не задаваясь элементарными вопросами.

Security Issues in the Diffie-Hellman Key Agreement Protocol^[link38]

Глава 6.The DH Shared Secret Key
Обратите внимание на 6.1 Key Derivation Function (KDF)

In most, if not all, instances we need to modify the shared secret key obtained in the DH protocol in order to use it with other cryptographic primitives. Here are the main motivations for “modifying” the shared DH secret key:

Although some bits of the shared secret are provably secure [13] the security of the vast majority of bits in the shared DH secret key is not known (i.e. it is not known whether an attacker can compute knowledge about them)

In fact, given only p, g, g^x and g^y in Z^*_p, we can easily compute the Jacobi symbol p of g^xy, and if g generates the whole group than we can also efficiently compute the last bit of xy.

См. также:

7.3 Using the Shared DH Secret Key

Here are the general points related to the utilization of the shared DH secret key.
1. Never Use the Key “As Is”: Always use a suitable key derivation function in order to get a session key.

Вы наивно полагаете, что SHA-256 — это "suitable key derivation function"? Я знаю только то, что она ей никогда не являлась.

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

Не падайте духом, но шифрпанки, искренне желающие написать "код без закладок", очень полезны для NSA.

Даже зачастую специально не придумать таких бэкдоров, которые может учудить оптимистичный софтописатель. Циммерман — тоже не криптограф, при всём к нему уважении, он такой же шифрпанк своего времени. Благо, его код привлёк в своё время очень большое внимание и его направлял даже Шамир.

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

OCB — похоже удачный и обоснованный выбор. Хотя и грамотно реализованный CTR с аутентификацией тоже бы подошёл.

Поищу-почитаю, спасибо.

Если они ссылаются на это^[link39], то ничего плохого. Только без устаревших хэшей (sha-1, md5).

Ну разве что в отдалённом будущем ожидаются универсальные PRP-PRF-примитивы и все эти нагромождения когда-нибудь устареют.

ПС: я не ставлю основной целью разработать суперзащищенное приложение, просто мне интересно разобраться. Это как вязание для домохозяйки, что-ли... :)

Покопал код PGPFone: действительно, уязвимо было...

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

Изменил таким образом:
использую PKCS#5 v2.0 PBKDF2 using HMAC_SHA256, 4096 итераций;
https://polarssl.org/pbkdf2-source-code
http://tools.ietf.org/html/rfc2898#section-5.2
отдаю ей в качестве пароля все биты общего секрета DH;
получаю 512 бит кей-материала для двух ocb-AES-256 ключей;
в качестве IV для ocb использую счетчик от старого режима CTR;
128-битный таг дописываю в конец каждого пакета.

3DES и AES256 в режимах CTR без аутентификации оставил для случаев экономии трафика при работе внутри Tor, т.к. длина пакета на 16 байт меньше, а особой необходимости в шифровании и нету.

Если есть явные ляпы или предположения уязвимости, очень прошу озвучить.

симметричный шифр в режиме CTR вообще не имел никакой аутентификации (даже crc32 считалась от криптотекста и просто дописывалась в конец пакета :(

PKCS#5 v2.0 PBKDF2 using HMAC_SHA256, 4096 итераций;

в случае использования какого-нибудь adpcm

это даже избыточно. PBKDF2

SHA-1 и SHA-2 являются не очень хорошими PRF. Для построения стойкого PRF из них используется HMAC. То, что из HMAC в свою очередь делается (для других уже целей) PBKDF2 не значит, что нужно тащить его туда весь. Достаточно правильно использовать только HMAC.

См. RFC4868^[link40] для описания PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, PRF-HMAC-SHA-512.

А касательно передачи файлов – полный п-ц: если злоумышленник точно знает, какой файл вы будете передавать, то вообще без никакой криптографии заменяет его на свой, тем самым подсовывая поддельный документ или трояна.

PGPFone использует нестандартный Циммерманновский протокол передачи файлов, задумывался он как надежный. Он достаточно сложный, я с ним детально не разбирался. Это как бы свой ftp-tcp поверх udp. Имя файла или папки получаем методом drag&drop, выстраиваем файлы в очередь, каждый файл инициализируем (имя, длина, SHA), передаем пакетами размером около 900 байт с указателем, подтверждаем группу байт, дублируем при потерях. Конечно, медленнее чем ftp или http, но выглядет надежно. Используется отдельный счетчик пакетов для передачи файлов. Его значение + тип пакета входят в IV.
Проблема была не в протоколе, а в режиме CTR без аутентификации: зная, какой файл будет передаваться (plaintext), ксором получаем гамму и затем формируем новый cifertext из гаммы и своего plaintext (включая пакет с именем файла, длиной, sha...), пересчитываем crc32 – и подмена готова.
При использовании OCB это исключено. Т.е. после согласования ДИффи-Хеллмана и аутентификации (голосом по списку слов или предустановленной фразой с использованием HMAC) можно быть уверенным в аутентичности файла и конфиденциальности: предварительное шифрование/подписывание PGP вроде как и не нужно. Хотя, конечно, береженого бог бережет...

Наконец нашлось время допилить Торфон до беты 1.1^[link41]. Постарался учесть все замечания и пожелания, а также реализовал две свои идеи, которые давно вынашивал. Руководство по тестированию в картинках обновлю в ближайшее время, пока можно пользоваться обновленным html-хелпом (англ., рус.) в пакете TORFona и на сайте.^[link42]
Хочу представить Торфон как звуковой плагин для популярного Торчата^[link43]: нужно лишь добавить строку HiddenServicePort 17447 127.0.0.1:17447 в файл torrc.txt, запустить Торфон, и можно выполнять и принимать звонки. В любой момент разговора можно переключиться на прямое UDP-соединение (выполняя NAT Traversal), просто установив галочку "UDP". Затем можно выбрать HQ-кодек (например, OPUS) и наслаждаться связью. Или выбрать супер-экономный MELPE и расходовать всего 2 Мбайт GPRS (в обе стороны) за час постоянного разговора. Сравните со Skype...
Само собой, TORFone полностью портабельный, работает c трукриптовского диска, из-под виртуалки WinXP^[link44] (с сетевыми и звуковыми драйверами) и из-под Wine. Я взял на себя смелость внести значимые изменения в криптографию, поэтому версия 1.1 не совместима с 0.X
Криптография:
1. Добавил AES-256-OCB^[link36] (128 bit MAC).
Есть смысл использовать при прямых соединениях и меньше – при работе через Tor (чем больше длина пакетов, тем больше задержка)
2. Для получения ключей с общего секрета DH использую PKDF2^[link45]
3. В процедуре аутентификации по списку слов заменил SHA1 на HMAC_SHA1 для предупреждения атаки подмены выбранного откр.текста (вместе с общим секретом там хеширутся еще куча параметров, которые можно менять).
4. Проверил источники энтропии CSPRNG, там все ОК (мышь, аудио вход, таймеры производительности и системного времени), но на выходе заменил SHA1 на HMAC_SHA1 из соображений рэндомности.
5. В двухфазной аутентификации с скрытым уведомлением под прессингом использовал PKDF2 для формирования тэга из фразы и HMAC собственно для аутентификации.
Голос:
1. Использовал кодеки MELP-2400^[link46] (MIL-STD-3005) (MELP не любит встроенный высокочувствительный микрофон: намного лучше выносной в составе гарнитуры у губ говорящего с минимально необходимой чувствительностью (в т.ч. и из соображений анонимности)) и CODEC2-1400^[link47] для работы через Tor, накапливая 900 и 1600 мс голоса соответственно в одном пакете: так компенсация Jitter даже лучше, чем при пользовании дополнительного буфера.
2. Добавил кодек MELPE-1200^[link48] (STANAG-4591 NATO) и CODEC2-3200 для работы через GPRS: при приемлемой задержке в 350 мс получается всего 0.3-1.0 Кбайт/сек в одном направлении.
3. Добавил HQ-кодеки GSM0610
(взял со SpeekFrealy^[link49] )и OPUS^[link50] в режиме VBR 6 Кбит/с с возможностью опции маскировки VBR для предупреждения атаки фонетической реконструкции^[link14].
4. Добавил опцию подавитель шума NPP7^[link51] для подавления случайных деанонимизирующих звуков окружения.
5. Добавил опцию вокодера для деперсонализации голоса. Использовал алгоритм синтезирующего кодека^[link52].
Можно выбрать стандартные предустановленные режимы (голос высокий, низкий, робота, шепот, интонация вверх и вниз). По данной теме очень мало материала в паблике, похоже, такой же алгоритм используется дачи анонимных свидетельский показаний в судах^[link53] и выглядит надежным для правдоподобного отрицания при голосовой идентификации.
6. Поправил режим рации (PTT) и голосового управления (VOX), теперь не теряется конец фразы. PTT может быть использован для экономии GPRS-трафика и для удобства общения в Tor (В определенных пределах наблюдается четкая корреляция между общим трафиком и латентностью Tor-канала. Кроме того, латентность существенно выше при использовании Exit-нод, но это уже другая история: кому интересно, поделюсь результатами своих исследований для Tor и I2P).
Транспорт:
1. Наконец реализовал давнюю идею, позволяющую уменьшить Tor-задержки. После установки соединения с HS адресата ему посылается инвайт с указанием своего HS. Вызываемый устанавливает встречное соединение с вызывающим (по другим цепочкам). Голосовые пакеты дублируются в оба канала, используется пакет, доставленный первым (по таймстемпу). Накапливается статистика и периодически через заданный интервал времени более медленный канал согласованно переподключается, пока второй используется. Реально уменьшает задержки в полтора раза. Если отказаться от сторожевых узлов, то возможно, и больше. Не могу сказать, как такое дублирование повлияет на эффективность атак деанонимизации, на Tor-мейл-листе не ответили...
2. Также реализовал свою вторую идею: использование Tor в качестве SIP (если анонимность не важна). Нет привязки к конкретному VOIP-серверу, регистрации и логов на нем, DH выполняется внутри p2p-Tor-шифрования к HS (MitM практически нереально), используется нестандартный UDP-протокол (определенная обфускация от DPI)), если NAT Traversal невозможен, то Tor выполняет функцию TURN.
Абонент находит другого по onion-ссылке средствами Tor-HS инфраструктуры, затем выполняется Diffie-Hellmann под прикрытием Tor и затем NAT Traversal с использованием любого заданного публичного STUN. Я не использовал техники NAT penentratin, поэтому UDP не будет установлено, если оба абонента за симметричными NAT, но это бывает не так часто. Кроме того, проблемы могут быть, если оба абонента за любыми NAT (домашними роутерами) и затем за общим NAT (в локалке провайдера). У меня не было возможности проверить на большом количестве сетей, но во всех проведенных тестах прямое UDP-соединение было установлено. Вобще, было бы очень неплохо убедить разработчиков реализовать такой без-серверный VOIP, например, в Jitsi.
Другое:
1. Добавил индикатор исходящего/входящего трафика (с учетом IP-заголовков) в кбитах/сек и общий счетчик сеансового трафика в кбайтах, а также индикатор состояния двойного Tor-соединения.
2. Для компиляции исходного кода^[link54] теперь достаточно установить Visual C 6.0^[link55] на Windows XP, открыть файл проекта и нажать кнопку. Больше никаких пакетов и внешних библиотек не требуется. Абсолютно все используемые библиотеки в С-исходниках и доступны для анализа.

Спасибо сообществу pgpru за помощь, буду благодарен за замечания и пожелания.

Current domain names trying to confuse users with fake or poor software

Current domain names confusing users about the origin of their software

If I paypal you $15, can you register an onionphone.org domain, and change torfone.org so it's just a simple redirect?

если у проекта будет репутация

К слову о репутации: сегодня зашел на гугл аналитику по сайту проекта пройтись по рефералам. В топ-10 висит censored.onion. Оказалось, Pedo Support Community, и там топик по Торфону уже месяц висит, с тестами, экспериментами и обсуждением. Таки Фрейд был прав на 100%, мотивация рулит! Зауважал – оказывается, они в хорошем смысле этого слова (а торпрожект ?).
Хотел респект отписать, но их капчу не осилил – специфика, однако (это вам не кошки – утята...)

Так как проект 100% на чистом энтузиазме и абсолютно без никакого финансирования

там топик по Торфону уже месяц висит, с тестами, экспериментами и обсуждением.

а что братья по разуму из "трехбуквенной корпорации" не проявили еще интереса? у них денег не мало.

What is Freenet?

"I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'"
Mike Godwin, Electronic Frontier Foundation

Торфон представляет собой Windows программу

атаку "человек по средине".

гарантированное пятой и четырнадцатой поправки к Конституции

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

аналогично, например, Скайп

Может быть использовано как TCP, так и UDP прямое соединение.

соединения с скрытым

UDP соединения.

уведомления под прессингом.

TORFone decentralized ie does not use

Calls using TORFone is hidden to the outside observer

https-connection.

Calls using TORFone is hidden to the outside observer since TOR traffic not differs from usual https-connection. Also in the case of a direct connection using a custom TCP or UDP protocol (not RTP/ZRTP), which protects against some DPI analysis.

• not differs → does not differ
• Второе предложение потеряло подлежащее и сказуемое.

Подумалось: GSoC не позволяет что-то получить? Или там жёсткие возрастные ограничения? Должны быть какие-то международные программы по поддержке открытого софта.

GSoC не подойдёт:

1. Google отбирает наиболее значимые проекты, столь малый проект попросту не пройдёт отбор;
2. проект обязан быть с большим числом участников, нельзя подать заявку на проект, который ведёт один человек;
3. GSoC служит для привлечения сторонних разработчиков из студенческой среды: привлекаемый программист работает над заранее строго определённой задачей, а один из текущих разработчиков выступает наставником, помогающим разобраться в коде; работа наставника требует очень много времени.

Ну, и нынешний GSoC уже начался, так что на текущий год так или иначе в пролёте.

Что подойдёт, так это любая краудфандинговая платформа:

1. Kickstarter^[link58] — если объём пожертвований за ограниченный срок не набирает заданную автором проекта сумму, автор не получает ничего, деньги возвращаются жертвователям; автор проекта должен быть резидентом США.
2. indiegogo^[link59] — если объём пожертвований не набирает заданный автором порог, он всё равно получает деньги, но площадка снимает бОльшую комиссию; площадка работает с зарубежными резидентами.

Эти две вроде самые известные. На волне свежего скандала с Verizon и PRISM вполне можно набрать неплохую сумму, как мне кажется.

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

Могу даже предложить создать раздел в Разработках^[link60], если gegel'ю это интересно.

>Зауважал – оказывается, они в хорошем смысле этого слова (а торпрожект ?).

Какого слова?

а при видеочате ещё и гримироваться надо будет...

gegel, я вам советую создать на сайте торфона форум

>дачи анонимных свидетельский показаний в судах
Ссылка не открывается.

>кому интересно, поделюсь результатами своих исследований для Tor и I2P
Было бы интересно, если бы описали в 2-3 абзацах хотя бы.

если будут блокировать весь неопознанный трафик

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

Некоторые замечания к тексту

Могу даже предложить создать раздел в Разработках, если gegel'ю это интересно

Предлагаю поменять приоритеты позиционирования:

Приоритеты 2 и 3 лучше поменять местами.

А название – СrypTorFone ;)

Видеочат будет? :)

Могу даже предложить создать раздел в Разработках, если gegel'ю это интересно

Интересно, но только не представляю, в каком виде лучше подать информацию.

Я сам не особо силен в php и web, но попросил друга – он обещал помочь в ближайшее время.

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

Неоткрывающиеся ссылки содержат пробелы в пути

""http://ссылка с пробелом""

если будут блокировать весь неопознанный трафик

Это жестко. Вряд-ли такое реально

я не ставил целью серьезную обфускацию, да и, наверное, вовсе не так это делается, если по уму.

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

1. Внятное техническое описание существующего протокола.
2. Внятное описание фич, которые имплеменчены в текущей версии.

концепция свободной без-серверной VOIP на основе Tor HS вместо SIP, похоже, тоже нова, нигде ранее не выдвигалась (поправьте, если не прав), и имеет право на существование.

А название – СrypTorFone ;)

А вот это – просто гениально!

Да и, как выяснилось, реальная анонимность практически понадобилась лишь сами видите кому.

TOR is too slow for any real time protocol, such as telephony.

у вас есть шанс доказать обратное

у меня проект по слежению за подвижными объектами (трекинг через GPRS по GPS и по сотовым вышкам), так там до десятка разных серверных протоколов поддержано.

Список:
  1. Пункт 1.
  2. Пункт 2.

Поэтому, такие ситуации принято пресекать в зародыше.

Cryptorphone смешивается сразу с двумя, как с Tor, так и Cryptophone.

созвучие торговых марок до степени смешения

Да, всех, если будет связь с Tor и если это будет TradeMark с близким к Tor функционалом

т.к. это из другой области

К чему здесь все эти спекуляции? На месте gegel'я, я бы просто уточнил у руководства Tor Project, нет ли у них претензий к такому наименованию. Подозреваю, что если не акцентировать в названии фрагмент "tor" (как CrypTorFone вместо Cryptorfone или CryptorFone), то и возражений не будет.

Вот то, что возражения будут со стороны GSMK Gesellschaft für sichere Mobile Kommunikation mbH, это я почти гарантирую.

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

И потребность в этом сомнительна. Зачем тогда голос?

Анонимность в голосовой связи играет вспомогательную роль в ситуациях:

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

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

И потребность в этом сомнительна. Зачем тогда голос?

По теме вокодеров вообще немного теоретических публикаций.
Прмененный мною код основан на синтезирующем LPC кодеке. Кодер представляет собой анализатор, который, грубо говоря, определяет наполнение речи по формантным зонам, высоту, заполненность/шум и т.д. Таким образом, речевой фрейм описывается коротким битовым кадром, содержащим минимально необходимою информацию об исходной речи. Декодер синтезирует речевой фрейм по этому кадру (т.е. это уже не нативная речь). Вокодер изменяет некоторые параметры в кадре, например, меняя темп речи (делая ее монотонной) или фиксируя/динамически меняя высоту, или вообще убирая озвучку (шепот). Т.к. системы речевой идентификации/распознавания используют эти же параметры, то не представляется возможным уверенно доказать совпадение/несовпадение измененного голоса с оригиналом.
Конечно, это касается лишь характиристик "нижнего уровня", определяемых анатомо-физиологическими особенностями говорящего. "Верхний уровень" (словарный запас, устоявшиеся фразы и т.п.) остается деанонимизатором, хотя врядли будет иметь юридическую силу, т.к. эти признаки легко изменить сознательно, посто не забывая об этом в процессе разговора.
Посмотрите также opensource проект Zerius Vocoder^[link66], работающий по сходному принципу, но вместо использования некоторых предустановленных параметров в кадре, извлекающий эти параметры из другого звукового потока. Это дает возможность в некоторой степени имитировать речь другого человека, или разговаривать гитарой, например. Также есть софт (коммерческий), позволяющий реал-тайм смещать тональность голоса под тональность музыки (для начинающих певцов) и т.п. Я также находил open source проекты голосовой идентификации/авторизации. Если есть интерес, поищу ссылки в архиве.
В любом случае, этот принцип вокодера используется в программах защиты свидетелей в тех же судах, где, возможно, будет доказываться и вопрос принадлежности вашего голоса, и выглядят надежно:
srs.kiev.ua/images/stories/PDF_brochures/SRS Anonymity System RU.pdf

ПС: Asterisk Voice Changer^[link67]
а это, к примеру, алгоритм совсем другого класса, обеспечивающий простой сдвиг тональности голоса, который легко восстановить такой же программой. То же касается и Skype Voice changer^[link68] .

А что касается востребованности вокдера, то далеко и ходить не надо: в случае выше упоминавшейся комьюнити Алиса как раз не знает Боба, и Боб крайне заинтересован в том, чтобы ни Алиса, ни Ева его не узнали позже. Со стороны Алисы вокодер не нужен, но со стороны Боба может быть использован (Торфон, естественно, представляет возможность абоненту включать вокодер своего голоса независимо от другого). Единственно что в таком режиме желательно использовать гарнитуру, чтобы исключить изменение своим вокодером входящего голоса абонента: в этом случае в наличии будет комплект: нативный+измененный голос абонента, что может облегчить предположительное восстановление вашего голоса.

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

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

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

эти ребята развлекаются

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

Запись работы вокодера^[link70] Торфона в разных режимах (wav).

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

А это ролик тестирования вокодера^[link71] автором алгоритма William Andrew Burnson. Т.к. он использовал кодек GSM 11025 KHz, то дополнительно получился сдвиг тональности (алгоритм вокодера считал, что на него поступает 8000 КГц аудио). Из-за этого появились дурацкие высокочастотные призвуки, но и тем не менее, все разборчиво, особенно хорошо в режиме робота и шепота.

DJ Gegel – трэк 1 – Проверка холоса.
Респект UA ;)

В варианте 1 было: "Пговегка голоса", но изменил силой воли, по паспорту таки UA :)

ваш голос добален в нашу базу

Удивили... Наверное, в вашей базе даже диаметры всех моих отверствий давно имеются. Писать тут полгода со своего айпи... Но, тов. начальник, я ведь не нарушаю ;)

This product is produced independently from the Tor® anonymity software and carries no guarantee from The Tor Project.

А сколько было обещаний! И развитие,и порт для Linux, и т.д и т.п.

Намек на что? Кто-то заплатил чтобы проект не развивался? ;)

И развитие,и порт для Linux, и т.д и т.п.

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

Полурабочий полуфабрикат

Я бы так не сказал. Укажите конкретно, что бы Вы хотели добавить, и что не работает, как хотелось бы. У меня исчерпалась фантазия: все мои идеи были реализованы в последней версии. Но только не просите, ради Бога, смайлики: придется "жить с серым и унылым чатом" ^®ZAS

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

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

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

Боюсь, что это в принципе невозможно. Даже на благоприятном фоне разоблачений Сноудена проект заинтересовал лишь очень узкий круг пользователей. Я лишний раз убедился, что участники pgpru – абсолютно не репрезентативная выборка к этой вашей широкой публике. Выйдите в город и поспрашивайте у народа, что кто знает о шифровании :) Даже большинство моих знакомых программистов имеет весьма туманное представление о базовых принципах криптографии, не говоря уже о реализации протоколов.

Лично я для себя считаю проект успешным, т.к. было наглядно показано, что:

• передача голоса вполне реализуема на ТСП-транспорте;
• на сегодня Tor обеспечивает приемлемую пропускную способность и латентность для потоковой передачи голоса с терпимыми задержками.

Любой пессимист может в этом убедиться, просто скачав и запустив Торфон "из коробки", и это должно подтолкнуть разработчиков к реализации своих проектов.
Впереди, как всегда, guardianproject^[link74].

Правда, они поленились и пошли по пути меньшего сопротивления, реализовав лишь подобие голосовой почты, несмотря на short-term grant from the Tor Project, но все впереди.

Опять же, зависла уникальная идея Tor-видео с передачей потока через множество Tor-цепочек между HS, алгоритмом отбора быстрых и дублирования сомнительных цепочек: наверное, педофилам уже перехотелось. Но такие проекты – однозначно не для одного человека, пишущего в свободное время и под настроение.

Что такого должно стоять за проектом, чтобы его назвали значимым?

Концепция, теоретические разработки, публикации, куча документации, отлаженное сообщество по разбору багов, масса всего, а код — только финальная крохотная часть работы на выходе, как капля в море. Чтобы по описанию протокола можно было легко разработать параллельную ветку кода даже не подглядывая в исходники.

В реальности — это конечно недостижимый идеал. Даже проект уровня Tor слабо ему соответствует — они уже захлебнулись разбирать 30 тикетов в день. Обычные OpenSource проекты справляются с нагрузкой, привлекая как можно больше разработчиков. Но если представить, что OpenSource проект связан секретностью/псевдонимностью, то его уровень скатится до очень низкого. Так же, при всей талантливости, малоперспективны проекты разработчиков-одиночек. Даже открытые, но где официальный разраб — только один. По этой причине маргинализовался и провалился линуксовый loop-aes против cryptsetup/dm-crypt, хотя изначально он намного опережал аналоги.

Not Found

The requested URL /forum/index.php was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

---

Apache/2.2.26 (Unix) mod_ssl/2.2.26 OpenSSL/1.0.1e-fips mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at torfone.org Port 80

но касаемо документации замечания есть

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

Форум ещё не прикручен?

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

2 /comment77388^[link83]:

С полгода с приятелем мы попытались заюзать Totfon.
Приятель – сисадмин с 10-летним стажем, сертификат MS и все такое, я просто опытный пользователь.

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

Вспомним начало проекта Tor, уже более 10 лет прошло. Он разрабатывается под Linux, версии под Windows сначала шли с большим отставанием. Никакого инсталлятора и графического конфигуратора под винду вроде не было, тем более готового браузера с преднастроенной связкой всего нужного. Сухой технический мануал-readme. В винде нужно было вручную распаковывать, ставить и запуcкать консольную программу, править руками (через тот самый дефолтный винблокнот) конфиги, прописывать прокси в браузере. И это ещё не всё. Tor не был самодостаточным. К нему надо было качать с другого сайта локальный промежуточный прокси со своей пачкой конфигов — privoxy, который торпроджектом не поддерживался, был вообще полузаброшен. Не помню, как там в винде решали и проблемы с SSL-либами.

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

Разработчики GnuPG над этим вообще не парятся. Есть консольная версия, слабо подходящая рядовому пользователю, и либа для сторонних программеров. За создателей GUI они не особо отвечают.

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

Скачайте архив Торчат, разархивируйте ...

есть общие замечания по поводу сайта.

Ссылка у вас здесь – нерабочая.

Но звонки друг другу по сгенерированным Точатом адресам ни к чему не привели.

Указали в Torfone IP-свои адреса

причина неконнекта в том, что не открыты какие-то порты в файрволах.

Где в вашем манауле есть описание протоколов и портов, которые нужно открыть?

В качестве слушающего все доступные сетевые интерфейсы будет использован UDP-порт с тем же номером, что и TCP, заданным в параметре ListenAddr:Prt

Лучше создайте какую-нибудь временную аську

Gegel, скажите чесно, Linphone чемто уступает вашему Торфону в плане защиты трафика?

Говорю честно: в плане защиты трафика ничем не уступает. Linphone может использовать ZRTP для p2p-шифрования голосового трафика.

Но это фундаментально разные приложения:
1. Linphone – это SIP-клиент и не может работать без внешнего SIP-сервера (включая обязательную регистрацию на нем с возможностью сбора данных о ваших контактах), в то время как Торфон использует Tor-HS для поиска абонента (не требует регистрации, нет возможности собирать метаданные).
2. Linphone использует RTP для передачи голоса, в качестве транспорта используется UDP, поэтому передача голоса через Tor принципиально невозможна – абоненты в конечном итоге устанавливают p2p-соединение. таким образом, каждая сторона видит IP второй стороны (т.е. знает, где он находится), и наблюдатель (ISP абонентов или SIP-сервера) видит IP участников беседы. Торфон может использовать нестандартный голосовой протокол на базе TCP, поэтому может установить двухсторонне анонимную связь через Tor, но ценой секундных задержек голоса.

Но мне другое интересно – что же в вашем случае помешало связать Торфоны? даже не предполагал, что это может вызвать хоть какую-то сложность. Я так понимаю, вы хотите установить прямое соединение с другим Торфоном?

Предполагается, что абоненты имеют "белые" IP от своих ISP:
1. Скачиваем архив, извлекаем из него папку Торфона.
2. В файле 'torfone.ini' блокнотом правим параметр ListenUDP=1
3. В роутерах абонетов пробрасываем UDP-порт 17447 на компьютер с запущенным торфоном
4. Для звонка в адресную строку вставляем внешний IP-адрес вызываемой стороны с символом @ вначале ( например, @74.99.25.25 )
5. После установки соединения оба абонента переключают кодек с MELP на OPUS

Если ваш ISP выдает "серые" IP, то нужет TorChat. Оба абонента делают следующее:
1. Скачиваете архив с TorChat с главной страницы моего сайта (в нем уже поправленный torrc-файл)
2. Запускаете TorChat, дожидаетесь, пока значок MySelf станет зеленым.
3. Копируете с этого значка свой адрес и обмениваетесь им с вашим абонентом.
4. Запускаете Торфон, вставляете Torchat-адрес (без .onion) вашего абонента в поле адреса Торфона и вызываете.
5. После установки соединения оба абонента устанавливают галку Edit -> UDP/TCP -> UDPdirect
6. После короткого звукового сигнала и сообщения о переключении на прямое соединение можно сменить кодеки на OPUS.

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

Круто было бы увидеть в торфон'е изменение голоса.

Да, увидеть – это было бы круто. Но для этого, как минимум, надо увидеть руководство в картинках^[link56] на стр.5., тогда по крайней мере изменение голоса можно услышать.
Также можно посмотреть демо-ролик^[link71] от автора кода вокодера William Andrew Burnson. Правда, он выбрал кодек, работающий не на 8КГц, поэтому наложился сдвиг полосы и появились свисты. Для качественной работы вокодера используйте OPUS, MELP или GSM0610slow. На мой взляд, для анонимизации лучшим есть режим Breathy (шепот).

Если дадите ссылку

– MorphVOX^[link87]
– AV Voice Changer Software^[link88]
– Scramby^[link89]
– VoiceMask Pro^[link90]

- MorphVOX^[link91]
– Scramby^[link89]

По моему самое оно!

Roger: Torchat has nothing to do with Tor and we haven't looked at it or evaluated it in any way. (In large part this is because they picked a confusing name for their program, so we spend energy teaching people that it's a confusing name rather than actually looking at it).

Gegel, заведите себе криптокошелек

Ну нужна распознавалка из голоса в текст и читалка из текста в голос.

Вот в Андроиде Гугл-переводчик теперь умеет работать локально, файл порядка 150 мб на язык.

что идентификация по голосу наоборот улучшится?

у нас доверия к другим клиентам неизвестно кем сляпанный и на кого работающим, особенно после разгрома тов. Gegel'ем Linphone'а

слышит голос с треском и хрипением,

sudo apt-get install libncurses5-dev

rounds

Как тут лучше поступить, где запускать OpenVPN-сервер и OpenVPN-клиент – в базовом Linux или гостевой Виндовс?
И как, если это повысит информационную безопасность, закрыть с помощью Iptables все адреса/порты, не участвующие в разговоре по Torfone?

Для такого государства, как Россия, это не деньги, шелуха.

Тов. Gegel, вас еще не пытались купить спецслужбы? ;)

Не-а, никто не пытался :(
Да и Торфоном, судя по гугланалитике, интересуются лишь честные люди: с r2d2, runion, pedoimperia и т.д., ну и штурмовики с разных лагерей еще.
Если покупать, то не меня, а проект, но тут есть проблема. Торфон – самодостаточная система, его безопасность зависит только от исполняемого файла и от Tor (нет сервера, который можно взять под контроль). Кроме того, не предусмотрено автоматического обновления, как в Skype или даже в хваленном Jitsi (который мало того, что под обновляемой Java, но и сам лезет на свой сервер тотчас после первого запуска).
Так что только если я начну активно петь об новой улучшенной версии или, наоборот, об страшной уязвимости, требующей немедленного обновления, значит, можете поздравить – таки купили :)

PS: SpeakFreely под Linux проверил, все функционирует ОК, как Linux-Linux, так и Linux-Win32. Чистая консоль, минимум библиотек, относительно простой код на С (всего два потока для двух направлений передачи). Сейчас разбираюсь в коде, найду время пропатчить и ввести добавочный TCP-транспорт и поддержку SOCKS5, вычищу от утечек DNS, и можно будет пробовать через Tor.
Прямое соединение можно пробовать и сейчас с нативной версией (там есть поддержка AES-128 в CBC на предрасшаренных ключах, но, похоже, без MAC – голос как аутентификаитор, Шнаер допускает такой вариант). Заодно подскажите, что можно убрать/добавить для удобства практического применения.

SpeakFreely под Linux проверил, все функционирует ОК

PS: SpeakFreely под Linux проверил, все функционирует ОК, как Linux-Linux, так и Linux-Win32. Чистая консоль, минимум библиотек, относительно простой код на С (всего два потока для двух направлений передачи).

А тут бац – и SpeakFreely. "© Кто такой, зачем, почему?"

На сайте Торфона с самого начала существует страница, где сделан порт SpeakFreely-Win32 для работы через Tor.

Но в самом деле, как в этом довольно старом проекте с уровнем криптозащиты?

В версии 7.2-Win32, которую я патчил год назад, AES нет, только DES-56 в ECB-режиме без никаких MAC (тоесть никак). В версии 7.6, на которую я давал ссылку, есть AES-128. Но не это сейчас главное: шифрование – не проблема, я прикручу все, что пожелаете. Планируется AES-256-OCB и Keccak-SpongeWrap в качестве красивой игрушки. Ну, и ECDH25519 для периодического наложения на имеющийся предрасшаренный ключ для PFS.
Гораздо важнее другое: TCP-транспорт, кодеки и т.д. Портировать Торфон под Linux as-is – весьма геморройное занятие. Нативный PGPFone написан на С++ под VisualC с использованием специфической для Win32 MFC и развитым GUI. Существенное снижение трудозатрат – взять готовый проект под Linux (пользовательский интерфейс, работа со звуком, буферизация, интернет-сокеты) и добавить к нему код из Торфона (благо, все, добавленное мною – на С). Это и шифрование, и кодеки, и проход NAT. Можно даже один в один повторить протокол Торфона, и сделать поную обратную совместимость, хотя эта идея не особо меня впечатляет, т.к. лучше сразу создать версии под разные платформы (или даже попробовать cygwin + прицепить GUI под Win32).
Можно назвать это Linux-Тофрон (или onionphone, чтобы не драконить Роджера).
Но в любом случае C-код SpeakFreely анализировать куда проще, чем С++ код Торфона, т.о. желающим будет проще найти потенциальные баги.
Еще раз повторюсь: из SpeakFreely я хочу взять командный интерфейс и логику консоли, работу со звуком и частично с сетью. Остальное – из Торфона.
Иначе, если пытаться делать новое Linux-приложение с нуля или один в один портировать Торфон вместе с GUI, этот проект так и умрет, не родившись.

Обещанного завершенного юзабельного Торфона мы уже сколько ждем – полгода или год?

Вот поэтому качественный кроссплатформенный сишный код сначала делают на Linux

Вот поэтому качественный кроссплатформенный сишный код сначала делают на Linux,.....

А GUI под Linux никому тут не интересно.

Forbidden

You don't have permission to access / on this server.

1. Отключить IPv6^[link108] [Важно! Файерволлом он не блокируется].

2. Удалить утилиту ping [опционально]. Ни в коем случае не разрешать ICMP в файерволле. ICMP всегда посылается с правами рута, какой бы юзер ни был указан в качестве отправителя. Не забывайте об этом.

3. С учётом требований конкретного софта отредактировать под себя следующий скрипт и выполнить его:

   #!/bin/sh
   # iptables script
    
   # Сброс ранее загруженных правил:
   iptables -F ;
    
   # Установка политик:
   iptables -P INPUT DROP ;
   iptables -P OUTPUT DROP ;
   iptables -P FORWARD DROP ;
    
   # На машине используются только 2 сетевых интерфейса: loopback (lo) и eth0.
   # Трафик уже созданных соединений идёт без фильтрации:
   iptables -A INPUT -i lo -m state --state ESTABLISHED -j ACCEPT
   iptables -A INPUT -i eth0 -m state --state ESTABLISHED -j ACCEPT
    
   # ФИЛЬТРАЦИЯ НА LOOPBACK-ИНТЕРФЕЙСЕ (ЛОКАЛЬНЫЕ ПАКЕТЫ)
   # (Если не нужно, всё закомментировать; если нужно, отредактировать под себя):
    
       # Разрешить софту, запущенному от имени юзера USER1,
       # инициировать соединение с адресом 127.0.0.1:1111 по TCP:
       iptables -A OUTPUT -o lo -s 127.0.0.1 -d 127.0.0.1 -p tcp \
                   -m owner --uid-owner USER1 -m tcp --dport 1111 -j ACCEPT
       # Разрешить принимать TCP-пакеты на адрес 127.0.0.1:1111:
       iptables -A INPUT  -i lo -s 127.0.0.1 -d 127.0.0.1 -p tcp \
                   -m tcp --dport 1111 -j ACCEPT
    
       # Разрешить софту, запущенному от имени юзера USER2,
       # инициировать соединение с адресом 127.0.0.1:2222 по UDP:
       iptables -A OUTPUT -o lo -s 127.0.0.1 -d 127.0.0.1 -p udp \
                   -m owner --uid-owner USER2 -m udp --dport 2222 -j ACCEPT
       # Разрешить принимать UDP-пакеты на адрес 127.0.0.1:2222:
       iptables -A INPUT  -i lo -s 127.0.0.1 -d 127.0.0.1 -p udp \
                   -m udp --dport 2222 -j ACCEPT
    
   # ФИЛЬТРАЦИЯ НА eth0-ИНТЕРФЕЙСЕ (ВНЕШНИЕ ПАКЕТЫ)
   # (Если не нужно, всё закомментировать; если нужно, отредактировать под себя):
    
     # ИНИЦИИРУЕМЫЕ НАМИ СОЕДИНЕНИЯ НАРУЖУ:
    
       # Разрешить софту, запущенному от имени юзера USER3,
       # инициировать соединение с адресом X.X.X.X:3333 по TCP:
       iptables -A OUTPUT -o eth0 -s ВАШ_IP_НА_eth0 -d X.X.X.X -p tcp \
                   -m owner --uid-owner USER3 -m tcp --dport 3333 -j ACCEPT
    
       # Разрешить софту, запущенному от имени юзера USER4,
       # инициировать соединение с адресом X.X.X.X:4444 по UDP:
       iptables -A OUTPUT -o eth0 -s ВАШ_IP_НА_eth0 -d X.X.X.X -p udp \
                   -m owner --uid-owner USER4 -m udp --dport 4444 -j ACCEPT
    
     # ПОДКЛЮЧЕНИЕ К НАМ ИЗВНЕ (ОПАСНО ДЛЯ АНОНИМНОСТИ И БЕЗОПАСНОСТИ):
    
       # Разрешить хосту X.X.X.X инициировать соединение с нашим адресом
       # ВАШ_IP_НА_eth0:5555 по TCP:
       iptables -A INPUT -i eth0 -s X.X.X.X -d ВАШ_IP_на_eth0 -p tcp \
                   -m tcp --dport 5555 -j ACCEPT
    
       # Разрешить хосту X.X.X.X инициировать соединение с нашим адресом
       # ВАШ_IP_НА_eth0:6666 по UDP:
       iptables -A INPUT -i eth0 -s X.X.X.X -d ВАШ_IP_на_eth0 -p udp \
                   -m udp --dport 6666 -j ACCEPT

   Если где-то что-то нужно разрешить для всех, конкретизирующий параметр (например, адрес хоста или порт) просто не указывается. Вначале ESTABLISHED, возможно, нужно заменить на RELATED,ESTABLISHED, но я не уверен. Эти правила — на ваш страх и риск, т.к. я не специалист по iptables. Правильно внимательно прочитал, но это не исключает ошибок и отпечаток, и нажимую я их не тестировал.
   
   Последние обсуждения того, как правильно писать безопасные правила для iptables, были тут^[link109]. Низкоуровневость iptables, вытекающая из этого требовательность внимательности к мелочам, большой объём текста даже для самой минимальной политики фильтрации — основные факты, из-за которых считается, что в Linux нормального файерволла нет. Интеграции iptables с окружением тоже нет (поэтому всё делается в виде самописных скриптов). На старте системы правила могут не работать^[link110]. Стандартных способов загрузки правил тоже нет: каждый их суёт туда, куда вздумается, в стартовых скриптах. Поддержки owner для входящих пакетов в iptables также нет. iptables — говно, ненавижу^Wне используйте iptables. Там, где можно, не используйте iptables, используйте pf. У последнего нет перечисленых недостатков, правила удобочитаемые человеком, а писать их легко, приятно и безопасно^[link111].^*
   
   Проверка загруженных правил — команда iptables-save.

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

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

Сама такая возможность многим тоже интересна, как концепт. Я слежу за её развитием, но никакой конкретный проект пока практического интереса не вызывает. Ни в каком «общем деле» я не участвую. Отвечаю на те вопросы, которые лично считаю интересными со своей субъективной точки зрения и не более того.

под себя следующий скрипт и выполнить его:

Отключить IPv6 [Важно! Файерволлом он не блокируется].

Там, где можно, не используйте iptables, используйте pf. У последнего нет перечисленых недостатков, правила удобочитаемые человеком, а писать их легко, приятно и безопасно.*

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

> В линуксе под названием BSD, причём во всех BSD и их деривативах вплоть до Mac OS X

Те, кто знают про ip6tables, всё равно предпочитают отключить ipv6 на уровне ядра, потому что им самим ipv6 не нужен.

это файрволл, управляющий ipv6. Если ipv6 у вас будет отключен^[link108], то и этот файрволл настраивать не понадобится.

Вы уверены, что при отключении скрипта, стартующего файрволл для ip6tables, отключается сам ipv6-протокол? Как вы это проверяли?

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

Почитайте, что типа этого^[link117] хотя бы. Если ipv6 запретить на уровне старта ядра, остальные компоненты работы системы, предназначенные для работы с IPv6, лучше даже не выключать, а удалить за ненадобностью.

Вы уверены, что при отключении скрипта, стартующего файрволл для ip6tables, отключается сам ipv6-протокол? Как вы это проверяли?

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

Действительно, они в одном пакете, так что по отдельности штатно не удалить, да и смысла получается нет. Но ip(6)tables не обеспечивают работу протокола, они только управляют фильтрацией уже включенного (если он всё таки есть и включен). Вообще, это уже оффтопик в теме. На сайте приведено масса способов отключения IPv6, да и на обычном линуксовом сайте или в мануале к своему дистрибутиву найти конкретный и наиболее подходящий вам ответ проще. И результаты действий надо тщательно проверять. И не пользуйтесь его конфигами. Изучите всю систему инициализации сети с потрохами, чтобы написать свой скрипт управления файрволлом вместо неудобного ip(6)tables-save и ip(6)tables-restore. Прострелить себе при этом ногу — очень просто, поэтому опять же, не забывайте про тщательные проверки.

XP – Must Die!

ХР — на мой взгляд, лучшее, что вышло в свет из застенок Майкрософта.

Поддерживаю. И 98 – тоже весьма неплохой вариант: разрешен прямой доступ к физическим портам ввода-вывода. Embedded-разработчику это часто нужно для написания всяких утилит для отладки проектов на микроконтроллерах: я обычно в борландовском С++ билдере (среда программирования для домохозяек) пишу короткие ассемблерные вставки с быстрым доступом к физическим портам. Вообще для подавляющего большинства удобство всегда было важнее безопасности, поэтому я все же предпочитаю Windows.

Особенно прочувствовал это в последние дни, пока портировал Торфон под линукс. К счастью, с положительным результатом: пропатчил код оригинальной SpeakFreely for Unix^[link126], теперь Linux-вариант совместим с ранее пропатченной мною Win32-версией^[link127] и уже работает через Tor под моей Ubuntu (думаю, и другими nix). Чуть зашлифую, немного потестирую код и выложу на своем сайте. Т.к. Tor обеспечивает оконечное шифрование к HS, то даже в таком виде ее можно использовать для защищенной связи, не смотря на слабость родной криптографии.
Превращение в задуманный OnionPhone планирую осуществить в три этапа:

На первом добавить три варианта крипто (стандартый – AES256-OCB, альтернативный – Serpent128+HMAC256 и модерн Keccak-SpongeWrap), CSPRNG, а также провести аудит кода на предмет крипто-надежности.

На втором добавить кодеки, поддерживаемые TorFone (Opus, Codec2, MELPE), вокодер и шумоподавитель.

На третьем добавить возможность переключения с Tor на прямое UDP-соединение с проходом NAT (используя Tor в качестве SIP), а также оптимизацию Tor-латентности за счет смены цепочек.

Будем надеяться, что все задуманное будет реализовано. Советы и пожелания весьма приветствуются.

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

ХР — на мой взгляд, лучшее, что вышло в свет из застенок Майкрософта. По ощущениям, на фоне остальных продуктов, начиная с тех же 95 или 98 и заканчивая 7 и 8.

Лучше оставьте минимум методов и протоколов, но наиболее востребованных и с наилучшими характеристиками.

Жду- не дождусь, когда заработает надежное прямое соединение!

Или назовите TorFone Pro

Лучше оставьте минимум методов и протоколов, но наиболее востребованных и с наилучшими характеристиками.

Мне кажется, это и есть необходимый минимум.

Вы — большинство?

Маскируюсь :) Но я привык к оконному интерфейсу, и ценю те удобства, которые он предоставляет.

тот минимум коммуникаций, который нужен gegel'ю, наверно, можно получить и без всяких TorChat'ов

Собственно, никакой минимум, кроме Tor, и не нужен: Торфон подключается к SOCKS5-порту Tor непосредственно. TorChat работает независимо параллельно через тот же Tor-HS и интересен в двух аспектах:

1. TorChat обеспечивает взаимную аутентификацию (по онион-адресам). Если на ваш Торфон кто-то звонит, вы понятия не имеете, кто это. Если вам кто-то пишет в TorChat, вы уверены, что это именно тот адрес, который отображается в контактах. В разных ситуациях и то, и другое может быть как полезно, так и нет.

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

Вызываемый создает параллельное соединение к HS вызывающего и передает ему nonce по вновь созданному каналу.

Вызывающий возвращает полученный nonce по первичному каналу. Т.е. это в точности протокол Abadi. Далее абоненты отсылают сообщения каждый по созданному им же каналу без всякого дополнительного шифрования (Tor сам шифрует их публичными ключами HS получателей).

Кстати, Торфон неявно делает то же в случае использования режима дублирования цепочек.
Это можно без проблем реализовать в течение получаса, или даже в точности повторить синтаксис протокола TorChat, инкапсулировав его в Торфон.

Я не вникал подробно в протокол Tor, и не могу сказать, как в данном случае обстоит дело с PFS и тем более с отрицаемостью в TorChat: если позже злоумышленник получит доступ к файлу private_key в папке hidden_service получателя, сможет ли он прочитать ранее записанные сообщения, или же внутри канала производится еще и DH (т.е. используются сеансовые ключи). Но это проблемы Tor, а не TorChat.

2. И основное, что меня склоняет к использованию Linux-Торфона совместно с TorChat: возможность определения он-лайн присутствия контактов с готовым графическим интерфейсом. Конечно, можно реализовать это и на С, но вылепить вывод в консоли – это как секс стоя в гамаке, тем более при моем положительном отношении к оконному интерфейсу.

какой вариант TorChat лучше использовать

Как и обещал, адаптировал Unix-версию SpeakFrealy7.6^[link95] для работы через TCP и Tor. Бинарные файлы с поддержкой TCP/SOCKS5 (с сайта Торфона) в sf76_01a.tar.gz^[link130], исходники (чистый С) в sf76_01a_src.tar.gz^[link131]
Пока ссылки выложил эксклюзивно только на форуме, так сказать, для внутреннего тестирования.

Тестирование: распаковываем архив в домашний каталог, работаем из консоли.
Программа работает с ALSA, использует устройства plughw:0,0. Если надо по другому, сразу меняем в файле alsacf.
(также можно перекомпилировать под старый OSS, тестировано на Ubuntu).

Запускаем ./sflaunch, жмем ввод, и еще раз. Если все ОК, слышим свой голос (loopback через localhost).
Если получаем ошибку (так было на DebianLiveCD), открываем файл alsacf и комментируем # первую строку (там размер чанка и их к-во в буфере). После комментирования система сама выбирает значение, и оно будет выведено в консоль. Если ОК, то меняем в первой строке на значения по умолчанию и убираем комент. Или можно поиграть с величинами, рекомендации ниже в фале alsacf.

Программа слушает порт 17447 на всех доступных интерфейсах (этот порт по UDP/TCP надо пробросить в роутере для возможности приема прямых соединений по IP), прокси установлен на 127.0.0.1:9150 (последний TBB). Если не так, меняем в файле spfrc.

Для запуска используем ./start, в нем прописана командная строка запуска с опциями. Используется кодек LPC10, включен VOX, компенсация дрожания 0.5 сек. Если надо по другому, меняем. Краткое описание опций ниже в файле start.

После запуска программа готова принимать входящие как по TCP (совместима с моей версией SpeakFrealy_7.2_TCP^[link127], кроме кодека CELP), так и по UDP (полностью совместима с версиями SpeakFrealy_7.6_Win32^[link132] и SpeakFrealy_7.6_UNIX^[link133]).

Для выполнения исходящего звонка по UDP (совместимо с оригинальными версиями) вводим доменное имя или IP-адрес.
Для выполнения исходящего звонка по TCP вводим доменное имя или IP-адрес с символом '$' в начале.
Для выполнения исходящего звонка через Tor вводим доменное имя или IP-адрес или onion-адрес (с суффиксом .onion) с символом '!' в начале.

Для приема входящего звонка жмем ввод. Во время разговора используем ввод для включения/отключения микрофона (MUTE). Можно использовать PTT-режим удержанием клавиши пробела. Для завершения звонка, а также для завершения сеанса после завершения звонка другой стороной жмем Esc. Для входа в режим чата жмем точку. Выход из программы – Ctrl+C.

Примечания:
– собирал на Ubuntu 10.04 i386, gcc 4.4.3. Требует libsound2-dev, остальное – по умолчанию. На 64-битных платформах не собирается, но бинарники работают. Тестировал на Ubuntu и DebianLiveCD. Использовал последний TBB, в файл torrc добавил скрытый сервис на порт 17447 (надеюсь, это не вызовет затруднений, если что – опишу подробнее). На Tails, к сожалению, пока не работает, т.к. я не блокировал UDP-сокеты для совместимости с оригинальной SpeakFrealy, поэтому при соксификации генерируется ошибка. Исправлю в OnionPhone.
– код вроде вычистил на предмет утечек, внешним снифером проверил. Но пока не гарантирую, это ответственный момент, надо еще погонять в разных режимах.
– шифрование в данной версии AES, IDEA, DES, есть возможность использования GPG для согласования сеансового ключа. В реализацию я не вникал, все равно буду прикручивать свое. При работе со скрытыми сервисами Tor это не важно, т.к. Tor обеспечивает оконечное шифрование и PFS.
– набор кодеков остался из оригинальной версии: GSM, CELP, LPC и LPC10. Наверное, для связи через Tor лучшим будет LPC10. Это первый низкобитрейтный (2400 бит/с) синтезирующий кодек, анализирующий голос в описатели на этапе кодирования и затем синтезирующий голос по описателям на этапе декодирования. Т.к. алгоритм старый и малотребовательный к ресурсам, то анализ не очень аккуратный, из-за чего голос звучит крайне неественно (но достаточно разборчиво). В нашем случае это может быть плюсом, т.к эти же описатели используются для голосовой идентификации, и чем они грубее, тем хуже идентификация. Собственно, вокодер Торфона использует этот же алгоритм (LPC), но целенаправленно манипулирует описателями после анализа исходного голоса.

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

А почему не работает с 64битными

Скомпилированный бинар работает. При компиляции на 64 бит-платформе (сам не пробовал, с чужих слов) собирается, но генерирует адресные ошибки в библиотеках. Если надо, разберемся. Но не на этом этапе.

Выложи исходники на github

Выложу, конечно. Просто это первая сырая альфа, выложил тут для узкого круга. Пока попробуйте бинарник (хоть на LiveCD), прежде чем "причесывать" проект, надо хоть немного убедиться в его адекватности.

А Ваши эти '!', '$' вначале – это плохо. Там что, нет возможности определить, ip addr/или доменное имя/или у доменного имени суфикс .onion?

Онион-ссылку, конечно, можно определить по суффиксу, и инициировать соединение через Tor. Но в случае обычного домена или IP как понять, хочет ли пользователь соединиться напрямую по UDP, напрямую по ТСР или по ТСР через Tor? Конечно, можно оставить только Tor, но тогда теряется гибкость.

Как torchat сделан все видели, там в коробке маленький Tor, сразу запиливается в него, и не нужны никакие слушания на raw ip, с пробросами через router.

Моя ошибка – нельзя в описании все мешать в одну кучу, учту.
Проброс порта в роутере нужен для приема прямого соединения по домену или IP-адресу. Это не имеет никакого отношения к работе через Tor.

Т.е. программа может работать в таких режимах:

– устанавливать прямые UDP-соединения
– устанавливать прямые TCP-соединения
– устанавливать TCP-соединения через Tor (на заданный IP, домен или HS, нужен запущенный Tor)

– принимать прямые UDP-соединения (нужен проброс UDP-порта на роутере)
– принимать TCP-соединения (прямые или с Tor-exit, нужен проброс TCP-порта на роутере)
– принимать соединения через свой Tor-HS (нужен запущенный Tor c натроенным HS)

Перечисленные режимы абсолютно независимы. Например, если вы используете прямые соединения, вам вовсе не нужен Tor, а если используете соединения к HS, то не нужно пробрасывать порты на роутере.

По поводу "маленького Tor в коробке" – его уже исключили из коробки, т.к. Tor обновляется, и лучше, если пользователь сам подбросит свежую версию. Можете распаковать последний TBB и скопировать с него Tor в папку с программой. Если тяжело будет запускать отдельно, может добавить в start. Для моей программы не важно, будет ли запущен Tor в составе TBB, TorChat или отдельно – вводим в конфиге действующий SOCKS5-интерфейс и работаем.

такую же прикалюху в Tor-сети

Это очень амбициозная и объемная (хотя и реальная) задача.
По поводу видео через Tor я уже писал: надо разбивать поток на куски и передавать их через множество независимых Tor-цепочек, постоянно контролируя их латентность, отсеивая медленные и дублируя сомнительные. На приемной стороне все собирать обратно. Это потребует локальных ресурсов (что при современных процессорах не проблема), но обеспечит приемлемую латентность транспорта.
Я бы хотел заняться таким проектом, но это на порядки выше onionphone и не для одного хобби-разработчика: нужна команда и финансирование.

Придётся вероятно отдельную башню поднимать

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

Вы как разработку ведёте? Как Satoshi или как все?

А Ваши эти '!', '$' вначале – это плохо. Там что, нет возможности определить, ip addr/или доменное имя/или у доменного имени суфикс .onion?

Онион-ссылку, конечно, можно определить по суффиксу, и инициировать соединение через Tor. Но в случае обычного домена или IP как понять, хочет ли пользователь соединиться напрямую по UDP, напрямую по ТСР или по ТСР через Tor? Конечно, можно оставить только Tor, но тогда теряется гибкость.

Символы! и $ имеют в консоли особое значение

Просветите поподробнее, у меня нет особого опыта работы с консолью. Но в процессе разработки и тестирования я не заметил никакого отличия этих символов от других в процессе ввода (чтения из stdin) как в Win32-консоли, так и в Linux. Они вводятся с клавиатуры, как обычно, включаются в C-строку, ищутся strchr и т.д.

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

ПС: данные символы не используются в командной строке и т.п. Они используются как модификатор адреса дозвона при его интерактивном вводе в уже запущенной программе.

В любом случае нет проблем поменять на предложенный Вами вариант.

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

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

Есть масса всевозможных гласных и негласных стандартов кодинга, которые хорошо бы проштудировать, прежде чем за что-то браться. Даже уже не знаю, нужно ли показывать общепринято минимально правильные вещи^[link134], или лучше не стОит — пусть уж будет виден весь изначальный подход невооружённым глазом.

или лучше не стОит

Наверное, действительно не стоит, по крайней мере так будет честно.
Тогда лучше не считать этот проект GNU, а еще лучше – вовсе не считать проектом. Просто экперимент.

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

Золотые слова, и вообщем-то я и не скрываю, что привык к такому подходу. Хороший пример – китайцы. Пока отечественные разработчики философствуют на electonix.ru, соображая грандиозный проект на 10 лет вперед, китайцы делают его за ночь, открыто используя ломанный Windows XP, ломанный ARM-компилятор и слямзенные куски лицензионного кода. Отечественный разработчик нервно курит и продолжает философию, а отечественный пользователь рад реально работающему китайскому продукту.

а не для сообщества

А оно вобще нужно сообществу? Мне кажется, единственный, кто решил потестировать, имеет к сообществу весьма косвенное отношение (прошу прощения, если ошибаюсь). Код работает на нижнем уровне, написан не мной и очень давно, есть много вопросов в частности к звуковому интерфейсу в современных ОС. Я задавал эти вопросы линуксоидам, но кроме пространственных рассуждений, ничего не услышал. Осталось впечатление, что там больше условностей и традиций, чем прагматики, практицизма и реальных знаний. Надеяться не на кого, но я привык: протестирую и выкручусь сам, не в первый раз.

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

Неужто кроха лайтов так подействовала?

Не дай бог так изголодать :)

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

Нет проблем: http://torfone.org/spfr.html под Win32 и http://torfone.org/download/sf76_01a.tar.gz под Linux, использовать кодек GSM или LPC10. Именно так и тестирую сам с собой, т.к. у меня один маленький нетбук с Ubuntu+GNOME для тестов, остальные 5 компов под Win32 во всех ее вариантах.
С Торфоном пока совместимости нет.

Извините, опечатка. Собственно, это для примера писал, и не выделял как url. имелся в виду http://electronix.ru/forum/: портал инженеров-электронщиков и embedded-программистов.
Некоторые темы там тоже имеют отношение к проблемам безопасности. На вскидку: http://electronix.ru/forum/ind.....howtopic=119428&st=0^[link135]

Я, например, отнюдь не рад вездесущей «китайчатине»

И что, этот SpeakFrealy обеспечивает такую же криптозащиту, как и TorFone?

Файловая система, тогда тоже должна быть аппаратной

зачем этот Raw UDP/TCP

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

Да, под Linux именно так (и пока только так) оно и работает:
Скачиваем последний TBB^[link138], распаковываем в папку. Открываем файл \tor-browser_en-US\Data\Tor\torrc и добавляем строку:
HiddenServicePort 17447 127.0.0.1:17447
Запускаем ./start-tor-browser, дожидаемся подключения. Открываем появившийся файл \tor-browser_en-US\Data\Tor\hidden_service\hostname и копируем созданный ваш onion-адрес.

Скачиваем патченую SpeakFrealy7.6^[link130], распаковываем в отдельную папку. Запускаем ./start
Для исходящего звонка вводим onion-адрес абонента с восклицательны знаком вначале и жмем ввод. Для приема входящего звонка жмем ввод.
Для тестирования жмем ввод и слышим себя.

Если что-то не так, опишите ошибку, посоветую.

Да, под Linux именно так

а под Ubuntu Touch заработает?

Я же не ясновидец. Для того и выложил, чтобы попробовали на разных ОС.
Не заработать может только звук. Просто запустите ./start (без никакого Тора) и затем нажмите ввод, и еще раз ввод. Или услышите себя, или получите ошибку. И в том, и в другом случае отпишите. Если будет ошибка, укажите, я попробую подсказать, как поправить ситуацию.

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

тогда будет просто пропуск каждого n-ого кадра

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

Если пропускать много трафика по множеству параллельных цепочек, то анонимность будет падать

Год назад я несколько раз поднимал этот вопрос и здесь, и на TorProject, но ответа не получил. Хотя у меня с самого начала были сомнения аналогично вашим.

фиксированный набор гвард-узлов скрытого сервиса

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

Проверил – подключается без проблем.
Убедитесь в правильность установки системного времени и соответствии его часовому поясу. Обновите tor.exe, заменив файлом из последнего TBB.
А вообще такое было в последний раз во время августовской атаки, тогда в первую очередь пострадали HS. Сейчас, судя по торовскому мейл-листу, все спокойно.

человечки не зеленеют

А из Крыма проверяли? Работает?

Да готов он, но после здешнего "воспитания" не хотел выкладывать "as is". Хотя все же я сторонник доводки софта "в процессе", поэтому в течение пары дней на скорую руку соберу пре-альфу и представлю на github. Пока могу показать черновик описания^[link142] (функционал, установка, команды, подробное описание криптографии и т.п.). Могут быть грамматические ляпы: вычитать все, подогнав под принятые здесь "математические" традиции – весьма кропотливый труд, сопоставимый с самой разработкой. Критика и пожелания принимается в любом виде :)

ПС: посмотрите в описании по ссылке [3] работу, в которой представлены эксперименты с Tor VOIP по VPN-туннелю. Возможно, это облегчит решение вашей задачи альтернативными способами.

Во всяком случае sip туда не входит

Бегло просмотрел описание криптографии TOX^[link146]. Весьма скудно, но в общих чертах так: используется Бернштейновская криптобиблиотека NaCl. Асимметричное шифрование там EC25519, симметричное – вроде salsa20. В описании TOX ничего не детализируется, надо смотреть исходники. По поводу SPRNG и источников энтропии тоже ни слова (добрая традиция с ними). Пользователь идентифицируется публичным ключом (это его ИД в DHT). При установке соединения отсылается свой публичный ключ и nonce, из них и ключа плучателя с помощью DH выводится симметричный ключ. Т.е. никаких эфемеральных ключей, и, как результат, без PFS. Т.о., скорее всего, при утечке приватного ключа хотя-бы одного участника давно записанный дамп может быть дешифрован. Отрицаемость даже не обсуждается (другое дело, что скорее всего она практически и не важна для потенциальных пользователей в наших реалиях).
Не совсем понятен механизм аутентификации при первичном p2p-контакте через Tor в режиме ToT: если DHT выполняет маршрутизацию к нему (атаки на DHT пока не осуждаем), то при p2p, получается, надо знать ключ получателя заранее. Возможно, предусмотрена голосовая аутентификация (типв SAS в ZRTP), не нашел в описании.

Как рекомендация – добавить возможность использования PGP для подписи EC-ключей.

Ну, и еще один ньюанс: по видимому, ToT использует выход через Tor на обычный хост (не HS). Наверное, надо будет пробрасывать порт получателю, что не всегда возможно. Кроме того, Exit node – бутылочное горлышко по латентности и дрожанию (проверено экспериментально), соединение с HS гораздо более приемлемо для VOIP.

ПС:

пре-альфу кода OnioPhone^[link147] поместил на git, дока^[link148] на сайте (пока только En). В процессе будут комменты, так что пока для ознакомления. В течение пары дней подготовлю страничку в old-school стиле и готовые к употреблению статически линованные бинарники для Linux и Windows.

Код OnionPhone реализован на чистом С на максимально нижнем уровне и полностью статически линкуется: так мало кто сейчас делает, это скорее стиль embedded-разработки. Все, что можно было закодить самому, компактно сделано в самом коде, без внешних библиотек. Компилируется gcc (Linux) и MinGW (Windows) на 32-битных платформах. GUI пока нет, будет через control port. Также попробую сделать версию под Android (всего то надо прицепить работу с аудио на нижнем уровне, пример кода у меня есть, но надо пробовать).

Таки используются ефемеральные ключи^[link149] в Tox, но, прочитав три раза, так и не смог понять тонкостей. Буду вникать, описание во истину потрясающее.
ПС: и после этого родители запрещают мне в носу ковыряться? [Вовочка]

OnionPhone – это ребрендинг TorFone, или новый продукт?

Даже не знаю, как и назвать. По протоколу абсолютно несовместим (совсем другая криптография), т.е. разговор между ними не получится. Но все идеи и функции TorFone повторены в OnionPhone. Но в консольном исполнении и на С. Плюс добавлены новые кодеки и оптимизировано аудио под высоколатентную среду.

Tox уступает вашему продукту по безопасности

Это очень абстрактный вопрос, и объективного ответа на него нет в принципе: любые попытки на данном этапе сравнить что-то – не более чем пиар.

Программу запустил и с большим интересом потыкал. addkey упала от help, но это издержки альфа-версии. Можно будет отправить через GitHub pull-реквесты, связанные с переводом на английский (как oph01a.TeX, так и самой программы)? Вы планируете выпуск OnionPhone в виде библиотеки?

По addkey исправлю. Хелп-скрин можно посмотреть при запуске без параметров. Так же добавлю и в командную строку для oph.
Конечно, реквесты отправляйте.
Наверное, имелось в виду: перевода на русский? Там и так все на английском пока. Конечно, сделаю русскую доку и страницу на сайте. Но однозначно будут проблемы с русским чатом (терминал у меня в raw для работы с меню без lcurces). Возможно, придется опционно отключать меню для русификации чата.
Что имеется в виду под "в виде библиотеки"? Все, что возможно, и в чем есть смысл – обязательно сделаю.

Только что активно тестировали соединение между линукс и виндоус-версией. Из багов замечено:
– декодер ILBC под линукс сразу падает (ошибка сегментации), причем моя сборка работает. Буду разбираться.
– кодер OPUS под Win32 падает иногда спонтанно в течение использования (возможно, и под линукс тоже). Постараюсь найти причину.
– после креша под линукс слушающий сокет не биндится сразу. Причина понятна, но как обойти, пока не в курсе.
– в 64-битном режиме код собирается, но падает сразу после активации звука: проблема в кодеках, посмотрю, но не обещаю: портировать кодеки под 64 я не готов. С -m32 на 64-битной платформе все собирается и работает ОК.
– m32 не передается в Makefile кодека G729, поправлю (пока надо дополнительно прописать и в его мейкфайле).

В остальном результаты положительные: латентность в Tor составила всего около 500 mS, при адаптивном буфере выходим на 700-800 mS общей задержки при редких underrun, что гораздо лучше, чем в TorFone. Во общем, общаться вполне можно даже без PTT.
На прямое UDP и обратно переходим, NAT проходится для домашних роутеров. Не могу потестировать тщательнее, т.к. не найду тестера с провайдером, предоставляющим серый IP (хорошо живем).

Проверить кодеки можно без звонка: введите -RV, а затем Enter-ом включайте/отключайте звук. Кодек переключается от -С1 до -C18. Для вывода инженерной информации о состоянии буфера: -RB

Не совсем. На первой странице Темы Вам предложили некоторые исправления для английской версии сайта, я тоже решил с этим помочь.

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

Возможно, уже нашли

чистый API

И все же я не до конца понимаю разницу между UI и API.
В данном случае мне кажется оптимальным:
1. реализовать управляющий TCP или UDP порт c возможность передавать через него команды и обратно дублировать выдачу в stdout и цеплять на него GUI или внешний мессенжер (по образцу Tor и Vidalia).
2. реализовать С-функции и хедер с возможностью использовать их, включив С-код OnionPhone в свое приложение (например, в виде so). Тут видится функция отправки строки команды, а вот обратно пока не знаю, как сделать лучше ( с учетом мультиплатформенности): callback можно регистрировать, или через файл в памяти. Если есть варианты, буду благодарен.

И все же я не до конца понимаю разницу между UI и API

управляющий TCP или UDP порт c возможность передавать через него команды и обратно дублировать выдачу в stdout и цеплять на него GUI или внешний мессенжер

C -C14 разобрался: падает сборка с оптимизацией -o3. Это не столь важно сейчас, т.к. ILBC не особо настолько ресурсоемкий, -o2 вполне работает даже на Celeron 700MHz. По поводу -C16: именно, падает при переборе. В случае постоянного использования кодек устойчив, т.е. скорее всего проблема в моем wrapper (codecs.c), я там немного поизвращался с оригинальной компактной упаковкой OPUS-VBR-фреймов в общий пакет. Отладку затрудняет спонтанность бага. Стараюсь разобраться.

С addkey --help тоже разобрался, конечно: тупо strlen(NULL). Все исправлю одним заходом.

через консольный интерфейс, по типу почтового агента mutt

Если можно, вкратце опишите механизм или ткните носом в доку: бегло просмотрел вики mutt, ничего не прояснил.

UI на ncurses

ncurces я использовал в одной из первых сборок, потом отказался: слишком громоздкая штука. Решил, что проще самому перевести консоль в raw, асинхронно читать с клавиатуры и написать простую процедуру обработки ESC-последовательностей для управляющих клавиш. Получилась навигация по меню стрелками, управление PTT удержанием Tab и т.д.

Но интересуют варианты взаимодействия на нижнем уровне:

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

Через что же лучше? Порт – это понятно, и будет сделано. Неважно, будет это control port со своим протоколом, Telnet, Web (HTTP) И т.д.
Но есть много других техник взаимодействия: системные сообщения Windows, файлы в памяти Linux, перенаправить ввод-вывод и т.д. и т.п. Интересно, что используют другие, и что лучше.

А зачем демон между библиотекой и клиентами?

Изначально вопрос стоял об использовании OnionPhone как добавки к другим клиентам. Это можно сделать двумя способами: издать его в виде so (dll) и использовать API (всего-то пару функций: отправка команды и чтение рапортов), или запускать отдельно OnionPhone в качестве демона и подключаться к нему, используя UI. Речь идет об низкоуровневых вариантах UI. Навреное, TCP-порт здесь – лучшее решение.

ПС: также пробую собирать под Androind, используя NDK и SWIG. Низкоуровневое аудио взял с этого^[link152] примера (аудио – единственный платформ-специфический код). Пока все на стадии прикидок, но надежды есть.

ППС: кодер OPUS падает при слишком большом уровне PCM на входе. Особенно заметно при манипуляциях с AGC (-Q0, -Q1). Возможно, уже пофиксили в OPUS (попробую обновить), или придется что-то придумывать самому.
Пофиксил вроде, сам протупил. После более тщательного тестирования все вместе обновлю на git.

А зачем демон между библиотекой и клиентами?

Через что же лучше? Порт – это понятно, и будет сделано. Неважно, будет это control port со своим протоколом, Telnet, Web (HTTP) И т.д.
Но есть много других техник взаимодействия: системные сообщения Windows, файлы в памяти Linux, перенаправить ввод-вывод и т.д. и т.п.

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

Я совершенно согласен в Вами, и этот вариант рассматривается как предпочтительный, и, конечно, будет реализован. Но хочется максимально учесть возможные ситуации с использованием OnionPhone с другими приложениями.

но OnionPhone она зачем?

Надо же как-то ожидать входящие звонки.
Демон – наверное, самый простой способ использования. Продумываю возможность UI в виде вебинтерфейса, использующего WebSocket. Это не совсем знакомая мне отрасль, пока консультируюсь с web-программистом. Со стороны OnionPhone придется держать отдельный порт для подключения браузера и реализовать на С протокол WebSocket. Открывая подготовленный html-файл, имеем GUI и подключаемся к указанному порту, получаем возможность двухстороннего общения с запущенным OnionPhone, кроссплатформенно.

Я всё равно не понимаю, чем хуже разделяемая библиотека

точек сбоя в этой схеме мне представляется меньше

Свободу выбора UI разделяемая библиотека тоже не ограничивает

демон и UI должны всегда исполняться вместе, что эквивалентно отсутствию демона, как такового

будет у Вас демон висеть "для ожидания звонков", а как и кому он будет сигнализировать о поступлении звонка?

API в виде библиотеки нужен только для свободы в создании графических надстроек, которые для таких задач на порядок проще реализовать на Qt/GTK/ncurses, чем многослойным веб-пирогом

Гость^[link155], огромное спасибо за pull-реквесты – фиксы моего английского.

Демон и библитека могут существовать независимо.

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

создании графических надстроек, которые для таких задач на порядок проще реализовать на Qt/GTK/ncurses, чем многослойным веб-пирогом.

Вначале я тоже смотрел в сторону Qt, и на самом деле такой подход мне ближе и понятней. Но это верно для тех, кто пишет на С. Большинство кодит максимум в веб, поэтому им проще как раз то, что нам сложнее.

это крайнее переусложнение.

Оказалось, что с WebSocket ситуация похожа на ту, с которой я столкнулся год назад, прикручивая SOCKS5 клиент к Торфону. Вначале, как и положено, я искал подходящие либы и пытался с ними разобраться, но потом прочитал rfc на протокол и с удивлением обнаружил, что SOCKS5-клиент на нижнем уровне реализуется десятью строчками С-кода. Точно так же, почитав спецификацию на WebSocket^[link156], обнаружил что реализация сервера на удивление проста. Клиент (браузер) открывает TCP-соединение и отсылает handshake-пакет с текстом (это делает простой Java-скрипт в html-файле). Сервер (OnionPhone) парсит полученный текст, ищет заданный подтекст, выделяет строку после него, дописывает к ней еще фиксированную строку, считает SHA1, результат кодит в base64 и вставляет в стандартный текст ответа, отсылает его обратно клиенту.
Это и вся процедура установки соединения, займет от силы 10 строк кода сервера.
Сам обмен текстовыми строками с браузером (строка команды на OnionPhone и текстовых сообщений от него, дублирующих stdout) еще проще: к UTF-8 строке в начале сервер добавляет два байта (фиксированный тип пакета и длина в байтах) и отсылает клиенту байт-пакет через установленное TCP-соединение в любой момент времени. Клиент (браузер) делает аналогично, но дополнительно добавляет еще 4 рандомные байта маски после длины, с которыми побайтно ксорит отправляемый текст.
Это все. Причем таким образом реализуется универсальный UI, который может быть использован и небраузерным клиентом.
Преимущества: кроссплатформенный GUI-клиент может быть легко реализован на HTML+Java-script, т.е. даже начинающим разработчиком под себя, используя только текстовые команды OnionPhone из описания.
Недостатки:
– не все браузеры (особенно на андроид – штатный только с 4.4) поддерживают стандарт;
– запущенный браузер – раздражитель для параноика.

Как получить исполняемый файл из исходного кода?

Возможно, уже заметили

Когда пытаюсь в Firefox с включенным javascript перейти по ссылке localhost:8000

Тут ошибка. Вам необходимо в браузере открыть файл index.html в подпапке web папки онионфона (можно просто перетянуть его мышей на окно браузера, если у вас GUI). Откроется страничка с кнопками и др. элементами управления. Затем запускаете онионфон. На страничке жмете Connect и браузер подключается к онионфону. Мне показалось проще использовать отдельно html-файл вместо интеграции его с онионфоном.

Попробовал позвонить по адресу, который тут выложил gegel.

Рабочий там только мой TorChat, и то я включаю его нечасто. Так что надо самому поднять или тестировать с кем-то.

не могли бы вы сделать автоответчик и выложить ссылку

Попробую поднять у себя на сервере.

! Failed attempt to connect to Tor
Похоже что адрес недоступен.
но после запуска порт 11109 отсутствует. Для чего нужен этот порт?
Может ли onionphone работать самостоятельно, как описано выше

Вы сами себе ответили. Причина не в том, что онион-адрес недоступен, а в том, что Tor для онионфона недоступен.
Торчат по умолчанию использует в качестве socks5-порта в своем єкземпляре Tor порт 11109 (это задано в его конфигурационном файле torrc). Я так понимаю, вы используете отдельный Tor, поэтому у вас наверное, задан другой порт в torrc. По умолчанию Tor в составе TBB сейчас использует 9150. Поэтому подстройте Онионфон под него, изменив в файле conf.txt строку
Tor_interface=127.0.0.1:11109
на строку
Tor_interface=127.0.0.1:9150

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

прикрутить к onionphone распознаватель речи

Распознаватель – нет (за неимением такового).

Т.е. говорим естественно, а собеседник слышит робота.

Изменитель речи (вокодер) – да (уже прикручен). Активируется командой -Q3 для шепота, от -Q20 до -Q100 для робота с различной высотой, отключается -Q-3

Способы заземления onionphone и подключения его к VoIP-провайдеру.

Наверное, пока не время над этим думать, тем более что держать VOIP-PSTN шлюз я не собираюсь. Если хотите – сделаю.

Перспектива установки тор с onionphone на коммуникатор

Я так понимаю, ркчь идет о сборке под Андроид. Да, планируется, работа вместе с Orbot. Для начала соберу .so в NDK, сразу отпишу результат.

PS:

-O!iyrqp2pt7qfrw6xu.onion

Восклицательный знак вначале не нужен (это использовалось в SpeakFreely и тут озвучивалась критика. Я сделал так, как рекомендовали).
Суффикс .onion также не обязателен. Т.е. так:
-Oiyrqp2pt7qfrw6xu

Причина не в том, что онион-адрес недоступен, а в том, что Tor для онионфона недоступен

Изменитель речи (вокодер) – да (уже прикручен). Активируется командой -Q3 для шепота, от -Q20 до -Q100 для робота с различной высотой, отключается -Q-3

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

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

"! Hidden Service unavaliable"
отсутствие онионфона на удалённой стороне

Да, именно так. Причем сам HS может быть задан в вашем Tor, но онионфон не запущен (нет слушающего порта). Разделить эти ситуации не представляется возможным.

онионфон блокирует доступ к аудио устройству
Error opening PCM device plughw:0,0

Да, есть такое. Я использовал модуль alsa на самом нижнем уровне, открываемое устройство plughw не расшаривается. Но в файле audiocfg в строчках 2 и 3 можно указать другое устройство соответственно ввода и вывода аудио, в т.ч. и расшариваемые (например, интерфейсы, представляемые pulse audio). К сожалению, я недостаточно фамилярен с линукс и даже не могу конкретно подсказать, как вывести список имеющихся в системе устройств, и их свойства. Если получится расшарить, сообщите.
Что касается виндоус, то в ней я вывожу список на старте, и по умолчанию используется расшариваемое устройство 0: программа переназначения звуков. Выбрать другое устройства из списка можно, указав в том же файле audiocfg в строчках 2 и 3 перед двоеточием нужные номера в списке.

При использовании искажений речи остаётся ли возможность идентифицировать говорящего?

Об этом писалось многократно: да, остается. Возможность идентификации определяется объемом доступного образца-оригинала, измененного голоса и допустимой вероятностью ошибки (альтернативной гипотезы). Используется, например, скрытая модель Маркова. Если развивать мысль, то стилометрия – частный случай голосовой идентификации полностью биометрически обезличенного голоса (Speech-to-Text-to-Speech).

если после -O указать не адрес скрытого сервиса, а реальное имя или IP-адрес

Да, верно. Опция -O заставляет онионфон соединиться с Tor и через SOCKS5 в неизменном виде передает ему строку после -O в качестве адреса назначения. Никакого ресолвинга доменного имени прямо не производится.

Есть ли в этом случае дублирование потоков по разным цепочкам
Ведь приёмник не сможет создать обратный канал, т.к. инициатор не имеет своего IP-адреса.

Нет, дублирования нет (хотя теоретически возможно). Для установки встречного соединения используется немного другой механизм. Алиса подключается к Бобу через Tor, устанавливает шифрованное соединение и затем передает Бобу свой адрес. Боб пытается соединиться с указанным адресом, при этом выполняется дополнительная аутентификация (подобно TorChat). Причем Боб устанавливает встречное соединение только в случае, если входящее соединение пришло с HS (с 127.0.0.1). Я намеренно ввел эту проверку для безопасности: даже в случае HS-HS безопасность встречных цепочек спорна, не говоря уже о наличии открытых участков, по которых идут совершенно одинаковые пакеты (дубли) на обоих концах. Как верно заметил ZAS, по уму надо бы использовать для этого разные ключи и паддинг, но пока что вот так.
Но не пойму смысла в использовании соединения Tor-Inet вместо Tor-HS. Сначала я думал, что латентность будет меньше (цепочка короче), но практика показала обратное. Соединение к HS существенно качественнее (наверное, Exit-ы подводят).

PS: согласно с озвученным ранее планом переписал протокол IKE и оптимизировал загрузку процессора. Сейчас тестирую, чтобы опять не выдать глючную сборку. Кстати, текущая статически линкованная версия имеет ошибки в кодеках AMR (валится на выходе) и OPUS (на старте), внесенные другим коммитером в процессе оптимизации кода. На github давно пофиксино. Бинарники на днях (после теста) заменю на новые уже V02a вместе с документацией (не совместима по IKE, все криптографические подробности внесенных изменений и их обоснования будут в релизе): добавлена wPFS к защите ИД инициатора, исключена возможность зондирования на предмет наличия контактов в записной книге, добавлена защита от тайминг-атаки и т.д.

aplay -l
arecord -l

Похоже что знак комментария # в этих строках 2 и 3 не работает.

Знак работает, но для упрощения я жестко привязал параметр к номеру строки (ничего не бывает так постоянно, как временные меры). Поэтому в случае, если строки 2 и 3 (считая с первой) закомментировать, то используется plughw по умолчанию, не зависимо от дальнейших параметров.

В опции TCP_interface указывать порт, отличный от 17447, бесполезно.

Честно, я не проводил таких экспериментов на одной машине: у меня достаточно недорогих компьютеров с разными ОС для таких целей. Но по вашему описанию не смог понять, сколько экземпляров Tor у Вас запущено и сколько HS поднято. В принципе, можно запустить один Tor, но HS в любом случае должно быть два, и они должны быть на разных портах (например, 17447 и 17448). Ну, и в conf.txt обоих онионфонов должны быть прописаны соответствующие порты TCP-слушателей.
Что касается звука, то не могу сказать причину, но точно знаю, что статически линкованный бинар работает на x86_64, и что собирается корректно на этой платформе в gcc в режиме 32.
Уточните, работает ли тест звука (без соединения) на онионфоне? Если да, то с кодеками все ОК. Попробуйте также lpc10 или celp выбрать: с ними точно все ОК было.

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

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

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

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

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

Я собираю 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 платформе.

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, нужен 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

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

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

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

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

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

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

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

ОК, напишу.

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

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

и пишет в фс

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