Быстро зашифровать большой файл. Чем?

openssl

TrueCrypt?

openssl

Думал об этом. Вроде бы не слишком удобно. Для TrueCrypt придется сначала создавать зашифрованный «раздел», а потом уже копировать туда файл, не?

Почему в толксах? Шёл бы ты сначала в гугл.

Был там.

Да, но это для большого количества файлов это может быть быстрей.

gnupg, openssl, aespipe, тысячи их.

Там такое текстовое поле есть, вводишь в него всё, что захочешь, нажимаешь Enter, далее начинается магия.

В педивикии не видно: для больших файлов годится?

У меня всегда в такий случаях возникает проблема со скоростью НЖМД или количеством ядер процессора. Что есть быстро?

Ты сегодня открыл для меня целый новый мир. :D

Имелось в виду, что важна скорее не непробиваемость, а скорость шифрования.

Use XOR, Luke!

не шифруй вообще, тогда скорость шифрования будет стремиться к бесконечности, а время, затраченное на шифрование будет равно 0.

Имелось в виду, что важна скорее не непробиваемость, а скорость шифрования

Ну, замени все нули на 1, а 1 на нули.

Use XOR, Luke!

+1. Особенно если сгенерировать/придумать ключ, который сопоставим по длине с файлом. Например, генерить его заранее выбранной реализацией рандома с заранее выбранным сидом, который и будет фактическим ключом.

Было бы здорово. Но так тоже нельзя. Терабайтный облачный диск mail.ru не должен понимать что именно у меня на нем лежит.

Я уже предлагал в треде про mail.ru приюзать для шифрованных бэкапов тот же rar с нормальным паролем. Считай, AES нахаляву, который можно развернуть почти на любой машине в мире.

Размер одного файла будет > 500 мег. Их будет много. Желательно, чтобы программа была межплатформенной.

GnuPG. Другого не бывает. При чём нет никакой разницы, симметричное или асимметричное, шифрование в gpg _всегда_ симметричное, ЕМНИП AES256

Файл шифруется случайным паролем, а вот этот пароль шифруется выбранным алгоритмом. Если файл больше 1М, то нет абсолютно никакой разницы, каким алгоритмом ты шифруешь пароль.

Собственно почему не должно годиться? А скорость от выбранного алгоритма зависит и от опций, с которыми openssl скомпилирован

Если таким образом зашифровать кусок видео, легко будет его как-то дешифровать?

gpg -c file

что может быть проще?

тогда убери

важна скорее не непробиваемость, а скорость шифрования.

и юзай ssl

Имелось в виду, что важна скорее не непробиваемость, а скорость шифрования.

на современных CPU скорость не имеет значения. Любой SSD тупит намного сильнее, потому не забивай голову ерундой. Скорость имеет значение лишь на серверах, которые отдают 9001ому клиенту файл (даже один и тот же, но зашифрованный для каждого по своему, с помощью например SSL/TLS)

Если таким образом зашифровать кусок видео, легко будет его как-то дешифровать?

Давайте я подытожу. То есть Вы шифруете видео размером около 500 мб, хотите, чтобы оно было надёжно зашифровано и всегда доступно для воспроизведения?

Интересная мысль.

Да, это куски больших видеофайлов.

gpg -c file что может быть проще?

gpg file

проще потому, что не нужно вводить пароль, достаточно ввести имя получателя.

Создай зашифрованый zip архив без сжатия

Только надо посмотреть заранее, какой алгоритм шифрования используется в конкретной реализации ZIP-а.

Если таким образом зашифровать кусок видео, легко будет его как-то дешифровать?

всё зависит от длинны ключа. Если длинна ключа совпадает с длинной файла — noway. Если она меньше — это элементарно, Ватсон (man пляшущие человечки, там Холмс даёт мастеркласс)

И не думай, что получить случайный ключ очень просто: чтение /dev/random тебя отрезвит. А вот /dev/urandom не подходит.

Посему XOR в чистом виде никогда НЕ применяют, а используют XOR не с прямо с ключом, а с некоторой необратимой функцией от неизвестного врагу ключа. Можешь например XORить от md5 многократно применённой сама к себе. Вот только это дольше AES256, и нет аппаратной поддержки. За то есть большие радужные таблицы, увы...

man zip

THIS IS INSECURE!

перевести, или сам догадаешься?

man zip

Юзайте 7zip, там AES-256.

Только надо посмотреть заранее, какой алгоритм шифрования используется в конкретной реализации ZIP-а.

хреновый. И только один. Потому-что если туда вкорячить новый, то архивы нельзя будет открыть старым распаковщиком. А зачем такой zip нужен, если есть WinRAR и GnuPG(ВНЕЗАПНО: gpg тоже сжимает файлы)

Тут все-таки имеет значение время обработки. Если pgp будет шифровать такой файл весь день, то придется отказаться в пользу чего-то менее безопасного.

Юзайте 7zip, там AES-256.

зачем мне это твоё маздайное говно? Чем оно лучше GnuPG?

Каким оно боком маздайное? Всю жизнь юзал его в линуксе без всяких проблем.

Чем оно лучше GnuPG?

Тем, что является просто архиватором, а не специализированной утилитой. Это достаточно полезно для сокрытия самого факта шифрования.

используй любой архиватор с паролем и все, содержимое архива без пароля проверит не возможно

Если pgp будет шифровать такой файл весь день, то придется отказаться в пользу чего-то менее безопасного.

слушай, что ты паришься? Тебе же для mail.ru надо? Поверь мне, нет никакой разницы, чем ты будешь шифровать. Это дерьмо всё равно жрать будет больше и времени и ресурсов. В РАЗЫ.

Сам попробуй, и сравни. Возьми зашифруй файл и отправь его на мылору. Нет абсолютно никакой разницы, чем ты шифровать будешь. Хоть самописным велосипедом на php (:

XOR

Каким оно боком маздайное? Всю жизнь юзал его в линуксе без всяких проблем

очевидно «вся жизнь» у тебя очень недолгая.

Тем, что является просто архиватором, а не специализированной утилитой. Это достаточно полезно для сокрытия самого факта шифрования.

кто-то тебе мешает прилепить зашифрованный файл в конец обычного?

ну учись, детка:

$ cat >message.txt
тестовое сообщение
CTRL+D
$ gpg --recipient emulek --encrypt message.txt
$ cat LEXX_-_2x01_-_Mantrid.\(DVDRip.Hattak.512x384x29\,97.Rus.by.TV6.RSFDrive.com\).avi message.txt.gpg >test.avi
$ tail -c636 test.avi >test.gpg
$ gpg --decrypt test.gpg 

Необходим пароль для доступа к секретному ключу пользователя: "emulek <emulek.bx@gmail.com>"
бла-бла-бла
тестовое сообщение

при этом файл test.avi отлично работает. Там первая серия LEXX'а. Можешь сам проверить. MPlayer отлично показывает.

архиватором жми, ага. Это если надо «быстро».

XOR

ещё один неуч...

Пафоса много, а толку ноль. Ты ещё и касательно XOR сел в лужу. По факту XOR с длинным ключом является весьма эффективным и очень быстрым методом. Хочешь опровергнуть — приведи хотя бы одну практически успешную атаку для XOR-шифрования с ключом длины >1e6 бит. Я уж не говорю о случае, когда длина ключа >= длины файла.

Если нужна скорость, смотри в сторону openssl+rc4. Это если у процессора нет аппаратной поддержки AES.

По факту XOR с длинным ключом является весьма эффективным и очень быстрым методом

а где ты ключ-то возьмёшь? По факту — да. Отличный метод. Если ключ УЖЕ есть.

Хочешь опровергнуть — приведи хотя бы одну практически успешную атаку для XOR-шифрования с ключом длины >1e6 бит. Я уж не говорю о случае, когда длина ключа >= длины файла.

разве так сложно прочитать первые 1e6 бит из /dev/random? Вот возьми, и прочитай. Потом возвращайся, если доживёшь конечно...

Ну и ещё вопрос в том, где ты этот ключ будешь ХРАНИТЬ? Нахрена нужен терабайтное хранилище на маилрушечке, если у тебя ключ(и) к нему занимает ровно терабайт? Может я дурак, и не понимаю?

PS: касательно атаки: XOR ломается атакой по известному тексту. Ну например, если это текстовый файл, то тебе известно, что там часто встречается пробел с кодом 32. Если ключ имеет длину M байтов, то велика вероятность появления одного и того же байта через каждые M символов. Т.е. если в ключе байт №0 равен 0xFF, и всего 100 байт в ключе, то вероятность появления байта 0xDF в каждом сотом байте велика, и равна вероятности появления пробела (0x20). Так мы вычислим длину ключа. После этого можно посчитать распределение(по частоте) всех байтов №0, байтов №1 и т.п. И подобрать искомый ключ.

В avi пробелов конечно нет, но структура фреймов хорошо известна, и отлично документирована. Потому подобрать ключ сможет даже школьник, если конечно он короче файла хотя-бы вдвое.

Потому подобрать ключ сможет даже школьник, если конечно он короче файла хотя-бы вдвое.

м... Про «вдвое» я конечно погорячился. Надо что-бы ключ хотя-бы сотню раз ложился в avi. Тогда успех взлома почти гарантирован.

видеофайлы уже сжаты

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

В случае чего хардовый ключевой носитель легко и просто уничтожается.