Live data from Hacker News

Gpg.fail

gpg.fail

291–300 of 376 posts

Re: Gpg.fail

#291

Earlier quoted context omitted.

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

They were attacking an entire community. Perhaps I should have complained about being deliberately provocative.

But to the point, how long should something like a key fingerprint be?

Re: Gpg.fail

#292

Earlier quoted context omitted.

Look, if defending "message history consistency" is a reason you're choosing some other secure messenger rather than Signal, then I don't think this argument is very productive; use some other secure messenger then. But if "message history consistency" is a reason you're endorsing encrypted email over Signal, you're committing malpractice. The point is that whatever secure messenger you use, it must plausibly be secu…

I’m definitely not “commiting malpractice” on account of not being a security practicioner. I’m talking from a perspective of a user. It’s important to me — as a user — that a communication tool doesn’t lose my data, and Signal already did. Actual practicioners keep recommending Signal and sure, I believe that in a weird scenario where my encryption keys are somehow compromised without also compromising my local mess…

> but it doesn’t actually work as a serious communication tool.

Say more. Plenty of people use Signal as a serious communication tool.

> Openwall are certainly practicioners, and they use PGP-over-email: are they commiting malpractice?

They, and other communities that use GPG-encrypted emails are LARPing, and it’s only fine because their emails don’t actually matter enough for anybody to care about compromising them.

It’s not malpractice to LARP: plenty of people love getting out their physical or digital toys and playing pretend. But if you’re telling other people that your foam shield can protect them from real threats, you are lying.

Re: Gpg.fail

#293

Earlier quoted context omitted.

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

Don't encrypt email. https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...

The only alternative suggested by the linked article is giving up email completely in favor of centralized solutions like Signal. My short answer is “no”. My long answer is: https://news.ycombinator.com/item?id=45390332>

Re: Gpg.fail

#294
post #89

Earlier quoted context omitted.

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?

What's your usecase here? Internal or external messaging?

Re: Gpg.fail

#295

Earlier quoted context omitted.

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

Source availability is what makes a chain of trust possible that simply isn't meaningfully possible with closed source software, even with dynamic analysis, decompilation, reverse engineering, runtime network analysis with TLS decryption, etc.

Both you and the preceding commenter are correct that just running binaries signed and distributed by Alphabet (Google) and/or Apple presents room for additional risks beyond those observable in the source code, but the solution to this problem isn't to say "and therefore source availability doesn't matter at all for anyone", it's to choose to build from source or to obtain and install APKs built and signed by the developers, such as via Accrescent or Obtanium (pulls directly from github, gitlab, etc releases).

There's a known-good path. Most people do not take the known-good path. Their choice to do so does not invalidate or eliminate the desirable properties of known-good path (verifiability, trustworthiness).

I genuinely do not understand the argument you and the other user are making. It reads to me like an argument that goes "Yes, there's a known, accurate, and publicly documented recipe to produce a cure for cancer, but it requires prerequisite knowledge to understand that most people lack, and it's burdensome to follow the recipe, so most people just buy their vials from the untrustworthy CancerCureCorporation, who has the ability to give customers a modified formula that keeps them sick rather than giving them the actual cure, and almost nobody makes the cure themselves without going through this untrustworthy but ultimately optional intermediary, so the public documentation of the cure doesn't matter at all, and there's no discernable difference between having the cure recipe and not having the cure recipe."

Re: Gpg.fail

#296
post #292

Earlier quoted context omitted.

I’m definitely not “commiting malpractice” on account of not being a security practicioner. I’m talking from a perspective of a user. It’s important to me — as a user — that a communication tool doesn’t lose my data, and Signal already did. Actual practicioners keep recommending Signal and sure, I believe that in a weird scenario where my encryption keys are somehow compromised without also compromising my local mess…

> but it doesn’t actually work as a serious communication tool. Say more. Plenty of people use Signal as a serious communication tool. > Openwall are certainly practicioners, and they use PGP-over-email: are they commiting malpractice? They, and other communities that use GPG-encrypted emails are LARPing, and it’s only fine because their emails don’t actually matter enough for anybody to care about compromising them.…

> Say more. Plenty of people use Signal as a serious communication tool.

I did say more already. Maybe you believe in serious communication tools that can’t synchronize searchable history between devices, but I don’t.

> They, and other communities that use GPG-encrypted emails are LARPing, and it’s only fine because their emails don’t actually matter enough for anybody to care about compromising them.

Are we talking about the same Openwall? Are you aware what Openwall’s oss-security mailing list is? Please, do elaborate how nobody cares about getting access to an unlimited stream of zerodays for basically every Unix-like system.

Re: Gpg.fail

#297
post #292

Earlier quoted context omitted.

> but it doesn’t actually work as a serious communication tool. Say more. Plenty of people use Signal as a serious communication tool. > Openwall are certainly practicioners, and they use PGP-over-email: are they commiting malpractice? They, and other communities that use GPG-encrypted emails are LARPing, and it’s only fine because their emails don’t actually matter enough for anybody to care about compromising them.…

> Say more. Plenty of people use Signal as a serious communication tool. I did say more already. Maybe you believe in serious communication tools that can’t synchronize searchable history between devices, but I don’t. > They, and other communities that use GPG-encrypted emails are LARPing, and it’s only fine because their emails don’t actually matter enough for anybody to care about compromising them. Are we talking…

I’m very familiar with oss-security, a public mailing list that doesn’t really have anything to do with GPG-encrypted emails. Encrypting emails to a public mailing list, with GPG or otherwise, wouldn’t really make sense.

Re: Gpg.fail

#298

Earlier quoted context omitted.

>Personal backup encryption with a long-lived key, passphrase-protected private key, and offline storage is a legitimate threat model ... If you're going to use a passphrase anyway why not just use a symmetric cipher? In fact for file storage why not use an encrypted disk volume so you don't need to use PGP?

That was just me being goofy in that bit (and only that), but I hope the rest of my message went across. :) > In fact for file storage why not use an encrypted disk volume so you don't need to use PGP? Different threat models. Disk encryption (LUKS, VeraCrypt, plain dm-crypt) protects against physical theft. Once mounted, everything is plaintext to any process with access. File-level encryption protects files at rest…

>You cannot send someone a LUKS volume to decrypt one file, and backups of a mounted encrypted volume are plaintext unless you add another layer.

Veracrypt, and I'm sure others, allow you to do exactly this. You can create a disk image that lives in a file (like a .iso or .img) and mount/unmount it, share it, etc.

Re: Gpg.fail

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

There's like one or two use cases where encrypting email could work. The best case I've come across--Bugzilla has the ability to let the user upload a public key to encrypt emails for updates to non-public bugs. It's not a big use case--pretty much the intersection of "must use email" and "can establish identity out of band," which does not describe most communication that uses email. (As tptacek notes in a sibling c…

[deleted]

Re: Gpg.fail

#300

Earlier quoted context omitted.

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

Source availability is what makes a chain of trust possible that simply isn't meaningfully possible with closed source software, even with dynamic analysis, decompilation, reverse engineering, runtime network analysis with TLS decryption, etc. Both you and the preceding commenter are correct that just running binaries signed and distributed by Alphabet (Google) and/or Apple presents room for additional risks beyond t…

> but the solution to this problem isn't to say "and therefore source availability doesn't matter at all for anyone"

Thankfully, I didn’t say that.

Post reply on HN