暗号化されたデータはファジー クエリにはあまり適していないことはわかっていますが、この記事では、皆さんにインスピレーションを与えることを願って、暗号化されたデータに対するファジー クエリの実装について説明します。データ セキュリティのため、開発プロセス中に重要なデータを暗号化して保存することがよくあります。一般的なデータには、パスワード、携帯電話番号、電話番号、詳細な住所、銀行カード番号、クレジット カード確認コード、その他の情報が含まれます。これらの情報には、暗号化と復号化の異なる要件があります。たとえば、パスワードを暗号化して保存する必要があります。一般に、不可逆的な低速ハッシュ アルゴリズムが使用されます。低速ハッシュ アルゴリズムは、ブルート フォース クラッキング (通常はセキュリティに時間を費やす) を回避できます。検索時に復号化やあいまい検索は必要なく、暗号文を直接使用して完全に一致しますが、携帯電話番号についてはこれができません。携帯電話番号の元の情報を表示する必要があり、携帯電話番号のあいまい検索をサポートする必要があるため、今日は可逆的に暗号化および復号化されたデータに対するあいまいクエリをサポートし、どのような実装方法があるかを確認します。
暗号化データのファジー クエリを次の 3 つのカテゴリに分類しました。
- 砂の彫刻法（ストレートな思考を考えず、ただ機能を認識し、問題について深く考えない）
- 従来の方法 (クエリのパフォーマンスの問題を考慮し、パフォーマンスのためにストレージ容量を使用するなど)
- 超神アプローチ（アルゴリズムレベルから考えるよりハイエンドなアプローチ）
これら3つの実装方法の実装アイデアとメリット・デメリットを一つずつお話していきます まず、砂像工法について見ていきましょう。
1. 砂彫刻の手法
- 復号化のためにすべてのデータをメモリにロードし、復号化後、プログラムアルゴリズムを使用してファジーマッチングを行います。
- 暗号文データを平文マッピング テーブル (一般にタグ テーブルとして知られる) にマッピングし、タグに対してファジー クエリを実行して暗号文データを関連付けます。
砂の彫刻その１
最初の方法を見てみましょう, すべてのデータをメモリにロードして復号化する方法です. データ量が少ない場合は, この方法を使用できます. この方法は簡単で手頃な方法です. データ量が多い場合は大惨事になります. 大まかに計算してみましょう. 英語の文字 (大文字と小文字は区別されません) は 1 バイト、中国語の文字は 2 バイトを占め、DES を例として使用すると、13800138000暗号化された文字列はHE9T75xNx6c5yLmS5l4r6Q==24 バイトを占めます。
| 行数 | バイト | MB |
|---|---|---|
| 100ワット | 2400万 | 22.89 |
| 1000ワット | 2億4000万 | 228.89 |
| 100000000 | 24億 | 2288.89 |
その範囲は数百メガバイトからギガバイトに及ぶため、アプリケーションは数分でメモリ不足に変換される可能性があります。データが数百、数千、または数万にすぎない場合は、完全に変換することができますが、データ量が大きい場合は、強くお勧めできません。
砂の彫刻Ⅱ
2 番目の方法を見てみましょう。暗号文データを平文マッピング テーブルにマッピングし、マッピング テーブルに対してファジー クエリを実行して暗号文データを関連付けます。? ? ！！！では、なぜデータを暗号化するのかというと、直接暗号化しない方が良いのではないか！データ暗号化にはセキュリティ要件が必要なので、これを行います。平文マッピング テーブルを追加すると、セキュリティ要件に違反します。これは安全でも便利でもありません。
2. 従来の慣行
最も広く使用されている従来のアプローチを見てみましょう。このタイプの方法は、データのセキュリティを満たし、クエリに適しています。
- 暗号化アルゴリズム機能をデータベースに実装し、あいまいクエリ時に使用します。
decode(key) like '%partial% - 暗号文データに対して単語分割組み合わせを実行し、単語分割組み合わせの結果セットをそれぞれ暗号化して拡張カラムに格納します。
key like '%partial%'
ルーチン 1
プログラムに合わせた暗号化・復号化アルゴリズムをデータベースに実装し、あいまい検索条件を変更し、データベース暗号化・復号化機能を利用して、復号化してからあいまい検索を実行します。この利点は、実装コストが低く、開発コストと使用コストが低いことです。以前のあいまい検索を少し修正するだけで実現できますが、欠点も明らかです。この方法では、データベースのインデックスを使用してクエリを最適化できません。データベースによっては、同じ暗号化と復号を保証できない場合があります。プログラムとしてはイオンアルゴリズムを使用していますが、従来の暗号化および復号化アルゴリズムのアプリケーションプログラムとの整合性を保証できます。クエリ パフォーマンスの要件が特に高くなく、データ セキュリティの要件が平均的な場合は、AES や DES などの一般的な暗号化および復号化アルゴリズムを使用することも良い選択です。会社が独自のアルゴリズム実装を持っていて、複数端末のアルゴリズム実装を提供していない場合は、優れたアルゴリズムを持っている人を見つけて研究して複数端末の実装を完了するか、この方法の使用を諦めてください。
ルーチン 2
暗号文データに対して単語分割の組み合わせを実行し、単語分割の組み合わせの結果セットを別途暗号化して拡張列に格納し、クエリ時に '%partial%' のようなキーを使用する、比較的コスト効率の高い実装方法です。最初に実装アイデアを分析しましょう。まず、文字を固定長でグループ化し、フィールドを複数に分割します。たとえば、英語 4 文字 (半角) と中国語 2 文字 (全角) を検索条件として使用します。
ningyu14 文字をグループとして暗号化方式を使用します。最初のグループは ning、2 番目のグループは ingy、3 番目のグループは ngyu、4 番目のグループは gyu1... というようになります。「ingy」などの検索条件の4文字を含むデータを暗号化して全データを取得したい場合は、 key like “%partial%” データベースを確認してください。
暗号化後に長さが増加することは誰もが知っていますが、ストレージの長さの増加は追加のコストとなります。通常の使用コストは速度と引き換えになります。暗号文の増加率はアルゴリズムによって異なります。DES を例に挙げると、暗号化前は 11 バイトを占有し、暗号化された文字列は 24 バイトを占有し、増加は 2.18 倍13800138000ですHE9T75xNx6c5yLmS5l4r6Q==。
話に戻りますが、この方法では暗号化データのあいまいクエリを実現できますが、あいまいクエリの文字長には要件があり、上の例では、あいまいクエリの原文文字長は英数字4文字以上、または漢字2文字以上である必要があります。これより短いと単語分割の組み合わせが増加し、ストレージコストが増加し、セキュリティが低下するため推奨できません。Taobao、Pinduoduo、JD の API に接続したことがありますか? これらは、プラットフォームの注文データ内のユーザー機密データを暗号化し、同時にファジー クエリをサポートします。これが使用される方法です。以下に、いくつかの電子商取引プラットフォームの暗号文フィールド取得スキームの説明をまとめました。興味がある場合は、以下のリンクを確認してください。
- 淘宝網暗号文フィールド取得スキーム: https://open.taovao.com/docV3.htm?docId=106213&docType=1
- Alibaba テキストフィールドの取得スキーム: https://jaq-doc.alibaba.com/docs/doc.htm?treeId=1&articleId=106213&docType=1
- Pinduoduo 暗号文フィールド取得スキーム: https://open.pinduoduo.com/application/document/browse?idStr=3407B605226E77F2
- 京東暗号文フィールド取得スキーム: https://jos.jd.com/commondoc?listId=345
この方法の利点は、実装が複雑ではなく、使用が比較的簡単であることです。拡張フィールドのストレージ コストが増加するため、妥協的な方法ですが、データベース インデックスを使用することでクエリ速度を最適化できます。この方法をお勧めします。
3. 超自然的なアプローチ
優れた実践例を見てみましょう。これらの方法はより難しく、アルゴリズム レベルから検討されます。新しいアルゴリズムを設計する人もいます。既製のアルゴリズムのリファレンスもいくつかありますが、そのほとんどはそのまま使用できない半完成品です。したがって、誰かが詳細な調査を実施し、それらを独自のアプリケーションに統合する必要があります。
アルゴリズム レベルで考えると、新しいアルゴリズムでもあいまい検索をサポートするように設計されます。このレベルは主にプロのアルゴリズムエンジニアの研究分野です。整然と、非不利なものであり、非不利なアルゴリズムを設計することは単純な問題ではありません。また、暗号文の長さの長さはあまり速く成長できません。一般的なアイデアは次のとおりです。デコード方法は次のとおりです。さらなる調査が行われていないため、参照のためにインターネットからいくつかの情報を見つけました。
- データベース内の文字データのあいまい一致暗号化方式: https://www.jiamisoft.com/blog/6542-zifushujumohupipeijiamifangfa.html
ここで注目できるのは、ヒル暗号処理とあいまい一致暗号方式 FMES です。
- 高速クエリをサポートするデータベースを暗号化する方法: https://www.jiamisoft.com/blog/5961-kuaisuchaxunshujukujiami.html
- Lucene ベースのクラウド検索と暗号文に基づくファジー クエリ: https://www.cnblogs.com/arthurqin/p/6307153.html
Lucene に基づく考え方は、上で紹介した従来の方法 2 と同様で、文字を同じ長さの単語に分割し、単語分割後の結果セットを暗号化して保存しますが、格納される DB が異なり、一方はリレーショナル データベース、もう一方は es 検索エンジンです。ここで、暗号化データのすべての検索スキームの紹介を終了しました。最初に、インターネット上のどこでも見られる砂像の手法について触れました。また、これらの砂像の手法は推奨されず、可能な限り使用する必要があるともここで述べました。会社に専門的なアルゴリズムの才能がある場合は、アルゴリズム レベルに基づいて超自然的な手法を検討することもできます。一般に、入力、出力比率、実装と使用のコストの観点から、2 番目のルーチン方法が強く推奨されます。