fts encrypted
1.0.0
注：トークンは、暗号化トークンではなく、語彙トークンを指します。たとえば、トークナー剤は「学習」、「学習」、「学習」を「すべて」に変えることがあります。
暗号化が必要ない場合、タンティビーはあらゆる方法で優れています。
DioxusとEnronの電子メールセットを使用した基本的なGUIデモは、ここで私のGitHubで入手できます。主に、クライアント側のアプリケーションに保存されているデータセットの種類には、検索速度が適切であることを示すことです。
これはまだ進行中の作業です。このライブラリまたはその依存関係について、概念的またはその他の依存関係について保証は行われていません。セキュリティ監査はこれまでに実行されていません。あなた自身の責任で使用してください。
検索またはインデックスの各キーワードはトークン化されます。このトークンとそれが発生するテーブル名は、Blake2B-128でハッシュされ、AES-128-ECBで暗号化されてから、クエリに保存または使用されます。
Encrypt(Hash(token + table_name))
ECBモードは暗号化に使用されます。 ECBは同一のプレーンテキストを同一にしますが、これはトークンやテーブル名のハッシュなどの一意の値の懸念ではありません。これは、同じトークンが別々のテーブルで発生する場合、異なる暗号文があることを意味します。
ドキュメントIDは、AES-128-ECBで暗号化されています。これは、32ビットカウンターに関連付けられます。
ドキュメントIDが何度も表示され、ドキュメントIDの数は128ビットで列挙できるよりもはるかに少ないため、ドキュメントIDを圧縮できます。
1,000個のユニークなトークン /ドキュメントを仮定すると、ドキュメントにトークンの発生を保存するコストは次のとおりです。
| ドキュメント | 最適化されていません | 32ビット |
|---|---|---|
| 1000 | 16MB | 4MB |
| 10k | 160MB | 40MB |
| 50k | 800MB | 200MB |
| 100k | 1.6GB | 400MB |
| 250k | 4ギガバイト | 1GB |
| 百万 | 16ギガバイト | 4ギガバイト |
| 十億 | 16tb | 4TB |
差異は、それらの違いとしてシーケンス内の値を表しています。これにより、ビットが少なく表現できる値が作成され、ビットパッキングが狭くなります。
ビットパッキングクレートは、128の整数の違いとビットパッキングブロックに使用されます。
値がソートされている場合は、違いが最適に機能しますが、並べ替えられた値とビットパックされた値を維持するには、注文不能なエントリが追加されたときにすべての値を再エンコードする必要があります。秩序外の値のコレクションを使用して償却アプローチを使用すると、それらを償却することで変更のコストを削減できます。
| レイヤー番号 | 梱包スキーム | ソート | ディフング |
|---|---|---|---|
| 0 | なし-32ビット（<128 ints） | なし | いいえ |
| 1+ | bitpacker4x（128 ints） | 0を超える層のグローバルに | はい |
約9,000〜10,000件のエンロンメールが圧縮され、結果のFTS DBサイズは32ビットエンコードを使用して235MBでした。償却された差分と層状のビットパッキングを使用すると、それを21MBに変更しました。
ファイルの削除は...費用がかかります...償却todo
Todo Explore。 Rocksdbメムテーブルやそりのようなもの。メモリに変更を保存し、500msごとにフラッシュするか、メモリ制限に達したときにフラッシュします。
最初の3文字または4文字（トークン化されていない）で単語を並べ替え、圧縮しますか？と暗号化。 CBCやGCM（認証暗号化）のような拡散を備えた何かを使用して、暗号化をブロックします。これは、オートコンプリートが3または4文字の後に始まることを意味します。これはまだ概念的な段階にあります。
データの整合性は、近い時間にデータベースファイルをハッシュし、暗号化されたバージョンのハッシュを保存することにより、オプションです。
暗号化されたドキュメントIDに拡散はありません。拡散を追加するには、ランダムに生成されたIVを使用してドキュメントIDを暗号化する必要があります。これにより、圧縮が不可能になります。 IVを保存すると、トークンごとに128ビットが追加され、ペアがドキュメントされます（AES CBCの場合）。
以下は、鍵なしで攻撃者に表示されます。
医師のオフィスの患者リストのインデックスの場合、キーのない攻撃者は、患者の数と文書内で使用されるトークンの分布を見ることができます。名前やその他の識別子など、プレーンテキストを見ることができず、患者の文書IDを表示することさえできませんでした。 2人の患者が検索トークンを共有しているかどうかを確認できましたが、患者が誰であるか、共有情報が何であるかについては何もありませんでした。
たとえば、ベトナムなどの一般的な姓を持つ国の名前のみに検索インデックスが構築されている場合、頻度分析を行い、姓Nguyen（ベトナムの人口の38％）の姓を持つ患者の可能性を把握できます。これは、手元のデータセットに対して有効である以前の（姓の分布）に依存しています。また、普通の名前に対してのみ効果的であり、特定されておらず、ベトナムで3番目に一般的な姓（11％、LEが10％でLE）から2番目を含む文書を自信を持って区別することはほとんどありません。
もう一度情報は、年齢、故郷、住所、説明など、周波数分析を実施する能力など、検索インデックスに追加されます。
懸念事項の1つは、一意のデータセットを保存することの非繰り返しです。ここでは、大きな既知のプレーンテキストデータセットの周波数分析を使用して、合理的な疑いを超えて、特定のデバイスがそのデータセットにインデックス化されていることを示すことができます。これは、権威主義国や犯罪者の反体制派にのみ影響するように思われます。これは、デバイスがオフになったときに完全なディスク暗号化によって軽減できます。
d1トークンt1を使用したドキュメントとします。 t2 、ハッシュがt1と衝突し、ドキュメントd1のトークンではないトークンとします。
検索結果に追加の無関係な結果が含まれていた誤検知は、検索にt2ではなくt1が含まれている場合、 d1に発生する可能性があります。
検索結果から関連する結果が省略された誤検知ネガは、衝突トークンの1つがドキュメントに対して削除された場合にのみ発生する可能性があります。これにより、他のトークンも「削除」されます。
誤検知またはネガティブは、衝突するトークンの1つを持つドキュメントにのみ適用されます。これにより、このような衝突の利害関係が非常に低くなります。
衝突の実際のリスクは、128ビットのハッシュでコミカルに小さいです（ウィキペディアの誕生日の問題を参照）。
64ビット暗号化は、非常に大きなインデックスの場合、数メガバイトのスペース節約をもたらします。英語には約1,000,000語とトークンが少ない。 6400万ビットはわずか8MBです。上位100個ほどの単語が頻度の半分を構成できる言語で見られる電力法の種類分布を考えると、実際の節約はかなり少なくなります。
