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

короче,

openssl aes-256-cbc -e -in infile -out outfile

два раза вводишь пароль

а для расшифровки

openssl aes-256-cbc -d -in infile -out outfile

/thread

ну тут не в сжатии задача, а в шифровании же.

gpg

Ключ хранится на хардовом ключевом носителе, генерировать можно различными методами, хоть с помощью того же теплового шума

ты разве не знаешь, что для неуязвимости XOR ключ должен быть

1. уникальный для каждого файла

2. иметь размер не менее размера файла

3. быть полностью непредсказуемым.

Тогда, и только тогда XOR не ломается. Если хотя-бы одно из условий не выполнено, XOR уязвима.

Да, частотная атака есть, но это работает только при известной структуре, коротком ключе и достаточной степени удачи

нельзя быть немножко беременной, увы. Если у тебя есть дыра, у тебя есть дыра.

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

значит в твоём алгоритме ошибка. Увы...

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

а если у бабушки был-бы... Ну ты знаешь. ТС шифрует файлы для отправки на мылору. CP наверное со своим участием. О какой фрагментации ты сейчас говоришь?

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

давай договоримся не врать, да? Я посмотрю на тебя, как ты «легко и быстро» уничтожишь SSDмассив на терабайт (:

Не знаю как тебе, а мне лучше паяльник в жопу, чем ТАКОЕ творить... Вот копеечная флешка с ключом на 2048 бит — совсем другое дело. Жалко конечно, но если в противном случае ко мне применят РК, то уничтожу без всяких колебаний.

openssl aes-256-cbc -e -in infile -out outfile

два раза вводишь пароль

а вот gpg шифрует тем же алгоритмом, только никаких паролей вводить не нужно. Это проще, надёжнее и быстрее. А ещё можно автоматизировать, и например хранить так бекап в облаке. Я так и делаю.

нельзя быть немножко беременной, увы. Если у тебя есть дыра, у тебя есть дыра.

В данном случае нужно здраво оценивать применимость этой дыры. Мы же рассматриваем систему не только с т.з. защищённости, но и с т.з. простоты и затрат ресурсов CPU.

Я посмотрю на тебя, как ты «легко и быстро» уничтожишь SSDмассив на терабайт (:

Можно обойтись флешкой на 32GB. Да, это, возможно, будет не так быстро, но едва ли у ТСа больше процессоров с его участием.

значит в твоём алгоритме ошибка. Увы...

Да нет, просто я использовал статистику для файла на основе N-грамм, а не знал заранее конкретный формат данных. Это получается несколько сложнее.

Действительно очень быстро. Лучший вариант, по-моему. Спасибо.

В данном случае нужно здраво оценивать применимость этой дыры. Мы же рассматриваем систему не только с т.з. защищённости, но и с т.з. простоты и затрат ресурсов CPU.

хватит уже. Зафелился — значит зафейлился. Достаточно изворачиваться, будь мужиком. Я сразу скажу — я подлец. Я прекрасно знал про XOR, и её недостатки.

Можно обойтись флешкой на 32GB. Да, это, возможно, будет не так быстро, но едва ли у ТСа больше процессоров с его участием.

вот началось опять... Ну всяко gpg будет быстрее, а 32Гб можно и получше применить, чем хранить там ненужный мусор.

Да нет, просто я использовал статистику для файла на основе N-грамм, а не знал заранее конкретный формат данных. Это получается несколько сложнее.

ну это твоя проблема, что ты чего-то не знал. Твоё незнание это не пруф того, что врагу это тоже будет неизвестно.

Действительно очень быстро. Лучший вариант, по-моему. Спасибо.

и насколько этот вариант медленнее чем gpg?

Сгенерировать байт 256 из /dev/random и ими поксорить. Хотя, таки проще и надежней будет сгенерировать эти 256 байт как sha256 от пароля.

хватит уже. Зафелился — значит зафейлился. Достаточно изворачиваться

Умоляй меня!

Я прекрасно знал про XOR, и её недостатки.

Которые не проявляются при нормальном применении.

Ну всяко gpg будет быстрее

Быстрее XOR-а? Да ну?

Твоё незнание это не пруф того, что врагу это тоже будет неизвестно.

Опять же, при нормальном ключе никаких проблем не возникнет.

Какие у ксора могут быть недостатки? И разве gpg не делает то же самое?

нельзя быть немножко беременной, увы. Если у тебя есть дыра, у тебя есть дыра.

Чушь какая. AES сломан, SSL сломан, SHA1, который в /dev/random используется тоже сломан. Везде дыры, как дальше жить?

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

Ну-ка выйди к доске и интерпретируй ключи

--cipher-algo TWOFISH --s2k-cipher-algo TWOFISH

XOR

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

Ну... Это уж больно просто и по-детски...

Сгенерировать байт 256 из /dev/random и ими поксорить.

говорю-же, это ненадёжно. Вскрывается тривиально, ибо статистическое распределение каждого байта не меняется, если ключ в 256 байт, и ты берёшь каждый 256й байт файла. Т.е. если в исходном тексте у тебя 17% пробелов, то в зашифрованном файле у тебя будет 17% какого-то другого байта. Если скажем этот байт 0xDF, то очевидно, что в ключе на этом месте стоит 0xFF.

ненадёжно

Ломается только в том случае, если "ломатель" знает кусок незашифрованного файла. А это маловероятно. Если боишься статистики, то поксорь дважды — ключами разной некратной длины. Только смысла никакого не будет.

А еще можно перед каждым очередным "ксориванием" циклически двигать эти 256 символов ключа.

Которые не проявляются при нормальном применении.

необходимые и достаточные условия я уже перечислил.

Ну всяко gpg будет быстрее

Быстрее XOR-а? Да ну?

конечно. Ибо для файла в 320Мб тебе не только надо выполнить 320Mb XOR'ов, но ещё и 10 раз прочитать 32Гб с флешки. Попробуй, тебе «понравится»...

Опять же, при нормальном ключе никаких проблем не возникнет.

при нормальном ключе конечно всё будет работать. Но ты так и не ответил, где хранить ключ в терабайт длинной? И как его сгенерировать? Стандартные методы генерации не подходят, т.к. очень медленные.

Какие у ксора могут быть недостатки? И разве gpg не делает то же самое?

не тоже самое. Gpg «создаёт» каждый раз «новый ключ» для каждого блока данных(это я тебе очень сильно упростил логику работы конечно).

Но ты так и не ответил, где хранить ключ в терабайт длинной? И как его сгенерировать?

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

Ибо для файла в 320Мб тебе не только надо выполнить 320Mb XOR'ов, но ещё и 10 раз прочитать 32Гб с флешки.

Для этого и придумали RAM. И, кстати, 10 раз читать вовсе не нужно ;) Даже один раз целиком читать не нужно для 320Мб.

--s2k-cipher-algo

--symmetric

ВП детектед. Откуда у тебя «секретный ключ» на симметричном шифровании?

Ты лучше набери gpg --version, и выбери самый плохой метод симметричного шифрования. Он и будет скорее всего самым быстрым. Можно и протестировать конечно. Потому-что если CPU умеет AES, то этот неплохой метод будет довольно быстрым.

--compress-algo 0

эта опция практически не влияет на время, но опускает защиту ниже плинтуса.

Чушь какая. AES сломан, SSL сломан, SHA1, который в /dev/random используется тоже сломан. Везде дыры, как дальше жить?

А если у тебя руки из жопы, то жить лучше не надо. Для всех лучше, и для тебя тоже.

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

*устало* учись чему? Этой унылой псевдо-стеганографии?

Учись, детка:

gpg --recipient emulek --encrypt /somefile1
gpg --recipient emulek --encrypt /some/another_file2

dhex /somefile1.gpg /some/another_file2.gpg

       0     85 04 0e 03 37 a3 f8 0e  25 a4 40 b5 10 0f ff 50  ca 3f 0d 65 dc 1a c2 5b  ef 13 ab e5 3b 51 32 14 c6     
---
       0     85 04 0e 03 37 a3 f8 0e  25 a4 40 b5 10 0f ff 5b  83 c0 de 09 3e 2d 23 89  68 8f 87 cf c7 65 a9 11 3a     

             85 04 0e 03 37 a3 f8 0e  25 a4 40 b5 10 0f ff

Или так

gpg --output /somefile1.sym --symmetric /somefile1
gpg --output /some/another_file2.sym --symmetric /some/another_file2

dhex /somefile1.sym /some/another_file2.sym

       0     8c 0d 04 0a 03 0a 70 52  97 28 50 58 4e 15 d0 d2  e9 01 e5 8d 03 0f 17 13  31 71 3b 63 95 5a 23 36 bc
---
       0     8c 0d 04 0a 03 0a bb 1a  f8 f0 c5 ef ba 7a d0 d2  eb 01 63 16 b7 bc 7a 8f  ff 61 db 69 03 f0 e0 28 c0

             8c 0d 04 0a 03 0a

Любой криминалист-первокласник знает что такое 8c 0d 04 0a 03 и т.п.

Ну-ка выйди к доске и интерпретируй ключи

с удовольствием:

--cipher-algo name Use name as cipher algorithm. Running the program with the command --version yields a list of supported algo- rithms. If this is not used the cipher algorithm is selected from the preferences stored with the key. In gen- eral, you do not want to use this option as it allows you to violate the OpenPGP standard. --personal-cipher- preferences is the safe way to accomplish the same thing.

--s2k-cipher-algo name Use name as the cipher algorithm used to protect secret keys. The default cipher is CAST5. This cipher is also used for conventional encryption if --personal-cipher-preferences and --cipher-algo is not given.

Ты точно правильное сообщение процитировал?

А это маловероятно.

а то я не знаю, какой формат и структура avi файлов! Самому не смешно?

поксорь дважды — ключами разной некратной длины. Только смысла никакого не будет.

А еще можно перед каждым очередным «ксориванием» циклически двигать эти 256 символов ключа.

сгинь. Зачем эти велосипеды, если есть AES256? Который работает заведомо быстрее, чем ты будешь этот файл читать.

The default cipher is CAST5

Ну и намёк, что AES меняется ключами легко.

ВП детектед. Откуда у тебя «секретный ключ» на симметричном шифровании?

Нераспарсил, что не нравится?

Ты тоже не ответил, зачем тебе ключ в терабайт длиной.

не мне, а ТСу. Хранить файлы в облаке майлру. Это он так сказал. Он хочет файлы зашифровать, и сохранить. А вот GnuPG для него «медленно».

Генерируется на ура хардовым генератором случайных чисел, либо софтово с помощью CUDA

сразу видно, что ты не работал ни с тем, ни с другим. Хардовый генератор работает отнюдь не быстро, а очень медленно. Он хороший, но для таких целей абсолютно негоден. Ну а если у тебя есть CUDA или ASIC(что ещё лучше), то на кой ляд тебе генерить случайный ключ, если быстрее просто взять, и зашифровать? Точнее — по времени одинаково, но ключ тут не нужно хранить, он сам в процессе создаётся.

Для этого и придумали RAM.

если-бы у ТСа был террабайт RAM, то я сильно сомневаюсь, что он юзал-бы бесплатный терабайт с маилру. Это всё равно как если миллионер будет кушать бесплатную еду, которую бомжам раздают. Всему есть предел...

Если ещё учесть, что несколько повторений ключа вполне допустимы

Если ты про вариации на тему шифра Вернама, то повторения граммы категорически недопустимо.

сразу видно, что ты не работал ни с тем, ни с другим.

Бла-бла-бла.

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

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

если-бы у ТСа был террабайт RAM

О терабайте ТС не говорил, только о некотором количестве 500мб файлов. Скажем, 8 ГБ есть сегодня у многих.

Любой криминалист-первокласник знает что такое 8c 0d 04 0a 03 и т.п.

1. ну и что это доказывает? Разве в avi такого быть не может?

2. ну отрежь сигнатуру, делов-то? Там только первые байты одинаковые. Вот их и отрежь, не вижу проблемы. Там записана информация о версии программы, об алгоритмах и прочее такое. Т.е. то, что можно узнать без расшифровки. Ну и id реципиентов тоже записан. Мой например. Ты же для меня шифровал? Вот и получилось одно и то же в начале. Что тут удивительного? Эту информацию хранить не обязательно, если ты прячешь.

ВП детектед. Откуда у тебя «секретный ключ» на симметричном шифровании?

Нераспарсил, что не нравится?

мне непонятно, на кой леший ты задаёшь алгоритм, который всё равно не применяется?

Ну и намёк, что AES меняется ключами легко.

а с какой целью ты мне это доказываешь? Я это и так знаю.

Внезапно по теме: http://www.howtogeek.com/121737/how-to-encrypt-cloud-storage-on-linux-and-win...

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

а вот кто тебя заставлял юзать IV «фиксированный и небольшой длинны»? Юзай IV размером 2048 бит, такой подобрать невозможно сегодня. А кстати рандомный ключ полностью знать и не нужно. Кто сказал, что тебе нужно весь файл расшифровать?

О терабайте ТС не говорил

иди и почитай, вот для слепых ссылка: Быстро зашифровать большой файл. Чем? (комментарий)

мне непонятно, на кой леший ты задаёшь алгоритм, который всё равно не применяется?

А, да то кусок кода, для переуказания дефолтов, разных режимов, тем не менее ничего плохого оно не делает.

оно конечно в тему, но для ТСа не пойдёт. Увы. EncFS не умеет работать с хранилищами, доступ в которые исключительно через закрытый гуй. Ну и потом вопрос о времени обновления криптоконтейнера в 1Тб до сих пор открыт.

тем не менее ничего плохого оно не делает.

я разве говорил, что оно плохое делает?

ВП значит «взаимоисключающие параграфы».

Остальные буквы в том посте не осилил, да?

А, у этого хранилища даже интерфейса нормального нет? Тогда оно не нужно.

Остальные буквы в том посте не осилил, да?

Эти буквы?

--compress-algo 0

эта опция практически не влияет на время, но опускает защиту ниже плинтуса.

Ну да, тут ты трагетизируешь об отсутствии сжатия как лёгкого каша-алгоритма над открытыми данными, а чуть выше предлагаешь

Потому-что если CPU умеет AES, то этот неплохой метод будет довольно быстрым.

Однораундовый процессорный AES, который и близко не лежит с полнораундовыми.

А, у этого хранилища даже интерфейса нормального нет?

яхз. Некоторые говорят — есть и работает, некоторые — есть, но не работает...

Ну да, тут ты трагетизируешь об отсутствии сжатия как лёгкого каша-алгоритма над открытыми данными

переведи пожалуйста на русский.

Однораундовый процессорный AES, который и близко не лежит с полнораундовыми.

а эту фразу я понял, но не смог нагуглить подтверждения.

Если тебе нужна безопасность - используй стойкие алгоритмы.

Если же ты просто хочешь, чтобы Иван Петрович в офисе mail ru не дрочил на 50 МПиксельные панорамные raw фотки твоего любимого кота - напиши свой простенький гпсч( можно даже взять сишный rand() ) и используй поточное шифрование. Будет быстро.

Но опять же. Не думай, что ты умнее математиков. Особенно на их поле.

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

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

На современных процессорах даже без аппаратной поддержки получается несколько сотен мегабайт в секунду стойкими шифрами, чего Вы свой велосипед изобретаете? Зашифровать файл можно утилитами, которые описаны выше, только почти всё ПО для шифрования файлов создаёт новый файл и пишет в него. А вот исходный файл нужно завайпить (иногда такой функционал входит в программу шифрования).