web-dev-qa-db-ja.com

リアルタイムアプリケーションでのRC4の使用

アプリケーションでストリーム暗号を使用する必要があります。多くのメッセージに同じキーを使用することは、ストリーム暗号（RC4）には適さないことを知っています。しかし、私はいつも新しいキーを作りたくないので、次のことを思いつきました。
秘密鍵を安全に作成します。次に、送信するすべてのメッセージについて、暗号化で使用する鍵は前の鍵のsha1ハッシュになります。
最初のメッセージの場合、キーはkey = sha1(key)になります
2番目のメッセージの場合、キーはkey = sha1(sha1(key))などになります。

key := makeSecureKey()
while(true){
     key := sha1hash(key);
     message := getNewMessage();
     encrypted_message := RC4.Encrypt(message, key);
     send(encrypted_message);
}

ここで暗号化は正しく使用されていますか？
最後に、sha1アルゴリズムの160ビットの結果を使用する代わりに、160ビットの最初の128のみをキーとして使用する場合、問題はありますか？

encryptionrc4
3
jfgdfhggjfhgjv

これは非常に多くの理由から悪い習慣です。

  1. RC4は日曜日以降、どの方法でも壊れています。
  2. 鍵生成アルゴリズムは自社開発であり、安全ではない可能性があります。たぶん crypto.stackexchange.com の誰かがあなたのためにそれを分析してくれるでしょう。私はそれを残して、公開された [〜＃〜] kdf [〜＃〜] を使用します。
  3. 開始キーのその後の派生を含む、RC4に対する既知の攻撃があります。これがあるかわかりません。
  4. SHAハッシュ関数は、優れたPRNGまたは優れたキージェネレーターとして設計されていません。これらはその目的ではありません。結果のハッシュ内に、暗号の使用方法を損なうアーティファクトがある可能性があります。それは鍵として、RC4はもちろんです。
  5. CBCモードの最新のブロック暗号は、ネットワークストリームがデータを処理するよりも高速であるため、これがネットワーク上を移動している場合、ストリームは必要ありませんストリーム暗号。

この Q＆A は、ストリーム暗号よりもブロック暗号を使用する必要がある理由について優れた答えを持っています。また、1つのステップで両方を実行するEAXやGCMなどのアルゴリズムよりも、プライバシー（暗号化）にはAES + CBCを、整合性保護にはHMACを優先します。私がこの立場（セキュリティ、数学的に）を守ることができるかどうかはわかりませんが、それでも、両方に対処する1つのアルゴリズムが私を悩ませています。

1
Andrew Philips