7

現時点では、非常に機密性の高い個人情報を処理するプロジェクトに取り組んでいますが、バックアカウント番号ではありませんが、依然として機密性の高い個人情報であり、この情報を暗号化して mysql 内に安全に保存するためにできることはすべてやりたいと考えています。できるだけ。そのため、この機密情報を処理できるセキュリティ対策を熱心に探しています。

文字列とテキスト ブロックを暗号化/復号化する簡単な方法の 1 つは、mcrypt を使用することです。しかし、stackoverflow で mcrypt を検索すると、多くの人が mcrypt は結局それほど安全ではないと言っていることに気付きました。

だから今私は疑問に思っています、それは本当にどのくらい安全ですか？キーが安全に保管されている場合、保管されている情報をクラックして復号化するには、多くのハッキング スキル、たとえば専門家のスキルが必要ですか? スキルがほとんどないハッカーが、mysql サーバー内に保存しようとしている暗号化された情報を解読できるのではないかと心配する必要はありますか? では、mcrypt で暗号化された暗号化された情報を解読するには、どのようなスキルが必要なのでしょうか?

Mcrypt が十分に使用できない場合、gnupg 拡張機能を使用するほど複雑ではない優れた代替手段は何ですか?

4

1 に答える 1

16

いくつかの落とし穴を回避し、いくつかの推奨事項を適用するために従うことができる小さなガイド.

  • 2 つの異なるメッセージに同じ暗号化キーと初期化ベクトル (IV) を再利用しないでください。

そうすることで、敵対者が同じキーと IV を使用して転送中に 2 つ以上のメッセージを傍受できた場合、平文が公開される危険があります。

  • ECB モードを使用しないでください。OFB および CTR モードは多少優れていますが、CBC または CFB モードを使用することをお勧めします。

ECB を使用しない主な理由は、このモードでは重複したプレーンテキスト ブロックに関する情報が漏洩し、エンコードされたデータ ストリームが損なわれる可能性があるためです。

OFB と CTR の方が優れていますが、同じ IV + キーの組み合わせを複数回使用するという前述のセキュリティ上の問題があります。

CFB と CBC は IV + キーの再利用に対して最も回復力がありますが、同じ共通のプレフィックスを持つ個別のメッセージは、そのプレフィックスの長さを漏らします。さらに、CFB は最初の同一でない平文ブロックの違いを漏らします。

  • 強力な暗号化キーがあることを確認してください

    印刷可能な ASCII から選択しないでください(たとえば、「私の超強力な秘密鍵」ではありません)。PBKDF2 が優先されます (すぐにネイティブでサポートされる予定ですが、それまでは Google で検索してください)。この鍵を安全に保管する必要があることは明らかです。失くしたらバイバイデータ。

  • 適切なエントロピー ソースを使用して、初期化ベクトルを生成します。

    Mcrypt には、 を呼び出すときに MCRYPT_DEV_RANDOM または MCRYPT_DEV_URANDOM を使用するオプションがありますmcrypt_create_iv()。

これがあなたを助けることを願っています:)

于 2012-06-15T15:29:36.207 に答える