SHA3 IANA registration - method?

[Andrey Jivsov]

On 12/14/2012 01:53 PM, Hauke Laging wrote:
> Am Fr 14.12.2012, 10:32:58 schrieb Andrey Jivsov:
>
>> I generate two keys A,B with the same fingerprint.
>
> And how are you going to do that? It's not enough to have two values with the
> same hash. These values (one is trivial) have to form valid key parameters.
> Otherwise you are not even capable of creating a valid self signature. The
> attack against X.509 certificates is easier as the hash refers to the whole
> certificate. Much more data to play with.
>

I answered the question:
"Can you describe an attack that might show how weak collision 
resistance could compromise the fingerprint?"

How practical this attack is a separate question and it requires much 
deeper analysts. It would depend on the ability to find collisions by 
choosing primes, dates, header sizes, selected by the attacker. Remember 
that we start from 80bit security by birthday bounds even when we simply 
randomly generate keys (for a perfect 160 bit hash function).

By the same token collision for ASCII documents is also not as easy as 
for arbitrary binary data. Same for colliding ISO images (with the 
intent is to create malicious code).

BTW, it's common to have a separate encryption-only subkey that doesn't 
need to sign anything.

>
>> I provide the key A
>> to another party. Another party encrypts a message to me using this key.
>>
>> At some later point that party deletes the key A
>
> So does the other party?

Do you mean the owner? Correct, the owner who generated keys A and B 
removes the incriminating key A. He will be claiming that he never had 
the key A. The key A need to disappear from caches. A and B in my 
description can be subkeys.

>
>
>> Here is my key (B) with the same fingerprint that
>> matches the one that the server has but this key doesn't decrypt the
>> message.
>
> This only works if
>
> 1) no-one (including the keyservers) has a copy of the key left

If you can keep everything that you signed (or hashed), you don't depend 
on collision resistance. The OpenPGP ecosystem uses fingerprints as a 
shortcut for keys quite extensively.

> 2) the key material is formally correct
 > 3) the key material is not bullshit (something that no software would 
create)

Yes, indeed, you have to produce the colliding pre-images that are 
appear valid to software tests. This is true for any attack on the 
collision resistance.

Does every OpenPGP software test validity of every public keys?


> So assuming a possible collision for SHA-1, how many collisions do you need to
> meet (2) and (3)?

Now let's ask ourselves: given what I said, would you be able to 
convince jurors about non-repudiation nature of a protocol that uses 
SHA-1 fingerprints? Would you feel better if it was, say, truncated 
P-256 or Keccak?

Regardless of practicality of the attacks, at some point OpenPGP 
fingerprints will start to be flagged by a black box audit based on the 
answer to "Do you use SHA-1 in applications that depend on collision 
resistance?".

What do I personally hope for here? A think a  solution that introduces 
a hardcoded Keccak fingerprint in the scope of RFC 4880 would be ideal, 
IMO. This assumes very slow adoption of this new alternative method.

Thank you.