Проброс модема через сжатый голосовой канал Опции

[GeGeL]

Хотелось услышать мнение о возможности проброса модемного соединения >=1200bps через сжатый речевой канал: GSM/UMTS (GSM-FR, -EFR, -HR, AMR), Skype (Silk), SIP (G723, G729 etc.). Какие алгоритмы модема целесообразно пробовать?

[GeGeL]

В реальной ЭКГ этих классов мало: на суточной записи типичное число - 20, а больше 50-ти мы вообще никогда не видали.

Очень интересные исследования, хотя есть одно но: по уму необходимо математически показать вероятность неподдерживаемого класcа, определяющего диагноз. Т.е. фактически это будет вероятность ошибки диагноза. Если достигается, скажем, Р<0.05, то это приемлемо в медицине.
Хотя есть масса участковых врачей, которые знают и используют всего 20 диагнозов и прекрасно работают. Но все же я бы не хотел к такому попасть.

Вы хотите иметь гарантированную стойкость

Конечно же, в качестве противника обычно рассматривается АНБ, а не младшая сестра

возьмет за нежные части и Боба, и Алису

ну, дискуссия между академичиской криптографией и реальностью может быть бесконечной.
Есть такие понятия, как Perfect Forward Secrecy, Plausible Deniability, Forward Deniability.
Согласен, в случае криптофона математическая отрицаемость (например, в плане использования своего PGP-ключа) малополезна, т.к. соединение в принципе неанонимно (по sim-карте). Но PFS обязательна в современной крипто, и без ефемеральных сесионных ключей, выведенных Диффи-Хелманн, это было бы несерьезно. Для защиты от MitM необходима аутентификация:
- биометрическая (голосовая) - ненадежна;
- общим секретом - требует протоколов с нулевым разглашением, ненадежна в плане key impersonation attack;
- публичным долговременным ключом в составе цепочки PKI (например, PGP, подписанным другими).

Еще народ делает дополнительно голосовую аутентификацию

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

Но если код открыт, то как на этом заработать деньги???

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

Все это тоже не добавляет оптимизма.

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