tar -cpzf our.tar.gz /home/user/folder
gpg --encrypt out.tar.gz

Про распаковку сам догадаешься :)

Такой вариант я пробовал, очень много по времени, на каждый файл уходит порядка одного часа. Учитывая что файлов под 80, получаем в пределах 80 часов, то есть трое с лишним суток. Сжимать кстати мне не обязательно, хватает простого архивирования

Такой вариант я пробовал, очень много по времени, на каждый файл уходит порядка одного часа. Учитывая что файлов под 80, получаем в пределах 80 часов, то есть трое с лишним суток. Сжимать кстати мне не обязательно, хватает простого архивирования

А ты что ожидал от такого объема? 5 минуточек?

Смысл такой, сделать что-то с файлами (запаролить и т.д. и т.п.), чтобы даже если кто-то их и заполучил, то ничего с ними не смог бы сделать.

Такой вариант я пробовал, очень много по времени, <...> Сжимать кстати мне не обязательно

Убери сжатие и добавь физический накопитель. Поскольку у тебя копирование неизбежно, выполняй его между разными накопителями.

Для уменьшения дисковых операций не сохраняй файл архива, а передавай на gpg через pipe.

Ну тогда просто gpg --encrypt.

Для уменьшения дисковых операций не сохраняй файл архива, а передавай на gpg через pipe. это как?

Как-то так:

tar cf - oldfilename | gpg --encrypt --output /path/to/newfilename

Только проверить, а то я так, из головы писал...

gpg --encrypt.

если файлов много, перед ним tar.

если мало gzip, то gpg --compress-level n --bzip2-compress-level n

если и этого, то перед шифрованием xz (но шифровать всё равно будет со сжатием)

Размер не имеет значения.

Сжимать кстати мне не обязательно

сжимать обязательно для надёжного шифрования.

Скорость увеличить нельзя. Увы. В zip не шифрование, а говно.

Смысл такой, сделать что-то с файлами (запаролить и т.д. и т.п.), чтобы даже если кто-то их и заполучил, то ничего с ними не смог бы сделать.

вариант с zip отпадает, если нашедший не полный дебил.

Есть вариант с WinRAR, но он ещё дольше, а про надёжность — я не в курсе. Исходники Рошал скрывает.

Т.ч. никаких вариантов кроме gpg.

Для уменьшения дисковых операций не сохраняй файл архива, а передавай на gpg через pipe. это как?

gpg --output - --recipient emulek --encrypt file.txt >oter_disk/file.gpg

вроде правильно, но зачем ты 1 файл таришь?

Это понял так, что у него большие файлы и он их каждый обрабатывает отдельно:

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

Т.ч. никаких вариантов кроме gpg.

Прям таки. Тот-же openssl никто не отменял.

man 1 openssl

OpenSSL is a cryptography toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) network protocols and related cryptography standards required by them.

не, ты конечно можешь накостылить «передачу файла из Сети localhost в Сеть localhost», Linux это позволяет, но зачем?

не, ты конечно можешь накостылить «передачу файла из Сети localhost в Сеть localhost», Linux это позволяет, но зачем?

Спасибо посмеялся. Чтоб больше так народ не веселить прочитай man enc для начала.

А то действительно начнешь франкенштейнов сооружать с пересылкой файлов через localhost.

не, ты конечно можешь накостылить «передачу файла из Сети localhost в Сеть localhost», Linux это позволяет, но зачем?

Спасибо посмеялся. Чтоб больше так народ не веселить прочитай man enc для начала.

ты вправду думаешь, что локальные файлы кто-то кроме тебя шифрует enc(1)?

Конечно. И через локалхост нисего передавать не нужно. Еще можешь man smime прочитать для общего развития. В openssl много чего есть - тебе надолго чтива хватит.

Конечно. И через локалхост нисего передавать не нужно.

вот ты через него и передаёшь.

Но это всё к теме не относится, ты так и не объяснил, чем тебе GnuPG не понравилась? А про openssl я и так в курсе, что оно есть. Мало того, даже юзаю в своём софте (я же не идиот, что-бы самому md5 считать).

Значит по порядку.

Изначально я ответил на смелое заявление «никаких вариантов кроме gpg.». И указал что это совсем не так.

Теперь почему используется enc, а не gpg:

1. openssl гораздо больше распространен и вероятность что на удаленной машине есть только gpg и нет openssl стремится к нулю.

2. openssl enc гораздо гибче чем gpg --symmetric

3. openssl имеет лучшую производительность (по крайней мере в случае стандартного aes128-cbc).

сжимать обязательно для надёжного шифрования.

Сжатие перед шифрованием никакого отношения к надежности шифрования не имеет.

сжимать обязательно для надёжного шифрования.

Не обязательно. У него там мультимедиа какая-то походу. Сжатие не даст сколь-нибудь значимого снижения избыточности.

Сжатие перед шифрованием никакого отношения к надежности шифрования не имеет.

Очень даже имеет. Сжатие снижает избыточность первоначального кодирования и соответственно увеличивает стойкость последующего шифрования к любым атакам.

1. openssl гораздо больше распространен и вероятность что на удаленной машине есть только gpg и нет openssl стремится к нулю.

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

Если у тебя нет GnuPG, то тебе не нужно шифровать/подписывать файлы. Всегда ваш, К.О. Но ты ≠ все.

2. openssl enc гораздо гибче чем gpg --symmetric

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

3. openssl имеет лучшую производительность (по крайней мере в случае стандартного aes128-cbc).

это невозможно. Реализация алгоритмов стандартная, здесь никто не изобретает велосипедов с квадратными колёсами.

Ну и потом, я уже ссылался на zip, там скорость ещё выше, и намного. Никто не против. Могу ещё и порекомендовать шифрование в PDF от адобы, там скорость шифрования бесконечно велика, на радость пользователям.

Сжатие перед шифрованием никакого отношения к надежности шифрования не имеет.

учи матчасть, детка.

Не обязательно. У него там мультимедиа какая-то походу. Сжатие не даст сколь-нибудь значимого снижения избыточности.

как раз даст. Да, сжатие никак не отразится на размере данных, т.к. фреймы(jpeg/mpeg) уже сжаты. Однако там между фреймами полно заголовков, которые хорошо известны. По ним и будет производится атака. Ну а сжатие эти все заголовки сожмёт в белый(непредсказуемый) шум.

Потому-то в GnuPG сжатие НЕ отключается, его можно только поменять (на bzip2).

Твой бред уже даже не интересно читать. Если надо «Заархивировать большие файлы с паролем» то наукообразный бред про нужность симметричного шифрования излагай другим пионерам.

GnuPG нужен когда тебе нужно OpenPGP. И все. В остальных случаях не нужен. Правда сомневаюсь что ты слышал про OpenPGP.

Прятать пароль в скрипте это вообще за гранью.

это невозможно. Реализация алгоритмов стандартная, здесь никто не изобретает велосипедов с квадратными колёсами.

Это вообще перл.

Иди в школу читать учебники. Надоел своим бредом.

Очень даже имеет

Нет

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

Шифрование которое зависит от избыточности исходных данных - хреновое шифрование

Да ты на пальцах объясни дядя

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

Твой бред уже даже не интересно читать. Если надо «Заархивировать большие файлы с паролем» то наукообразный бред про нужность симметричного шифрования излагай другим пионерам.

сам-то понял, что написал?

GnuPG нужен когда тебе нужно OpenPGP. И все. В остальных случаях не нужен. Правда сомневаюсь что ты слышал про OpenPGP.

я не удивлён, что ты всех вокруг считаешь дебилами, которые ничего ни о чём не слышали.

Прятать пароль в скрипте это вообще за гранью.

обычное дело, для таких Экспертов как ты.

Это вообще перл.

а ты просто трепло.

Иди в школу читать учебники. Надоел своим бредом.

детка, игнор там -->

По ним и будет производится атака. Ну а сжатие эти все заголовки сожмёт в белый(непредсказуемый) шум.

Еще раз для особо упоротых. Задача повышения энтропии входных данных != задаче сжатия данных. Это всего лишь одно из возможных решений.

Да ты на пальцах объясни дядя

предположим, у тебя есть ИДЕАЛЬНОЕ шифрование, которое ИДЕАЛЬНО шифрует. Теперь попробуй зашифровать строку ABCDEFG и строку ABCDEFG одним и тем же паролем. Предположим, у тебя получилось ФВЫГЫФФЙ в первом случае, а что получится во втором при условии, что алгоритм детерминирован?

Очевидно, что ФВЫГЫФФЙ.

Таким образом, ты можешь «расшифровать» ФВЫГЫФФЙ даже не только не зная пароля, но и даже алгоритма!

Это называется «атака по открытому тексту».

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

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

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

Само начало тоже можно сделать непредсказуемым, надо просто приписать к файлу скажем 1000 случайных символов, которые после дешифрования можно тупо отбросить. Тогда даже «начало» будет непредсказуемо.

Это называется «атака по открытому тексту».

Задача повышения энтропии входных данных != задаче сжатия данных. Это всего лишь одно из возможных решений.

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

Тогда даже «начало» будет непредсказуемо.

А еще можно тупо зашифровать дважды ага. Абсолютно пофигу каким образом ты повысил энтропию

Еще раз для особо упоротых. Задача повышения энтропии входных данных != задаче сжатия данных. Это всего лишь одно из возможных решений.

ты чё, Бабушкин? У тебя есть другие какие-то решения для повышения энтропии?

Дык ты рассказывай, а то мне они не известны.

Я не в курсе как там в твоей теории, но на практике ВСЕ программы сжатия работают одинаково:

1. предсказывают символ.

2. сравнивают с тем, который есть на самом деле.

3. вместо самого символа записывают его энтропию, т.е. символ длинной в разницу между п2 и п1. Если предсказано ТОЧНО, то записывается символ длинной 0 бит. Если предсказание 50/50, то длинна выходного символа 1 бит. Если вероятность правильного ответа 1/3, то на выход пишут 1.58496250072115618146 битов.

Т.о. предсказуемость каждого бита выхода равна в точности 1/2. Т.е. каждый бит непредсказуем, и его энтропия равна 1бит. (на практике конечно немного меньше, из-за кривого libastral и некоторой ошибки округления)

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

вот именно по этой причине в GnuPG могут использоваться _только_ gzip и bzip2, которые НЕ оставляют таких блоков.

А еще можно тупо зашифровать дважды ага

нет, нельзя. Если ты зашифруешь дважды два текста ABCDEFG и ABCDEFG, то ты получишь два других текста ВЫВАЦЫЫФЫВ и ВЫВАЦЫЫФЫВ, что никак не затруднит атаку. Также НЕ затруднит атаку и Over9000 раундов. Но достаточно всего N случайных бит в начале, и вероятность повтора будет 2**(-N).

Абсолютно пофигу каким образом ты повысил энтропию

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

вот именно по этой причине в GnuPG могут использоваться _только_ gzip и bzip2, которые НЕ оставляют таких блоков.

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

ты чё, Бабушкин? У тебя есть другие какие-то решения для повышения энтропии?

man скрамблер

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

что ты этим хотел сказать?

ты чё, Бабушкин? У тебя есть другие какие-то решения для повышения энтропии?

man скрамблер

ясно всё с тобой.

RAR

Да конечно

gpg2 --compression-algo=none -c zxc

По ним и будет производится атака

А cbc там для чего? Нормальные алгоритмы шифрования использовать надо, вот и все.

тьфу! Дай дураку хрустальный член…

Шифрование которое зависит от избыточности исходных данных - хреновое шифрование

А оно и не зависит. Просто при прочих равных сжатие данных таки дает плюс к стойкости.

Очевидно, что ФВЫГЫФФЙ.

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

Если мой алгоритм в начало данных допустим добавляет один случайный байт

то он не является детерминированным. И на выходе получается не однозначно ФВЫГЫФФЙ, а ровно 256 штук таких ФВЫГЫФФЙ. Это конечно значительно усложняет атаку, и об этом я писал выше(посл. абзац).

Тем не менее, криптостойкость сжатого файла всё равно ЗНАЧИТЕЛЬНО выше, а времени на это уходит очень мало.

Смысл такой, сделать что-то с файлами (запаролить и т.д. и т.п.), чтобы даже если кто-то их и заполучил, то ничего с ними не смог бы сделать.

Если нужна скорость то заворачиваем все в tar а он не жмет а просто все в один файл делает. и шифруем. тем же pgp но на больших объемах pgp медленный. есть конечно самописные решения для таких шифрований. но это уже подробнее если ты ко мне на почту постучишься.