Re: get_random_int() should use hash[1]

[David Miller]

From: David Miller <davem@xxxxxxxxxxxxx>
Date: Tue, 16 Aug 2011 02:09:35 -0700 (PDT)

> From: "George Spelvin" <linux@xxxxxxxxxxx>
> Date: 16 Aug 2011 05:07:23 -0400
> 
>> Re: commit e997d47bff5a467262ef224b4cf8cbba2d3eceea
>> 
>> As long as you're using MD5, you should know that each round only
>> modifies one word of the state.  The order is [0], [3], [2], [1],
>> repeating 64 times.  Thus, on output, word [1] is the "most hashed"
>> word.  If you really wanted word [0], you could just skip the last
>> 3 rounds.
>> 
>> It's not really critical, but as long as you're performing the
>> rounds, you might as well use them...
> 
> Please provide a proper signoff with your change and properly
> "-p1" base your patch.

Not a problem.  This came up in the middle of a rebase operation so I
didn't have a tree immediately at hand to work with.

I'll also get the various uses in net/core/secure_seq.c.

One thing about that commit I'm becoming more concerneed by: I notice that
it eliminates the periodic reseeding of the secret.

While the reduction in the number of random bits was a tradeoff (and it
can be increased to 28 or so), it had two great advantages:
- The usefulness of an attack drops off sharply after 5 minutes (you
  can still attack connections established during the attack window,
  but then you have to guess how much data has been sent across them).
- An initial shortage of seed entropy does not become a persistent
  problem.  Note that late_initcall() is still before any device
  activity, much less entropy pool re-seeding from init scripts.

Put together, an attacker has the system uptime to try to guess
the low-entropy boot seed.  That's not clearly a security improvement.

What I *really* wonder is whether such a change is really -stable
material.  Cc: to Matt Mackall for comment.

It seems at least worth figuring out a way to defer seeding until
after /dev/random reseeding.  (E.g. until first non-loopback
connection is made.)

(There are also both better and faster algorithms than MD5 for
the job, but that's a separate issue.)


Just for example, as long as you're actually willing to spend more CPU
time, you could do *both*.  Compute both a fixed-secret 32-bit value and a
changing-secret 24-bit value and add them together.  Best of both worlds.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/