1

ユーザーが（機密情報を含む）ネストされた文字列のツリーを作成できるWebアプリケーションを作成しているとしましょう。これらの文字列はおそらく非常に短いです。保存する前に、このツリーのキーと値の両方を暗号化したいと考えています。ツリー内のすべての値は、ユーザーが指定した対称キーを使用してクライアント側で暗号化されます。同様に、読み取り時にクライアント側で復号化されます。

ツリーは Mongo データベースに永続化されます。

ツリー内のすべてのデータが同じキーを使用して暗号化されることを考慮して、ツリーをシリアル化して文字列全体を暗号化するか、値を個別に暗号化するかを決定できません。

どちらの長所と短所は何ですか？

私が知る限り、AES は 128 ビットのブロック サイズを使用します。つまり、文字列はエンコード時に最大 15 文字の長さになる可能性があり、シリアル化された文字列をエンコードすることを支持します (オーバーヘッドを避けたい場合)。

注: webapp は HTTPS、IP ホワイトリスト、および多要素認証の両方を使用しますが、Mongo データベースが盗まれた場合に備えて、データ侵害を防ぐ努力をしたいと考えています。それが私がここにいる目的です。これを達成する方法についてのアドバイスや考えをいただければ幸いです。

アップデート

さらに、私のサービスが信頼を刺激することも望んでいます。(HTTPS 経由ではありますが) 平文でデータを送信するということは、データを永続化する前に、ユーザーがデータを暗号化することを信頼する必要があることを意味します。クライアント側を暗号化すると、何を保存しているのかわからない (または知る必要がない) ことを強調できます。

4

2 に答える 2

2

これらのアプローチが実際の文字列のセキュリティに関して異なる理由は考えられません (両方が正しく実装されていると仮定します)。文字列を個別に暗号化するということは、明らかにツリーの構造が秘密にされないことを意味しますが、それを気にするかどうかはわかりません。たとえば、各文字列を個別に暗号化すると、暗号文を見た人はツリーに含まれるキーの数を知ることができ、各キーと値の長さについても知ることができます。ツリーをシリアル化されたブロブ全体として暗号化すると、暗号文を見た人はツリー内のデータ量を大まかに知ることができますが、個々のキー/値の長さや数については何もわかりません。

あなたが言及したように、オーバーヘッドに関しては、パディングが考慮されます。ストレージ オーバーヘッドの大きな原因は IV です。CTR などのブロック暗号モードを使用している場合は、暗号文ごとに個別の IV を使用する必要があります。つまり、各文字列を個別に暗号化する場合、文字列ごとに IV を保存する必要があります。シリアル化されたツリー全体を暗号化する場合は、その 1 つの暗号文に対して 1 つの IV を保存するだけで済みます。

ただし、これを Javascript で実装する前に、クライアント側の暗号化を行うことで実際にセキュリティが向上していることを確認する必要があります。この記事は古典的です。サーバー。盗まれたデータベースが主な懸念事項である場合は、データベースにデータを挿入する前にサーバー上のデータを暗号化するだけで、同じセキュリティを実現できます。

于 2013-03-16T22:07:33.183 に答える
0

まず第一に、私はセキュリティの専門家ではありません;-)

ツリー内のすべてのデータが同じキーを使用して暗号化されることを考慮して、ツリーをシリアル化して文字列全体を暗号化するか、値を個別に暗号化するかを決定できません。

最初にツリーをシリアライズし、その結果を暗号化することには最大の短所があります。

暗号の解読に成功するために大きな役割を果たしているのは、多くの場合、元のテキストに頻繁に現れる特定の文字 (英語の e と n など) に関する知識と、暗号化されたテキストに基づく統計分析の実行です。

たとえば、JSON を使用して、ツリーを暗号化する前にクライアント側でシリアル化するとします。攻撃者として、クライアント側のスクリプトを自由に分析できるので、私はそれを簡単に知ることができます. したがって、「文字」{、}、[、]、:、" は、暗号化するすべての「テキスト」で高い割合で出現することもわかっています...そして、すべてのテキストの最初の文字は、 { または [ (ツリーがオブジェクトであるか配列であるかに基づく) – これは、アプリによって暗号化されるテキストについて、潜在的に非常に役立つ知識のかなりの部分です。

于 2013-03-16T21:54:04.183 に答える