расшифровать зашифрованный файл gpg, используя внешний секретный ключ - PullRequest
9 голосов
/ 31 января 2012

Я зашифровал файл, используя gpg, теперь я хочу расшифровать файл.

Есть ли способ расшифровать файл без необходимости импорта секретного файла?

У нас есть секретный ключ в файле с именем key.sec; можем ли мы передать секретный файл в gpg в качестве параметра (когда мы запускаем команду decrypt из командной строки bash) для использования при расшифровке зашифрованного файла? Или мы должны импортировать секретный ключ, а затем расшифровать зашифрованные файлы?

Ответы [ 3 ]

11 голосов
/ 31 января 2012

Вы должны добавить секретный ключ в связку ключей. Из gpg(1) документации:

   --no-default-keyring
          Do not add the default keyrings to the list of
          keyrings. Note that GnuPG will not operate without any
          keyrings, so if you use this option and do not provide
          alternate keyrings via --keyring or --secret-keyring,
          then GnuPG will still use the default public or secret
          keyrings.

Вы можете --import --no-default-keyring --secret-keyring temporary импортировать ключ, использовать --secret-keyring temporary для расшифровки содержимого, а затем удалить файл ~/.gnupg/temporary.gpg, когда закончите. Но это всего лишь обходной путь.

4 голосов
/ 04 октября 2016

Вы должны импортировать секретный ключ, чтобы использовать его , но способ управления секретными ключами в GnuPG версии 2.x изменился. Существует демон gpg-agent, который обрабатывает доступ к секретным ключам, и его использование обязательно с версии 2.1.

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

$ mkdir -m 700 ~/.gnupg-temp
$ gpg --homedir .gnupg-temp --import key.sec
$ gpg --homedir .gnupg-temp -d an_ecrypted_file

Если вы хотите выполнить очистку, остановите агент и удалите каталог:

$ gpg-connect-agent --homedir .gnupg-temp KILLAGENT /bye
$ rm -r ~/.gnupg-temp

Раньше был параметр --secret-keyring, о котором в документации для версии 2.1 говорится:

Это устаревшая опция и игнорируется. Все секретные ключи хранятся в каталоге private-keys-v1.d под домашним каталогом GnuPG.

Каталог private-keys-v1.d--homedir или ~/.gnupg) принадлежит и управляется агентом.

1 голос
/ 07 февраля 2019

Цель ОП Мухаммеда, кажется, состоит в том, чтобы держать его ключи ОБЩЕСТВЕННЫЙ и СЕКРЕТ врозь. В конце концов, хотим ли мы сохранить Секретный ключ с данными, которые использовались для шифрования? Таким образом, Мохаммед и еще 10 650+ (в то время, когда я пишу это) интересуются если / как это возможно. На самом деле это так, и вот как вы это делаете:

Общедоступный хост имеет только два ключа: Оба являются публичными ключами

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

  2. Ваш SSH Открытый ключ в .ssh / authorized_keys для упрощения неинтерактивных входов в систему.

Обход зашифрованного файла с использованием разделения открытого секретного ключа:
Следующий фрагмент кода bash при выполнении на хосте с секретным ключом извлечет зашифрованный файл с DMZ-хоста через scp и перенаправит стандартный дешифрованный вывод gpg обратно на DMZ-хост в файл, чтобы его можно было читать / оперировать. Этот код проверен и, как известно, работает правильно:

echo "$(gpg -d $(scp myuser@192.168.1.10:/home/myuser/test-gpg.txt.asc .;ls ./test-gpg.txt.asc))" | ssh myuser@192.168.1.10 'cat > /home/myuser/test-gpg.txt'

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

И не забудьте сделать rm test-gpg.txt дешифрованного файла после завершения операции, которая требовала, чтобы его содержимое было доступно для чтения.

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

...