Re: [openpgp] Fingerprints

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Apr 10, 2015 at 9:57 AM, Werner Koch <[e-mail]> wrote:
> On Fri, 10 Apr 2015 15:23, [e-mail] said:
>
>> There is no need to have an algorithm field, a version field is
>> sufficient because we should only be using one algorithm at a given
>
> Right.  However an algorithm field is as good as a version field because
> they have the same purpose in this context.  An algorithm field saves us
> a mapping to the actual algorithm.  Recall that OpenPGP uses an
> one-octet indentifier and not an OID.
>
>> time. There is no need for a length field either.
>
> Agreed.
>
> It is often useful to have a keyid to quickly (but insecure) refer to a
> key.  I suggest to take it from the fingerprint bytes 1 to 4 (ignoring
> the algorithm byte).  There is no need for a long keyid.  However, we
> may also suggest a use like in git where you may abbreviate it as you
> like - however the keyid should be non-normative because the protocol
> should not make any use of it.
>
>> I am also using SHA512 and truncating to 128 bits, then base 32
>> encoding. The rationale for this is
>
> Because there are several versions of BASE-32 I suggest the use of
> z-base-32 which is used by Tahoe-LAFS and ZRTP.  The truncation length of
> the hash should be match a best match for the base 32 encoding.

That is the one I am using already. Truncating to a multiple of 5 bits makes
sense to me (32 = 2^5). If we truncate to a multiple of 5 characters as well,
we can break at the segment boundaries:

100 bit fingerprint:
opgp:xxxxx-xxxxx-xxxxx-xxxxx

125 bit fingerprint:
opgp:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

200 bit fingerprint:
opgp:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

250 bit fingerprint:
opgp:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

The version field will steal a few bits. We might want to consider using
a 5 bit field rather than 8 and set it up so that the first character gives
the version number. Future generations can always decide to add bits
if they start to run out.


>> * Fingerprints are the root of trust, there is an outside chance that
>> SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits
>> is a lot harder because it has 80 rounds rather than 64.
>
> I think that should be discussed in the context of the new default hash
> algorithm.

OK, fair enough.


>> The bit that will probably be controversial is how I am calculating
>> them, over an X.509v3 KeyInfo block. There is method to the madness
>
> X.509 has no definition for a fingerprint but OpenPG already uses a well
> defined method to compute the fingerprint.  You can't compare the two
> protocols or define a unique fingerprint method.

The objective here is to be able to establish the fingerprint as the interface
between the trust model and the protocol.

X.509 does not have that concept at the moment. But introducing that
concept into the PKIX world is how I think we can get to convergence between
the two models.


>> If people really can't stomach ASN.1 code then we could do some other
>> key format. But the problem then becomes having to specify how to
>
> We want to do an rfc4880bis and not an entire new protocol.  Thus any
> ASN.1 encoding is not an option.

For approved algorithms, I really don't care. I will need to implement
the existing
key format in any case.


What I would like to avoid is having to review drafts describing vanity crypto.

The fingerprint is going to need to include some sort of algorithm
identifier key
in the data being hashed to prevent algorithm substitution attacks. So
one option
would be to specify how to encode the algorithms we plan to approve and
recommend and then reserve one code for 'X.509 KeyInfo Blob' just treating
it as an algorithm.

Then when the Russians come looking to get a PGP RFC issued describing
how to use GOST, the NSA come along wanting code points for Suites A, B and C,
Fred comes round with Power One Time Pad, etc. etc. They can be told they
don't need it.

This has the major advantage that there would be no need to shift away from
the existing one byte registries and it would reduce the risk of having them
filled up with junk.

One of the things I would like the IETF to adopt as a general policy
is to have one
Mandatory to Implement algorithm and one backup algorithm that are supported by
all IETF crypto protocols that are in active use and to avoid having
working groups
dragging on for five years after they were really finished as people bikeshed
algorithm choices.