LINUX.ORG.RU

короче,

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

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

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

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

/thread

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

emulek ()

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

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

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

Умоляй меня!

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

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

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

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

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

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

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

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

Eddy_Em ☆☆☆☆☆ ()
gpg \
   --cipher-algo AES256 \
   --digest-algo SHA512 \
   --s2k-mode 3 \
   --s2k-digest-algo SHA512 \
   --s2k-count 31923643 \
   --s2k-cipher-algo AES256 \
   --compress-algo 0 \
   --output /file-crypt \
   --symmetric /file
Umberto ★☆ ()
Ответ на: комментарий от emulek

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

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

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

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

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

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

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

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

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

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

ненадёжно

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

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

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Sadler

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--s2k-cipher-algo

--symmetric

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

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

--compress-algo 0

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

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

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

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

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

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

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

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

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 и т.п.

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

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

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

--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.

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

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

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

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

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

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

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

The default cipher is CAST5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Umberto ★☆ ()
Ответ на: комментарий от manntes-live

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

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

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

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

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

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

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

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

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

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

Эти буквы?

--compress-algo 0

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

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

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

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

Umberto ★☆ ()
Ответ на: комментарий от manntes-live

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

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

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

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

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

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

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

emulek ()

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

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

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

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

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

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

ktulhu666 ☆☆☆ ()

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

ktulhu666 ☆☆☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.