PGPOnePassSignature.verifyを呼び出すときに署名の長さが正しくない

Question

ライセンス管理にlicense3jというJavaライブラリを使用しています。ライブラリは非対称暗号化を使用し、Bouncycastleに依存しています。 gpgコマンドを使用してライセンスファイルを作成し、公開鍵を使用してソフトウェア内のライセンスを確認します。これまでのところすべてがうまくいきました。しかし、生成された1,000個のライセンスでは、実際には有効です（約5/1000）が、正しく検証できない部分があります。この場合にはどうなり

：基本的な暗号の知識を持つ、私に

org.bouncycastle.openpgp.PGPRuntimeOperationException: unable to verify signature: Signature length not correct: got 511 but was expecting 512

音ではなく曖昧：org.bouncycastle.openpgp.PGPOnePassSignature.verify(PGPSignature)ライセンスがcom.verhas.licensor.License.setLicenseEncoded(InputStream)で検証する場合は、次の例外がスローされます。グーグルで過ごす時間は、「先導するゼロ」について何かがあることを私に告げた。したがって、与えられた例では、明らかに先行ゼロがどこかで取り除かれ（？）、比較するシグネチャデータの長さが一致しません。意味をなさない

ここでは問題がどこにあるのかわかりません。ライセンスファイルのの作成中ですか？基本的には、次のようにしています：

gpg --armor --local-user=name.of.software --sign 

ライセンスファイルは私たちに与えられます。

またはエラーが検証中に起こるのでしょうか？先行ゼロ問題に正しく対処するためにBouncycastle構成を変更する必要がありますか？それらのFAQはいくつかのヒントを示していますが、License3jsourceは決してCipherインスタンスを使用しないため、これを指定されたAPIに統合する方法が完全に失われています。

私はこれが明らかにあまりよく知られていないライブラリでは非常に特別な問題であると認識しています。したがって、私は少しのフィードバックや入力を感謝します。それは、はBouncyCastleは常にデータ間違って作成しただけで1.6後のJavaのバージョンで遭遇はBouncyCastleのバグは、ですが、Javaは、データ中1.7以来、それは検証中に受け入れるより厳密になったよう

Answer 1

が見えます。整数は、それのバイト表現が小さくなり、十分な先行ゼロを有する場合、それは、ファイルにシリアライズする際

はBouncyCastleは、正しい長さにパッドに署名を失敗しています。
Javaバージョン1.7以上では、RSA署名バイトが鍵と同じ長さになると予想されます。

はBouncyCastleは整数に（JavaのRSA JCEプロバイダから返された）RSA署名バイト配列を変換し、それは、その長さについての情報を破棄する。
Line 263 of the PGPSignatureGeneratorは、RSA署名バイトがJCEから返され、整数に変換される場所を示します。

この整数は最終的に、出力するストリームに、MPInteger#encodeを使用して書き込まれます。これは、基礎となるbigintegerのビット長を使用して書き込むデータ量を決定するだけです。

This answerあなたはこのaproximatleyすべての200例に1つ、どのバージョンのJavaが役割を果たしているを参照してください理由の詳細を説明します。