id: Гость   вход   регистрация
текущее время 01:33 31/07/2021
Автор темы: Гость, тема открыта 30/11/2006 11:42 Печать
https://www.pgpru.com/Форум/ПрактическаяБезопасность/КриптодискСдошифровкойДанныхИмеетЛиСмысл
создать
просмотр
ссылки

криптодиск с "дошифровкой" данных. имеет ли смысл?


У меня давно уже зреет идея создания своего криптодиска, в качестве альтернативы TrueCrypt, но для параноиков.
Основными фичами этого диска будет следующее:
1) В 2-4 раза более высокая, чем у TrueCrypt производительность (имеется опыт оптимизации крипто на ассемблере, и подобные результаты достигнуты)
2) Максимальная простота в том, что касается формирования ключа тома. У TrueCrypt не вызывает доверия rng используемый для формирования ключа заголовка, т.к. его структура излишне сложна.
3) Оптимальная работа с многоядерными процессорами (windows драйвер у трукрипта написан мягко говоря через ж.пу, и не умеет быстро обрабатывать запросы).
4) Файл с криптодиском будет иметь размер в 10 раз больше, чем размер подключаемого диска. В этом файле можно создать от 1 до 10 дисков, и при давлении выдавать пароли от несекретных.
4) Специальный алгоритм "дошифровки" данных, включающийся перед (либо после) основного криптоалгоритма, и улучшающий общую защищенность системы. Об этой части хочеться сказать подробнее:


Алгоритм дошифровки необходим для противостояния неизвестным атакам на распостраненные криптоалгоритмы (например секретным реализациям алгебраических атак), и защищает диск от статистического анализа и ватермаркинга.
Для этого используется самопальный алгоритм с максимально запутаной структурой, который шифрует данные на основе отдельного ключа (не пересекающегося с ключами основного алгоритма) и положения читаемого сектора на томе. Первое нужно для затруднения атак на известные алгоритмы (алгоритм дошифровки просто никто не будет ломать из за его нераспостраненности), а второе – для затруднения создания маркированых файлов, которые потом можно обнаружить на криптотоме. Про криптостойкость алгоритма дошифровки говорить не будем, он делается дилетантом и не проходит никаких проверок, поэтому будем считать ее нулевой. Но применение дошифровки вместе с основным алгоритмом шифрования, будет в любом случае повышать его стойкость к неизвестным атакам (так как добавляются не исследованые криптоаналитиками преобразования).


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


 
Комментарии
— sentaus (30/11/2006 15:29)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Позволю себе побрюзжать.

1) Полезно, если будет качественно и под различные процессоры.
2) 3) Здесь прокомментировать не могу, т.к. с исходниками не знакомился.
4) О полезности/бесполезности подобных фишек уже неоднократно здесь говорилось. А почему 10? По количеству пальцев, которые отобьют "взломщики" бедному пользователю. :)
5) Смысла от такой "дошифровки" будет ноль. Сложность и стоимость анализа объектного кода несопоставимо низка по сравнению со сложностью и стоимостью криптоанализа.
второе – для затруднения создания маркированых файлов,

А векторы инициализации просто так, для крастоты существуют?
— unknown (30/11/2006 15:41, исправлен 30/11/2006 15:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ассемблер используется редко (например проверенный код от профессора Брайана Гладмана ), потому что в самописном асме разобраться сложно.

В Linux-crypto_API (к примеру) используется самый медленный сишный вариант, где не только не просчитаны комбинации S-блока с матрицами, но даже не рассчитан сам S-блок. Зато можно визуально заметить правильность кода. Это важнее.

(алгоритм дошифровки просто никто не будет ломать из за его нераспостраненности)

(так как добавляются не исследованые криптоаналитиками преобразования).

Если Ваша программа Open Source, то это ничего не даст. Да и на закрытость и запутанность полагаться бесполезно.

Более того, это вызывает подозрения, что таким путём можно внести криптографический backdoor в программу.

и защищает диск от статистического анализа и ватермаркинга

Статистический анализ? В обычном виде он не применим к стойким алгоритмам. Ватермаркинг основан на использовании неподходящих режимов шифрования. Существуют же нормальные режимы. В последних версиях truecrypt реализован LRW

Алгоритм дошифровки необходим для противостояния неизвестным атакам на распостраненные криптоалгоритмы (например секретным реализациям алгебраических атак)

К алгебраическим атакам должен быть устойчив blowfish или возможно его попытка расширения kaweichel, правда он не исследован в должной степени, да и функция линейного смешивания XOR-ADD-XOR считается несколько устаревшей.
— SATtva (30/11/2006 16:07)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4110
Разработка TC открыта, поэтому, если бы я считал свои познания по пунктам 1-3 достаточно высокими, то просто предложил бы свои услуги и помощь авторам программы.
— Lemtoks (30/11/2006 17:30)   профиль/связь   <#>
комментариев: 53   документов: 3   редакций: 1
Вряд ли кто-то будет пользоваться этой программой, несмотря на её преимущества. Я, например, предпочту более медленный, без возможности создания 10 дисков, но проверенный TrueCrypt недавно написанной софтине, надёжность которой никто подтвердить не может.
— Гость (30/11/2006 20:42)   <#>

Интересно, каким это преобразованием проводящемся после основного шифрования данных, на отдельном ключе, и не изменяющим размера выходных данных можно ослабить криптозащиту?
У нас имеются УЖЕ зашифрованые данные. Любые их последующие преобразования никак не помогут злоумышленику в расшифровке, при условии что в них не участвует основной ключ шифрования.

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

Понятно. Следовательно если программу и стоит делать, то только для личного использования.

Про TrueCrypt могу сказать лишь одно – мне очень не нравиться его реализация rng, а вся стойкость шифрования замешана именно на него. Имхо шифровать данные нужно только хешем от пароля и соли, а не ключем созданым неизвестно чем. При этом будет невозможно сменить пароль без перешифровки данных, но я не считаю это недостатком.
— Гость (30/11/2006 20:42)   <#>
FreeOTFE имеет возможность подключения своих алгоритмов и создания неограниченного числа "криптодисков".
— Гость (30/11/2006 21:16)   <#>
Если будете писать свою модификацию, было бы неплохо иметь возможность скрывать её назначение, хотя бы позволяя пользователю называть исполняемые файлы по своему, а ещё лучше не оставлять в них сигнатур, используя технику полиморфных вирусов. И дать возможность "склеивать" с какой-нибудь, по выбору пользователя, маскировочной игрушкой.

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

Ну и что-нибудь надо для оправдания наличия массивов случайных чисел, конечно.
— sentaus (30/11/2006 21:21)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32

У нас имеются УЖЕ зашифрованые данные. Любые их последующие преобразования никак не помогут злоумышленику в расшифровке, при условии что в них не участвует основной ключ шифрования.

Как, впрочем. и не помешают при условии их нестойкости.
— Lemtoks (30/11/2006 21:44)   профиль/связь   <#>
комментариев: 53   документов: 3   редакций: 1
У нас имеются УЖЕ зашифрованые данные. Любые их последующие преобразования никак не помогут злоумышленику в расшифровке, при условии что в них не участвует основной ключ шифрования.
А откуда я знаю, что основной ключ не участвует?
— Гость (30/11/2006 22:17)   <#>
А откуда я знаю, что основной ключ не участвует?

А из исходников. :) ( если не криво писать и с комментариями, чётко обозначая внесённые изменения )
— Гость (30/11/2006 22:35)   <#>
Совсем для параноиков нужна поставка ввиде проверенные исходники + проверенный патчер + свои изменения
— Гость (30/11/2006 22:50)   <#>
Уточнение:
ссылка на проверенные исходники + ссылка на проверенный патчер + свои изменения
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3