Re: [RFC][PATCH] Make cryptoapi non-optional?

[Theodore Ts'o]

On Sun, Aug 10, 2003 at 12:45:28PM -0500, Matt Mackall wrote:
> I suppose the comment you deleted was a little light on details, sigh.
> 
> The idea with the folding was that we can cover up any systemic
> patterns in the returned hash by xoring the first half of the hash
> with the second half of the hash. While this might seem like a good
> technique intuitively, it's mathematically flawed.

No, that's not why the folding was done.  You could have asked me
first....

First of all, I wasn't worried about simple correlations.  There are
enough statistical tests done that we don't need to worry about xor
causing problems.

The real issue is discarding information.  By folding, we hide
information about the output of the SHA hash that will hopefully deny
information that a Very Sophisticated Attacker (say, at the level of a
certain agency that designed the SHA algorithm) that might make it
easier for them to attack the SHA algorithm.

> just x. With the former, every bit of input goes through SHA1 twice,
> once in the input pool, and once in the output pool, along with lots
> of feedback to foil backtracking attacks. In the latter, every output
> bit is going through SHA four times, which is just overkill. 

Speed really doesn't matter here.  /dev/random is supposed to produce
somethign which is close to true randomness, not crypto
psuedo-randomness.  So overkill is a good thing.  It should only be
used for generating long-term keys, so speed is really not a concern. 

						- Ted
-
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/