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

[Benjamin Kaduk <[e-mail]>]

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