Re: [Cfrg] Fwd: Hash-Based Key Derivation

David Wagner wrote on 10/25/2005 02:51:58 PM:

> >> I wanted call your attention to an individual draft on "Hash-Based 
> >> Key Derivation."
> >>       http://www.ietf.org/internet-drafts/draft-dang-nistkdf-00.txt
> 
> General: The document doesn't specify how integers are to be encoded.
> Little-endian?  Big-endian?  It seems to me that protocols that 
reference
> this spec should be required to specify the encoding of integers into
> bit-strings.

The counter in Step 3, Section 2.2 is said to be big-endian.  I presume 
that endian-ness of the various length indicators (for algorithmID, 
contextID, SharedInfo) are intended to specified by the application 
protocol, as this spec only says that they are fixed-length bit strings 
without specifying the length.

> 
> 2.1.2: algorithmOID is variable-length, but there is no length field
> prepended to it.  It seems like this omission should be remedied.

Doesn't algorithmLen do this?  My concern is with the ASCII string 
encoding of algorithmOID: why not use the usual DER encoding?  What ASCII 
string should be encoded?   The sequence of numbers, separated as spaces, 
embedding as ASCII?

Also, traditionally, many object identifiers are associated with some 
parameters, with the whole bundle being called an algorithm identifier.  I 
feel that a proper algorithm identifier would be more appropriate rather 
than just an object identifier with the parameters field cut off.

> 
> 2.1.4: The size of keydatalen is not specified.  It should be.

But keydatalen is an input, how can it be specified?  Do you mean that 
there should be a minimum size for keydatalen?

> 
> 2.1.6: I'm not entirely certain about the requirement that "protocols
> SHOULD support multiple hashes"; perhaps that SHOULD should be a MAY.

Agree.

> 
> 2.2: I agree that the spec should probably be using a PRF (e.g., H-HMAC)

Presumably this is based on two results: (1) HMAC makes a good PRF and (2) 
PRF makes a good KDF.  Are there convenient references for such results? 
If their explanations are short enough, could somebody summarize them to 
me?

> rather than a plain hash (H), 

Moreover, this comments implies some doubt about the security of the more 
direct construction in HKDF, i.e. that without going through a HMAC may 
not only be formally unjustified but perhaps insecure.

> and probably should be pre-hashing the secret
> value with H (depending upon the properties of the PRF).

Wouldn't pre-hashing create a bottleneck for entropy, albeit one large 
enough for adequate security?  With HDKF, if SV contains more than hashlen 
bits of entropy, there's some chance that the DerivedKeyMaterial also 
comes out more than hashlen bits of entropy.  If SV was replace with 
Hash(SV), the maximum entropy would be hashlen. 

> 
> 4: Should there be some discussion about the dangers of hash negotiation
> (e.g., that your security against active attacks might degrade to that
> of the weakest hash supported)?

Agree.