SHA3 IANA registration - method?
openpgp at brainhub.org
Sat Dec 15 02:32:16 CET 2012
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
> 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
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
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
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.
More information about the Gnupg-devel