Live data from Hacker News

Gpg.fail

gpg.fail

271–280 of 376 posts

Re: Gpg.fail

#271
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 wi…

So what toolbag or workshop of excellent specialized tools would provide the same capability as GnuPG?

Re: Gpg.fail

#272

Earlier quoted context omitted.

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

So what toolbag or workshop of excellent specialized tools would provide the same capability as GnuPG?

Ask me a question about a specific realistic problem (ie, not "how do I replicate this behavior of PGP", but rather "how do I solve this real-world problem") and I'll give an answer (or someone else will).

Re: Gpg.fail

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

Asking for an equivalent to GPG is like asking for an equivalent of a Swiss knife with unshielded chainsaws and laser cutters.

Stop asking for it, for your own good, please. If you don't understand the entire spec you can't use it safely.

You want special purpose tools. Signal for communication, Age for safer file encryption, etc.

What exact problems did you have with age? You're not explaining how it broke anything. Are you compiling yourself? Age has yubikey support and can do all you described.

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

This applies to algorithms, it does not apply to cryptographic software in the same way. The state of art changes fast, and while algorithms tend to stand for a long time these days there are significant changes in protocol designs and attack methods.

Downgrade protection, malleability protection, sidechannel protection, disambiguation, context binding, etc...

You want software to be implemented by experts using known best practices with good algorithms and audited by other experts.

Re: Gpg.fail

#274
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 email clients have their own way of encryption, confusing the matters even more. I now use mutt because it can be easily likned to GnuPG and it does not lock me into a specific client.

Re: Gpg.fail

#275
post #270

Earlier quoted context omitted.

But you don't know how many SMTP relays the recipient has and if they are all secured. E2E encryption, be it via GPG or x.509/SMIME, is still good in that case. edit: smime

Can you give an example of an email provider or technology that’s doing GPG or SMIME at the gateway? I’ve never seen that configuration and it doesn’t seem like it would make sense. Either it’s just theatre, encrypting emails internally and then stripping it when they’re delivered, or you still need every recipient to be managing their own keys anyways to be able to decrypt/validate what they’re reading.

I will not name it, but I worked on such product for some time. In fact it is still being sold, maybe 3rd decade already.

> you still need every recipient to be managing their own keys anyways to be able to decrypt/validate what they’re reading.

Nope, that is handled at the gateway on the receiving side.

edit: Again, the major point here is to ensure no plain text email gets relayed. TLS does not guarantee that plain text email doesn't get relayed by a wrongly configured relay on its route.

Re: Gpg.fail

#276

Earlier quoted context omitted.

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

> You don't have to use it like "encrypted SMS"! You're free. Using it as something more than encrypted SMS requires persistent message history between devices. > metric fuckton of messages “More than 45 days” is a metric fuckton? Seriously? > 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. I don’t want Signal to store…

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.

Re: Gpg.fail

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

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.

Re: Gpg.fail

#278
post #270

Earlier quoted context omitted.

Can you give an example of an email provider or technology that’s doing GPG or SMIME at the gateway? I’ve never seen that configuration and it doesn’t seem like it would make sense. Either it’s just theatre, encrypting emails internally and then stripping it when they’re delivered, or you still need every recipient to be managing their own keys anyways to be able to decrypt/validate what they’re reading.

I will not name it, but I worked on such product for some time. In fact it is still being sold, maybe 3rd decade already. > you still need every recipient to be managing their own keys anyways to be able to decrypt/validate what they’re reading. Nope, that is handled at the gateway on the receiving side. edit: Again, the major point here is to ensure no plain text email gets relayed. TLS does not guarantee that plain…

If the gateways are putting encryption in place and then stripping it, it’s not end-to-end. You’re just doing theatre over mandating TLS.

Re: Gpg.fail

#279

Earlier quoted context omitted.

> You don't have to use it like "encrypted SMS"! You're free. Using it as something more than encrypted SMS requires persistent message history between devices. > metric fuckton of messages “More than 45 days” is a metric fuckton? Seriously? > 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. I don’t want Signal to store…

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 message history than IRC — at least with IRC I can set up a bouncer and have a consistent view of history on all of my devices, but there’re no Signal bouncers.

Re: Gpg.fail

#280

Earlier quoted context omitted.

> I need an alternative to "gpg --encrypt --armor --recipient " That's literally age. https://github.com/FiloSottile/age

No, because there is no keyring and you have to supply people's public key each time. It is not suitable for large-scale public key management (with unknown recipients), and it does not support automatic discovery, trust management. Age does NOT SUPPORT signing at all either.

What you described IS WHY age is the better option.

GPG's keyring handling has also been a source of exploits. It's much safer to directly specify recipient rather than rely on things like short key IDs which can be bruteforced.

Automatic discovery simply isn't secure if you don't have an associated trust anchor. You need something similar to keybase or another form of PKI to do that. GPG's key servers are dangerous.

You technically can sign with age, but otherwise there's minisign and the SSH spec signing function

Post reply on HN