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

281–290 of 376 posts

Re: Gpg.fail

#281

Post by goldsteinq »

Natanael_L wrote: post #277
goldsteinq wrote: post #247

Earlier quoted context omitted.

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

Then your next best bet is Matrix.org. Not to the same security standard as Signal, but if you don't have a specific threat against you then it's fine.

Pros of Matrix: it actually has a consistent history (in theory); no vendor lock-in. Cons of Matrix: encryption breaks constantly. Right now I’m stuck in a fun loop of endlessly changing recovery keys: https://github.com/element-hq/element-web/issues/31392

Re: Gpg.fail

#282

Post by osiris88 »

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…

I used to develop free software exclusively under GPL or AGPL.

But at some point, for things like, a very small-but-useful library or utility, I had a change of heart. I felt that it's better for the project to use non-copyleft licenses.

I do this as a rule now for projects where the scope is small and the complexity of a total rewrite is not very large for several engineers at a large company.

For small stuff, the consideration is, I want people to use it, period.

When devs look at open source stuff and see MIT / Apache, they know they can use it no questions asked. When they see GPL etc. then they will be able to use it in some cases and not others depending on what they are working on. I don't want to have that friction if it's not that important.

For a lot of stuff I publish, it's really just some small thing that I tried to craft thoughtfully and now I want to give it away and hope that someone else benefits. Sometimes it gets a few million downloads and I get feedback, and I just like that experience. Often whatever the feedback is it helps me make the thing better which benefits my original use case, or I just learn things from the experience.

Often I'm not trying to build a community of developers around that project -- it's too small for that.

I still like the GPL and I have nothing against it. If I started working on something that I anticipated becoming really large somehow, I might try to make it GPL. And I feel great about contributing to large GPL projects.

I just feel like even though I'm friendly to the GPL, it's definitely no longer my default, because I tend to try to publish very small useful units. And somehow I've convinced myself that it's better for the community and for the projects themselves if those kind of things are MIT / Apache / WTFPL or similar.

I hope that makes sense.

I realized that I can be seen as one of those that treats the GPL as weird or not normal, because I don't really use it anymore. But I'm not trying to be an enemy of the GPL or enable embrace-extend-extinguish tactics. It's just that it a very nuanced thing for me I guess nowadays. Your comment caused me to reflect on this.

Re: Gpg.fail

#283

Post by woodruffw »

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…

> I just wish all the crypto experts doing that would point me to an alternative that is functionally equivalent.

The entire point of every single valid criticism of PGP is that you cannot make a single functionally equivalent alternative to PGP. You must use individual tools that are good at specific things, because the "Swiss Army knife" approach to cryptographic tool design has yielded empirically poor outcomes.

If you have an example of how age broke for you, I think its maintainers would be very interested in hearing that -- I've been using it directly and indirectly for 5+ years and haven't had any compatibility or runtime issues with it, including when sharing encrypted files across different implementations of age.

Re: Gpg.fail

#284

Post by woodruffw »

jmclnx wrote: post #274
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…

I believe all the criticism of GnuPG is due to the fact most people grew up with Microsoft or Apple, so they are use to hand-holding. If you read the various how-tos out there it is not that hard to use, just people do not want to read anything more than 2 lines. That is the main issue. My only complaint is Thunderbird now uses its own homegrown encryption, thus locking you into their email client. Seems almost all e…

> If you read the various how-tos out there it is not that hard to use, just people do not want to read anything more than 2 lines. That is the main issue.

The video linked above contains multiple examples of people using GnuPG's CLI in ways that it was seemingly intended to be used. Blaming users for holding it wrong seems facile.

Re: Gpg.fail

#285

Post by tptacek »

goldsteinq wrote: post #279
some_furry wrote: post #276

Earlier quoted context omitted.

I literally included a screenshot that shows you can setup backups in a directory on your device and then use your own backup solution. Signal is not holding you hostage.

Yes, if your only device is a single Android phone you can do that. You can’t, however, use that backup to populate your message history on other platforms. I’ve already lost message history consistency because one of my devices was offline for too long. The messages are there on my other device, but Signal refuses to let me copy my data from one of my devices to another. Signal is, quite literally, worse at syncing…

Look, if defending "message history consistency" is a reason you're choosing some other secure messenger rather than Signal, then I don't think this argument is very productive; use some other secure messenger then. But if "message history consistency" is a reason you're endorsing encrypted email over Signal, you're committing malpractice.

The point is that whatever secure messenger you use, it must plausibly be secure. Email cannot plausibly be made secure. Whatever other benefits you might get from using it --- federation, open source, UX improvements, universality --- come at the cost of grave security flaws.

Most people who use encrypted email are doing so in part because it does not matter if any of their messages are decrypted. They simply aren't interesting or valuable. But in endorsing a secure messenger of any sort, you're influencing the decisions of people whose messages are extremely sensitive, even life-or-death sensitive. For those people, federation or cross-platform support can't trump security, and as practitioners we are obligated to be clear about that.

Re: Gpg.fail

#286

Post by Natanael_L »

deknos wrote: post #207
some_furry wrote: post #111

Earlier quoted context omitted.

Why is a keyring important to you? Would "fetch a short-lived age public key" serve your use case? If so, then an age plugin that build atop the AuxData feature in my Fediverse Public Key Directory spec might be a solution. https://github.com/fedi-e2ee/public-key-directory-specificat... But either way, you shouldn't have long-lived public keys used for confidentiality. It's a bad design to do that.

We need a keyring at a company. Because there's no other media for communicating, where you reach management and technical people in companies as well. And we have massive issues due to the fact that the ongoing-decrying of "shut everything off" and the following non-improvement-without-an-alternative because we have to talk with people of other organizations (and every organization runs their own mailserver) and the…

You need a private PKI, not keyring. They're subtly different - a PKI can handle key rotation, etc.

Yes there aren't a lot of good options for that. If you're using something like a Microsoft software stack with active directory or similar identity/account management then there's usually some PKI support in there to anchor to.

Across organisations, there's really very very few good solutions. GPG specifically is much too insecure when you need to receive messages from untrusted senders. There's basically S/MIME which have comparable security issues, then we have AD federation or Matrix.org with a server per org.

> You could say, we do not need gpg, because we control the mailserver, but what if a mailserver is compromised and the mails are still in mailboxes?

How are you handling the keys? This is only true if user's protect their own keypairs with strong passwords / yubikey applet, etc.

Re: Gpg.fail

#287

Post by Natanael_L »

palata wrote: post #213
some_furry wrote: post #99

Earlier quoted context omitted.

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I wrote this to answer this exact question last year.

> The only downside to Sigstore is it hasn’t been widely adopted yet. Which, from where I stand, means that PGP is the only viable solution because I don't have a choice. I can't replace PGP with Sigstore when publishing to Maven. It's nice to tell me I'm dumb because I use PGP, but really it's not my choice. > Use SSH Signatures, not PGP signatures. Here I guess it's just me being dumb on my own. Using SSH signature…

The fact that every email encryption integration exports secure context messages into insecure contexts when decrypting (which is how encrypted messages end up cited in plaintext) means email can't be secured.

This is true both for GPG and S/MIME

Email encryption self-compromises itself in a way Signal doesn't

Re: Gpg.fail

#288

Post by goldsteinq »

tptacek wrote: post #285
goldsteinq wrote: post #279

Earlier quoted context omitted.

Yes, if your only device is a single Android phone you can do that. You can’t, however, use that backup to populate your message history on other platforms. I’ve already lost message history consistency because one of my devices was offline for too long. The messages are there on my other device, but Signal refuses to let me copy my data from one of my devices to another. Signal is, quite literally, worse at syncing…

Look, if defending "message history consistency" is a reason you're choosing some other secure messenger rather than Signal, then I don't think this argument is very productive; use some other secure messenger then. But if "message history consistency" is a reason you're endorsing encrypted email over Signal, you're committing malpractice. The point is that whatever secure messenger you use, it must plausibly be secu…

I’m definitely not “commiting malpractice” on account of not being a security practicioner. I’m talking from a perspective of a user.

It’s important to me — as a user — that a communication tool doesn’t lose my data, and Signal already did. Actual practicioners keep recommending Signal and sure, I believe that in a weird scenario where my encryption keys are somehow compromised without also compromising my local message history, Signal’s double-ratchet will do wonders — but it doesn’t actually work as a serious communication tool.

It’s also kinda curious that while the “email cannot be made secure” mantra is constantly repeated online, basically every organization that needs secure communication uses email. Openwall are certainly practicioners, and they use PGP-over-email: are they commiting malpractice?

Re: Gpg.fail

#289

Post by tptacek »

goldsteinq wrote: post #288
tptacek wrote: post #285

Earlier quoted context omitted.

Look, if defending "message history consistency" is a reason you're choosing some other secure messenger rather than Signal, then I don't think this argument is very productive; use some other secure messenger then. But if "message history consistency" is a reason you're endorsing encrypted email over Signal, you're committing malpractice. The point is that whatever secure messenger you use, it must plausibly be secu…

I’m definitely not “commiting malpractice” on account of not being a security practicioner. I’m talking from a perspective of a user. It’s important to me — as a user — that a communication tool doesn’t lose my data, and Signal already did. Actual practicioners keep recommending Signal and sure, I believe that in a weird scenario where my encryption keys are somehow compromised without also compromising my local mess…

Yes.

Re: Gpg.fail

#290

Post by Natanael_L »

xeonmc wrote: post #191
some_furry wrote: post #99

Earlier quoted context omitted.

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I wrote this to answer this exact question last year.

offtopic question: as a recent dabbling reader of introductory popsci content in cryptography, I've been wondering about what are the different segmentation of expert roles in the field? e.g. in Filippo's blogpost about Age he clarified that he's not a cryptographer but rather a cryptography engineer, is that also what your role is, what are the concrete divisions of labor, and what other related but separate positio…

There's no clear segmentation. There's symmetric and asymmetric primitives (and stuff that doesn't fit into these like ZKP), algorithms, protocols, research in many different types of attacks against each of these, research in design and defenses, and plenty of people will cover completely different subsets.

"don't" roll your own cover everything from "don't design your own primitive" to "don't make your own encryption algorithm/mode" to "don't make your own encryption protocol", to "don't reimplement an existing version of any of the above and just use an encryption library"

(and it's mostly "don't deploy your own", if you want to experiment that's fine)

Post reply on HN