ПС: нашел таки протокол git.jami.net/savoirfairelinux/ring-project/wikis/technical/Protocol
Использует DTLS, аутентификация осуществляется RSA-4096 ключом (собственно, аккаунт). Для шифрования медиа используется SRTP, ключ согласуется посредством SDES под DTLS. В принципе, все доказуемо стойко. Нет отрицаемости, но это на сегодня не самое актуальное свойство. Хуже, что нет защиты ID: злоумышленник может собирать информацию о звонках, привязанную к приватному ключу, особенно, с учетом Sybil attack.
Но это проблема не только jami, почти все ею страдают в той или иной степени.
В Торфоне я, по крайней мере, старался ее решать использованием протокола с нулевым разглашением. И надо еще учитывать и практическую сторону: в реальных условиях злоумышленник, собирая статистику, будет скорее привязываться к IP пользователей, чем к их приватным ключам.
Я имел ввиду вариации Sybil attack. При незначительном количестве пользователей злоумышленник легко может контролировать сеть, извлекая метаданные так же эффективно, как и в случае контроля центрального сервера. С ростом количества участников делать это сложнее.
В современных коммуникаторах оконечное шифрование само собой разумеется, и на первый план выходят другие требования, определяемые свойствами протокола: PFS, отрицаемость, защита ID, KCI и UKS — устойчивость и т.п. В этом плане хорошими примерами являются протоколы Axolotl («трещетка» с окном компромисса в Signal, WhatsApp) и новые разработки OTR (с использованием ring signatures на билинейном спаривании). MTPproto (Telegram) и Tox собраны «на коленке» и, хоть и практически безопасны, имеют теоретические изъяны.
Так что пока jami не предоставит формализованное описание протокола, говорить вообщем то не о чем. Особенно глядя на их гламурный сайт: там только лишь не хватает фраз «military grade encryption» и «AES-256» для полного счастья…
Хм, я впервые слышу об этом проекте. При беглом знакомстве напоминает Tox (p2p через DHT) плюс SIP-клиент. Последний функционал потребует SIP-сервер (например, поднять свой Asterisk на белом IP).
DHT — это здорово, но я вижу тут другую проблему: количество участников должно быть достаточно большим, чтобы обеспечить безопасность системы. Но на старте проекта при недостаточной популярности, естественно, участников мало, и это весьма ограничивает развитие. Т.е. получается замкнутый круг.
И, кстати, я не увидел внятного описания криптографии. Ее нет вообще, или я не нашел в их Вики? Подскажите ссылку, если она есть.
Что касается оффлайн-состояния, то это проблема мессенжеров, но никак не звонилок: разговаривать с отключенным абонентом невозможно априори. Многие месенжеры решают проблему по разному, но это отдельная тема, и тут другие модели угроз. Я просто отказался от чата в Торфоне — нет чата, нет и проблем.
Симплексная рация имеет кнопку «Передача», и это «дисциплинирует» участников. В дуплексных высоколатентных системах участник, задавая вопрос, ожидает ответ, и, не дождавшись, начинает опять говорить в то время, когда ответ как раз доходит. Просто к этому нужно привыкнуть (другой пример — прямое спутниковое включение журналистов ТВ и их диалог со студией).
Полностью с Вами согласен, код писался в течение месяца, поэтому однозначно сыроват. Четкое разделение на модули — основная цель реализации, процентов на 99 выдержана (кроме пары вызовов инициализации пути из main). Что касается вызовов foo(char *data), то сделано это с целью получить интерфейс, адаптированный к использованию UART микроконтроллера в режиме DMA. Конечно, по всем канонам это небезопасно, но в данном случае используются глобальные массивы фиксированного размера и фиксированные поля данных строго в пределах этих массивов. Понятно, смотрится это не очень красиво, тем более для библиотеки. Буду рад, если предложите более изящное решение, но в первую очередь удовлетворяющее требованием к интерфейсу, модульности и переносимости.
Собственно, проект изначально делался как embedded. И, действительно, там есть кусок из WiringPI (последовательный порт в Linux). Такой код легко портировать под ОС, хотя он, конечно, будет выглядеть несколько странно. Но код в традициях ОС очень трудно портировать для работы в bare metal. Поэтому в итоге получилось универсальное решение, не привязанное к ОС.
Качество голосовой связи — понятие весьма многогранное. В данном проекте основным вызовом была задержка, вносимая Tor. И дискомфорт пользования Торфоном определялся именно эти фактором. Но человек может адаптироваться к задержке существенно выше рекомендованных 400 мсек. Именно это имелось в виду в плане постепенного «привыкания» пользователя к высоколатентным каналам голосовой связи.
Несколько дней назад тестировал в Free WiFi на Киевском вокзале в Москве. WhatsApp и Viber не работают голосом, прямое TCP соединение блокируется на порт по умолчанию 4444, но успешно на 8080, соединение через Tor работает везде. Tor заблокировать не так просто, судя по опыту Китая и Ирана.
Для GPRS (2G) задержка составляет около 0.8 сек, для WCDMA (3G) менее 100 мсек. Tor вносит от 0.5 до 1.5 сек. Но важен также jitter: для его компенсации необходим буфер, вносящий дополнительную задержку. В Торфоне этот буфер в широких пределах адаптируется к каналу, и алгоритм различен для звонка через Tor, TCP-звонка на IP-адрес и UDP-соединения после прохода NAT. Что касается различия между Wave API и Direct Sound, то оно ничтожно в сравнении с задержками в GPRS и, тем более, в Tor. Wave API было выбрано из-за лучшей совместимости (текущая Windows-версия работает от Win98 до Win 10).
Да, согласен. Это, наверное, оптимальный вариант, хотя и громоздкий. Возможно, в итоге так и будет, но пока что все на этапе альфа-тестирования самой библиотеки, поэтому UI временно лепил на скорую руку.
Ставить кодек 1600bps в VOIP нет смысла, это для других применений.
А по поводу p2p шифрованных звонков в плохих каналах: я таки доделал свой Torfone c GUI (на сегодня есть Linux X86, Linux ARM, Windows и Android, планируется iOS и bare metal: Tor и транспорт — на одноплатнике, крипто, аудио и GUI — изолированно через UART на STM32 ). Можно звонить на онион-адрес через Tor, при желании покидать Tor и переходить на p2p через проход NAT (шифрование остается) или же непосредственно звонить на IP:port (в т.ч. в локалке без интернет). Использует кодек AMR4750, шумодав NPP7 от MELPE, VAD, эхоподавление от WebRTC, звук по качеству — как в мобильном. Собственных серверов и регистрации нет: RSA-ключ для скрытого сервиса Tor и X25519 ключ для собственного шифрослоя генерируются при первом старте. Ну, и полная обфускация для работы вне Tor (если его все ж заблокируют): коннект в две сесии, Elligator2, Zero knowledge IKE с защитой ID, голос по TCP (не RTP): вообщем, на чужих ошибках готов потягаться с DPI.
Если интересно, скину ссылку на apk, чтобы оценить возможности и латентность в Tor (она весьма приемлема за счет всяких фирменных трюков). Полностью открытый код для всех платформ будет чуть позже (команды у меня нет, все делаю сам).
Может, статью на Хабр написать? Но не знаю, есть ли у меня карма.
Звучит вполне неплохо для 1600 bps. Интересно попробовать использовать MELP вместо CODEC2 (при всем уважении к Дэвиду), но ребята не хотят связываться с лицензированным кодеком. Жду снижения битрейта до 800bps, чтобы использовать в своем шифраторе голоса (открытый вариант JackPair). Сейчас там MELPE-1200 и запущен на Cortex M4 180 MHz realtime: звучит терпимо, но далеко не супер.
Использует DTLS, аутентификация осуществляется RSA-4096 ключом (собственно, аккаунт). Для шифрования медиа используется SRTP, ключ согласуется посредством SDES под DTLS.
В принципе, все доказуемо стойко. Нет отрицаемости, но это на сегодня не самое актуальное свойство. Хуже, что нет защиты ID: злоумышленник может собирать информацию о звонках, привязанную к приватному ключу, особенно, с учетом Sybil attack.
Но это проблема не только jami, почти все ею страдают в той или иной степени.
В Торфоне я, по крайней мере, старался ее решать использованием протокола с нулевым разглашением. И надо еще учитывать и практическую сторону: в реальных условиях злоумышленник, собирая статистику, будет скорее привязываться к IP пользователей, чем к их приватным ключам.
В современных коммуникаторах оконечное шифрование само собой разумеется, и на первый план выходят другие требования, определяемые свойствами протокола: PFS, отрицаемость, защита ID, KCI и UKS — устойчивость и т.п. В этом плане хорошими примерами являются протоколы Axolotl («трещетка» с окном компромисса в Signal, WhatsApp) и новые разработки OTR (с использованием ring signatures на билинейном спаривании). MTPproto (Telegram) и Tox собраны «на коленке» и, хоть и практически безопасны, имеют теоретические изъяны.
Так что пока jami не предоставит формализованное описание протокола, говорить вообщем то не о чем. Особенно глядя на их гламурный сайт: там только лишь не хватает фраз «military grade encryption» и «AES-256» для полного счастья…
DHT — это здорово, но я вижу тут другую проблему: количество участников должно быть достаточно большим, чтобы обеспечить безопасность системы. Но на старте проекта при недостаточной популярности, естественно, участников мало, и это весьма ограничивает развитие. Т.е. получается замкнутый круг.
И, кстати, я не увидел внятного описания криптографии. Ее нет вообще, или я не нашел в их Вики? Подскажите ссылку, если она есть.
Что касается оффлайн-состояния, то это проблема мессенжеров, но никак не звонилок: разговаривать с отключенным абонентом невозможно априори. Многие месенжеры решают проблему по разному, но это отдельная тема, и тут другие модели угроз. Я просто отказался от чата в Торфоне — нет чата, нет и проблем.
А по поводу p2p шифрованных звонков в плохих каналах: я таки доделал свой Torfone c GUI (на сегодня есть Linux X86, Linux ARM, Windows и Android, планируется iOS и bare metal: Tor и транспорт — на одноплатнике, крипто, аудио и GUI — изолированно через UART на STM32 ). Можно звонить на онион-адрес через Tor, при желании покидать Tor и переходить на p2p через проход NAT (шифрование остается) или же непосредственно звонить на IP:port (в т.ч. в локалке без интернет). Использует кодек AMR4750, шумодав NPP7 от MELPE, VAD, эхоподавление от WebRTC, звук по качеству — как в мобильном. Собственных серверов и регистрации нет: RSA-ключ для скрытого сервиса Tor и X25519 ключ для собственного шифрослоя генерируются при первом старте. Ну, и полная обфускация для работы вне Tor (если его все ж заблокируют): коннект в две сесии, Elligator2, Zero knowledge IKE с защитой ID, голос по TCP (не RTP): вообщем, на чужих ошибках готов потягаться с DPI.
Если интересно, скину ссылку на apk, чтобы оценить возможности и латентность в Tor (она весьма приемлема за счет всяких фирменных трюков). Полностью открытый код для всех платформ будет чуть позже (команды у меня нет, все делаю сам).
Может, статью на Хабр написать? Но не знаю, есть ли у меня карма.