Суть следующая. Хочу защитить бекапы, но не хочу, что бы ключ для расшифровки хранился на конечном устройстве.
Сейчас бекап шифруется скриптом, но сам ключ хранится в скрипте.
Искал варианты, нашел только gnupg. Но там все не очень удобно.Есть пара минусов.
1) Нужно хранилище ключей создавать, импортировать туда сертификаты.
2) Шифрует только файл, папку не зашифровать. Нужно отдельно в архив все сложить и уже потом шифровать.

Может есть вариант проще, типа...
Что ни будь консольное. Указать открытый ключ получателя и папку, он бы все зашифровал.

Сам себе вирус-шифровальщик

(0) линукс? конвеер не пойдет?

GNUPG

gnup вполне подходит для тебя, в нем есть командная строка, при этом в хранилище достаточно хранить только открытый ключ.

строку шифрования вставляешь в общий скрипт после бекапа

(2) К сожалению винда. В линуксе все красиво, в винде сложнее.

(4) (3) Я описал неудобства с gnupg
>строку шифрования вставляешь в общий скрипт после бекапа
Вот это не понял.

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

(6) бекап настраиваешь через джоб скуля, после добавляешь вызов команды системы и в нее командную строку для шифрования...

А если в строке поиска набрать
"программы для шифрования файлов из командной строки windows"?

(8) У меня сейчас так и сделано.
Но неудобно просто, кроме самого бэкапа sql нужно туда еще сложить файлы разные. для gnupg это нужно сначала запаковать в 1 файл. при том не забыть, что бы в хранилище gnupg был импортирован открытый сертификат получателя.
А сервер не один, и периодически меняются.
(9) Пробовал. Из опенсорсных под винду + командная строка нашел только gnupg.

(10) а в чем сложность запаковать предварительно перед шифрованием? в линуксе вообще обычная практика таром все собирать перед подбными процедурами

учитывая что тар это вообще утилита для бекапов изначально

(11) Нет сложности, сейчас так и делается. Но хочется удобства, что бы одна утилита все делала. И не думать, а есть ли 7zip на сервере, а правильно ли пути при упаковке указаны.

(13) а то надо будет думать "а установлена ли эта утилита? а правильная ли версия"?
в таких вещах как шифрование лучше использовать проверенные утилиты, даже если они не удобные
как показывает практика, комбайны все в одном нажми кнопку зачастую уязвимы

chiper.exe

https://www.white-windows.ru/kak-zashifrovat-fajly-v-komandnoj-stroke-windows/
Используется как раз открытое (ассиметричное) шифрование.

(0) Асимметричное шифрование для бэкапов непрактично. Обычно делают так: бэкап шифруют симметрично, симметричный ключ шифруют асимметрично и кладут рядом с бэкапом.

Кстати, по ссылке (16) винда делает именно так.

(17) это непрактично, т.к. у тебя есть ключ. Иметь ключ иногда очень непрактично

(16) Не. ищу все же опенсорсные варианты.

Извиняюсь. Одной проблемой с gnupg меньше. Не заметил утилиту gpgtar, она позволяет каталоги шифровать в tar.

(17) Ну у меня задача, как раз не хранить на сервере ключ для расшифровки.

(19) Непрактично из-за низкой производительности.

http://stackoverflow.com/questions/118463/ddg#118503

(20) "Не хранить на сервере ключ для расшифровки" в открытом виде вполне достаточно.

(21) Норм. 1,5 гига где то 2 минуты.

(13) 7zip работает вообще без установки

(0) акронис из коробки без всех дополнительных приблуд это умеет делать. Покури шифрование по ГОСТ 28147-89 - там в настройках его указываешь и все.

(24) Только ГОСТ?

(24) он платный, автор ищет халявы

(26) Я не ищу халявы. Я ищу вариант, при котором даже создатель приложения не сможет получить к ним доступ. В закрытых проектах такого быть не может. Код закрыт.

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

(25) Нет конечно, много всякого, но фишка акрониса в том, что он наш стандарт поддерживает в т.ч.

(27) >> даже создатель приложения не сможет получить к ним доступ.

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

(27) ну создатель приложения по любому может получить доступ, от этого защиты нет...

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

а то потом локти кусать будете...

(27) Может. Если закрытый проект шифрует по определенному алгоритму - это легко проверяется. А если ты знаешь что шифрует по ассиметричному алгоритму, и подается только открытая часть ключа - то можно быть уверенным что взлом уже зашифрованного файла невозможен.

Более того - шифрование, например RSA, можно написать самому. И будешь уверен что шифрует именно RSA.
например на JAVA, 10 строк кода
http://www.cyberforum.ru/post4798375.html
и еще 30 строк кода рекурсивно перебрать папки и зашифровать все файлы.

(31) угу: Cipher cipher = Cipher.getInstance( "RSA" );

Ловко ты про 10 строк кода )

(32) Это же не соревнование на самостоятельную реализацию RSA.

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

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

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

(34) Неужели врут, что RSA используется для шифрования?

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

(36) Понятно, что шифруем данные только если хватает времени (производительности). Но данные конечно-же шифруют при помощи RSA.

в RSA при подписи и при шифровании данных используют две различные схемы дополнений. Схема, реализуемая для подписания документов, называется RSA-PSS(probabilistic signature scheme) или вероятностная схема подписи. Схема, используемая при шифровании – RSA-OAEP(Optimal asymmetric encryption padding) или оптимизированное асимметричное дополнение шифрования, на примере OAEP и рассмотрим как на самом деле происходит шифрование сообщений в RSA.
https://habr.com/post/99376/
Вот в википедии, шифрование данных (не ключа!)
https://ru.wikipedia.org/wiki/Оптимальное_асимметричное_шифрование_с_дополнением