РегистрацияАнонс идеи аппаратного скремблера
Параллельно работе над 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 является военным стандартом и его рефференс-код тщательно проверен на предмет выполнения произвольного кода при подаче на вход фатальных битовых последовательностей. Любая манипуляция входными битами без знания ключа шифрования может вызвать лишь искажение голоса вплоть до получения шума, но не нарушение криптографии в целом. Преимущество данного подхода очевидно: спонтанное искажение единичных битов приведет лишь к искажению голоса, но не к полному выпадению неаутентифицированных блоков.
комментариев: 393 документов: 4 редакций: 0
Как и обещал, немного поэкспериментировал, отчитаюсь.
Во-первых, на другом форуме меня, как школьника, ткнули носом ETSI- стандарт для уже разработанного модема с подробным описанием
и открытым
исходным кодом для тестироания). Стандарт разработан для системы eСall, обязательной к внедрению до 2015 года всеми мобильными операторами и предусматривает возможность передачи экстренной информации (пакет в 140 байт) максимум за 4 сек через любой акустический канал связи, включая все комбинации мобильных операторов. Русский сегмент (совместимый) – Эра-Глонасс.
GSM-FR, 
GSM-HR и 
семейства AMR кодеков.
Я не пожалел времени и очень внимательно изучил принцип модема и исходный код, сравнил с теоретическими работами, цитируемыми выше, а также тщательно вник в алгоритмы работы
В результате стало ясно, что, во первых, предлагаемый для 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-гарнитуру, получится весьма защищенный универсальный цифровой скремблер.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 393 документов: 4 редакций: 0
Ну, я с Вами прямо в параллель работаю :) Даже OnionPhone пока приостановил, так меня заинтересовала идея модема.
тут. Я тоже прошел это, используя код GSM-FR для синтеза. 
работа. В отличие от остальных, авторы сравнили 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...
То, что я и предполагал. И, боюсь, размер вашей кодовой книги после определенного предела вовсе не будет играть роль (не забывайте про кодек посредине). Надеюсь как-то вырваться из плоскости мышления и найти какое-то оригинальное решение (если это вообще возможно теоретически).
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, найти соответствующие кодеки – не проблема
комментариев: 393 документов: 4 редакций: 0
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.
Я пробовал FDMDV модуляцию (проект FreeDV) и 4QAM (по статье французов). Уверенно проходит только EFR, но даже на FR рубится. Пульсами же у меня получилось реально выжать почти 1600 на EFR и FR, используя вариант схемы, рекомендованной шведом: с одним пульсом в 6-ти возможных позициях на 18 сэмплов (шаг 3 сэмпла) при очень низком BER.
Насколько я понял из обзора публикаций, проблема сложная и остается нерешенной. Подтверждение: серьезный проект модема для eCall использует все же Суррейский путь (только вместо чистого пульса используется пульсообразная вейформа с затуханием, наверное, для обеспечения лучшей корреляции с 4-мя сдвинутыми образцами и возможности накопления при повторных передачах). На месте Джефри, если бы у меня получилось то, что он декларирует в JackPair (якобы проходит и AMR475, и даже HR), я бы скорее срубил академическую работу и патент, чем собирал 50K на кикстартере.
Это радует, но, наверное, я не там искал. MELPE600 – пока лишь мечта для меня.
LPC коэффициенты в кодеках обычно передаются в виде LSP. Для лучшего сжатия передается не сами LSP, a нечто вроде вектора разности LSP относительно предыдущего фрейма. Предполагается, что в реальном арречевом сигнале LPC изменяется медленно по сравнению с фреймрейтом. Вектор разности кодируется по кодебуку, отдающему предпочтение малым изменениям (нечно вроде логарифмической зависимости + отрихтовано по психоакустике). В результате LPC данные ужимаются до 16...24 бит на фрейм, то есть порядка килобита в секунду и менее. На приемной стороне LPC часто интерполируют вдоль фрейма, чтобы не было резких скачков.
Для передачи данных я бы попробовал использовать не LPC, а кепстральные коэффициенты или просто вектор распределения энергии по полосам.
Дело обстоит не совсем так. На передающей стороне кодек пытается закодировать сигнал таким образом, чтобы минимизировать ошибку между входным сигналом и синтезированным сигналом (Analysis by Synthesis, AbS). Ошибка измеряется относительно психоакустической модели. Синтезированный сигнал представляет собой сумму вкладов кодебуков, лагов, гейнов и LPC. Ищется оптимальная комбинация всех параметров, путем перебора. Перебор ускоряют разными евристиками, cтатистиками, оптимизациями и прочими халявно-отфонарными методами. Так что параметры оказываются cущественно взаимно завязанными, и к тому же зависящими от предыстории.
http://www.zas-comm.ru
комментариев: 393 документов: 4 редакций: 0
Именно mfcc+dwt Sfinx и пытается использовать. А использование спектральных полос, наверное, имелось в виду в неоднократно цитируемой здесь
шведской работе: 5.4.2 Sinusoid Waves. Автор не использовал данный путь из-за корреляционного демодулятора, не подходящего для этой задачи. Но при использовании других типов демодуляции (спектрального анализа) предполагает перспективность подхода.
Вообще, выбор способа демодуляции может существенно влиять на битрейт. Например, в eCall-модеме модулятор выдает табличную 16-сэмпловую вейформу с центральным пиком и затуханием, сдвигая ее по кольцу так, чтобы центральный пик был в одной из 4-х позиций. Демодулятор коррелирует сигнал с 4-мя паттернами и выбирает лучший. В процессе тестирования я случайно остановил программу и, посмотрев отладчиком на массив сэмплов, обнаружил, что всегда могу определить позицию центрального пульса "на глаз". В результате применил другую технику демодуляции: просто ищу максимальный и минимальный сэмпл среди 16, а также среднее значение. Затем смотрю, какой из экстремумов больше отличается от среднего (пульс может быть как положительный, так и отрицательный). Его сэмпл-позицию делю на 4, получаю трехбитовый результат (полярность + 2 бита позиции). В итоге BER неожиданно получился меньше, чем в оригинальном демодуляторе, причем при гораздо меньших вычислениях.
Вот еще
иранская работа, где используются псевдоречевые символы длиной в 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, но куда-то пропали. Подтвердил сложность проблемы, высказал свою заинтересованность и обещал помочь в работе.
Ой-ой-ой. Честно говоря, огорчает радиолюбительский подход, в том числе и в цитируемых здесь работах.
Источник псевдоречи описан в ITU-T P.50: http://www.itu.int/rec/T-REC-P.50-199909-I/en
комментариев: 393 документов: 4 редакций: 0
Честно, я и сам в замешательстве. Но есть объективная реальность: усредненный показатель BER. Это пример того, когда тупые решения дают неожиданное и плохо объясняемое преимущество перед академическими. Профессионал даже в страшном сне не стал бы и пробовать это. Наверное, в этом суть радиолюбительства.
комментариев: 9796 документов: 488 редакций: 5664
[offtop]
Из темы вырисовывается интересный пример.
Любительство хорошо, когда можно показать принцип "just works". Это много где работает, где результат нагляден (связь есть / связи нет) и нет угрозы отдалённых негативных последствий (что-то не учли и дорогостоящий спутник в критический момент упал, реактор взорвался, лекарство лечит и внезапно калечит). Вот в криптографии — всё наоборот, принцип "just works" не работает, отдалённые последствия тоже труднопрогнозируемы, поэтому там к любителсьтву относятся плохо, особенно в фундаментальной криптографии.
Ещё интересно, когда тема при поверхностном знании кажется лёгкой — вот сейчас сядем и изобретём, но в процессе всплывает куча подводных камней и проект не взлетает. Те, кто не в курсе этих подводных камней разработки думают, что «власти скрывают» и не дают изобретать намеренно.
[/offtop]
комментариев: 393 документов: 4 редакций: 0
Кстати, ZAS, по идее больше чем кто либо, видился как сторонник таких новаций. Наверное, концепт поменялся, раз критикует какие-никакие, но академические работы, цитируемые в теме. Ну, тогда ждем реальных рекомендаций и ссылок.
Пусть потери пакетов и битов в канале нет. Тогда должно быть возможно при разумных вычислительных затратах пропустить через канал поток полезных данных примерно до половины битрейта кодека (где-то треть-четверть должно проходить без особых проблем).
Предполагаем гибридный кодек (какой-то из вариантов CELP). Тогда информация в основном передается через позицию и амплитуду импульсов с частотой обновления 10ms, и меньшая часть информации через огибающую спектра с частотой обновления 40ms.
В канале есть динамические искажения вызываемые perceptual enhancement на приемной стороне; их должно быть возможно скомпенсировать; но тогда придется тренировать компенсатор под конкретный режим конкретного кодека.
За основу передатчика в канал можно взять декодер от любого низкоскоростного CELP кодека, за основу приемника – кодер от того же кодека. Подрихтовать приемник и передатчик. На передающей стороне удлиннить фреймы и субфреймы. Исследовать проходимость различных комбинаций параметров; выбрать полезные, убрать слабые. Проанализировать поток данных на приемной стороне на предмет BER каждого отдельного бита в каждом параметре. Построить многоуровневую схему коррекции неравномерного распределения ошибок чтобы выровнять BER к заданной целевой величине.
Cделать адаптацию скорости применительно к качеству конкретного канала и кодека.
В общем много разных вещей можно сделать и попробовать. Вырисовывается проект на пол-года-год до построения практического модема; плюс год на обкатку. Задача для специалиста, требующая адекватного финансирования.
Перспективы сомнительны; применение ограничено. Видимо, поэтому предлагаемые работы находятся на уровне студентов и радиолюбителей. Возможно, более простой путь – модификация софта, т.е. создание криптофонов.
комментариев: 9796 документов: 488 редакций: 5664
Вот и у меня было такое подозрение, скорее согласен с оценкой. Может она даже более оптимистичная, чем реалистичная.
комментариев: 393 документов: 4 редакций: 0
Тут не совсем согласен: например, проект eCall. И, учитывая масштаб этого проекта, срок разработки (с 2008 года), уровень исследований и финансирования, понятно, что не стоит и пытаться самому что-то сделать лучше. После компиляции их исходников и тестирования я понял, что это и есть предел. Но тут появилось несколько китайцев со своим JackPair и объявили, что сделали модем на порядок лучше. И на сколько это реально, как думаете? Если рассуждать трезво, все больше и больше думаю, что это фейк.