[147547] in cryptography@c2.net mail archive
Re: [Cryptography] Sha3
daemon@ATHENA.MIT.EDU (Peter Fairbrother)
Mon Oct 7 09:59:20 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 07 Oct 2013 02:13:26 +0100
From: Peter Fairbrother <zenadsl6186@zen.co.uk>
To: John Kelsey <crypto.jmk@gmail.com>,
Cryptography Mailing List <cryptography@metzdowd.com>
In-Reply-To: <CAE5511E-FC4D-458F-BCFA-747E30FBBD4D@gmail.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
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