Live data from Hacker News

Gpg.fail

gpg.fail

251–260 of 376 posts

Re: Gpg.fail

#251
post #207

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…

> We need a keyring at a company.

https://xyproblem.info

Look closely at the UX I'm proposing in https://github.com/fedi-e2ee/pkd-client-php?tab=readme-ov-fi...

Tell me why this won't work for your company.

Re: Gpg.fail

#252
post #160

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…

GnuPG should be extended (incrementally rewritten into something much better and turned into a library) and the original GnuPG should be extinguished.

With UI/UX person involved in whole thing preferably. It's just... bad

Maybe have it run CLI in compatibility mode when called as `gpg` but have completely new one when called normally

Re: Gpg.fail

#253
post #213

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…

> Which, from where I stand, means that PGP is the only viable solution because I don't have a choice.

You don't have a choice today. You could have a choice tomorrow if enough people demanded it.

Don't let PGP's convenience (in this context) pacify you from making a better world possible.

Re: Gpg.fail

#254
post #191

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…

My job title is in the Security Engineer family.

I do not have a Ph.D in Cryptography (not even an honorary one), so I do not call myself a Cryptographer. (Though I sometimes use "Cryptografur" in informal contexts for the sake of the pun.)

Re: Gpg.fail

#255
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 seriously don't care what messenger you use, as long as it isn't email, which can't be made secure. Pick something open source. It'll be less secure than Signal, but way more secure than email.

Re: Gpg.fail

#256
post #231

Earlier quoted context omitted.

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

They didn't personally attack you. They (correctly) attacked 64-bit identifiers.

Re: Gpg.fail

#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 able to encrypt my backups to multiple recipients. And I want the same keys (stored on Yubikeys, remember?) to be usable for SSH authentication, too.

And by the way, if your fancy tool is written using the latest language du jour with a runtime that changes every couple of years or so, or requires huge piles of dependencies that break if you even as much as sneeze (python, anyone?), it won't do.

BTW, in case someone says "age", I actually followed that advice and set it up just to be there on my systems (managed by ansible). Apart from the fact that it really slowed down my deployments, the thing broke within a year. And I didn't even use it. I just wanted to see how reliable it will be in the most minimal of ways: by having it auto-installed on my systems.

If your fancy tool has less than 5 years of proven maintenance record, it won't do. Encryption is for the long term. I want to be able to read my stuff in 15-30 years.

So before you go all criticizing GnuPG, please understand that there are reasons why people still use it, and are actually OK with the flaws described.

Re: Gpg.fail

#258
post #191

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 isn't one, but the modal professional cryptography engineer probably has a graduate degree in cryptography.

Re: Gpg.fail

#259
post #79

Earlier quoted context omitted.

Your mail either needs to be encrypted reliably against real adversaries or it doesn't. A private emailing circle doesn't change that. If the idea here is, a private group of friends can just agree never to put anything in their subjects, or to accidentally send unencrypted replies, I'll just say I ran just such a private circle at Matasano, where we used encrypted mail to communicate about security assessment projec…

> Your mail either needs to be encrypted reliably against real adversaries or it doesn't. It is, GPG take care of that. > If the idea here is, a private group of friends can just agree never to put anything in their subjects, or to accidentally send unencrypted replies That’s not what I’m talking about. It’s an enterprise - you cannot send non-encrypted emails from your work mail account, the gateway takes care of it…

If you're relying on a trusted gateway, you don't need any of this; just do TLS to the gateway to exchange messages. This is how 95% of corporate "secure email" systems work.

Re: Gpg.fail

#260
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 isn't an alternative that is functionally equivalent because what PGP does is dumb. It's a Swiss Army Knife. Nobody who wants to design an excellent saw sets out to design the Swiss Army Knife saw[†]. Nobody who needs shears professionally buys a Swiss Army Knife for the scissors.

The cryptographic requirements of different problems --- backup, package signing, god-help-us secure messaging --- are in tension with each other. No one design adequately covers all the use cases. Trying to cram them all into one tool is a sign that something other than security is the goal. If that's the case, you're live action roleplaying, not protecting people.

I'd be interested in whether you could find a cryptographer who disagrees with that. I've asked around!

[†] I am aware that SAK nerds love the saw.

Post reply on HN