LINUX.ORG.RU
ФорумAdmin

Заархивировать большие файлы с паролем


1

3

Есть файлы более 30гб но менее 40гб, нужно их заархивировать и запаролить. Пока нашел одно средство (zip), но как оказалось, оно не поддерживает файлы такого размера. Других вариантов пока найти не могу. Прошу вашей помощи. Система RHEL 5.5 x64



Последнее исправление: worsvch (всего исправлений: 1)
Ответ на: комментарий от MrKooll

Сей эксперт еще про salt не прочитал.

salt тут каким местом приплёл?

emulek
()
Ответ на: комментарий от crowbar

ну тогда я думаю понятно, что два блока «qweqweqwe» не будет отображаться в два «йцуйцуйцу».

будут с вероятностью 1/256, если добавить 8 бит.

emulek
()
Ответ на: комментарий от emulek

Не будут, если каждый следующий блок файла перед шифрованием xor'ится с результатом шифрования предыдущего. CBC называется, наверное знаешь такую аббривеатуру.

crowbar
()
Ответ на: комментарий от crowbar

дык тут предлагали IV из одного байта. А с нормальным IV конечно нечего ловить.

Но всё равно, если удельная энтропия маленькая(типа шифрование /dev/zero), то без сжатия, даже с нормальным IV, вскрыть можно. А что там на входе будет — неизвестно, может (почти)/dev/zero. Быстрее пожать немножечко, всё равно энтропию считать необходимо, а если мы её УЖЕ посчитали, то это уже почти готовое сжатие(после подсчёта энтропии достаточно выкинуть ненужные биты, в которых энтропии нет).

emulek
()

Если это всё потом передается по сети кому-то другому, то альтернатив gpg --encrypt по сути нет.

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

tar cpzf archive.tar.gz /some/folder
openssl enc -aes256 -in archive.tar.gz -out archive.tar.gz.aes
Как ни странно, если указать для gpg --symmetric такой же алгоритм шифрования, то он будет работать медленнее. Хотя, конечно, никто не запрещает заюзать и gpg-ключи. Но тут палка о двух концах - для асимметричного шифрования надо приватный ключ отдельно бэкапить так, чтобы его не стащили, для симметричного надо запомнить/надежно записать пароль. Лично я для бэкапов использую пароль, который я очень хорошо помню.

lu4nik ★★★
()
Ответ на: комментарий от Suntechnic

Но, увы, вовсе не обязательно, как тут пытаются насвистеть.

С тем же успехом, простейшее изменение имени файла, так же таки дает плюс к стойкости. Иначе откуда злоумышленник узнает что это за файл и на какие именно блоки данных нужно производить атаку.

TEX ★★★
()
Последнее исправление: TEX (всего исправлений: 1)
Ответ на: комментарий от TEX

С тем же успехом, простейшее изменение имени файла, так же таки дает плюс к стойкости.

Нет. Я не криптоаналитик и всех тонкостей не расскажу, но там другие методы. Переименование файла тебе точно не поможет.

Suntechnic ★★★★★
()
Ответ на: комментарий от Suntechnic

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

Если таковая есть - то ей ваше сжатие перед шифрованием что семечки.

TEX ★★★
()
Ответ на: комментарий от TEX

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

Suntechnic ★★★★★
()
Ответ на: комментарий от Suntechnic

Например как раз известен тип исходных данных.

Как кролик из шапки фокусника ? Известен и всё тут. Отличный! отличный метод.

Обычно есть ряд доп-сведений и возможностей.

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

Ан нет, вобьют себе в голову «обязательно», и будет топикстартер 30Гб сжимать пару часов. Для +0.00001% к «стойкости» и фанатов «обязательности»

TEX ★★★
()
Последнее исправление: TEX (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.