id: Гость   вход   регистрация
текущее время 14:42 28/03/2024
Автор темы: gegel, тема открыта 24/06/2014 23:21 Печать
Категории: криптография, инфобезопасность, протоколы, защита телефонной связи
http://www.pgpru.com/Форум/ПрактическаяБезопасность/АнонсИдеиАппаратногоСкремблера
создать
просмотр
ссылки

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

Параллельно работе над 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 является военным стандартом и его рефференс-код тщательно проверен на предмет выполнения произвольного кода при подаче на вход фатальных битовых последовательностей. Любая манипуляция входными битами без знания ключа шифрования может вызвать лишь искажение голоса вплоть до получения шума, но не нарушение криптографии в целом. Преимущество данного подхода очевидно: спонтанное искажение единичных битов приведет лишь к искажению голоса, но не к полному выпадению неаутентифицированных блоков.



 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии
— ZAS (25/12/2014 19:30)   <#>
например, проект eCall. И, учитывая масштаб этого проекта, срок разработки (с 2008 года), уровень исследований и финансирования, понятно, что не стоит и пытаться самому что-то сделать лучше. После компиляции их исходников и тестирования я понял, что это и есть предел.


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

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


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

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


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

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

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

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

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

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

— Гость (05/01/2015 16:58)   <#>

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

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


filehttp://www.news.cs.nyu.edu/~jinyang/pub/hermes.pdf
— gegel (06/01/2015 20:55)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Спасибо! Тогда мы об одном и том же, вот еще ссылка (текст практически тот же):
filehttp://www.news.cs.nyu.edu/~ad.....mobicom10-hermes.pdf

Я списался с 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, к сожалению, у меня нет FullText), но гораздо проще.

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

И для ZAS: ваши оценки возможностей GSM-кодированных каналов подтверждаются в работе:
filehttp://www.nativitysoftwares.c.....%20GSM%20Network.pdf
— 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)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Однако их подход ограничен скоростями порядка 1200 bit/s.

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

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

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

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

Частично делают турки. Ссылка на диссертацию (на турецком) уже приводилась в начале темы, и еще их fileстатья.
Они передают 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, эксплуатируя тот факт, что мои пульсы используют лишь каждую третью (или четвертую, пятую) сэмпл-позицию. Для псвевдоречи это не подойдет, но есть и другие идеи, как выравнять на границы символа.

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

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


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


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


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

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

— Гость (07/01/2015 01:42)   <#>

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

Я ведь правильно Вас понял?
— 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)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Я ведь правильно Вас понял?

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


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

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


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

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


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

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


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

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


Кстати, в 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
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3