Re: [openpgp] Should fingerprints be "key-canonical"?

[KellerFuchs <[e-mail]>]

On Wed, Apr 06, 2016 at 04:20:08PM -0300, Bryan Ford wrote:
> Getting back to DKG’s question of whether the Unix creation-timestamp should be included in the octet-stream passed to a (future) OpenPGP fingerprint scheme…  I want to generalize the question into a choice between three options:
> 
> 1. The fingerprint covers *only* the public-key material itself, in a verifiably and enforceably canonical form.
> 2. [...]
> 3. The fingerprint covers the public-key material and some extensible variable-length information, e.g., parameters the key-holder specifies in its self-signed cert at key creation time.
> 
> The advantages I see to approach #1 (fingerprint covers public-key ONLY) are: (a) simplicity in specification and implementation; and (b) there may be security benefits in any public-key having one and only one fingerprint - IF canonical encoding is 100% enforced in current OpenPGP implementations, which may or may not be the case.

Also, as Werner mentioned in an earlier thread, having a 1-to-1 map
  between pubkey and fingerprint makes it much easier to work with
  smartcards (or any other device) that can store the key itself,
  but no associated data (which seem to currently require
  device-specific hacks).

> The advantages I see to approach #3 (fingerprint covers public-key and some extensible information) are that the key’s creator can bind to the key, at creation time, additional information that other parties might subsequently use in checking the validity or revocation status of a key, when importing or checking its fingerprint.
> [...] 
> The general (potential) risk here - although I’m not sure how “real” it is - is that either the key-holder, or someone who manages to steal the key, can tweak the creation-timestamp and/or any other non-canonical bits that the fingerprint depends on, to create a new “public key” with a different fingerprint but the same key material as the old one.
> [...] 
> On the upside of allowing the fingerprint to depend on non-canonical (e.g., creator-provided) information, I understand Phil is going to post a document listing some of the uses for this type of functionality, and I look forward to seeing that.  But just to list a few potential uses I can think of:
> 
> - This information could include a creation-timestamp as a Unix time, as it is now.
> - This information could include a more verifiable analog to a creation-timestamp [...]

A user-chosen timestamp doesn't seem to do much to help check the
  key's validity, and I'm not sure a verifiable timestamp helps
  much either (imagine I put in there an attacker-chosen timestamp,
  and a block which look like a verifiable timestamp, but uses a
  method your client doesn't support).

As an aside, the Bitcoin blockchain could possibly be used as a
  timestamped, append-only log and thus implement your notary
  service (for verifiable time of creation) without using a (list
  of) centraly trusted service(s).

> - The information covered by the fingerprint could include “hardness parameters” that feed into the fingerprint scheme itself, enabling the key creator to obtain a configurable level of protection for the key from fingerprint-mining attacks where an attacker tries to search for other keys with fingerprints that match in the first several digits.  This was discussed at the last IETF meeting, and subsequently on this mailing list thread, so I won’t repeat it at length here: https://www.ietf.org/mail-archive/web/openpgp/current/msg08478.html <https://www.ietf.org/mail-archive/web/openpgp/current/msg08478.html>

If I understand correctly (I didn't see the subject of hashing scheme
  parameters discussed in the thread you linked), it would be about
  having parameters (iteration count, memory usage, ...) as part of
  the description of the prefered hashing scheme.


Again, it's not obvious why it needs to be part of the hashed data,
  assuming the scheme parameters are displayed as part of the hash.

If I can get a human to accept “Argon2(1,8): 0123456789abcdef” in
  place of “Argon2(1000,1000): 1023456689acbdef”, the difficulty
  of generating a key with such a hash [0] doesn't seem to depend
  on whether the parameters 1 and 8 are part of the hashed data.

[0] Not the exact value 0123456789abcdef, but a “close enough” match
    to fool a human.

On the other hand, if the human carefully compares “Argon2(1,8)”
  and “Argon2(1000,1000)”, having the parameters part of the hashed
  data doesn't change anything: I have to find a close enough match
  with the keyholder's “prefered parameters”.

(Note that I'm not suggesting we use Argon for key hashes, but it
 was the first example of a scheme with “hardness parameters” that
 came to mind.  Put PBKDF2 there, or anything else, if it makes you
 happier.)

> - The information covered by the fingerprint could include hash-pointers to blockchain transactions in order to incorporate blockchain-randomness into the fingerprint (see https://eprint.iacr.org/2015/1015.pdf <https://eprint.iacr.org/2015/1015.pdf>), thereby making it extremely expensive, if not effectively impossible, for  an attacker to produce another key with the same or even a similar-looking fingerprint without the attack likely being detected.  Not every OpenPGP implementation would necessarily be expected to know how to actually verify this blockchain-randomness; implementations that don’t support it would just see it as an opaque blob of information that the fingerprint covers but that they otherwise don’t interpret.

Even assuming the “Bitcoin blockchain shared RNG” scheme to be perfect,
  the “random value” is random at the time the key is generated, but
  from the perspective of the attacker it is a known constant that must
  be hashed alongside the data they control. (Worse, the attacker can
  choose any value that was previously output by the “Bitcoin RNG”)

As such, I don't see how that makes it harder to generate a key whose
  fingerprint is similar to any other given key.


Best,

  kf