web-dev-qa-db-ja.com

openssl aes-256-cbc暗号化はオフサイトバックアップに安全ですか

私は約20000ファイル（約9GB）を持っていますが、それぞれのファイルはopenssl enc -aes-256-cbc -in infile -out outfile -k mypasswordコマンドを使用して暗号化されています。各ファイルは同じパスワードを使用します。私のopensslバージョンは1.1.0eです。

これらのファイルをオフサイトの場所にバックアップすると、既知の攻撃に対して脆弱になりますか？そうでない場合、私の選択肢は何ですか？

opensslaesbackup
9
yasar

OpenSSLのコマンドラインユーティリティを汎用の暗号化に使用しないでください。実際には、ライブラリの内部暗号化ルーチンのテストとしてのみ設計されています。このため、実際の機密性と整合性が必要な場合に使用すると、いくつかの固有の問題があります。

  • CBCモードは認証されていないため、 malleability attack に対して脆弱です。これにより、暗号化キーを知らなくても、特定の予測可能な方法でファイルを変更できます。
  • 整合性チェックが行われないと、破損した意味不明なメッセージが出力されても、間違ったキーでの復号化は成功します。ファイル暗号化用に設計されたユーティリティ設計は、キーが間違っているかどうかを通知します。
  • マスターキーの導出に使用される デフォルトハッシュ はMD5であり、理想とはかけ離れています。たとえば-md sha512を使用してハッシュを変更することは可能ですが、それでもキーストレッチは使用されません。
  • 新しいバージョンでは、以前に暗号化されたファイルをデフォルトで復号化できない場合があります。デフォルトのハッシュ値がMD5からSHA-512に変更された場合、再び機能するには明示的な-md md5が必要でした。
  • キーとIVは両方とも、入力パスワードから導出されます。同じパスワードを使用して複数のファイルを暗号化すると、IVが再利用されます。これは、CBCモードでは良くなく、CTRモードでは致命的です。
  • 十分にテストされていません。 OpenSSLの多くのバージョンでは、GCMモードの暗号化を使用したencは機能しましたが、復号化は機能しませんでした。これはまだ事実かもしれません。

これはencコマンドに固有のものではありません。 OpenSSLコマンドラインユーティリティには、ライブラリのテスト以外の目的でOpenSSLコマンドラインユーティリティを使用しようとすると、別の問題があります。別の例は、SSLまたはTLSを介してサーバーに接続するために使用されるs_clientコマンドです。これは、ターゲットの証明書を検証しません。全体として、OpenSSLユーティリティは使用しないでください。 GnuPGを使用するだけです。

OpenSSLを直接使用するのは、完全にランダムなキーまたは特定の未加工のキーとIVを使用して何かを暗号化する必要があり、メッセージの整合性を気にしなかった場合のみです。たとえば、カーネルによってシードされた疑似ランダムストリームをstdoutに書き込むには、次のようにします。

openssl aes-128-ctr -nosalt -k $(xxd -l16 -c16 -ps /dev/urandom) -in /dev/zero

同様に、生の鍵と生のIVの両方が16進数でわかっている場合（暗号鍵の導出に-mdの必要性を省略）、プレーンな暗号化データのblobを復号化するには、次のようにします。

openssl aes-128-cbc -d -nosalt -K $hex_key -iv $hex_iv -in infile -out outfile

しかし、汎用のファイル暗号化についてはどうでしょうか。 GnuPGを使用するだけです。

13
forest