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

Reply via email to