「1234」などの値を想像してください。その値を「abcd」などの別の値にマップしたいと思います。制約:
これは基本的なアルゴリズムである必要があり、最終的には Ruby で記述しますが、ここでは関係ありません。
私は次の行に沿って考えていました：
SECRET = 1234
def to(int)
SECRET + int * 2
end
def fro(int)
(int - SECRET) / 2
end
明らかに、これは制約 1 と 3 に違反しています。
最終的な目標は、データベース内のレコードを匿名化することです。私はこれを考えすぎているかもしれません。
まず、あなたの目標は野心的すぎると思います。なぜ制約 6 なのですか?
第二に、技術的に必要なのは、整数のドメインからの全単射です。
第三に、制約 3 はカーコフの原則に反します。秘密鍵によって管理されるよく知られたアルゴリズムを使用したほうがよいでしょう。この場合、大きな整数セットの結果がわかっている場合でも、秘密鍵を導き出すのは困難です。
第四に、あなたは何に対して匿名化していますか? 個人情報を扱っている場合、他のデータとの関係に基づいて、Xyzzy が実際に John Doe であることを明らかにする統計分析からどのように保護しますか? このような攻撃ベクトルに対抗するための研究がいくつかあります (たとえば、' k-anonymization ' をググってください)。
第 5 に、独自の暗号化プリミティブを作成しようとするのではなく、既存の暗号化プリミティブを使用します。十分にテストされた暗号化アルゴリズム (暗号ブロック連鎖モードの AES など) が存在します。AES は、おそらく Ruby と同様に、最新のすべてのプラットフォームで十分にサポートされています。ただし、暗号化は依然としてレコードに強い意味での匿名性を与えません。
達成しようとしていることについてもう少し詳しく説明する価値があるかもしれません。おそらく、悪意のある人物がデータを入手することを心配しているでしょうが、この悪意のある人物がデータベースにアクセスしたコードにもアクセスできる可能性はありませんか? あなたのコードを調べて、彼らがアルゴリズムを学習するのを止めるにはどうすればよいでしょうか?
本当にデータを匿名化したい場合、それは通常、一方通行です (名前が削除される、クレジット カードの値が削除されるなど)。データベースのコンテンツを暗号化しようとしている場合、多くのデータベース エンジンはこれを行うための十分にテストされたメカニズムを提供します。例えば：
MSSQL で暗号化されたデータを処理するためのベスト プラクティス
独自の暗号化メカニズムを使用するよりも、製品の暗号化メカニズムを使用する方が常に優れています。