Fingerprint algorithm and SHA-1 usage [was: Re: SHA3 IANA registration - method?]

[Christian Aistleitner]

Hi Andrey,

On Fri, Dec 14, 2012 at 05:32:16PM -0800, Andrey Jivsov wrote:
> The OpenPGP ecosystem uses fingerprints as a 
> shortcut for keys quite extensively.

for whatever "OpenPGP ecosystem" means to you :-)

IIRC, in RFC 4880 the fingerprint is used as "a shortcut for keys"
only once [1] -- and the corresponding subpacket is not even
mandatory.
I would not call that "quite extensively".

Part of the SHA-1 fingerprint also makes up the key id. But that can
even less be expected to be unique. And it's useful only as sieve for
keys (to limit the keys you have to check) than a unique handle to a
key.

So for whatever software or practice [2] you employ that mistakes
fingerprints for unique key identifiers, fix that software or
practice -- it's not the flaw of RFC 4880.


Indeed SHA-1 /fingerprints/ are not a problem. As they are effectively
not used in RFC 4880, it's up to us—the users and software
developers—if we use them or what we use them for. We can switch at
will [3].


The problem is rather SHA-1 than fingerprints. And OpenPGP also uses
SHA-1 for other things than fingerprints as well. RFC 4880 forces
SHA-1 usage also in
* § 5.5.3 Secret-Key Packet Formats (usage 254)
* § 5.14 Modification Detection Code Packet

Fortunately, SHA-1 in those packets does not do much harm. But it shows
that, we do not get rid of SHA-1 by only changing the OpenPGP
fingerprint algorithm.

Furthermore, eight other packet types allow to set the used hash
algorithm. But as SHA-1 is the only mandatory hashing algorithm, we
may resort to using it, when trying to provide maximal
interoperability within RFC 4880.

So if we want to avoid SHA-1 (and I am all for it), we'd rather change
  "Let's see how to change the fingerprint algorithm."
to
  "Let's avoid SHA-1"
. And it's actually easy.



> 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, 

I tend do disagree.

As said above switching the fingerprint algorithms, does not
eliminate SHA-1 from OpenPGP.

But even if. Forcing the fingerprint algorithm allows for effortless
interoperability, but it limits the users' freedom to avoid using
algorithms within the specification's borders.

Even worse: as soon as the chosen algorithm is broken (for whatever
value of broken), dependent applications are probably affected/broken
as well and they cannot switch away quickly.

We'd end up being in the same situation as now -- only having traded
SHA-1 by whatever algorithm we'd settle on.


Best regards,
Christian


[1] "Revocation Key" subpackets.
http://tools.ietf.org/rfcmarkup?doc=4880#section-5.2.3.15

And the key owner can decide for her-/himself whether she/he wants to add
"Revocation Key" packets.

[2] Yes, that includes typical key signing parties.

[3] Shameless plug: You can for example allow others to avoid SHA-1 at
key-signing parties, by adding additional (non-standard) SHA-512
fingerprints to your paper slips:
  http://openpgp.quelltextlich.at/slip.html?key=8421F11C&format=pdf&variant=SHA512,A4R,sparse
as described here
  http://openpgp.quelltextlich.at/slip.html?query=0x8421F11C#faq-additional-digests



-- 
---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
                           Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65a        Email:  christian at quelltextlich.at
4040 Linz, Austria           Phone:          +43 732 / 26 95 63
                             Fax:            +43 732 / 26 95 63
                             Homepage: http://quelltextlich.at/
---------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: </pipermail/attachments/20121215/915a6198/attachment.pgp>