Re: [openpgp] Fingerprints and their collisions resistance

[Andrey Jivsov <[e-mail]>]

On 01/04/2013 12:55 PM, Andrey Jivsov wrote:
> On 01/03/2013 10:25 PM, ianG wrote:
> ...
>> Hence my earlier question - has anyone allocated the OpenPGP numbers for
>> Keccak as yet?  The reason I asked is because I stumbled on the code
>> last week and thought what a fine idea it would be to at least prepare
>> the way....  Strawman?
>>
>>    SHA3-224         4        12
>>    SHA3-256         5        13
>>    SHA3-384         6        14
>>    SHA3-512         7        15
>>
>> Strawman?  I'm not sure why there is a gap 4-7 in rfc4880.  Are there
>> any spots already allocated?
>>
>
> One point I wanted bring up here based on the draft that I wrote last
> year is that let's think for a moment about the usefulness of the SHA3-224.
>
> I would like to see an argument for it. Algorithms like DSA/ECDSA are
> capable to deal with hash truncation or padding. RSA mod has sufficient
> space to always use SHA3-512.
>
> The question is especially relevant if you familiarize yourself with the
> Keccak. Keccak is basically a single hash algorithm which output is
> truncated to 256, 384, 512, etc bits. The only difference between
> SHA3-256 and SHA3-512, for example, is one integer used in the internal
> loop.
>
> You can always go with stronger security. Who are those people who would
> not be OK with SHA3-256 but are happy with SHA3-224 ? Why can't they use
> shorter public keys (to solve space concerns?) ?

I think I found some support to my suggestion in the latest SHA2 spec: 
FIPS 180-4 "Secure Hash Standard (SHS)":

> 7.  TRUNCATION OF A MESSAGE DIGEST
> Some application may require a hash function with a message digest length different than those
> provided by the hash functions in this Standard. In such cases, a truncated message digest may be
> used, whereby a hash function with a larger message digest length is applied to the data to be
> hashed, and the resulting message digest is truncated by selecting an appropriate number of the
> leftmost bits. For guidelines on choosing the length of the truncated message digest and
> information about its security implications for the cryptographic application that uses it, see SP
> 800-107 [SP 800-107].

In SHA2 SHA-224 is the SHA-256 with different IV. NIST was worrying 
about some theoretical concerns with examples that show non-uniform 
distribution of the SHA2 hash output (see 
http://csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf)

Given that there are no IVs in Keccak, the section 7 of FIPS 180-4 
allows the truncation, and the truncation should be happening anyway in 
practice when you use mismatched weaker DSA keys with stronger hashes, 
benefits of SHA3-224 are even harder to see.