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

Question

Использование: gpg (GnuPG) 2.0.22 libgcrypt 1.5.3

Я пытаюсь расшифровать файл с удаленного сайта. Я экспортировал наш ключ в файл. gpg <filename> возвращает: (идентификаторы ключей изменены)

pub 2048R/656CC421 2018-04-19
sub 2048R/99F89J32 2018-04-19

Я отправил его отправителю и попросил импортировать, подписать и доверять.

Они прислали мне два разных ключевых файла. Использование gpg <filename> возвращает:

1. pub 2048R/62568LK1 2015-09-03

2. pub 2048R/J561VE25 2015-09-23

Если я сделаю правку, я получу следующее:

Мой ключ:

Secret key is available.

pub 2048R/656CC421 created: 2018-04-19 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048R/99F89J32 created: 2018-04-19 expires: never usage: E
[ultimate] (1).

Их ключи:

1. pub 2048R/62568LK1 created: 2015-09-23 expires: never usage: SCE
trust: full validity: full
[ full ] (1).

2. pub 2048R/99F89J32 created: 2015-09-03 expires: never usage: SC
trust: full validity: full
[ full ] (1).

Я запускаю команду decrypt в скрипте bash со следующими параметрами.

echo $passphrase | /usr/bin/gpg --verbose --passphrase-fd 0 --no-tty --output $output_file --recipient myuser --decrypt $input_file

Ниже приведен вывод команды:

Version: GnuPG v1.2.4 (MingW32)
gpg: armor header:
gpg: public key is 99F89J32
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: cancelled by user
gpg: encrypted with 2048-bit RSA key, ID 99F89J32, created 2018-04-19
"usrname (Description) <usrname@domain.com>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

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

pub 2048R/J561VE25 2015-09-23

sub 2048R/SOM3NUMB 2015-09-23

Я подумал, что файлы ключей, которые они мне отправили, не имеют соответствующей информации pub/sub, и поэтому gpg не может проверить, потому что у меня есть только одна часть информации их пар ключей.

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

Спасибо!

Answer 1

Version: GnuPG v1.2.4 (MingW32)

Святые шары это старая версия 1.2.4 была выпущена в 2003 году. Похоже, отправителю не очень важно обновлять свое программное обеспечение безопасности.

(Ваш собственный 2.0.22 не намного лучше, с 2013 годом в качестве даты выпуска.)

gpg: public key is 99F89J32
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: using subkey 99F89J32 instead of primary key 656CC421

Это нормально. "Основная" пара ключей используется только для подписи (или сертификации) других ключей; часто также для подписания сообщений. Он не пригоден для шифрования - для этого у вас всегда есть подраздел.

(Разделение также допускает такие вещи, как автономное подписание или частая ротация ключей шифрования.)

gpg: cancelled by user
gpg: encrypted with 2048-bit RSA key, ID 99F89J32, created 2018-04-19 "usrname (Description) <usrname@domain.com>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

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

Запрос пароля показывается компонентом пинентри в GnuPG, который запускается через gpg-agent. Я действительно не знаю, с чего начать устранение неполадок в Windows - возможно, более новая версия будет работать лучше. (Ваш GnuPG 2.0.22 был выпущен в 2013 году.)

Более новые версии, начиная с GnuPG 2.1, поддерживают режим "loopback pinentry", который может работать без компонента pinentry . Если обновление не помогает само по себе, попробуйте активировать эту опцию.

что отправитель должен отправить мне свой открытый ключ

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

Такие как:

pub 2048R/J561VE25 2015-09-23

Я подумал, что файлы ключей, которые они мне отправили, не имеют соответствующей информации pub/sub, и поэтому gpg не может проверить, потому что у меня есть только одна часть информации их пар ключей.

Нет. Этот бит информации предназначен для вас, пользователя - он суммирует тип ключа, короткий (бесполезный) идентификатор и дату истечения срока действия. GnuPG может отлично извлечь его из самого ключа, а не того, что ему нужно.

Answer 2

Ну а после долгих поисков я нашел решение в двух изменениях.

1. В gpg-agent.conf нужно было pinentry-program /usr/bin/pinentry-curses .

2. Автор сценария должен был добавить --batch к своей командной строке.

Как только это было сделано, gpg смог получить секретный ключ и расшифровать его.

Спасибо за ответ. Ваше время ценится.