Re: [openpgp] Fingerprints

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

On Fri, Apr 10, 2015 at 10:58 AM, Derek Atkins <[e-mail]> wrote:
> Werner Koch <[e-mail]> writes:
>
>> 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.
>
> I'm with Werner on this one.  There's not a significant difference
> between a version field and an algorithm field.  Either option adds a
> single byte to the data structure, but using a version field requires
> additional lookup map (from fingerprint version # to hash algorithm).
>
> Maybe that's useful to make sure an attacker doesn't use a "bad" hash
> algorithm for a fingerprint?  But I'd rather just use the hash algorithm
> directly.

Well if we are all going to use the same algorithm, having the leading byte
be 8 (SHA-2-256) or 10 (SHA-2-512) versus 0 hardly makes a difference.

In fact I could continue to use 0 for my OID based scheme and achieve
interop :)


The only downside of this approach is that divergence is easier.


> I presume here you are referring to the "printed" fingerprint, and not
> the "internal" fingerprint?  Internally we'd still use the full length,
> right?  Or would we need to somehow know when (and how) to truncate the
> hash?

We would need something to tell us how many bits we should require in
particular circumstances.

So for example, if I am wanting to send you an email, I should probably
require at least 100 bits. If I am deciding whether to accept a request to
connect to my home network from a set top box, 25 bits is probably
sufficient as only one device is likely to be making a request at a time and
a 1 in a million chance of being fooled is probably OK.


>>> 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.
>
> Similarly, I think we should be clear that we're talking about two
> different things here.  Internally (e.g. in a signature packet) it
> should be the binary result, not hex- or base-32 encoded.

Yes, definitely. Base32 is just for display.


>>> * 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.
>>
>>
>>> 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.
>
> I think "how you take the fingerprint of an X509 key block" should be
> out of scope for the OpenPGP WG.  I think that you can (and should)
> write a separate document that does that.

As long as the identifier is reserved in the OpenPGP registry so there is
no risk of ambiguity, that is OK.

I think that where any draft is discussed is really an issue for the AD and
the WG chairs. It might well be simpler for me if it is outside the WG.


>>> 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.
>
> Ditto.  If the goal here is to have the same key material result in the
> same fingerprint regardless of whether it's encoded in OpenPGP or X.509,
> I think the answer is going to be "X.509 people are going to need to
> convert their key material to OpenPGP packet format and feed into the
> hash algorithm".  I see no other way, and frankly any other way is
> madness (for the OpenPGP group).
>
> I'm sure Phill wont like that answer, but I think it's the right answer
> for this (potential) working group.

Phill cares more about the timing of a decision rather than what the
decision is.