ToppyMicroServices

RFC 6234 Quiz (JA)

US Secure Hash Algorithms

ENJA
0 / 0

参照（URL）

範囲: RFC 6234はSHA algorithmを規定し,SHA/HMAC/HKDFのsample codeを提供します.HMACとHKDFのconstructionはRFC 2104とRFC 5869が定義します.structured-data serialization,signature,request authentication,authorizationは構成するprotocolの責務です.

Q1: RFC 6234自身が規定する内容はどれか

単一選択

A2A draftが, SHA-256, HMAC-SHA-256, HKDF-SHA-256の完全なnormative definitionとしてRFC 6234だけを参照しています.

**解説:** A: RFC 6234はHMACやHKDFの完全なspecificationを再掲していません. B: Section 7.1はHMACのcontextとreferenceを示しますが, 完全なHMAC specificationではありません. HKDFも外部仕様です. C: RFC 6234 Sections 1 and 3-6はSHA-1,SHA-224,SHA-256,SHA-384,SHA-512を規定します.Section 7.1はHMACのRFC 2104,Section 7.2はHKDFのRFC 5869を参照し,Section 8は三familyのsample codeを含みます. D: SHA processingは規定されており, 各implementationへ任されていません.

Q2: structured valueをhashする前にA2A profileが定義すべきものは何か

単一選択

二つのconforming SHA-256 libraryが同じlogical task objectを受け取ります. 一方はUTF-8 JSON, 他方はplatform object serializationをhashします.

**解説:** A: RFC 6234は与えられたbit stringをhashし, application-level equivalenceは認識しません. B: character encoding, field encoding, numeric representationはすべてinput bitsを変えます. C: RFC 6234 Sections 1, 2, and 4はalgorithm-level inputとprocessingを定義します. canonicalizationとtruncationは, interoperableなprotocol useのためprofileが固定する選択です. D: display encodingはdigestの後段であり, 異なるhash inputを一致させません.

Q3: digest verification前のcanonicalizationをどこで行うべきか

単一選択

clientがJSONとSHA-256 digestを送ります. gatewayはJSONをparseして書き換えてからforwardします. backendは書き換え後のbytesをhashしますが, clientは元bytesをhashしました. 設計意図はclientの正確なrequest representationをdigestでauthenticateすることです.

**解説:** A: parsed-object equalityはclientのexact representationをauthenticateするclaimとは異なります. B: RFC 6234 Sections 1 and 4はspecific bit stringを処理します. A2A profileはsecurity meaningを持つbytesを定義し, verifierでそのまま保つかcanonically reproduceする必要があります. C: gatewayでの再計算はdigest claimを支えるpartyとbytesを変えます. D: 連結してもclientがauthenticateしたbytesを確立できず, 未定義のconstructionを追加します.

Q4: secret-prefixed SHA-256 constructionはHMAC profileを満たすか

単一選択

A2A profileはrequest authenticationにHMAC-SHA-256を求めます. あるimplementationは代わりにSHA-256(secret || request-bytes)を計算し, 自作test vectorには成功します.

**解説:** A: HMACにはdefined inner/outer keyed constructionがあり, secret concatenationはそのconstructionではありません. B: self-generated vectorは自己一貫性を示すだけで, HMAC conformanceを示しません. C: output lengthが等しくてもalgorithmは同値になりません. D: RFC 6234 Section 7.1はHMACについてRFC 2104を参照します. このreview conclusionはprofileの明示的なHMAC要件から導かれます. RFC 6234だけで全raw-hash constructionのsecurityを一般判定するものではありません.

Q5: raw SHA-256はHKDF-based key scheduleを満たすか

単一選択

A2A設計はshared input keying materialからrequest-proof keyとaudit keyを別々に導出する必要があります. profileはHKDF-SHA-256を指定しますが, implementationはSHA-256(input-keying-material)を一度だけ計算して両purposeへ使います.

**解説:** A: hash primitiveが共通でも, 異なるconstructionがsemanticに同じにはなりません. B: 一つのshared keyを得た後のlabelでは, KDFへ異なるderivation inputを与えられません. C: RFC 6234 Section 7.2はHKDFについてRFC 5869を参照します. profileはpurpose separationを含むHKDF inputを定義し, constructionのtestを行う必要があります. D: SHA-256はHKDFで一般的に使うhashです. 問題はnamed KDFをraw digestで置き換えたことです.

Q6: clientのA2A proofを維持するdigest pipelineはどれか

単一選択

clientがrequest digestへ署名します. gatewayはrequestをparse, normalizeし, normalized bytes, original digest, client verification成功を示すunsigned headerをbackendへ送ります. backendはnormalized operationをauthorizeします.

**解説:** A: SHA-256はexact input bitsを処理し, encoding間のapplication-semantic equivalenceを保ちません. B: authenticated representationとverifierを明示します. RFC 6234 Sections 1 and 4はdigest processingを提供し, signature verification, assertion protection, request mapping, authorizationはcomposition profileが提供します. C: output lengthではnormalized bytesを誰がauthenticateしたか分かりません. D: sample codeの正しいoutputでもunsigned success claimをauthenticateできず, authoritative request semanticsも選べません.