使用されているOPのキーのもっともらしい否認を可能にする暗号化および署名システム（許可されていませんか？）
マロリーがメッセージに暗号化と署名キーを盲目的に照合するのを防ぐ必要があります
架空のシナリオ：
- ユーザーが公開鍵を作成する
- 暗号化または署名されたペイロードが存在します。
- 公開鍵と署名または暗号化されたペイロードのみを使用して、マロリーは誰がデータに署名したかを調べたいと考えています。マロリーが暗号化されたペイロードを公開鍵に関連付けるのを防ぎたい。
最新の暗号化プリミティブ（GCM、AES、RSA、Blowfish）はこのタイプの関連付けを許可していると思いますが、一部のプロトコル（GSM？、SMIME？PGP？）がペイロードの署名鍵を開示する可能性があります- 仕様で省略が許可されている場合でも
質問
誰かがどの暗号がもっともらしい否認を可能にするか、または逆にそうでないかを教えてもらえますか？*
*どちらが大きいかわからないため、あまりにも広い理由が近づかないようにします
追加情報：
- マロリーは公開鍵を持っているため、CPA攻撃が可能である可能性がありますが、データはランダムである必要があります。
- 元の署名者と目的の受信者がキーを検証できることは許容されます。
- マロリーが何らかの方法で接続をMITMし、彼女のキーを署名者に渡す場合、もっともらしい否認は適用する必要はありません。
暗号化されている場合、公開鍵を知っているだけで、使用された鍵を隠すことができる場合があります。公開キーは対称暗号のランダムキーを暗号化するだけなので、キーの長さが十分に長い場合、ブルートフォースできないことを意味します。秘密鍵の所有者は、単に鍵を復号化し、データが適切に復号化されているかどうかを試みます（たとえば、添付されたhmac）。マロリーは単にすべての可能なキーをテストすることはできません。
一方、データが署名されている場合、その定義により、キーAが署名されたデータを検証できる必要があります。したがって、Malloryは常に、そのファイルに署名した公開鍵を特定できます。 （OTOHは、Malloryがキーを持っていない場合、たとえば「メタデータ」を含むスキーマであっても、容疑者全員からのキーを含むデータベースがある場合、通常は使用されているキーのフィンガープリントしか提供しないため、役に立たない）
単純な答えは、encrypt（sign（data））です。
明らかに、メタデータ（メールアカウントの送信など）がIDを漏らしてはなりません。
これは、キーをメッセージに盲目的に一致させる特定のシナリオでもっともらしい拒否可能性を達成するだけです。ボブは、彼が受け取ったメッセージがアリスによって送信されたことを完全に証明することができます。通常、もっともらしい否認という用語は、アリスが書いたことを否定することさえできることを意味するために使用されます。そのためには、OTRのようなプロトコルを使用できます。