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

261–270 of 376 posts

Re: Gpg.fail

#261

Post by some_furry »

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…

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

I'm very curious about this. Tell me more.

Re: Gpg.fail

#262

Post by tptacek »

some_furry wrote: post #261
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…

> 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. I'm very curious about this. Tell me more.

I didn't even catch this the first read. `age` is a command line program written in Go. It's not a system service. Simply "having it installed" on your system can't do anything.

Re: Gpg.fail

#263

Post by some_furry »

johnisgood wrote: post #129
soatok wrote: post #117

Earlier quoted context omitted.

(This is some_furry, I'm currently rate-limited. I thought this warranted a reply, so I switched to this account to break past the limit for a single comment.) > This statement is generic and misleading. It may be generic, but it's not misleading. > Using long-lived keys for confidentiality is bad in real-time messaging, but for non-ephemeral use cases (file encryption, backups, archives) it is completely fine. What…

You introduced "short-lived" vs "long-lived", not me. Long-lived as wall-clock time (months, years) is the default interpretation in this context. The Alice / Bob comparison is asymmetric in a misleading way. You state Bob Ltd retains all private keys indefinitely. A Heartbleed-style attack on their key storage infrastructure still compromises 30 years of backups, not 90 days. Rotation only helps if only the current…

> The Alice / Bob comparison is asymmetric in a misleading way. You state Bob Ltd retains all private keys indefinitely. A Heartbleed-style attack on their key storage infrastructure still compromises 30 years of backups, not 90 days.

No. Having 30 years of secret keys at all is not the same of having 30 years of secret keys in memory.

Re: Gpg.fail

#264

Post by [deleted] »

kpil wrote: post #84
kaoD wrote: post #73

Earlier quoted context omitted.

This is not the first time I see "secure key distribution" mentioned in HN+(GPG alternatives) context and I'm a bit puzzled. What do you mean? Web of Trust? Keyservers? A combination of both? Under what use case?

I'm assuming they mean the old way of signing each others signatures. As a practical implementation of "six degrees of Kevin Bacon", you could get an organic trust chain to random people. Or at least, more realistically, to few nerds. I think I signed 3-4 peoples signatures. The process had - as they say - a low WAF.

[deleted]

Re: Gpg.fail

#265

Post by p2detar »

tptacek wrote: post #259
p2detar wrote: post #216

Earlier quoted context omitted.

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

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

Re: Gpg.fail

#266

Post by tptacek »

anonym29 wrote: post #164
akerl_ wrote: post #162

Earlier quoted context omitted.

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

These are words, but I don't understand how they respond to the preceding comment, which observes that binary legibility is an operational requirement for real security given that almost nobody uses reproducible builds. In reality, people meaningfully depend on work done at the binary level to ensure lack of backdoors, not on work done at the source level.

The preceding comment is saying that source security is insufficient, not that transparency is irrelevant.

Re: Gpg.fail

#267

Post by goldsteinq »

some_furry wrote: post #249
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…

> 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 my messages. I want Signal to not lock in my messages on their servers, so I can sync them between my devices and back them up into my own backups.

> If you want to self-host your own backups (at your own cost), that's easy to do.

Except there’s no way to move it between platforms. I have more than one device.

> Are you referring to MobileCoin? That feature isn't in the pipeline for sending messages.

I don’t want shady crypto company to hold my data hostage, and there’s no way to store it on my hardware and then move it between platforms. That’s my problem with signal.

> A Synchronized Start for Linked Devices

It only properly transfers 45 days. You can’t have more than one phone. Phones are special “primary devices” and AFAIK you can’t restore your messages if you lose your phone even if you have logged-in Signal Desktop.

Re: Gpg.fail

#268

Post by dwattttt »

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…

> Apart from the fact that it really slowed down my deployments

Is this a comparable complaint worth mentioning, and if it is are you sure you actually need cryptography? It slowed things down a bit, so you don't really want to move on from demonstrably too-complex to not have bugs GnuPG?

Re: Gpg.fail

#269

Post by fn-mote »

tptacek wrote: post #262
some_furry wrote: post #261

Earlier quoted context omitted.

> 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. I'm very curious about this. Tell me more.

I didn't even catch this the first read. `age` is a command line program written in Go. It's not a system service. Simply "having it installed" on your system can't do anything.

If it fails to build when the system is updated?

Poster says:

> slowed down my deployments

I take that to mean the _deployment_ step, not the deployed system.

Re: Gpg.fail

#270

Post by akerl_ »

p2detar wrote: post #265
tptacek wrote: post #259

Earlier quoted context omitted.

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.

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.

Post reply on HN