Re: [Cfrg] Ed448 hash choice

To clarify my previous message, If you successfully find a collision on the hash value, then the extension property does not happen. However, if you successfully find a collision on the c bits of the permutation, then the extension property happens. But, this is 2^256 work factor for SHAKE256.  

Regards,
Quynh. 

________________________________________
From: Cfrg <cfrg-bounces@irtf.org> on behalf of Dang, Quynh <quynh.dang@nist.gov>
Sent: Tuesday, October 20, 2015 9:01 AM
To: Dan Brown
Cc: 'cfrg@irtf.org'
Subject: Re: [Cfrg] Ed448 hash choice

Hi Dan,

SHAKE256 if being used as 512-bit hash function is a wide-pipe hash function: the rate r is (1600 - 512) 1088 bits, but the hash output is only 512 bits.

Regards,
Quynh.

________________________________________
From: Cfrg <cfrg-bounces@irtf.org> on behalf of Dan Brown <dbrown@certicom.com>
Sent: Monday, October 19, 2015 1:52 PM
To: 'ilariliusvaara@welho.com'; 'gilles.vanassche@st.com'
Cc: 'cfrg@irtf.org'
Subject: Re: [Cfrg] Ed448 hash choice

Clarifying my preferred hash for Ed448:

1) For message digesting, i.e. all the hashing done by the verifier:
Pre-hash = internal hash = H = SHA3-512
So both the signer and verifier compute H(R,H(M))

2) For key derivation, i.e. secret integers computed by the signer:
PRF-hash = SHAKE256

Of the above, 1 is a strong preference, while 2 is a weak preference.

Why I recommend different hashes for the different tasks:

In the message digesting, no inputs are secrets, yet resisting forgery
depends on the security of H.  For these types of no-secret security
properties, I feel that the extra-large pipe of 1024 in SHA3-512 is a
reasonable security cushion for the hash, i.e. compensation for the lack of
a secret input.

Sorry if I'm being a bit harsh on hashes here. But when I recall the MD5 and
SHA1 collision and length extension attacks, and the novel ways in which we
are relying on hashes, I gravitate to a security buffer.

For key derivation, there are secret inputs, so I see less need for the
extra-wide pipe.  But there is more need for proper expansion, and SHAKE256
is already established for this.    Possible alternatives: HKDF or the
various methods in the generalized EdDSA proposal (applied to SHA3-512, or
some other Keccak).

Sorry for my earlier mistake of recommending SHAKE256 for the internal hash:
I was misinterpreting what the EdDSA internal hash to mean the key
derivation steps.  This correction should now align pretty much with what I
recommended in my ECDSA_CFRG proposal, so at least I am not contradicting
myself.

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg