5 ms·

I don't know why more folks don't display keys and fingerprints as Base64; it seems to me that "q68RxlopcLEwq+PEeb4+QwBBGIY=" (Linus's real key) and "D2oUZTLYaa

by wtbob 10y ago

I don't know why more folks don't display keys and fingerprints as Base64; it seems to me that "q68RxlopcLEwq+PEeb4+QwBBGIY=" (Linus's real key) and "D2oUZTLYaa7kOPdLYhGqOwBBGIY=" (Linus's fake key) are pretty easilt-distinguishable, and not terribly verbose.

eli 10y ago
If everyone did that, couldn't attackers just target collisions that "look like" the target key in Base64? i.e. the same first 5 or 6 chars and the punctuation in the right places.
YPCrumble 10y ago
Is there a reason a hacker couldn't just create a key like "q68RxlopoLEwq+PEeb4+QwBBGIY=" to create a similar problem?
- akerro 10y ago
  The string is longer so collision is harder to find. btw that's a way .onion addresses are generated, it takes first 80 bytes from the key and outputs base32 from the input.
  - CiPHPerCoder 10y ago
    Rather, it takes the first 80 bits of a SHA1 hash of a 1024-bit RSA public key, then converts it to base32. Obviously, collisions aren't obscenely expensive.
_wmd 10y ago
You can do what PGPfone did and encode the fingerprint as a series of dictionary words: Real gregkh: 647F28654894E3BD457199BE38DBBDC8 = style tactful newcomers file gallows adored insist flags athletics Fake gregkh: 497C48CE16B926E93F49630127365DEA = jukebox governor fashionable mahogany prepares gobble surprised martha apostles There's even an Internet standard for this: http://tools.ietf.org/html/rfc1751 http://tools.ietf.org/html/rfc1751 , although its dictionary isn't very large or interesting. Here's another implementation intended for BitTorrent magnet hashes: http://pythonsweetness.tumblr.com/post/56715292510/cheatcodes-turning-bittorrent-links-into-spoken http://pythonsweetness.tumblr.com/post/56715292510/cheatcode... SSH keygen has a mode where the digest is printed as ASCII art, I imagine by using the key as input into something like a fractal function. I can't find the option for it, but I'm sure you've seen it on the console at some point
- zepolen 10y ago
  This is just turning one hash into another, so would be just as easy to brute force.
  - adrianratnapala 10y ago
    The point is to turn one fairly big hash into a representation where humans can easily spot the differences.
    - vesinisa 10y ago
      Pretty sure most of the time people only read the first few and last words and e.g. don't concern if the words in the middle are in correct order. Not sure about the size of that dictionary, but it would seem to greatly diminish the entropy.
      - sp332 10y ago
        It doesn't. The dictionary is exactly the same size as the input data. It's lossless.
      - avisser 10y ago
        It's asking for a solution with more gestalt impact. Turn the key into a painting or some sort of visualization.
        AdamN 10y ago
        Ah, you mean randomart: http://superuser.com/questions/22535/what-is-randomart-produced-by-ssh-keygen http://superuser.com/questions/22535/what-is-randomart-produ...
        thomasahle 10y ago
        It has to be a visualization in which changing a few pixels make it look significantly different. Otherwise we can still make a 'low distance' brute force attack.
forgotpwtomain 10y ago
I've got to say, I think Satoshi picking the Base58[0] subset instead of B64 was a very smart choice for Bitcoin and it would make sense to adopt it elsewhere as well (as far as anywhere that the string needs to be parsed by a human-eye). [0] https://en.wikipedia.org/wiki/Base58 https://en.wikipedia.org/wiki/Base58
lucb1e 10y ago
While it's certainly more easy to tell the difference between two random keys represented in base64, it's probably not that hard to create a similar brute force algorithm that makes the base64 representation look similar. Odds are 1 in 64 to get the first character as lowercase q, 10 in 64 to get digits in the second spot, once more for the third spot, one in 16 to get a + sign close to where the plus sign is right now (so 1/64 for an exact match, 1/32 for one position off to either side, 1/16 for one position off to the left or right), another 1/16 for the second plus, and finally let's match the last three characters so another 1/(64^3). The padding should always be the same I think. After, on average, 27.5 billion attempts you'd have a matching base64 output. It's not as great as a 32-bit integer (2 billion attempts on average) but it's in the same ballpark. This is different from the 32 bit key id because the key id would be an exact match and the "visually similar" base64 string is only similar on first glance, but if you check the base64 carefully you might as well check the fingerprint carefully. This is why it's recommended to check a few random positions when matching cryptographic hashes by the way.
- dilap 10y ago
  It's software, but it seems like some sort of digit-coloring scheme for hashes could make fakes easy to spot by eye. The simplest thing would just be a different color for every character (and and pick very distinct colors for similarly-shpaed characters). Or maybe color groups of 3 digits or something.
  - x1798DE 10y ago
    If you're using software to display both key ids, why not just use software to compare them?
    - vidarh 10y ago
      They may be on different devices, for example. I agree we should use software to compare them whenever possible, but sometimes it is practical to be able to eyeball differences.
mtgx 10y ago
I believe miniLock also does that. Any reason why miniLock can't be used as an alternative to PGP? (for email/file encryption) https://minilock.io/ https://minilock.io/
- SolarNet 10y ago
  Because this isn't just about that. It's about an independently implemented web of trust. PGP has buy in from people like Linus, it has independent implementations, it is distributed, and has a strong web of trust.
gabemart 10y ago
Something I hadn't realised before now is that a PGP fingerprint has the same format as an IPv6 address, so if you just substitute colons for spaces you can display it as a hipku http://hipku.gabrielmartin.net/#0F6A:1465:32D8:69AE:E438:F74B:6211:AA3B http://hipku.gabrielmartin.net/#0F6A:1465:32D8:69AE:E438:F74... > Hipku.encode('0F6A:1465:32D8:69AE:E438:F74B:6211:AA3B'); > Bold grouse and brass ghosts > clamp strict lean sane tart dry whales. > Fresh geese blur rust dice.
- eridius 10y ago
  I hadn't heard of hipku before, it's quite clever. And my current IP produces a nice one. The clever dark lamb prowls in the ancient jungle. Tiger lillies dance.
SloopJon 10y ago
There was a study posted here recently on this very topic: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/dechand https://www.usenix.org/conference/usenixsecurity16/technical... https://news.ycombinator.com/item?id=12272425 https://news.ycombinator.com/item?id=12272425 From the abstract: "The highest attack detection rate and best usability perception is achieved with a sentence-based encoding. If language-based representations are not acceptable, a simple numeric approach still outperforms the hexadecimal representation."

by wtbob 10y ago

eli 10y ago

If everyone did that, couldn't attackers just target collisions that "look like" the target key in Base64? i.e. the same first 5 or 6 chars and the punctuation in the right places.

YPCrumble 10y ago

Is there a reason a hacker couldn't just create a key like "q68RxlopoLEwq+PEeb4+QwBBGIY=" to create a similar problem?

akerro 10y ago
The string is longer so collision is harder to find. btw that's a way .onion addresses are generated, it takes first 80 bytes from the key and outputs base32 from the input.
- CiPHPerCoder 10y ago
  Rather, it takes the first 80 bits of a SHA1 hash of a 1024-bit RSA public key, then converts it to base32. Obviously, collisions aren't obscenely expensive.

_wmd 10y ago

You can do what PGPfone did and encode the fingerprint as a series of dictionary words: Real gregkh: 647F28654894E3BD457199BE38DBBDC8 = style tactful newcomers file gallows adored insist flags athletics Fake gregkh: 497C48CE16B926E93F49630127365DEA = jukebox governor fashionable mahogany prepares gobble surprised martha apostles There's even an Internet standard for this: http://tools.ietf.org/html/rfc1751 http://tools.ietf.org/html/rfc1751 , although its dictionary isn't very large or interesting. Here's another implementation intended for BitTorrent magnet hashes: http://pythonsweetness.tumblr.com/post/56715292510/cheatcodes-turning-bittorrent-links-into-spoken http://pythonsweetness.tumblr.com/post/56715292510/cheatcode... SSH keygen has a mode where the digest is printed as ASCII art, I imagine by using the key as input into something like a fractal function. I can't find the option for it, but I'm sure you've seen it on the console at some point

zepolen 10y ago
This is just turning one hash into another, so would be just as easy to brute force.
- adrianratnapala 10y ago
  The point is to turn one fairly big hash into a representation where humans can easily spot the differences.
  - vesinisa 10y ago
    Pretty sure most of the time people only read the first few and last words and e.g. don't concern if the words in the middle are in correct order. Not sure about the size of that dictionary, but it would seem to greatly diminish the entropy.
    - sp332 10y ago
      It doesn't. The dictionary is exactly the same size as the input data. It's lossless.
    - avisser 10y ago
      It's asking for a solution with more gestalt impact. Turn the key into a painting or some sort of visualization.
      - AdamN 10y ago
        Ah, you mean randomart: http://superuser.com/questions/22535/what-is-randomart-produced-by-ssh-keygen http://superuser.com/questions/22535/what-is-randomart-produ...
      - thomasahle 10y ago
        It has to be a visualization in which changing a few pixels make it look significantly different. Otherwise we can still make a 'low distance' brute force attack.

forgotpwtomain 10y ago

I've got to say, I think Satoshi picking the Base58[0] subset instead of B64 was a very smart choice for Bitcoin and it would make sense to adopt it elsewhere as well (as far as anywhere that the string needs to be parsed by a human-eye). [0] https://en.wikipedia.org/wiki/Base58 https://en.wikipedia.org/wiki/Base58

lucb1e 10y ago

While it's certainly more easy to tell the difference between two random keys represented in base64, it's probably not that hard to create a similar brute force algorithm that makes the base64 representation look similar. Odds are 1 in 64 to get the first character as lowercase q, 10 in 64 to get digits in the second spot, once more for the third spot, one in 16 to get a + sign close to where the plus sign is right now (so 1/64 for an exact match, 1/32 for one position off to either side, 1/16 for one position off to the left or right), another 1/16 for the second plus, and finally let's match the last three characters so another 1/(64^3). The padding should always be the same I think. After, on average, 27.5 billion attempts you'd have a matching base64 output. It's not as great as a 32-bit integer (2 billion attempts on average) but it's in the same ballpark. This is different from the 32 bit key id because the key id would be an exact match and the "visually similar" base64 string is only similar on first glance, but if you check the base64 carefully you might as well check the fingerprint carefully. This is why it's recommended to check a few random positions when matching cryptographic hashes by the way.

dilap 10y ago
It's software, but it seems like some sort of digit-coloring scheme for hashes could make fakes easy to spot by eye. The simplest thing would just be a different color for every character (and and pick very distinct colors for similarly-shpaed characters). Or maybe color groups of 3 digits or something.
- x1798DE 10y ago
  If you're using software to display both key ids, why not just use software to compare them?
  - vidarh 10y ago
    They may be on different devices, for example. I agree we should use software to compare them whenever possible, but sometimes it is practical to be able to eyeball differences.

mtgx 10y ago

I believe miniLock also does that. Any reason why miniLock can't be used as an alternative to PGP? (for email/file encryption) https://minilock.io/ https://minilock.io/

SolarNet 10y ago
Because this isn't just about that. It's about an independently implemented web of trust. PGP has buy in from people like Linus, it has independent implementations, it is distributed, and has a strong web of trust.

gabemart 10y ago

Something I hadn't realised before now is that a PGP fingerprint has the same format as an IPv6 address, so if you just substitute colons for spaces you can display it as a hipku http://hipku.gabrielmartin.net/#0F6A:1465:32D8:69AE:E438:F74B:6211:AA3B http://hipku.gabrielmartin.net/#0F6A:1465:32D8:69AE:E438:F74... > Hipku.encode('0F6A:1465:32D8:69AE:E438:F74B:6211:AA3B'); > Bold grouse and brass ghosts > clamp strict lean sane tart dry whales. > Fresh geese blur rust dice.

eridius 10y ago
I hadn't heard of hipku before, it's quite clever. And my current IP produces a nice one. The clever dark lamb prowls in the ancient jungle. Tiger lillies dance.

SloopJon 10y ago

There was a study posted here recently on this very topic: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/dechand https://www.usenix.org/conference/usenixsecurity16/technical... https://news.ycombinator.com/item?id=12272425 https://news.ycombinator.com/item?id=12272425 From the abstract: "The highest attack detection rate and best usability perception is achieved with a sentence-based encoding. If language-based representations are not acceptable, a simple numeric approach still outperforms the hexadecimal representation."