web-dev-qa-db-ja.com

現在、実際に機能する最適な検索可能暗号化（SE）アルゴリズムは何ですか？

Searchable Encryptionに関する優れた文献を見つけるのに苦労しています。もちろん、LaTeXでComputer Modernを使用して書かれたいくつかの学生向けの論文には、中には素敵なギリシャのスープがいくつかありますが、実際の具体的な例はありません。 YouTubeの動画も同様です。ウィキペディアの 記事 はせいぜい不足しています。

現在、どのアルゴリズムが最適であるかはまだ判断していません（2018年5月現在）。

現在この分野で実際に機能する最良のアルゴリズムと考えられているものを誰かが知っていますか？参考文献も参考にしたいと思います。

encryptionhomomorphic-encryptionsearchable-encryption
8
HelloWorld

検索可能な暗号化はめったに実用的ではないので、それは希少です。

一般的には、非常に弱い暗号を使用しているか、すべての暗号を解読していることを意味します。最初のケースは、暗号化のパターンを使用して、十分な大きさのサンプルでそれを解読できるため、不適切です。 1つ目のクエリを実行するにはデータセット全体を復号化する必要があるため、2番目の、より推奨される方法は非常に遅くなります。いずれにせよ、検索可能な暗号化は非常に小さなデータセットでのみ実際に実用的です。

単一の従業員レコードでキーワードを検索できるようにしたい場合などに使用します。従業員のIDは暗号化されません。そのため、これを使用してその人のレコードのみをクエリし、レコードセット全体をアプリケーションに渡して復号化することができます。次に、復号化されたデータを検索し、そこから必要なフィールドのみを出力します。

つまり、正確な検索を実行している限り、ソート可能な暗号化には多くの可能性があります。並べ替え可能な暗号化は、新しい暗号化された各文字列の範囲を、並べ替えるべき文字列の間に設定します。したがって、次のことが当てはまるとしましょう：

7iFA384S4BPmuXokR9rcMI37SKnClqnE = ant
E10ZJbnmvJHs3MOKkzDXw7sd037kLCUJ = cat
miHBVXxATe1Jg6G97ug86zv31BxrpRAa = dog
z0L9f8Py12euq9Nhy9Zk0e9L83F8MiBi = man

「fox」をリストに追加したい場合、私の暗号化アルゴリズムは「miHBVXxATe1Jg6G97ug86zv31BxrpRAa」と「z0L9f8Py12euq9Nhy9Zk0e9L83F8MiBi」の間で戻り、次のような結果になります。

7iFA384S4BPmuXokR9rcMI37SKnClqnE = ant
E10ZJbnmvJHs3MOKkzDXw7sd037kLCUJ = cat
miHBVXxATe1Jg6G97ug86zv31BxrpRAa = dog
Pe2624gcRjP6YGWOnhiW2xnRomAjDYQK = fox // sorts alphabetically between dog and man
z0L9f8Py12euq9Nhy9Zk0e9L83F8MiBi = man

暗号化された文字列の最初の部分は単に情報を並べ替えているだけで、2番目の部分は実際の暗号化されたデータであるため、これは機能します

SortingId(Pe2624gcRjP6YG), EncyptedData(WOnhiW2xnRomAjDYQK)

暗号化を並べ替えると、これは2つのことを意味します。1つは、暗号化されていないデータと同じくらい簡単に、暗号化されたデータを並べ替えることができるということです。2つ目は、選択的に復号化できることです。実際にどのデータベースがこれをサポートしているか、まだサポートしていないかは個人的にはわかりませんが、上記のリストで「man」を検索して「dog」を復号すると、上位2項目が男性ではないことがわかります。それらを検索するためにそれらを解読する必要はありません。つまり、データセットが大きいほど、データセットの％を復号化して物を見つける必要があります。

3
Nosajimiki

私は この講演 に今年の初めにいて、そのアプローチに感銘を受けました。この製品はEncryptedQueryと呼ばれ、 秘密情報の取得 の（関連するものと思います）問題を解決しようとします。 PIRの場合、PIRはおそらくSEよりも強力な要件です。PIRを使用すると、dbサーバーでさえ、何を検索したか、またはどのレコードが返されたかを知ることができません。

講演についての私のメモ：

  • 動機：データアクセスパターンを非公開にしたい場合。
  • PIRはOblivious TransferおよびSecure Multiparty Computationの問題と絡み合っています。
  • 2016年NSA PIRKというオープンソースのPIRソフトウェアスタック
  • 2017年にPIRKプロジェクトは終了しました。 Envietaという会社がこのプロジェクトを担当し、EncryptedQueryという名前に変更しました
  • 平文空間での加算が暗号文空間での乗算になるという意味で準同型であるPaillier暗号化を使用します。

アルゴリズムについての私の理解（おそらくこれは当時は理にかなっていたが、おそらく間違っている）は、要求者が文字列を暗号化することである

_encr_req = encr(0 0 0 0 0 1 0 0 0 0 ...}
_

ここで、1を含むkth列は、取得する行番号です。この文字列が暗号化されると、サーバーはどの列に1が含まれているかがわかりません。

次に、サーバーはデータベースを反復処理します

_sum_i( encr_req[i] * encr(data[i]) )
_

Paillierは準同型であり、プレーンテキスト値の1つを除いてすべて0であるため、これは次と同等です。

_0*data[0] + 0*data[1] + ... + 1*data[k] + 0*data[k+1] + ...
_

したがって、復号化すると、結果が得られます。

_decr( sum_i( encr_req[i] * encr(data[i]) ) ) = data[k]
_

長所：

  • サーバーは、要求されたIDを知らなくても、データベースからのアイテムの取得をIDで処理できます。
  • 応答の帯域幅が狭い：sum_i( encr_req[i] * encr(data[i]) )は、単一のデータベースフィールドの幅です。
  • 同じクエリで複数のアイテムをリクエストするように拡張できます。

短所：

  • パフォーマンス：サーバーは要求ごとに、データベース全体を反復処理し、すべてのエントリを要求者の公開鍵で暗号化する必要があります。
  • データベース内のすべての行のビット幅は同じである必要があります（これは、暗号化手順のパフォーマンス上の理由から、小さくしたい場合）。
  • データベース内のエントリの数とその順序は、固定され、要求者に認識されている必要があります。
  • 大規模または構造化されていないDBの場合は、より一般的な（ただし安全性は低い）検索可能な暗号化を使用します。

TL; DRこれが実際にHelloWorldの最適な検索可能な暗号化についての質問に答えているかどうかはわかりません：/

3
Mike Ounsworth