On 01/05/2012 05:59 PM, Thor Lancelot Simon wrote:
FWIW, using HMAC like this is the "extract" step of the two-step
extract-expand HMAC based construction that is HKDF
From http://tools.ietf.org/html/draft-krawczyk-hkdf-01
2.2. Step 1: Extract
PRK = HKDF-Extract(salt, IKM)
Options:
Hash a hash function; HashLen denotes the length of the
hash function output in octets
Inputs:
salt optional salt value (a non-secret random value);
if not provided, it is set to a string of HashLen zeros.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So this is your fixed-value 'tweak'.
IKM input keying material
Output:
PRK a pseudo-random key (of HashLen octets)
The output PRK is calculated as follows:
PRK = HMAC-Hash(salt, IKM)
Now the definition of HMAC from http://tools.ietf.org/html/rfc2104
where 'K' is the key/tweak input:
ipad = the byte 0x36 repeated B times
opad = the byte 0x5C repeated B times.
H(K XOR opad, H(K XOR ipad, text))
So HMAC with a fixed key input is exactly equivalent to evaluating the
underlying hash function twice with two different fixed prefixes.
HMAC does have some other desirable properties that the raw
hash functions do not, no?
I'm not seeing any for the simple extraction scenario, other than the
doubling-up of the hash function.
I thought HMAC met the strict avalanche
criterion, while SHA1 does not,
Well perhaps, but what I'm saying is that if you believe that that has
implications for your RNG extractor, then you also believe that SHA-1 is
not an ideal hash function, i.e., it is "broken" (and I think most folks
would agree with you on that).
But the hash function
SHA-1(fixed_prefix_b || SHA-1(fixed_prefix_a || text))
AKA
HMAC_SHA-1(fixed_key, text)
MAY be usefully less broken. However, the result will have slightly less
than the theoretical 160 bits of entropy (maybe 159.2) due to the way
SHA-1 is iterated.
and that this was one of the reasons
why truncation of HMAC results was considered safer than truncation
of raw hash results.
I think that that has more to do with the presumption that the key is
secret. If the attacker doesn't know the key, he can't compute the
function so he can't conduct offline attacks against the truncated result.
In this application, the result will often be
truncated when it is used, which is another reason why I -- naive
crypto-plumber though I am -- thought HMAC might be a better choice.
IMHO the bigger danger in RNGs is complexity and overengineering.
But others have well-reasoned opinions that differ from mine. :-)
- Marsh
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
