51–60 of 131 posts
keyid-format long
Earlier quoted context omitted.
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 n…
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.
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.
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.Seems some people are playing havoc with key ids. I got a mail earlier today I couldn't decrypt for unclear reasons. Now I understand why: It seems it was encrypted with a copy of my public key that is on the keyserver colliding with the keyid of my real key. Right now there is a revoked copy of my key there: https://pgp.mit.edu/pks/lookup?search=hanno%40hboeck&op=inde... What's exactly going on here? Other commentor…
> I saw that your clone of the strong set is revoked?
> Someone downloaded our copy of the strong set and uploaded all of the keys to the SKS keyserver network. :( While we took on this project to help prompt GPG to build a more secure ecosystem, this mass clone made the keyservers harder for everyone to use. Of course anyone could use our tools to regenerate their own strong set clone and do this again, but we'd rather our keys not be used that way.
I take that to mean that yes, they continued to be in possession of the private keys.
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.
https://www.usenix.org/conference/usenixsecurity16/technical...
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."
Earlier quoted context omitted.
This is just turning one hash into another, so would be just as easy to brute force.
The point is to turn one fairly big hash into a representation where humans can easily spot the differences.
i.e. Ctrl + C, Ctrl + F, Ctrl + V
"oh look it didn't find it ... they don't match", versus, "yup all 64/128/2048/n digits match, the hashes are the same".
All the fake keys that I've seen mentioned are from the data set at https://evil32.com . It appears a couple of researchers decided, back in 2014, to demonstrate this issue by cloning the entire strong set of the PGP web of trust (not just Linus' key, but basically everyone who uses PGP/GPG for Free Software development - myself included). It would appear that sometime quite recently, someone decided it would be fun…
Earlier quoted context omitted.
It doesn't anymore. With GnuPG 2.1 listing of keys shows the fingerprint.
But for server installations (auto-signing, checking, etc.) you are often directed to GnuPG 1 because "less dependencies". Also "apt install gnupg" / "dnf install gnupg" both give you version 1 on the most recent Ubuntu/Fedora. For desktop usage many prefer GnuPG 2.0, because they fear compatibility issues that the new 2.1 key storage format could have with 3rd party software, and you can't go back (at least this is…
What 3rd party software is using the keystorage mechanisms directly? Do you mean how information is output from GnuPG?
It sounds like the situation you are describing is the keystore, which has changed formats. GnuPG 2.1, as far as I can remember, will oll use the older versions keystore, but you are correct, once you have a 2.1 keystore it can't be used by GnuPG 2.0 and 1.x.
It's a tough call for the GnuPG developers and something distributions should help with. On one hand there is immense pressure to improve GnuPG, on the other hand, you have many actors who kick GnuPG around when it makes any deviation.
I would say defaulting to GnuPG 1.x is a bug and new releases of Linux, Homebrew, etc., should use GnuPG 2.0 at the very least, but better yet, use GnuPG 2.1 which has many of the things that people complain about fixed or in process of being fixed.
Earlier quoted context omitted.
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 , although…
Regarding the SSH randomart, it's enabled by adding `VisualHostKey=yes` to your ssh config or adding the flag `-o VisualHostKey=yes` on the command line. It was announced with OpenSSH 5.1 ( http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-Jul... ) and there's also a paper on it ( http://www.dirk-loss.de/sshvis/drunken_bishop.pdf ). You can find the code/comments in `key.c` under `key_fingerprint_randomart()`.…
Earlier quoted context omitted.
Regarding the SSH randomart, it's enabled by adding `VisualHostKey=yes` to your ssh config or adding the flag `-o VisualHostKey=yes` on the command line. It was announced with OpenSSH 5.1 ( http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-Jul... ) and there's also a paper on it ( http://www.dirk-loss.de/sshvis/drunken_bishop.pdf ). You can find the code/comments in `key.c` under `key_fingerprint_randomart()`.…
Sure, but what is the point of that? It's not as if I would remember all the different images. And it checks with the previous one, so what's the purpose (genuinely asking, as it looks pretty cool).