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

[Stephen Farrell]

Hiya,

On 02/02/17 02:21, Stephen Farrell wrote:
> 
> 
> 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.
> 

I did that and concluded that "hold for document update" was
the right outcome so I've done that too.

S.

[1] https://www.ietf.org/mail-archive/web/cfrg/current/msg08942.html

> Thanks for bringing that up
> 
> S.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
> 

-------------- 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/20170203/742bacfe/attachment.bin>