Skip to main content
13 events
when toggle format what by license comment
Apr 26, 2025 at 19:04 history edited Glorfindel CC BY-SA 4.0
added 1 character in body
Apr 25, 2025 at 12:09 comment added Guanyuming He Thank you for your good answer. You are right that I assume we will be very careful to double check each character before typing, although I didn't explicitly mention it in my question (now I have added that), so please be a little kinder to @jpa; I could have added more context.
Apr 25, 2025 at 10:42 comment added mti2935 @dave_thompson_085 That's correct, the verification method that I am suggesting would require the participants to transfer the uncompressed public key (i.e. the X and Y values of the point on the EC curve).
Apr 25, 2025 at 10:32 vote accept Guanyuming He
Apr 25, 2025 at 7:26 comment added Michael Karcher @dave_thompson_085 While PGP keys are/were identified by keyid, they never were meant to be verified by keyid, but by fingerprint. The keyid is a trunctated fingerprint (was 32 bit, nowadays 64 bit), and you were supposed to compare the whole fingerprint since the invention of PGP.
Apr 25, 2025 at 7:24 comment added Ja1024 @jpa: You again make the absurd and completely baseless assumption that the participants will only check a few fingerprint bytes after the meeting. Do you not understand the OP's scenario? There are two people who don't know each other but are willing to meet in person for the sole purpose of exchanging key information. That's obviously an enormous effort. Now you want to tell me it's somehow impossible for those people to spend a few seconds on a complete fingerprint check? Don't be ridiculous.
Apr 25, 2025 at 7:12 comment added jpa @Ja1024 Sure, QR codes is a reasonable option, but that is not in this answer. The claim "even minor manipulations (or bit errors) will result in completely different hashes, making it easy to detect wrong keys" is not true if the attacker spends some effort in picking the false key.
Apr 25, 2025 at 6:41 comment added Ja1024 @jpa: You're ignoring the OP's scenario. Do you really think that two people will first go through all the trouble of doing a physical meeting for the sole purpose of a fingerprint exchange, but then they suddenly become too lazy to actually check the full fingerprints? This sounds absurd. Anyway, if mobile phones are acceptable in the meeting, the participants could scan the keys/fingerprints as QR codes (like in WPA3 SAE-PK).
Apr 25, 2025 at 6:19 comment added jpa Visual comparisons are prone to checking only some of the digits. It the method is known, the attacker can generate random private keys until they hit one that matches a couple of first and last digits.
Apr 25, 2025 at 3:13 comment added Solomon Ucko Another variant on this could be to print both the full key (if reasonably short) and the fingerprint/hash, so that the recipient can type in the key and then double-check it using the fingerprint.
Apr 25, 2025 at 0:38 comment added dave_thompson_085 @mti2935: only using X9 uncompressed form (or hybrid, which AFAIK nobody ever did). X9 compressed, and the only standard form for EdDSA, are dense and errors are likely to produce an apparently-valid wrong value. // PGP uses such a fingerprint as the key's official identification, and for decades (until fairly recent attacks) it was common for someone to give you their keyid (usually truncated to 32bits or 64bits) and store the full key in a server from which you could fetch it by keyid.
Apr 24, 2025 at 21:43 comment added mti2935 +1. OP, In the case of EC public keys - the public key must be a point that lies on the EC curve. A simple way to check for an error in an EC public key is to simply check if it lies on the EC curve. If there was some error during the transfer of the EC public key, then the likelihood of it lying on the EC curve will be infinitesimally small.
Apr 24, 2025 at 17:28 history answered Ja1024 CC BY-SA 4.0