[Cryptography] Sha3

Peter Fairbrother zenadsl6186 at zen.co.uk
Sun Oct 6 21:13:26 EDT 2013


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


More information about the cryptography mailing list