HMAC-SHA256 ハッシュ生成

A: SHA-256 は一方向ハッシュ関数で、誰でも同じ入力のハッシュを計算できます。HMAC-SHA256はキーが必要で、キーを持つ者だけがHMAC値を生成・検証できます。 主な違い：SHA-256はデータの整合性（改ざんされたかどうか）のみを検証し、HMAC-SHA256は整合性とソースの真正性（認可された当事者からのものかどうか）の両方を検証します。 ユースケース：ファイル検証にはSHA-256を、API署名と認証にはHMAC-SHA256を使用します。

A: RFC 2104 はキー長をハッシュ関数の出力長以上にすることを推奨しています。HMAC-SHA256の場合、推奨キー長は≥256ビット（32バイト）です。 短いキー：キーが256ビット未満の場合、セキュリティは低下しますが有効です。 長いキー：キーが512ビット（SHA-256のブロックサイズ）を超える場合、まず256ビットにハッシュされ、追加のセキュリティは提供されません。 ベストプラクティス：256ビット（32バイト）のランダムキーを使用し、Base64またはHexエンコーディングで保存します。 パスワードジェネレーター を使用して高強度のキーを生成してください。

A: 典型的なAPI署名フロー：1) 署名文字列の構築：リクエストパラメータを合意した形式で連結します（HTTPメソッド、URL、タイムスタンプ、リクエストボディなど）。2) HMACの計算：共有キーを使用して署名文字列のHMAC-SHA256を計算します。3) リクエストへの追加：HMAC値をリクエストヘッダー（X-Signatureなど）またはクエリパラメータに追加します。4) サーバー検証：サーバーは同じ方法でHMACを計算し、リクエスト値と比較します。例：AWS Signature V4、GitHub Webhooks（X-Hub-Signature-256）、Stripe（Stripe-Signature）。 注意：署名文字列の構築順序は厳密に一致させる必要があり、通常はパラメータをアルファベット順にソートします。

A: HMAC-SHA256自体はリプレイ攻撃を防止できません。攻撃者は正当なリクエスト（HMAC署名を含む）を傍受して再送信できます。 防御方法：1) タイムスタンプ：署名文字列にタイムスタンプを含め、サーバーは期限切れのリクエストを拒否します（例：5分以上前のリクエスト）。2) Nonce（乱数）：各リクエストは一意の乱数を使用し、サーバーは使用済みNonceを記録して重複を拒否します。3) リクエストカウンター：クライアントはインクリメントカウンターを維持し、サーバーはデクリメントされたカウンターのリクエストを拒否します。 ベストプラクティス：タイムスタンプとNonceを組み合わせてリプレイ攻撃を防止しながら、サーバーでの大量のNonceセットの保存を避けます。AWS Signature V4とOAuth 1.0はどちらもこのアプローチを採用しています。

A: JWT（JSON Web Token） は複数の署名アルゴリズムをサポートしており、HS256がHMAC-SHA256です。JWTは3つの部分で構成されています：ヘッダー、ペイロード、署名。署名はbase64(header).base64(payload)に署名するためにHMAC-SHA256を使用し、トークンが改ざんされていないことを保証します。 利点：対称暗号化、高パフォーマンス、内部システムに適しています。欠点：キーはすべてのサービスで共有する必要があり、キー漏洩リスクが高くなります。 代替手段：RS256（RSA署名）またはES256（ECDSA署名）は非対称暗号化を使用し、より安全ですが若干パフォーマンスが低下します。

A: どちらも安全です。選択は具体的なニーズによって異なります。HMAC-SHA256：256ビット出力（64文字）、より良いパフォーマンス、より広い互換性、業界標準（AWS、GitHub、Stripeで使用）。 HMAC-SHA512：512ビット出力（128文字）、理論的により高いセキュリティ、64ビットシステムではHMAC-SHA256よりもさらに良いパフォーマンス、ただし長い出力はより多くの帯域幅とストレージを消費します。 推奨：ほとんどのアプリケーションでは、HMAC-SHA256が最良の選択です。より高いセキュリティ（政府の機密データ、長期有効な署名など）や64ビットサーバーでのパフォーマンスが必要な場合は、 HMAC-SHA512 を選択してください。