使用: gpg (GnuPG) 2.0.22 libgcrypt 1.5.3
リモート サイトからファイルを復号化しようとしています。キーをファイルにエクスポートしました。gpg <filename>戻り値: (キー ID が変更されました)
pub 2048R/656CC421 2018-04-19
sub 2048R/99F89J32 2018-04-19
私はそれを送信者に送り、インポートして署名し、信頼するように依頼しました。
2 つの異なるキー ファイルが送られてきました。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).
次のパラメータを使用して、bash スクリプトで decrypt コマンドを実行しています。
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) <[email protected]>"
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 は検証できないと考えました。
私が間違っているのか、それとも私の考えが正しいのか、誰か教えてもらえませんか?
ありがとう！
答え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) <[email protected]>" gpg: public key decryption failed: Operation cancelled gpg: decryption failed: No secret key
GnuPGがロック解除のためにパスフレーズプロンプトを表示しようとしたようですあなたのキーペアですが、パスフレーズ ウィンドウが開かなかったか、誤って自分でキャンセルしてしまいました。
パスワードプロンプトはGnuPGのピンエントリーコンポーネント自体は、gpgエージェントWindowsでトラブルシューティングをどこから始めたらよいのかよくわかりません。新しいバージョンよりうまく動作するでしょう。(GnuPG 2.0.22 は 2013 年にリリースされました。)
GnuPG 2.1以降の新しいバージョンでは、「ループバックピンエントリ」モードがサポートされており、ピンエントリーコンポーネント。アップグレードだけでは解決しない場合は、このオプションを有効にしてみてください。
送信者は私に公開鍵を送る必要がある
送信者の公開鍵は復号化には役に立たず、署名の検証にのみ必要です。
のような：
pub 2048R/J561VE25 2015-09-23送られてきたキー ファイルには対応する pub/sub 情報がないため、キー ペアの情報の一部しか持っていないため gpg は検証できないと考えました。
いいえ。この情報はあなた、ユーザー – キーの種類、短い (役に立たない) ID、有効期限を要約します。GnuPG はキー自体からこれを完全に抽出できますが、そうする必要はありません。
答え2
何度もやり取りした後、2 つの変更で解決策を見つけました。
gpg-agent.conf
pinentry-program /usr/bin/pinentry-cursesを追加する必要がありました。スクリプト作成者は
--batchコマンド ラインに追加する必要がありました。
それが完了すると、gpg は秘密鍵を取得して復号化できるようになりました。
ご返信いただきありがとうございます。お時間を割いていただきありがとうございます。