lkml.org 
[lkml]   [2003]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH] Make cryptoapi non-optional?
    On Tue, Aug 12, 2003 at 11:06:14PM -0500, Matt Mackall wrote:
    >
    > The argument applies to any and all structure. If X and Y are n-bit
    > words and some pairs (X,Y) are more likely than others even though X
    > and Y are perfectly distributed when looked at normally, the
    > distribution (and hence the entropy) of X^Y will be less ideal than X
    > or Y taken alone. No statistical tests will catch the case of
    > X=hash(a) and Y=hash(~a).

    Right, but that's also easy to test. You just simply test the
    statistical randomness of folded hash. In any case, if there was any
    kind of correlation between any two bits in the SHA hash, that would
    be a significant weakness in the hash, and would have detected before
    now.

    > I'll buy that. However simply dropping the data would serve this
    > purpose better. As would hashing less than the entire pool on each
    > read.

    Dropping the data does serve this purpose, yes. But it has the
    downside of exposing half the hash directly to the attacker. This
    probably shouldn't be an issue, but if you assume no statistical
    correlation between any two bits, folding will hide half of the hash.

    In any case, it probably doesn't make that much difference either way,
    assuming that SHA is anywhere near competently designed.

    > > 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.
    >
    > Mostly agreed. But I would also like to:
    >
    > a) cat /dev/urandom > /dev/hda and not have it take all day

    You shouldn't be using /dev/urandom this way. OpenBSD has a
    /dev/frandom which is just a quick psuedo-random generator. I've
    resisted this, since there's no reason why this should be done in the
    kernel. User-space is perfectly capable of taking 160 bits of
    randomness out of /dev/urandom, and using it to seed a SHA-based
    random number generator. However, if people insist on doing silly
    things like "cat /dev/urandom > /dev/hda", and worse yet, screwing
    with the /dev/random and /dev/urandom with the excuse that speed is of
    importance, then perhaps following OpenBSD and implementing
    /dev/frandom is a better choice.

    > b) enable syncookies with less of a performance penalty

    Syncookies doesn't use the mainline random number generator at all.
    It uses a syncookie secret generated using the high quality random
    number generator, and it uses a single crank of the SHA hash to
    generate the random number.

    > c) generate other short-term keys, cookies, and UUIDs rapidly

    In the kernel or in user space? In either case, the right answer is
    to do something similar to what Syncookies does --- pull a seed from
    /dev/urandom, and then use simple SHA-based PRNG to generate
    short-term keys, cookies, or UUID's.

    > d) not disable preemption for long stretches while hashing (a
    > limitation of cryptoapi)

    Sounds like a bug in CryptoAPI that should be fixed in CryptoAPI.

    - Ted
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:47    [W:3.041 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site