Scrypt ハッシュの生成と検証

機能

• 双方向：ハッシュの生成、パスワードとハッシュの照合
• パラメータ調整可：N の指数（ln）、ブロックサイズ r、並列度 p
• 出力は PHC ハッシュ文字列、派生鍵の16進数 / Base64、あるいは3種類すべてから選択
• 検証時はハッシュからパラメータを読むため、事前に把握しておく必要がありません
• 現在のパラメータのメモリ消費を表示し、予算を超えたときは実際に使った N を明示します（黙って変更しません）
• 定数時間比較 —— 「先頭の数バイトが合った」ことで早期リターンしません

使い方

1. モードを選びます：生成または検証
2. 生成時はパラメータを調整（既定は ln=15 / r=8 / p=1、32MB）し、出力形式を選びます。検証時はハッシュを該当欄に貼り付けます
3. パスワードを入力欄に貼り付けます
4. Ctrl/⌘ + Enter か「実行」を押し、結果をコピーします

よくある質問

scrypt と bcrypt のどちらを選ぶべきですか？

どちらも現在は許容される選択で、違いは何を消費するかです。bcrypt は CPU だけを消費するため、GPU で何千ものインスタンスを同時に走らせられます。scrypt はメモリも消費し、1インスタンスあたり 128 × r × N バイトを占めるので VRAM がすぐ尽きます —— これが利点です。暗号学的な推奨順は Argon2id > scrypt > bcrypt で、いずれも「速い」ハッシュより遥かに優れています（SHA-256 でパスワードを直接保存するのは誤りです）。本ツールが両方を提供するのは、既存システムには bcrypt の資産が多いからです。

ln・r・p はどう調整しますか？

ln が主要なつまみです：N = 2^ln で、メモリも所要時間もこれに比例して増えるため、1つ上げるごとにコストが倍になります。既定の 15（N=32768、32MB）が通例で、passlib などの既定値でもあります。r はメモリと計算の配分を決めます（大きいほどメモリ寄り）。通常は 8 のままにします。p は入力を並列に分割し、総メモリを p 倍しますが、ブラウザでは単一スレッドで動くため、p を 1 より大きくしても速くならず総コストが増えるだけです。通常は 1 のままにします。

検証時にパラメータを入力しなくてよいのはなぜですか？

パラメータがハッシュ文字列自体に書かれているからです —— `$scrypt$ln=15,r=8,p=1$…` の部分です。これが PHC 形式の狙いで、検証側はハッシュさえあれば再計算でき、別途パラメータ表を保存する必要がありません（そんな表はいずれハッシュと同期しなくなります）。本ツールはハッシュ内の ln / r / p を読み、画面上の3つの入力欄は無視するので、書き換えても結果は変わりません。

生成したハッシュは他のプログラムで使えますか？

使えます。PHC 形式は passlib（Python）や node-scrypt などで共通の書き方で、ソルトとハッシュはパディングなしの標準 Base64 です。文字列全体を保存し、検証時にそのまま本ツールやそれらのライブラリに渡してください。逆に、他のシステムから渡された scrypt ハッシュが `$scrypt$…` の形をしていない場合（JSON や、古い `$7$` 形式など）、本ツールは認識できず、形式が違うと明示します。

PHC・16進数・Base64 のどれを選ぶべきですか？

パスワードを保存するなら PHC です —— ソルトとパラメータを含む唯一の形式で、1つの文字列だけで検証できます。16進数と Base64 は派生鍵の生バイト（既定で32バイト）で、ソルトも ln / r / p も含まないため、それだけではどのパスワードも検証できません。用途は「その鍵を別のものに使う」こと、たとえば HMAC 鍵や別の KDF の入力です。そのため同じパスワードでも PHC 文字列は毎回異なり（ソルトがランダム）、同じソルトとパラメータの下では16進数と Base64 は同じ鍵の2つの書き方で、デコードすると1バイトずつ一致します。