The same question goes for how computationally expensive it is to generate a key that kinda-resembles a known key? If you are just eyeballing the key "yeah that looks like Github's key" when the terminal ask you, you might fall for a fake one that merely begins with the same characters.
The neat trick is that it's others of magnitude harder to find a key that kinda-resembles a known key and kinda-resmbles it's randomart, so if both are presented at the same time, you'd be safer.
Reminds me of a slide from one of Peter Gutmann's lectures on PKI and related stuff: a mock up of a title page for a proposed conference paper, titled "Do SSH Fingerprints Increase Security?", with abstract consisting of just "No."
Yes, it follows other slides that describe precisely the attack in TFA, only for traditional SSH fingerprints, and the real world surveys on the "how many users have called or emailed to verify the SSH key fingerprint whenever the key changed?" question (answer: literally zero), so it seems sadly accurate.
I often compare SHA256 sums of software and have to trust my eyes that the two hashes are the same. Most of the time I just look at the first 5 characters, alongside the last five characters, but I don't look at the middle, and I really should.
Some hashes could deliberately look the same but have 2-3 characters different, and I wouldn't know, unless I look at each character individually, but who does that?
It is a bit of effort, but you can make the computer do the verification for you by writing (or generating) a simple text file. Using Perl shasum because I'm on a mac at the moment, but Linux sha256sum works the same:
$ echo hi > some_file
$ shasum -a 256 some_file > check
$ cat check
98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4 some_file
$ shasum -a 256 -c check
some_file: OK
$ echo $?
0
$ echo bye > some_file
$ shasum -a 256 -c check
some_file: FAILED
shasum: WARNING: 1 computed checksum did NOT match
$ echo $?
1
Edit: Oh cool, at least perl's shasum allows reading from stdin so you can even skip the file if you're just copying some check file off the software's website:
$ shasum -a 256 -c - <<EOF
> 98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4 some_file
> EOF
some_file: OK
Any hash calculations using a "read from stdin or a pipe" strategy, in my experience, is fraught with issues caused by an extra newline at the end of the input possibly being there today, and not in later checks, or vice-versa.
When people claim they wrote a prediction at some later date, they always have to document the EXACT command used to avoid this, e.g. `echo "smart prediction" | md5sum`
Sure. The case in question is verifying a hash someone else gave you, so the problem you mention is present regardless of what verification method you're using.
There is one method that might help, the "astronomer's blink": open two editor tabs, paste the expected and the actual hash in either tab, then quickly switch between tabs using the keyboard (eg. Ctrl+PgUp/Dn if your editor supports this). Can also be used for comparing ordered JSON output when in a hurry.
(The term comes from https://en.wikipedia.org/wiki/Blink_comparator and someone wrote about this in a tech context as well, but I forgot where I read it. I'm seeing one search hit with the exact expression, so it could have been something close as well.)
If you are going to take the effort to paste into an editor you might as well paste both hashes into same tab, put the cursor on one and let the ide highlight all occurances. Ctrl-c + Ctrl-f for those with less sophisticated editors.
Heck, most editors even come with a “compare selection with clipboard” option.
Malware that replaces crypto addresses on webpages is already aware of this - they try to generate addresses with similar starting and ending characters since most people aren't checking the whole thing.
It is weird that this doesn't exist. The algorithm is pretty simple and there are libraries for it, but I couldn't find a generic command-line tool that shows one after hashing any file.
This might be a cool contribution to coreutils (which contains the `sha256sum`, `sha1sum`, `md5sum`, ... programs)
It looks like they discussed it on the mailing-list years ago when it was being selected, but nothing since. Maybe they forgot about it? This is strange.
The real argument is that if the keys change, you'll know about it, because OpenSSH will yell very loudly about it.
The random art is intended for _first time_ connections, where OpenSSH has to trust your judgement of the key's legitimacy because it has never connected to that host before.
It's not like it will hurt anything, but turning it on for every connection doesn't make a security difference.
yeah, i guess syncing around your known_hosts file to everyplace you originate an ssh connection from, would make more of a difference. So that way you minimize the making of first-time connections as much as possible.
In my head I've always read that as rando-mart. I have a mental image of a small high-density city street shop with anything you could possibly want to buy including small ascii art images of my ssh keys.
I always understood the option, but seems like a little color would go a LONG way in making them much more usable? I never got around to paying attention to them and I think that's why.
Tangentially related: does any one know any nice libraries/tools to generate images (PNGs or whatever, doesn't need to be terminal compatible, colors even preferred) from hashes?
Maybe they could use something like Chernoff faces (a method in which data is converted into images of a human face on the grounds that people are better at distinguishing faces than other images).
How much of a face would you recognize if it is rendered with ASCII on a console though? Which is probably the default use-case for SSH for 99% of people.
and it turns out it worked! For example, I've started seeing the GitHub fingerprint (above) as something like the Statue of Liberty if it were a cat (don't ask why; that's just how my brain sees it)
I think you should treat it as posting the key itself. In other words, it's probably possible to transform from the randart back to the key (else it wouldn't be unique per key, right?). So for a public key that is intended to be public, yes, it should be fine. For keys which you do not want public, it's probably not a good idea to post it publicly.
It's not even a representation of the public key itself; it's the SHA256 fingerprint of the key. There's no practical way to transform that back into the key -- and, in any case, the server will send that key to any client that connects, so it's not like recovering it from a screenshot accomplishes anything.
I suppose the argument would be that the key search space is reduced. Statistically speaking, you know the weights of certain binary pairs if the image is not evenly distributed. But I'm guessing that it'd only drop the average search space by... two or three powers of two for most keys?
Again: the randomart image is based on a hash of the public key. If you want to know what that key is, all you have to do is ask the server. You don't need to launch a sophisticated, expensive cryptographic attack to obtain it.
Good question. I would assume that with the visualization being defined by the public-key of the server, this cannot be use to reverse-engineer the private key. Also, the linked paper (I just read the summary) does try to attempt this and partially succeeds and talks more about the implication.
What's the point when the server, if it's one you're logging into regularly (or even just more than once), will already be in your known_hosts file? Let the computer do the checking for you.
Showing the random art can help to notice if you connected to the wrong server by accident, e.g. Incorrectly connecting to staging.example.com when you actually wanted to connect to live.example.com
Good question. Perhaps it's useful if you're logging in from many machines/users without populated known_hosts? So if you spin up a new machine and push to Github, you can recognize it visually by its randart which you saw many times before on other machines.
How computationally expensive is it to generate a key with randomart that kinda-resembles a known randomart?
I've always ignored randomart since I always assumed it's easy to get a close-enough "collision".
EDIT: algorithm explained here https://pthree.org/2013/05/30/openssh-keys-and-the-drunken-b...