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

Dennis E. Hamilton dennis.hamilton at acm.org
Sun Feb 5 13:56:56 EST 2017


TLDR: E.g., it is part of the procedure by which HMAC makes the key the same size as the block size of the hash function.

Details below.

> -----Original Message-----
> From: cryptography [mailto:cryptography-
> bounces+dennis.hamilton=acm.org at metzdowd.com] On Behalf Of Jerry
> Leichter
> Sent: Sunday, February 5, 2017 03:32
> To: Peter Gutmann <pgut001 at cs.auckland.ac.nz>
> Cc: Cryptography Mailing List <cryptography at metzdowd.com>; Ron Garret
> <ron at flownet.com>; Francisco Corella <fcorella at pomcor.com>; Stephen
> Farrell <stephen.farrell at cs.tcd.ie>
> Subject: Re: [Cryptography] Why is a short HMAC key zero-padded instead
> of hashed?
> 
[ ... ] 
> Does anyone know
> where the "hash it if too long" mechanism came from, as it's not in the
> base research paper?  *Someone* must have proposed it.  Or was it in
> some pre-existing implementation that got standardized without any
> thinking about it?
[orcmid] 

I have seen the hash-if-too-long scheme applied in the use of PBKDF2 and it comes directly from HMAC.

This is not provided directly in PKCS5 v2.0, which assumes that the password is an octet string of arbitrary length.

However, in Appendix B.1.1 of IETF RFC 2898, the pre-hashing of too-long passwords is described for the use of HMAC-SHA1.  The RSA Labs PKCS #5 v2.0 refers to RFC 2104, as does RFC 2898.  RFC2104 is very explicit about what is done when the key, K exceeds B, the block size of the hash function, H.  If K has fewer than B octets, the 0-padding is required before xor operations with the ipad and opad blocks.

In the application I am aware of [1], using HMAC-SHA1 as the PBKDF2 pseudo-random function, the application pre-hashes its password using SHA1 to produce the P for PDBKDF2. In that manner, the HMAC-SHA1 always uses that derived P as given.  The SHA1 pre-hash is *not* salted, although PBKDF2 uses the salt thereafter.

This case raises some pass-the-hash concerns for me because (1) the encryptions are for persistent static files, (2) there tend to be short known-plaintexts in the bundle of encrypted parts, (3) there is useful unencrypted metadata about the encrypted content, and (4) SHA1 hashes are recorded for certain "protections" in unencrypted material, creating candidates as potential hashes of reused passwords. To make matters worse, the protection by hashes in plaintexts is described and thought of as a document security mechanism [2].  Finally, the PBKDF2 work factor used by default is way too small.

Mitigating this situation involves adding complexity and does nothing for long-lived encrypted documents exposed to third-parties, if there are such things [;<).  There are proprietary tools that have some success helping people recover documents for which the password has been "lost."  These may simply be combinations of dictionary and variation attacks though.  More-sophisticated schemes, including crowd-sourced attacks, are likely kept in dark places.

 - Dennis

[1] OpenDocument Format for Office Applications (OpenDocument) v1.0.  OASIS Standard, 1 May 2005.  While there have been improvements in ODF 1.2, the pre-hashing of the password has not changed and the ODF 1.0 scheme parameters remain the default for document interchange preservation into up-version implementations of ODF.

[2] <https://tools.oasis-open.org/version-control/svn/oic/Advisories/00009-ProtectionKeySafety/trunk/description.html>

[ ... ]



More information about the cryptography mailing list