単純な署名と暗号化とはどういう意味ですか？
彼の論文ではS/MIME、PKCS＃7、MOSS、PEM、PGP、XMLでの署名と暗号化の欠陥、ドン・デイビスはよくこの言葉について話します
単純な署名と暗号化
論文を読んだ後、私はこれが何を意味するのか正確にはわかりません。
彼は、（主流の）ユーザーが署名と暗号化が許容できるセキュリティ慣行だと考える可能性のある習慣を意味しているのでしょうか？ （あなたのメッセージを誰が暗号化したかについての保証はありませんが）
著者は「シンプル」と「ナイーブ」を同じ意味で使用しているようです。はい、彼は送信前に平文に（送信者の秘密鍵で）署名し、（受信者の公開鍵で）暗号化する行為に言及しているようです。
第三者が送信者が書き込んだ既存の署名付きメッセージを受信者に転送できるため、これはナイーブであると彼は考えています。
ボブとアリスが安全に通信しようとしている状況を想像してみてください。 Chuckは信頼されていないサードパーティで、どちらも知っています。
- チャックはボブに一連の質問を送り、ボブはかなり一般的な応答で返信することを期待しています。たとえば、チャックは「ドン紙を読みましたか？」と尋ねます。そして、ボブは「はい」を送り返します-署名され暗号化されます。
- アリスはボブに「チャックを信用してもいいですか」というメッセージを送ります。チャックはアリスがこれをするつもりであることを知っています。
- チャックは前から署名された「はい」メッセージを復号化し、それをアリスの公開鍵で再暗号化します。ボブが返信する前に、彼はそれを彼女に送ります。
- アリスは彼女の質問に対して「はい」と答える。これはボブによって署名され、彼女の公開鍵で暗号化されて送信されたので、彼女はそれを信頼しています。
署名および暗号化を authenticated encryption に組み合わせて署名された秘密のメッセージを送信できるようにするための正しい順序を決定する暗号およびセキュリティ業界の人々の文脈で、署名および暗号化スキームを読む必要があります。
単純な署名と暗号化は、メッセージが作成者の秘密キーによって署名され、最も簡単な最も明白な方法で受信者の公開キーに暗号化される暗号化スキームです。
message = encrypt(recipient public key, sign(author private key, message))
このシンプルなスキームには、このペーパーで説明されているように、いくつかの脆弱性があります。
その他の素朴な命令：「暗号化してから署名する」にもいくつかの脆弱性があります。以前は、暗号化APIは署名と暗号化プリミティブを公開するために使用されていましたが、認証された暗号化プリミティブは公開していなかったため、プロトコル設計者とアプリケーションプログラマーは常に独自の結合メカニズムを再発明しなければなりませんでした。通常、2つの単純な順序と、プロトコル設計者とアプリケーションプログラマーがこれらのプリミティブを組み合わせる方法は、予期しない脆弱性につながることがよくあります。
非単純な署名および暗号化は、従来の署名および暗号化プリミティブと、署名および暗号化操作を相互リンクする追加操作とを組み合わせて、単純な署名および暗号化の脆弱性を回避する認証済みの暗号化方法になります。これは、認証済み暗号化の設計基準を満たすようにゼロから設計された真の認証済み暗号化とは対照的です。
従来の署名と暗号化から認証された暗号化を構築するこのアプローチは魅力的です。それが正しく行われれば、署名アルゴリズムと暗号化アルゴリズムを組み合わせることができ、よく知られている、戦闘テスト済みのプリミティブから始めると分析が容易になる可能性があります。まったく新しい暗号を設計するよりも。このアプローチにも前例があり、PBKDFやHMACなどの高レベルの操作は既存のハッシュプリミティブに基づいて構築されています。