複数のキーを使用してドキュメントを暗号化し、それらのキーに責任を持たせる


4

ここで仮説。非常に機密性の高いファイルがあり、これを公開したくない、他の人も公開したくない。殺される可能性を減らすために、暗号化されたバージョンのファイルをbittorrentで公開し、殺された場合に公開する指示とともに暗号化キーを信頼できる関係者(「キーホルダー」)に渡します。次に、公開したファイルが本物であることを公開します。(はい、マニングの状況について話しているところです。)

1つのキーホルダーが侵害され、次の3つのことを行う可能性を回避する必要があります。

  1. 平文ドキュメントを公開する
  2. 公開した認証文を使用して、平文が本物であることを一般に知らせます(つまり、もっともらしい拒否を削除します)
  3. 匿名のまま

たとえば、これを行う1つの方法を次に示します。

  1. 各キーホルダーに1つずつ、N個の対称キーを作成します。
  2. 各キーホルダーについて、プレーンテキストのコピーを作成し、「このドキュメントのリリース者:」とそのキーホルダーのIDを先頭に追加します
  3. 各コピーをそれぞれの対称キーで暗号化します
  4. キーをそれぞれ配布する
  5. 完全なファイルを公開する

ただし、これにはN * size_of_plaintextスペースが必要です。この質問は、より効率的な方法があるかどうかを尋ねています。

最初に、gpgの複数キー暗号化について調査しました。https://stackoverflow.com/questions/597188/encryption-with-multiple-different-keys(@terdonに感謝)を参照してください。GPGは次のように機能します。

gpg --encrypt --recipient alice@example.com --recipient bob@example.com doc.txt
  1. GPGは対称キーを選択します(X
  2. GPGはプレーンテキストを暗号化します X
  3. GPGは、暗号化Xパーティのキーを使用してP_aliceP_bob...及びその他アリス、ボブは、それぞれそれらのいずれかを復号化することができます

これは、回避したい攻撃に対して脆弱です。

  1. ボブはP_bob復号化に使用しますX
  2. ボブはX匿名で公開します
  3. 公開された平文を公開します X

-1。質問を投稿する前に、時間をかけて検索してください。質問のタイトルをGoogleに貼り付けてコピーします。これが最初のヒットです。
テルドン

おそらく、私はその質問に追加すべきでした。しかし、私が探している機能は、(単なる)暗号化ではなく、説明責任です。
ウィリアムエントライケン

Downvoteは撤回されましたが、タイトル(および質問)を編集して、求めているものを明確にしてください。
テルドン

回答:


3

プレーンテキストの暗号化ハッシュの適切なセットを事前に公開できます。たとえば、平文の[ MD5SHA-1-160SHA-3-512RIPEMD-320 ]ハッシュのセットを公開することにより、それらのハッシュすべてに同時に正確に一致する平文を見つけることは非常に困難です。このような攻撃は、第1または第2のより著しく困難であろうことに留意されたいプリイメージ攻撃ため関与するハッシュアルゴリズムのいずれかに対して同じデータが正しい値にハッシュしなければならないすべての関与するアルゴリズム読んだときに意味があります。また、ウィキペディアによると、これらのうち少なくとも少なくともSHA-3-512とRIPEMD-320には、全出力スペースに対するブルートフォースよりも優れた攻撃があることは知られていません。プリイメージ攻撃は依然として2 ^ 123であり、完全な出力スペース2 ^ 128に対する全面攻撃よりもわずかに単純です。(基本的に、衝突攻撃は両方の入力を選択し、一方のハッシュが他方にも有効であるように同一のハッシュを生成する異なる入力のペアを探している場所です。プリイメージ攻撃は、ハッシュといくつかの入力、できれば与えられたハッシュを生成する元の入力とは異なるものを探しています)これらのハッシュ値自体は、プレーンテキストデータについては何も言いません。

攻撃をさらに複雑にするために、Merkle-Damgårdの構造に基づいていない少なくとも1つの暗号化ハッシュアルゴリズムを、従来の圧縮関数(上記のハッシュアルゴリズムは、SHA-3を除いて、 )、そのような獣が存在する場合; 頭の上のものは知りませんが、可能性を排除するものではありません。どうやら、Keccak / SHA-3は少なくとも一部が異なるデザインを使用しているため、このようなハッシュアルゴリズムセットに含めるのに適しているようです。

これにより、後のある時点で平文ファイルのコピーを受け取った人は、あなたに何かが起こった場合に公開するつもりのものと一致することを確認する方法を得ることができます。その人が平文が本物であるという非常に高い確実性を得るためには、その人はそれらのハッシュのソースが本物であることを信頼するだけでよい(そしてハッシュ値の自分のコピーが改ざんされていないこと) 、タンパーエビデントシールを使用して明らかにローテクな方法で実行できます)、コンピューターのハッシュを計算するために使用されるソフトウェアが想定どおりに動作します(複数の個別の実装を使用して、ある程度独立して検証できます)公開されたテストベクトルに対してこれらの実装をテストします)。

ただし、暗号化された平文のコピーを複数配布することなく、誰が復号化キーを漏らしたのかについて本当の責任を負うことはできないと思います 各平文ブロックと受信者の鍵のための別個の暗号化されたデータ・ブロックを必要としない、任意の複数の鍵暗号方式は、平文が特定のキー使用して暗号化されていることを必要とするであろうK_0次いで順番に受信者の鍵のセットの各々を用いて暗号化されたK_1を通してK_nために、n受信者、および暗号化されたマスターキーの完全なセットE(using K_n)(K_0)暗号文に含まれています。(それが望ましくない場合はいつでも、プレーンテキストごとに複数の暗号化テキストが必要です。これにより、攻撃者にとって、攻撃者の名前がManningかSnowdenかどうかが懸念される攻撃対象領域が増えます。) 「マスター」復号化キーK_0。保護しようとしているシナリオを正確に提示します。

私が考えることができる唯一の方法については、DESのようなアルゴリズムを使用することです(古い恐竜について言及しているため、この答えを投票する前に読んでください)キーマテリアルの未使用のパリティビットを許可し、それらのビットを各受信者に対して一意に設定し、また、各キー受信者のパリティビットが何であるかをメモしておきます。(とにかく、セキュリティに影響を与えないあなたは残りのキーマテリアルの独立したこれらの「パリティ」ビットを設定するのではなく、実際のパリティと、これらのビットのようになりますので、このことから、セキュリティのないdegredationはありません。)合理的なセキュリティのためのようなスキームEDE 3DES使用することができます。ただし、暗号文にアクセスし、アルゴリズムの知識があり、暗号化の知識がある人は、暗号化アルゴリズムのこのプロパティを知っているか、簡単に見つけることができ、未使用/パリティビットを任意の値に設定できます復号化キーを公開する前に、考えられる説明責任の手段を無効にし、おそらく他の誰かに指を向けます。

これはいずれも、対称(または非対称)暗号化の使用を想定していないことに注意してください。対称アルゴリズムのみのアプローチは、おそらく非対称アルゴリズムのみのアプローチよりもはるかに実用的ですが、どちらでも完全に実行できます。それはだ簡単に(鍵配布問題を解決するという意味で)、より実用的なデータのための対称暗号化を使用するように(暗号文のサイズのEg換算)、その後、解読キーの非対称暗号化-それは、非対称暗号化が正常に行われている方法です。 -しかし、そこには絶対に言って何も持ってそのように行うために、そしてあなたはまだ何とかあなたがする復号鍵を暗号化されている公開鍵を信頼できるようにする必要があります。


[OK]を、私は現在、暗号化はすべて本当にプレーンテキストに対して対称であり、キーに対して非対称であることを受け入れています。しかし、あなたのソリューションは間違いなく創造的であり、信用を得ています。乾杯!
ウィリアムエントライケン

@FullDecent非対称暗号化を使用する必要はまったくありません。私の編集を参照してください。キーの配布が容易になりますが、対称のみのアプローチでも、キーの配布は解決可能な問題です。
CVn

0

アリスがそのような主張をする場合、他の人がその主張を検証する方法が必要です。私は常に公開キー暗号化は認証の方法にはあまり役に立たないという印象を受けていましたが、何らかの方法でデジタル署名のようなものを導入すると、説明責任の問題に対処するドキュメントの信頼性を検証できます。

あなたがgpgを使用しているので、ここで説明されているもののようなもの:http : //www.tutonics.com/2012/11/gpg-encryption-guide-part-3-digital.html

送信者が公開鍵を使用して受信者のデータを暗号化する場合、受信者は送信者が実際に自分が誰であるかをどのように知るのですか?

公開鍵は誰でも使用できるため、その送信者がデータが送信者から来たことを明確に証明する手段が必要です。GPGは、データが改ざんされていないことを証明するデータの署名(指紋など)の生成と組み合わせて上記の方法を提供します。


「送信者」は暗号化されたファイルを準備して配布する人であり、「受信者」は送信者から暗号化されたファイルを受信する人であることに注意してください。この場合、受信者はファイルを復号化して平文を配布するか、他の誰かが暗号文を復号化するために鍵を配布します。キー。そのような状況では、暗号化されたファイルが復号化されるときに署名を削除できるため、署名は役に立ちません。
CVn

0

暗号化されたファイル自体を公開するのではなく、公開キーのコピーを公開します。次に、それぞれの信頼できるキーホルダーに、ドキュメントの平文コピーを、ドキュメントの正当性を裏付ける暗号化された(公開したばかりの公開キーに対応する秘密キーとともに)自分の声明とともに提供します(たとえば、ドキュメント)、およびこのステートメントを提供しているキーホルダーの名前を記載しています。

この方法では、キーホルダーのいずれかがプレーンテキストドキュメントを漏らす可能性があります。しかし、その正当性を証明するために、彼らはあなたからの署名された声明のバージョンを明らかにしなければなりません。

さらに保護するために、Shamirの秘密共有アルゴリズムを使用して、キーホルダー間でキーを分割し、各キーホルダーに与えられたプレーンテキストドキュメントを暗号化できます。そのようにして、個々のキーホルダーは、他のキーホルダーの1つ以上と協力することなく、機密ファイルの内容を読んだり明らかにしたりすることはできません。このスキームを使用すると、ドキュメントを公開するために協力するキーホルダーをいくつでも必要とすることができますが、ドキュメントの正当性を確認するためにキーホルダーの1人だけが身元を明らかにする必要があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.