Live data from Hacker News

Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

lkml.org

91–100 of 131 posts

Re: Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

#91
post #83
post #82

Earlier quoted context omitted.

wait, this looks interesting. Can someone comment on this? Are you supposed to know the fingerprint after you input name and stuff or before? Or is this just modification of data like how you can add email IDs?

You're supposed to confirm the fingerprint with the person. At the time the recommendation was a phone call (if you knew their voice) using the PGP word list - it was felt to be computationally implausible to fake that up in realtime. Or people publish fingerprints on their site etc. Obv. the fingerprint only matters if you want to be sure you are talking to someone specific, in which case you usually have a way to k…

Thanks for taking the time, but seems like you didn't click on the link. When you look at the name of the keyholder of the fingerprint (B9E39278), the User Name of the keyholder is same as the fingerprint of the key. I was asking if the User Name is set after the key is generated or before. Or if one can change user name after key generation. And I think you can, so there's nothing interesting here :)

Re: Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

#92
post #82

Earlier quoted context omitted.

wait, this looks interesting. Can someone comment on this? Are you supposed to know the fingerprint after you input name and stuff or before? Or is this just modification of data like how you can add email IDs?

method 1: Keep generating keys until you have a collision. method 2: What you said, modify the details. A fun way to play/explore all things GPG is to use a javascript library and Chrome's javascript debugger (e.g. https://openpgpjs.org/ )

Yeah I was wondering if method 2 exists. I remember reading about something similar but wasn't sure. Thanks for the link!

Re: Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

#93
post #45
post #42

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…

> 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

Any idea what this will mean for Yubikey users? I've been wanting to set up my Yubikey 4 for GPG for a while, and have been... daunted.

Re: Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

#94
post #42
post #35

Earlier quoted context omitted.

At this point this is INSANE that GnuPG still defaults to short IDs...

It doesn't anymore. With GnuPG 2.1 listing of keys shows the fingerprint.

Worth noting for any Mac users, the version of gpg2 available by default in Homebrew is 2.0.30. If you want 2.1 you can install it from Homebrew/homebrew-versions/gpg21 at the risk of possibly breaking other formula that expect 2.0.

Re: Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

#95
post #7

32 bit seems so obviously bad I'm not sure why we still have it..

The 90s were a different time, that's the only explanation I can come up with. Short key IDs are yet another 90s-crypto wart.

Even in the 90s it seems odd to design a system trivially vulnerable to birthday attacks (with maybe a simplification, but that's how primitives are evaluated: if it fails in a slightly simplified version or environment, it's unfit for service). Now birthday attacks are not exactly applicable to the "how to forge a key with the same short id as that exact person", but with an high number of keys available there may be other ways to ease your attempts to generate collisions, even if that means relaxing your target requirements somehow. Even if there are not, you must be extremely paranoid when designing anything security related: here barely doubling the size of the short id would have mitigated today's problem, but we see that now 64 bits is not even enough. So there has been a fuck-up (with, I agree, a (lack of) security climate in the 90s that might have contributed a lot to that fuck-up), it has enormous consequences right now (given some distro still default their gpg packages to an obsolete version, it seems). We must take what happened and happens right now into account, and learn our lesson: trivial conveniences decreasing security against abstract hole shall be considered an absolute no-go, and something to fix ASAP with absolute priority.

Sadly I do not expect the security approach to change before at least one more people generation, and then to be honest I'm not even sure it will ever change at all if we consider the mean global situation: the approach of far too many people is still "we don't give a fuck, we don't know anything about that, actually we don't even know that we should know something about that, this will just not happen to us, this is only a cost we can skip". Unless they are personally fucked, I don't expect half of that kind of people changing their mind. And then there are now so much software everywhere that I expect that the vast majority are so full of holes this is not even funny, and I expect that the ratio of insecure software will actually increase unless some kind of regulation are put in place -- but then I don't expect regulation to actually be sane and mandate for real security, given that politics want back doors at least every 4 years.

To optimistic people, please consider the following: even in a mainstream IT field, on one of the most used kind of device today, handling personal data all the day, the market leader designed an ecosystem where the OS that most people are actually using is most of the time not patched during most of the lifetime of said devices. If Google can get away with having such insane and shameful approach, why would you expect a random car vendor to have any real security in its embedded software? Obviously it is even worse for gadgets that VC currently think should/will be installed everywhere.

We are heading to security nightmare unless each of you who think security is important wake up and push the hardest they can to improve the situation. Relentlessly.

Re: Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

#97
post #87
post #2

This has also been discovered with the Debian project, as I submitted a while ago [1]. The really scary part is the follow-up [2]: > € gpg --search-key samuel.thibault@gnu.org > ... > (1) Samuel Thibault > 4096 bit RSA key 7D069EE6, created: 2014-06-16 And it has 55 signatures from 55 colliding keys... Edit: even the 64-bit fingerprint is probably insufficient, see [3]. [1] https://lists.debian.org/debian-devel/2016/…

Why is this scary?

Because it removes many obvious tells of a deliberate key collision targeting a specific key, and thus is harder to detect.

For example, pgp.mit.edu and Enigmail would currently output information for both keys that would be almost identical per 2014-08-05, the day evil32 apparently generated the keys. I say "almost" only because they didn't set the correct timestamps, and apparently did not duplicate all UIDs -- but they easily could have.

The diligent PGP user will of course not fall into such a trap, but an inexperienced user easily might, and there are many of them.

Re: Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

#98
post #84
post #63

Hi, Eric here, co-creator of evil32. I posted a brief note on our site about this, but here's a little more detail. I found an old (local) backup of the private keys and used it to generate revocation certificates for each key. Fortunately, there is no way for anyone else to access or regenerate the private keys for this particular clone of the strong set, and I have been very careful with my copy - it is only availa…

> users who want to email someone discover their key by searching the keyserver for that email, then taking the newest key. This is akin to trust-on-first-use, and opts out completely from the web of trust or any kind of external verification Well, yes? What is the alternative, if I want to email someone who exists only in the form of a pseudonymous online identity?

Most of the time there's some at least semi-trusted communication channel. If they have a website, ask them to publish the key or the full fingerprint on their website. If they frequent some IRC channel, ask them on IRC for their key's fingerprint. If they regularly sign their emails you can check mailing lists they participate on to confirm they use the same key there.

If the key is just for their pseudonym, I usually offer to sign the key if they can send me the key through one service of my choice (where their username is public knowledge) and the fingerprint through another (meaning an attacker would have to compromise both accounts I chose). The offer to sign their key often makes people much more willing to jump through hoops, and I get to improve the web of trust.

But for some people I just don't care enough and just add the first best key.

Re: Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

#99
post #88

These keys have always seemed remarkably short. Roughly how many CPU-hours does it take to find a collision?

I'm using ABCDABCD, and from memory it took a couple of hours. The hardest part was picking a 'vanity' short id that wasn't already taken.

Re: Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs

#100
apt package manager uses short-ids with a repository key is not recognised, as well as when you use apt-key to add the key to your keychain.

When using 3rd party repositories, you will often see something like the following, which also uses short-ids:

> apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10

So it makes me wonder if any commonly used repositories (or PPA's) have fake duplicate keys with the same key-id.

Post reply on HN