5 ms·

How the comparison is supposed to be displayed: +-----[first]-----+ +-----[second]----+ | .=o. . | | ..=o . | | . +. o |

by Luc 5y ago

How the comparison is supposed to be displayed: +-----[first]-----+ +-----[second]----+ | .=o. . | | ..=o . | | . *+*. o | | o 0+.. o | | =.*..o | | X.o. o | | o + .. | | . * . . | | S o. | | S o . | | o . | | o . | | . . . | | . ..| | o .| | .o| | E.| | Eo| +-----------------+ +-----------------+ That's way too much alike IMHO. A more chaotic algorithm would create images that differ more substantially.

whoomp12342 5y ago
it might be, but its much easier to spot a difference for a technical eye.
- Luc 5y ago
  Ideally you'd want spot a change without comparing them side by side, I think.
reificator 5y ago
Interested mobile users: Please rotate your screen to see "How the comparison is supposed to be displayed" Interested HN mods: Yet another request for horizontally scrolling code blocks instead of line wrapping.
- Luc 5y ago
  Is this better? +-----[first]-----+ | .=o. . | | . *+*. o | | =.*..o | | o + .. | | S o. | | o . | | . . . | | o .| | E.| +-----------------+ +-----[second]----+ | ..=o . | | o 0+.. o | | X.o. o | | . * . . | | S o . | | o . | | . ..| | .o| | Eo| +-----------------+
- syrrim 5y ago
  >yet another request I believe it used to work this way, but they changed it after people complained. Go figure
olejorgenb 5y ago
A fun trick is to cross the eyes so the differences become obvious - a bit easier with more space between them: +---[ 1 ]---+ +---[ 2 ]---+ | .=o. . | | ..=o . | | . *+*. o | | o 0+.. o | | =.*..o | | X.o. o | | o + .. | | . * . . | | S o. | | S o . | | o . | | o . | | . . . | | . ..| | o .| | .o| | E.| | Eo| +-----------------+ +-----------------+
jfrunyon 5y ago
The chaotic algorithm is meant to be the hash, not the art-ification. So of course if you take two very similar hashes they will appear very similar.
- deleted 5y ago
  [deleted]
- progbits 5y ago
  Doing an extra round of hashing wouldn't hurt though, right? Either the hashes are very different and you can already tell from them (but the art will also be different) or they are very similar (someone trying to sneak a close-enough hash by you) and then the second round of hashing leads to very different art.
  - c3534l 5y ago
    Doing an extra round of hashing wouldn't do anything. If they were different before, now they might be the same. If the hashing algorithm is worth its salt (pun intended) then the original hash will be just as random as the hash of the hash, providing nothing of value.
    - fred256 5y ago
      I think it might work if you display both the hash and the image, and ask the user to compare both. If the hashes are very different, it doesn't matter that the images are similar (assuming the user indeed verifies both). If the hashes are similar, another round of hashing before producing the image, might make the images very different. But maybe I misunderstood?
    - yencabulator 5y ago
      The problem is that an attacker can churn out public keys until they end up with a hash that's very similar. Picking a random number and doing a keyed hash of both inputs, then comparing those, would bring out small differences in a way the attacker cannot control.
  - 5y ago

How the comparison is supposed to be displayed: +-----[first]-----+ +-----[second]----+ | .=o. . | | ..=o . | | . *+*. o |

by Luc 5y ago

whoomp12342 5y ago

it might be, but its much easier to spot a difference for a technical eye.

Luc 5y ago
Ideally you'd want spot a change without comparing them side by side, I think.

reificator 5y ago

Interested mobile users: Please rotate your screen to see "How the comparison is supposed to be displayed" Interested HN mods: Yet another request for horizontally scrolling code blocks instead of line wrapping.

Luc 5y ago
Is this better? +-----[first]-----+ | .=o. . | | . *+*. o | | =.*..o | | o + .. | | S o. | | o . | | . . . | | o .| | E.| +-----------------+ +-----[second]----+ | ..=o . | | o 0+.. o | | X.o. o | | . * . . | | S o . | | o . | | . ..| | .o| | Eo| +-----------------+
syrrim 5y ago
>yet another request I believe it used to work this way, but they changed it after people complained. Go figure

olejorgenb 5y ago

A fun trick is to cross the eyes so the differences become obvious - a bit easier with more space between them: +---[ 1 ]---+ +---[ 2 ]---+ | .=o. . | | ..=o . | | . *+*. o | | o 0+.. o | | =.*..o | | X.o. o | | o + .. | | . * . . | | S o. | | S o . | | o . | | o . | | . . . | | . ..| | o .| | .o| | E.| | Eo| +-----------------+ +-----------------+

jfrunyon 5y ago

The chaotic algorithm is meant to be the hash, not the art-ification. So of course if you take two very similar hashes they will appear very similar.

deleted 5y ago
[deleted]
progbits 5y ago
Doing an extra round of hashing wouldn't hurt though, right? Either the hashes are very different and you can already tell from them (but the art will also be different) or they are very similar (someone trying to sneak a close-enough hash by you) and then the second round of hashing leads to very different art.
- c3534l 5y ago
  Doing an extra round of hashing wouldn't do anything. If they were different before, now they might be the same. If the hashing algorithm is worth its salt (pun intended) then the original hash will be just as random as the hash of the hash, providing nothing of value.
  - fred256 5y ago
    I think it might work if you display both the hash and the image, and ask the user to compare both. If the hashes are very different, it doesn't matter that the images are similar (assuming the user indeed verifies both). If the hashes are similar, another round of hashing before producing the image, might make the images very different. But maybe I misunderstood?
  - yencabulator 5y ago
    The problem is that an attacker can churn out public keys until they end up with a hash that's very similar. Picking a random number and doing a keyed hash of both inputs, then comparing those, would bring out small differences in a way the attacker cannot control.
- 5y ago