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