クライアントAは通常、公開鍵を使用してファイルを暗号化し、その秘密鍵を持つクライアントBにファイルを送信してファイルの復号化を行います。
私たちのチームは顧客Aの責任を引き受け、公開鍵（電子メールを介して保護されていないファイル転送PUB_KEY.asc）を受け取りました。これは正常にインポートされ、私のキーリングで確認できます。
gpg --list-keys
pub 1024R/21FG3F01 2008-11-05
uid PUB_KEY
sub 1024R/3287SBN9 2008-11-05
次のコマンドを使用してファイルを暗号化しました。クライアントAとまったく同じコマンドクライアントBに送信しますが、復号化に失敗します。
gpg --output file.txt.gpg -e -r PUB_KEY file.txt
クライアントBは、次のような復号化エラーを受け取ります。1080: 復号化のための秘密鍵が見つかりません。（秘密鍵がありますが）。
鍵署名が可能であるため、署名公開鍵を試してみましたgpg --sign-key PUB_KEYが、次のエラーが発生しました。
pub 1024R/21FG3F01 created: 2008-11-05 expires: never usage: SC
trust: unknown validity: unknown
sub 1024R/3287SBN9 created: 2008-11-05 expires: never usage: E
[ unknown] (1). PUB_KEY
gpg: no default secret key: No secret key
公開鍵に署名するために秘密鍵が必要なのはなぜですか？正しい公開鍵を使用すると、クライアントBがファイルを復号化できなくなる原因は何ですか？
答え1
最初の質問（「公開鍵に署名するにはなぜ秘密鍵が必要なのですか」）は簡単です。これが公開鍵暗号化がどのように機能するかです。何か（鍵、文書など）に署名するには秘密鍵が必要であり、公開鍵を使用して確認できます。暗号化は公開鍵を使用し、秘密鍵を使用して復号化できます。
2番目の質問はより複雑です。鍵に署名するかどうかは関係ありません。署名すると、そのキーがPGP / GPGで設定された信頼ネットワークの重要な部分であるという警告のみを防ぐことができます。ただし、信頼ネットワークの外部で鍵の正確性を確認した場合（たとえば、受信者から直接鍵を受信するなど）、信頼ネットワークを無視できます。したがって、署名は必要ありません。
-rフルキーフィンガープリントではなくパラメータを使用しており、誤って誤った受信者を暗号化しているようです。完全な指紋を使用する必要があります（たとえば、067E3C456BAE240ACEE88F6FEF0F382A1A7B6500短い指紋EF0F382A1A7B6500や非常に短い指紋はありません1A7B6500）。
私が考えることができる唯一の違いは、あなたが解読側でサポートしていないいくつかのアルゴリズムを（おそらくあなたには知られていない）使用していることです。たとえば、受信者よりはるかに最新のバージョンのgnupgを使用している場合です。または、受信者が別のプログラムを使用している場合です。受信者のキーがプログラムがサポートするものを指定するのは正常ですが、その特定のキーはサポートされていないか、間違っている可能性があります。 GPGにはオーバーライドオプションがあります（マンページの「相互運用性」を参照）。試してみる価値があります--pgp8。--pgp7--pgp6
答え2
gnupgは暗号化されたメッセージのヘッダーにファイルが含まれているため、失敗する前にファイルを復号化するために必要なキーを報告します。たとえば、
‰ gpg -d test
gpg: encrypted with 4096-bit RSA key, ID 0xF38153E276D54749, created 2011-09-23
"Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>"
gpg: decryption failed: No secret key
gpg --list-secret-keysメッセージに提供されたキーは、クライアントBの出力にあるキーの1つと一致しますか？間違った公開鍵を受け取ったか、クライアントBが関連する秘密の{sub、}鍵を削除したようです。