21

データ ファイルを暗号化し、パスワードで保護できる小さなデスクトップ アプリを作成しています (つまり、解読するには正しいパスワードを入力する必要があります)。暗号化されたデータ ファイルを自己完結型で移植可能にしたいので、認証をファイルに埋め込む必要があります (またはそう思います)。

私が知っていることに基づいて、実行可能で論理的に見える戦略があります (これはおそらく危険であるには十分です) が、それが実際に優れた設計であるかどうかはわかりません。だから教えてください：これはクレイジーですか？それを行うためのより良い/最良の方法はありますか?

  • ステップ 1: ユーザーは、「MyDifficultPassword」などの平文のパスワードを入力します。
  • ステップ 2: アプリはユーザー パスワードをハッシュし、その値を対称キーとして使用してデータ ファイルを暗号化/復号化します。例: "MyDifficultPassword" --> "HashedUserPwdAndKey"。
  • ステップ 3: アプリはステップ 2 のハッシュ値をハッシュし、新しい値をデータ ファイル ヘッダー (つまり、データ ファイルの暗号化されていない部分) に保存し、その値を使用してユーザーのパスワードを検証します。例: "HashedUserPwdAndKey" --> "HashedValueForAuthentication"

基本的に、Web サイトのパスワードを実装する一般的な方法 (つまり、OpenID を使用していない場合) から推測しています。これは、ユーザーのパスワードの (ソルト化された) ハッシュを DB に保存し、実際のパスワードを決して保存しないことです。 . しかし、対称暗号化キーにハッシュ化されたユーザー パスワードを使用しているため、認証に同じ値を使用することはできません。したがって、もう一度ハッシュして、基本的に別のパスワードと同じように扱い、二重にハッシュされた値をデータ ファイルに保存します。そうすれば、ファイルを別の PC に持っていき、パスワードを入力するだけで復号化できます。

では、この設計は合理的に安全なのか、それともどうしようもなくナイーブなのか、あるいはその中間なのか? ありがとう！

編集: 明確化とフォローアップの質問: ソルト。
ソルトは有用であるためには秘密にしておく必要があると思いましたが、あなたの回答とリンクはそうではないことを示唆しています. たとえば、 erickson によってリンクされたこの仕様(以下) は次のように述べています。

したがって、ここで定義されているパスワードベースの鍵導出は、パスワード、ソルト、および反復回数の関数であり、後者の 2 つの量を秘密にしておく必要はありません。

これは、ハッシュ化されたキーと同じ場所/ファイルにソルト値を保存でき、ハッシュ時にソルトをまったく使用しない場合よりも安全であることを意味しますか? それはどのように機能しますか？

もう少しコンテキスト: 暗号化されたファイルは、他のユーザーと共有したり復号化したりすることを意図したものではなく、実際にはシングル ユーザー データです。しかし、完全に制御していないコンピューター (職場など) の共有環境に展開し、ファイルをコピーするだけでデータを移行/移動できるようにしたい (自宅や別の場所で使用できるようにするため)ワークステーションなど）。

4

5 に答える 5

24

鍵の生成

PKCS #5 バージョン 2.0で定義されている PBKDF2 などの認識済みのアルゴリズムを使用して、パスワードからキーを生成することをお勧めします。概説したアルゴリズムに似ていますが、AES で使用するためのより長い対称キーを生成できます。さまざまなアルゴリズムの PBE キー ジェネレーターを実装するオープン ソース ライブラリを見つけることができるはずです。

ファイル形式

ファイルのフォーマットとして暗号化メッセージ構文を使用することも検討してください。これには、ある程度の検討が必要ですが、使用する既存のライブラリがあり、S/MIME 対応のメール クライアントなど、他のソフトウェアとよりスムーズに相互運用できる可能性が開かれます。

パスワードの検証

パスワードのハッシュを保存したい場合、PBKDF2 を使用してキーを生成する場合は、標準のパスワード ハッシュ アルゴリズム (ビッグ ソルト、1000 ラウンドのハッシュ) を使用して、異なる値を取得できます。

または、コンテンツの MAC を計算することもできます。パスワードのハッシュ衝突は、攻撃者にとって有益である可能性が高くなります。コンテンツのハッシュの衝突は無価値である可能性があります。しかし、これは、復号化に間違ったパスワードが使用されたことを正当な受信者に知らせるのに役立ちます。

暗号塩

Saltは、事前に計算された辞書攻撃を阻止するのに役立ちます。

攻撃者が可能性の高いパスワードのリストを持っているとします。彼はそれぞれをハッシュして、被害者のパスワードのハッシュと比較し、一致するかどうかを確認できます。リストが大きい場合、これには長い時間がかかることがあります。彼は次のターゲットに多くの時間を費やしたくないので、ハッシュが対応する入力を指す「辞書」に結果を記録します。パスワードのリストが非常に長い場合は、レインボー テーブルなどの手法を使用してスペースを節約できます。

しかし、彼の次のターゲットが彼らのパスワードをソルトしたとします。攻撃者がソルトが何であるかを知っていたとしても、事前に計算されたテーブルは無意味です。ソルトは、各パスワードから得られるハッシュを変更します。彼は、リスト内のすべてのパスワードを再ハッシュし、ターゲットのソルトを入力に追加する必要があります。ソルトごとに異なるディクショナリが必要であり、十分な量のソルトが使用されると、攻撃者はそれらすべてのディクショナリを格納する余地がなくなります。時間を節約するためにスペースを交換することは、もはや選択肢ではありません。攻撃者は、攻撃したいターゲットごとに、リスト内の各パスワードのハッシュにフォールバックする必要があります。

したがって、塩を秘密にしておく必要はありません。攻撃者がその特定のソルトに対応する事前に計算された辞書を持っていないことを確認するだけで十分です。

于 2008-09-11T06:37:40.467 に答える
2

Niyaz が言ったように、ハッシュと暗号化にSHA-265やAESなどの強力なアルゴリズムの高品質な実装を使用する場合、このアプローチは妥当に思えます。さらに、Saltを使用して、すべてのパスワード ハッシュの辞書を作成する可能性を減らすことをお勧めします。

もちろん、Bruce SchneierのApplied Cryptographyを読むことも決して間違いではありません。

于 2008-09-11T06:03:17.990 に答える
1

パスワードで保護されたファイルをサポートする圧縮ライブラリを使用しないのはなぜですか? 過去に、XML コンテンツを含むパスワードで保護された zip ファイルを使用しました:}

于 2008-09-11T06:01:43.640 に答える
1

強力なハッシュ アルゴリズム (SHA-2) と強力な暗号化アルゴリズム (AES) を使用している場合は、このアプローチでうまくいくでしょう。

于 2008-09-11T05:56:00.037 に答える
0

ハッシュ化されたパスワードをファイルに保存する必要は本当にありますか。パスワード（またはハッシュ化されたパスワード）をソルトとともに使用して、それでファイルを暗号化することはできませんか。復号化するときは、パスワードとソルトを使用してファイルを復号化してみてください。ユーザーが間違ったパスワードを入力した場合、復号化されたファイルは正しくありません。

私が考えることができる唯一の欠点は、ユーザーが誤って間違ったパスワードを入力し、復号化が遅い場合、再試行するのを待たなければならないことです. もちろん、パスワードを忘れた場合、ファイルを復号化する方法はありません。

于 2008-09-11T07:08:06.337 に答える