追加のメモリ空間を提供することなく、それらを暗号化することによって一部のレジスタを保護したい暗号化するデータの長さを維持する暗号化アルゴリズムはありますか? (つまり、plaintext.length = ciphertext.length)
基本的に、メッセージと同じブロックサイズ、またはメッセージエンコーディングの文字サイズ(ASCII/UTF8の場合は8ビット、UTF-16および-32の場合はそれぞれ16および32)にできる非対称暗号を求めています。 )。
バニラRSAは技術的にこれを行うことができます。符号なし整数[〜#〜] n [〜#〜]のビットサイズを制限する必要があります。2つのランダムな素数を選択することで生成されますpおよびq(pしたがって、sqrt([〜#〜] n [〜#〜])および可能な領域qより小さくなければなりません=値はpがsqrt([〜#〜] n [〜#〜]))に近づくほど減少します。最大Nは、連結されたメッセージと同じ桁か、またはその約数(1バイト/文字まで)のいずれかです。
ただし、これには2つの重大な問題があります。
したがって、キーサイズを調整したプレーンなRSAのアプローチは、根本的に欠陥があると見なされます。楕円曲線暗号化など、私が見つけることができる他のすべての公開鍵システムには、暗号化に使用される計算に基づく同様の制限があります。
** 2048ビットは、X.509デジタル証明書の最小推奨キーサイズです。 22048 〜= 3.2317e616。この数を展望すると、プランクの体積は4.22419e−105 mです。3;理論的には、この単位は宇宙の粒度の「解像度」であり、プランクの長さはどの機器でも測定できる最小距離です。観測可能な宇宙は少なくとも半径1e27 m(137億光年)のオーダーであるため、観測可能な宇宙の球は〜4.189e79 mです。3 〜= 1.7e185 Pl3。つまり、「星を数えて名前で呼び出す」だけでなく、観測可能なユニバースのすべての細かい部分に序数を割り当てることができる場合、必要な数の数は、数の数よりも10進数で400桁短くなります。 RSAキースペースに固有。
厳密に言うと、安全な非対称暗号化ではプレーンテキストの長さを維持できません。問題は、公開されている公開鍵が誰にでも知られていることです。したがって、誰もが潜在的なplaintextsを「試行」して暗号化し、結果が暗号化されたテキストと一致するかどうかを確認できます。それは、キーの代わりに徹底的な検索平文上であり、平文には何らかの「意味」があり、したがって構造があるため、機能します。たとえば、銀行の注文を暗号化する場合、金額と宛先口座の組み合わせは数十億しかなく、これは徹底的な検索に適しています。
この問題を防ぐには、安全な非対称暗号化アルゴリズムをdeterministicにしないでください。暗号化プロセスにはランダム性を含める必要があるため、特定のプレーンテキストを公開鍵を指定すると、可能な暗号文のセットが大量になる可能性があります。これは、たとえばRSAで PKCS#1 によって定義されているように発生します。プレーンテキストが最初にパディングランダムバイトで。もちろん、復号化すると、パディングは明確に検出されて削除されます。
確定的ではないということは、可能な暗号文のセットが、可能な平文のセットよりもはるかに大きいことを必ずしも意味します。つまり、暗号文は必ず平文よりも大きくなります。
少なくとも、通常の方法 ハイブリッド暗号化 :ランダムバイトのシーケンスを非対称に暗号化することにより、サイズのオーバーヘッドを一定に保つことができます(入力メッセージの長さに比例するサイズの増加ではなく、一定の増分)。 [〜#〜] k [〜#〜]、これを使用して対称平文の暗号化を行います。さらに言えば、非対称暗号化を鍵交換メカニズムに置き換えることができます。サイズの予算が気になる場合は、 elliptic-curve Diffie-Hellman を参照することをお勧めします。標準のP-256曲線を使用すると、メッセージごとのオーバーヘッドを32バイトに保つことができます。
RSAでは、暗号化するメッセージがキーよりも長いと想定すると、少し低くなる可能性があります(PKCS#1 v1.5パディングは少なくとも11バイトのオーバーヘッドを意味します。2048ビットのRSAキーを使用すると、RSAで暗号化できますメッセージの最初の229バイト、および16バイトの対称鍵。AES-CTRを使用してメッセージの残りの部分にその鍵を使用します。これは27バイトのオーバーヘッドです)。
「フォーマット保持暗号化」を探しているようですが、FPEをこれまでに見たことがない場合は、Wikiの記事をご覧ください。良い参考文献がたくさんあります。
http://en.wikipedia.org/wiki/Format-preserving_encryption
Asymmetric Format Preserving Encryptionのようなものが存在するかどうかはわかりませんが、その用語を検索すると、その周りに多くの議論があります。
タイトル行にタイプミスがあるのではないかと思います。 「非対称」が「対称」である場合、私の答えは次のとおりです。すべての一般的なブロック暗号はあなたの条件を満たします。アプリケーションでブロック長が問題になる場合は、ストリーム暗号化を使用できます。 (私はあなたの条件を満たす非対称暗号化アルゴリズムを知りません。それは不可能だと思います。)