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

341–350 of 376 posts

Re: Gpg.fail

#341

Post by goldsteinq »

Arathorn wrote: post #336
goldsteinq wrote: post #331

Earlier quoted context omitted.

I’m facing it on Element Desktop, but I’ll try to reproduce it on Element Web. I’ve tried to submit logs from Element Desktop, but it says that `/rageshake` (which I was told to do) is not a command. I’m happy to help with debugging this, but I’m not sure how to submit logs from Desktop. Something like this happens basically every time I try to use Matrix though. Messages are not decrypting, or not being delivered, o…

Weird. Encryption these days (in Element Web/Desktop and Element X at least) should be pretty robust - although this whole identity reset thing is a known bug on Element Web/Desktop. You can submit debug logs from Settings: Help & About: Submit Debug Logs, and hopefully that might give a hint on what's going wrong.

No “Submit Debug Logs” there, as far as I can see. Do I need to be on matrix.org homeserver for this to work or something?

https://photos.goldstein.lol/share/OIgowBN4Wmi4zlm8DmDP0s8jH...

Re: Gpg.fail

#342

Post by cykros »

jwr wrote: post #257

It has become fashionable to s*t on GnuPG. I just wish all the crypto experts doing that would point me to an alternative that is functionally equivalent. Something that will encrypt using AES-256 with a passphrase, but also using asymmetric crypto. Oh, and I want my secret keys printable if needed. And I want to store them securely on YubiKeys once generated ( https://github.com/drduh/YubiKey-Guide ). I want to be a…

There's something to be said perhaps for preferring tools that do one of those things, rather than all of those things, and doing them well.

Not to say you can't then make an umbrella interface for interacting with them all as a suite, but perhaps the issue has become that gpg has not appropriately followed the Unix philosophy to begin with.

Not that I've got the solution for you. Just calling out the nature of your demands somewhat being at odds with a key design principle that made Unix and Unix-likes great to begin with.

Re: Gpg.fail

#343

Post by upofadown »

Valodim wrote: post #334
upofadown wrote: post #218

Earlier quoted context omitted.

Here is my take on the OpenPGP standards schism: * https://articles.59.ca/doku.php?id=pgpfan:schism Nothing has improved and everything has gotten worse since I wrote that. Both factions are sleepwalking into an interoperability disaster. Supporting one faction or the other just means you are part of the problem. The users have to resist being made pawns in this pointless war. >Maybe the new formats in RFC 9580 are i…

Here is the short version from someone who took part in this process: while serving as the editor of the draft, Werner did not let anything into the draft that wasn't his own idea. But for his own ideas, there were cases where a new feature was committed to spec master and released in gnupg within the week. He was impossible to work with over many years, to the point that everyone agreed that the only way forward was…

Yes, the OpenPGP standards schism was all about personality conflicts. Those conflicts still came from a fundamental difference of philosophy. Who's idea was it to have Koch lead the most recent attempt at a process? Why was that supposed to make a deadlocked process somehow work?

None of this matters now. Everyone is cheerfully walking into an interoperability disaster that will cause much harm. There isn't any real chance GnuPG will lose this war, it is pretty much infrastructure at this point. But the war will cause a lot of harm to the PGP ecosystem, possibly even to the point that it becomes unusable in practice. This is an actual crisis.

Either faction can stop this. But at this point both factions are completely unreasonable and are worthy of criticism.

Re: Gpg.fail

#344

Post by upofadown »

some_furry wrote: post #319
upofadown wrote: post #291

Earlier quoted context omitted.

They were attacking an entire community. Perhaps I should have complained about being deliberately provocative. But to the point, how long should something like a key fingerprint be?

> 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?

Re: Gpg.fail

#345

Post by upofadown »

amluto wrote: post #327
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…

> attacker advantage of less than 2^-64 Why so high? Computers are fast and massively parallel these days. If a cryptosystem fully relies on fingerprints, a second preimage of someone’s fingerprint where the attacker knows the private key for the second preimage (or it’s a cleverly corrupt key pair) catastrophically breaks security for the victim. Let’s make this astronomically unlikely even in the multiple potential…

>And it’s not like 256 bit hashes are expensive.

A key fingerprint is a usability feature. It has no other purpose. Otherwise we would just use the public key. Key fingerprints have to be kept as short as possible. So the question is, how short can that be? I would argue that 256 bit key fingerprints are not really usable.

Signal messenger is using 100 bits for their key fingerprint. They combine two to make a 60 digit decimal number. Increasing that to 256 x 2 bits would mean that they would end up with 154 decimal digits. That would be completely unusable.

Re: Gpg.fail

#346

Post by upofadown »

amluto wrote: post #320
upofadown wrote: post #244

Earlier quoted context omitted.

>The fact that it’s short enough that I even need to think about whether it’s a problem is, frankly, pathetic. Please resist the temptation to personally attack others. I think you mean that 64 bits of hash output could be trivially collided using, say, Pollard's rho method. But it turns out that simple collisions are not an issue for such hashes used as identities. The fact that PGP successfully used 32 bits (16 bit…

> I think you mean that 64 bits of hash output could be trivially collided using, say, Pollard's rho method. But it turns out that simple collisions are not an issue for such hashes used as identities. No. I mean that 64 bits can probably be inexpensively attacked to produce first or second preimages. It would be nice if a decentralized crypto system had memorable key identifiers and remained secure, but I think that…

>I mean that 64 bits can probably be inexpensively attacked to produce first or second preimages.

Keep in mind that you would have to generate a valid keypair, or something that could be made into a valid keypair for each iteration. That fact is why PGP got along with 32 bit key IDs for so long. PGP would still be using 32 bit key IDs if it wasn't that someone figured out how to mess with RSA exponents to greatly speed up the process. Ironically, the method with the slowest keypair generation became the limiting factor.

It isn't like this is a new problem. People have been designing and using key fingerprint schemes for over a quarter of a century now.

>$ better_gpg decrypt_and_auth --sender_pubkey [KEY] --recipient_privkey [KEY]

How do you know that the recipient key actually belongs to the recipient? How does the recipient know that the sender key actually belongs to you (so it will validate correctly)?

Re: Gpg.fail

#347

Post by Valodim »

upofadown wrote: post #343
Valodim wrote: post #334

Earlier quoted context omitted.

Here is the short version from someone who took part in this process: while serving as the editor of the draft, Werner did not let anything into the draft that wasn't his own idea. But for his own ideas, there were cases where a new feature was committed to spec master and released in gnupg within the week. He was impossible to work with over many years, to the point that everyone agreed that the only way forward was…

Yes, the OpenPGP standards schism was all about personality conflicts. Those conflicts still came from a fundamental difference of philosophy. Who's idea was it to have Koch lead the most recent attempt at a process? Why was that supposed to make a deadlocked process somehow work? None of this matters now. Everyone is cheerfully walking into an interoperability disaster that will cause much harm. There isn't any real…

Sorry, but no. This is not a 50/50 situation where a bonkers position is inexplicably backed by half the populace. There is one faction that is a single person on a large lever, and another who are everybody else. Werner made it clear he will accept nothing less than an unquestioning BDFL hierarchy, but has over many years demonstrated no competence to actually fill that role (TFA being a small example of this).

Re: Gpg.fail

#348

Post by antonvs »

oefrha wrote: post #33

Okay, since there’s so much stuff to digest here and apparently there are issues designated as wontfix by GnuPG maintainers, can someone more in the loop tell us whether using gpg signatures on git commits/tags is vulnerable? And is there any better alternative going forward? Like is signing with SSH keys considered more secure now? I certainly want to get rid of gpg from my life if I can, but I also need to make sur…

I haven't gone through the list in detail, but I don't see anything there that implies the ability to forge a valid signature without the private key, which is what matters most for git commits.

Most of the entries have to do with ways to compromise the unencrypted text presented to the user, so that the displayed message doesn't match the signed message. This allows for multiple different kinds of exploit.

But in the git commit case the main thing we care about, for commits authored by anyone whose signature we trust, is that the actual commit matches the signature, and git itself enforces that.

Of course, it's possible that a malicious user could construct a commit that expands to something misleading (with or without GPG). But that comes back to the point of signatures in the first place - if your repo allows random anonymous people to push signed commits, then you might have an issue.

Re: Gpg.fail

#349

Post by baobun »

jwr wrote: post #257

It has become fashionable to s*t on GnuPG. I just wish all the crypto experts doing that would point me to an alternative that is functionally equivalent. Something that will encrypt using AES-256 with a passphrase, but also using asymmetric crypto. Oh, and I want my secret keys printable if needed. And I want to store them securely on YubiKeys once generated ( https://github.com/drduh/YubiKey-Guide ). I want to be a…

If you haven't checked out sequoia (sq), you should! I think it ticks your boxes.

https://book.sequoia-pgp.org/about_sequoia.html

Post reply on HN