並行環境でパスワードハッシュを生成および検証するために使用CCKeyDerivationPBKDF
していますが、それがスレッドセーフかどうかを知りたいです。関数のドキュメントではスレッド セーフについてはまったく言及されていないため、現在は安全のためにロックを使用していますが、必要がなければロックを使用したくありません。
2 に答える
のソースコードCCKeyDerivationPBKDF()
を調べたところ、「スレッドセーフではない」ことがわかりました。のコードCCKeyDerivationPBKDF()
はスレッドセーフな多くのライブラリ関数 (例: bzero
) を使用していますが、ほとんどのユーザー定義関数 (例: PRF
) とそれらのユーザー定義関数から呼び出される基になる関数は、潜在的にスレッドセーフではありません。(たとえば、いくつかのポインタの使用と安全でないメモリのキャストが原因で、たとえばCCHMac
)。基になるすべての関数をスレッドセーフにするか、少なくとも条件付きでスレッドセーフにするメカニズムがない限り、アプローチに固執するか、commoncrypto
コードを変更してスレッドセーフにしてそのコードを使用しない限り、私はお勧めします。
それが役に立てば幸い。
ドキュメントやソース コードが不足している場合、1 つのオプションは、CCKeyDerivationPBKDF への呼び出しでループする、たとえば 10 個のスレッドを使用して、たとえば 10 個の既知の結果を持つ 10 個の異なる引数セットからランダムに選択するテスト アプリを構築することです。
各スレッドは呼び出しの結果をチェックして、期待どおりであることを確認します。各スレッドは、可能な限り操作をインターリーブするために、このループ内でランダムな時間 (CCKeyDerivationPBKDF への各呼び出しにかかる時間の約 10% のベル カーブ) の usleep() 呼び出しも行う必要があります。
おそらく、どれだけの並行性を生成できるかを追跡するデバッグ機能を装備することをお勧めします。10% のスリープ時間と 10 のスレッドで、9 つのスレッドを同時に維持できるはずです。
100,000,000 回の呼び出しをエラーなしで実行できた場合、スレッドセーフであると思います。もちろん、より大きな保証を得るために、それよりもはるかに長く実行することもできます。