ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt]

2019-08-29 23:44:00
On Mon, Aug 26, 2019 at 02:43:15PM -0400, Daniel Kahn Gillmor wrote:
On Mon 2019-08-26 02:19:12 -0500, Benjamin Kaduk wrote:
On Thu, Aug 22, 2019 at 06:01:23PM -0400, Daniel Kahn Gillmor wrote:
Note that this only works if there is a well-established convention
about what digest algorithm to use.  I don't want to keep a SHA256 and a
SHA512 and a blake2b index of all the certifications i know about.  Note
also that SHA256 isn't used here for strong cryptographic purposes --
it's just a hash table indexer.

This sounds an awful lot like (my understanding of) what PHB's UDF [1]
(uniform data fingerprint) is supposed to be.  Sadly, I've not had time
yet to give it a proper read...

[1] https://tools.ietf.org/html/draft-hallambaker-mesh-udf

I don't think that this is the same thing as i'm proposing above -- my
understanding is that PHB's UDF is intended to have some level of
cryptographic resilience -- to collisions at least, and maybe to
pre-images in some contexts.

That's my understanding as well, but with the related property that a
single index will encompass all fingerprint-generating algorithms, which is
what I was focusing on.  It does not really get you the property that if
you have one fingerprint you can look up the entry for the object with that
fingerprint, though (IIUC), since the entry might only be in the index
under a different "name".

Sorry for not thinking it through more,

Ben

In the scheme i've proposed above, the digest is simply used to find a
certification in an index.  It could conceivably be non-unique, even,
since the verification is expected to be done over the full underlying
certification data.  (i.e. it's an index to a non-keyed hashtable)

To avoid malicious attacks against the efficiency of the non-keyed
hashtable (e.g. if we used CRC32, an adversary could flood the user with
certifications that produce identical checksums, reducing them to linear
search), we probably *do* want it to be collision-resistant, but it's
not going to need the same level of cryptographic rigor that we'd need
for a fingerprint, where the fingerprint itself is used to prove
identity of data.

         --dkg


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

<Prev in Thread] Current Thread [Next in Thread>