The fact that this works means that comparing keys visually by their artwork is insecure, since it allows you to generate a key pair which looks very similar to a target public key. I guess visual fingerprints might not have enough entropy.
It's enough to find a fingerprint that's visually similar enough. It doesn't have to be exactly the same. That's many orders of magnitude easier than finding an exact match!
It's probably still more secure than trying to compare the regular old string representations (who checks more than the last 5 characters from the end?)
And plus, you still have to brute force it to get one that looks close
> Once visualization is introduced, so is aesthetics. This feature presents a great opportunity to fight against truly random key generation in order to trade security for arbitrary human desires.
If this person made this tool specifically for the satire opportunity, that's hilarious.
yes, when I tried this some years ago I only could set the first 3 o 4 characters, after that, it took more time I was willing to wait. I don't know how is it today.
I mean, that brute-forceability was a reason for the newer v3 addresses; the v2 ones just weren't long enough.
(As told to me by Alec, they bruteforced the first bit, but found a very coincidentally attractive one for a backronym among the candidates and chose that.)
I guess if you use this, then the security of your key is only as strong as for how many minutes the bruteforce took (since anyone else could also run the tool and generate their own key matching the desired fingerprint in the same amount of minutes you needed - or less).
I don't think the idea is to use the visual representation of the SSH key as a security mechanism but rather to have an SSH key that looks cool when you visualize it.
Isn't the whole point of VisualHostKey in ssh to act as a security mechanism, i.e. "yes this looks like the correct server key" on first use on a new client that doesn't already have the key in known_hosts?
Is the runtime of this application "a number of minutes greater than the heat death of the universe" to find something that could pass off as matching the target visualhostkey?
The fact that this works means that comparing keys visually by their artwork is insecure, since it allows you to generate a key pair which looks very similar to a target public key. I guess visual fingerprints might not have enough entropy.
A very easy way to find such "visual" collisions is described in section 4.2 of our drunken bishop paper: http://www.dirk-loss.de/sshvis/drunken_bishop.pdf
Where's the proof that this works?
It's a brute forcing tool with the goal of finding the desired fingerprint, but there's no demonstration of it actually working.
It's enough to find a fingerprint that's visually similar enough. It doesn't have to be exactly the same. That's many orders of magnitude easier than finding an exact match!
> and kill the artist when patience is depleted.
This is the key part. You probably have to have _a lot_ of patience to get anything reasonable.
It's probably still more secure than trying to compare the regular old string representations (who checks more than the last 5 characters from the end?)
And plus, you still have to brute force it to get one that looks close
> means that comparing keys visually by their artwork is insecure
I'm not sure if this goal is achievable.
Comparing visually wasn't safe in the first place for the same reason, this changes nothing
Here's my key's [1] art:
After 10,000,000 iterations (150 hours CPU time or so), this is the closest I got: [1]: https://github.com/remram44.keys"kill the artist when patience is depleted"
drastic!
> Once visualization is introduced, so is aesthetics. This feature presents a great opportunity to fight against truly random key generation in order to trade security for arbitrary human desires.
If this person made this tool specifically for the satire opportunity, that's hilarious.
I can't believe no one in this thread doesn't see this. This project is a critique of the openssh visual hash
I wish Bitcoin produced at least something like that.
Vanity addresses are a similar idea.
yes, when I tried this some years ago I only could set the first 3 o 4 characters, after that, it took more time I was willing to wait. I don't know how is it today.
You can always artify the qr code.
This is cool as a project, but relying on humans to do pixel-perfect matching for security is probably a bad idea (well, glyph-perfect).
On the other hand - when ssh warns you the host key has changed but the art looks unchanged to your eye, you know something serious has happened.
Yes.
benjojo has an article on this, with another (Golang) implementation: https://blog.benjojo.co.uk/post/ssh-randomart-how-does-it-wo...
Includes example results, as well as an explanation for the randomart algorithm.
And imagine how Facebook got lucky with their .onion address
I mean, that brute-forceability was a reason for the newer v3 addresses; the v2 ones just weren't long enough.
(As told to me by Alec, they bruteforced the first bit, but found a very coincidentally attractive one for a backronym among the candidates and chose that.)
They did the first 8 characters of the v3.
I guess if you use this, then the security of your key is only as strong as for how many minutes the bruteforce took (since anyone else could also run the tool and generate their own key matching the desired fingerprint in the same amount of minutes you needed - or less).
I don't think the idea is to use the visual representation of the SSH key as a security mechanism but rather to have an SSH key that looks cool when you visualize it.
Isn't the whole point of VisualHostKey in ssh to act as a security mechanism, i.e. "yes this looks like the correct server key" on first use on a new client that doesn't already have the key in known_hosts?
That's not how randomness works. The expected duration of the attack is only determined by how close they want to get to your artwork.
For example, if you pick the first key you generate, it obviously doesn't mean the attacker can get the same art in one try.
so the exact same as any other crypto key?
The number of minutes being greater than the heat death of the universe
Is the runtime of this application "a number of minutes greater than the heat death of the universe" to find something that could pass off as matching the target visualhostkey?