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

161–170 of 376 posts

Re: Gpg.fail

#161

Post by akerl_ »

johnisgood wrote: post #153
akerl_ wrote: post #144

Earlier quoted context omitted.

I gave you the answer that exists: I'm not aware of any existing or likely-to-exist secure messaging solution that would be a viable recommendation. The available open-source options come nowhere close to the messaging security that Signal/Whatsapp provide. So you're left with either "find a way to access Signal after they pull out of whatever region has criminalized them operating with a backdoor on comms" or "pick…

> messaging security > WhatsApp Eh? There are alternatives, try Ricochet (Refresh) or Cwtch.

I stand by what I said.

Re: Gpg.fail

#162

Post by akerl_ »

anonym29 wrote: post #154
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.

Could you please link the source code for the WhatsApp client, so that we can see the cryptographic keys aren't being stored and later uploaded to Meta's servers, completely defeating the entire point of Signal's E2EE implementation and ratchet protocol?

This may shock you, but plenty of cutting-edge application security analysis doesn't start with source code.

There are many reasons, but one of them is that for the overwhelming majority of humans on the planet, their apps aren't being compiled from source on their device. So since you have to account for the fact that the app in the App Store may not be what's in some git repo, you may as well just start with the compiled/distributed app.

Re: Gpg.fail

#163

Post by talideon »

ghickPit wrote: post #141
cpach wrote: post #20

Earlier quoted context omitted.

To be frank, at this point, GPG has been a lost cause for basically decades. People who are serious about security use newer, better tools that replace GPG. But keep in mind, there’s no “one ring to rule them all”.

> To be frank, at this point, GPG has been a lost cause for basically decades. Why do high-profile projects, such as Linux and QEMU, still use GPG for signing pull requests / tags? https://docs.kernel.org/process/maintainer-pgp-guide.html https://www.qemu.org/docs/master/devel/submitting-a-pull-req... Why does Fedora / RPM still rely on GPG keys for verifying packages? This is a staggering ecosystem failure. If GPG h…

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.

Re: Gpg.fail

#164

Post by anonym29 »

akerl_ wrote: post #162
anonym29 wrote: post #154

Earlier quoted context omitted.

Could you please link the source code for the WhatsApp client, so that we can see the cryptographic keys aren't being stored and later uploaded to Meta's servers, completely defeating the entire point of Signal's E2EE implementation and ratchet protocol?

This may shock you, but plenty of cutting-edge application security analysis doesn't start with source code. There are many reasons, but one of them is that for the overwhelming majority of humans on the planet, their apps aren't being compiled from source on their device. So since you have to account for the fact that the app in the App Store may not be what's in some git repo, you may as well just start with the co…

Whether or not other people build from source code has zero relevance to a discussion about the trustworthiness of security promises coming from former PRISM data providers about the closed-source software they distribute. Source availability isn't theater, even when most people never read it, let alone build from it. The existence of surreptitious backdoors and dynamic analysis isn't a knock against source availability.

Signal and WhatsApp do not belong in the same sentence together. One's open source software developed and distributed by a nonprofit foundation with a lengthy history of preserving and advancing accessible, trustworthy, verifiable encrypted calling and messaging going back to TextSecure and RedPhone, the other's a piece of proprietary software developed and distributed by a for-profit corporation whose entire business model is bulk harvesting of user data, with a lengthy history of misleading and manipulating their own users and distributing user data (including message contents) to shady data brokers and intelligence agencies.

To imply these two offer even a semblance of equivalent privacy expectations is misguided, to put it generously.

Re: Gpg.fail

#165

Post by pornel »

rurban wrote: post #19
singpolyma3 wrote: post #15

AFAICT this is GnuPG specific and not OpenPGP related? Since GnuPG has pulled out of standards compliance anyway there are many better options. Sequoia chameleon even has drop in tooling for most workflows.

They presented critical parser flaws in all major PGP implementations, not just GNU PGP, also sequoia, minisign and age. But gpg made the worst impression to us. wontfix

Sequoia is mentioned in only one vulnerability for supporting lines much longer than gpg. gpg silently truncates and discards long base64 lines and sequoia does not. So the vulnerability is in ability to feed more data to sequoia which doesn't have the silent data loss of gpg.

In all other cases they only used sequoia as a tool to build data for demonstrating gpg vulnerabilities.

Re: Gpg.fail

#166

Post by pornel »

akerl_ wrote: post #42
rurban wrote: post #19

Earlier quoted context omitted.

They presented critical parser flaws in all major PGP implementations, not just GNU PGP, also sequoia, minisign and age. But gpg made the worst impression to us. wontfix

Since when are age or minisign PGP implementations?

They're not, but the flaws they found are independent of PGP. Mainly invalid handling of strings in C and allowing untrusted ANSI codes in terminal output.

Re: Gpg.fail

#167

Post by tazjin »

ekjhgkejhgk wrote: post #148

Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license because it's "the default license"? (Yes, I've had someone say this to me, no joke) GnuPG for all its flaws has a copyleft license (GPL3) making it difficult to "embrace extend extinguish". If you replace it with a project that becomes more successful but has a less protective (for…

> Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license

Yeah; I actually used to do that to (use the "default license"), but eventually came to the same realisation and have been moving all my projects to full copyleft.

Re: Gpg.fail

#168

Post by ekjhgkejhgk »

rendaw wrote: post #158
ekjhgkejhgk wrote: post #148

Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license because it's "the default license"? (Yes, I've had someone say this to me, no joke) GnuPG for all its flaws has a copyleft license (GPL3) making it difficult to "embrace extend extinguish". If you replace it with a project that becomes more successful but has a less protective (for…

How would MIT make anyone lose control of it?

The way it works is:

A company adopts some software with a free but not copyleft license. Adopts means they declare "this is good, we will use it".

Developers help develop the software (free of charge) and the company says thank you very much for the free labour.

Company puts that software into everything it does, and pushes it into the infrastructure of everything it does.

Some machines run that software because an individual developer put it there, other machines run that software because a company put it there, some times by exerting some sort of power for it to end up there (for example, economic incentives to vendors, like android).

A some point the company says "you know what, we like this software so much that we're going to fork it, but the fork isn't going to be free or open source. It's going to be just ours, and we're not going to share the improvements we made"

But now that software is already running in a lot of machines.

Then the company says "we're going to tweak the software a bit, so that it's no longer inter-operable with the free version. You have to install our proprietary version, or you're locked out" (out of whatever we're discussing hypothetically. Could be a network, a standard, a protocol, etc).

Developers go "shit, I guess we need to run the proprietary version now. we lost control of it."

This is what happened e.g. with chrome. There's chromium, anyone can build it. But that's not chrome. And chrome is what everybody uses because google has lock-in power. Then google says "oh I'm going to disallow you running the extensions you like, so we can show you more ads". Then they make tweaks to chrome so that websites only get rendered well if they use certain APIs, so now competitors to Chrome are forced to implement those APIs, but those aren't public.

And all of this was initially build by free labour, which google took, by people who thought they were contributing to some commons in a sense.

Copyleft licenses protect against this. Part of the license says: if you use these licenses, and you make changes to the software, you have to share the changes as well, you can't keep them for yourself".

Re: Gpg.fail

#169

Post by ekjhgkejhgk »

tazjin wrote: post #167
ekjhgkejhgk wrote: post #148

Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license because it's "the default license"? (Yes, I've had someone say this to me, no joke) GnuPG for all its flaws has a copyleft license (GPL3) making it difficult to "embrace extend extinguish". If you replace it with a project that becomes more successful but has a less protective (for…

> Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license Yeah; I actually used to do that to (use the "default license"), but eventually came to the same realisation and have been moving all my projects to full copyleft.

Thank you.

Re: Gpg.fail

#170

Post by computerfriend »

palata wrote: post #135
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…

> It survives only because nerds have a parasocial relationship with it. I really would like to replace PGP with the "better" tool, but: * Using my Yubikey for signing (e.g. for git) has a better UX with PGP instead of SSH * I have to use PGP to sign packages I send to Maven Maybe I am a nerd emotionally attached to PGP, but after a year signing with SSH, I went back to PGP and it was so much better...

> better UX with PGP instead of SSH

This might be true of comparing GPG to SSH-via-PIV, but there's a better way with far superior UX: derive an SSH key from a FIDO2 slot on the YubiKey.

Post reply on HN