wip: "imprint" fn

[hko-s]

This is just a sketch for discussion.

We could consider having an "imprint" function roughly like this, and implementing "fingerprint" in terms of it.
I think the cost of that would mainly be that the Hasher is Boxed in this more generic approach?

[link2xt]

Implmenting fingerprints in terms of imprint is good for test coverage, so we can be sure imprints always contain the same data as fingerprints. I don't think a Box is a problem.

[hko-s]

I've pushed a commit to see how fingerprint looks when based on imprint

[hko-s]

It's a bit sad how much expecting is currently going on in this PR. I think it would be possible to make imprint nicer by linking the hash algorithm parameter and returning an array with a corresponding output size.

But it seems that neither the rustcrypto types nor the current rpgp hashing mechanism have suitable facilities for this. We could make them for this PR?

[link2xt]

But it seems that neither the rustcrypto types nor the current rpgp hashing mechanism have suitable facilities for this. We could make them for this PR?

Is it going to use generic-array? We already have generic-array dependency and it does not need to appear in the public API unless we expose the imprint function with a generic hash algorithm.

[hko-s]

Is it going to use generic-array? We already have generic-array dependency and it does not need to appear in the public API unless we expose the imprint function with a generic hash algorithm.

I didn't have a concrete idea, but making this nicer on the type-level would seem potentially worthwhile.

Hoping for @dignifiedquire to weigh in with thoughts/preferences :)

[link2xt]

I'm also fine with .expect(), it's not really going to crash the app. Especially if alternative with generic types and boxes and so on is much uglier.

[hko-s]

Closing in favor of #549