これはこのサイトでの私の最初の質問であり、RSAの基本的な数学的理解しかありませんので、ご容赦ください。:)
私は大学での最終年度のプロジェクトのためにJavaWebアプリケーションを書いています。これは、聞いたことがある人のための安全な投票システムである「Pret-a-voter」のWebベースの実装です。
基本的に私の問題は、監査人の役割を果たす誰かを与えたいということです。
- ソースバイト配列（暗号化されるプレーンテキスト）
- RSA公開鍵ファイル
- 「宛先」バイト配列。これは、平文と公開鍵を指定して暗号データを自分で計算した結果です。
次に、監査人が最初の2つの項目を使用して暗号化を実行できるようにし、3番目の項目が結果であることに満足してもらいたいと思います。したがって、暗号化を決定論的にする必要があります。つまり、同じ平文と公開鍵を使用した暗号化が繰り返されるたびに同じ暗号化データを生成する必要があります。
（注-このプロジェクトでは非常に小さなデータブロックを使用しています-対称暗号化はまったく含まれていません...これがRSAの「興味深い」使用法であることを認識しています！）
とにかく私はJavaでそれを見つけました
cipher = Cipher.getInstance("RSA");
デフォルトのランダムパディングスキームを使用しますが、コストは11バイトです（したがって、2048ビットのキーペアを使用すると、2048 / 8-11 = 245バイトを暗号化できます）。同じ平文の暗号化を繰り返すと、異なる暗号文が生成されますが、これは明らかに私が望むECBモードではありません。
私の質問は-私は以下を使うべきですか？
cipher = Cipher.getInstance("RSA/ECB/NoPadding");
多くの場所で、RSAはパディングなしでは安全ではないことを読みました。それは、攻撃者が平文/暗号文の辞書を作成できるからですか？これは、監査人が私の暗号化を検証できるようにするために必要な確定的暗号化の副作用であり、私のスキームでは監査人は信頼されているので、それで問題ありません。
私の質問のパート2は、よりJava関連です。上記のようにRSA/ECB / NoPaddingを使用する場合、（たとえば）長さ128のソースバイト配列（1024ビットRSAキーペアの場合）を提供し、それを暗号化して長さの別のバイト配列を取得できると思います128.次に、別の1024の長さの公開鍵を使用してそれを再度暗号化しようとすると、次のようになります。
javax.crypto.BadPaddingException：メッセージがモジュラスより大きい
誰かが理由を知っていますか？
編集-NoPaddingを使用した暗号化は、常にこの例外を生成するとは限りません-それは一時的なものです。ただし、暗号化によってこの例外が生成されない場合でも、復号化によって次の例外が生成されます。
javax.crypto.BadPaddingException：データはゼロで始まる必要があります
これを読んでくれてありがとう！どんな助けでも大歓迎です。
編集-申し訳ありませんが、私の元の質問は、私が何をしたいのかについてあまり明確ではなかったので、ここに[試み]の説明があります：
- 平文は選挙における有権者の投票です。
- Pret-a-voterは、投票者の機密保持などを犠牲にすることなく、エンドツーエンドで検証できるようにすることを目的としています。投票後、投票者には、投票が正しく記録されたことを確認するために使用できる領収書が提供されます。この領収書には、後で投票が改ざんされていないことが示されます。投票者は、領収書の情報をWebに投稿された同一のコピーと比較します。
- ただし、投票者がどのように投票したかを証明することはできません（強制につながる可能性があるため）。そのため、情報は平文ではなく、投票の暗号化されたコピーになります。
- 実際、平文は4回暗号化され、4つの異なる非対称キーが2つの異なるテラーによって保持され、それぞれが2つのキーを保持します。したがって、投票（平文）が公開鍵＃1を使用して暗号化する1人のテラーに提供され、次にその暗号文を2番目の公開鍵で暗号化し、その暗号文を2番目のテラーに提供します。仕方。結果の暗号文（4つの連続した暗号化の結果）は、Webに投稿されたものです（公開されます）。テラーは信頼されています。
- 暗号化された各投票は、中心が投票であり、暗号化のいくつかの層がある「タマネギ」として視覚化できます。投票するには、各レイヤーを順番に削除する必要があります。つまり、対応する秘密鍵（テラーが保持している）を逆の順序で適用する必要があります。これはセキュリティの鍵です。投票を復号化するには、すべての出納係が協力して作業する必要があります。
- Web掲示板は、5つの列を持つテーブルとして視覚化できます。最初の（左側）は完全に暗号化された投票（各投票者の領収書にも表示されます）を保持し、投票の段階で表示される唯一の列です。2番目の列には同じ投票のセットが含まれていますが、外層が削除されています。出納係2は、集計段階で秘密鍵を使用して投票を復号化することにより、この列と列3にデータを入力します。集計段階の最後に、列5には、集計できる完全に復号化された投票が含まれます。
- 各投票者は、列1の暗号化された投票にリンクする領収書を受け取ります。これは投票方法を示していませんが、選挙プロセス全体を通じて暗号化された投票を確認できるため、投票が改ざんされていないことを確認できます。 1列目にはそのまま残っています。もちろん、これは「エンドツーエンド検証」の半分にすぎません。投票者は、復号化が正しく行われたことを検証できないためです。つまり、投票から暗号化の外層を差し引いた列2にエントリがあります。 。各有権者は、列1のポイントまでの検証にのみ責任があります。
- その後、1列目のエントリが2列目に復号化されることを確認するのは監査人の責任です。これを行う方法は、確定的暗号化と、暗号化に使用される公開鍵が公開されていることに依存することです。
- 公開鍵は公開されているため、5列目から1列目まで単純に線を引いて、暗号化が繰り返されるときに誰かの投票に参加することは望ましくありません。つまり、暗号化された投票にあなたを結び付ける領収書は、実際にはあなたを暗号化されていない、読みやすい投票->強制！したがって、列1、3、および5のみが公開され（これが各テラーが2つの暗号化を実行する理由です）、列3の各エントリについて、{2,4}の対応するエントリの1つのみが監査人に公開されます。これにより、誰もが（監査人でさえ）暗号化された投票を暗号化されていない投票にリンクすることができなくなります。
- したがって、監査人は列3のエントリを取得し、列2の対応するエントリと公開鍵を与えられ、同じ暗号化を実行して、列2のエントリを実際に取得することを確認する必要があります。
- まとめると、これはエンドツーエンドの検証可能性を提供します。
申し訳ありませんが、それは非常に長かったです-決定論的な暗号化の必要性を説明していることを願っています。私は多くの基本的な詳細を見逃しました（私はこのスキームを大幅に変更しました）が、うまくいけば、コア原則がすべてそこにあります。読んでくれてありがとう-本当に感謝しています。