fingerprint associated public key does not match displayed public key

S.B. sami.badri at gmail.com
Fri Dec 17 17:30:02 CET 2021


> Think of them as two different snapshots of the same
document at different points in time, as various minor edits are made to
it.  But the important bits, the stuff you care about, will be
consistent through revisions so long as the fingerprint remains unchanged.

The document snapshot analogy really helps.

> No, and I'm going to strongly encourage you to stop asking
implementation questions.

I think I'll take that advice.

> What you're calling a "key block" is a certificate, not a key.  A certificate
includes cryptographic keys and metadata about those keys.

I'm getting the picture now.  The pgp key block is really the
certificate.  The certificate holds the key and metadata.

> gpg --import < certificate.asc

So, when dealing with a displayed certificate (what I was calling a
pgp public key block), the only method I thought of was copying and
pasting it onto a txt file.  But the import command doesn't work with
txt.  I was thinking of converting the txt to asc using a conversion
app but then I knew that it can't be that difficult.  If the only
thing you have is the person's certificate, and it's not in an .asc
format, is there any other way of importing it into your key ring?  Or
are all public key imports obtained via asc files?

S.B.

On Fri, Dec 17, 2021 at 4:43 AM Robert J. Hansen <rjh at sixdemonbag.org> wrote:
>
> > That key block did not match the one on his profile. That’s what
> > confused me. But I’m learning (from you guys) that the key blocks
> > don’t necessarily have to match.  So I can assume that:
>
> More accurately, they're very unlikely to match.  The version on his
> site may lack some signatures or user IDs present on the keyserver copy,
> or vice-versa.  Think of them as two different snapshots of the same
> document at different points in time, as various minor edits are made to
> it.  But the important bits, the stuff you care about, will be
> consistent through revisions so long as the fingerprint remains unchanged.
>
> > - the fingerprint is specific for the secret key component of the
> > generated key pair and does not change.
>
> No, and I'm going to strongly encourage you to stop asking
> implementation questions.  You're not ready for them.  For now, learn
> how to use the system, and only then start paying attention to the fine
> detail of how the system is implemented.
>
> But if you insist, see section 12.2 of RFC4880.  "A V4 fingerprint is
> the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet
> packet length, followed by the entire Public-Key packet starting with
> the version field.  The Key ID is the low-order 64 bits of the fingerprint."
>
> > - the pgp public key is, in a way, fluid. It can take many different
> > forms but encrypts specifically for the matching secret key only. The
> > same public key can have different key blocks.
>
> No.  This will probably become easier to understand if we use the
> correct language.  *Keys* are not fluid.  *Certificates* can be.  What
> you're calling a "key block" is a certificate, not a key.  A certificate
> includes cryptographic keys and metadata about those keys.  The keys
> generally don't change (although I can think of pathological cases where
> they do).  The metadata about those keys can change a lot.
>
> Most of the data in a certificate is metadata.
>
> > - I could’ve used the keyserver-obtained public key (retrieved via the
> > fingerprint), or I could’ve used the displayed public key that was
> > given in armor text form.  They are one and the same, even though
> > their revealed text is different.
>
> You could have used it and the odds are quite good it wouldn't have
> mattered in the slightest.
>
> > When you want to give someone your public key, do you normally just
> > give your email, fingerprint, key ID, or the armor form key block?
>
> I use WKS.
>
> > is there a command i could've used to directly import the key using
> > the displayed key block?  I've tried some different ones I found in
> > various places but nothing worked.
>
> gpg --import < certificate.asc



More information about the Gnupg-users mailing list