Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gpg.fail

gpg.fail

Post reply on HN
Print view View original

371–376 of 376 posts

Re: Gpg.fail

#371

Post by talideon »

ghickPit wrote: post #222
talideon wrote: post #163

Earlier quoted context omitted.

Let's not conflate GPG and PGP-in-general. RPM doesn't use GPG, it uses Sequoia PGP. GPG is what GP is referring to as a lost cause. Now, it can be debated whether PGP-in-general is a lost cause too, but that's not what GP is claiming.

> it can be debated whether PGP-in-general is a lost cause too, but that's not what GP is claiming It is though what both the fine article, and tptacek in these comments, are claiming!

But it's not what cpach was writing about, is it?

Also no, the gpg.fail site makes no such claims. Now, tptacek, has said that, but he didn't write the comment you were replying to.

Re: Gpg.fail

#373

Post by sethev »

jwr wrote: post #365
tptacek wrote: post #272

Earlier quoted context omitted.

Ask me a question about a specific realistic problem (ie, not "how do I replicate this behavior of PGP", but rather "how do I solve this real-world problem") and I'll give an answer (or someone else will).

I think I described (though perhaps too briefly or not clearly enough) the very specific realistic problems? I'm somewhat amused that every time this kind of discussion comes up, the answer is "you are holding it wrong". I have a feeling the world of knowledgeable crypto folks is somewhat detached from user reality. If a single tool isn't possible, give me three tools. But if those three tools each require separate s…

I only counted one problem:

> I want to be able to encrypt my backups to multiple recipients.

Presumably this means you want to encrypt the backup once and have multiple decryption keys or something?

The rest of your original comment are constraints around how you want it to work.

Re: Gpg.fail

#374

Post by MobiusHorizons »

LtWorf wrote: post #340
MobiusHorizons wrote: post #241

Earlier quoted context omitted.

Not trying to diminish broader trends in the software landscape, but this thread was talking about big established gnu software (like GPG) and newer rust based alternatives (like sequoia mentioned in the recording). This choice seems fairly unmediated by large corporations. Probably has more to do with the popularity of rust and how well they market, but the license doesn’t seem to matter that much to people.

Uh? So ubuntu replacing gnu coreutils with rust has nothing to do with ubuntu being run by a corporation? And a single developer deciding for the entirety of the debian project just also happened to be a canonical employee by pure chance?

I didn’t realize that particular change came with a license change. Thanks for the context.

Re: Gpg.fail

#375

Post by some_furry »

upofadown wrote: post #344
some_furry wrote: post #319

Earlier quoted context omitted.

> How long should something like a key fingerprint be? At least 128 bits for most threat models. 192+ is preferable for mine. https://soatok.blog/2024/07/01/blowing-out-the-candles-on-th... My threat model assumes you want an attacker advantage of less than 2^-64 after 2^64 keys exist to be fingerprinted in the first place, and your threat model includes collisions. If I remember correctly, cloud providers assess mul…

>...and your threat model includes collisions. OK, to be clear, I am specifically contending that a key fingerprint does not include collisions. My proof is empirical, that no one has come up with an attack on 64 bit PGP key fingerprints. Collisions mean that an attacker can generate two or more messaging identities with the same fingerprint. How would that help them in some way?

https://soatok.blog/2026/01/07/practical-collision-attack-ag...

Q.E.D.

Re: Gpg.fail

#376

Post by upofadown »

some_furry wrote: post #375
upofadown wrote: post #344

Earlier quoted context omitted.

>...and your threat model includes collisions. OK, to be clear, I am specifically contending that a key fingerprint does not include collisions. My proof is empirical, that no one has come up with an attack on 64 bit PGP key fingerprints. Collisions mean that an attacker can generate two or more messaging identities with the same fingerprint. How would that help them in some way?

https://soatok.blog/2026/01/07/practical-collision-attack-ag... Q.E.D.

Sorry that my, perhaps, poor wording caused you to waste your time producing colliding 64 bit PGP key IDs. I should have used the term "threat model". We were discussing how long key fingerprints should be. My point was that even though 64 bit key IDs are trivially collidable there did not seem to be any practical attacks based on that. So you in a sense provided support for my argument. :) So we can skip directly to your proposed attack...

I have to admit that I don't actually understand it. First the attacker gets some kernel devs to sign key1 of the two keys with colliding key IDs. Why? How does that help the attacker? Then I am guessing that the attacker signs some software with key1. Are the signatures important here? Then the attacker signs the malicious software with key2? Key2 isn't signed by any developers so if that was important the attack fails. If it wasn't important then why mention it?

Could you please provide a more detailed description of the attack? It seems to me that the sort of attack you are describing would require some trusted third party to trick. Like a TLS certifying authority for example.

Post reply on HN