区別が困難な難読化または機能暗号化の例を説明する
Perfecting the Art of Sensible Nonsense で説明されているように、暗号化研究の大きな進歩が2013年の夏に発表されました。
原則として、ほとんどのコンピューター科学者が想定していたことは不可能であると考えられています。コンピューターコードを難読化して、コードを自分の制御下で完全に実行できる攻撃者によってもその秘密が保持されるようにします。この種の難読化は非常に強力であり、たとえば、新しい形式の公開キー暗号化を作成するために使用できます。 function encryption および deniable encryption のブレークスルーに関連しています。
それは記事でこのように説明されています：
...難読化ツールは、コンピュータプログラムをSahaiが「マルチリニアジグソーパズル」と呼ぶものに変換することによって機能します。プログラムの各部分は、慎重に選択されたランダムな要素を混ぜることによって難読化されるため、意図した方法で文字化けしたプログラムを実行すると、ランダム性が相殺され、適切な出力を計算するために部分が合わさります。しかし、プログラムで何か他のことを行おうとすると、そのランダムさにより、個々のパズルのピースは無意味に見えます。
しかし、「...商用アプリケーションの準備が整っているとは言えません。この手法は、短く単純なプログラムを巨大で扱いにくいアルバトロスに変えます。」
扱いにくい理由は、完全に準同型の暗号化（FHE）を使用する必要があることです。これは 関連する質問 で説明されているように、扱いにくいままです。
これは他のスタック交換で議論されていることに注意してください：
Crypto はおそらく一般的な議論に適したフォーラムですが、考えられる実用的な側面（またはその欠如）に関する多くの議論は、ここで行うのが最善です。
現在の最先端技術を考えると、実用的なアプリケーションは存在しないようです。しかし、その発言は例がなければ受け入れがたいものです。だからここに関連すべき質問があります：誰かが区別不能難読化または機能的暗号化がいつの日に使用されるかもしれない種類の有用なタスクの具体例を提供し、この時点でどれほど扱いにくいか（サイズ、パフォーマンス）を説明できますか、など）？
の簡単な説明を追加するだけ 機能暗号化 完全に準同型暗号化してから、機能的な暗号化と区別がつかない難読化に進む前に説明します。主に http://crypto.stanford.edu/craig/easy-fhe.pdf から引用上記はCraig Gentry（この分野のパイオニアの1人）による論文で、数学でアリスの例に従うのは簡単です。
完全準同型暗号化
数学を除く 機能暗号化 完全準同型暗号は次のようなものです。
暗号化されていないデータがあるとしましょう-UD。暗号化されたデータ-EDと呼ばれる非暗号化データの暗号化があります。 UDでいくつかの分析/操作（分析を関数Fと呼びます）を実行して、暗号化されていない出力-UOを取得します。
機能的暗号化によって提起/回答される質問は-暗号化されたデータEDで分析/操作関数Fを実行し、対応する暗号化された出力を取得できます-EO、そのようなEOを復号化すると、上記で定義された暗号化されていない出力を取得できます-UO？
簡単な図（プロセス1はプロセス2と同じ出力を与えるはずです）：
暗号化されていないデータUD->いくつかの分析関数Fを介して渡される->暗号化されていない出力UOを提供します。
a）暗号化されていないデータのUD->暗号化アルゴリズム->暗号化されたデータのED [このプロセスは信頼できる環境で行われます]
b）EDをどこにでも転送します。 -> EDで分析機能Fを実行します-> EO（暗号化された出力）を取得します。 [信頼できない環境、クラウドなど、どこでも実行可能]
c）EOを取得します。 ->復号化アルゴリズム-> UO（暗号化されていない出力）を取得[信頼された環境]
上記のペーパーで説明したように、ビットレベルでの作業スキームは、ADD、SUBTRACT、およびMULTIPLYをサポートする必要があるだけです。そして、それがビットレベルで機能する場合、一般的にすべての計算に拡張できます。
拡張として、一般的な再帰を考えると、分析関数Fを暗号化して、実行されている分析でさえ信頼できない環境に知られないようにすることもできます。
評判が足りないので下のコメントに答えてね！
上記の回答を書いている間、あなたの質問は私を襲った。おそらく、上記の例は少し単純すぎて、概念は少し抽象的です。
一般的に言えば、平文と暗号化されたテキストの間には1対1の対応があり、解読が保証されます。
それでは、「青」というテキストのデータを検索したいとしましょう。上記の例を続けると、テキスト「blue」が「xChd」に暗号化されているとしましょう。したがって、暗号化されたデータを検索すると、「青」ではなく「xChd」が検索されます。アルゴリズム的に言えば、機能は同じです。つまり、「テキストの検索」です。関数の個々のインスタンスは、コンテキストに応じて、異なるフレーズを検索します。しかし、繰り返しますが、これは高レベルの見方では多すぎると言います。
ビットレベルでは、ADD（一般的にORとして知られています）、SUBTRACT（NOTおよびOR）、およびMULTIPLY（AND）のみがあります。これは、論文で説明されているとおりです。それ以外の場合、ビットレベルでは、AND、ORおよびNOTの3つの基本演算しかありません。
今日の世界の典型的な暗号化は、暗号化されたテキストを与えるためにプレーンテキストとXORされるビットのユニークでランダムなストリームを生成することを含みます。復号化では、暗号化されたテキストが暗号とXORされて、プレーンテキストになります。
したがって、著者（Craig）や他の人がビットレベルで達成しようとしていることは次のとおりです。
暗号化されていない入力に対する[AND、OR、NOTまたはこれらの基本操作の任意の組み合わせ]は、暗号化されていない出力を提供します。
暗号化された入力に対して[AND、OR、NOTまたはこれらの基本操作の任意の組み合わせ]のような暗号化スキームを開発することは可能ですか？暗号化されていない出力と同じ出力を与えるために復号化できる暗号化された出力を提供します（ s）。
文献では、完全準同型暗号は、いわゆる評価関数を使用して次のように説明されています。
以下を想定します。
a。 fはブール回路Cに縮約された関数です（つまり、ゲートとさまざまな入出力のみで構成されています）
b。鍵ペア-pkは公開鍵、skは秘密鍵
c。 UIとUOはそれぞれ暗号化されていない入力と出力です
d。 EIとEOは、それぞれ暗号化された入力と出力です。
次に、FHE（完全準同型暗号）は次のように記述されます。
Evaluate（pk、C、EI）は、Decrypt（sk、EO）がUIで回路Cを実行しているのと同じになるEOを提供します。
したがって、FHEでの質問に答えるには、論理またはアルゴが同じでなければならないため、関数fまたは回路Cは同じです。評価関数は、回路Cの暗号化されていない入力/中間体を暗号化された形式に変換できるように公開鍵を必要とします（たとえば、「blue」を検索したい場合、関数fに「blue」が埋め込まれている場合があります。コードですが、暗号化されたデータを「xChd」で検索する必要があります。これも非常に高レベルの例であり、ビットレベルに完全には対応していません。ビットレベルでは、Evaluate関数がさらに、ビットレベルでは、関数は単一の出力として定義されます-基本ゲートAND、ORおよびNOTはすべて単一の出力です。通常の多入力多出力関数は、アルゴリズムについて説明すると、高水準言語プログラムはすべて基本的なゲートから構築されます。ここでは、高水準の類推は失敗し、公開鍵はEvaluate関数で必要になります。非対称暗号化の公開/秘密鍵モデルとの適合-Iと同様私の秘密鍵で暗号化されたデータを送信しますda関数と私の公開鍵、FHEは次のように要約できます-公開鍵を使用して暗号化されたデータの関数を計算し、暗号化された出力を送信できます ）。
機能暗号化
機能暗号化に移ります。 FE（Functional Encryption）は、非常に単純または明確に定義されていません。実際、FEの定義を形式化することを専門に扱った研究論文全体があります- http://eprint.iacr.org/2010/543.pdf
FEは少し魔法のように聞こえます-誰かが公開鍵/秘密鍵の暗号化を紹介されたときのようです。
FEにも、マスターシークレットキー（msk、マスターキーとも呼ばれます）があります。ファンクションキー-fkは、しばしばskf、秘密のファンクションキー、秘密のトークン、秘密のキーと呼ばれます（マスターの秘密のキーと混同しないでください）。 msk/fkペアは、秘密鍵/公開ペアのようなものです。
暗号化されていない入力を「x」と呼びましょう。関数F（またはゲートの回路）があるとします。 E(x) [Encrypted x]]と呼ばれるmskを使用してxの暗号化を行います。次に、関数キー-fkがある場合、F(x) E（x）のみを使用します。出力F(x)は暗号化されないことに注意してください。
それを数学的に述べるF(x) = Decrpyt（fk、E(x)) where E(x)は、キーペアmsk、fkのEncrypt（x、msk）です）
直感に反しているように見えるかもしれませんが、E(x)のサイズまたは長さは関数Fのサイズの関数であり、通常は線形スケーリングではありません。直感的には、関数Fのアルゴリズムまたはロジックが復号化アルゴリズムにマッピングされていると考えてください。また、Decrypt（fk、E(x))の出力は暗号化されていないことに注意してください。したがって、アルゴリズムの暗号化を達成しました！暗号化された入力とファンクションキーをサードパーティに提供でき、サードパーティは暗号化されていないデータに対して関数を実行した結果を取得できます。たとえば、スパムフィルターはメールがスパムかどうかを判断できます、電子メールを復号化することなく、またスパムを決定するための私のアルゴリズムが何であるかを知らずに.
上記のFHEの例では、暗号化されていないデータと暗号化されたデータが1対1で対応しているため、辞書攻撃を簡単に開始できます（同じ入力に対して常に同じ出力を生成するとは限らない暗号化スキームがあり、実際にはほとんどssl、sshなど、広く使用されているすべての暗号化スキームでは、常に同じ入力に対して同じ出力が生成されるわけではありませんが、ここでは説明しません）。一般に、単語は出現順に配置され、簡単に推測されます。しかし、FEでは何も推測できません。データとアルゴリズムの両方が安全です！
FEの主な利点は、さまざまな機能に対してさまざまなファンクションキーを生成できることです。また、ファンクションキーを適切に配布することで、さまざまな人がさまざまな機能にアクセスできるようにすることができます。誰もがすべてを知っている必要はありません[もちろん、彼らが共謀すれば、それは問題です]。 FEのサブクラスはABE（Attribute Based Encryption）です。 ABEは最初に形式化され、その後FEに一般化されました。 ABEでは、人によって情報へのアクセスレベルが異なります。暗号化された情報は公開されています。ただし、各人が解読できる情報は、保持しているキーによって異なります。したがって、完全な製品発売では、エンジニアリングが図面のみを見ることができるようにキーを発行することができ、販売は最終製品の芸術的な表現だけを見ることができ、提供する機能の説明を見ることができ、管理者はすべてを見ることができます。この不自然な例をこちらでご覧ください- http://www.cs.uiuc.edu/class/fa07/cs498mmp/presentations/john.pdf ABEの最大の利点は、キーの配布と管理が容易になることです現在の公開鍵インフラストラクチャと比較して。
FHEとFEの両方の非常に優れたわずかな数学的導入がここにあります http://outsourcedbits.org/2013/10/06/how-to-search-on-encrypted-data-part-1/ そしてここに http://outsourcedbits.org/2012/06/26/applying-fully-homomorphic-encryption-part-1/
FEとFHEの関係については、こちらをご覧ください https://www.usukita.org/sites/default/files/func_enc.pdf
ただし、FEの問題は、いくつかの機能に対してのみ実装可能であったことです。一般的または任意の機能には実装できません。ここで、識別不能難読化（IO）が登場します。上記の著者は、IOの定義について正しくありません。
区別が困難な難読化
元の論文によると（ http://www.wisdom.weizmann.ac.il/~oded/PS/obf4.pdf ）同じ機能の2つの実装があるとしますF（ブール回路）つまり、F1とF2。 F1とF2の難読化を前提として、IOは、F1の難読化とF2の難読化（どちらが難読化か）を区別することが不可能な場合（成功の可能性が無視できる場合）に達成されます。 F1を難読化した結果であり、どの難読化がF2を難読化した結果です）。
上記のようにIO IOの唯一の使用は、これまでのところ、あらゆる関数の完全な一般的なFEを達成するための足がかりとして使用されていることです。完全なFEはここで最初に達成- https://eprint.iacr.org/2013/451.pdf「IOプログラムを難読化します "。
結論をまとめる
これまでのところ、これらの開発はすべて、実用的な観点からはある程度、概念的には特に、特にコードとアルゴリズムの保護に関してはあまり効果がないようです（現在十分に保護されているデータとは対照的です。データの侵害は主に計算に使用されるコード）。これらを実装するために必要な膨大なコンピューティングリソースは別として、強力な敵を阻止することを困難にする上記のプロトコルには、依然としてさまざまなセキュリティリークがあります。 http://outsourcedbits.org/2013/10/30/how-to-search-on-encrypted-data-part-3/ および http://windowsontheory.orgを参照してください。/2014/01/14/progress-and-challenges-in-code-obfuscation-part-ii / コード保護における最先端のセキュリティは、おそらくここで説明されているものです http：// outsourcedbits .org/2013/12/20/how-to-search-on-encrypted-data-part-4-oblivious-rams /