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

241–250 of 376 posts

Re: Gpg.fail

#241

Post by MobiusHorizons »

LtWorf wrote: post #230
MobiusHorizons wrote: post #182

Earlier quoted context omitted.

Seems like the users are voting with their feet, right? Maybe respect the users wishes and stop preaching what users should be wanting?

Users aren't voting. A few people who work at some huge corporations are making these decisions.

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.

Re: Gpg.fail

#242

Post by signed-log »

jhgb wrote: post #143
akerl_ wrote: post #136

Earlier quoted context omitted.

There's no future-proof suggestion that's immune to the government declaring it a crime. If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.

Nobody decided that it's a crime, and it's unlikely to happen. Question is, what do you do with mandatory snooping of centralized proprietary services that renders them functionally useless aside from "just live with it". I was hoping for actual advice rather than a snarky non-response, yet here we are.

Most countries will throw you in jail for years if you refuse to give the password to encrypted devices they want. [1]

And that's even if you are innocent on the underlying charge or search.

Encryption in this political climate, is a pick your poison.

- Either you go to jail for years but you know your gov and other actors has no access to your data.

- or you store on remote/proprietary apps, stay free, but your gov or other actors may or may not have access to it.

[1]: https://en.wikipedia.org/wiki/Key_disclosure_law

Re: Gpg.fail

#243

Post by tptacek »

benchloftbrunch wrote: post #239
tptacek wrote: post #89

Earlier quoted context omitted.

Everything is better than PGP (not just GPG --- all PGP implementations). The problem with PGP is that it's a Swiss Army Knife. It does too many things. The scissors on a Swiss Army Knife are useful in a pinch if you don't have real scissors, but tailors use real scissors. Whatever it is you're trying to do with encryption, you should use the real tool designed for that task. Different tasks want altogether different…

What is the alternative to PGP for the specific use case of secure email? That doesn't mandate dealing with the X509 certificate bureaucracy?

Don't encrypt email.

https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...

Re: Gpg.fail

#244

Post by upofadown »

amluto wrote: post #231
upofadown wrote: post #215

Earlier quoted context omitted.

>And it wants to identify keys by 32-bit truncated hashes. That's 64 bits these days. >I should really not have to even think about the interaction between decryption and verification. Messaging involves two verifications. One to insure that you are sending the message to who you think you are sending the message. The other to insure that you know who you received a message from. That is an inherent problem. Yes, you…

>> And it wants to identify keys by 32-bit truncated hashes. > That's 64 bits these days. The fact that it’s short enough that I even need to think about whether it’s a problem is, frankly, pathetic. > Messaging involves two verifications. One to insure that you are sending the message to who you think you are sending the message. The other to insure that you know who you received a message from. That is an inherent…

>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 bits of effort for a collision) for so long is actually a great example of the principle.

>...encrypt-then-sign, encrypt-and-sign, sign-then-encrypt...

You mean encrypt-then-MAC here I think.

>...I should not even be able to do them separately even if I want to.

Alas that is not possible. The problem is intrinsic to end to end encrypted messaging. Protocols like PGP combine them into a single key fingerprint so that the user does not have to deal with them separately. You still have to verify the fingerprint for people you are sending to and the fingerprint for the people who send you messages.

Re: Gpg.fail

#245

Post by upofadown »

jcranmer wrote: post #103
upofadown wrote: post #78

Earlier quoted context omitted.

There is some misleading stuff in that article. To save time I made an article to provide my commentary: * https://articles.59.ca/doku.php?id=pgpfan:tpp

Don't you think it's time to update it, given you start by saying that "If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument"? Because you're clearly presenting it as a defense of PGP on a thread from a presentation clearly delineating breaks in it using exactly the kind of complex…

The mechanical analogy is particularly interesting here because at least one of the claimed vulnerabilities involves tricking the victim into decrypting an encrypted message for the attacker and then sending it to them. If someone can be tricked into opening a safe to let the burgler rummage around inside then few would consider that a failure of the safe technology. I mean there is still a problem there but it is a different one.

I think this supports my contention that we spend much too much time quibbling about cryptographic trivialities when it comes to end to end encrypted messaging. We should spend more time on the usability of such systems.

Re: Gpg.fail

#246

Post by lagniappe »

akulbe wrote: post #88
tptacek wrote: post #51

Earlier quoted context omitted.

One of those WONTFIX's is on an insane vulnerability: you can bitflip known plaintext in a PGP message to switch it into handling compression, allowing attackers to instruct GnuPG packet processing to look back to arbitrary positions in the message, all while suppressing the authentication failure message. GPG's position was: they print, in those circumstances, an error of some sort , and that's enough. It's an attac…

Is there a better alternative to GPG?

age https://github.com/FiloSottile/age

Re: Gpg.fail

#247

Post by goldsteinq »

akerl_ wrote: post #136
jhgb wrote: post #134

Earlier quoted context omitted.

> Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based secure messenger. That's a "great" idea considering the recent legal developments in the EU, which OpenPGP, as bad as it is, doesn't suffer from. It would be great if the author updated his advice into something more future-proof.

There's no future-proof suggestion that's immune to the government declaring it a crime. If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.

> If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.

I want secure messaging, not encrypted SMS. I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device. I want not losing my messaging history to not be a paid feature. I want to not depend on a shady crypto company to send a message.

Re: Gpg.fail

#248

Post by arccy »

pabs3 wrote: post #150
arccy wrote: post #55

Earlier quoted context omitted.

ssh or minisign for signing age for file encryption

The gpg.fail page mentions minisign vulns too.

The minisign ones are much weaker though? "just" display of data, one of them not even through minisign itself.

Re: Gpg.fail

#249

Post by some_furry »

goldsteinq wrote: post #247
akerl_ wrote: post #136

Earlier quoted context omitted.

There's no future-proof suggestion that's immune to the government declaring it a crime. If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.

> If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that. I want secure messaging, not encrypted SMS. I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device. I want not losing my messaging history to not be a paid feature. I want to…

> I want secure messaging, not encrypted SMS.

I send long messages via Signal, typed on a desktop computer, all the time. (In fact, I almost exclusively use Signal through my desktop app.)

You don't have to use it like "encrypted SMS"! You're free.

> I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device.

OK. https://signal.org/blog/a-synchronized-start-for-linked-devi...

> I want not losing my messaging history to not be a paid feature.

I genuinely don't understand what you mean here. From https://signal.org/blog/introducing-secure-backups/

"If you do decide to opt in to secure backups, you’ll be able to securely back up all of your text messages and the last 45 days’ worth of media for free."

If you have a metric fuckton of messages, that does cost money, sure, but as they say:

"If you want to back up your media history beyond 45 days, as well as your message history, we also offer a paid subscription plan for US$1.99 per month."

"This is the first time we’ve offered a paid feature. The reason we’re doing this is simple: media requires a lot of storage, and storing and transferring large amounts of data is expensive. As a nonprofit that refuses to collect or sell your data, Signal needs to cover those costs differently than other tech organizations that offer similar products but support themselves by selling ads and monetizing data."

If you want Signal to host the encrypted storage, that costs money. If you don't want to pay Signal money, they provide 45 days of backup for free.

If you want to self-host your own backups (at your own cost), that's easy to do.

https://imgur.com/a/EIfaIee

You can literally set up SyncThing to stream your on-device backups to your NAS, cloud storage, or whatever.

> I want to not depend on a shady crypto company to send a message.

Shady crypto company?

Are you referring to MobileCoin? That feature isn't in the pipeline for sending messages.

I checked! https://soatok.blog/2025/02/18/reviewing-the-cryptography-us...

Post reply on HN