Анонс идеи аппаратного скремблера

Параллельно работе над Linux OnionPhone по просьбе трудящихся хочу взяться за разработку аппаратного решения для шифрованной телефонии через обычные акустические каналы со стандартной полосой 300-3000Гц (наземные телефоны, УКВ и КВ, в т.ч. SSB радиоканалы и, возможно, GSM/CDMA). Идея заключается в портировании открытого софта в подходящий DSP: низкобитрейтный кодек, софтверный модем и криптографию. Аппаратно потребуются: DSP (микроконтроллер) с АЦП/ЦАП (ШИМ) стандартной разрядности, производительностью не ниже 50 MIPS и со значительным объемом ПЗУ для кодовой книги аудиокодека, монохромный графический дисплей, подключаемый по трехпроводному SPI-интерфейсу (например, от Nokia 3310) для отображения результатов аутентификации, микроSD для хранения адресной книги (публичных ключей контактов), смарт-карта стандарта ISO7816 (например, GoldWaffer на PIC16F84+24LC16, ранее популярная для клонов сим-карт и карт платного спутникового телевидения) для хранения приватного ключа и возведения в его степень по модулю, и, возможно, внешнее ОЗУ.
В качестве голосового кодека думаю использовать или свободный Codec2, или лицензированный MELPe (стандарт NATO STANAG-4591) на битрейте 1200bps с подавителем шума NPP7, специально адаптированным для условий боя. В качестве модема – FDMDV из проекта Codec2, обеспечивающий битрейт 1450bps, быструю синхронизацию и восстановления после ошибок, устойчивый к частотным и временным сдвигам.
Хочу более подробно озвучить свои соображения по поводу криптографии: не с целью получить експертную оценку и потом ссылаться на форум, но чтобы как минимум исключить явные ляпы и, возможно, услышать конкретные советы по улучшению. Я старался не использовать совсем уж Bleeding edge, хотя все же предпочел Modern. Естественно, данный проект является исключительно образовательным (например, как основа для дипломной работы), так как шифрование гражданской радиосвязи в большинстве стран запрещено.

Задача.
В групповом попарном радиочате выполнять отбор сообщений для себя и их потоковое дешифрование с быстрой синхронизацией после потерь неизвестного количества байт. Индивидуальная аутентификация контаков друг перед другом должна выполняться с помощью уже имеющихся PGP-ключей, обеспечивать PFS и полную отрицаемость в отношении этих ключей, содержимого энергонезависимой памяти (в случае захвата устройства), а также между сеансами связи.
На первом этапе хочу сделать софтварную реализацию под Linux для i386 без использования FPU, приведенное описание протокола сделано под нее.
Планирую использовать ECDH на Бернштейновкой кривой 25519, хеширование Keccak, потоковое шифрование и PRNG с использованием Keccak Duplexing Sponge, для сидирования PRNG использовать HAVEGE (а в аппаратной реализации – RNG на шуме перехода стабилитрона).

Общее описание протокола.
При первичном включении генерируется индивидуальная долговременная ECDH-ключевая пара Aa, приватный ключ a сохраняется на диске (предполагается, что программа будет запускаться с TrueCrypt-контейнера). Публичный ECDH-ключ A (256 бит) дополняется пользовательской информацией I (256 бит) и подписывается с помощью PGP. В качестве публичного ключа используется:
PubKeyA = A | I | PGPSig{A | I}
Для идентификации используется отпечаток ключа в виде его 128-битного хеша:
IDA=H(PubKeyA)
Включение подписи в хеш блокирует UKS, характерную, например, для ранних версий OTR.
При появлении на радиоканале абоненты периодически, используя промежутки радиообмена, публикуют свои ключи, сопровождая их флагом ключа и CRC32. Последняя необходима только для исключения непреднамеренных ошибок передачи и не используется в протоколе. При размере ключа в 150-200 байт публикация займет около секунды. При получении валидного ключа он автоматически добавляется в адресную книгу. Позже в ручном режиме можно просмотреть полученные ключи, удалить лишние, проверить PGP-подпись, используя PGP PKI и пометить ключи как доверенные.
Публикация ключа полностью отрицаемая, т.к. ключ может быть переопубликован кем угодно на любом канале. Наличие ключа в адресной книге также отрицаемо, т.к. ключи принимаются и сохраняются автоматически. Например, приняв ключ на канале террористов, и затем опубликовав его на канале гомосексуалистов, можно всегда утверждать, что приняли его именно там, а ЗАС пользуетесь, т.к. стесняетесь ориентации.

Установка связи.
Для установки связи между A и B необходимо, чтобы оба участника уже имели ключи друг друга. Процедура установки связи сводится к обмену всего двумя посылками: А (инициатор) посылает запрос, а B (вызываемый) отвечает подтверждением. После этого между данными абонентами устанавливается приватный сеанс, и они могут общаться друг с другом без дополнительных согласований в пределах этого сеанса (но без PFS). Для обеспечения PFS абоненты просто переустанавливают сеанс, снова обмениваясь запросом и подтверждением.

A выполняет запрос для B:
– генерирует две DH-пары: аутентификационную и ключевую (Xx и X'x' соответственно);
– подсчитывает префикс:
P AB = H( IDA | Bx),
где IDA-собственный отпечаток, B – публичный DH-ключ получателя. Префикс усекается до 32 бит из соображений снижения битрейта. Он является только идентификатором, и даже если будет совпадение (2-32), то соединение не будет установлено из-за несовпадения ключей. Префикс полностью отрицаемый, т.к. любой может сгенерировать его, используя публичные отпечаток и DH-ключ участников.
– фиксирует таймстемп T, ограничивающий время для подбора злоумышленником и предотвращающий Replay-атаку.
– транслирует запрос в виде: P AB, T, X, X'
– добавляет в список ожидающих соединение запись IDB, T, x, x'
– удаляет слишком старые безответные записи из списка по таймстемпу.

B получает запрос от A и отвечает:
B cлушает канал и, приняв посылку с флагом запроса, сверяет таймстемп, затем "примеряет" ее к каждому контакту из адресной книги:
– однократно подсчитывает Xb, где b – собственный приватный ключ.
– для каждого абонента их адресной книги
извлекает IDn и подсчитывает Pn=H(IDn | Xb)
– при совпадении с префиксом считает, что получил запрос именно для себя предположительно от абонета n, иначе запрос адресован кому-то другому.
– аналогично генерирует две DH-пары (Yy и Y'y') и подсчитывает ответный префикс:
P BA=H( IDB | Ay),
где IDB-собственный отпечаток, A – публичный DH-ключ предполагаемого отправителя.
– транслирует ответ в виде: P BA, Y, Y'
– подсчитывает мастер-ключ данного соединения:
K=X'y'
Мастер-ключ выводится с использованием исключительно DH и не содержит материала долговременных ключей и ключей аутентификации. Это необходимое условие полной отрицаемости, в отличие от "разумной" отрицаемости, которую обеспечивают протоколы с неявной аутентификацией (например, FHMQV).
– подсчитывает аутентификаторы:
M A=H( Xb | Ay | X | Y | X' | Y' )
M B=H( Xb | Ay | X | Y | Y' | X' )
Учитывая идеальность хеширования Keccak, фактически DH-параметры мастер-ключа (X' и Y') подписываются (с перестановкой местами) общим ключом аутентификации. Это в точности соответствует протоколу SKEME, но в нем ключ аутентификации выводится с использованием протокола Abadi (обмен случайными значениями, зашифрованными публичными ключами участников), а в данном случае – с использованием протокла KEA+ (по смыслу то же, но с использованием DH-публичных ключей). SKEME обеспечивает полную отрицаемость и является доказуемо стойкой (по Кравчику). KEA+ также удовлетворяет требованиям отрицаемости, т.к. не использует непосредственой комбинации ключей A и B вне хеширования.
– инициализируется 32-битный счетчик-вектор для шифрования: С=0
– добавляет запись в список открытых соединений: IDA, T, С, K, M A, M B

A получает подтверждение от B:
А слушает канал, и приняв посылку с флагом ответа, аналогично "примеряет" ее к каждому контакту из адресной книги:
– однократно подсчитывает Ya, где a – собственный приватный ключ.
– для каждого абонента их адресной клиги извлекает IDn и подсчитывает
Pn=H(IDn | Ya)
– при совпадении с префиксом считает, что получил ответ именно для себя предположительно от абонета n, иначе ответ адресован кому-то другому.
– находит соответствующую запись в списке ожидающих соединение контактов и сверяет таймстемп получения ответа с таймстемпом отправки запроса, игнорируя ответ при слишком длинном интервале.
– подсчитывает мастер-ключ данного соединения:
K=Y'x'
– подсчитывает аутентификаторы:
M A=H( Xb | Ay | X | Y | X' | Y' )
M B=H( Xb | Ay | X | Y | Y' | X' )
– инициализируется 32-битный счетчик-вектор для шифрования С=0
– добавляет запись в список открытых соединений: IDA, T, C, K, M A, M B
– удаляет запись из списка ожидающих соединение

На данном этапе ни А, ни B пока не могут быть уверены ни в идентичности друг друга, ни в отсутствии MitM, т.к. они еще не обменялись аутентификаторами. Тем не менее они имеют общий мастер-ключ и могут начинать общение. Это исключает прерывание протокола при неудачной аутентификации, что необходимо для полной отрицаемости. Уведомление об аутентичности контакта будет скрытно выдано абоненту при приеме первой же голосовой посылки (любая передача теперь будет начинаться с аутентификатора). Также контролируется интервал времени по таймстемпу от начала протокола до получения первого аутентификатора, в случае слишком длинного интервала достоверность аутентификации снижается (т.к. злоумышленник имел время для вычислений).
Аутентификаторы также усекаются до 26 байт (этого требует низкий битрейт канала). Я старался внимательно проанализировать возможность использования коротких аутентификаторов и прише к выводу, что это допустимо в данной приложении, хотя буду рад услышать другие обоснованные мнения на этот счет и идеи.
При приеме данных с флагом голосового сообщения получатель ищет подходящий аутентификатор в списке открытых соединений. Если он там отсутствует, получатель считает, что сообщение адресовано не ему. Если аутентификатор обнаружен, и он не соответствует последнему контакту, то выводится сообщение о новом контакте в виде контактной информации из публичного ключа контакта и степени доверия, установленной ранее вручную в результате проверки PGP-подписи.
Вместе с аутентификатором в начале каждой передачи, а также с полусекундным интервалом на протяжении передачи, транслируется счетчик С (его младшие 26 бит). При приеме счетчика С его значение восстанавливается до полных 32 бит (только вперед!) и последовательность T | C | K используется для инициализации Keccak Duplexing Sponge. При получении последующих данных выжимается гамма, использующаяся для расшифровки потока. Т.к. транспорт не обеспечивает коррекцию ошибок по соображениям снижения битрейта и минимизации задержки, то регулярная реинициализация с полусекундным интервалом позволяет восстанавливать корректность расшифровки при потерях данных в случае длительной непрерывной передачи.
Также из соображений снижения битрейта и устойчивости связи аутентификация принятых данных не производится. Шнаер допускает такой подход при передаче голоса, т.к. голос сам по себе является достаточным аутентификатором. Такой же подход используется и в PGPFone Циммерманна. Голосовой кодек MELPe является военным стандартом и его рефференс-код тщательно проверен на предмет выполнения произвольного кода при подаче на вход фатальных битовых последовательностей. Любая манипуляция входными битами без знания ключа шифрования может вызвать лишь искажение голоса вплоть до получения шума, но не нарушение криптографии в целом. Преимущество данного подхода очевидно: спонтанное искажение единичных битов приведет лишь к искажению голоса, но не к полному выпадению неаутентифицированных блоков.



Комментарии
— SATtva (25/06/2014 09:30)   
фиксирует таймстемп T, ограничивающий время для подбора злоумышленником и предотвращающий Replay-атаку.

B cлушает канал и, приняв посылку с флагом запроса, сверяет таймстемп

То есть предполагаются синхронные часы? Не слишком ли непрактичное требование?
— gegel (25/06/2014 10:21)   
Не особо синхронные – предполагался допуск минутной погрешности.
Хотя, конечно, в аппаратной реализации это не совсем практично, да.
Собственно, таймстемп нужен исключительно для ограничения времени выполнения протокола для усеченных айтентификаторов. Но, как мне намекнули, это неэффективный костыль: хотя-бы в начале надо передать полный (128 бит) аутентификатор. В таком случае синхронизированный таймстемп можно смело выбрасывать, а для удаления зависших в ожидании соединений использовать счетчик тактов с момента включения устройства.
— unknown (25/06/2014 10:35, исправлен 25/06/2014 11:03)   

А, так вы всё-таки прослушиваете мои интернет-коммуникации! Буквально вчера искал документы такого плана.


Начал интересоваться возможностью создания скрытых каналов в WiFi. По типу стего поверх обычного WiFi-соединения между двумя подставными узлами (чтобы кто-то в стороне получал сообщение путём пассивного перехвата этого канала) или коротких импульсных односторонних связей.


Сначала нашёл это[link1] и это[link2]. Но показалось слишком примитивно.


Затем наткнулся на ULTRA WIDEBAND DATA CHANNELS FOR SPECIAL OPERATIONS FORCES[link3]. Откуда вышел на Millimeter-Wave Soldier-to-Soldier Communications for Covert Battlefield Operations[link4].


И дошёл до: Radio Communications in the digital Age[link5], откуда заинтересовался STANAG и низкобитрейтным MELPe. Там, ближе к концу, после разъяснения азов, интересная информация


Начал думать, как это всё можно скомпоновать вместе и понавесить крипто. А тут вы со своей темой :)

— unknown (25/06/2014 17:05, исправлен 25/06/2014 17:58)   

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


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


Т.е., вместо PAB = H(IDA ║ Bx) считать PAB = H(IDA ║ T ║ Bx) и передавать запрос внешне по старому PAB, T, X, X', но с учётом зависимости PAB от T. И в других шагах протокола по аналогии.


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



Скрытно, это как?



Это если абоненты знают друг друга не только по ключам, но и по голосу. А если абонент B, скажет: «по этому вопросу свяжись с C, он больше владеет информацией». А с C до этого A никогда не разговаривал(а)?

Гость (25/06/2014 21:19)   
Уважаемый Gegel!

Аппаратный скремблер, это, конечно, хорошо, но каковы перспективы дальнейшего развития вашего Torfone – вот что заботит большинство пользователей!
Особенно с учетом непопулярных действий MS по Skype.
Вы посмотрите, какой переполох начался по этому поводу – https://www.linux.org.ru/news/internet/10606010, и это только на ЛОРе.
А у простого люда до сих пор нет надежного качественного открытого шифрующего Voice-мессенджера, которым можно заменить Skype.
Хотя количество их разработок достигает десятков, но все они в абсолютном своем большинстве – у.г.
Вот на что следует обратить ваше бесценное внимание и усилия!
— gegel (25/06/2014 21:33, исправлен 25/06/2014 21:42)   
А, так вы всё-таки прослушиваете мои интернет-коммуникации!

СОРМ+. Добавлен астральный модуль.
СОРМ+Pro. Активный режим: участники pgpru дружно роют в направлении, заданном тов.майором :)
А если серьезно, то тенденция к смене модели со шпионской на военную тревожная.


Использование таймштампа T вполне оправданно

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


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


Скрытно, это как?

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

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

Я понял Шнаера немного по другому: человек четко отличает голос от не-голоса. Это и есть фактор аутентификации. Т.е. вероятность, не зная ключа, изменить данные так, чтобы после дешифровки и декодирования получить голос, а не шум, причем с другой голосовой информацией, пренебрежимо мала.
Хотя, конечно, если, рассматривать вариант с фразой "Казнить нельзя помиловать", то можно внести искажения и изменить двоякий смысл. Но на практике, учитывая наличие естественных искажений телефонии, обычно критические места уточняют.


PS: если можно, поменяйте в моем первом посте в двух местах SIGMA на SKEME: думал об одном, а писал другое...


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

Доделываю консольный под Linux (но несовместим со старым по протоколу и криптографии – все оптимизировал). И сразу будет под Windows. Значительно улучшил обработку голоса (новые кодеки) и криптографию (ECDH, Keccak).

— unknown (25/06/2014 22:45)   

Поменял. Возможно, кое-какие вопросы и размышления сформулирую чуть позже.
Гость (25/06/2014 23:35)   


Можно попробовать текущую бетку? Или она сильно сыра?
— gegel (26/06/2014 02:53)   
Можно попробовать текущую бетку? Или она сильно сыра?

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

To unknown: похоже, это те же ребята, что и по первой вашей ссылке: https://github.com/lulzlabs/AirChat
— unknown (26/06/2014 12:19, исправлен 26/06/2014 12:34)   

Т.е. уже после согласования при установлении связи по шифрованному каналу передаётся от A к B значение MA, а от B к A значение MB?


Да и ещё в DH там предусмотрены проверки на навязывание плохих значений?


Ещё интересно: голос не аутентифицируется и не кодируется кодами упреждающей коррекции ошибок (FEC), это понятно. А данные запросов каким кодированием передаются в однонаправленном канале с помехами? В КВ (HF/SSB) и GSM особенно, где могут быть сильные шумы, задержки, пропуски, эхо и искажения. Или FDMDV это всё обеспечивает для данных?

— gegel (26/06/2014 23:50, исправлен 27/06/2014 00:37)   
Т.е. уже после согласования при установлении связи по шифрованному каналу передаётся от A к B значение MA, а от B к A значение MB?

После DH-согласования мастер-ключа абоненты могут обмениваться голосовыми посылками. В начале каждой посылки в открытом виде передаются MA (MB) и CTR. Аутентификаторы служат одновременно и идентификаторами отправителей: получатель просматривает список открытых соединений и, найдя аутентификатор, идентифицирует отправителя и одновременно его подлинность. Прятать аутентификаторы под шифр нет смысла, т.к. тогда понадобятся отдельные идентификаторы отправителя. Кроме того, в этом случаем мы уходим от SKEME[link6], что, скорее всего, повлияет на ее доказуемо полную отрицаемость[link7].


Тут хочу уточнить один момент: аутентификатор усекать нельзя: хотя бы однократно каждый абонет должен получить 128-битный аутентификатор другого (иначе Боб может MitM-мить, подобрав подходящий X' – Боб ведь может влиять на мастер-ключ). После обмена полными аутентификаторами можно перейти на усеченные (используя их только в качестве идентификатора отправителя). Думаю, есть смысл передать длинные аутентификаторы однократно в первых голосовых посылках. Если будет сбой передачи полного аутентификатора, соединение для кого-то из участников будет выглядеть неаутентифицированным, и он инициирует его переустановку.


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


Вообще я опишу побитную структуру фреймов чуть позже, исходя из требований кодека и возможностей FDMDV-модема[link8], прикидка уже есть. Модем обеспечивает передачу фрейма в 28 бит за 20 mS. Его достоинство (в сравнении с STANAG) – в начале посылки нет тренинг-сигнала, и плюс моментальное восстановление. 20mS звуковой фрейм содержит одну центральную несущую (для синхро) и по 7 боковых с каждой стороны, т.о. параллельно передаются 28 бит+1 синхро (фазовыми сдвигами). Один бит уходит на тип, остальные: или данные, или подтип+control. Я, гуляючи, придумал устойчивый транспортный протокол для проекта, но надо по свободному времени потестировать, хотя бы через микрофон между двумя ноутами для начала.


Да и ещё в DH там предусмотрены проверки на навязывание плохих значений?

Я не готов ответить, на сколько это актуально для EC25519. Для обычной DH публичный ключ проверяют на 0 и ±1 (в PGPFone это реализовано). Что касается ECDH, то планируется использовать C-реализацию[link9]. Бернштейн пишет[link10], что валидны любый публичные ключи (пункт Free Key Validation на стр.2). Или Вы не то имели в виду?

А данные запросов каким кодированием передаются в однонаправленном канале с помехами?

Это вопрос меня тоже волновал. Наверное, есть смысл использовать обычную CRC32, просто игнорируя ошибочные. Не знаю, какой процент ошибок (BER) реально получим в канале, но, думаю, 40 байт все же удастся передать без коррекции, если не с первого раза, то повторами (это полсекунды эфирного времени). А что касается ключа, то он тоже не такой уж длинный (скажем, те же 40 байт + PGP-сигнатура), и содержит урезанный отпечаток к качестве идентификатора, который есть хеш. Так что даже CRC32 не нужна. Публикуем периодически, рано или поздно выловится.

— unknown (27/06/2014 10:35, исправлен 27/06/2014 12:06)   

Всё строится на том, что под хэш запроса попадают случайные параметры DH. Поэтому посторонняя сторона (Ева), даже зная открытые ключи, по записи данных не может определить, кто с кем связывается — если речь речь идёт про радио (некоммутируемую среду распространения сигнала). И это хорошо :)


Но допустим, она определила это по косвенным признакам (пеленговала, номера GSM прослушивала). Затем, Ева от своего имени связывается с Бобом и прерывает сеанс после прохождения всех шагов («извините, не на тот номер попала»).


Также она может соединиться и с Алисой.


Затем, она знает, что настоящий Боб по каким-то причинам ответить не может. И знает, что в данный момент его вызывает Алиса. Сможет ли Ева выдать себя за Боба, подсунув Xb и Ay, записанные от предыдущих сеансов связи с настоящими Алисой и Бобом? Или хотя бы навязать известный ей K, пусть даже не пройдя аутентификацию? Или как-то вклиниться посредине? Хотя, вроде нет — аутентификаторы M не совпадут.



В то время как всё прогрессивное человечество использует MFSK[link11] для данных.


А совсем прогрессивное — 4QAM[link12] как раз под вашу задачу.


Data transmission over voice dedicated channels using digital modulations[link13]:


Abstract. The mobile phone networks use medium rate voice coders. These coders use a destructive compression based on speech specific characteristics. Therefore, any other signal than voice could be highly damaged. In this paper we discuss the technical reasons of this degradation by exposing the principle algorithms used in speech coders, and the features and the effect of Voice Activity Detectors (VAD). We propose a flexible approach allowing data transmission up to 3 kbps with a binary error rate (BER) lower than 3.10-3. Such a bit rate makes it possible to transmit ciphered speech. This approach is based on using digital modulation and optimizing their parameters, in order to obtain a modulated signal that shows the better resistance to the speech coder and robustness to the VAD. The considered modulations are QAM and FSK. We evaluate and compare their performances for transmission through a medium rate speech coder.

Digital modulations can handle data transmission through an EFR speech coder at considerable binary rates. With 4QAM, we can reach 3 kbps while maintaining a BER lower than 3.10-3. The advantage of using digital modulations is the simplicity of the demodulation, which doesn’t require complex computations as in [3, 4]. Thus, it remains to add some error correcting code, and a channel equalizer in order to improve the BER and increase the achievable bit rate. The performances offer the possibility of tunneling real time speech conversations through speech-dedicated channels, like GSM voice channel, in order to establish a secure communication. In this case, the tunneled speech is coded at low bit rates, typically by a MELP 2.4 kbps. Then the binary coded parameters are modulated, and the modulated signal is transmitted through the channel, across one or more speech coders.

Т.е., можно упаковать всё в 4QAM и слать и свои данные, и кодированно-шифрованную речь по узким каналам с помехами и внешними кодеками, хоть по GSM, хоть по КВ/УКВ.

— gegel (27/06/2014 12:15, исправлен 27/06/2014 12:18)   
И знает, что в данный момент его вызывает Алиса. Сможет ли Ева выдать себя за Боба

По описанию – классическая попытка MitM. Предлагаемый протокол – не мой велосипед, все же это доказанный SKEME[link6]. Как я уже писал, в классической SKEME общий ключ, которым стороны подписывают параметры (с перестановкой) выводится с помощью протокола Abadi[link14], у меня – с помощью KEA+[link15] (исключительно для удобства работы с ECDH вместо, скажем RSA). Правда, для KEA+ показана wPFS-атака[link16] в eCK-модели, но, мне кажется, в данном приложении это не суть важно, т.к. выводимый с помощью KEA+ ключ используется лишь для подписи других DH-параметров, и "мастер-ключевая" чистая DH сама по себе уже обеспечивает PFS. Даже утечка общего ключа подписывания после завершения протокола ничего не даст злоумышленнику, т.к. в любой новой сесии (в т.ч. параллельной) честной стороной всегда будут использованы новые DH-параметры.
Но это мы опять вступаем в высокие сферы доказательств, я зимними вечерами их столько перелопатил, что уже аллергия – проще использовать общеизвестные доказанные протоколы, что я и пытался сделать в проекте.


В то время как всё прогрессивное человечество использует MFSK.

Как раз вчера тоже был по этой ссылке :) Еще подробнее тут[link17].
Программа open-source, можно даже скачать и потестировать все варианты. Большинство работает ниже уровня шума (маскировка!). Есть прикольные решения, например Hellschreiber, передающий в чат вместо кодов символов их графические сканы (человек сам корректирует искажения графического образа). Но они все слишком низкобитрейтные (для чата), для голоса не подходят. Да и исходный код MELPe-600 жутко проприетарный, мне так и не удалось достать. С больши трудом нашел MELPe-1200 (для Торфона), так что от этого и исходим. Как вариант, можно использовать для голоса FDMDV, а для чувствительных данных – MFSK, но это будет еще тот гемморой: определять еще и тип модуляции на фоне шумов. Как ни крути, а проще короткие, но важные данные защищать контрольной суммой и дублировать в случае ошибки, чем городить для них отдельную низкобитрейтную, но надежную инфраструктуру с FEC.
Другое дело, если дополнительно планируется обмен пользовательскими данными (например, картинками или документами). Мой проект этого не предполагает, и это значительно упрощает ситуацию. Но если это для Вас важно, то посмотрите проект Анонимусов по моей ссылке в посте выше – там используется как раз FLDIGI со всеми ее модемами. В их демо-видеоролике, ближе к концу, при демонстрации поиска в Твиттере ищут по ключевому слову Ukraine, прикольно.


PS:

А совсем прогрессивное — www4QAM как раз под вашу задачу.

Сейчас гляну.

— unknown (27/06/2014 12:46, исправлен 27/06/2014 12:52)   

Гляньте ещё на End-to-End Voice Encryption over GSM – Defcon[link18].


Я так понимаю, что в голосовых цифровых сетях с вредными кодеками (GSM) данные лучше передавать в 4QAM (туда же и паковать шифрованный кодек для голоса), а небольшие объёмы данных на (ультра)коротких волнах — в MFSK-посылках. И посылка вызова будет слышна на слух.


Совсем извратный вариант: для КВ — в FMDV-модем положить данные в 4QAM в перерыве между голосом; а для GSM — обернуть всё в 4QAM.

— gegel (27/06/2014 14:49)   
Дело в том, что каждый из вариантов (КВ, УКВ, GSM, WiFi-вставики) имеют свои особенности, поэтому пытаться делать универсальное решение только хуже. Например, в КВ это замирания, доплер при движении отражающего слоя в ионосфере, эхо от многократных отражений и даже повторы после втогого огибания земли. Плюс неточная настройка SSB (неизвестный частотный сдвиг). Где-то в этом блоге[link19] я встречал ссылку на документ с рекомендациями по эмуляции различных каналов, сейчас не найду.
Но в любом случае – это целые исследования, которые, к тому же активно продолжаются. Я не рискну взяться за разработку собственных решений в этой области, нет достаточного опыта. Пока поиграюсь с FMDV, а там посмотрим по результатам.
Кстати, тут[link20] блог по тестированию FMDV радиолюбителями на КВ, а тут[link21] – их проект в железе (аналогично, но без криптографии, конечно).
— unknown (27/06/2014 14:59, исправлен 27/06/2014 15:06)   

Для КВ есть программа Pathsim[link22]. Только под винду. И возможно, какие-то аналоги. CoCoaPath[link23] — под MAC. Под Linux ничего нет.



Rowetel уже читал.


Готовых тестов для режимов данных на КВ тоже хватает[link24].



Может прямо внутрь FMDV вставлять данные запросов в режиме 4QAM, а сам FMDV считать оптимально проходящим через все каналы?

— gegel (27/06/2014 15:29, исправлен 27/06/2014 15:40)   
Может прямо внутрь FMDV вставлять данные запросов в режиме 4QAM, а сам FMDV считать оптимально проходящим через все каналы?

Такая идея возникала, но это, наверное, еще больший геморрой в реализации, чем просто добавить FEC к FMDV или же даже чем чередовать FMDV и 4QAM (в последнем случае можно одновременно декодить и то, и другое, и далее методом исключения: если устойчивый 4QAM валидет, то, понятно, не голос в FMDV.
Ваша ссылка на GSM-modem просто супер, я давно думал над этим, и где-то так и предполагал решение. Дело в том, что скорее всего, FMDV через GSM не пройдет: GSM-кодеки (06.10-full rate, 06.20-half rate и 06.60 enhanced full rate) все же LPC, они ищет описатели именно голоса в специальных статичтически наработанных кодовых таблицах с учетом особенностей голосового тракта именно человек. В своей Linux-версии SpeakFrealy, которую я выкладывал пару месяцев назад, сигнал вызова (трель звонка) проигрывается не получателем, а отправляется отправителем, сжимаясь текущим кодеком. После декодирования даже на слух – не узнать, хотя речь разборчива.
Я по свободному времени попробую пропустить FMDV через все GSM-кодеки (все это уже есть в исходниках OnoinPhone и отлажено), но, боюсь, результат будет плачевный.
Решение, предложенное по ссылке (слайд 47), очевидно: подстроить модем под кодек, использовать его же таблицы так, чтобы модем генерировал для кодека понятные ему и обрабатываемые звуки (псевдо-речь).
Это новое решение, и, боюсь, кроме слайдов, в паблике не удастся найти даже спецификаций, не говоря об рабочем прототипе и исходниках – уж слишком это в пику большому брату. Разработать такое самому вряд ли под силу, во всяком случае у меня нет такого опыта и достаточно хорошего понимания LPC и особенностей его реализации в отдельных кодеках.

— unknown (27/06/2014 15:42, исправлен 27/06/2014 16:01)   

Именно. Где-то даже упоминалось, что MELPe даёт плохую разборчивость с низким битрейтом когда речь не на английском. Т.е., отличие уже даже на уровне распознавания типичного произношения.


Кстати, видео[link25] к слайдам.

— gegel (27/06/2014 16:17)   
MELPe даёт плохую разборчивость с низким битрейтом когда речь не на английском

Мало того, когда слушаю себя loopback-ом в своем Торфоне, радуюсь: MELPe-1200 такой милый английский акцент добавляет, как у настоящего американца, пытающегося общаться на русском :)
— unknown (27/06/2014 16:24)   
:)

Вот похожая работа ещё от других авторов: REAL-TIME END-TO-END SECURE VOICE COMMUNICATIONS OVER GSM VOICE CHANNEL[link26].
— unknown (27/06/2014 18:16)   
А там в ECDH-парах шифрование не рэндомизированное?

В смысле, всегда без проблем вычисляется:

Bx = Xb
Ay = Ya
— gegel (27/06/2014 20:28, исправлен 27/06/2014 20:51)   
всегда без проблем вычисляется:

Да, конечно. Ограничения касаются лишь приватного ключа: он получается с 256 бит рандома сбросом младших трех бит и установкой 4-ого бита и старшего, если не ошибаюсь. Я это все лично тестировал, для проверки использовал тестовый код из Tor[link27], отдельно Берштейновские векторы[link28] и отдельно сотню DH-согласований c рандомными ключами. Все пробовал с различными компиляторами как под Linux, так и под Win32, и с разными оптимизациями. Никаких проблем ни разу не возникло.


Вот похожая работа ещё от других авторов

Так это они есть, из Суррея. По первой ссылке просто использован их модем, их имена – на слайде 47. Жаль, работа не особо свежая, пробовать написать им уже нет смысла, наверное.
Если случайно наткнетесь на другие ссылки, буду безмерно благодарен – интерес к p2p поверх GSM огромен.


Я уже несколько лет дружу с китайской Quectel, производящей дешевые ($15) GSM-модули M12 и M85 на чипсете MT6252, базирующимся на ARM7 с возможности разработки встраиваемого прямо в модуль кода для пользовательский задач и имеющего все неообходимые HW-интерфейсы (SIM, аудио, клавиатура, дисплей, SD-карта, RS232). IMEI тоже может меняться налету изнутри. Конечно, он MELPe внутри не потянет, но можно добавить внешний STM процессор для кодека и модема. Т.о. можно сделать простой криптофон.

— unknown (27/06/2014 21:47)   
С точки зрения крипто, пока, насколько я старался ничего не просмотреть, протокол скрэмблера выглядит весьма оптимистично: никаких лишних наворотов, всё самое необходимое, надеюсь и достаточное.

Ссылки по Data/Encrypted Voice over GSM попадались ещё от индусов каких-то. Но малоинформативно. Такой же квадратик в схеме: а вот тут у нас псевдоречевой кодировщик. В принципе, можно попробовать совсем методом тыка: порезать речь на очень мелкие фрагменты, придумать между ними функцию сглаживающего перехода, посмотреть статистически — какие фрагменты лучше сохраняются в канале, выбрать их, назначить им комбинации битов и оптимизировать это всё по устойчивости-скорости, многократно прогоняя поиск с самого начала.
— unknown (28/06/2014 00:20, исправлен 28/06/2014 00:32)   

Code Review lulzlabs Radio AirChat[link30]. Это просто обвязка к fldigi, которая стандартно в Linux дистрах есть. Если эта обвязка настолько кривая, как описано в обзоре, то она просто не нужна, как и попытка использовать её реализацию криптографии.


Для связи можно использовать лазеры[link31]. Или нелазерные фотодиоды, как в RONJA[link32]. Бывает ещё оптика с отражением от облаков, рассеивающийся и переотражающийся в воздухе через препятствия ультрафиолет (UV NLOS), связь через пространственное разделение светосигналов (по типу считывания картинок видеокамерой с экранов), ультразвуковые сигналы под водой, подземные токи и подземное радио… Потоки нейтрино ещё :) Много интересных каналов.



Оказывается, всё есть[link34]. Linsim, например.

— gegel (28/06/2014 01:23, исправлен 28/06/2014 01:24)   
Ссылки по Data/Encrypted Voice over GSM попадались ещё от индусов каких-то.

Я не пожалел времени – активно погуглил. Индус – это тот же N.N. Katugampala, просто публикуется в Англии. Но удалось найти гораздо более подробные работы:


http://v3solar.com/wp-content/.....5/LaDueIEEEpaper.pdf[link35]
http://www.diva-portal.org/sma.....21981/FULLTEXT01.pdf[link36]
http://web.itu.edu.tr/~orssi/t.....SercanTuncay_bit.pdf[link37]


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

Гость (28/06/2014 03:35)   
А почему все-таки аппаратный? Понятно, если заказчик с толстым кошельком, тут и деваться-то некуда :-)
Но если они просто желающие, как все? Тогда эти аппаратные решения достанутся еденицам (десяткам, сотням), а остальные миллионы юзеров слюну глотать.
Гораздо полезнее было бы сделать программный – разошелся бы по всему миру!
Заодно и имя бы свое обессмертили, как Циммерман :-)
— SATtva (28/06/2014 09:59)   
Программный давно уже есть[link38].
— gegel (28/06/2014 10:53, исправлен 28/06/2014 11:29)   
Гораздо полезнее было бы сделать программный

Из первого поста:

На первом этапе хочу сделать софтварную реализацию под Linux для i386 без использования FPU

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


PS: 4QAM тоже проходит[link13]. Так что есть перспектива решить проблему малой кровью.

Гость (28/06/2014 17:48)   

Ну это не совсем скремблер, а полноценный криптованный голосовой мессенджер, включающий и скремблер.

А отдельный программный скремблер, как я понимаю, это универсальный модуль с открытым интерфейсом, который можно подключить, например, к Skype (если позволяет его API) и тем самым послать любопытных товарищей майоров из M$ и АНБ лесом.
Гость (29/06/2014 23:58)   
Новейшая защита телефона Меркель не спасет от американских спецслужб

Новый мобильный телефон канцлера Германии Ангелы Меркель оснащен новейшей системой защиты. Несмотря на это, гарантий, что разговоры Меркель останутся конфиденциальными, нет, сообщает газета Bild.
Накануне появилась информация, что специально для председателя правительства ФРГ изготовили Blackberry Q10 с усиленной системой безопасности. Смартфон оснащен специальным устройством защиты – крипточипом Secusmart, который стоит 2,5 тысячи евро.
Один из сотрудников АНБ США рассказал изданию, что американские системы дешифровки опережают технологии защиты мобильных телефонов. "Технические изменения сотовых телефонов не мешают нашей работе", — заявил он. Представитель компании, занимающейся разработкой систем кодировки Secusmart, в свою очередь заявил, что их изобретение способно защитить от всех видов атак.

http://www.vesti.ru/doc.html?id=1742120

Как ваш скремблер – получчше будет меркелевского? ;-)
Гость (30/06/2014 03:05)   

GSM — это не радиосвязь[link39]. Кстати, по ссылке как раз обсуждались альтернативные каналы связи.


Судя по картинкам по ссылке, «невидимость» луча просто феноменальная. Я думаю, если такое в городе запустить, незванные гости на пороге будут уже через 5 минут.
— SATtva (30/06/2014 09:58)   
Заметно, что фотки сняты с очень высокой экспозицией. Но учитывая, какая сейчас истерия в связи с идиотами, светящими лазерами в самолёты (может, это на самом деле просто лазерные каналы связи?), гостей действительно можно будет ждать.
— unknown (30/06/2014 10:04, исправлен 30/06/2014 10:31)   

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



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



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


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

— unknown (17/10/2014 10:26, исправлен 17/10/2014 11:54)   

Описание некоего проекта, похожего на идею топика, на кикстартере[link41] (сумму собрали в сентябре), сайт http://www.jackpair.com, довольно кстати неудобный и малоинформативный, даже по сравнению с кикстартеровской страницей (лучше сначала прочитать/посмотреть её).


Авторы создали прототип аппаратного скрэмблера с кодеком, пробивающим GSM (имитирует речь) и с шифрованием DH/Salsa. Размером с флэшку или стандартную карманную зажигалку для сигарет. Подключается в разъём аудиогарнитуры к мобилке — шифруется только аналоговое аудио и нет контакта с аппаратной/программной частью мобилки (выломать встроенный микрофон в мобилке когда-то в форуме уже советовали). В принципе, наверное может работать и для VoIP (например, Скайп), и других аудиоканалов.


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


Насчёт доверия к проекту — вопрос открытый. Много презентационных материалов, но мало описания технической части. Интересно как демонстрация возможности. Непонятно, что они уже реально сделали, а на что только заказы принимают. Если опубликуют все открытые спеки, то можно перевоспроизвести самому, хотя бы их прототип на raspberry pi.


P.S. Собственно, слово «скрэмблер» — устаревшее понятие из аналоговой техники, а термин «цифровой скрэмблер» — не совсем удачная попытка его осовременить.

— SATtva (17/10/2014 12:05)   
Некоторое время назад даже Шнайер эту штуку попиарил[link42].
— unknown (06/11/2014 00:06, исправлен 06/11/2014 00:11)   

Всё-таки, проект модема на речеподобном сигнале, способном проходить внутри GSM-канала, не давал мне покоя. Изначально он упоминался в /comment80945[link44], /comment80950[link45], /comment80964[link46], /comment80975[link47]. Затем вот проект Jackpair /comment84026[link48].


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


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


Итак, оцифрованный голос они кодируют в codec2, шифруют, а вот чем создают сигналы речеподобного модема? Скорее всего, самим codec2!


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


Узнаем, какая звуковуха в ALSA-системе нам подходит коммандой aplay -L. Допустим это будет default:CARD=SB. Тогда, скачаем и скомпилим утилиты для codec2 и наслаждаемся звучанием посредством команды:


Скорость 2400 — оптимальная, звук очень похож на речь, покодированную чем-то вроде старого аналогового скрэмблера. Если взять 3200 — то слишком быстро и много высоких тонов, какое-то птичье чирикание. А на меньших скоростях псевдоречь очень медленная, много больших пауз. И скорее всего, раскодировка псевдослучайных бит через codec2 и есть тот речеподобный сигнал, который гарантированно проходит через GSM и другое внешнее речевое кодирование.


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


Если эта догадка верна, то вторая часть ноу-хау скрывается в системе кодирования (не путать с шифрованием): биты на входе возможно как-то дополняются, чтобы давать наиболее различимые фонемы. Ну и с однозначным раскодированием тоже не всё понятно: непонятен пока ни сам принцип однозначного обратного преобразования, ни система синхронизации, ни система коррекции ошибок. В GSM, когда каналы забиты и абонентам режут битрейт, очень часто пропадают куски (звуковые фреймы), возникают дребезжания (многократные повторы очень коротких фрагментов), задержки и пр. Кодирование и синхронизация должны уметь с этим эффективно бороться. Возможно и тут всё сравнительно просто, например всё бьётся на очень большие куски, к которым применяется FEC (Forward Error Correction).


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

Гость (06/11/2014 14:04)   
Не знаток в области голосовой связи, но всё-же выскажу мысль. Самое простое это наверное выделить звуковые образцы, которые можно распознать после GSM-кодирования. Например если образцы А и Б после прохождения
через GSM-канал распознаются опять как А и Б, то получается однобитное кодирование: А=0, Б=1. Подобрать два образца можно и на слух без всякой теории. Например использовать два гласных – А и О, которые отличаются частотой и могут легко идентифицироваться при декодировании. Принципиально это решает задачу, но для повышения плотности кодирования необходимо увеличение количества образцов. Чтобы решить задачу по распознаванию образцов после прохода через GSM, нужно определить набор параметров, которыми описывается каждый образец, и критерии для их различия между. Получается чисто математическая задача – для заданных допусках по искажению при GSM-преобразовании и величине шума найти все образцы, которые могут быть различимы. Чем качественней канал, тем меньше допуски и тем больше можно использовать образцов. Чтобы контролировать ошибки, ввести CRC для кусков кодированной информации. В зависимости от качества канала и процента ошибок автоматически регулировать количество звуковых образцов, т.е. битность кодирования. Если ошибок много, то это количество/битность уменьшается, если мало – увеличивается.
— gegel (06/11/2014 20:40, исправлен 06/11/2014 21:23)   

Я эту тему не забыл, но полностью переключился на ониофон, так что отложил до лучших времен. Но в начале лета провел несколько экспериментов по проходу GSM различными модуляциями. В частности, я поднял рефференс-код кодеков GSM-FR (классический, поддерживается всеми телефона), GSM-HR (половина битрейта, отключаемый), GSM-EFR (улучшенный на полном битрейте), а также семейство AMR. Все эти кодеки сейчас входят в проект ониофона, и можно включить онионфон в режим теста и использовать как платформу для тестирования, пропуская через нее модулированный сигнал (единственно что, работает автоподстройка битрейта, но только в случае нехватки быстродействия, и, кроме того, отключен DTX/VAD на GSM-HR, но если у кого-то возникнет желание тестировать, я сделаю кастомизированную сборку).
Для теста использовал две FreeDV[link49], запущенные на двух компьютерах, итого понадобилось 3 компьютера, пара звуковых шнурков, микрофон и наушники.
FreeDV использует FDMDV-модуляцию в трех разных режимах: 14 полос без FEC, 16 полос с FEC, и 16 полос с бОльшим разносом между ними (Wide). Единственный кодек, через который удалось пропустить сигнал, был GSM-EFR, с ошибками меньше десятой процента, и без срабатывания VAD (по моему, в wide он все же срабатывал – кодек считал, что это не речь). Т.о. вопрос по крайней мере частично был решен, и можно было делать реализацию, в т.ч. и аппаратную[link21].


Что касается теории, то ссылки в теме выше, наверное, исчерпывающие. Вкратце так.
В теоретической работе[link35] (кстати, один из авторов – русский) подробно расписан алгоритм выбора псевдоречевых символов и формирования таблиц. Много математики, unknown должно понравиться. И, кстати. это похоже на предложенный Вами метод. Но есть один минус – не учитываются внутренние алгоритмы кодирования в GSM. Хотя, может, оно и лучше, т.к. дает статистически наработанную универсальность.
В дипломной работе[link36] швед на гораздо более простом языке подробно излагает классический Суррейский путь (см. 3.1.1., я уже было подумал, что их алгоритм нон-паблик), а также предлагает его улучшение, и, самое главное, расширение на стандартный GSM-FR (остальные кодеки в любом телефоне можно принудительно отключить). Он использует синтетическую кодовую таблицу, наработанную не статистически, а выведенную исходя их особенностей кодового алгоритма (см. 5.3.7). Вобще. рекомендую прочитать – очень познавательно.
И, наконец, французская статья[link13], где показано, как просто и сердито решается проблема с помощью выше рекомендованной unknown модуляции 4QAM. Наверное, я мог бы выполнить подобную работу, протестировав FDMDV в различных вариантах и выбрав оптимум, но это позже, сначала закончу онионфон.


В итоге, наиболее простым вариантом видится использование FDMDV или 4QAM с настраиваемыми (возможно, даже, адаптируемыми к текущему каналу) параметрами, а наиболее перспективным – использование кодовой таблицы, рекомендованной шведом для GSM-FR. Кодер там тривиальный (в зависимости от слова данных выбираем из таблицы и шлем на звуковую карту нужный символ), декодер можно сделать минимальной переделкой стандартного GSM-декодера (заменить имеющуюся таблицу на свою).
Что касается статистической наработки, то тут будет напряг с ее синтезом на базе рандома и больших речевых фрагментов в матлаб. Я к этому не готов, если кто-то возьмется – респект.
Ну, и, наверное, вместо codec2 я бы использовал melpe (но лицензия!), и на выбор варианты на низком битрейте, но без FEC, и на более высоком, но с FEC.


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

— unknown (06/11/2014 22:44)   

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


Хотелось бы даже в двустороннем канале иметь одностороннюю связь (как UDP вместо TCP), полностью опирающуюся на FEC вместо CRC и не использующую какие-либо автоматические ответы для переотправок или подстройки канала — это ещё и для радио может пригодиться. Для голоса стопроцентная коррекция не нужна. Именно на этом принципе работает codec2 и его аналоги: если какие-то биты приняты неправильно, то кодек выдаст случайный речеподобный звук или искажение уже существующего. Если битовых ошибок мало, то человеческое ухо само всё поправит. Поэтому, если стоит задача передавать именно шифрованный голос, то можно использовать шифрование счётчиком без аутентификации и слабое FEC, больше для синхронизации, чем для исправления ошибок.


Я бы исходил из ситуации, в которой каналы связи труднодоступны (например, в районах стихийных бедствий или боевых действий), сигнал от сотовой вышки слабый, каналы перегружены, голос постоянно рвётся, качество связи ужасное, всем режут битрейт. Кроме того, может таким способом пытаться прокинуть канал внутри спутникового телефона (чисто голосовые звонки там гораздо дешевле, чем зверские тарифы на интернет) или недоверяемого VoIP (Skype и др.), возможно способ будет универсальным и для раций (а там некоторые современные модели в некоторых диапазонах голос уже тоже передают цифрой или имеют перескок частоты, но это всё закрытое и недоверяемое, хорошо бы иметь внутри этого свой канал). Т.е., заранее неизвестно, какой кодек будет в канале оператора и насколько плохое качество связи. Чем создавать коррекцию связи, абонентам проще голосом в открытую корректировать: «твой сигнал плохо схватывается, голос в шифре совсем не разобрать, попробуем переключиться на битрейт пониже, 1600 вместо 2400».


Есть что объединить по смыслу и почитать.


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


Вот когда-то ширпанку Циммерману было не до лицензий, после чего был такой бардак с алгоритмами в PGP: RSA пришлось выкидывать, а когда патент на RSA истёк — возвращать, но в другом формате; IDEA тоже выковыривали, так что те, кто к ней привык, долго использовали сторонние патчи, но сидели на несовместимых по свойствам ключах и т.д.
— gegel (19/11/2014 22:04, исправлен 19/11/2014 22:12)   

Воодушевленный китайцами, провел эксперименты и сделал модем для GSM-FR по рекомендациям в шведской дипломной работе + некоторые расширения + синхронизация. Действительно, получился очень низкий BER через GSM-HR и чуть хуже через GSM-EFR на битрейте 1600, чего достаточно для кодека на 1200 + FEC 2/3.
Но GSM-HR был не проходим.


Очень внимательно изучил демку JackPair с ютуба, прогнав аудио через массу возможных анализаторов. Со слов китайцев, их модем прекрасно проходит GSM-HR[link52] и AMR[link53]-4750. Очень похоже по звуку, что в качестве модема они использовали готовый GSM-HR декодер, использующий кодовую таблицу CELP. Тщательно разобрал документацию ETSI на данные кодеки, чтобы использовать их в качестве модема.


В качестве модулятора можно использовать декодер GSM-HR (fig.5).
Четыре псевдоречевые символы длительностью по 5 мс выбираются из таблицы (512 шт) 9-ю битами каждый (CODE_1 – CODE_4), расположенными в фиксированных позициях сжатого фрейма (блока) кодированного голоса. Остальные биты надо оставлять постоянными, причем LPC-паремтры подобрать по равномерному спектру (китайцы, походе, их меняют каждые 40-60 мс для предотвращения сработки детектора не-голоса, отсюда специфическое улюлюканье), а GSP-параметрами задать максимальное усиление для статической таблицы и минимальное – для адаптивной. Блок с 4 псевдоречевыми сиволами (4*9 полезных бит) подаем на декодер и получаем фрейм псевдоречи (20 мс, 160 сэмплов), которую и передаем через аудиоканал.


В качестве демодулятора можно использовать GSM-HR-кодер (fig.2), подавая на него псевдоречь и извлекая 4*9 бит из кодированного фрейма. Сдвиг по времени (лаг) компенсируется самим кодеком по максимуму вероятности совпадения с стандартными табличными символами, так что остается лишь синхронизировать бит-поток, разбив его на блоки. В итоге получаем те же 1600bps чистые и 1200bps после FEC.
По идее, стандартная кодовая таблица CELP уже наработана с учетом реальной речи, поэтому такой вариант должен быть проходим через большинство кодеков.


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


Попробую еще так, результат отпишу.

— unknown (20/11/2014 09:37, исправлен 20/11/2014 09:38)   

А можете прокоментировать в шведской диссертации рис. "Figure 4.4. Framework voice channel" (стр. 46 в pdf или page 30 во внутренней нумерации документа)?


Насколько я понимаю, в реальном канале возможно двойное перекодирование всеми сочетаниями кодеков, например AMR Narrow → TETRA (если передаётся в транк). И идея в том, чтобы сигнал гарантировано проходил через все такие возможные сочетания.



Разговаривать на 1200bps в codec2 — это жесть! Это как голоса в голове слушать :)

— gegel (20/11/2014 12:40, исправлен 20/11/2014 12:46)   
в реальном канале возможно двойное перекодирование всеми сочетаниями кодеков, например AMR Narrow → TETRA

На сколько я понимаю, Figure 4.4 возможно в случае соединения между различными операторами, особенно различных систем связи. Например, один абонент использует GSM и старую трубу (в ней только GSM-FR) и звонит UMTS-абоненту (там только AMR). Тогда система должна преобразовать одно сжатие в другое через несжатый голос. Поэтому швед в своем фреймворке использовал два последовательных преобразования (но одним кодеком). Хотя мне кажется, что при использовании одинаковых кодеков в одной сети двойного преобразования не выполняется в целях экономии ресурса системы (и звонки с своей сети поэтому дешевле). Но принудительно выбираются (переключаются) кодеки абонентов из их набора возможных.
Я вчера почитал доки к GSM-модулям Quectel, которые я использую в других разработках. В инженерном меню есть команды выбора предпочитаемого кодека, а также есть возможность уведомления о используемом кодеке, а также каждый раз в случае его изменения. Попробую использовать две отладочные платы с модулями в одной и в разных сетях, проверю, что там реально происходит. А также попробую сделать реальный аналоговый аудиолинк через модули и проверю поведение модемов с ним.


Разговаривать на 1200bps в codec2 — это жесть!

Согласен. Меня и MELPE напрягает. Но это все для полувоенных задач, шептаться с девушкой так врядли кто будет.
А вот поврех Skype/Jitsi, возможно, придется искать более скоростные модемы. Например, скайповский Silk оказался весьма проходим.
Сделать шифровальщик там вобще можно без труда: в виндоус установить пару виртуальных аудио-кабелей (каждый создает в системе устройства ввода и вывода так, что все аудио, поданное на вывод, может быть считано с ввода). Кодировщик представляет два аудиоинтерфейса: один настраиваем на штаную звуковую карту, второй на шнурки. Скайп настраиваем на другие концы шнурков.
В линукс мне посоветовали в качестве аналога alsa loop, но я пока с ним не разбирался.

— unknown (20/11/2014 13:06)   

Я бы на это особенно не наделся. Мало ли что учудит провайдер при падениях и перегрузке линии.


Это интересно в любом случае.


На 3200/2600 можно хотя бы узнавать голос и различать интонации. На более низком битрейте даже односложные команды можно перепутать. Т.е., для разговора нужна тренировка ушей. Понятно, что сквозь аудио-тракт GSM вытянуть гарантированные 1200 — уже успех.


Эту задачу решает такая надстройка на ALSA как Jack, но его используют только в профессиональной работе с сигналами вообще и со звуком в частности. Обычный пользователь его не поставит и не настроит. Хуже того, обычным пользователям удобнее PulseAudio, которое несовместимо (плохо совместимо) с Jack.
— gegel (20/11/2014 13:18, исправлен 20/11/2014 13:40)   

Посмотрите варианты, которые мне посоветовали. Вы скорее в этом разберетесь.


http://www.alsa-project.org/ma...../Matrix:Module-aloop[link54]


http://www.vsound.org/


PS: этот пример показался мне более информативным:
http://unix.stackexchange.com/.....ing-alsa-loop-device[link55]

— unknown (20/11/2014 14:55, исправлен 20/11/2014 15:13)   

Там всё закончилось предсказуемым срачем ALSA vs. PulseAudio.
И предсказуемым же призывом использовать ALSA+Jack. Чтобы стало вот так[link56]:


Option 1: don't use PulseAudio with JACK
The most experienced and demanding users of JACK do not attempt to link PulseAudio and JACK. Many of them will not run PulseAudio at all, having either never installed it, removed it from their systems, or disabled it. They will generally route audio from other apps to JACK without using PulseAudio

Option 2: use two different soundcards

И другие решения. Принцип в том, чтобы были рады или хомячки (PulseAudio), или продвинутые пользователи (ALSA+Jack). Или-или, а другая половина чтобы страдала. Похоже на проблему TBB у торпроджекта (выбор между системным тором и TBB[link57]).


Вот напишете вы свой аудиопроект под PulseAudio, >90% будут рады, а часть ни за что его не поставит, чтобы не связываться с PulseAudio также как с Java, Flash, Mono etc.


Виновник и первоисточник несовместимого аудиозоопарка печально известен[link58], вот слайды[link59], где он оправдывает свою позицию.

— gegel (26/11/2014 00:21, исправлен 26/11/2014 00:24)   

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

www.etsi.org/deliver/etsi_ts/126200_126299/126267/11.00.00_60/ts_126267v110000p.pdf

и открытым исходным кодом[link60] для тестироания). Стандарт разработан для системы eСall, обязательной к внедрению до 2015 года всеми мобильными операторами и предусматривает возможность передачи экстренной информации (пакет в 140 байт) максимум за 4 сек через любой акустический канал связи, включая все комбинации мобильных операторов. Русский сегмент (совместимый) – Эра-Глонасс[link61].
Я не пожалел времени и очень внимательно изучил принцип модема и исходный код, сравнил с теоретическими работами, цитируемыми выше, а также тщательно вник в алгоритмы работы GSM-FR[link62], GSM-HR[link63] и семейства AMR[link64] кодеков.
В результате стало ясно, что, во первых, предлагаемый для eCall модем не является оптимально спроектированным, и, во вторых, он не подходит для потоковой негарантийной передачи, т.к. предполагает многократную переотправку одинаковых данных с использованием инкрементального турбокода для FEC. Это и понятно, т.к. пакет eСall содержит, например, координаты, которые не могут быть искажены, в отличие от сжатого голоса, зашифрованного потоковым шифром.
В итоге мне пришла идея совместить лучшее со всех источников и сделать свой вариант модема, заточенный под задачу; этим и занимаюсь.


Что касается экспериментов с GSM-модулями Quectel в реальных условиях: сделал фреймворк из двух отладочных плат, ввел оба модуля в инженерное меню, использовал сети Киевстар и UMC. По умолчанию всегда применялся низкобитрейтный AMR-кодек (худший для нас вариант). При выборе GSM FR из меню этот кодек применялся всегда, причем как для исходящих, так и для входящих соединений (выбор можно зафиксировать). Но у другого абонента все равно использовался AMR по умолчанию. Причем транскодирование происходило даже при звонках между абонентами одного оператора.
При фиксации на обоих концах GSM FR использовались одинакове кодеки, но есть подозрение, что перекодирование все же происходило 2 раза (это совпадает с данными шведов).
Плохо то, что обычные телефоны могут отключать GSM-EFR и GSM-HR, но не могут управлять AMR (хотя я могу и ощибаться, разберусь позже). Что касается GSM-FR, то у меня получилось достичь нужного битрейта при малом BER, следуя рекомендации шведа. Пробую добавить к этому решению идеи из eCall и оригинальную автосинхронизацию, пока не взирая на лицензии и используя фрагменты референс-кода самих кодеков.
Надеюсь, будет лучше, чем у китайцев. Если сделать андроидный вариант и запускать на дешевом планшете с выпиленным WiFi-модулем, в качестве второй звуковой карты использующем Bluetooth-гарнитуру, получится весьма защищенный универсальный цифровой скремблер.

— unknown (26/11/2014 00:51)   
Интересные результаты, держите в курсе дальнейших изысканий! Даже если по какой-то причине не будет возможности или желания доделать, то такие черновые наработки могут кому-нибудь пригодиться.
— Sfinx (21/12/2014 19:52)   
GSM кодек пройти легко, а вот AMR 475 – не просто. Отрабатываю идею с LPC генератором речеподобных символов, но непонятно как они смогли получить набор коротких и уникальных ones. Мои эксперименты дают более или менее рабочие результаты для символов длиной от 40ms длиной, что подразумевает пипец как большую кодовую книгу для скоростей 1.2-1.5k/sec.
— gegel (22/12/2014 01:05, исправлен 22/12/2014 01:10)   

Ну, я с Вами прямо в параллель работаю :) Даже OnionPhone пока приостановил, так меня заинтересовала идея модема.
По поводу кодовой книги немного есть тут[link65]. Я тоже прошел это, используя код GSM-FR для синтеза.
А вот еще одна интересная работа[link66]. В отличие от остальных, авторы сравнили LPC-модем с обычным DPSK, и предпочли последний (правда, для EFR). И чем больше я об этом думаю, тем больше убеждаюсь в теоретической невозможности пройти на 1200 AMR475 и HR. Так что JackPair вполне может оказаться фейком.


Рассуждения вот какие.
Можно использовать или пульсы (Суррейский путь), или LPC-коэффициенты (по первой ссылке), или и то, и другое.
Но AMR475 использует всего 2 импульса на 40 сэмплов. Кодек в телефоне не синхронизирован с приеником-передатчиком, поэтому, для того, чтобы никогда не было более 2-х импульсов в любых подряд 40 сэмплах, можно использовать только один импульс на 40 сэмплов. Количество позиций в треке – 8 (каждые 5 сэмплов), использовать гуще не совсем хорошо, т.к. AMR475 выбирает из двух возможных субсетов, и не факт, что сдвиг не будет фатальным. Т.о. останавливаемся на 8-и позициях на 40 сэмплов + знак пульса. Имеем 4 бита на 40 сэмплов, т.е. 800 bps.
Теперь об LPC. AMR475 использует 10 коэффициентов, но, например, GSM-FR – 8, поэтому остановимся на 8. Обычно LPC-анализ проводится на 160 сэмплов. Помним, что кодек на проводе не синхронизирован с приемником-передатчиком. Т.о. при изменении коэффициентов в фрейме кодек посредине может обрабатывать ее половину и половину следующей.
С лагами субфреймов еще хуже: думаю, lag и gain на модуляторе вообще трогать нельзя, оставляя свободу кодеку посредине. Для предотвращения интерференции соседних фреймов предлагаю чередовать в соседних фреймах наборы по 4 LPC-коеффициента. Причем передавать в одном коэффициенте есть смысл только один бит (+ или -). Т.о. получаем еще по биту на субфрейм, итого 1000bps. Мне нужно 1200. Возможно, получится как-то впихнуть по 2 бита на LPC-коэффициент без потери надежности, это будет победа.


Что касается личных экспериментов, то разработана уникальная система двойной синхронизации: тонкой на базе GridSelection из GSM-FR, и грубой, используя Golay-FEC из FDMDV-CODEC2 и накапливая BER для всех возможных лагов в блоке из 540 сэмплов, выбирая лучший по приему всего блока. Работает супер: теряется только текущий блок при начале приема из любого места потока (причем тест не на фреймворке, а с реальным С-кодом на реальном HW (PC) через аудиошнуры. Уверенно подстраивает синхро при разнице в сэмплрейте до 10% (эта разница реально была между двумя компьютерами, не упускайте ее из виду! Ресемплеры дают худший результат, чем синхро путем периодической вставки/скипа сэмпла).


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


Код MELPE имеет свой FEC, и его результат можно использовать для грубой синхронизации (выбора лага) на чистом битрейте 1200. Криптосинхронизацию для счетчика в потоковом шифре я тоже смогу обеспечить. Но вот осталось чуть-чуть – получить 1200 (пока есть 1000). Или заиметь исходники MELPE600...


Мои эксперименты дают более или менее рабочие результаты для символов длиной от 40ms длиной, что подразумевает пипец как большую кодовую книгу для скоростей 1.2-1.5k/sec.

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

— Sfinx (22/12/2014 12:34)   
Вот количество символов в кодовой книге для разных скоростей в зависимости от длины символа :

5 ms:[40 samples] required symbols for 450: 4
5 ms:[40 samples] required symbols for 600: 8
5 ms:[40 samples] required symbols for 800: 16
5 ms:[40 samples] required symbols for 1000: 32
5 ms:[40 samples] required symbols for 1250: 64
5 ms [40 samples] required symbols for 1500: 128

10 ms:[80 samples] required symbols for 450: 16
10 ms:[80 samples] required symbols for 600: 64
10 ms:[80 samples] required symbols for 800: 256
10 ms:[80 samples] required symbols for 1000: 1024
10 ms:[80 samples] required symbols for 1250: 4096
10 ms [80 samples] required symbols for 1500: 32768

15 ms:[120 samples] required symbols for 450: 64
15 ms:[120 samples] required symbols for 600: 512
15 ms:[120 samples] required symbols for 800: 4096
15 ms:[120 samples] required symbols for 1000: 32768
15 ms:[120 samples] required symbols for 1250: 262144
15 ms [120 samples] required symbols for 1500: 4.1943e+06

20 ms:[160 samples] required symbols for 450: 512
20 ms:[160 samples] required symbols for 600: 4096
20 ms:[160 samples] required symbols for 800: 65536
20 ms:[160 samples] required symbols for 1000: 1.04857e+06
20 ms:[160 samples] required symbols for 1250: 3.35544e+07
20 ms [160 samples] required symbols for 1500: 1.07374e+09

я распознаю символы используя mfcc+dwt, уверенное распознавание происходит при 7-11 коэффициентах, отсюда можно прикинуть размер памяти для множества векторов, в котором нужно производить поиск. Стартовую синхронизацию можно сделать передачей длинного сэмпла тишина/частота – моя быстрая реализация показывает уверенное распознавание, далее можно просто передавать сэмпл "частота" как маркер фрэйма, с этим тоже пока проблем нет. Заморачиваться с импульсами я не решился, почитав патент Kondoz'а – как по мне это overcomplication, уж лучше тогда сделать по быстрому hermes-like модем c его диким ecc ;) У LPC есть еще pitch, который тоже может нести пару бит. Не думаю, что джекпэйр фейк, просто им удалось сделать генератор LPC с малым искажением символов при проходе через AMR. Я даже попробовал подобрать символы, которые менее всего искажаются тупо перебором всего доступного пространства LPC коэффициентов (слегка конечно загрубив), но пока безуспешно ;( 1200 – это конечно неплохо, но для старта достаточно 500-600 бит/sec, найти соответствующие кодеки – не проблема
— gegel (22/12/2014 22:35, исправлен 22/12/2014 22:51)   
Мои эксперименты дают более или менее рабочие результаты для символов длиной от 40ms длиной

AMR475 посредине проводит LPC-анализ 20mS-фрейма. При длине символа в 40mS хотя-бы один фрейм кодека будет в границах вашего символа, т.о. коэффициенты будут переданы правильно. Моя идея, озвученная выше – использовать два непересекающихся набора коэффициентов для соседних символов. Т.о. интерференция между соседними символами за счет работы несинхронного кодека посредине сводится к минимумму.
В этом случае символ можно попробовать уменьшить до 20 mS, в любом случае не менее половины спектральной характеристики будет верно передано через канал. Синхронный приемник анализирует только свой субсет коэффициентов для каждого фрейма, игнорируя второй субсет, интерферирующий с соседним фреймом.
Кстати, хотел оценить девиацию LPC-коэффициентов при чередовании двух фиксированных символов через асинхронный кодек-посредине. Надо бы запустить передатчик, транскодер и приемник на трех РС с чуть отличающимся сэмплрейтом аудиокарт и посмотреть, какие коеффициенты получаем, и их динамику. Везде использовать код AMR475. Когда-нибудь попробую.


Кстати, ваше направление и выбранное мною взаимно дополняют друг друга. На сколько я понимаю, суть кодека сводится к первоначальному LPC-анализу (получаем коеффициенты, указывающие на активность соответствующих синусоидальных частот), затем полученный коэффициенты применяет в фильтре и отфильтровывает эти частоты от исходного сигнала. В итоге получается резидуальный сигнал с намного меньшей энергией ("инновации", не описываемые синусоидальными формами). Эти инновации кодируются по алгебраической книге в виде позиции и знака пульсов (для EFR – 5, для AMR475 – 2 на 5 mS). Т.о., по идее, использование для передачи информации LPC-коэффициентов и пульсов будет мало интерферировать друг с другом.
Как я писал в предыдущем посте, скорее всего, должно получиться пройти AMR475 пульсами на 800bps (1 пульс на 5 mS в 8 возможных позициях с шагом 5 сэмлов). На этот резидуальный сигнал можно наложить ваши синусоидальные псевдоречевые символы. Если с их помощью получиться добавить еще хотя-бы 400bps, имеем нужные 1200. Для синтеза и анализа можно использовать тот же код AMR475.


сделать по быстрому hermes-like модем

Я пробовал FDMDV модуляцию (проект FreeDV) и 4QAM (по статье французов). Уверенно проходит только EFR, но даже на FR рубится. Пульсами же у меня получилось реально выжать почти 1600 на EFR и FR, используя вариант схемы, рекомендованной шведом: с одним пульсом в 6-ти возможных позициях на 18 сэмплов (шаг 3 сэмпла) при очень низком BER.


просто им удалось сделать генератор LPC с малым искажением символов при проходе через AMR

Насколько я понял из обзора публикаций, проблема сложная и остается нерешенной. Подтверждение: серьезный проект модема для eCall использует все же Суррейский путь (только вместо чистого пульса используется пульсообразная вейформа с затуханием, наверное, для обеспечения лучшей корреляции с 4-мя сдвинутыми образцами и возможности накопления при повторных передачах). На месте Джефри, если бы у меня получилось то, что он декларирует в JackPair (якобы проходит и AMR475, и даже HR), я бы скорее срубил академическую работу и патент, чем собирал 50K на кикстартере.


найти соответствующие кодеки – не проблема

Это радует, но, наверное, я не там искал. MELPE600 – пока лишь мечта для меня.

— ZAS (22/12/2014 23:59)   
Кстати, хотел оценить девиацию LPC-коэффициентов при чередовании двух фиксированных символов через асинхронный кодек-посредине.


LPC коэффициенты в кодеках обычно передаются в виде LSP. Для лучшего сжатия передается не сами LSP, a нечто вроде вектора разности LSP относительно предыдущего фрейма. Предполагается, что в реальном арречевом сигнале LPC изменяется медленно по сравнению с фреймрейтом. Вектор разности кодируется по кодебуку, отдающему предпочтение малым изменениям (нечно вроде логарифмической зависимости + отрихтовано по психоакустике). В результате LPC данные ужимаются до 16...24 бит на фрейм, то есть порядка килобита в секунду и менее. На приемной стороне LPC часто интерполируют вдоль фрейма, чтобы не было резких скачков.
Для передачи данных я бы попробовал использовать не LPC, а кепстральные коэффициенты или просто вектор распределения энергии по полосам.

На сколько я понимаю, суть кодека сводится к первоначальному LPC-анализу (получаем коеффициенты, указывающие на активность соответствующих синусоидальных частот), затем полученный коэффициенты применяет в фильтре и отфильтровывает эти частоты от исходного сигнала. В итоге получается резидуальный сигнал с намного меньшей энергией ("инновации", не описываемые синусоидальными формами). Эти инновации кодируются по алгебраической книге в виде позиции и знака пульсов (для EFR – 5, для AMR475 – 2 на 5 mS). Т.о., по идее, использование для передачи информации LPC-коэффициентов и пульсов будет мало интерферировать друг с другом.


Дело обстоит не совсем так. На передающей стороне кодек пытается закодировать сигнал таким образом, чтобы минимизировать ошибку между входным сигналом и синтезированным сигналом (Analysis by Synthesis, AbS). Ошибка измеряется относительно психоакустической модели. Синтезированный сигнал представляет собой сумму вкладов кодебуков, лагов, гейнов и LPC. Ищется оптимальная комбинация всех параметров, путем перебора. Перебор ускоряют разными евристиками, cтатистиками, оптимизациями и прочими халявно-отфонарными методами. Так что параметры оказываются cущественно взаимно завязанными, и к тому же зависящими от предыстории.
http://www.zas-comm.ru
— gegel (23/12/2014 23:33, исправлен 23/12/2014 23:50)   
Для передачи данных я бы попробовал использовать не LPC, а кепстральные коэффициенты или просто вектор распределения энергии по полосам.

Именно mfcc+dwt Sfinx и пытается использовать. А использование спектральных полос, наверное, имелось в виду в неоднократно цитируемой здесь шведской работе[link36]: 5.4.2 Sinusoid Waves. Автор не использовал данный путь из-за корреляционного демодулятора, не подходящего для этой задачи. Но при использовании других типов демодуляции (спектрального анализа) предполагает перспективность подхода.


Вообще, выбор способа демодуляции может существенно влиять на битрейт. Например, в eCall-модеме модулятор выдает табличную 16-сэмпловую вейформу с центральным пиком и затуханием, сдвигая ее по кольцу так, чтобы центральный пик был в одной из 4-х позиций. Демодулятор коррелирует сигнал с 4-мя паттернами и выбирает лучший. В процессе тестирования я случайно остановил программу и, посмотрев отладчиком на массив сэмплов, обнаружил, что всегда могу определить позицию центрального пульса "на глаз". В результате применил другую технику демодуляции: просто ищу максимальный и минимальный сэмпл среди 16, а также среднее значение. Затем смотрю, какой из экстремумов больше отличается от среднего (пульс может быть как положительный, так и отрицательный). Его сэмпл-позицию делю на 4, получаю трехбитовый результат (полярность + 2 бита позиции). В итоге BER неожиданно получился меньше, чем в оригинальном демодуляторе, причем при гораздо меньших вычислениях.


Вот еще иранская работа[link67], где используются псевдоречевые символы длиной в 20mS. У них получилось втиснуть в такой символ 12 бит, получив 600 bps. Затем, используя punctured convolutional code, авторы повысили битрейт до 1.15 kbps при 0.2% BER. Мне не особо нравится такой подход в условиях высокого исходного BER, тем более что авторы тестировали свой модем на GSM FR, который и так обеспечивает гораздо лучшие показатели при использовании пульса в каждой третьей сэмпл-позиции (5.3.7 GSM FR Specialized Symbol Pattern в шведской работе по ссылке выше). Используемый мною вариант (один расширенный пульс на каждые 18 сэмлов в 6-ти возможных позициях) дает практически нулевой BER на GSM FR, обеспечивая 1555 bps.


PS: я написал David Rowe (автору CODEC2), он ответил, что общался с авторами JackPair, и они имели желание опубликовать код своего модема под GPL, но куда-то пропали. Подтвердил сложность проблемы, высказал свою заинтересованность и обещал помочь в работе.

— ZAS (24/12/2014 03:27)   
В процессе тестирования я случайно остановил программу и, посмотрев отладчиком на массив сэмплов, обнаружил, что всегда могу определить позицию центрального пульса "на глаз".


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

Источник псевдоречи описан в ITU-T P.50: http://www.itu.int/rec/T-REC-P.50-199909-I/en
— gegel (24/12/2014 09:35)   
огорчает радиолюбительский подход

Честно, я и сам в замешательстве. Но есть объективная реальность: усредненный показатель BER. Это пример того, когда тупые решения дают неожиданное и плохо объясняемое преимущество перед академическими. Профессионал даже в страшном сне не стал бы и пробовать это. Наверное, в этом суть радиолюбительства.
— unknown (24/12/2014 10:15, исправлен 24/12/2014 10:17)   

[offtop]
Из темы вырисовывается интересный пример.


Любительство хорошо, когда можно показать принцип "just works". Это много где работает, где результат нагляден (связь есть / связи нет) и нет угрозы отдалённых негативных последствий (что-то не учли и дорогостоящий спутник в критический момент упал, реактор взорвался, лекарство лечит и внезапно калечит). Вот в криптографии — всё наоборот, принцип "just works" не работает, отдалённые последствия тоже труднопрогнозируемы, поэтому там к любителсьтву относятся плохо, особенно в фундаментальной криптографии.


Ещё интересно, когда тема при поверхностном знании кажется лёгкой — вот сейчас сядем и изобретём, но в процессе всплывает куча подводных камней и проект не взлетает. Те, кто не в курсе этих подводных камней разработки думают, что «власти скрывают» и не дают изобретать намеренно.
[/offtop]

— gegel (24/12/2014 12:15)   
Я тоже подумывал, что в данном конкретном случае BER может быть лучше только в определенных условиях, а в других корреляционый способ будет работать, а предложенный – нет.
Кстати, ZAS, по идее больше чем кто либо, видился как сторонник таких новаций. Наверное, концепт поменялся, раз критикует какие-никакие, но академические работы, цитируемые в теме. Ну, тогда ждем реальных рекомендаций и ссылок.
— ZAS (24/12/2014 22:17)   
Когда-то работал в предметной области; хотя проблемой передачи данных через кодек не занимался; но принципы мало изменились. Поэтому могу предложить только общие соображения.

Пусть потери пакетов и битов в канале нет. Тогда должно быть возможно при разумных вычислительных затратах пропустить через канал поток полезных данных примерно до половины битрейта кодека (где-то треть-четверть должно проходить без особых проблем).
Предполагаем гибридный кодек (какой-то из вариантов CELP). Тогда информация в основном передается через позицию и амплитуду импульсов с частотой обновления 10ms, и меньшая часть информации через огибающую спектра с частотой обновления 40ms.
В канале есть динамические искажения вызываемые perceptual enhancement на приемной стороне; их должно быть возможно скомпенсировать; но тогда придется тренировать компенсатор под конкретный режим конкретного кодека.
За основу передатчика в канал можно взять декодер от любого низкоскоростного CELP кодека, за основу приемника – кодер от того же кодека. Подрихтовать приемник и передатчик. На передающей стороне удлиннить фреймы и субфреймы. Исследовать проходимость различных комбинаций параметров; выбрать полезные, убрать слабые. Проанализировать поток данных на приемной стороне на предмет BER каждого отдельного бита в каждом параметре. Построить многоуровневую схему коррекции неравномерного распределения ошибок чтобы выровнять BER к заданной целевой величине.
Cделать адаптацию скорости применительно к качеству конкретного канала и кодека.

В общем много разных вещей можно сделать и попробовать. Вырисовывается проект на пол-года-год до построения практического модема; плюс год на обкатку. Задача для специалиста, требующая адекватного финансирования.
Перспективы сомнительны; применение ограничено. Видимо, поэтому предлагаемые работы находятся на уровне студентов и радиолюбителей. Возможно, более простой путь – модификация софта, т.е. создание криптофонов.
— unknown (24/12/2014 23:11)   

Вот и у меня было такое подозрение, скорее согласен с оценкой. Может она даже более оптимистичная, чем реалистичная.
— gegel (25/12/2014 14:16)   
применение ограничено

Тут не совсем согласен: например, проект eCall. И, учитывая масштаб этого проекта, срок разработки (с 2008 года), уровень исследований и финансирования, понятно, что не стоит и пытаться самому что-то сделать лучше. После компиляции их исходников и тестирования я понял, что это и есть предел. Но тут появилось несколько китайцев со своим JackPair и объявили, что сделали модем на порядок лучше. И на сколько это реально, как думаете? Если рассуждать трезво, все больше и больше думаю, что это фейк.
— ZAS (25/12/2014 19:30)   
например, проект eCall. И, учитывая масштаб этого проекта, срок разработки (с 2008 года), уровень исследований и финансирования, понятно, что не стоит и пытаться самому что-то сделать лучше. После компиляции их исходников и тестирования я понял, что это и есть предел.


В eCall предлагается довольно незатейливый модем c отфонарной схемой FEC и простым физическим уровнем. Вероятно, ориентировались на мобильные радиоканалы с минимально удовлетворительным качеством, бeзотносительно к конкретным кодекам, и делали упор на простоту реализации при минимуме MIPS. Они достигли результата, достаточного для решения их задачи; очевидно что не предел.

Но тут появилось несколько китайцев со своим JackPair и объявили, что сделали модем на порядок лучше.


Что известно и что заявлено про JackPair?

И на сколько это реально, как думаете?


Я думаю что вполне реально достичь полезной скорости порядка четверти-трети битрейта кодека. И, возможно, более половины битрейта, если адаптироваться под конкретный кодек и иметь процедуру тренировки при установлении связи.
— unknown (25/12/2014 22:02)   

Ник у вас ZAS, насмешливое слово — «радиолюбительство», «радиолюбительский подход», здесь[link69] промелькнуло слово «интерливер» в описании криптоалгоритма, ещё что-то в том же духе.

Радиомодемы, модуляции, помехоустойчивое кодирование, распределённый спектр, перескок частоты, системы наведения, распознаватели «свой-чужой» — это всё у вас можно спрашивать?
— gegel (05/01/2015 13:45, исправлен 05/01/2015 13:45)   

To Sfinx (если Вы еще смотрите тему):
что имелось в виду под

уж лучше тогда сделать по быстрому hermes-like модем c его диким ecc

?
Оказывается, это не совсем однозначный термин. Возможно, наиболее перспективное направление по соотношению эффективность/сложность.

Гость (05/01/2015 16:58)   

Ничего подобного – ЗАС это "засекречивающая аппаратура связи", так что в самую точку :)
— gegel (05/01/2015 20:25)   
Радиомодемы, модуляции, помехоустойчивое кодирование, распределённый спектр, перескок частоты, системы наведения, распознаватели «свой-чужой»

Не удивлюсь, если в миру unknown окажется священником, а ZAS – оперным певцом. Про семейного доктора уже молчу. А вышеперечисленное – просто безобидное хобби: так, копаемся на досуге в гараже.
— unknown (05/01/2015 21:46)   
Вот, это мудрый взгляд! Я сначала думал, чтобы хоть в моём церковном приходе не узнали. А они оказываются всё уже давно знают, бесы окаянные :)
— Sfinx (06/01/2015 11:10)   
To Sfinx (если Вы еще смотрите тему):
что имелось в виду под
уж лучше тогда сделать по быстрому hermes-like модем c его диким ecc
?


http://www.news.cs.nyu.edu/~jinyang/pub/hermes.pdf
— gegel (06/01/2015 20:55)   
Спасибо! Тогда мы об одном и том же, вот еще ссылка (текст практически тот же):
http://www.news.cs.nyu.edu/~ad.....mobicom10-hermes.pdf[link70]

Я списался с David Rowe (автором codec2), он обещал повторно связаться с авторами JackPair по поводу их модема.

Кстати, Вы наверняка тоже анализировали их аудиопример на youtube
https://www.youtube.com/watch?v=rh6yF79FkAA
Символы у них достаточно длинные (20 mS), четко прослеживаются гармоники pitch около 75-80 Гц. Есть подозрение, что был использован код синусоидального кодека (тот же CODEC2), как думаете?


И еще Rowe подкинул несколько идей. Одна из них и раньше мне приходила в голову: организовать параллельно два канала: отдельно пульсов (по Kondoz, но реже: 1 пульс на 40 сэмлов в 8-ми возможных позициях), и отдельно – тонами (используя код CODEC2). До этого я проводил подобные эксперименты с кодом GSM-FR: отдельно смотрел на LPC-параметры на всей фрейме (20мсек), причем для четных и нечетных фреймов использовал разные наборы частот; и отдельно на позицию пульсов в резидуальном сигнале. Все было хорошо до появления чужеродного кодека по-средине (даже GSM EFR), после чего резидуальный сигнал существенно искажался, и BER пульсового подканала существенно увеличивался. Возможно, другая техника демодуляции была бы лучше.

Я еще спрошу совета у Rowe по поводу идеи авторов hermes. Судя по обзору публикаций, они достигли практически тех же результатов, что и Shahbazi at all (http://ieeexplore.ieee.org/xpl.....3Farnumber%3D5432651[link71], к сожалению, у меня нет FullText), но гораздо проще.

С другой стороны, французы получают всего 200 bps и предпочитают оптимизированные стандартные модуляции:
http://www-common.esiee.fr/dow.....se_CHMAYSSANI%20.pdf[link72]
Это диссертация авторов (на французском, но все равно познавательно), их статью я цитировал выше в теме.

И для ZAS: ваши оценки возможностей GSM-кодированных каналов подтверждаются в работе:
http://www.nativitysoftwares.c.....%20GSM%20Network.pdf[link73]
— ZAS (06/01/2015 21:09)   
Cпасибо за ссылку на hermes. Действительно, проcтое решение, и результ неплохой. Однако их подход ограничен скоростями порядка 1200 bit/s.

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

Кодеки довольно нетребовательны к количеству ошибок в канале. Удовлетворительное качество звука получается при общем BER где-то до 1e-3. Причем разные биты в фрейме войсового кодека имеют разную чувствительность к ошибкам. Первое, что следует сделать – отсортировать биты в исходном фрейме на несколько групп по чувствительности к ошибке.

Информация в *.CELP кодеках передается в основном как (амплитуда, частота, фаза) импульсов. Эта информация обновляется раз в 5ms, причем предполагается что параметры меняются медленно. Рассмотреть символы (амплитуда, частота, фаза) как векторы, придумать схему векторного квантования. Ввести адаптивную коррекцию огибающей спектра для большей различимости векторов. Опять же, отсортировать биты на группы по BER после векторного квантования.

Далее, сопоставить группы битов по чувствительности к BER от кодека c группами по BER от канального декодера. Соответственно придумать раскладку битов по кадру. Применить правильно рассчитанное помехоустойчивое кодирование в тех группах битов, где требуется.

Синхронизацию предлагается устанавливать по преамбуле вначале соединения; потом поддерживать по границам между символами. В случае рассогласования откат на низкоскоростной режим, с последующим переустановлением. Также протокол должен как-то отрабатывать потерю кадров, плохое качество сотового радиоканала, и.т.д. и.т.п.
Построение подобной системы – техническая задача. В общем понятно как что делать, и что получится. Не сомневаюсь что кем-то уже сделано; но вряд ли реализуемо в студенческом или хоббистском варианте.
— Sfinx (06/01/2015 23:04)   
Мое сугубое IMHO – hermes это last choice путь, и если честно, как-то очень сомневаюсь в этом документе, особенно учитывая ньюансы AMR. Моя первая попытка реализации hermes даже для GSM была неэффективной, допускаю что что-то не учел или где-то ошибся. Да, в начале пути тоже анализировал jackpair сигнал и могу сказать, что наблюдаются блоки и поменьше длиной (в 10ms / 80 samples) – очень похоже на синхро-frame. У меня есть идея, по поводу того, какой принцип они использовали в своем модеме – как раз этим сейчас и занимаюсь ;) Просто праздники вывели из строя на не надолго ...
— gegel (06/01/2015 23:21, исправлен 06/01/2015 23:30)   
Однако их подход ограничен скоростями порядка 1200 bit/s.

Я был бы счастлив получить хотя бы 1200 через AMR475, который, к слову, применяется по умолчанию, судя как по моим личным экспериментам с GSM-бордами, так и по публикациям (причем часто жескто фиксирован).

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

К счастью, это уже сделано, и профессионально. Натовский стандарт MELPE1200 использует отсортированный по значимости порядок бит, а также свой FEC, заточенный под задачу, с восстановлением ошибок по предыдущим данным и "стиранием" заведомо искаженных, чтобы не портить Long-term. Смотрите исходный код.

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

Частично делают турки. Ссылка на диссертацию (на турецком) уже приводилась в начале темы, и еще их статья[link65].
Они передают 2 бита в energy, 4 бита в pitch и 10 бит в LPC (два вектора), насколько я понимаю, на 20mS символ: используется код GSM 06.10 для реализации Модулятора. Т.е. имеем всего 800bps.

Синхронизацию предлагается устанавливать по преамбуле вначале соединения; потом поддерживать по границам между символами.

С синхронизацией я решил вопрос по другому, по крайней мере с модемом по Kondoz. Причем идея пришла спонтанно, и не замечена в публикациях. Работает супер. Для этой цели я использую BER: или защищаю первые 12 бит 11-битным кодом Golay23 (оверхед 11 бит на блок, но с пользой: FEC), или использую внутренний BER кодека MELPE. После получения очередной порции сэмплов, выровнянных на символ, я считаю BER, как вроде бы это последний символ в блоке, используя предыдущие символы. Для блока с Goley23 количество ошибок будет от 0 до 3. И накапливаю BER в массиве для всех возможных лагов (по количеству символов в блоке). По получению количества символов в блоке я выбирая лаг с минимальным накопленным BER, и выдаю как блок, затем все сдвигаю на один блок.
Т.о. без никакой начальной последовательности, с любого места потока я синхронизирую с потерей максимум один блок. И это реально работает в С-коде на звуковых картах, проверено.
Что касается "тонкого" выравнивания на символ, я использую процедуру GridSelection из GSM06.10, эксплуатируя тот факт, что мои пульсы используют лишь каждую третью (или четвертую, пятую) сэмпл-позицию. Для псвевдоречи это не подойдет, но есть и другие идеи, как выравнять на границы символа.

Не сомневаюсь что кем-то уже сделано

Самое свежая работа Сапожникова[link74], но FullText у меня нет. Судя по публикациям, у них лучшие результаты в теме.


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


Но это реально напряжно, тем более я не в теме, все осваивал недавно, так что глубоких понятий нет. Буду ждать, может, Rowe убедит китайцев GPL-ить их модем, и таки попробую в свободное время соорудить hermes из подручных средств (CODEC2 etc.).


если честно, как-то очень сомневаюсь в этом документе

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

Гость (07/01/2015 01:42)   

Sci-Hub[link75] спешит на помощь, статья есть в LibGen: http://lib.gen.in/next/MTAuMTA...../sapozhnykov2012.pdf[link76]

Я ведь правильно Вас понял?
— ZAS (07/01/2015 01:48)   
Но это реально напряжно, тем более я не в теме, все осваивал недавно, так что глубоких понятий нет.


Хорошие книжки по аудиокодекам:
"Digital Speech" M. Kondoz.
"Digital Speech Processing" L. Rabiner.
Описаны общие принципы устройства речевых кодеков; и, главное, какие параметры как передаются, и почему так сделано.
Прочтение сьэкономит много труда и избавит от заведомо неправильных направлений проб и ошибок.

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


Вот множество примеров тупиковых направлений :)

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



Частично делают турки. Ссылка на диссертацию (на турецком) уже приводилась в начале темы, и еще их статья.
Они передают 2 бита в energy, 4 бита в pitch и 10 бит в LPC


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

С синхронизацией я решил вопрос по другому, по крайней мере с модемом по Kondoz. Причем идея пришла спонтанно, и не замечена в публикациях. Работает супер. Для этой цели я использую BER: или защищаю первые 12 бит 11-битным кодом Golay23


Классика. См. учебник Питерсона по кодам для исправления ошибок.

И накапливаю BER в массиве для всех возможных лагов (по количеству символов в блоке)


Почему бы и нет; хотя неэффективно по MIPS и по памяти, возможна ложная синхронизация, особенно при наличии ошибок.

//
Пожалуйста, не сочтите критику за наезд. Мне самому абстрактно интересна эта тема; и я с удовольствием помогу Вам.

Кстати, в ZAS Communicator, как Вы предложили, сделано отключение бутстрапа (чтобы редиректить в TOR) и еще много всяких улучшений по мелочи.

http://www.zas-comm.ru
— gegel (07/01/2015 11:45, исправлен 07/01/2015 11:47)   
Я ведь правильно Вас понял?

О, конечно! Спасибо за статью, и за библиотеку.


Как раз турки не используют векторное квантование; а Вы плаваете в основах.

По поводу основ не спорю, т.к. этой темой интересуюсь всего пару месяцев, какие тут основы? Но в статье[link65] на стр.269 (3 в pdf) в разделе "C. Design of Codebooks" вижу:


хотя неэффективно по MIPS и по памяти

По сравнению с MELPE оверхед при подсчете 180 раз Golay23 незначительный.
Для такого малого количества бит я использовал табличный метод
(код взят с FreeDV[link77]), память не расходуется.


возможна ложная синхронизация, особенно при наличии ошибок.

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


Пожалуйста, не сочтите критику за наезд.

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


Кстати, в ZAS Communicator

Обязательно посмотрю после релиза.

— ZAS (07/01/2015 19:12)   
возможна ложная синхронизация, особенно при наличии ошибок.

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


Вероятность, что случайное слово окажется словом кода Голея (23,12), равна 1/2^11.
То есть, на произвольных данных за 180 попыток такое слово найдется с вероятностью порядка 1/10; даже при отсутствии ошибок.


По сравнению с MELPE оверхед при подсчете 180 раз Golay23 незначительный.
Для такого малого количества бит я использовал табличный метод
(код взят с FreeDV), память не расходуется.


Код Голея – это примерно как 2 x 2 = 4. Кодер/декодер пишется за пол-часа.

http://www.zas-comm.ru
— gegel (07/01/2015 20:27, исправлен 07/01/2015 20:31)   
на произвольных данных за 180 попыток такое слово найдется с вероятностью

Вы неверно поняли идею. Постараюсь объяснить подробно. Допустим, у нас поток символов уже выровнян на границу символа. Каждый символ несет, скажем, 7 бит информации. Наша задача – выдать блок 98 бит (14 символов), т.е. выровнять на границу блока.


Используем 11 последних бит блока как Golay-код от 12 первых бит.
Создаем массивы char data[14*2] для принятых символов, и float ber[14] для накопленных усредненных значений к-ва ошибок. Также создаем счетчик полученных символов, он же – указатель на лаг (от 0 до 13).
После получения очередного символа пишем 7 бит его значения в data по счетчику+14 (во вторую половину). Предполагаем, что это последний символ в блоке, исходя из чего, обрабатываем полученный последний символ + предыдущие 13 в массиве data как блок: корректируем, считаем к-во ошибок (оно может быть от 0 до 3), и это к-во усредняем в массиве ber[значение счетчика=лаг]:


ber[c]=err+ber[c]*0.95; //можно и с целочисленной арифметикой,
где err – к-во скорректированных ошибок в защищенных 12 битах (0-3
для Golay23).


То же самое проделываем для каждого следующего полученного символа, увеличивая значение счетчика.
При достижении счетчиком значения 14 ищем минимальное значение в массиве ber[14], и, используя найденный индекс как лаг, выдаем наиболее корректный блок из data с нужным смещением.
Затем копируем вторую половину data в первую, сбрасываем счетчик и продолжаем для следующего блока (массив ber не стираем, продолжаем усреднять).
Т.о. с каждым новым блоком значение по индексу правильного лага в ber[] становится все меньше по сравнению с другими. И единичная ошибка блока на эту тенденцию не повлияет.


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

— ZAS (07/01/2015 21:22)   
Постараюсь объяснить подробно. Допустим, у нас поток символов уже выровнян на границу символа. Каждый символ несет, скажем, 7 бит информации. Наша задача – выдать блок 98 бит (14 символов), т.е. выровнять на границу блока.

Используем 11 последних бит блока как Golay-код от 12 первых бит.
Создаем массивы char data[14*2] для принятых символов, и float ber[14] для накопленных усредненных значений к-ва ошибок.


Понятно и логично. Тогда вероятность правильной синхронизации после приема первого же блока порядка 0.99, и схема будет в принципе работоспособна при BER до нескольких процентов.

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

добавил автоопределение инверсии сигнала в канале


Это можно было бы сделать, модифицировав тот же FEC код, который используется для синхронизации. Чтобы был не инвариантен к инверсии.

Ошибки у меня возникали из-за смещения позиции пульса кодеком посредине.


Насколько я понимаю, позиция пульса задается непосредственно каким-то количеством бит? Тогда можно разделить биты на "сильные" и "слабые" по BER. К слабым битам применить FEC.

http://www.zas-comm.ru
— gegel (07/01/2015 21:57)   
не инвариантен к инверсии

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

Да, я пробовал разные варианты. Например, так: фрейм 18+18 сэмплов, в нем два пульса, каждый в своей половине в 6-ти возможных позициях. Т.е. имеем 36 вариантов, это 5 бит. Плюс по биту на полярность каждого пульса. Т.е. 7 бит на 36 сэмплов, 1555 bps. Очень хорошая схема для GSM FR. Выравнивание на позицию пульса плюс/минус один – процедурой GridSelection, а затем выравнивание на 3 пульса – способом, описанным выше (по FEC).
Или другой вариант (я его пытался пихать через AMR475): один пульс на каждые 40 сэмплов в 8-ми возможных позициях (каждые 5 сэмплов). Пульс широкий (в три сэмпла, боковые по 0.5 от центрального). 800bps, если учитывать знак пульса. Проблема в том, что AMR-кодек посредине "размазывает" пульс, добавляя к нему след из синусоид. Искажается как знак, так и позиция. Кроме того, появляются артефакты в неожиданных позициях. Я пробовал различные способы детектирования позиции, но ошибки все равно значительные.
Разнородные биты – полярность пульса (1 бит) и позиция. Но вот какие из них "слабее", непонятно. Статистически явной закономерности так просто обнаружить не удалось.
— ZAS (07/01/2015 22:39)   
Проблема в том, что AMR-кодек посредине "размазывает" пульс, добавляя к нему след из синусоид. Искажается как знак, так и позиция. Кроме того, появляются артефакты в неожиданных позициях. Я пробовал различные способы детектирования позиции, но ошибки все равно значительные.


Чем более кодек приспособлен для речи, тем более он искажает сигналы, не похожие на речь. На импульсы накладывается реакция LPC фильтра. Можно попробовать компенсировать эту реакцию, представив ее как возбуждение LPC фильтра исходным импульсом. Выделив "звон" синусоид, рассчитать по нему коэффициенты фильтра. Отсюда найти исходное положение и величину возбуждающего импульcа.
Можно считать по максимуму правдоподобия: сделать на приемной стороне модель канала с таким же кодеком; пробовать разные позиции импульсов, найти позицию, в которой сигнал получается наиболее близким к принятому.
Такой приниматель оптимален; но возможно неприемлем по затратам MIPS.

http://www.zas-comm.ru
— gegel (08/01/2015 09:40, исправлен 08/01/2015 09:41)   

Я и сам думал использовать демодулятор на основе AMR475 для прохода AMR475. Но проблема в том, что кодек посредине не синхронизирован по границам символов, более того, из-за неточности частоты дискретизации модулятора и системы GSM сдвиг постоянно "плывет".


Отсюда найти исходное положение и величину возбуждающего импульcа.

В идеале сделать то же, что делает кодек: провести LPC-анализ фрейма, применить найденные коэффициенты в фильтре, выделить резидуальный сигнал, и в нем искать возбуждающий пульс. Пробовал, используя код GSM FR. Все хорошо, пока нет кодека посредине.
Еще есть идея. Раз кодек дописывает "хвост" синусоид к пульсу, основываясь на своей логике (хотя его там не должно быть, т.к. исходный сигнал, по идее, безголосый), то, может, есть смысл самому в модуляторе добавить эти затухаемые синусоидальные хвосты к пульсам. Так поведение кодека будет гораздо предсказуемее, и легче колдовать над алгоритмом демодулятора. Кроме того, если повезет, то частотой синусоиды в хвосте можно еще и пару бит кодить.

— ZAS (08/01/2015 18:46)   
Удивительно, как люди пытаются делать модем, не зная основ. Перед тем как применять чужие процедуры, не понимая смысла и свойств, освойте учебник, например Bernard Sklar "Digital Communications", и выше рекомендованные книжки по устройству кодеков.

Кодек (типа AMR или любой другой вариант CELP) пытается апроксимировать входной сигнал набором имеющихся у него вариантов кодирования. Апроксимация по психоакустической модели; возможности кодирования оптимизированы под статистику речевого сигнала. Cоответственно, импульсы будут преобразованы в некие речеподобные всплески. Причем, кодирование будет зависеть от предыстории. Cамое простое решение в этом случае – декодирование по принципу максимума правдоподобия. Раз импульс кодируется во всплеск, набрать библиотеку таких всплесков для разного взаимного положения импульсов. На приеме коррелировать сигнал с библиотекой, искать максимум корреляции, т.е. найти исходный сигнал. Такой приемник оптимален, но может быть труднореализуем по затратам памяти и MIPS.

Более правильный путь – исходно использовать речеподобные символы; про то уже писал. Cмотрите как в кодеках передаются параметры pitch, gain и innovation раз в 5ms и параметры LPC раз в 20ms. Соответственно сконструировать сигнал и оптимальный приемник для этого сигнала. Продумать схему FEC. Довольно много работы для квалифицированного специалиста, научная ценность = 0, практическая полезность под вопросом.

http://www.zas-comm.ru
— gegel (08/01/2015 20:04, исправлен 08/01/2015 20:08)   
Апроксимация по психоакустической модели

Книгу я пока не читал, но описание работы[link64] ACELP-кодеков (семейство AMR) зачитал до дыр и вник в каждую процедуру, что и Вам советую сделать. Т.е. я разобрался, как обрабатывается речевой сигнал на этапе кодирования, формируется адаптивная кодовая книга, как производится поиск, и как устроена фиксированная кодовая книга. Посмотрел все в референс-коде на С. Это гораздо более тонкие механизмы, чем

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

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

Это совсем другой путь, символьный алфавит из работ Сапожникова. Мы обсуждаем путь Kondoz at all. Принцип модема Kondoz не является универсальным, а использует инженеринг конкретного кодека (в оригинале – GSM EFR=AMR122) для достижения результата. И задача – сделать то же для AMR475, жертвуя битрейтом.


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

Это совсем другие вопросы, и частично я с Вами согласен.
В отличие от JackPair, реально работающие НАТО-вские системы p2p кодирования голосовой GSM-связи используют CSD[link78]
(см. например презенташку Fabio Pietrosanti[link79],) и это можно сделать за месяц, подключив в той же RaspberryPi недоверяемый китайский модуль Quectel M66[link80] тремя проводами (RX, TX, корпус) через UART2USB переходник (например, FTDI).
Таким образом, имеем полную гарантию, что из модуля никуда никто не проникнет в систему, а на модуль будет подаваться уже криптоданные для паблика. Тем более, имеется доступ к расширенному инженерному меню (можно видеть соты, силу их сигнала, считать расстояния, лочить частоту и соту, выбирать аудиокодек; и даже недокументированные штуки (если еще не выпилили – менять хоть на лету IMEI и Serial командами через тот же трехпроводный интерфейс).

— ZAS (08/01/2015 22:02)   
Книгу я пока не читал, но fileописание работы ACELP-кодеков (семейство AMR) зачитал до дыр и вник в каждую процедуру, что и Вам советую сделать.


Всегда пожалуйста. Конкретные вопросы welcome.

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


Вы разобрались в "как" на примере частного случая. Осталось разобраться в главном: почему и зачем так делается; каковы свойства используемых процедур. Заодно изучить принципы оптимального приема, методы синхронизации, теорию помехоустойчивого кодирования, и уметь делать в реальной практике. Ничего особенного, просто еще одно ремесло.


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

Это совсем другой путь, символьный алфавит из работ Сапожникова. Мы обсуждаем путь Kondoz at all.


Не существует разных путей чьего-то имени. Существуют технические решения разной степени сложности и оптимальности.
Предлагается математически корректное квазиоптимальное решение. Чем не устраивает?

Принцип модема Kondoz не является универсальным, а использует инженеринг конкретного кодека (в оригинале – GSM EFR=AMR122) для достижения результата. И задача – сделать то же для AMR475, жертвуя битрейтом.


Какие проблемы? Вы же во всем разобрались и вникли :)

Разные CELP-кодеки устроены по одному и тому же принципу; отличие в деталях. Поэтому сигнал в таких кодеках преобразуется примерно одинаковым образом. Очевидно что если информация проходит через низкобитрейтный CELP, то через высокобитрейтный пройдет тем более. GSM-FR вообще халява, а не кодек. Почти что прямая отцифровка.

реально работающие НАТО-вские системы p2p кодирования голосовой GSM-связи используют CSD.


Если есть доступ к цифровому каналу, задача тривиальна.

http://www.zas-comm.ru
Гость (09/01/2015 01:04)   

Ни чуть не более удивительно, чем наблюдать, как вы лезете в криптографию с собственным кустарным шифром, не зная основ современной криптографии (хотя бы на уровне книжки Bellare & Rogaway). Видимо, там где вы изучали кодеки, крипто не учат, бывший СССР всё ж таки, тяжёлое наследение.
— ZAS (09/01/2015 01:56)   
> Удивительно, как люди пытаются делать модем, не зная основ.


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


:) Верно подмечено.

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

Видимо, там где вы изучали кодеки, крипто не учат,


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

http://www.zas-comm.ru
Гость (09/01/2015 04:50)   

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


Современные криптографы не занимаются практическим криптоанализом.

Д[link81]о практического криптоанализа в открытом сообществе дело обычно не доходит, но иногда его всё-таки проводят.

Основные причины его проведения таковы:

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


Так толсто, впрочем, как всегда. Даннинг-Крюгер[link82] во всей красе. Даже боюсь спросить, кого вы считаете компетентным в криптографии. Мнение в FAQ — это как бы консолидированное мнение научного сообщества. Наверно, Шамир для вас был бы тоже некомпетентен.
— ZAS (09/01/2015 07:34)   
не вижу здесь людей, компетентных в криптографии.
не говоря уж об аргументированных ответах или содержательной критике.


Так толсто, впрочем, как всегда. Даннинг-Крюгер во всей красе.


Скажите хоть слово по делу, для разнообразия.

Даже боюсь спросить, кого вы считаете компетентным в криптографии.


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

Однако cлабый примитив можно усилить перестраховочными методами


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


Читая книжки и рассматривая разные конструкции, у меня сложилось впечатление, что большинство практически применяемых шифров основаны на отфонарных решениях. Видны заплаты против известных методов анализа и некоторые математические оценки; но настоящей теории мало. Это так?
Гость (09/01/2015 11:42)   

Unknown в т.ч. и это для вас делал, но вы же всё равно пишите

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


Серьёзных рекомендуемых шифров сейчас — пара штук, это TwoFish и Rijndael. По обоим есть серьёзные работы от их авторов, можно почитать.


Под настоящей теорией каждый своё понимает. Стараются основываться на теории сложности в той мере, в какой только можно.
— gegel (10/01/2015 12:20, исправлен 10/01/2015 12:21)   

To Sfinx:

но непонятно как они смогли получить набор коротких и уникальных ones

Нашел время вникнуть в работу Сапожникова,

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

Гость (10/01/2015 19:29)   

Для этого нужны годы на исследования вашей поделки. Кто их будет тратить?


Меньшинство из криптографов разрабатывает свои алгоритмы. Об этом написано в FAQ.


Тут не бывает любительского уровня понимания. Есть его присутствие (годы работы, вникание в тему, профильное образование и т.д.) и отсутствие.


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

В авиастроении так же. Можно на любительском уровне сказать, что можно улучшить в Boeing 737? Да так, чтоб сразу это пустить на production без дополнительных проверок, тестов, сертификаций «специально обученными людьми»? А если б можно было, полетели бы вы на самолёте собственной модификации? Но даже тут проще: однажды ваш самолёт грохнется, и всё ваше любительство вылезет наружу, а в крипто — это когда самолёты, казалось бы, летают, а через 20 лет вдруг выясняется, что все они упали, задним числом причём. Современное крипто потому такое и сложное, что страхует от будущих успехов в криптоанализе по-максимуму, а не оперирует только тем, что уже имеется.
— ZAS (10/01/2015 20:06, исправлен 11/01/2015 11:38)   


Для этого нужны годы на исследования вашей поделки. Кто их будет тратить?

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


> Разработать свой алгоритм, превосходящий другие.

Меньшинство из криптографов разрабатывает свои алгоритмы. Об этом написано в FAQ.

Скажите мне, как криптограф криптографу. Вы что-нибудь умеете? Пока одни слова, и все не по делу.
Не умеете – не мешайте другим.


> Криптография это практика. Должны быть осязаемые результаты.
В этом и состоит корень ваших заблуждений. Криптография — это пипец какая сложная теория. Поздно делать шифры на коленке из любительских соображений — это было позволительно году так в 1950-ом. Сейчас этим занимаются специально обученные люди.

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


В авиастроении так же.

Аналогия не аргумент. Или Вы специалист и в самолетостроении?


Можно на любительском уровне сказать, что можно улучшить в Boeing 737?

Да. В Boeing 737 можно сделать много технических улучшений. Однако он жестко зажат по ограничениям типа качество/цена, сертификация, патенты, логистика, обслуживание, бюрократический оверхед и пр.


Да так, чтоб сразу это пустить на production без дополнительных проверок, тестов, сертификаций «специально обученными людьми»? А если б можно было, полетели бы вы на самолёте собственной модификации?

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


Но даже тут проще: однажды ваш самолёт грохнется, и всё ваше любительство вылезет наружу, а в крипто — это когда самолёты, казалось бы, летают, а через 20 лет вдруг выясняется, что все они упали, задним числом причём. Современное крипто потому такое и сложное, что страхует от будущих успехов в криптоанализе по-максимуму, а не оперирует только тем, что уже имеется.

BTW, для любителей продаются наборы "собери самолет в гараже". Не Boeing конечно, а легкомоторный. Собирают и летают по 20 лет и более.


http://www.zas-comm.ru

Гость (10/01/2015 20:33)   

Далеко не всегда. Пример этому[link83] я наблюдаю даже на собственных разработках. Ни один спец не может сразу сказать «да, взлетит» или «нет, не взлетит». Часть проблем я сам вижу (пока непохоже, чтобы указали на какие-то принципиально новые), но готового ответа нет.


Не переживайте за меня.


Не мешать вам фричить на сайте?


Они учились очень много и долго в нужном направлении, речь идёт о временах порядка 10 лет на fulltime. Даже среди тех, кто номинально всё это прошёл, большинство так и не становятся специалистами.


А аргумент аналогия или нет, определяется моим личным опытом в самолётостроении? Вот это разворот в логике.


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


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


Криптография от младшей сестры тоже есть.
— unknown (10/01/2015 20:46, исправлен 10/01/2015 20:51)   

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


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

— SATtva (11/01/2015 11:46, исправлен 11/01/2015 11:47)   

Из готовых деталей по готовой инструкции (которые делают и пишут специалисты), а потом ещё в гараж приходит инспектор из FAA или его аналога, чтобы проверить правильность сборки, иначе аппарат не получит годность к полётам. В итоге "самолёт в гараже" — штука ближе к протоколу из готовых примитивов, который Вам даже не позволят использовать in the wild, пока специалист не проверит, не напортачили ли Вы где-нибудь. Вот такие дела с этими аналогиями.

— ZAS (06/02/2015 00:22)   
Вы меня заинтриговали. Интересная проблема.

Попробовал кодек, именно вышеупоминавшийся AMR 4.75. Из-за малого битрейта кодек имеет длинный переходный процесс. Сигнал на выходе становится квази-стационарным после установления в течение 2-3 фреймов кодека. Декодировать установившееся состояние намного проще, чем пытаться апроксимировать переходный процесс. Соответственно, символы должны иметь длину порядка 3-4 фреймов; решение о принятом символе принимается по установившейся части; предполагается что модем несинхронизирован относительно кодека.
В качестве параметров берем величину основного тона, амплитуды и фазы первых cкольки-то гармоник, и некий набор параметров, характеризующий форму спектра. Например, кепстральные коэффициенты. Символы дополнительно придется подкорректировать по таблице относительно высоты тона. По оценкам, должна получаться скорость порядка 1/4 от cкорости кодека. Многое тут является вопросом оптимизации; например, длина символа vs величина основного тона vs дискретность амплитуд/фаз. Символы переменной длины и/или с переменным числом битов на символ, да.
Коррекция, возможно, окажется специфической именно для AMR 4.75; для других кодеков и даже для других режимов AMR коррекция будет другой. Если удастся синхронизировать модем и кодек, то возможен дополнительный выигрыш где-то до половины битрейта. Однако потребует обратного канала для передачи ошибки синхронизации на передающую сторону.
Примерно так.
— gegel (06/02/2015 21:24)   
Вы меня заинтриговали. Интересная проблема.

Ваш пост в 00:22, а в 23:42 получил письмо с тем же тезисом от Дэвида Ровэ. Астрал? Пишет, что Джефри с JackPair молчит, и предложил консультировать в разработке модема. Мои знания в предметной области слишком поверхностны, но попробую, буду сообщать о рекомендованном направлении работы.

символы должны иметь длину порядка 3-4 фреймов
Длина фрейма 20 мсек. Символ в 60-80 мсек должен нести 70-100 бит информации для получения 1200bps. Боюсь, извлечь их более чем нереально. Поэтому придется корячится с более короткими символами.
Просмотрите внимательно работу Сапожникова (ссылка есть выше), там приведены различные варианты и результаты SER.

Если удастся синхронизировать модем и кодек

А это свежая и оригинальная мысль, ранее никто об этом не упоминал. Действительно, используя обратный канал, теоретически возможно провести тренинг и синхронизировать модулятор и демодулятор с кодеком в канале. Но тут есть проблема: в канале может быть и два кодека, несинхронных между собой. В таком случае сложность задачи резко увеличивается вплоть до невыполнимости.
— ZAS (06/02/2015 23:16)   
получил письмо с тем же тезисом от Дэвида Ровэ. Астрал?


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

Символ представляет собой периодический waveform с периодом в диапазоне допустимых лагов. На приеме выделяем период, усредняем несколько периодов в установившейся части в один период, далее Фурье на периоде, потом коррекция в зависимости от периода. Длину символа и/или количество битов на символ в зависимости от периода нужно оптимизировать. Получается простой эффективный алгоритм. Возможно, лучше не усреднять, а взять последний из периодов.

Символ в 60-80 мсек должен нести 70-100 бит информации для получения 1200bps. Боюсь, извлечь их более чем нереально. Поэтому придется корячится с более короткими символами.


Для 1200 получается что-то порядка одного-двух битов на отсчет сигнала по t (или по F) на приеме. На первый взгляд незапредельно. Нужно смотреть, какого порядка получаются флуктуации от периода к периоду, и в зависимости от сдвига по времени между модемом и кодеком.

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


Просмотрите внимательно работу Сапожникова


Имеется в виду "Data Modem For GSM voice channels"? Так себе; пробуют шаманские методы.

Если удастся синхронизировать модем и кодек


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

в канале может быть и два кодека, несинхронных между собой.


Тандеминг кодеков приводит к cущественному ухудшению качества. В грамотно построенных системаx стараются избегать.
— gegel (07/02/2015 00:55)   
намного проще анализировать установившееся состояние

Если я верно Вас понял, то идею можно сформулировать так: вместо того, чтобы распределять биты равномерно по времени, группируем их плотнее, но в периоде пускаем несколько одинаковых пакетов подряд. С каждым новым повтором состояние кодека стабилизируется, и таким образом, последний пакет допускает более тщательный анализ, и извлечение всех битов фрейма.
Тоже свежая идея, во всяком случае, об этом речь нигде ранее не шла. Но надо бы попробовать, получим ли мы существенный выиграш от стабилизации (повышение точности передачи), превосходящий проигрыш от уплотнения бит (повышения требований к этой точности).
— ZAS (07/02/2015 02:42)   
Если я верно Вас понял, то идею можно сформулировать так: вместо того, чтобы распределять биты равномерно по времени, группируем их плотнее, но в периоде пускаем несколько одинаковых пакетов подряд. С каждым новым повтором состояние кодека стабилизируется, и таким образом, последний пакет допускает более тщательный анализ, ие извлечение всех битов фрейма.


Примерно так. Период повторения в диапазоне основного тона кодека. Количество повторов в зависимости от периода. Период может быть переменным, модулированным в соответствии с данными. И даже должен быть, чтобы открыть VAD.

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


Где-то должен быть оптимум бит/c в зависимости от периода/количества повторов.

Неочевидно, каким образом промодулировать повторяемый участок. Простым решением было бы DMT на периоде основного тона.
— gegel (07/02/2015 11:51, исправлен 07/02/2015 12:16)   
Имеется в виду "Data Modem For GSM voice channels"?

Не совсем, судя по названию. Я имел в виду работу 2012 года (ссылку на публикацию любезно предоставил Гость в теме выше) с подробным описанием алгоритма синтеза псевдоречевых символов для конкретного кодека и тщательным анализом SER для символов различной длины при конкретном битрейте. Весьма интересно.


Vitaliy V. Sapozhnykov·Kurt S.Fienberg A Low-rate Data Transfer Technique for Compressed Voice Channels



— Sfinx (08/02/2015 15:50)   
Метод Sapozhnykov'a ни фига не работает для AMR, как и наработки Kondoz'a – эти хлопцы работали только с GSM, и результат получили, скажем, неважнецкий. ZAS все верно сказал, кстати, на этом принципе построен и jackpair, по крайней мере моя реализация звучит чертовски похоже ;) Синхронизироваться с кодеком нет смысла, так как посередине канал может быть перекодирован несколько раз (попробуйте позвонить с одного GSM оператора на другой, особенно если между абонентами пару тыщ км), соответственно нет смысла подбирать настройки под каждый кодек. Train sequence нужна только для одного – если собираетесь кодировать еще и энергию сигнала – это может добавить 2-3 бита на символ максимум.
— ZAS (08/02/2015 19:59)   
Емкость канала определяется неопределенностью сигнала на выходе. Неопределенность вызвана двумя причинами: несинхронизированностью модема и кодека и зависимостью выхода кодека от предыстории. Плюс к тому потери пакетов и битов, но их пока не рассматриваем.

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


Cинхронизация модема с кодеком была бы большим выигрышем; т.к. в пределе можно было бы точно воссоздать все параметры. В общем понятен алгоритм, как установить начальную синхронизацию и как потом поддерживать. Насколько реальна проблема с многократными перекодировками?

Train sequence нужна только для одного – если собираетесь кодировать еще и энергию сигнала – это может добавить 2-3 бита на символ максимум.


Чтобы кодировать амплитуды, достаточно нормировать сигнал к средней энергии.

Метод Sapozhnykov'a ни фига не работает для AMR, как и наработки Kondoz'a


Отож. Радиолюбители :)


http://www.zas-comm.ru
— gegel (08/02/2015 20:24)   
кстати, на этом принципе построен и jackpair

Какой конкретно из обсуждаемых выше принципов Вы имеете в виду?
Если не секрет, какой общий принцип Вашей реализации?

Насколько реальна проблема с многократными перекодировками?

К сожалению, реальна, причем даже с одним оператором, как ни странно.
Я использую две платы Quectel Kit в инженерном режиме. На исходящей фиксирую, скажем GSM FR, и включаю сообщения о кодеке и его смене в терминал. Входящая сторона по прежнему использует назначаемый по умолчанию LOW BITRATE AMR.
Не совсем понятна логика разработчиков, но это характерно для сети в целом, и упоминания о двух кодеках (причем даже одинаковых) в тандеме встречаются во многих работах, шведы для чистоты эксперимента даже в своем фреймворке использовали двойное перекодирование одинаковым кодеком, вводя посредине случайную задержку для имитации асинхронности.
Гость (09/02/2015 00:48)   

По-русски это называется не "ёмкость" (capacity), а "пропускная способность".
— Sfinx (09/02/2015 07:55)   
Перекодирование имеет место быть, в частности между СНГ операторами, так как они стыкуются все теми же E1/VoIP линками между собой, отсюда и транскодинг. Я так понимаю, AMR passthrough это устаревшее оборудование просто "не умеет".
Принцип модема – генерация и распознавание псевдо-речевых звуков, данные кодируются pitch и формантными частотами. Есть еще мысль добавить пару бит на энергию, но подозреваю, что AGC может эту идею запороть на корню.
— ZAS (09/02/2015 19:36)   
Насколько реальна проблема с многократными перекодировками?

К сожалению, реальна,


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

Принцип модема – генерация и распознавание псевдо-речевых звуков, данные кодируются pitch и формантными частотами.


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

Есть еще мысль добавить пару бит на энергию, но подозреваю, что AGC может эту идею запороть на корню.


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

http://www.zas-comm.ru
— gegel (09/02/2015 20:55, исправлен 09/02/2015 21:22)   
Принцип модема – генерация и распознавание псевдо-речевых звуков, данные кодируются pitch и формантными частотами.

Ровэ после знакомства с проблемой независимо предложил в точности такой же подход.


Интересно, сколько бит удается уложить в кадр.

И какая длина фрейма предполагается?


Ровэ на вскидку предлагает пробовать 9 бит на LPC (3 спектральных пика в 8 возможных позициях каждый) и 5 бит на pitch (в диаппазоне лагов 20-140 сэмплов), и длину фрейма 40-100mS. Обещает помочь с практической реализацией фремворка для модулятора/демодулятора с гибкими настройками параметров для экспериментов с разными типами транскодеров.

— ZAS (09/02/2015 22:29)   
Ровэ на вскидку предлагает пробовать 9 бит на LPC (3 спектральных пика в 8 возможных позициях каждый) и 5 бит на pitch (в диаппазоне лагов 20-140 сэмплов), и длину фрейма 40-100mS.


Пессимистично.

По-хорошему, количество/положение спектральных пиков, и, возможно, длину символа сделать переменными в зависимости от pitch. Сигнал в вокодере устанавливается по-разному.

Пробовал DMT на периоде основного тона при длине символа 60...80ms через AMR-4.75. Порядка 800 bit/s, без транскодинга и с настройкой под кодек. Возможно cделать лучше; но становится тонко и сложно.
— gegel (27/08/2018 14:38)   
Не прошло и 4-х лет, как дошли руки до практической реализации девайса: гарнитура для стойкой защиты речевого канала аналоговых УКВ радиостанций и мобильных телефонов на STM32F446RE (прототип на отладочной плате Nucleo64):

https://github.com/gegel/jackpair

Режимы работы: PTT (полудуплекс) или полный дуплекс.
Кодек: MELPE-1200+NPP7, переделанный на 800bps и адаптированный к Cortex M4.
Модемы: BPSK для VHF радио, PLS (аналог модема Кондоза) для GSM/AMR.
Криптография:
– симметричная – Shake-128 на базе Keccak800, синхронизация CTR в речевых паузах;
– ассиметричная – SPEKE на X25519 (аутентифицированная DH с нулевым разглашением общего секрета), использует Hash2Point на базе Elligator2.
– TRNG (сидирование) – сборщик энтропии от изменения младшего бита результата АЦП шума резистивного делителя напряжения питания, блочный частотный тест до достижения приемлемой статиcтики накопителя.

Все элементарные криптографические примитивы реализованы в виде неоптимизируемого кода на ассемблере для Cortex M4 архитектуры, с учетом минимизации утечек по побочным каналам
(постоянны по времени выполнения).
— unknsecured (04/10/2018 11:28)   
gegel, ты где был?! Мы всерьез думали, что тебя либо посадили/убили, либо вербануло СБУ с запретом общаться на эти темы с посторонними! Расскажи, что было эти 4 года с учетом изменений в твоей стране проживания? :)
— gegel (08/10/2018 19:08)   
Приветствую!
Не, ну не так все плохо :)
Просто сменил работу, не до форумов было.
А что касается изменений, то особых я не увидел – более или менее укладываются в глобальную тенденцию. Политикой я не балуюсь, в горячих точках никогда не был, как и Вы, вижу только по телевизору. К теме у меня только академический интерес.

Смотрю, Вас тоже давно не было слышно. И вообще, впечатление такое, что ресурс мертв.

Я больше читаю конфу modern crypto и уточняю необходимое в личной переписке.
Так, elligator2 (Hash2Point для X25519) с использованием инверсного квадратного корня – от Mike Hamburg
(paper[link84])
а элементарная математика кривой X25519 на ассемблере для Cortex M4 – получена от Bjorn Haase (public domain), тоже ранее не публиковалась.
(paper[link85])
Аутентификация с нулевым разглашением, позволяющая использовать короткий общий секрет, также обсуждалась на modern crypto, патент на протокол SPEKE истек в этом году.
Ну, и, собственно, кодек MELPE – адаптация под архитектуру M4 до режима реального времени тоже не было в открытом доступе. Так что, возможно, будет интересно. Хотя больше таким интересуются китайские друзья...
Если что, мой PGP имеется на серверах, да и у меня где-то был Ваш отпечаток (жаль, теперь все убрали с форума).

Ссылки
[link1] http://www.bandwidthco.com/whitepapers/netforensics/crafting/Wifi%20Advanced%20Stealth.pdf

[link2] http://naukainform.kpi.ua/CriMiCo/Crimico/013_016.pdf

[link3] http://hadmernok.hu/2013_1_nemetha.pdf

[link4] http://doc.utwente.nl/69796/1/commsmagOct09.pdf

[link5] http://rf.harris.com/media/Radio%20Comms%20in%20the%20Digital%20Age%20-%201_tcm26-12947.pdf

[link6] http://www.di.unisa.it/~ads/corso-security/www/CORSO-9900/oracle/skeme.pdf

[link7] https://www.dmi.unict.it/diraimondo/web/wp-content/uploads/papers/deniability-ake.pdf

[link8] http://n1su.com/fdmdv/

[link9] http://code.google.com/p/curve25519-donna/

[link10] http://cr.yp.to/ecdh/curve25519-20060209.pdf

[link11] https://en.wikipedia.org/wiki/Multiple_frequency-shift_keying

[link12] https://en.wikipedia.org/wiki/Quadrature_amplitude_modulation

[link13] http://www.esiee.fr/~chmaysst/RadioElektronika_finalpaper.pdf

[link14] https://www.cs.cmu.edu/~rwh/courses/llsec/slides/private-auth.pdf

[link15] http://research.microsoft.com/en-us/um/people/klauter/security_of_kea_ake_protocol.pdf

[link16] http://www.infsec.ethz.ch/research/dh_tamarin_csf.pdf

[link17] http://www.w1hkj.com/FldigiHelp-3.21/html/modems_page.html

[link18] http://www.defcon.org/images/defcon-13/dc13-presentations/DC_13-Tanner-Smith-Lareau.pdf

[link19] https://groups.google.com/forum/#!forum/digitalvoice

[link20] http://www.rowetel.com/blog/?p=2433

[link21] http://www.rowetel.com/blog/?p=3125

[link22] http://www.moetronix.com/ae4jy/pathsim.htm

[link23] http://www.w7ay.net/site/Applications/cocoaPath/

[link24] http://www.udxf.nl/Some%20Digimodes%20through%20different%20Channels.pdf

[link25] https://www.youtube.com/watch?v=qxTsadG3mAM

[link26] http://www.eurasip.org/Proceedings/Eusipco/Eusipco2005/defevent/papers/cr1512.pdf

[link27] https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/src/test/test_crypto.c

[link28] http://cr.yp.to/highspeed/naclcrypto-20090310.pdf

[link29] http://www.pgpru.com/comment80949

[link30] http://www.daemon.de/blog/2014/04/25/351/code-review-lulzlabs-radio-airchat/

[link31] http://skorina.org/projects/2012/06/26/long-range-laser-communication

[link32] https://en.wikipedia.org/wiki/RONJA

[link33] http://www.pgpru.com/comment80959

[link34] http://w1hkj.com/download.html

[link35] http://v3solar.com/wp-content/uploads/2014/05/LaDueIEEEpaper.pdf

[link36] http://www.diva-portal.org/smash/get/diva2:21981/FULLTEXT01.pdf

[link37] http://web.itu.edu.tr/~orssi/thesis/2012/SercanTuncay_bit.pdf

[link38] http://www.pgpru.com/forum/anonimnostjvinternet/voiceovertor

[link39] http://www.pgpru.com/comment74717

[link40] http://www.pgpru.com/comment80996

[link41] https://www.kickstarter.com/projects/620001568/jackpair-safeguard-your-phone-conversation

[link42] https://www.schneier.com/blog/archives/2014/09/jackpair_encryp.html

[link43] http://www.pgpru.com/comment80968

[link44] http://www.pgpru.com/comment80945

[link45] http://www.pgpru.com/comment80950

[link46] http://www.pgpru.com/comment80964

[link47] http://www.pgpru.com/comment80975

[link48] http://www.pgpru.com/comment84026

[link49] http://freedv.org/tiki-index.php

[link50] http://www.pgpru.com/comment84348

[link51] http://www.pgpru.com/comment84361

[link52] http://www.qtc.jp/3GPP/Specs/GSM_GERAN/0620-801.pdf

[link53] http://www.3gpp.org/FTP/Specs/2014-03/Rel-11/26_series/26090-b00.zip

[link54] http://www.alsa-project.org/main/index.php/Matrix:Module-aloop

[link55] http://unix.stackexchange.com/questions/127567/recording-audio-from-web-based-audio-player-using-alsa-loop-device

[link56] http://jackaudio.org/faq/pulseaudio_and_jack.html

[link57] http://www.pgpru.com/biblioteka/rukovodstva/setevajaanonimnostj/prodvinutoeispoljzovanietorvunix/razdeljnoeispoljzovanietorbrowserssistemnymtoriprozrachnajatorifikacija

[link58] http://0pointer.de/blog/projects/when-pa-and-when-not.html

[link59] http://lac.linuxaudio.org/2010/download/lennarts-talk-auf-der-lac-2010.pdf

[link60] http://www.3gpp.org/ftp/specs/latest/Rel-11/26_series/26268-b10.zip

[link61] http://ru.wikipedia.org/wiki/ЭРА-ГЛОНАСС

[link62] http://www.etsi.org/deliver/etsi_en\300900_300999\300961\08.01.01_60\en_300961v080101p.pdf

[link63] http://www.etsi.org/deliver/etsi_en\300900_300999\300969\08.00.01_60\en_300969v080001p.pdf

[link64] http://www.etsi.org/deliver/etsi_ts\126000_126099\126090\09.01.00_60\ts_126090v090100p.pdf

[link65] http://www.emo.org.tr/ekler/acb89c94a3adb43_ek.pdf

[link66] http://publications.lib.chalmers.se/records/fulltext/72428.pdf

[link67] http://www.wseas.us/e-library/conferences/2008/mexico/cisst/33-CISST.pdf

[link68] http://www.pgpru.com/comment85442

[link69] http://www.pgpru.com/comment85453

[link70] http://www.news.cs.nyu.edu/~aditya/Research_files/dhananjay-mobicom10-hermes.pdf

[link71] http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5432651&url=http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5432651

[link72] http://www-common.esiee.fr/download/recherche/fic_publication/These_CHMAYSSANI%20.pdf

[link73] http://www.nativitysoftwares.com/downloads/A%20Lower%20Capacity%20Bound%20of%20Secure%20End%20to%20End%20Data%20Transmission%20via%20GSM%20Network.pdf

[link74] http://link.springer.com/article/10.1007/s11265-011-0594-x#page-1

[link75] http://sci-hub.org/

[link76] http://lib.gen.in/next/MTAuMTAwNy9zMTEyNjUtMDExLTA1OTQteA==/sapozhnykov2012.pdf

[link77] https://github.com/freedv/codec2/blob/master/src/golay23.c

[link78] http://ru.wikipedia.org/wiki/Circuit_Switched_Data

[link79] http://www.slideshare.net/fpietrosanti/2009-voice-security-and-privacy-security-summit-milan

[link80] http://www.soselectronic.cz/a_info/resource/Quectel/Quectel_M66_GSM_Presentation_V1.0.pdf

[link81] http://www.pgpru.com/faq/kriptografijaobschievoprosy#h37247-13

[link82] https://ru.wikipedia.org/wiki/Эффект_Даннинга-Крюгера

[link83] http://www.pgpru.com/comment85450

[link84] https://elligator.cr.yp.to/elligator-20130828.pdf

[link85] https://raw.githubusercontent.com/gegel/jackpair/master/docs/343.pdf