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…
Gpg.fail
271–280 of 376 posts
Re: Gpg.fail
#272Earlier 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?
Re: Gpg.fail
#273It 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…
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
#274It 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…
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
#275Earlier 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.
> 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
#276Earlier 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…
Signal is not holding you hostage.
Re: Gpg.fail
#277Earlier 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…
Re: Gpg.fail
#278Earlier 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…
Re: Gpg.fail
#279Earlier 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.
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
#280Earlier 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.
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