[Cryptography] please dont weaken pre-image resistance of SHA3 (Re: NIST about to weaken SHA3?)

[ianG]

On 14/10/13 17:51 PM, Adam Back wrote:
> On Tue, Oct 01, 2013 at 12:47:56PM -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.
>
> I think hash functions clearly should try to offer full (256-bit) preimage
> security, not dumb it down to match 128-bit birthday collision resistance.
>
> All other common hash functions have tried to do full preimage security so
> it will lead to design confusion, to vary an otherwise standard
> assumption. It will probably have bad-interactions with many existing
> KDF, MAC,
> merkle-tree designs and combined cipher+integrity modes, hashcash (partial
> preimage as used in bitcoin as a proof of work) that use are designed in a
> generic way to a hash as a building block that assume the hash has full
> length pre-image protection.  Maybe some of those generic designs survive
> because they compose multiple iterations, eg HMAC, but why create the work
> and risk to go analyse them all, remove from implementations, or mark as
> safe for all hashes except SHA3 as an exception.


I tend to look at it differently.  There are ephemeral uses and there 
are long term uses.  For ephemeral uses (like HMACs) then 128 bit 
protection is fine.

For long term uses, one should not sign (hash) what the other side 
presents (put in a nonce) and one should always keep what is signed 
around (or otherwise neuter a hash failure).  Etc.  Either way, one 
wants here a bit longer protection for the long term hash.

That 'time' axis is how I look at it.  Simplistic or simple?

Alternatively, there is the hash cryptographer's outlook, which tends to 
differentiate collisions, preimages, 2nd preimages and lookbacks.

 From my perspective the "simpler" statement of SHA3-256 having 128 bit 
protection across the board is interesting, perhaps it is OK?


> If MD5 had 64-bit preimage, we'd be looking at preimages right now being
> expensive but computable.  Bitcoin is pushing 60bit hashcash-sha256
> preimage
> every 10mins (1.7petaHash/sec network hashrate).


I might be able to differentiate the preimage / collision / 2nd pi stuff 
here if I thought about if for a long time ... but even if I could, I 
would have no confidence that I'd got it right.  Or, more importantly, 
my design gets it right in the future.

And as we're dealing with money, I'd *want to get it right*.  I'd 
actually be somewhat happier if the hash had a clear number of 128.


> Now obviously 128-bits is another scale, but MD5 is old, broken, and there
> maybe partial weakenings along the way.  eg say design aim of 128 slips
> towards 80 (in another couple of decades of computing progress).  Why
> design
> in a problem for the future when we KNOW and just spent a huge thread on
> this list discussing that its very hard to remove upgrade algorithms from
> deployment.  Even MD5 is still in the field.

Um.  Seems like this argument only works if people drop in SHA3 without 
being aware of the subtle switch in preimage protection, *and* they 
designed for it earlier on.  For my money, let 'em hang.

> Is there a clear work-around proposed for when you do need 256?  (Some
> composition mode or parameter tweak part of the spec?)


Use SHA3-512 or SHA3-384?

What is the preimage protection of SHA3-512 when truncated to 256?  It 
seems that SHA3-384 still gets 256.

  And generally where
> does one go to add ones vote to the protest for not weakening the
> 2nd-preimage propoerty?


For now, refer to Congress of the USA, it's in Washington DC. 
Hopefully, it'll be closed soon too...



iang