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

231–240 of 376 posts

Re: Gpg.fail

#231

Post by amluto »

upofadown wrote: post #215
amluto wrote: post #159

Earlier quoted context omitted.

> you have to supply people's public key each time Keyrings are awful. I want to supply people’s public keys each time. I have never, in my entire time using cryptography, wanted my tool to guess or infer what key to verify with. (Heck, JOSE has a long history of bugs because it infers the key type , which is also a mistake.) I have an actual commercial use case that receives messages (which are, awkwardly, files sen…

>And it wants to identify keys by 32-bit truncated hashes. That's 64 bits these days. >I should really not have to even think about the interaction between decryption and verification. 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 problem. Yes, you…

>> 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 problem. Yes, you can use a shared key for this but then you end up doing both verifications manually.

I can’t quite tell what you mean.

One can build protocols that do encrypt-then-sign, encrypt-and-sign, sign-then-encrypt, or something clever that combines encryption and signing. Encrypt-then-sign has a nice security proof, the other two combinations are often somewhat catastrophically wrong, and using a high quality combination can have good performance and nice security proofs.

But all of the above should be the job of the designer of a protocol, not the user of the software. If my peer sends me a message, I should provision keys, and then I should pass those keys to my crypto library along with a message I received (and perhaps whatever session state is needed to detect replays), and my library should either (a) tell me that the message is invalid and not give me a guess as to its contents or (b) tell me it’s valid and give me the contents. I should not need to separately handle decryption and verification, and I should not even be able to do them separately even if I want to.

Re: Gpg.fail

#232

Post by LtWorf »

kuschku wrote: post #200
p2detar wrote: post #68

Earlier quoted context omitted.

> Encrypting email > Don't. https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#en... I’m not sure I completely agree here. For private use, this seems fine. However, this isn’t how email encryption is typically implemented in an enterprise environment. It’s usually handled at the mail gateway rather than on a per-user basis. Enterprises also ensure that the receiving side supports email encryption as well. edi…

Even my doctor's office and local government agencies support PGP encrypted emails, and refuse to send personal data via unencrypted email, but tech nerds still claim no one can use it?

In general the userbase here is startuppers, they hate distributed solutions and love centralisation.

Re: Gpg.fail

#233

Post by xorcist »

ameliaquining wrote: post #60
elric wrote: post #13

This is depressing. From what I can piece together while the site is down, it seems like they've uncovered 14 exploitable vulnerabilities in GnuPG, of which most remain unpatched. Some of those are apparently met by refusal to patch by the maintainer. Maybe there are good reasons for this refusal, maybe someone else can chime in on that? Is this another case of XKCD-2347? Or is there something else going on? Pretty m…

If by "pretty much every Linux distro depends on PGP being pretty secure" you're referring to its use to sign packages in Linux package managers, it's worth noting that they use PGP in fairly narrowly constrained ways; in particular, the data is often already trusted because it was downloaded over HTTPS from a trusted server (making PGP kind of redundant in some ways). So most PGP vulnerabilities don't affect them. I…

That is not an accurate description.

Debian, and indeed most projects, do not control the download servers you use. This is why security is end-to-end where packages are signed at creation and verified at installation, the actual files can then pass through several untrusted servers and proxies. This was sound design in the 90s and is sound design today.

Re: Gpg.fail

#234

Post by Avamander »

akerl_ wrote: post #179
Avamander wrote: post #175

Earlier quoted context omitted.

> For most apps on non-mobile devices, there isn't filesystem isolation between apps. If there isn't there should be. At least my Flatpaks are isolated from each other. > Apple/Microsoft/Google all ship encrypted storage for secrets (Keychain, Credential Manager, etc), because restricting key material access within the OS has merit. The Linux equivalents are suspicious and stuck in the past to say the least. Dependin…

> Then we know where this stuff came from. I can’t figure out what you mean by this.

Just a joke that if indeed GPG predates and was not inspired by corporate security theatre then the opposite must be true. That corporate security theatre was inspired by GPG/PGP.

Re: Gpg.fail

#235

Post by Avamander »

palata wrote: post #227
ahlCVA wrote: post #221

Earlier quoted context omitted.

For what it's worth: You can set no-touch-required on a key (it's a generation-time option though).

Sure, but then it is set to no-touch for every FIDO2 interaction I have. I don't want to touch for signing, but I want to touch when using it as a passkey, for instance.

Use the PIV applet for SSH and signing Git commits instead? Git supports S/MIME and SSH can use keys over PKCS#11 basically out-of-box on OSs that don't ship gpg-agent (that just interferes with SmartCard usage in general).

Re: Gpg.fail

#236

Post by Avamander »

ghickPit wrote: post #222
talideon wrote: post #163

Earlier quoted context omitted.

Let's not conflate GPG and PGP-in-general. RPM doesn't use GPG, it uses Sequoia PGP. GPG is what GP is referring to as a lost cause. Now, it can be debated whether PGP-in-general is a lost cause too, but that's not what GP is claiming.

> it can be debated whether PGP-in-general is a lost cause too, but that's not what GP is claiming It is though what both the fine article, and tptacek in these comments, are claiming!

They are also correct, but that's indeed not what the person you replied to said.

> then why haven't alternatives ^W replacements been produced for decades?

Actually we do have alternatives for it.

For example Git supports S/MIME and could absolutely be used to sign commits and tags. Even just using self-signed certificates wouldn't be far off from what PGP offers. However if people used their digital IDs like many countries offer, mission-critical code could have signatures with verifiable strong identities.

Though there are other approaches as well, both for signing and for encrypting. It's more that people haven't really considered migrating.

Re: Gpg.fail

#237

Post by dkdcio »

ekjhgkejhgk wrote: post #223
UqWBcuFx6NV4r wrote: post #204

Earlier quoted context omitted.

You are attributing a general trend to a particular language community. I also believe that you are unjustifiably unfairly interpreting “default license” just because you disagree with what they think the “default license” is. We all know what is means by this. It just sounds like you think it should be something GPL

No, you're guessing what I'm thinking. I'm telling you that a person I spoke to TOLD ME verbatim "I chose MIT because it's the default lincense". I'm not guessing that's what they did, that's what they TOLD ME. Do you understand the concept or literally telling someone something?

FWIW I would absolutely say “MIT is the default license”. I also understand copyleft and personally would still choose MIT in general

I also like Rust, but the above would be true before I started using Rust (I agree it’s not a programming language thing)

Re: Gpg.fail

#238

Post by woodruffw »

kuschku wrote: post #198
woodruffw wrote: post #106

Earlier quoted context omitted.

With Let’s Encrypt, your private key is (typically) rotated every 90 days. It’s kept on disk because 90 days is too long to reliably keep a private key resident in memory on unknown hardware. With attestations on PyPI, the issuance window is 15 minutes instead of 90 days. So the private key is kept in memory and discarded as soon as the signing operation is complete, since the next signing flow will create a new one.…

No? With let's encrypt the certificate is rotated, but the private key remains the same, and importantly, let's encrypt never gets to see it, and anything is logged.

I said “typically” because Let’s Encrypt doesn’t control key rotation: the issuance managing client (like Certbot) does.

But AFAICT, Certbot has rotated private keys automatically on reissuance since at least 2016[1]. There’s no reason not to in a fully automated scheme. I would expect all of the other major issuing clients to do the same.

[1]: https://community.letsencrypt.org/t/do-new-private-keys-get-...

Re: Gpg.fail

#239

Post by benchloftbrunch »

tptacek wrote: post #89
akulbe wrote: post #88

Earlier quoted context omitted.

Is there a better alternative to GPG?

Everything is better than PGP (not just GPG --- all PGP implementations). The problem with PGP is that it's a Swiss Army Knife. It does too many things. The scissors on a Swiss Army Knife are useful in a pinch if you don't have real scissors, but tailors use real scissors. Whatever it is you're trying to do with encryption, you should use the real tool designed for that task. Different tasks want altogether different…

What is the alternative to PGP for the specific use case of secure email? That doesn't mandate dealing with the X509 certificate bureaucracy?

Re: Gpg.fail

#240

Post by grayhatter »

bfkwlfkjf wrote: post #184
grayhatter wrote: post #177

Earlier quoted context omitted.

> Is anyone else worried that [...] the Rust world [...] slap on it MIT license because it's [reason you don't like]? No... I don't think that's how software works. Do you have an example of that happening? Has any foss project lost control of the "best" version of some software? > Not everything in software is about features. I mean, I would happily make the argument that the ability to use code however I want witho…

[flagged]

> You're mischaracterizing what I'm saying.

"I'm saying"? Why are you posting from multiple nonsense account names?

> For one thing you're talking about "someone" when I'm taking about "someone with power".

Are you sure you it's a mischaracterization? Or is it a disagreement over what are the important parts?

> Copyleft isn't about two people, one gaining power over the other. It's about lots of people with no power protecting themselves again one entity with a lot of power to impose themselves.

That's sounds like two parties, who disagree about what they should be allowed to do with the work of others. One side thinks they should be able to control the behavior and actions of the other, and the other disagrees they should have any say over how they act. In that example which side is the GPL, and which side do you think I believe is more free?

> Are you new to HN?

Brand new!

> Every month there's news of projects trying to arrest power contributors using various shenanigans. Copyleft protects against a class of such attacks.

Then you should have specific examples you can describe and or cite?

> Eg Oracle and open office, red hat and centos.

those are names of companies, not examples of embrace, extend, extinguish... which is the FUD you started with?

the reddit post isn't linux losing control, is it? They made an insulin pump, and used linux... did linux lose control over anything? Is the best version of Linux on that insulin pump? Given it appears to be killing patients, I'm gonna guess it's not the best version, and the best version is still what I'm gonna call "mainline".

I restrict myself to foss software as much as I can. Because I want to be able to modify, and hack on the stuff I use. I also strongly support right to repair laws. But I'm unwilling to force my opinions on others. If you want to make something, and keep it secret, and set rules about how I'm allowed to use it, that's reasonable. I'm gonna tell you no, and suggest you piss off. Then I'll find or make something to replace it. I've never seen other person doing things, as preventing me from doing it myself or my way. And haven't found an example of it happening, other than people saying, I should be able to take what you made, and use it how I want without asking you for permission.

Either you believe 1) others should be able to set rules related to how they are allowed to use your work, or 2) you don't support the GPL

I guess there is a secret third option where you believe that you should be able to make up rules, but no one else should.

Post reply on HN