РегистрацияZAS Communicator
ZAS Communicator Opensource Project: secure voice, file transfer and text chat.
Комментарии, советы, предложения?
|
|||||
|
|
||||
|
|
|
||||
|
|||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
комментариев: 9796 документов: 488 редакций: 5664
Моя логика проста: вероятность фатальной ошибки в собственноручном шифре гораздо выше, чем в созданном признанными специалистами в открытом сообществе при соблюдении всех определённых условий и формальностей. А по последствиям самопальный шифр м.б. хуже любой закладки. Причём, скорее всего, дырка будет такая, что создатели криптозакладок помрут со смеху, когда до неё докопаются. Я бы ни за что не стал доверять собственноручно созданному шифру, если только не стал бы проводить муторную многолетнюю работу по его академической публикации, привлечению других спецов и пр. Или только как в качестве демопримера для изучения каких-нибудь свойств новых функций в теоретических работах.
И по отношению к шифру, опубликованному псевдонимом без серьёзного теоретического бэкграунда я рассуждаю примерно также. Мне приблизительно понятно к какой группе шифров его можно отнести и какие примерно методы криптоанализа против них обычно применяются. Если там явная слабость, то может он и поломается легко. А если нет, то тратить массу времени на поиск реализаций атаки с негарантированным результатом — неинтересно. И ради чего собственно? Я лучше AES или SHA-3 лишний раз поковыряю. Оно как-то полезнее будет, даже если крохотную атаку на них показать.
Вот только почему бы вам самому не начать это делать, на вашем шифре? Попробовать самому выяснить, сколько раундов вашего шифра ломаются. За сколько шагов, с какими затратами, какими атаками. Алгебраическую сложность функции рассчитать, дифференциальные и прочие характеристики. Показать, что с ростом раундов сложность атаки будет расти вот по такой-то формуле. Тогда может кто-то найдёт зацепку для атаки, исходя из ваших возможных неправильных теоретических предпосылок как разработчика алгоритма.
Правда и это будет больше похоже на глас вопиющего в пустыне: симметричных алгоритмов публикуют и так много. Часто, даже если автор известен, никто малораскрученный алгоритм не анализирует. А в криптоалгоритме без каких-либо теоретических наработок могут поковыряться разве что, если его авторами будет АНБ или крупная коммерческая компания.
В таком случае, не стоит огульно охаивать тех, кто пытается что-то делать. Можно чему-то научиться и чего-то достичь, только конструируя шифры и обсуждая их слабости. Кстати, системные и структурные cлабости намного опаснее, чем слабости собственно шифра.
Не доверяю ни себе, ни другим. Поэтому вышеописанная конструкция на основе XXTEA/IDEA.
Была мысль сделать все на основе DES, потому что DES изучен вдоль и поперек. Но слишком неэстетичный алгоритм.
Функция s_box() биективна, в отличие от используемых в Enrupt и XXTEA. По моим оценкам, обеспечивает наихудшую вероятность дифференциальной характеристики не хуже 2^-3. Параметры s_box оптимизированы. Исходя из вероятности диф. характеристики получаем минимально необходимое число раундов 11..12 для всей UFN. Слабость s_box в том, что она линейна по краям, т.е. есть "сильные" и "слабые" биты. Еще одно потенциально слабое место – key schedule, которое регулярно и ни разу не оптимально. Лечим проблемы количеством раундов.
Алгоритм имеет смысл публиковать только если он в чем-то лучше многих существующих. Например, быстрее и/или эффективнее в реализации. Если алгоритм ничем не лучше, то зачем такой нужен.
Во многих случаях был бы удобен универсальный блочный примитив с ключом и блоком произвольных размеров, пусть неэффективный, но простой в реализации. Известны XXTEA и Enrupt, в которых авторы недооценили нужное число раундов в погоне за скоростью. Универсальный безопасный шифр легко построить со количеством операций порядка N^2, где N-размер блока, но слишком неэффективно. Я попытался изобразить нечто подобное со сложностью порядка N.
Simon интересен как идея, да. Но доверять NSA не хочется.
http://www.zas-comm.ru
Даже если всё делать по-академичному, есть личный пример: я находил опечатки, ошибки и непонимание авторами в уже опубликованных статьях. В моих статьях тоже находили серьёзные ошибки. Очень часто статья выходит, но её никто не читает, и если там есть ошибка, она там может сидеть хоть десятилетиями.
Вообще, если рассматривать пристально, статьи — отражение форума. Часто пишут непонятно, проглатывают мысли, ставят не те ссылки, опечатваются, приводят фальшивые аргументы, а иногда вообще ошибаются и пишут неправильные результаты. Этим страдает, пожалуй, чуть ли ни каждая вторая статья в архиве. И когда платят за количество, а не за качество, мало кто остаётся верен высокой планке качества: лучше выбросить сырой непродуманный результат, оформленный наспех, в надежде, что мелочёвка потом будет общими усилиями исправлена (вычитка редакторами, рецензентами, самим перед принятием к публикации), а глобальных проблем в работе нет.
[/offtop]
комментариев: 9796 документов: 488 редакций: 5664
Ответ на околостатейный офф., ещё и на этот комент и далее по текущему топику. У авторов AES и Keccak — одни из лучших статей, просто за счёт подробности обоснований. Но когда они слегка накосячили в обеих проектах их есть куда ткнуть носом. Про AES по памяти помню, они ввели определение "Hermetic и K-Secure". После взломов можно сейчас найти эти строки, фигурально ткнуть пальцем и разобрать, почему это доказательство и эта модель были ошибочны. Сложнее, но также можно покопаться, почему в Keccak ошиблись с выбором нулевого вектора для старта начального раунда (решили, что это некритично?), что привело к созданию атак на различители с нулевой суммой, а также спорить и пытаться прогнозировать, что там у них оказался заниженный результат с уровнем алгебраической сложности. Не будь качественной развёрнутой теоретической работы (пусть даже ошибочной), сами эти ошибки не стали бы столь наглядными и поучительными, имели бы больше шансов пройти незамеченными.
По поводу возникновения темы выбора самопального криптопримитива в топике.
Попытка заменить S-блок алгебраическими функцией были придумана давно. Видимо вам такой подход нравится: IDEA, {X,XX,}TEA, RC{5,6}, MD5, SHA{1,2}. Теперь вот Salsa, ChaCha и Treefish/Skein. Получается виртуальный S-блок большого размера (32 бита).
Обычный таблично-представимый 8-битовый S-блок можно изучить на все придумываемые зависимости методом перебора, хотя с межблочными зависимостями внутри раунда и межраундовыми зависимостями так не получится. Используются оптимизационные алгоритмы поиска, которые часто не публикуются, а публикуется лишь общая идея и найденные результаты.
Ваш виртуальный S-блок похож на ARX (Addition-Rotation-Xor), хотя и использует немного другой набор операций, но суть похожа. Методом перебора пар текстов и ключей в таком большом массиве что-либо найти сложно (пытаться перемножить, перексорить, складывать и пр. все комбинации 32-битных блоков, 264 варианта как минимум). Поэтому такие функции были очень популярны, хотя оставалось сомнение в доказательстве их стойкости. Проблема возникла, когда для ARX-подобных шифров нашли метод оптимизированного поиска характеристик без полного перебора. К сожалению работы не вспомню, общая идея была понятна, но тоже не запомнилась, а подробности самой реализации поиска, как и предполагалось, в работах оказались скрыты.
Получается, что математическая теория, описывающая свойства таких элементарных функций, отсутствует, но есть некий набор оптимизационных методов поиска различителей, которыми авторы, не раскрывая деталей, как фокусники вытаскивают дефекты. Есть ли смысл соревноваться с теми, кто знает и понимает больше, не достигнув их уровня понимания — решать вам.
Но смешивание создания криптопримитивов и программной разработки в лучшем случае — показатель излишней самоуверенности. Хотя бы формально разнесли по разным проектам и не пихали одно в другое (разумеется, решать всё вам, никто кроме вас вам не указ), да ещё занимаясь саморекламой с непрерывной простановкой ссылок на свой сайт, непрерывным постингом ченджлогов, репортов и пр. Общие идеи, пожалуйста, обсуждайте. У нас несколько достаточно-достойных русскоязычных проектов о себе заявило в менее навязчивой форме. Но если активным участникам форума проекты в чём-то не нравятся и не всегда охота подробно разбирать в чём, это не знак молчаливого одобрения для того чтобы их форсить не через свой ресурс.
В таких случаях удобно сделать, скажем, 16-битную версию функции и проанализировать на предмет возможных проблем. Оптимальные параметры функции и конкретные слабости будут, разумеется, другими, но классы проблем вы увидите. Другой прием с той же целью – сделать функцию частично или полностью линейной, заменяя addition на xor.
A попробуйте на досуге 4-битную версию RC4, прикольно :)
http://www.zas-comm.ru
комментариев: 9796 документов: 488 редакций: 5664
Да, напомнили, вроде ключевые слова — "ARX linearisation". Одну из букв в ARX выкидывают, подбирая наиболее похожую, но более линейную функцию, на которой легче найти дефект. В окрестностях дефекта упрощённой функции ищут дефект исходной, полной нелинейной функции. Какая-то такая была идея, именно так, как вы описываете.
Пара вопросов, небольших критических замечаний по теме.
Создавая «негосударственный» шифр вы можете доказать отсутствие явной или тайной связи с влиянием государства только самому себе. Как другие могут поверить в отсутствие этой связи, даже если бы вы были не аноним, а человек с репутацией? Это как взлом. Явно продемонстрированный взлом доказывает нестойкость однозначно, а стойкость в большинстве областей современной криптографии доказывается плохо, косвенно и неполностью.
Размер ключа в эллиптике и размер ключа в целочисленном поле не обосновывают сравнительную стойкость против методов квантового криптоанализа разных асимметричных алгоритмов, насколько я знаю.
Ваш проект под какой лицензией идёт? Если не GPL/BSD и вы даже не хотите брать куски такого кода и линковаться с ним, шарахаетесь от патентов на эллиптику, которые, вроде как решены для опенсорсных лицензий, да ещё хотите коммерциализировать часть проекта, то всё это наводит на подозрительную мысль. Автор может в случае успеха подсадить часть пользователей на свой негласный стандарт, а затем закрыть или полностью коммерциализировать проект, сделав вендор-локинг.
Ваш проект обещает какие-то деньги за аудит. Откуда они у беззвестного анонима? Не стоИт ли за этим коммерческая контора или мутный стартап, который даст попользоваться бесплатно, а затем закроет исходники, перепродасться и заобфусцирует часть кода и протокол. Самопальный простые шифры как раз очень для этого подходят — в скомпиленном коде с обфускацией их труднее отреверсить.
Даже в случае успеха с таким подходом и позиционированием проекта маячут, как минимум лавры трукрипта или ещё какие сюрпризы.
О вкусе устриц. Вместо абстрактно-отвлеченных cуждений, посмотрите cобственно проект. И вопросов будет меньше.
Вклад создателей трукрипта в дело защиты гражданских свобод трудно переоценить.
http://www.zas-comm.ru
http://www.zas-comm.ru
Win32/Win64 версии, исполняемые файлы и исходники.
В этом билде исправлено несколько багов в юзеровском интерфейсе и сетевом протоколе, выявленных при эксплуатации программы. Кроме того, сделан свой сборщик энтропии от системных событий, в дополнение к уже имеющимся вызовам штатного системного генератора и сбору энтропии из передаваемых и принимаемых данных.
Работает замечательно: установил, сгенерировал ключ и подключайся. Ничего нигде настраивать не требуется. Для девелоперов имеется отдельное меню с логами и дебаговой информацией.
In 2012, full 8.5 round IDEA was finally broken, using a narrow-bicliques attack, with a reduction of cryptographic strength of about two bits, similar to the effect of the previous bicliques attack on AES.
Не знаю. Причем тут вообще IDEA?
Если уж упоминули IDEA и bicluques: 126-битная стойкость при 128-битном ключе. И...?
Вместо обычного бормотания не по делу, попробуйте сделать хоть что-то сами. Хотя бы предложите что-нибудь полезное или умное.
Версия под Linux в процессе. Приходится обрастать bloat в виде QT; тот еще отдельный гемор.
Единственный аналог – TOX. Остальные – либо SIP клиенты, либо говорилки с прямым соединением без поиска абонентов.
Не говоря уж об отсутствии средств обфускации траффика и по большей части отвратительном качестве связи.
Очень рад за TOX, спасибо за наводку. Приятно видеть, что идея распределенной cистемы связи на основе DHT имеет сторонников. Если действительно в TOX все хорошо, первый буду пользоваться. Тем не менее, надо растить и совершенствовать свою систему.
http://www.zas-comm.ru
Для тех, кто в танке: новость была ещё год назад.
комментариев: 393 документов: 4 редакций: 0
Торфон обеспечивает поиск абонента средствами TorHS (по его onion-адресу), а затем переход на прямое UDP-соединение с NAT-traversal через уже установленное onionHS-соединение и любой STUN. Я давно продвигал эту идею, как более практичную, чем свой DHT.
Что касается обфускации трафика, то Торфон использует нестандартный протокол (не RTP) без особых паттернов, причем при выходе из onion на прямое p2p UDP-соединение уже шифрованный (причем согласование ключей выполнено внутри Tor).
По качеству связи: куча кодеков на выбор, в т.ч. OPUS.
Во-первых, неудобно; нужен обычный произвольный поиск юзеров по ключевым словам без предварительных согласований или публикации каких-то таблиц на каких-то серверах. Во-вторых, концептуально не нравится зависимость от третьих сущностей в виде TOR.
Вполне понятно желание разработчика упростить себе жизнь.
Траффик ZAS в любой фазе соединения выглядит как поток случайных UDP пакетов случайной длины; порты тоже выбираются случайно.
Для хорошего голоса достаточно одного кодека, с самплрейтом 16kHz. Но дело не столько в кодеке, сколько в правильном алгоритме буфферизации, адаптирующемся под канал. Каналы oчень разные.
/*
*/
Была идея использовать Скайп как транспорт, подсунув ему на вход свое устройство в виде псевдо-аудио/псевдо-видео.
Или перехватывать на уровне сетевого стека уже установленное соединение Скайпа и накладывать на него сверху свой шифрователь. Таким образом, решаются проблемы с поиском и соединением. Но появляются третьи сущности, которым вряд ли это нравится. Кроме того, заклад на негарантированные свойства. Такой проект может пойти как мелкий хак; но вряд ли получится сделать большую систему. Хотя идея проста и очевидна. Кто-нибудь пробовал?
http://www.zas-comm.ru
комментариев: 393 документов: 4 редакций: 0
Я давно хотел у Вас спросить: есть ли в этом смысл? Для поиска абонента надо точно знать имя (или любой другой идентификатор), чтобы искать по хешу. Чем это практичнее поиска по заранее опубликованному адресу? Конечно, можно организовать какой-то перебор при поиске, или же, наоборот, публиковать различные варианты (ключевые слова) и т.п. Но всего ведь не учтешь, да и поиск существенно затянется. Мне кажется, что перебор – это непрактичный костыль в данном случае. А как реализован поиск у Вас? Можно ли найти всех абонентов, содержащих в имени 'gegel'?
У меня тоже была идея использовать Скайп в качестве транспорта. Но тут вы правы: рано или поздо это не понравится Microsoft, и на этом все закончится. Зависеть от Microsoft несравненно хуже, чем зависеть от Tor.