2

私たちの製品には、Windows API関数CryptEncryptを介して暗号化されたSQL文字列（MSSQLサーバーまたはsybaseSQLのいずれかを選択）として、アプリケーションのデータベースに長い間データが保存されている状況があります。 （直接および復号化可能）

問題は、CryptEncryptが出力にNULLを生成する可能性があることです。つまり、データベースに格納されると、文字列操作によって、ある時点でCipherTextが切り捨てられます。

理想的には、NULLを含まないCipherTextを生成するアルゴリズムを使用します。これにより、既存のデータベースへの変更が最小限に抑えられます（列を文字列からバイナリに変更し、コードを文字列ではなくバイナリに処理する）データベースのアップグレード時に、既存のデータを復号化し、新しいアルゴリズムで再暗号化するだけです。

データベースはすでに適度に安全な環境（オープンネットワーク/インターウェブではない）にあるため、アルゴリズムは最も安全である必要はありませんが、ROT13（頭の中でほとんど解読できる）よりも優れている必要があります今！）

編集：ところで、暗号文を暗号文に変更する特別な理由はありますか？暗号文はもっと広く使われているようです...

4

4 に答える 4

3

半ばまともなアルゴリズムは、結果の暗号文のどこかにNULL値を生成する可能性が高くなります。

DBに永続化する前に、 base-64のようなもので結果のバイナリブロブをエンコードしてみませんか？（C ++でのサンプル実装）。

于 2008-08-20T09:49:56.333 に答える
1

ハッシュを保存することは良い考えです。ただし、Jeff のYou're おそらく Storeing Passwords Incorrectlyを必ずお読みください。

于 2008-08-20T10:41:15.837 に答える
0

それは興味深いルートOJです。可逆的でない方法の実現可能性を検討しています（復号化するデータを明示的に取得しないように注意してください）。たとえば、送信時に比較するためにハッシュを保存するだけです。

于 2008-08-20T10:06:03.970 に答える
0

これを処理する開発者は、データを取得できるようにする必要があるため、既存の暗号化をyEncでラップしてテーブルの整合性を維持しようとしているようです。定着した設備。チアーズガイズ

于 2008-08-20T11:16:49.930 に答える