[Cryptography] Why is a short HMAC key zero-padded instead of hashed?

[Stephen Farrell]

On 01/02/17 22:20, Jerry Leichter wrote:
> There is a reported erratum against that RFC, which changes the text
> about long keys to say "Applications MUST not use keys longer than B
> bytes."  The explanation given is that "Using this approach creates
> an exploitable vulnerability where there are two known K instances,
> one the hashed key, and the other the key itself.... To cite a real
> world vulnerability; for all keys longer than B, using password
> storage configurations which store the hash of the key for integrity
> checks, and store the key itself in a tamper proof device, there will
> exist plain text keys stored on both storage systems. Compromising a
> hash database should not reveal plain text secrets, which will only
> be true if an implementation first hashes the key and uses the
> resultant L byte string as the actual key to HMAC."
> 
> The disposition of the Erratum is not clear.

I'll ask on cfrg and dispose of that accordingly. I'm not
sure the suggested fix is the right thing, nor what is done
in deployed code.

Thanks for bringing that up

S.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3840 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170202/aa9ef099/attachment.bin>