[HN Gopher] What is the point of a public key fingerprint?
___________________________________________________________________
What is the point of a public key fingerprint?
Author : rolph
Score : 42 points
Date : 2023-12-16 18:15 UTC (4 hours ago)
(HTM) web link (www.johndcook.com)
(TXT) w3m dump (www.johndcook.com)
| mark_l_watson wrote:
| Nice write up. I have had two customers who had me install PGP in
| Apple email, which was fairly painless.
|
| Until ProtonMail, which is what I use, using PGP was a great
| option. More people should try to encrypt communication.
| gruez wrote:
| > Nice write up. I have had two customers who had me install
| PGP in Apple email, which was fairly painless.
|
| Mail.app supports PGP? How?
| kstrauser wrote:
| I use to use this plugin: https://gpgtools.org/
| eduction wrote:
| can affirm that gpgtools + mail.app is close to seamless,
| once the keys are already exchanged.
| asimpletune wrote:
| So I guess Apple Mail + Keychain Access is all it takes
| https://support.apple.com/guide/mail/sign-or-encrypt-
| emails-...
|
| Pretty neat!
|
| (Edit: not technically PGP, but PKI)
| rhuru wrote:
| Where I work we often have to exchange keys with partners. Key
| fingerprint is often used as a mechanism to make sure the partner
| really has OUR public key. We email the key first and then
| another known employee is expected to verify the fingerprint on
| phone.
|
| Another approach is to host the keys on a HTTPS endpoint on our
| official domain name and their servers can fetch it
| programmatically and rely on TLS to verify that it is indeed our
| endpoint.
| 0xDEAFBEAD wrote:
| >Another approach is to host the keys on a HTTPS endpoint on
| our official domain name and their servers can fetch it
| programmatically and rely on TLS to verify that it is indeed
| our endpoint.
|
| That's only as secure as the weakest CA in their trust store
| though, right?
| https://en.wikipedia.org/wiki/Certificate_authority#CA_compr...
|
| IMO the best way is to put your key fingerprint on your
| business card and all your promotional materials. Then you just
| have to ensure that an adversary doesn't tamper with those :-)
|
| (Of course, use of additional verification for the sake of
| redundancy is great too)
|
| Spreading your Signal phone number is another approach. There
| was a recent HN thread discussing the merits of GPG vs Signal:
|
| https://news.ycombinator.com/item?id=38557888
|
| https://news.ycombinator.com/item?id=38558231
|
| https://news.ycombinator.com/item?id=38555803
| halJordan wrote:
| No public keys are meant to be public, either yes key will be
| correct or not. This is why (to my knowledge) package
| managers like apt still check http endpoints instead of https
| ones.
| 0xDEAFBEAD wrote:
| >No public keys are meant to be public, either yes key will
| be correct or not.
|
| Yeah but how do you know if the key is correct if you're
| getting it for the first time?
|
| >This is why (to my knowledge) package managers like apt
| still check http endpoints instead of https ones.
|
| Your distro ships with a public key that lets you verify
| package signatures. TLS is redundant because you already
| have that trust anchor which came with the distro. (I would
| suggest using TLS anyway though, to force an attacker to
| break 2 layers of security.)
| groestl wrote:
| And to mitigate sniffing
| Borealid wrote:
| OpenSSH has built-in support for retrieving a key
| fingerprint over DNSSec-secured DNS. It's disabled by
| default.
|
| If you enable it, the first connection to a new host will
| say "matching host key fingerprint found in DNS" if
| DNSSec is operational AND the retrieved key matches.
| naitgacem wrote:
| The first time I got on a telegram call using their Android
| client, the call had a string of 4 emojis and said something
| along the lines of "if you and the other person see the same
| emojis, this call is secure". I thought that was pretty neat!
| jonhohle wrote:
| If you see the same emojis as others, this comment is secure:
| <HN doesn't support emoji>
| CharlesW wrote:
| (+deg#deg)+( +-+
| pndy wrote:
| Matrix clients use similar way to verify login sessions
| csdvrx wrote:
| I don't get it. Can you explain me why it is, and what the
| emojis represent?
|
| Do you have the projection of some binary string in the unicode
| emoji space? (then you'd need to chunk it and possibly use many
| emojis)
| vecter wrote:
| It's just a fingerprint for their chat. It's almost the same
| as a random four-letter code to verify that you're both
| seeing the ame thing.
| stavros wrote:
| This is for calls, not chat. It's probably ZRTP (hash
| commitment) with emojis instead of letters.
| progval wrote:
| I don't know about Telegram, but it is indeed how Matrix does
| it. Here is the encoding they use:
| https://spec.matrix.org/v1.8/client-server-api/#sas-
| method-e...
| csdvrx wrote:
| I read https://spec.matrix.org/v1.8/client-server-api/#sas-
| hkdf-cal...
|
| So is it the representation in emojis of a server
| controlled shared secret?
|
| That'd make 2 clients talking to eachother through the
| server vulnerable to tampering at the server level
| (ex:MITM)
|
| Shouldn't the 2 clients not involve the server for the
| secret? This would require each of them being able to
| access the other public key fingerprint without trusting
| what the server says. But if they see eachother fingerprint
| projected into the unicode emoji space, they would see
| different emojis.
|
| I think I may be missing something obvious. I just don't
| understand this trick.
| bloopernova wrote:
| As far as I know, if the 2 clients talk directly, their
| IP addresses are exposed to each other.
| Arathorn wrote:
| It's not a server controlled secret; it's a MAC of a
| shared secret negotiated via ECDH between the two
| clients. Diffie Hellman ftw. See
| https://www.uhoreg.ca/blog/20190514-1146
| cbm-vic-20 wrote:
| So, 64 symbols. That same amount of information could be
| conveyed with lowercase letters, uppercase letters, digits,
| and two additional symbols, just like Base64. That seems a
| lot more straightforward than trying to interpret what each
| emoji represents. To my old eyes, a lot of the chosen
| animal emojis look really similar. Or take symbol 34 for
| example, listed there as "spanner" (wrench). Unless I zoom
| in pretty far, that one looks like a diagonal line.
| sgjohnson wrote:
| Essentially, the fingerprint.
|
| Emojis take up 32 bits each. So 4 emojis would be 128 bits.
|
| Of course, this doesn't account for all the 4 byte unicode
| combos that don't result in an emoji, but still.
| spencerchubb wrote:
| How would you know what emojis the other person is seeing?
| anamexis wrote:
| By asking them
| 0xDEAFBEAD wrote:
| I think you'd need to do it out of band though, otherwise
| you're vulnerable to MITM? (That's the primary attack this
| is meant to protect against, I think?)
| webappguy wrote:
| OLVID App by the French Government asks users to swap a 4
| digit PIN. App is great for OpSec check it out.
| theamk wrote:
| if this is voice chat, in-band might be good enough.
| There is no technology (yet?) which can real-time
| recognize spoken emoji description like "weird cucumber
| with mouth.. wait I think its an alligator or maybe even
| a crocodile?" and then retroactively replace it with a
| different one while keeping the timing correct.
| tjoff wrote:
| The man in the middle would need to spoof the voice (with
| current microphone+environment etc.) in ~real time,
| probably both parties as well. And with the awareness to
| detect which words to replace in the middle of a normal
| conversation.
|
| With the demos we've seen feels absolutely doable, but
| for now requires quite some effort.
| 0xDEAFBEAD wrote:
| You're talking about an attacker who wants to tamper with
| communication. Eavesdropping is far easier. [I agree
| you'll want deepfakes if you want your MITM eavesdropping
| to handle emoji codes, for mass surveillance at least.]
|
| But even tampering seems pretty easy if the attacker has
| a more modest objective, of having you and your buddy
| each talking to one of the attacker's henchmen using
| voice changers. The emoji verification won't help here --
| each henchman just gives the emoji for their respective
| conversation.
| tjoff wrote:
| Yes the whole point was how you'd have to deal with the
| emojis.
|
| I feel it is implied that the latency is low enough (a
| few 100s of ms) to not impede the conversation, and that
| the parties have talked before and would notice if the
| tone of the conversation was completely different. Or
| maybe I'm misunderstanding.
| 0xDEAFBEAD wrote:
| Yeah that seems right. I guess an attacker could tamper
| with the call early on, say "hey what are your emojis?"
| as soon as the call starts. Deepfaked voices and 2
| henchmen should be sufficient here, no need for real-time
| audio rewriting. Then once the emojis have been verified,
| switch to a pure-eavesdrop MITM.
|
| To defend, could ask to verify emojis at a random point
| in the middle of the call to make the attacker's life
| more difficult. Especially right before discussing
| sensitive information ;-)
|
| Or drip verify over the course of the call, e.g. "what's
| your 3rd emoji?", and listen for signs of an attacker
| cutting in and out.
| drdaeman wrote:
| Depends on your threat analysis. If you're not
| considering an active attacker who has an ability to
| seamlessly fake voice and/or face to be a realistic
| attack scenario (e.g. you're guarding against mass
| surveillance, but not a prepared targeted attack - i.e.
| you don't find it plausible that someone has prepared
| actors - human or machine - with quality deepfakes made
| specially for you and your peer) and you know the other
| party personally, you can verify in-band, relying on
| natural biometrics aka your knowledge of one's voice and
| face. If you do - certainly the verification must be done
| out-of-band.
| throwaway092323 wrote:
| I can't imagine what it would be like to actually have to
| deal with the scenario you described.
| wombatpm wrote:
| There are four emojis. I reveal the first 1, they reveal
| the 2 nd, etc. how many rounds of exchange do you need to
| happen to be safe?
| ghgr wrote:
| I'm not sold on this argument. Why is a 40-char long fingerprint
| better that verifying the last 40 chars of the public key?
| otachack wrote:
| Because of tampering. If an attacker can produce a pair where
| the public key's last 40 chars match the victim's public key
| last 40 chars they effectively have a public key to dish out
| via MITM.
|
| How feasible it is to produce said pair is another story.
| tux3 wrote:
| It doesn't sound too hard to generate an RSA "vanity key", with
| any value you want for some of the bytes.
|
| You can't control _all_ of the bytes, because it still needs to
| have the right structure and for you to have the corresponding
| private key, but 40 bytes of your choosing seems completely
| doable.
|
| And if you can do that, you can impersonate someone else whose
| pubkey has the same 40 bytes. With a hash, any bit difference
| in any part of the key should result in a completely different
| fingerprint (hash collisions being extremely hard to find).
| eadmund wrote:
| Because there is less entropy in 40 characters of public key
| than there is in 40 characters of cryptographic hash of a
| public key.
| brookst wrote:
| Great answer, but why? Doesn't that suggest the public key
| should be suitable for lossless compression to fewer bits?
| smnc wrote:
| Hashing is not compression, it should not be
| reversible/inflatable.
| petra wrote:
| One possible public key is zeroes + public fingerprint. If I
| remember correctly diffie-helman is based on multiplications ,
| so maybe finding the private key is now equivalent to finding
| the private key of a 40 chat public key, which may be doable.
|
| I'm probably wrong on the details here , but there's probably
| some math tricks you could use to more easily find some
| private, public key pairs that end with the fingerprint.
| wiml wrote:
| It's really easy to generate a public RSA key with desired
| patterns in it. The 1992-era PGP did use the last few bytes of
| the public key as the identifier, but later versions moved to
| using a truncated hash (MD5, and later SHA). At some point
| someone generated colliding keys for all the keys in the public
| keyring and uploaded them all, which kinda drove the point
| home.
|
| (I assume that it's harder to generate a public ECDSA key with
| a specific pattern, but elliptic curve stuff didn't become
| common until after hashes were used for key identifiers.)
| gruez wrote:
| >What you'd really like is a cryptographic hash of the public
| key, short enough to conveniently compare, but long enough that
| it would be infeasible for someone to alter the public key in
| such a way as to produce the same hash. And that's exactly what a
| fingerprint is.
|
| This seems overly specific to PGP. x509 (ie. "SSL") certificates
| have fingerprints as well, but they're almost always expressed in
| 128+bit formats, not truncated.
| tptacek wrote:
| X.509 fingerprints cover entire certificates and public keys.
| Neither PGP nor X.509 "truncates" keys.
| gruez wrote:
| Truncating the hash, I mean.
| dixie_land wrote:
| Isn't the main problem to secure the distribution of the key?
|
| > Maybe my site has been hacked and I don't even know it.
|
| How would the fingerprint help in this case? If the fingerprint
| is also hosted on the website.
| ytret wrote:
| I think one can verify the fingerprint by other means, e.g.
| phone
| pengaru wrote:
| `gpg --auto-key-locate` is a thing, except not many actually
| use DANE for key distribution...
|
| https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
| bluedino wrote:
| I always wonder why randomart (or an improved version) never
| seemed to catch on
| upofadown wrote:
| Isn't it much harder to compare a bunch of random characters
| scattered across a mostly blank field than some sort of number?
| denton-scratch wrote:
| I thought it was obvious that a fingerprint allows you to verify
| that you have the correct public key via some alternative
| channel. So I read the article to find out why I was wrong;
| perhaps the article detailed an obscure wetware hole in the
| verification process, or maybe a dramtically better way of
| verifying public keys.
|
| Nope: the article was a straight answer to the question in the
| title. Oh, well: it was short and to the point.
| password4321 wrote:
| You haven't lived until you've manually typed your ed25519 public
| key into your Hyper-V VM authorized_keys because "Type clipboard
| text" still doesn't work out of the box...
| 1vuio0pswjnm7 wrote:
| "If I give you my public key, say I post it on my web site, how
| can you be sure that it's really my key? Maybe my site has been
| hacked and I don't even know it. Or maybe someone tampers with
| the site content between the time it leaves my server and arrives
| at your browser (though TLS is supposed to address that).
|
| We could get on a phone call and I you could read the key back to
| me. The problem with this approach is that keys are long. A
| 4096-bit RSA key, for example, encoded in hexadecimal, is 1024
| characters long."
|
| If trust the "phone" and phone numbers but not the "internet" and
| IP numbers, then why not just use modems to transfer the public
| key.
|
| Is the assumption that it would be impossible for both the
| person's website and his phone to be simultaneously compromised.
| pants2 wrote:
| My favorite solution to this is probably ENS (Ethereum Name
| Service) - you can link your public key to a domain name,
| essentially, and it's extremely verifiable and widely adopted.
___________________________________________________________________
(page generated 2023-12-16 23:00 UTC)