[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 32 bit counter -- 96 bit HMAC-SHA/MD5

	 > No, they have to be secure for hours at best.  This is for per-packet
	 > authentication; when you rekey, old packets are useless to the adversary.
	 > And there are no secrecy implications here -- my attacks assumed that
	 > the key was still live.
	 
	 Let me rephrase what I meant.. These *algorithms* need to be secure
	 for years (not the actual MAC values, of course those change
	 relatively quickly).  The problem is that as computer speed increases
	 the amount of time required to brute-force these values will decrease.
	 Just look at how the time to break 40-bit keys has decreased over the
	 last year or two.
	 
	 I'm just afraid that a 96-bit MAC might come down into this breakable
	 range before the algorithms get replaced.  And if we limit them to 96
	 bits completely, eventually the brute-force mechanisms will catch up
	 with us.

Ah -- this makes more sense -- but I'm still not worried.

Let's consider a brute-force attack.  You take a known packet, crunch
at possible keys, and find something where the first 96 bits of the
HMAC-SHA output match the observed value.  But there are many possible
keys that will yield that result for this packet; most won't work for
the second packet.  When you find a key that works for the first two
packets, will it work for the third?  The fourth?  I'm not certain what
the exact complexity of this process is, but I'm sure that it's quite
high.  (I have some guesses, but I'd embarrass myself if I stated
them...)  Nor does the traditional collision attack apply here; you
can't find two matching hash values offline per the van Oorschot/Wiener
'94 paper, since the key is unknown.

It would be an interesting exercise, I think, to come up with a paper
design for an HMAC cracker, with the hash length, the truncation length,
and the key length as input parameters.

One more point -- the defense has another advantage here.  As the
apparent threat increases, we can cut the rekey time down.  That's
just a parameter of the key exchange mechanism, not code.
Follow-Ups: