7

私はBouncyCastleのRSA(Lightweight API)の実装をいじって、基本を理解しました。JCEプロバイダー実装の仕様を見ると、RSAでさまざまなパディングスキームを使用できることに気付きました。私の理解では、デフォルトではnullパディングが使用されます。そこで、特にOAEPパディングの調査を開始しましOAEPWithSHA512AndMGF1Paddingた。グーグルで検索することはあまり役に立たなかったので、私はBCのソースコードを掘り下げ始め、org.bouncycastle.jce.provider.JCERSACipherクラスを見つけました。しかし、すぐに見ると頭痛の種になりました...具体的には、コンストラクターinitFromSpecに渡すことができる最後の2つのパラメーターが何であるかがわかりません。OAEPEncodingBCのAPIによるとOAEPEncoding、4つのパラメーターを許可するコンストラクターDigest mgf1Hashbyte[] encodingParams最後の2つの引数として。マスク生成アルゴリズムのインスタンスを取得する方法がわからず、と呼ばれるバイト配列の背後にある目的も理解できないため、これは私を困惑させましたencodingParams。以下のコードのarg3との値はどうあるべきですか?arg4

RSABlindedEngine rsa = new RSABlindedEngine();
SHA512Diges sha512 = new SHA512Digest();
Digest arg3 = ???;
byte[] arg4 = ???;
AsymmetricBlockCipher cipher = new OAEPEncoding(rsa, sha512, arg3, arg4);
4

1 に答える 1

11

OAEPは、PKCS#1、セクション7.1で指定されています。

OAEPには次のパラメータが必要です。

  • ハッシュ関数;
  • 出力長が無制限のハッシュ関数と考えることができる「マスク生成関数」。
  • 「ラベル」(任意のバイトシーケンス)。

MGF1と呼ばれる定義済みのマスク生成関数は1つだけであり、その関数はハッシュ関数の上に構築されています。つまり、arg3MGF1が使用するハッシュ関数です。これは、最初のハッシュ関数と同じハッシュ関数である可能性があります(Bouncy Castle APIの同じDigestインスタンスであるかどうかはわかりません。ここでは、数学的に話しています)。別のハッシュ関数の場合もあります。

ラベルは、インスタンス間の一種の区別として使用できます(たとえば、ラベルにエンコードされた明示的な「目的」を使用してデータを暗号化できます)。いくつかの数学的証明には便利ですが、現時点では、PKCS#1は空の文字列を使用してそれを実行することをお勧めします。PKCS#1で説明されている目的では、空のラベルは他のラベルと同じです。

復号化プロセスは、動作するためにこれらのパラメータを知っている必要があります。暗号化されたメッセージに付属し、「これはRSA/OAEPで暗号化されています」という構造でそれらをエンコードするのが通例です。それがCMSで起こる方法です。

疑わしい場合は、最初のパラメーターと同じハッシュ関数をMGF1に使用し、空のラベルを使用します。

于 2010-06-23T13:17:30.923 に答える