Hacker News Reader

Comment by acqq | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com