LINUX.ORG.RU

Ответ на: комментарий от StReLoK

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

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

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

StReLoK ☆☆ ()

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

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

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

CYB3R ★★★★★ ()

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

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

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

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

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

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

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

Use XOR, Luke!

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

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

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

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

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

Sadler ★★★ ()

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

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

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

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

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

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

тогда убери

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

и юзай ssl

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

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

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

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

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

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

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

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

gpg file

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$ 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 отлично показывает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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