アルゴリズムではなく、なぜ鍵を秘密にしておくのですか？
暗号化に関する情報を一般的に関連付けているほとんどすべてのWebサイトには、ほとんどすべての暗号化/復号化アルゴリズムがキーを入力の1つとして使用する必要があるという共通の概念があります。この背後にある理由は、キーを使用しない暗号化アルゴリズムは技術的に役に立たないためです。
そのため、どうして彼らがその結論に至ったのか疑問に思わずにはいられません。暗号化の一般的な傾向は、セキュリティキーを秘密にして、暗号化および復号化アルゴリズムを公開できるようにすることです。暗号化アルゴリズムと復号化アルゴリズムの両方が秘密である場合はどうなりますか？その場合、鍵は不要になり、非常に簡単になります。
たとえば、あるコンピュータから別のコンピュータにテキストメッセージを送信（および返信）して、通信（簡単なチャットアプリ）を許可したいソフトウェア開発者であるとします。コンピュータがTCP/IPプロトコルを使用した安全でないネットワークを介して相互に通信しているとします。会話のプライバシーを確保し、プレーンテキストの各文字の各ASCIIコードに10を追加してから、生のバイトとして送信するという非常に基本的な「暗号化」アルゴリズムを考えたいとしましょう。ネットワーク。 「こんにちは！」などのメッセージとして攻撃者は「Rovvy6 * l | y〜ro | +」として傍受します。
暗号化アルゴリズムまたは復号化アルゴリズムのいずれかを知らない場合、メッセージを傍受して元のプレーンテキストを再構築するにはどうすればよいですか？この暗号システムを解読する最善の方法は何でしょうか？鍵を使用しない暗号化スキームを破るのは本当に簡単で、実行可能なソリューションではないのですか？
最後に、「まあ……平文の各バイトに10を足しているだけだと理解するのに天才は必要ない」というようなことを言いたいのであれば、簡単にするためにそうしました。メッセージをさらに暗号化したい場合は、数式がはるかに複雑になることを自由に想像してください（たとえば、7を加算し、10を減算し、2を乗算します）。
私たちは秘密を求めているのではありません。 数量化可能機密性が必要です。重要なのは、データの機密性を確保することだけでなく、実際にデータの機密性が確保されたことを知ることができるということです。
公開アルゴリズムと秘密鍵があれば、秘密性を定量化できます。たとえば、128ビットキーで [〜＃〜] aes [〜＃〜] を使用した場合、攻撃者は平均2を試行する必要があることがわかります。127 正しいキーを見つけるための可能なキー（つまり、実際にそれを行うには多すぎる）。
代わりに秘密のアルゴリズムを使用しようとすると、3つの大きな課題に直面します。
@Xanderが説明するように、secure暗号化アルゴリズムを作成することは非常に困難です。ある程度の信頼性を提供する唯一の既知の方法は、パブリックデザインです。アルゴリズムを公開し、何百人もの暗号技術者を解き放ち、何か問題があるかどうかを確認します。 2、3年経っても、アルゴリズムに問題が見つからなかった場合、おそらく弱すぎません。シークレットアルゴリズムを使用すると、クロスレビュー作業をすべて自分で行う必要があります。これは、適切な時間では実行できません。
「まともな暗号化アルゴリズム」がいくつ存在できるかはわかりません。攻撃者は可能なアルゴリズムを列挙しようとする可能性があり、「可能性がある」とは「設計者が思いついたかもしれないもの」を意味します。問題の一部は心理学の領域にあるので、定量化は難しいでしょう。
シークレットアルゴリズムは、一部のコンピューターではソースコードとして、他のコンピューターではコンパイル済みバイナリとして、少なくとも1人のデザイナーの頭にまだ存在しています。関係するすべての開発コンピューターとデザイナーの死体が大きな酸の大釜に溶けていなければ、その「秘密のアルゴリズム」がどこにでも漏れることを防ぐのは非常に困難です。一方、秘密鍵は、より効率的に管理して秘密に保つことができる小さな要素です（RAMにのみ格納され、おそらく Diffie-ヘルマン ...）。
アルゴリズムはおそらく漏洩するので、それを公開し、鍵の機密性のみに依存することも考えられます。アルゴリズムを実際に公開することで、他のユーザーによる詳細なレビューの恩恵を受けることができます。これは、セキュリティを実現するためのほぼ避けられない前提条件です。
考慮すべき点がいくつかあります。
まず、安全な暗号化アルゴリズムを考案することは困難です。それほど難しいことではありませんが、暗号化アルゴリズムが実際に安全であることを実際に証明することはできませんが、2未満の労力でそれらを解く方法がわからないことを示すだけで、本当に心が折れるほど難しいです。 nの値が大きい場合は^ n。そのため、アルゴリズムに致命的な欠陥がないことを合理的に確認する唯一の方法（そして、アマチュアによって設計されたほとんどすべてのアルゴリズム、および専門家によって設計されたアルゴリズムのすべてにある）は、資格のある人々による厳密なピアレビューを受けることです。したがって、アルゴリズムが吟味されたとしても、定義上、秘密にすることはできません。一方、審査されていない場合、妥当な手段で安全であると見なすことはできません。
第二に、長期的な秘密の実際的な問題があります。秘密性のアルゴリズムのみに依存していた場合、アルゴリズムが発見された場合にアルゴリズムを変更する必要が生じるリスクがあります。これは困難であり、アルゴリズムのすべての実装を変更する必要があり、コストが高く、破壊的です。鍵が唯一の秘密である場合、鍵は安価で簡単に変更できるため、鍵ベースのスキームははるかに魅力的です。
最終的に、現代の暗号化は Kerckhoffsの原則 に基づいています。これは、次のように述べています：暗号システムは、キー以外のシステムに関するすべてが公開されている場合でも安全である必要があります。これは、私たちが持っている知識があれば、これが、真剣で安全な暗号システム設計に取り組むための実際に唯一の合理的な方法だからです。
学問的ではない答え：
あなたがある国の政府だと想像してみてください。あなたがこの素晴らしい新しい暗号アルゴリズムを設計するために人々を雇い、それを実装するマシンを構築するために人々を雇い、そしてあなたがすべての船と飛行機とモバイルコマンドセンターと大使館とオフィスを装備したと想像してください。 。 それと。
そして、あなたの敵が機械の1つを捕獲するか、またはあなたの敵が機械を作った人の1人を回すか、または...
どちらが簡単ですか？新しいアルゴリズムを設計し、新しいマシンを設計し、それらすべてを置き換えますか？またはキーを変更しますか？
DESのようなものをアルゴリズムとしてではなく、56ビットを指定すると、2 ^ 56暗号化アルゴリズムの1つを生成するアルゴリズムジェネレーターとして考えることが役立ちます。はほぼ同じくらい強力です。AESなどの新しいスキームでは2 ^ 128以上のアルゴリズムを生成できますが、これらはすべて強力です。安全な暗号化アルゴリズムを最初から設計することは非常に困難です。安全なアルゴリズムを採用して、それを「アルゴリズムジェネレータ」に変換することができます。比較すると、非常に多くの安全なアルゴリズムを生成する方がはるかに簡単です。何千ドル以上ものコストで暗号化アルゴリズムをゼロから設計する専門家を雇うか、いくつかのサイコロを投げて結果を使用するかを選択できます他の「アルゴリズムジェネレーター」の「キー」として、後者は暗号化のほとんどのユーザーにとって非常に簡単でより優れているだけでなく、機密性をもって部外者を信頼する必要もありません。結果を使用して生成します自分が使用するために秘密情報を保護するために使用されるキー。誰も自分の秘密を解読できるようにしたくない場合は、他の人や個人のグループに十分な知識を持たせる必要はありません。そう。
さて、想像できるアルゴリズムはいくつありますか？キーを使用する場合は、キーが異なることに依存してはならないことに注意してください。
攻撃する方法を共有していない人はどれくらいいますか？例えば。 replace x with x+10とreplace x with k[d]はどちらも、文字頻度攻撃に対して脆弱です。
123456およびpasswordに相当しないものはいくつありますか。つまり、チェックする上位のアルゴリズムのリストに含まれませんか？
誰かがすべてをチェックするのが遅すぎるのに十分ですか？
あなたが提案したスキームは、基本的な置換を使用しています。マッピングは複雑ですが（7-10）* 2 = -6です。したがって、暗号文で周波数分析を使用すると、平文が提供されます。現時点では、使用している文字列は分析には短すぎますが、時間が経つと、同じスキームを使用したデータのサーフェストにより、平文を取得する手段が提供されます。
このパスに沿って、暗号文の頻度分布を混乱させるために、関数が12文字ごとや18文字ごとなどに変更された場合に暗号文がどのように生成されるかを検討することができます。最終的には、第二次世界大戦中に使用されたEnigma enc /デコーダーに遭遇します。そしてそのすぐ後、diffie helmanを使用して公開鍵で共有鍵を安全に交渉します。 DHは、インターネット上で公開鍵の交渉を処理するための基礎です。エニグママシンを初期化するために使用されるキーは、最初に誰かがキーを送信する必要があるため、かなり興味深い開発です。戦いのなかでやるにはトリッキーなこと。これで、鶏と卵の問題は解決しました。
認証局だけが第2層のCAの数を把握できる場合は、すべてが優れています。