The mapping of only one byte to one symbol results in too many symbols in one fingerprint. Using more than 8 bits per symbol would result in something much easier to recognize. The goal should be "staple battery horse" and not "p k b t v r m n z x t c." Was my key "p k t b t v r m n z x t c" or was it "p t k b t v r n m z x t c," who can see the difference?

However another danger is all the emoji that look too similar. It can be too easy to forge one emoji wink instead of another. So it can be not so good an idea in general. But maybe somebody demonstrates the easyness of differentiation or manages to select only the symbols that are visually and cognitively different enough for the "alphabet." Still I suggest significantly more than 256 elements, and significantly different one from another. That's the hardest part.

Knowing minor differences is likely to be unimportant. This really only matters if an attacker is able to generate a key with almost the same fingerprint. AFAIK, there is no way to do this. I do agree though that the string of emoji is still hard to memorize.

Almostness reduces the brute-forcing effort. It's not something to be hand-waved, programming to bruteforce just until it's "good enough" is easy. Once somebody learns that he doesn't have to carefully check the signature he won't check at all. The goal is to have as little to check as reasonable, but to check thoroughly.

Agreed that this reduces the effort, but I'll believe it's easy when I see it :) In any case, I think OpenSSH randomart is likely to be more effective than the emoji approach.

I have been experimenting with a dictionary-based encoding system for this kind of data - https://neftaly.github.io/radixWord/

To prevent a similar-looking-fingerprint attack, you could just re-hash the fingerprint with a secret salt before displaying. I wonder if XOR'ing the fingerprint against a plain hash of itself could also be difficult enough?

It seems you use too small set of words? I can't see the source on this device, but it looks so.

Secret salt would have to be the same everywhere. So it has no sense to think about it. Just a good hash is needed, hard enough not to be brute forced, like scrypt.

You only need ~4k words for 2 bytes-per-word alphanumeric encoding (keyspaceLength^bytesPerWord). There is a "special" dictionary identifier prefix and a padding indicator postfix, however (mostly for dev purposes).

Scrypt would probably be fine, though the addition of a secret salt (wouldn't need entropy, just secrecy) would be much better. On reflection, XOR would be stupid bad :B

For security purposes, it would probably be best to have something that hashes the key and displays it in a more human-parsable format like an identicon for verification. For a terminal, a generated phrase or sentence might be the best way to go; there are some stackoverflow posts about doing just that: https://stackoverflow.com/questions/4683551/generating-a-pse...

For the more general case of analyzing binary data, I could see something like this being useful for other tasks such as visualizing network traffic, or analyzing logs. Basically finding some way to transform the data into an optimal form for human pattern recognition.

There are so much more emojis just in this block, I think it could be squeezed down to at least half as many.

Yeah, at a first glance it looks like this is harder to memorize than some Hex numbers.

I did something similar with colours in the console, but this is much cooler!

My system didn't have the right fonts for this to work, but installing "symbola" seems to have fixed that. The package is called "ttf-symbola" on Arch.

Unicode is fun to play with. I found a trick the other day in Racket to squeeze text using ligature codes into fewer visible characters; really handy for tweet-sized code golfing.

need some variant of robohash for SSH fingerprints.

Neat! Melons and spruces!

This almost triggers my Stack Overflow-honed reflexes to go on a huge rant about the fact that there are no "hex bytes" anywhere in your computer. But I guess the OP's author really does know that, and is just being colloqial.

Still, it seems to create a lot of confusion among beginning programmers, so it's a somewhat unfortunate way of expressing things, in my opinion.

It's meant as a shorthand for "hex-encoded bytes".

You're really just interpreting bytes as characters in a different character set. "Visualizing hex bytes" suggests something slightly different, like using an emoji for each of the digits 0-9 and A-F (not much unlike the other proposals for writing hex digits, e.g. http://en.wikipedia.org/wiki/File:Bruce_Martin_hexadecimal_n... .)

What you believe "hex bytes" suggest to you (but falsely) are actually "nibbles"

http://en.m.wikipedia.org/wiki/Nibble

I'm confused. What you mean is that all bytes are hex bytes if you choose to look at them in hex, right?

No bytes are hex bytes. Bytes are bytes. You can display them however you like, even one byte as one emoji (what I argue to be too inconvenient representation in another message). But they are also not "emoji bytes." They are just bytes. As in "octets of bits," bit being a unit of information. And hystorically, the bytes weren't even necessarily octets, but some other group of bits.

This is semantics. For the record: I know what a byte is, and I am fully aware that numbers exist independently of any representation.

The tools for twiddling the bits of hex bytes are not always as readily available as those for Phillips or flathead bytes. Torx bytes are rarer still, and should be avoided.