[wtbob]

I don't know why more folks don't display keys and fingerprints as Base64; it seems to me that "q68RxlopcLEwq+PEeb4+QwBBGIY=" (Linus's real key) and "D2oUZTLYaa7kOPdLYhGqOwBBGIY=" (Linus's fake key) are pretty easilt-distinguishable, and not terribly verbose.

[_wmd]

You can do what PGPfone did and encode the fingerprint as a series of dictionary words:

Real gregkh: 647F28654894E3BD457199BE38DBBDC8 = style tactful newcomers file gallows adored insist flags athletics

Fake gregkh: 497C48CE16B926E93F49630127365DEA = jukebox governor fashionable mahogany prepares gobble surprised martha apostles

There's even an Internet standard for this: http://tools.ietf.org/html/rfc1751 , although its dictionary isn't very large or interesting. Here's another implementation intended for BitTorrent magnet hashes: http://pythonsweetness.tumblr.com/post/56715292510/cheatcode...

SSH keygen has a mode where the digest is printed as ASCII art, I imagine by using the key as input into something like a fractal function. I can't find the option for it, but I'm sure you've seen it on the console at some point

[cooper12]

Regarding the SSH randomart, it's enabled by adding `VisualHostKey=yes` to your ssh config or adding the flag `-o VisualHostKey=yes` on the command line. It was announced with OpenSSH 5.1 (http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-Jul...) and there's also a paper on it (http://www.dirk-loss.de/sshvis/drunken_bishop.pdf). You can find the code/comments in `key.c` under `key_fingerprint_randomart()`. (http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/key...)

[mangodrunk]

Sure, but what is the point of that? It's not as if I would remember all the different images. And it checks with the previous one, so what's the purpose (genuinely asking, as it looks pretty cool).

[dijit]

It's for people to recognise differences in art, between runs.

[lmm]

The idea is that you may not "remember" it but you'd subconsciously notice if the image was different. I'm not sure it's any better than a hex key in that regard - either way people usually just go "yes" the first time they connect - but I can imagine it might be easier for some people to notice.

[zepolen]

This is just turning one hash into another, so would be just as easy to brute force.

[adrianratnapala]

The point is to turn one fairly big hash into a representation where humans can easily spot the differences.

[vesinisa]

Pretty sure most of the time people only read the first few and last words and e.g. don't concern if the words in the middle are in correct order. Not sure about the size of that dictionary, but it would seem to greatly diminish the entropy.

[sp332]

It doesn't. The dictionary is exactly the same size as the input data. It's lossless.

[avisser]

It's asking for a solution with more gestalt impact. Turn the key into a painting or some sort of visualization.

[AdamN]

Ah, you mean randomart:

http://superuser.com/questions/22535/what-is-randomart-produ...

[adrianratnapala]

Whether it is vision or words, the point is to enlist some of our primal, automatic brain machinery. Both the random word lists and randomart are a good start, but far from perfect.

The word lists ignore and even foil, our gramatical machinery. And I at least have never been able to remember what my own randomart SSH key fingerprint looked like. Adding colour might be a good start.

[thomasahle]

It has to be a visualization in which changing a few pixels make it look significantly different. Otherwise we can still make a 'low distance' brute force attack.

[rrobukef]

It depends on how valuable the identity is. I check some characters, for additional security I check some in the middle until I am satisfied with security. The downside is security creep, but verified identities generally grow more secure the older they are (does this grow faster?).

The upside to showing a larger hash is that humans are very good at roughly comparing two things. The difference in casing is probably enough to trigger a conscious check. A visual hash is still better.

[crottypeter]

The correct way to compare hashes is to let the computer do it.

i.e. Ctrl + C, Ctrl + F, Ctrl + V

"oh look it didn't find it ... they don't match", versus, "yup all 64/128/2048/n digits match, the hashes are the same".

[kccqzy]

We still need to define a hash format. Typical hex/base64 would work, but imagine someone tries to be smart and invent a dictionary word encoding with Unicode characters, and then someone brute forces another key that's actually different but will match a search with smart Unicode collation algorithms.

[torrent-of-ions]

When is it sensible for a human to inspect the fingerprint anyway?

[acdha]

Other than the business cards people keep mentioning, PGPfone wasn't a typo but rather a voice communications package, where it's very reasonable to think that you might bootstrap a secure conversation by reading someone your key fingerprint over a phone. Prior to the NSA reveal, the threat model I most heard for this was someone doing business in China or Russia where there have perennially been allegations that the intelligence agencies help large businesses, where blocking a passive wiretap is a success.

[forgotpwtomain]

I've got to say, I think Satoshi picking the Base58[0] subset instead of B64 was a very smart choice for Bitcoin and it would make sense to adopt it elsewhere as well (as far as anywhere that the string needs to be parsed by a human-eye).

[0] https://en.wikipedia.org/wiki/Base58

[gabemart]

Something I hadn't realised before now is that a PGP fingerprint has the same format as an IPv6 address, so if you just substitute colons for spaces you can display it as a hipku

http://hipku.gabrielmartin.net/#0F6A:1465:32D8:69AE:E438:F74...

    > Hipku.encode('0F6A:1465:32D8:69AE:E438:F74B:6211:AA3B');

    > Bold grouse and brass ghosts
    > clamp strict lean sane tart dry whales.
    > Fresh geese blur rust dice.

[eridius]

I hadn't heard of hipku before, it's quite clever. And my current IP produces a nice one.

  The clever dark lamb
  prowls in the ancient jungle.
  Tiger lillies dance.

[lucb1e]

While it's certainly more easy to tell the difference between two random keys represented in base64, it's probably not that hard to create a similar brute force algorithm that makes the base64 representation look similar.

Odds are 1 in 64 to get the first character as lowercase q, 10 in 64 to get digits in the second spot, once more for the third spot, one in 16 to get a + sign close to where the plus sign is right now (so 1/64 for an exact match, 1/32 for one position off to either side, 1/16 for one position off to the left or right), another 1/16 for the second plus, and finally let's match the last three characters so another 1/(64^3). The padding should always be the same I think.

After, on average, 27.5 billion attempts you'd have a matching base64 output. It's not as great as a 32-bit integer (2 billion attempts on average) but it's in the same ballpark.

This is different from the 32 bit key id because the key id would be an exact match and the "visually similar" base64 string is only similar on first glance, but if you check the base64 carefully you might as well check the fingerprint carefully.

This is why it's recommended to check a few random positions when matching cryptographic hashes by the way.

[dilap]

It's software, but it seems like some sort of digit-coloring scheme for hashes could make fakes easy to spot by eye. The simplest thing would just be a different color for every character (and and pick very distinct colors for similarly-shpaed characters). Or maybe color groups of 3 digits or something.

[x1798DE]

If you're using software to display both key ids, why not just use software to compare them?

[vidarh]

They may be on different devices, for example. I agree we should use software to compare them whenever possible, but sometimes it is practical to be able to eyeball differences.

[eli]

If everyone did that, couldn't attackers just target collisions that "look like" the target key in Base64? i.e. the same first 5 or 6 chars and the punctuation in the right places.

[SloopJon]

There was a study posted here recently on this very topic:

https://www.usenix.org/conference/usenixsecurity16/technical...

https://news.ycombinator.com/item?id=12272425

From the abstract:

"The highest attack detection rate and best usability perception is achieved with a sentence-based encoding. If language-based representations are not acceptable, a simple numeric approach still outperforms the hexadecimal representation."

[mtgx]

I believe miniLock also does that. Any reason why miniLock can't be used as an alternative to PGP? (for email/file encryption)

https://minilock.io/

[SolarNet]

Because this isn't just about that. It's about an independently implemented web of trust. PGP has buy in from people like Linus, it has independent implementations, it is distributed, and has a strong web of trust.

[YPCrumble]

Is there a reason a hacker couldn't just create a key like "q68RxlopoLEwq+PEeb4+QwBBGIY=" to create a similar problem?

[akerro]

The string is longer so collision is harder to find. btw that's a way .onion addresses are generated, it takes first 80 bytes from the key and outputs base32 from the input.

[CiPHPerCoder]

Rather, it takes the first 80 bits of a SHA1 hash of a 1024-bit RSA public key, then converts it to base32.

Obviously, collisions aren't obscenely expensive.