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

From: David Wagner <[email-masked]>
Date: Tue, 25 Oct 2005 11:51:58 -0700 (PDT)

>> 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.

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

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

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

2.2: I agree that the spec should probably be using a PRF (e.g., H-HMAC)
rather than a plain hash (H), and probably should be pre-hashing the secret
value with H (depending upon the properties of the PRF).

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)?

In general, it looks like a useful standard.  It has a few little
rough edges, but they can easily be smoothed off.

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Daniel Brown <[email-masked]>
Date: Tue, 25 Oct 2005 17:03:28 -0400

> this spec should be required to specify the encoding of integers into

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.

> 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?

> 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

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. 

> of the weakest hash supported)?

Agree.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Oct 2005 14:02:56 -0700

>SHOULD support multiple hashes"; perhaps that SHOULD should be a MAY.

All of the RFC2119esque SHOULDs and MUSTs in the document are wrong 
in that they are not about interoperability, but are instead about 
cryptographic goodness. The reference to RFC 2119 should be removed 
and all MAYs, SHOULDs, and MUSTs should be lowercased.

--Paul Hoffman, Director
--VPN Consortium