On Tue, 2013-10-01 at 12:47 -0400, John Kelsey wrote: > The actual technical question is whether an across the board 128 bit > security level is sufficient for a hash function with a 256 bit > output. This weakens the proposed SHA3-256 relative to SHA256 in > preimage resistance, where SHA256 is expected to provide 256 bits of > preimage resistance. If you think that 256 bit hash functions (which > are normally used to achieve a 128 bit security level) should > guarantee 256 bits of preimage resistance, then you should oppose the > plan to reduce the capacity to 256 bits. If you think a 256 bit hash > function should only promise 128 bits of security, except in specific > applicaitons like keyed hashes where it has been analyzed specifically > and shown to get more, then you should (at least on technical grounds) > like the proposal to reduce the capacity to 256 bits for a 256-bit > hash output.
I think the question is rather, what is the exact benefit NIST expects from this? AFAIU, performance wasn't the major priority during the competition, was it? And even were, then Keccak has won already with the higher values, hasn't it? So when c roughly gives the performance/security tradeoff... then from a pure security POV, we should obviously set a high c, right? So has NIST experienced some real world scenarios where the "previous" values of c yielded in a too slow algorithm, that made it unusable for the job? Cause if not,... then I'm back to the argument, why moving the performance/security tradeoff towards performance, if there was no strong reason,... Even(!) if one says, that from a crypto POV, 128 bits would be enough for a 256 bit hash... as long as we aren't forced due to some strong performance reasons... rather waste the extra security margin than dropping it. Cheers, Chris. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
