Subject: [mobile-ip] issue 233: 160 vs 128 bit entropies in RR

From: Pekka Savola <[email-masked]>
Date: Sat, 25 Jan 2003 07:23:32 +0200 (EET)

Issue 233:
=====
Pekka Savola writes:

   When the mobile node has received both the Home and Care-of Test
   messages, the return routability procedure is complete.  As a result
   of the procedure, the mobile node has the data it needs to send a
   Binding Update to the correspondent node.  The mobile node hashes the
   tokens together to form a 20 octet binding key Kbm:

       Kbm = SHA1 (home keygen token | care-of keygen token)

==> a hash of 128 bits generates a 160-bit key?  Is this enough entropy 
for
this algorithm??  Perhaps this is ok (I don't know how well those hashing
algorithms work with this little input), but if so, the reasoning 
should be mentioned explicitly somewhere (e.g. security considerations?)

   In this case, the care-of keygen token is not used.
   Instead, the binding management key is generated as follows:

       Kbm = SHA1(home keygen token)

==> 64 bits -> 160 bits, see above

------------------------

Jari Arkko writes: I don't think entropy has been a consideration in
making the Kbm 20 bytes. Rather, where Kbm is used (HMAC_SHA1) you can
give a 20 byte input. RFC 2104 allows smaller lengths as well, but I'm
not sure it increases the security; it might even lower it. But yes,
the true entropy is what originally came into the system.  I still
think we should not explicitly make the values shorter. But did you
want an explanation somewhere about the implications of the size of
the original inputs?
=====

Yes.  What I'd like to see, is some justification for this mechanism.  
That is:

- is SHA1 used _solely_ for the up-ward compatibility with 160 bit keys 
(of different algorithm but same size)?
- does it matter if keygen tokens do not hash properly?  That is, if the 
mechanism is only used to join trusted data to get a specific-length 
output (with no fear of reverse-hashing the tokens), then no problem here
- the implications of hash algoritms to short input, do they generate 
randomly-looking data?

One of the main points, I guess, was that "should the resulting hash look 
authentic and indisguishable from any other (longer input)?"  If so, there 
may be a problem.  If not, some explanation could be useful (somewhere, 
e.g. security considerations).

Does that make sense?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings