криптодиск с "дошифровкой" данных. имеет ли смысл?
У меня давно уже зреет идея создания своего криптодиска, в качестве альтернативы TrueCrypt, но для параноиков.
Основными фичами этого диска будет следующее:
1) В 2-4 раза более высокая, чем у TrueCrypt производительность (имеется опыт оптимизации крипто на ассемблере, и подобные результаты достигнуты)
2) Максимальная простота в том, что касается формирования ключа тома. У TrueCrypt не вызывает доверия rng используемый для формирования ключа заголовка, т.к. его структура излишне сложна.
3) Оптимальная работа с многоядерными процессорами (windows драйвер у трукрипта написан мягко говоря через ж.пу, и не умеет быстро обрабатывать запросы).
4) Файл с криптодиском будет иметь размер в 10 раз больше, чем размер подключаемого диска. В этом файле можно создать от 1 до 10 дисков, и при давлении выдавать пароли от несекретных.
4) Специальный алгоритм "дошифровки" данных, включающийся перед (либо после) основного криптоалгоритма, и улучшающий общую защищенность системы. Об этой части хочеться сказать подробнее:
Алгоритм дошифровки необходим для противостояния неизвестным атакам на распостраненные криптоалгоритмы (например секретным реализациям алгебраических атак), и защищает диск от статистического анализа и ватермаркинга.
Для этого используется самопальный алгоритм с максимально запутаной структурой, который шифрует данные на основе отдельного ключа (не пересекающегося с ключами основного алгоритма) и положения читаемого сектора на томе. Первое нужно для затруднения атак на известные алгоритмы (алгоритм дошифровки просто никто не будет ломать из за его нераспостраненности), а второе – для затруднения создания маркированых файлов, которые потом можно обнаружить на криптотоме. Про криптостойкость алгоритма дошифровки говорить не будем, он делается дилетантом и не проходит никаких проверок, поэтому будем считать ее нулевой. Но применение дошифровки вместе с основным алгоритмом шифрования, будет в любом случае повышать его стойкость к неизвестным атакам (так как добавляются не исследованые криптоаналитиками преобразования).
Прошу высказать ваще мнение о целесообразности разработки, и о вышеописаных идеях.
комментариев: 1060 документов: 16 редакций: 32
1) Полезно, если будет качественно и под различные процессоры.
2) 3) Здесь прокомментировать не могу, т.к. с исходниками не знакомился.
4) О полезности/бесполезности подобных фишек уже неоднократно здесь говорилось. А почему 10? По количеству пальцев, которые отобьют "взломщики" бедному пользователю. :)
5) Смысла от такой "дошифровки" будет ноль. Сложность и стоимость анализа объектного кода несопоставимо низка по сравнению со сложностью и стоимостью криптоанализа.
А векторы инициализации просто так, для крастоты существуют?
комментариев: 9796 документов: 488 редакций: 5664
В Linux-crypto_API (к примеру) используется самый медленный сишный вариант, где не только не просчитаны комбинации S-блока с матрицами, но даже не рассчитан сам S-блок. Зато можно визуально заметить правильность кода. Это важнее.
Если Ваша программа Open Source, то это ничего не даст. Да и на закрытость и запутанность полагаться бесполезно.
Более того, это вызывает подозрения, что таким путём можно внести криптографический backdoor в программу.
Статистический анализ? В обычном виде он не применим к стойким алгоритмам. Ватермаркинг основан на использовании неподходящих режимов шифрования. Существуют же нормальные режимы. В последних версиях truecrypt реализован LRW
К алгебраическим атакам должен быть устойчив blowfish или возможно его попытка расширения kaweichel, правда он не исследован в должной степени, да и функция линейного смешивания XOR-ADD-XOR считается несколько устаревшей.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 53 документов: 3 редакций: 1
Интересно, каким это преобразованием проводящемся после основного шифрования данных, на отдельном ключе, и не изменяющим размера выходных данных можно ослабить криптозащиту?
У нас имеются УЖЕ зашифрованые данные. Любые их последующие преобразования никак не помогут злоумышленику в расшифровке, при условии что в них не участвует основной ключ шифрования.
В случае шифрования отдельных сообщений да, важнее. В случае же шифрования дисков, проблема производительности является весьма значительной. Я например все данные (это сотни гигабайт) храню на криптодиске, и производительность для меня важна.
Правильность реализации легко проверить простым сравнением результатов с официальными исходниками. В крайнем случае можно предложить выбор между медленной официальной реализацией, и ускореной ассемблерной.
Понятно. Следовательно если программу и стоит делать, то только для личного использования.
Про TrueCrypt могу сказать лишь одно – мне очень не нравиться его реализация rng, а вся стойкость шифрования замешана именно на него. Имхо шифровать данные нужно только хешем от пароля и соли, а не ключем созданым неизвестно чем. При этом будет невозможно сменить пароль без перешифровки данных, но я не считаю это недостатком.
Вот тогда бы такая программа имела спрос среди желающих скрыть сам факт шифрования.
Ну и что-нибудь надо для оправдания наличия массивов случайных чисел, конечно.
комментариев: 1060 документов: 16 редакций: 32
У нас имеются УЖЕ зашифрованые данные. Любые их последующие преобразования никак не помогут злоумышленику в расшифровке, при условии что в них не участвует основной ключ шифрования.
Как, впрочем. и не помешают при условии их нестойкости.
комментариев: 53 документов: 3 редакций: 1
А из исходников. :) ( если не криво писать и с комментариями, чётко обозначая внесённые изменения )
ссылка на проверенные исходники + ссылка на проверенный патчер + свои изменения