web-dev-qa-db-ja.com

PKCS#1-1.5エンコーディング-ブロックタイプで00を使用する理由はありますか?

次のような暗号化ブロックの場合:EB = 00 || BT || PS || 00 || BT-ブロックタイプとPS-パディング文字列のデータ、BT、00、01、02の3つのタイプを使用することを読みました。今、00と01は秘密鍵の操作用です(01が推奨されます-なぜですか?)。 、署名のように、そして02は暗号化のような公開鍵操作のためのもので、なぜ '00'ブロックタイプの使用が推奨されないのか疑問に思っています。また、それが推奨されない場合、なぜそれが可能なのですか?

初心者であることをもう一度お詫びします。

2
James Pond

PKCS#1 は、2つの「古いスタイル」のパディング(別名「v1.5」)のみを定義します。これらはPKCS#1 v1.5で定義された2つのパディングでしたが、より新しいバージョンでは、他のオプションが追加され、既知の「OAEP」および「PSS」として)。これらの2つのパディングは、「タイプ1」と「タイプ2」です。 「タイプ0」のパディングは定義されていません。もちろん、任意のバイトは概念的に0〜255の範囲の任意の値を持つことができますが、PKCS#1は3つ以上ではなく2つのパディングのみを定義します。

2つのパディングは、「タイプバイト」(値0x01または0x02)のみが異なるわけではありません。後続のバイト(「PS」文字列)は、セキュリティにとって非常に重要です。 「タイプ1」パディングでは、「PS」文字列は値0xFFのバイトのみで構成されます。完全に確定的です。 「タイプ2」のパディングでは、「PS」文字列はランダムバイトで構成されます(バイトの値は0x00であってはなりませんが、それ以外の場合は0x01..0xFFの範囲でランダムに生成される必要があります)。それらを相互に使用することはできません。タイプ1のパディングは署名用、タイプ2は非対称暗号化用です。署名にタイプ2のパディングを使用すると、非常に弱い署名スキームが得られます(モジュラ指数に固有の malleability のため)。非対称暗号化にタイプ1パディングを使用すると、弱い暗号化スキームが得られます(タイプ1パディングの確定性により、平文に対するブルートフォース攻撃が可能になるため)。

パディングタイプを識別する「BT」バイトは、主に(そしてほとんどの場合)2つのパディングを明確に区別するためにあります。それ以外の場合は、暗号化されたメッセージとして署名を使用する攻撃者、またはその逆について心配する必要があります。したがって、2つのパディングには異なる「BT」値が必要です。 PKCS#1の作成者は、2つの値を0と1、または1と2、または17と42、またはその他の異なる値のペアに選択することができます。 1と2を選択しました。これは任意です。

いずれの場合も、パディングの重要性は「BT」バイトではなく、それに続くバイト(「PS」文字列)にあります。 タイプ0のパディングは存在しないため、「タイプ0」のパディングを使用することはお勧めしません。

4
Thomas Pornin

まず、ブロックタイプ(BT)の「00」と「01」は、秘密鍵の操作、つまり署名のためのパディングです。規格では、署名用の「データ」は、署名されたデータのハッシュ(DER DigestInfo構造)であると定義されています。

ブロックタイプ(BT) '01'パディングは、モジュラスの長さまで固定パディングデータを追加します。

00 | 01 | FF .. FF | data

ブロックタイプ(BT) '00'のパディングは、BTが00に設定され、パディング文字列がゼロに設定されることを意味します。これは、実際にはパディングが適用されないことを意味します。

00 | 00 | 00 .. 00 | data

標準に準拠したソフトウェアは、この形式のデジタル署名を受け入れません。ブロックタイプ '00'のパディングは、秘密鍵を使用して生の指数演算を実行する場合、またはライブラリ(RSA-PSSなど)が提供するよりも高度なパディングを実装する場合にのみ役立ちます。

0
FaST4