「平文で」公開される 3 つのフィールドがあり、これらのフィールドにデジタル署名して、安全なハッシュ関数を使用して改ざんされていないことを確認したい場合。2 つのオプションがあります。
明らかに、アプローチ 1 はアプローチ 2 よりも高速ですが、アプローチ 2 は、さまざまな出力からの入力をリバース エンジニアリングすることによってソルトの値を発見することを防ぐという点で「より強力」になります (私はそう信じていますが、追加の CPU コストの価値がある)?
まず、ハッシュが署名されていないという標準的なコメントを発行する必要があります。デジタル署名は、キーと検証者が関与するプロセスです。ここでは、一部のデータをハッシュし、ハッシュ値を「安全な」場所に保持して、ハッシュ値の整合性をハッシュデータに拡張できるようにします。ハッシュ値が改ざんされていないことを確認し、 、データ要素に対してハッシュを再計算し、同じハッシュ値を見つけることで、フィールド要素も改ざんされていないという考えに自信を持てるようになります。
次に、2番目の標準コメントを発行する必要があります。これは、現実的な条件で適切に測定されるまでパフォーマンスの問題はないということです。ハッシュは高速です。それほど高速ではないハッシュ関数でも、基本的なPCは1秒あたり数百万のハッシュ操作を実行できます。
さて、あなたは「塩」を使いたいと思います。ソルトは公開データの一部であり、その目的は、復号化コストの共有を防ぐために、インスタンスごとに区別することです。これは、暗号化されたデータがある設定では意味があります。あなたの説明からわかる限り、あなたの問題には暗号化されたものは何もありません。
...実際に「ソルト」を秘密にして、データフィールドと一緒にハッシュ値を保存することを意味する場合を除きます。その場合、ハッシュについてはもう話していません。あなたの「ソルト」は、機密を保持することを目的としているため、より適切には「キー」と呼ばれます。そして、ハッシュではなくMACが必要です。MACは「署名」と呼ばれることもあります。これは適切ではありませんが、ハッシュを「署名」と呼ぶよりも不適切ではありません。必要なのがMACである場合（そしてソルトが本当に重要である場合）、どちらの構造も使用しないでください。MACの構築は簡単ではありません。セキュリティに関しては、多くの手作りの構造は完全に失敗します。幸い、 HMACと呼ばれる標準のMACがあります。HMACは、基盤となるハッシュ関数（SHA-256を使用）とキーをスマートな方法で使用して、それらをMACに変換します。HMACは、多くの暗号化ライブラリでサポートされています。
独自に作成しようとする代わりに、HMAC (ハッシュベースのメッセージ認証コード) を使用します。それはより安全であり、ほとんどすべてのプラットフォームには、他の誰かが開発、テスト、および保守するために使用できる無料の実装が既にあります.
「追加の CPU コストに見合う価値がある」かどうかを誰が判断できますか? どのくらいの頻度でこれを行いますか? 実際に追加の CPU を購入する必要がありますか? 電気料金はいくらですか？バランスの反対側では、自作のアルゴリズムによって「保護」されたデータが誰かによって改ざんされた場合、どのような損害が発生するでしょうか?