隠蔽によるセキュリティが暗号化に適さないのはなぜですか？
簡単な説明があるに違いないと思いますが、周りを見回しても、正解は見つかりませんでした。
たとえば、私の名前はアリスと私の親友のボブであり、私たちは安全に通信したいと考えています。
テキストを受け取り、それを数十のフィルターで覆い隠して、プロセスを正常に逆転させることができるプログラムを書いた場合、私が紙にプログラムを書いて、ボブに私の紙を砂漠の真ん中に渡して彼がそれを記憶したと仮定しますそしてそれを燃やしたなら、誰がどうやって私たちのコードをクラックすることができるでしょうか？
あいまいさについて詳しく説明するために、たとえば次のようにします。
- 元の文字列をバイナリに変換します
- そこから、年の最後の桁を各数値に追加します
- 次に、テキストを逆にしました
- 次に、3文字ごとにランダムに生成された文字を追加しました
- 以下同様に、私が数十の不明瞭さを除去するまで繰り返しました。
プログラムや数式なしで（または少なくとも数年間）メッセージを解読するのが多かれ少なかれ不可能ではないのはなぜですか。
サイドノート：「私は奇妙なOSを使うだけで誰が奇妙なOSを理解しているので安全だ！」と言っている人々にとって、あいまいさによるセキュリティが機能しない理由を完全に理解します。暗号化されたメッセージを送受信することについて純粋に質問します。第三者によって傍受された場合、そのあいまいさのために現実的にクラックすることはできません。
短いメッセージを1つ（1つまたは2つ）送信するだけの場合、改ざんするのは困難です。ただし、大きなメッセージまたは頻繁なメッセージの送信を開始すると、言語文字の頻度などの手法を使用して簡単に破ることができるでしょう。
たとえば、多くの単純な暗号化技術では、「a」は常に同じ暗号化された文字に変換されます。その結果、十分なテキストがあれば、頻度に基づいてどの文字がどの文字であるかを簡単に判別できます。
テキストを暗号化した式について何も知らなくてもそれを行うことができます。文字の頻度を隠しているように見える暗号でさえ、それを公開することができます（たとえば this one を参照）。コンピュータを使用すると、文字の頻度の評価を自動化して非常に迅速に行うことができます。
コードを壊す方法は他にもあります。文字の頻度は、理解しやすい例にすぎません。
あいまいさを介してセキュリティに依存することが嫌われるのは、アルゴリズムが漏洩または破壊されると、あいまいさによって得られたすべてのセキュリティが完全に失われてしまうためです。したがって、アルゴリズムにアクセスできるアクターが組織を離れたり、ハッキングされたり、暗号化/復号化プログラムのソースコード（または実行可能ファイル）が何らかの形で漏えいしたり盗まれたりした場合、すべてのセキュリティが完全に失われます。アルゴリズムは不明瞭です。
あいまいさを介してセキュリティを回復するには、まったく新しい暗号化アルゴリズムを考え出し、暗号化の専門家に新しいアルゴリズムを安全に分析させ、通信する必要のあるすべての関係者とアルゴリズムを密かに交換する必要があります。
一方、よく吟味された標準の暗号化アルゴリズムを使用している間は、アルゴリズム（たとえば、誰かが盗んだとしても構わない）を、ブルートフォース（たとえば、256ビット対称のブルートフォース）に計算上実行できないキーから分離します。地球上のすべての陽子/中性子（すべての10 ^ 51）が1秒あたり10億個のキーを試行した場合、100万年の総当たり攻撃では、1000分の1の確率で破壊されます。
秘密にしておく必要があるのはキーだけです。攻撃によって鍵を紛失したり、新しいパーティーでメッセージを安全に送信したりする必要がある場合、まったく新しいアルゴリズムを発明する必要はありません。新しいキーを生成するだけです。
十分に吟味された公開アルゴリズムを使用すると、だれでも一緒にそれを分析して、深刻な脆弱性があるかどうかを確認できます。これは、実装者が考えるよりもはるかに弱いプライベートアルゴリズムでは実行できません。 （たとえば、ダニエルが述べたように、あなたが説明したアルゴリズムは、文字頻度分析、テキストのピリオド分析、基礎となる平文のパターンの悪用など、多くの標準的な攻撃に対して脆弱です。）
さらに、シークレットアルゴリズムを使用することは、ユーザビリティの観点からかなり困難です。他のすべてのユーザーとのやり取りのたびに、ユーザーが覚えておかなければならないことは他にもたくさんあります。 5年前に暗号化したファイルを見つけた場合、または誰かがファイルを送信した場合、キー/パスワードをまだ持っていても、CBCモードのAES256で暗号化されていることがわかっていれば、ファイルメタとして-その情報を示すデータと、この特定の個人で使用していた可能性のある秘密のカスタム暗号化アルゴリズムの種類を思い出そうとするのではありません。ユーザーがさまざまなプラットフォームで作業している場合、カスタムシークレット暗号化アルゴリズムをすべてのプラットフォームで完全に機能させるのは面倒になります。
この質問 、特に この質問 をご覧ください。あなたの質問は私の質問とほとんど同じです。トーマスポルノは、これまでと同じようにこの質問に最良の答えを出しました。読んでみてください。ここに抜粋があります：
「あいまいさによるセキュリティ」は、秘密性ではなく、あいまいさという用語を使用する表現です。 暗号化とは、機密性を通じてセキュリティを実現することです。それが全体の違いです。パスワードは秘密にすることができます。アルゴリズムは、せいぜいobscureです。隠喩は、比喩的なランタンを持参することを考えているとすぐに払いのけられます。秘密は鋼の金庫のようなものです。それを突破するには、より強力なツールが必要です。
キーの使用または秘密アルゴリズムの使用は同じです。繰り返しますが、よく知られている暗号アルゴリズムで鍵を使用することも、発明の特別な巧妙なアルゴリズムを使用することも同じです。両方の方法で、生の情報のビットで測定できる 共有秘密 があります。
すべての暗号化方式は「obscurity」に基づいており、基本的には 共有シークレット の保護です。基本的に、それは shared-secret を秘密に保つことです。キーの秘密性は、そのランダム性（そのエントロピー）に相関しています。ランダムでないほど、私はあなたの秘密の一部を推測することができます。これらの推測された部分はもはや秘密ではないため、shared-secretは生の情報のビットであると言えます。
そして、あなたはあなたが長いを持っているなら壊れない方法を考案することができるという意味で完全に正しいです事前共有秘密。
ただし、アルゴリズムについてあまり複雑にする必要はありません。標準のキー付き暗号化を使用していて、キーが十分に長い場合（たとえば、メッセージよりも長い場合）、保護が完全であることを理解するのは非常に簡単です。覚え書きとして：メッセージより長い真にランダムなキーを持つ単純な XOR暗号 は解読できません。ただし、次のことを忘れないでください。十分な長さの 事前共有 シークレット（および通信ごとに新しいシークレット）が必要です。
それで、問題はどこにありますか？なぜこれを行わないのですか？ あなたの共有秘密はそれを使うたびに使い古されるからです。そして、あなたは最終的にそれを使い果たすでしょう。キーを使用すると、その微妙な部分が失われます。たとえば、アルゴリズムを生成するものを見ると、微妙なヒントが得られます。アルゴリズムからの出力が多いほど、より多くのパターンが認識されます。
したがって、ほとんどの実際的なケースでは、アリスとボブが最初に秘密を共有しないところから始めたいと思います、または少なくともこの秘密は、彼らの通信をカバーするのに十分な長さではありません。あなたの場合、秘密はアルゴリズムであり、標準の場合、それはしばしば鍵であり、これをshared secretと呼ぶことに注意してください。
したがって、標準の暗号化の場合、懸念は（さらに）共有シークレットを作成する方向にシフトします。したがって、ほとんどの労力は、keyを作成する方法を見つけるために費やされ、ボブとアリスが理論と標準の解読不可能な暗号によって保護されるようになります。十分に長い秘密。
今日のほとんどの暗号通信はこのように機能します：共有キーをオンザフライで（多くの場合、継続的な通信では定期的な間隔で）作成してから、任意の簡単な方法を使用しますしかし、この鍵を使用した完全な暗号化アルゴリズム（XOR 1つなど）） Diffie Hellman は、これらのアルゴリズムの1つです。通常、最初の部分は最も複雑で、コンピュータの電力を大量に消費する可能性があり、2つ目は簡単です。
したがって、難しいのは、データを暗号化するのに十分な共有シークレットを用意する（または生成する）ことです。
Imoが安全であることと、あなたが安全であることを証明できることは、2つの異なることです。理想的には、検査のためにすべてをテーブルに配置できるようにしたいです。
これには、障害点とシステムに存在する秘密、およびそれらの秘密がどのように保護されているかを特定することが含まれます。
インフラストラクチャシークレットの場合、アプリケーションはキーフレーズを使用してリソースにアクセスすることができ、これらのキーはDMZファイアウォール内で保護され、マシンキーで暗号化されます。そして、それと監査人と彼らが満足していることを証明できます。
ユーザーアクセスの場合、その秘密はユーザーだけが知っているという考え方であり、他のパスワードのベストプラクティスの中でも特に、秘密を導き出せる方法でどこにも保存していないことを監査人に証明できます。審査員に、彼らは幸せです。
あいまいさは何かを隠しているときであり、これはキーとパスワードを秘密にしておくこととは異なります。システムまたはアルゴリズムの動作を隠しています。
あいまいさが悪いとは思わない。それはおそらくほとんどの企業にとって悪い選択だと思います。これは必要ではなく、ビジネス全体で複雑化を引き起こす可能性があります。