On 05/10/13 20:00, John Kelsey wrote:
http://keccak.noekeon.org/yes_this_is_keccak.html
Seems the Keccac people take the position that Keccak is actually a way of creating hash functions, rather than a specific hash function - the created functions may be ridiculously strong, or far too weak.
It also seems NIST think a competition is a way of creating a hash function - rather than a way of competitively choosing one.
I didn't follow the competition, but I don't actually see anybody being right here. NIST is probably just being incompetent, not malicious, but their detractors have a point too.
The problem is that the competition was, or should have been, for a single [1] hash function, not for a way of creating hash functions - and in my opinion only a single actual hash function based on Keccak should have been allowed to enter.
I think that's what actually happened, and an actual function was entered. The Keccac people changed it a little between rounds, as is allowed, but by the final round the entries should all have been fixed in stone.
With that in mind, there is no way the hash which won the competition should be changed by NIST.
If NIST do start changing things - whatever the motive - the benefits of openness and fairness of the competition are lost, as is the analysis done on the entries.
If NIST do start changing things, then nobody can say "SHA-3 was chosen by an open and fair competition".
And if that didn't happen, if a specific and well-defined hash was not entered, the competition was not open in the first place.
Now in the new SHA-4 competition TBA soon, an actual specific hash function based on Keccac may well be the winner - but then what is adopted will be what was actually entered.
The work done (for free!) by analysts during the competition will not be wasted on a changed specification.
[1] it should have been for a _single_ hash function, not two or 3 functions with different parameters. I know the two-security-level model is popular with NSA and the like, probably for historical "export" reasons, but it really doesn't make any sense for the consumer.
It is possible to make cryptography which we think is resistant to all possible/likely attacks. That is what the consumer wants and needs. One cryptography which he can trust in, resistant against both his baby sister and the NSA.
We can do that. In most cases that sort of cryptography doesn't take even measurable resources.
The sole and minimal benefit of having two functions (from a single family) - cheaper computation for low power devices, there are no other real benefits - is lost in the roar of the costs.
There is a case for having two or more systems - monocultures are brittle against failures, and like the Irish Potato Famine a single failure can be catastrophic - but two systems in the same family do not give the best protection against that.
The disadvantages of having two or more hash functions? For a start, people don't know what they are getting. They don't know how secure it will be - are you going to tell users whether they are using HASH_lite rather than HASH_strong every time? And expect them to understand that?
Second, most devices have to have different software for each function - and they have to be able to accept data and operations for more than one function as well, which opens up potential security holes.
I could go on, but I hope you get the point already. -- Peter Fairbrother _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
