セキュリティによるあいまいさは恐ろしいです。セキュリティとあいまいさは良いですか？
通常、私は独自のカスタム暗号アルゴリズムをローリングすることは悪い考えだと説いています。しかし、それが最も外側の層である場合、それは本当に傷つくでしょうか？それともセキュリティを悪化させますか？
AES -> CipherText -> CustomEncryptionAlgorithm-> CipherText
追加のレイヤーが役立つと思います。たとえば、CustomEncryptionAlgorithmがバグに埋もれた混乱状態であっても、事態を悪化させることはありません。これは、AES出力がすでにランダムノイズと区別できないためです。
一方、次の点に問題があることがわかりました
CustomEncryptionAlgorithm -> CipherText -> AES -> CipherText
悪いですか？なぜ？
セキュリティとあいまいさなどに費やされた企業リソースについてはコメントしないでください（セキュリティが先に出てくることに同意します）このアプローチの脆弱性の背後にある暗号理論を理解することにもっと興味があります。
自分の暗号をロールバックしないでください！
純粋に暗号化の観点から見ると、長さを維持する全単射関数はセキュリティを低下させることはできません。実際、f（x）= xとして定義される 恒等関数 であっても、キーを想定してセキュリティを低下させません標準暗号に使用され、自作の暗号は相互に独立しています。セキュリティを低下させる可能性のある唯一の方法は、homebrew関数が別の独立したキーを使用せず、暗号文でキーをリークする場合です。たとえば、 fk（x）= x⊕k入力の個々のブロックxで行われ、クラシックXOR既知の平文攻撃に対して脆弱な暗号。
実用的な観点から、重要な問題があります。上記で長さを維持することについては、正当な理由で説明しました。圧縮関数は依然として関数であり、圧縮と暗号化によって 非常に悪い結果 が発生する場合があります。これが、標準暗号化の前にカスタムアルゴリズムを適用した2番目の例が実際に悪い理由の1つです。これは、プレーンテキストに関する情報を長さを通じて漏らす可能性があります。実装にバグがあり、他のセキュリティの脆弱性が発生する場合もあります。純粋に理論的な観点から、それらは範囲外です。
私はこれがどれほどひどい考えなのかを十分に強調していないかもしれないとコメントで指摘されました。理論的には問題ないかもしれませんが、現実の世界は異なった働きをします。実際に独自の自作暗号を使用することは非常に悪い考えです。実際にこれを行う必要があるのは、プロの暗号技術者である場合のみです。バーンスタインはこれを行うことができます。 Rivestはこれを行うことができます。ライメンはこれを行うことができます。それはいけません。足元を撃たずに、適切なアルゴリズムを使用してください。
最初にカスタム暗号化アルゴリズムを適用すると、リスクが伴います。
これは、AESのような暗号化がプレーンテキストのlengthに関する情報をリークするという事実に基づいています。
カスタムアルゴリズムが0x40のような1バイトの平文を64個のゼロに、0x02 0x00のような2バイトの平文を512個のゼロに「暗号化」する非常に架空の（そして非現実的な）例を考えてみます。
AESを使用してこれを暗号化しても、攻撃者はAES暗号化テキストの長さを調べるだけで、カスタム暗号化結果の長さを知ることができます。
この情報を使用すると、攻撃者はAES暗号化キーがなくても、これを元の平文に「復号」できます。
要約すると、非常に悪いカスタムアルゴリズムは、実際に次のAES暗号化のセキュリティを損なう可能性があります。
あらゆる種類のセキュリティシステムを評価するときに最初に尋ねる質問は、「攻撃者はだれで、何ができるのか」です。ローエンドでは、メッセージの1つの暗号化された出力を見るだけの攻撃者には反対です。ハイエンドでは、攻撃者に対して プレーンテキストと暗号化テキストのペアで他の数百のメッセージを知っている 、 同じキーで他のメッセージを暗号化するように強要することができる =、 建物への電力線を監視し、暗号化プロセスの進行に伴う電力消費の小さな変動を測定できる人 、およびあらゆる種類の同様の攻撃。標準の暗号化アルゴリズムは、これらの強力な敵に対しても耐性があることを確認するために精査されています。
最初に独自の暗号化を使用すると、2番目のレイヤーが軍事グレードの暗号化であっても、標準の暗号化だけを使用する場合と比較してセキュリティが低下するリスクがあります。
たとえば、テキストを暗号化するとします。最初に単純な 置換暗号 を使用し、次に、選択した強打アルゴリズムを使用します。残念ながら、置換暗号は本質的に、個人情報（つまり、平文と鍵）から配列を検索することに依存しています。これにより、タイミング攻撃に対して脆弱になります。プレーンテキストの2つの文字が近接している場合のCPUキャッシュの動作方法により、より平凡な2つの文字よりも高速に暗号化される可能性があります。それは多くの情報のようには聞こえませんが、攻撃者が十分な暗号化を監視できれば、AESをクラックしたりせずに平文が何であるかを潜在的に解明できます上で使用しているものは何でも。
カスタム暗号化レイヤーが秘密情報とまったくやり取りしない場合、つまり、送信のために十分に安全に暗号化されており、標準暗号化のキーに触れていないデータで機能する場合は、安全である可能性があります。少なくとも、標準の暗号化をバイパスすることはできません。ただし、追加のソフトウェアはすべて追加のリスクを伴うため、リスクは依然として存在します。おそらく、カスタムレイヤーのバグが原因で、リモートの攻撃者がマシン上で任意のコマンドを実行できます。その後、プレーンテキストを自分にメールで送信できます。
したがって、持ち帰りメッセージは、標準の暗号化機能のように十分に吟味され、バグのない優れたセキュリティコードを1つまとめても、バグのある自社開発のプログラム（何らかの種類、暗号化など）を置くとなお損なわれる可能性があるということです。同じシステム。
シンプル。 これを行わないでください。
まず、暗号化アルゴリズムは、あなた、私、そして私たちの周りの誰もがそれを見て、解読しようとするように設計されています。 [〜＃〜] aes [〜＃〜] の数学を文字通りかなり見ることができます。多くの賢い人々がAESの検証に時間を費やしています。これは優れた暗号化の信条であり、信頼できる理由です。
第二に、隠蔽は決して「セキュリティ」オプションではありません。メリットはありません。あなたがこれを実際に信じているなら、私はあなたに "Schneier's Law" を参照させます。
誰もが自分で破ることができないセキュリティシステムを発明できます。私はこれを頻繁に言ったので、Cory Doctorowはそれを「シュナイアーの法則」と名付けました。誰かがあなたにセキュリティシステムを手渡して、「これは安全だと思います」と言うとき、あなたが最初に尋ねなければならないことは、「一体誰なんだ？君は？"システムのセキュリティに対するあなたの主張が何かを意味していることを示すために、あなたが何を破ったのかを見せてください。 -ブルース・シュナイアー、2016
あなたがしたことはすべて：
- アプリケーションに不要なリスクを導入する
- 問題のデバッグ時間の増加
- 価値のない機能にCPU時間を追加
セキュリティの最も基本的な原則。シンプルなバカにしてください（KISS）。
信頼性に依存するセキュリティの唯一のレイヤーではない限り、あいまいさによるセキュリティは、場合によってはgreatであってもよいです。しかし、あなたの場合、それは価値がないと思います。
例としてGPGを取り上げます。 GPGを使用してAESでファイルを暗号化すると、ヘッダーに攻撃者がAESで暗号化されたGPGファイルとして認識できるようになります。その後、カスタム暗号化を使用してGPGファイルを暗号化すると、認識できない可能性のあるファイルを取得します。攻撃者は、あなたが何らかの暗号化を使用していると誤って想定し（そして何もしないために多くの時間を失う）、またはカスタム暗号化を使用していると想定し、暗号解析手法を使用してファイルを分析することを決定します（そして、彼は十分であるか、あなたのアルゴリズムは十分です）。一方、逆の方法（最初にカスタムアルゴリズムで暗号化し、次にAESで暗号化する）で行う場合、結局シナリオは大幅に変更されません。
とはいえ、カスタム暗号化には巨大なconとにかくあるので、価値がないと思います。暗号化ソフトウェアをどこかに保存する必要があり、ソフトウェアは完全にカスタム化されているため、紛失した理由（バックアップの紛失や盗難など）はねじ込まれ、データを回復できなくなります。
より良い解決策は、すでに知られていて利用可能なアルゴリズムを使用して暗号化のいくつかの層を使用することかもしれません。たとえば、GPGはtwofishや椿などをサポートしているようです。AESを除いて、どのアルゴリズムが最も安全であると考えられるべきかを知る経験はありません。とにかく、例として、AES-> TWOFISH-> CAMELLIAは、おそらくAES-> CUSTOM_ALGOよりもはるかに優れたソリューションです。もちろん、暗号化レイヤーごとに異なる強力なパスワードを使用する場合は、
OPSEC？...
重要な情報と敵対者との間に追加の障壁を設けることは、一般的には良い考えです効果的に行われる場合。
意味のあるセキュリティ対策としての不明瞭さは、OPSEC（運用セキュリティ）の原則によって対処されます。要するに、これには、社会的または技術的な方法のいずれかを介して組織を危険にさらすのに役立つ可能性がある情報の敵から奪うことが必要です。
ただし、優れた暗号化では、キーを秘密にしておけばデータを保護できます。 追加の技術レイヤーは、独自の技術的メリットに基づいて正当化する必要があります。
...またはバスト
暗号化は非常に複雑な数学の分野であり、小さな間違いは大きな結果をもたらす可能性があります。 暗号化を扱う場合、信頼できる専門家が別の方法で指示しない限り、アルゴリズムの値は実質的にゼロであると想定します。
米国では、NSAとNISTがそれぞれ暗号アルゴリズムと実装の公式評価者です。意見を探す場所がわからない場合や、内部ポリシーの合理的な根拠が必要な場合は、そこ。
実際には、適切な暗号をラップしても意味がありません。攻撃者が適切な暗号に遭遇すると、通常、暗号化されていないデータが公開されているエンドポイントをピボットして攻撃します。
これは、ユーザーが情報を提供するWebサーバー、データベースにフィードするSCADAシステム、または従業員が情報を分析または監視するワークステーションです。データベースから情報を引き出し、それを別のフォーマットに変換してベンダー/顧客に配信するデータポンプがある場合、それは別の大きな目標です。あるいは、あなたの鍵を探しに行くこともできます。
バランスについて
アプリケーションに機能を追加すると、バグが発生してトラブルシューティングが複雑になる可能性がゼロではありません。これは、何かがうまくいかなかったり、アプリケーションのセキュリティの脆弱性への対応が遅くなった場合に、ダウンタイムが長くなる原因となります。 これらの要因により、ほとんどまたはまったく価値のないセキュリティ機能は、改善というよりむしろ不利益です。
AESに対する潜在的な攻撃から身を守りたい場合は、独自のアルゴリズムを開発するのではなく、吟味されたアルゴリズムに基づく別の暗号規格を使用する必要があります。 少ない労力でより良いセキュリティが得られます。
セキュリティモードと不明瞭モードには、主に2つの問題があります。
あいまいな場合、セキュリティが妨げられる可能性があります。自分の暗号をロールすると、欠陥が生じる可能性が非常に高くなります。主要な専門家が何十年もの間それらに取り組んできたにもかかわらず、最高のシステムでさえ欠陥があります。セキュリティコミュニティよりも上手くできる可能性は低いです。
本当にあいまいなものはほとんどありません。クリプトには多くの新しいアイデアはありませんし、あなたが行うことは以前に行われた何かのバリエーションである可能性が高いので、実際にはそれほどあいまいではありません。小さな変更は、攻撃者が処理に慣れているものです。
最初のバリアント（カスタムアルゴリズムが最後）は、既知の暗号化のセキュリティを危険にさらすことはできません。これは、可能であれば、既知の暗号化を解読するための方法となるためです。結局のところ、攻撃者は、既知の暗号化だけで暗号化された暗号文に対してカスタムアルゴリズムを実行して、クラッキングに役立てることもできます。
他の方向（最初にカスタムアルゴリズム）は、既知の暗号化のプレーンテキスト入力に冗長性を導入することにより、既知のアルゴリズムのセキュリティを実際に損なう可能性があり、そのアルゴリズムを弱める可能性があります。
たとえば、次の完全に欠陥のあるカスタムの「暗号化」スキームを考えてみましょう。入力平文を2回繰り返して「暗号文」を生成します。これにより、2番目のアルゴリズムの入力に極端な量の冗長性が追加され、実際の暗号化を弱める可能性があります。 （それがAESを弱めるかどうかは別の問題です。）これは実際には Enigma で起こり、演算子は平文で3文字のシーケンスを繰り返しましたこれにより、その暗号文は特定の種類の攻撃に対して脆弱になります。 Enigma Wikipediaページの Cryptanalysisからの引用 ：
2番目の問題は、インジケーター内でのメッセージキーの繰り返しでした。これは深刻なセキュリティ上の欠陥でした。メッセージ設定は2回エンコードされたため、1番目と4番目、2番目と5番目、3番目と6番目の文字の間の関係が発生しました。このセキュリティ問題により、ポーランド暗号局は1932年には戦前のエニグマシステムに侵入できました。1940年5月1日、ドイツ人はメッセージキーを一度だけ暗号化するように手順を変更しました。
言われたように：攻撃者は誰ですか？
これは本当にあなたが最初に見つけて定義しなければならないことです！
テレビのリモコンに問題を抱えているのは、恐怖症の祖母ですか？あなたの小さな（そして非常にせんさく好きな）妹は？あなたのお父さんは、実際にコンピューターのプログラミングと管理を行っており、ハードドライブを取り外す方法を知っていますか？あなたを倒す地元の学校のいじめっ子？組織犯罪？クラッキング攻撃のためにクラウドコンピュータをレンタルするために数百万ドルを費やすことができる会社ですか？第三世界独裁者？ FBI、NSAまたはあなたの国の同等の代理店ですか？優れたスパイサービスがあり、ボディバッグを気にしない気のある世界の大国ですか？
第二に、あなたの「暗号化」 1 があなたの攻撃者に対してあなたに与える追加の本当のセキュリティは何ですか？暗号文の再暗号化[2]が必要である、または非常に役立つ理由を十分に説明できない限り、そうすべきではありません。複雑さが増しても、セキュリティが増すわけではありません。バグが増え、物事が適切に機能しない可能性が高くなります。
そして、攻撃者があなたの家に侵入したり侵入したりして、スパイソフトウェアやキーロガーをコンピュータに配置しないのはなぜですか？あなたの暗号化はゴムホース暗号分析[3]に対する何らかの助けになるでしょうか、それともその可能性がない場合、誰がAESを破るのに十分強力であなたやあなたの最愛の人や最寄りの人に到達することができませんか？
暗号化を強力かつ安全にする可能性が、月を歩く可能性と同じくらい高いとしましょう。暗号化では、すべてが正しいキーで機能する必要があるだけでなく、それなしでは何も機能しない可能性があります...
私は、専門家によるチェックの際にクラックされなかった、フィールド外の誰かによって構築された暗号システムについて知りません。また、最高の専門家によって発明された強力な暗号化システムがいくつ破壊されましたか？
1つの例は、ドイツから潜水艦への第二次世界大戦での通信です。一部の非常に秘密の通信は「オフィサーのみ」であり、暗号化され、メタ情報が付加され、両方が通常のキーで暗号化されて送信されました。ラジオ/エニグマオペレーターを受信すると、メッセージを復号化し、メタ情報と暗号化されたブロックを警官に渡します。 （ 例はこちらをご覧ください ）
「暗号システムへの鍵が発見されるまで、ゴム製のホースが足の裏に力強く頻繁に適用されます。このプロセスは、驚くほど短時間で実行でき、計算コストが非常に安価です。」
ソリューション1では、AESとCustomEncryptionAlgorithmの暗号化に同じ秘密鍵を使用すると、セキュリティが低下する可能性があります。
CustomEncryptionAlgorithmは、秘密鍵の推定を可能にする可能性があり、そのためAESも危険にさらされます。
CustomEncryptionAlgorithmの一意のキーを作成した場合は、再び問題ないはずです。
KEY = SHA-2（AES-CipherText）のようなもの
問題は、カスタム暗号化機能にバグがあり、どういうわけかセキュリティが低下する可能性があることです。あなたのCustomEncryptionAlgorithmがセキュリティを低下させていないことを確認する唯一の方法は、あなたよりも賢い研究者、私、そしてあなたのチームの他のメンバーを組み合わせて注ぎ込み、あなたの仕事をチェックすることです。しかし、それはまったく不明瞭ではありません。
極端な例を挙げます：
public string CustomEncryptionAlgorithm(string plaintext) {
var ciphertext = plaintext.shuffle();
return "password";
return ciphertext; // ya ya. I know. You'd never make a bug that obvious.
// tell it to the guy who did the 'goto bug' at Apple
}
このスキームを使用すると、結果として次のような結果が得られます。
AES-> CipherText-> CustomEncryptionAlgorithm-> CipherText：
'abcABC123!@#' -> 'password' 'correct_horse_staple_battery' -> 'password' 'password' -> 'password'
一方、他のスキームを使用した場合：
CustomEncryptionAlgorithm-> CipherText-> AES-> CipherText
'abcABC123!@#' -> '8ZnO44trPK48kqr3rDxkdQ==' 'correct_horse_staple_battery' -> '8ZnO44trPK48kqr3rDxkdQ==' 'password' -> '8ZnO44trPK48kqr3rDxkdQ=='
少し良いかもしれません。しかし、それでも少しでも良いことはありません。
悪い、悪い、悪い。
RSA（良質で安全、強力）と自作の組み合わせを使用した、SIMの初期化などの極東モバイルプロトコルの逸話があります。
決定的な弱点は、自作の「追加の」暗号化だけではありませんでした。しかし、問題は、追加のメソッドがRSAとのassociativeである場合に実際に特別なケースがあり、部分的なキーブリードが発生することでした。何年も前に講話の逸話として言われたので、詳細は覚えていません。
しかし要点は、他の点では安全なプロトコルに不適切な自作を追加すると、元のバージョンよりもプロトコルが弱いになる可能性があります。ですから、それは大したことではありません。
2番目のアルゴリズムは不明瞭と呼ばれているため、セキュリティが追加されないと想定しているようです。
それが実際にセキュリティを追加しない場合、なぜそれを使用するのですか？ aesの暗号化には、最初のパスワードに加えて2番目のパスワードを使用します。 2倍の長さのパスワードは、2つのパスワードよりもはるかに安全です（例：2^2+2^2 = 4対2^4 = 16）、特に2番目のアルゴリズムが安全でない場合。
短い答え：それは可能ですが、あなたの例ではできません。
長い答え：他の答えは、あなたの例がそれほど役に立たず、害を及ぼす可能性がある理由を適切にカバーしています。そうは言っても、あいまいさは非常に役立ちます。適例：SSHをポート22に配置しないでください。22から2222に変更すると、ブルートフォース攻撃のほんの一部しか行われません。ポート10000 + _Rand(1,55535)に変更すると、完全に消える可能性があります。別の例はポートノッキングです。基本的に、あいまいさは暗号化やパスワードではなく、接続プロセスで主に役立ちます。
適切に行われれば：確かに。問題は、それが適切であることをどのようにして知るのですか？確かに、さまざまなレイヤーを通じて情報を漏らす何かを書くことができます。最も明白なものは、長さと繰り返しです。また、同じキーを使用すると問題が発生する場合があります。
何が適切で何がそうでないかを判断するのは非常に困難です。確かに、AESの前にROT13を使用するとROT13が少し安全になり、私の直感では...少なくとも害はないが、実際にはわかりません。
私の直感では、長さを変えずにランダム性と区別がつかない出力を生成するアルゴリズムを適用し、次にAESを適用すると、少なくともAESのセキュリティが低下しないはずです。
不明瞭さはセキュリティ（一般）の一部であり、セキュリティ（あなたのケースではAES暗号化）と直交しています。隠蔽は、暗号化とは異なる脅威に対して防御します。たとえば、パスワードを使用します。サーバーからプレーンテキストが漏洩するのを防ぐために暗号ハッシュが必要です。TLSはネットワークトラフィックの盗聴を防ぎます。[*******]で埋められたパスワードフォームは、ランダムな見物人によるプレーンテキストのピークを防ぎます。したがって、セキュリティbyあいまいさ（のみ）を行うことはできませんが、セキュリティwithあいまいさは通常の方法です。現実の世界では、あいまいさはメタデータを隠すことを意味します。 CC/ToではなくBCCを使用してメールを送信するか、サードパーティのCookieをブロックします。