Добрый день! Мне требуется шифровать файлы, чьи размера могут колебаться от 4 Кб до 64 Гб, шифратор собственно Blowfish. Вычислять CRC32/CRC64, и основываться на сходстве данного показателя? Или как то по другому можно? А как 7z проверяет?
Хранить какой нибудь (MD5, SH1, etc) хэш пароля. Или вычислить хэш шифруемых данных, добавить в конец к данным и зашифровать все используя пароль(или его хэш) как ключ. При расшифровке пароль не проверять, а просто расшифровавать тем что есть. После посчитать хэш расшифрованых данных и сравнить с оригинальным хэшем. При совпадении считать пароль правильным, а расшифрованные данные валидными.
В любом случае, пароль явно нигде не хранится. В одном случае хранится только хэш пароля, а в другом хэш данных.
Partner 64 ГБ таким образом расшифровывать? Имхо сигнатуру надо шифровать и хранить в зашифрованном файле, а потом расшифровывать и сравнивать с оригинальной.
1) сформировать из хорошего (!) rnd случайный блок, равный по длине блоку шифра 2) зашифровать этот блок паролем 3) приложить к файлу первый блок целиком, а второй - либо весь, либо частично (чем меньшую часть зашифрованного блока приложишь, тем больше будет вероятность ложного допуска до реальной расшифровки неверного ключа, но теоретически тем меньше информации ты сообщаешь для тех, кто захочет с помощью этих данных взломать ключ - я бы посоветовал около 16-20 бит - от случайных опечаток при вводе пароля защитит хорошо, а те, кто будут подбирать, получат 2^108 ложных ключей) - "пароль не будет уязвимым", т.к. одно из тщательно соблюдаемых свойств блочных шифров - это защита от атаки "known plaintext" - и Blowfish его выполняет т.е. для вычисления ключа по этим "припискам" злоумышленнику потребуется в среднем 2^129 таких пар - шифровать фиксированную сигнатуру плохо, т.к. если разные файлы будут зашифрованы одним и тем же паролем, то этот факт будет сразу заметен - хешировать пароль конечно можно, но 1) обязательно с длинной солью, 2) прогресс в области rainbow-таблиц и прочих атак на хеш-суммы мне не нравится, 3) придется в коде реализовывать еще и хеш-функцию, а в предлагаемом мною методе используется уже имеющийся блочный шифр P.S. Определенную проблему любая дополнительная проверка валидности пароля (неважно как криптографически реализованная) создает в тех случаях, когда пользователь шифросистемы выбирает относительно слабые пароли. Как известно, человеку очень сложно придумать пароль информационной емкостью выше 64 бит, "типовые" "стойкие" пароли живут в диапазоне 25-40 бит. Вот тут быстрая проверка валидности может сыграть злую шутку. Лучше бы конечно сделать ее весьма медленной, если есть угроза использования слабых паролей, например как в RAR-е - порядка миллиона (если я правильно помню) итеративных операций. Проверка валидности 1 пароля должна занимать где-то 100 миллисекунд. Тогда для валидного пользователя это незаметно, а вот злоумышленнику проверить хотя бы 2^30 паролей займет 4 года. В-общем, решай сам.
OLS по первому: srand+time+rand - я так понимаю не хороший rnd? по третьему: первый блок - это собственно данные, второй блок - это весь или половина блока заполненного случайными значениями (т. е. блок для проверки валидности ключа)? Я правильно понял?
Извини мне мое незнание конкретных платформ и языков программирования, но я не понимаю твой язык ... Про то как ты хранишь собственно зашифрованные данные, я вообще ничего не говорю. Я описываю только возможную процедуру "предпроверки" валидности пароля. первый блок (пусть p[0-63]) - это случайные данных от rnd второй блок (пусть c[0-15])- это частичка от блока "c[0-63]", который равен c[0-63]=CRYPT(p[0-63], key) ведь для проверки достаточно снова зашифровать "p[0-63]" (а он прилагается к файлу полностью) и сравнить соответствующую часть (биты 0-15) с прилагаемым к файлу блоком c[0-15] P.S. Отвлеченно говоря, а тебе ради чего вообще нужна предпроверка валидности пароля ?
OLS функции из стандартной библиотеки Си. Ага: первый блок чистый (заполненный случайными числами), второй небольшая часть уже закриптованого первого блока. Все понял спасибо! Ну к примеру файлом в 1-4 гб сегодня ни кого не удивишь, и к примеру ждать расшифровки такого файла чтобы сравнить md5 или crc, слишком долгий и утомительный процесс, при условии что пароль был забыт. А так предварительно хоть программа сможет определить валидность ключа прежде чем весь файл будет расшифрован.
