Subject: [mobile-ip] Text for issue #233: 160 vs. 128 bit entropies

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Feb 2003 15:41:05 +0200

Hi Pekka,

Here's a new section that I have added to the security considerations.
It talks about the lengths of the various items in the protocol and
tries to justify why they are sufficient.

Comments appreciated.

-----

14.4.6 Key Lengths

64 bit cookies are used to protect spoofed responses while the return
routability procedure is in progress. This is believed to be
sufficient, given that to blindly spoof a response a very large number
of messages would have to be sent before success would be probable.

The tokens used in the return routability procedure provide together
128 bits of information. This information is used internally as an
input to a hash function to produce a 160 bit quantity suitable for
producing the keyed hash in the Binding Update using the HMAC_SHA1
algorithm. The final keyed hash length is 96 bits. The limiting
factors in this case are the input token lengths and the final keyed
hash length. The internal hash function application does not reduce
the entropy.

The 96 bit final keyed hash is of typical size and believed to be
secure. The 128 bit input from the tokens is broken in two pieces, the
home keygen token and the care-of keygen token. An attacker can try to
guess the right cookie value, but again this would require a large
number of messages, in the average 2**63 messages for one or 2**127
for two. Furthermore, given that the cookies are valid only for a
short period of time, the attack has to keep a high constant message
rate to achieve a lasting effect. This does not appear practical.

When the mobile node is returning home, it is allowed to use just the
home keygen token of 64 bits. This is less than 128 bits, but
attacking it blindly would still require a large number of messages to
be sent. If the attacker is on the path and capable of seeing the
Binding Update, it could conceivably break the keyed hash with brute
force. However, in this case the attacker has to be on path, which
appears to offer easier ways for denial-of-service than preventing
route optimization.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Feb 2003 19:14:59 +0200

Pekka Savola wrote:

> I can't think of much to add here -- well, perhaps one thing.  A possibly 
> important factor I was mainly worried about was whether these hash 
> functions would produce useful (or even dangerous) results when applied to 
> shorter-than-probably-expected inputs, like 64 bits to generate 160 bits.
> But this does not seem to be a problem except for 
> local/on-the-path-observers -- if you're worried someone obtaining the 160 
> bit value and trying to invert it -- whether breaking the hash that way 
> would be easier.  I'm not sure but I think this is probably not a problem?  
> In any case, this might be spelled out in a short paragraph if it seems 
> like a potential issue worth noting.

If the internal hash step reduces the entropy in a surprising
way from 64 bits to something less, that would be a problem.
But I don't think it does.

I thought about this issue while writing the text. At first, I started
out to write *only* that but I quickly realized the other bit lengths
are more important to be explained to the reader. So I devoted
some amount of text to these, and tried to find a brief formulation
of the internal hash issue. This turned out to be simply the statement
"The internal hash function application does not reduce the entropy."

Perhaps the actual arguments supporting this statement do not
belong to the specification, but we can discuss them here:
I'm not a cryptographer, but... as long as the entropy is there,
we should be fine. Let's assume that there's something
"interesting" in the hash function which would produce
significantly less than 2^64 outputs from a 64 bit input.
This sounds awfully close to a hash function which would
allow us to vary the first 64 bits of an N-bit input and
find a collision faster than in 2^64 attempts. That would
be bad, and I don't think popular hash functions are so weak.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Feb 2003 18:45:06 +0200 (EET)

> tries to justify why they are sufficient.

This woulds very good to me.

Thanks.

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