ietf-openpgp
[Top] [All Lists]

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

2016-04-09 14:45:40
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

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp