Messages in this thread | | | Date | 24 Sep 2004 21:42:30 -0000 | From | linux@horizon ... | Subject | Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random |
| |
> What if I told the SHA-1 implementation in random.c right now is weaker > than those hashs in terms of collisions? The lack of padding in the > implementation is the cause. HASH("a\0\0\0\0...") == HASH("a") There > are billions of other examples.
EXCUSE me? You're a little unclear, so I don't want to be attacking strawmen of my own devising, but are you claiming the failure to do Merkle-Damgaard padding in the output mixing operation of /dev/random is a WEAKNESS?
If true, this is a level of cluelessness incompatible with being trusted to design decent crypto.
The entire purpose of Merkle-Damgaard padding (also know as Merkle-Damgaard strengthening) is to include the length in the data hashed, to make hashing variable-sized messages as secure as fixed-size messages. If what you are hashing is, by design, always fixed-length, this is completely unnecessary.
If I were designing a protocol for message interchange, I might add the padding anyway, just to use pre-existing primitives easily, but for a 100% internal use like a PRNG, let's see... I can reduce code size AND implementation complexity AND run time without ANY security consequences, and there are no interoperability issues...
I could argue it's a design flaw to *include* the padding. - 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/
| |