ZAS Communicator

под линукс в каком виде то будет?

Во-первых, перед тем, как бороться с разными версиями линуксов, нужно 100% отладить протокол.
Во-вторых, Линукса и Андроиды поднимают целый ряд своих проблем. Например, как унифицировать юзеровский интерфейс, аудио интерфейс и интерфейс сети/upnp. Эти проблемы непринципиальны и решаются трудом и временем, которого нет.
Была идея сделать на QT но отказались из-за крайней монструозности, глючности и лицензионных проблем QT.

За что конкретно планируется взиматься плата?

За плагины с продвинутыми опциями. Видео, desktop sharing и пр.

предложение в 500$ за аудит непонятного проекта, – вообще смешно..

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

Опиши нормально концепцию своего "творения".

Бессерверная сеть с маршрутизацией с помощью DHT (Kademlia). Все участники равноправны. Каждый участник идентифицируется 256-битным ID. ID вычисляется как хеш от открытого ключа проверки подписи этого участника.
Весь обмен зашифрован и подвергнут обфускации; так что стороннему наблюдателю придется разбирать пакеты, чтобы вообще установить наличие траффика. Вхождение в связь по протоколу подобному Sigma-I. DHT обеспечивает поиск участников, как по ID, так и по ключевым словам.

Чем лучше торфона или xmpp с соответствующим XEP'ом + TOR. Да хоть I2P...

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

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

Единственным конкурентоспособным аналогом является Скайп. Но Скайп – частная и закрытая система со всеми вытекающими.
Плюс циркулирующие слухи на тему skype spyware.

Начнём с того, что у него самодельные шифры, и он считает их лучше общепризнанных. Дальше можно не продолжать и не описывать, так ведь?

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

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

Что нам удобно:

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

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


Предлагается следующая конструкция (см. random.cpp):

128-битная машина состояний, гарантирующая минимальный период последовательности. Счетчик – скушно и слишком предсказуемо. Полином – особая точка =0, которую нужно проверять. Мне нравятся нелинейно-конгруэнтные генераторы
типа X[n+1] = (X[n]^A)*B mod C, потому что их нельзя представить как F(n), нужно вычислять пошагово.

256-битная хеш функция, ключуемая машиной состояний. Берется XXTEA c 20 раундами, с запасом. Сила раундовой функции XXTEA порядка трех бит, так что хватило бы 11 раундов.

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

Получился не слишком эффективный алгоритм, зато надежный и удобный. A попробуйте придумать что-то более эффективное и сильное с однонаправленной функцией, гарантированным 128-битным периодом, 256-битной стойкостью и 384-битным состоянием.

256-битная хеш функция, ключуемая машиной состояний. Берется XXTEA c 20 раундами

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

A попробуйте придумать что-то более эффективное и сильное с однонаправленной функцией, гарантированным 128-битным периодом, 256-битной стойкостью и 384-битным состоянием.

Я уже предлагал использовать Keccak SpongeWrap mode. Это, во всяком случае, академично, имеет теоретический базис, и никто Вас не упрекнет в самодеятельности.

ПС: напомните, какие голосовые кодеки и битрейты вы используете?

256-битная хеш функция, ключуемая машиной состояний. Берется XXTEA c 20 раундами

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

Есть статья Elias Yarrkov где показано, что XXTEA с 6 раундами как криптоалгоритм не обеспечивает 128-битной стойкости, адекватной размеру ключа. Функция раунда XXTEA не биективна, что упрощает поиск коллизий для хеш функции на основе XXTEA. Однако поиск коллизий != обращение функции.

A попробуйте придумать что-то более эффективное и сильное с однонаправленной функцией, гарантированным 128-битным периодом, 256-битной стойкостью и 384-битным состоянием.

Я уже предлагал использовать Keccak SpongeWrap mode. Это, во всяком случае, академично, имеет теоретический базис, и никто Вас не упрекнет в самодеятельности.

С вектором состояния больше килобита.

какие голосовые кодеки и битрейты вы используете?

Speex Wideband 8/16/24k режимы

Если работать медленнее чем 8k, то скорость в канале определяется оверхедом IP. Можно, конечно, упаковывать несколько пакетов аудиоданных в большой пакет, но это увеличит задержку.
http://www.zas-comm.ru
zas@zas-comm.ru

Во-вторых, Линукса и Андроиды поднимают целый ряд своих проблем. Например, как унифицировать юзеровский интерфейс, аудио интерфейс и интерфейс сети/upnp.

Самый лучший интерфейс – командная строка, всё остальное – мусор.

Есть статья Elias Yarrkov

Да, именно эту работу я и подразумевал.

поиск коллизий != обращение функции.

На сколько я понимаю, в таком применении хеш-функции как раз достаточно поиска коллизий.

С вектором состояния больше килобита.

Так используйте меньше (соответственно требуемой криптостойкости всей системы), если это имеет для Вас значение: F-преобразование ведь позволяет работать с различными соотношениями.

Самый лучший интерфейс – командная строка

Я, кстати, тоже с этим столкнулся в процессе работы над onionphone. Все же он интерактивный по сути, и без интерфейса будет неудобен и непрактичен. Например, установив соединение через Tor, пользователь захочет переключиться на прямое, используя выбранный STUN. Или в процессе разговора изменить кодек, подстроить компенсацию jitter в изменившемся Tor-канале и т.д. Пока остановился на curces.

Speex Wideband 8/16/24k режимы

Я так понимаю, VBR маскируется вашей обфускацией. При малых задержках и высоких битрейтах реконструкция фонем по VBR – уже не теоретическая, а практическая уязвимость.
Я ради интереса прикрутил много кодеков: MELPE-1200, CODEC2-1400, MELP-2400, LPC10-2400, GSM-FR, GSM-HR, GSM-EFR, G729, G723.1, CELP, LPC, ILBC, BV16, SILK, SPEEX и OPUS. Часть из них под патентами, часть свободна. Попробуйте добавить CODEC2 для возможности работы через GPRS, лишним не будет.
Также интересна возможность у LPC-кодека манипулировать описателями речи. Кодируете фрейм, изменяете описатели, затем декодируете. Получаются различные эффекты вокодера. Если использовать рандомные изменения (в определенных пределах) или статические значения, то, наверное, можно теоретически оценить устойчивость к идентификации (вероятность ошибки при сравнении с эталоном определенной длины).

поиск коллизий != обращение функции.

На сколько я понимаю, в таком применении хеш-функции как раз достаточно поиска коллизий.

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

С вектором состояния больше килобита.

Так используйте меньше (соответственно требуемой криптостойкости всей системы), если это имеет для Вас значение: F-преобразование ведь позволяет работать с различными соотношениями.

Разве смысл не в том, чтобы использовать готовую стандартную функцию Keccak без своих переделок?

Я, кстати, тоже с этим столкнулся в процессе работы над onionphone. Все же он интерактивный по сути, и без интерфейса будет неудобен и непрактичен.

Именно.

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

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

Speex Wideband 8/16/24k режимы

Я так понимаю, VBR маскируется вашей обфускацией. При малых задержках и высоких битрейтах реконструкция фонем по VBR – уже не теоретическая, а практическая уязвимость.

VBR не используется. Юзер может выбрать одну из трех фиксированных скоростей, согласно качеству канала. Как показал опыт, бывают cлабые каналы, по которым не проходит аудио на 16.8kbps.

Если применять VBR, то одной обфускацией не обойдешься. Придется дополнять аудиоданные случайным количеством мусора до шифрования. Неочевидно что получится какой-то выигрыш в среднем битрейте по сравнению с использованием фиксированной скорости.

Я ради интереса прикрутил много кодеков: MELPE-1200, CODEC2-1400, MELP-2400, LPC10-2400, GSM-FR, GSM-HR, GSM-EFR, G729, G723.1, CELP, LPC, ILBC, BV16, SILK, SPEEX и OPUS. Часть из них под патентами, часть свободна.

Ваш интерес понятен и близок. Занимался кодеками.

Попробуйте добавить CODEC2 для возможности работы через GPRS, лишним не будет.

Скорость кодека ниже 8kbps не имеет смысла для VoIP, т.к. траффик в этом случае определяется оверхедом самого IP протокола. Группировать аудиоданные в большие пакеты = увеличивать задержку.

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

Эффекты и идентификация – другая тема, хотя тоже интересная.

http://www.zas-comm.ru

zas@zas-comm.ru

Аудит одного дня. 500$ в день — это так мало?


OnionPhone gegel'я тоже.


KeccaK PRP + специальные режимы использования. Вопрос толком теоретически не проработан, но прорабатывается. Стандартов, я так понимаю, мы ещё долго не увидим.


Опять началось. Отсутствие периода не подразумевает криптостойкость.


А теоретический/сертификационный криптоанализ ≠ практическому. Но весь объём накопленных знаний, примеров и опыта говорит о том, что шифры, разработанные устойчивыми к первому устойчивы и ко второму, причём с очень хорошим запасом (обратное обычно неверно), поэтому устойчивость к первому принимается за максиму в любом респектабельном научном или академическом сообществе. Любительские шифры, даже «созданные с запасом», условиям сертификационного криптоанализа не удовлетворяют, их ломают только так. Навиная попытка компенсировать своё незнание и непонимание дизайна шифров их запутыванием часто ведёт к их ослаблению. Unknown даже недавно приводил конкретный исторический пример (подскажите ссылку, так и не смог найти), как соединив вместе два по отдельности стойкие примитива получили полностью нестойкую конструкцию (тривиальный взлом?).

> предложение в 500$ за аудит непонятного проекта, – вообще смешно..

Аудит одного дня. 500$ в день — это так мало?

Пока вы меня не убедили в том, что ваша стоимость $120k в год.
Кто-то говорил что любительские шифры ломает в пять минут?

> В отличие от, cистема обеспечивает поиск и соединение юзеров друг с другом.

OnionPhone gegel'я тоже.

Допустим, я хочу позвонить Васе Печкину. Каким образом найти Васю Печкина в TorPhone?

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

KeccaK PRP + специальные режимы использования. Вопрос толком теоретически не проработан, но прорабатывается. Стандартов, я так понимаю, мы ещё долго не увидим.

Необязательно keccak; подойдет любая хеш-функция + хеш функция от хеш функции. Можно взять за основу, например, BLAKE, SKEIN как, впрочем, и любой другой cильный блочный шифр. A можно построить необратимую пермутацию а-ля RC4, только посложнее. Но это потребует существенно больше памяти для хранения состояния. Способов множество.

> гарантированным 128-битным периодом

Опять началось. Отсутствие периода не подразумевает криптостойкость.

Сами себе возводите какие-то аргументы, потом сами же их опровергаете.
Заговариваетесь?

> Однако поиск коллизий != обращение функции.

А теоретический/сертификационный криптоанализ ≠ практическому. Но весь объём накопленных знаний, примеров и опыта говорит о том, что шифры, разработанные устойчивыми к первому устойчивы и ко второму, причём с очень хорошим запасом

Так как насчет того чтобы инвертировать хеш функцию с использованием XXTEA с 20 раундами и 256-битным блоком?
При известном 128-битном ключе. Или найти хотя бы одну коллизию?

Unknown даже недавно приводил конкретный исторический пример (подскажите ссылку, так и не смог найти), как соединив вместе два по отдельности стойкие примитива получили полностью нестойкую конструкцию (тривиальный взлом?).

Речь шла об Akelaire – хороший пример слабого шифра. Во-первых авторам показалось достаточно 4-х раундов. Во-вторых, функция раунда оказалась с линейной зависимостью между двумя битами при любом ключе.

Есть интересная статья Бирюкова и Шамира насчет конструкций типа SASAS. Заставляет хорошо задуматься о проблемах AES – подобных шифров.

http:\\www.zas-comm.ru
zas@zas-comm.ru

Если вы хотите централизованный поиск как в Skype, то его нет, да. Нужно обменяться IP'шниками или использовать какой-то иной discovery-сервис. В принципе, можно хоть на свой PGP-ключ в качестве uid'а повесить нужные аутентификационные данные, которые потом все будут искать на серверах PGP-ключей.


Речь о теоретическом криптоанализе шла.


Простите, но про период вы тут начали. К чему этот аргумент? О том, что нет периода = всё стойко, тут до вас успела повещать орава виндовых троллей (кажется, в топиках типа сжатия диска и в топиках про каскадные шифры, но мне лень искать точные цитаты).


Оказывается, об это было здесь же на предыдущих страницах [но написано с опечаткой]. Вики.

Безопасность примитива доказывает тот, кто его выдвигает, а не наоборот («пока не нашли уязвимость, оно безопасно»). Тяжесть доказательства и всё такое.

/comment79981:
/comment79982:
/comment79983:
Keccak в чём-то неоптимален, а самопальные алгоритмы изначально не претендуют на оптимальность реализации, пытаясь компенсировать этим свои слабости разработки. В чём выигрыш такого подхода, неясно.

Даже в реализации известных алгоритмов могут быть уязвимости, неотлавливаемые годами (как в OpenSSL), а если ещё и алгоритм неизвестный, то как там его неидеальности лягут на всё остальное, докопаться смогут не скоро.

(...описание алгоритма cм выше...)

поиск коллизий != обращение функции.

Насколько я понимаю, в таком применении хеш-функции как раз достаточно поиска коллизий.

Требуется обращение хеш функции, т.е. найти все входные вектора которые дают заданный выходной вектор. Поиск коллизий, т.е. нахождение каких-то двух разных входных векторов, дающих один и тот же результат – более простая задача. Во втором случае мы можем подбирать слабые ключи или данные, в первом – нет.
Но даже во втором случае, для XXTEA вероятность уходит за 2^-100 после первых 5 раундов.

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

Конкретнее. Какие именно слабости?

В чём выигрыш такого подхода, неясно.

Уже писал, каких целей хотелось достичь. Необратимости алгоритма, минимальной памяти, практической стойкости, простоты реализации.
http://www.zas-comm.ru
zas@zas-comm.ru

Перепутаны местами «во втором» и «в первом»?


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

Прошу прощения, постинг сьел функцию.

const u32 rounds = 32; u32 s_box(u32 x) { x = (x << 4) - x; x ^= x >> 10; x = (x << 7) | (x >> 25); return x; } void encrypt(u32 *x, const u32 *key, const u32 len) { u32 N = 0; for(u32 i = 0; i < rounds; i++) { for(u32 j = 1; j < len; j++) { x[j] += s_box(x[j-1] ^ (N + key[j])); N++; } x[0] += s_box(x[len-1] ^ (N + key[0])); N++; } } void decrypt(u32 *x, const u32 *key, const u32 len) { u32 N = rounds * len; for(u32 i = 0; i < rounds; i++) { N--; x[0] -= s_box(x[len-1] ^ (N + key[0])); for(u32 j = len - 1; j > 0; j--) { N--; x[j] -= s_box(x[j-1] ^ (N + key[j])); } } }