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

301–310 of 376 posts

Re: Gpg.fail

#301

Post by akerl_ »

stackghost wrote: post #298
johnisgood wrote: post #195

Earlier quoted context omitted.

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.

That’s not what they said. They’re saying you often want to give someone a specific file from a disk, rather than the whole set of files.

Re: Gpg.fail

#302

Post by goldsteinq »

akerl_ wrote: post #297
goldsteinq wrote: post #296

Earlier quoted context omitted.

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

Okay, sorry, not oss-security mailing list, oss-security _distros_ mailing list.

https://oss-security.openwall.org/wiki/mailing-lists/distros

> Only use these lists to report security issues that are not yet public

> To report a non-public medium or high severity 2) security issue to one of these lists, send e-mail to distros [at] vs [dot] openwall [dot] org or linux [dash] distros [at] vs [dot] openwall [dot] org (choose one of these lists depending on who you want to inform), preferably PGP-encrypted to the key below.

Re: Gpg.fail

#303

Post by anonym29 »

akerl_ wrote: post #300
anonym29 wrote: post #295

Earlier quoted context omitted.

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.

Great, then it sounds like we agree: your original equivalence of Signal and WhatsApp was misguided, since one offers a verifiable chain of trust that starts with source availability and the other doesn't, to say nothing of the lengthy history of untrustworthiness and extensive, deliberate privacy violations of the company that owns and maintains WhatsApp, right?

Re: Gpg.fail

#304

Post by akerl_ »

goldsteinq wrote: post #302
akerl_ wrote: post #297

Earlier quoted context omitted.

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.

Okay, sorry, not oss-security mailing list, oss-security _distros_ mailing list. https://oss-security.openwall.org/wiki/mailing-lists/distros > Only use these lists to report security issues that are not yet public > To report a non-public medium or high severity 2) security issue to one of these lists, send e-mail to distros [at] vs [dot] openwall [dot] org or linux [dash] distros [at] vs [dot] openwall [dot] org (c…

Yes, that would be an example of LARPing security. The obviously indicator is that encrypting your message is entirely optional, per their own instructions. The less obvious bit is that even if you encrypt your message, anyone without GPG configured who replies has stripped any attempt at encryption from the contents.

Re: Gpg.fail

#305

Post by akerl_ »

anonym29 wrote: post #303
akerl_ wrote: post #300

Earlier quoted context omitted.

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

Great, then it sounds like we agree: your original equivalence of Signal and WhatsApp was misguided, since one offers a verifiable chain of trust that starts with source availability and the other doesn't, to say nothing of the lengthy history of untrustworthiness and extensive, deliberate privacy violations of the company that owns and maintains WhatsApp, right?

No, we don’t agree. There are things that source code is good for, but validating the presence or absence of illicit data stealing code in apps delivered to consumers is not one of those things. For that, source code can show you obvious malfeasance, but since it’s not enough to rule out obvious malfeasance, you’re stuck going to analysis of the compiled app in both cases.

The population of users who have a verifiable path from an open source repo to an app on their device is a rounding error in the set of humans using messaging apps.

Re: Gpg.fail

#306

Post by joshuamorton »

goldsteinq wrote: post #288
tptacek wrote: post #285

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…

Very few organizations need security from state level or similar threats and the infrastructure provider. Most organizations that want secure email don't use any kind of e2ee at all, they just trust Google or Microsoft or whomever.

The few jobs that actually care about this stuff, like journalists, do use signal.

Openwall doesn't get security via pgp, it gets a spam filter.

Re: Gpg.fail

#307

Post by joshuamorton »

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?

The point is that this isn't unique to rust.

Re: Gpg.fail

#308

Post by Arathorn »

goldsteinq wrote: post #281
Natanael_L wrote: post #277

Earlier quoted context omitted.

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.

Pros of Matrix: it actually has a consistent history (in theory); no vendor lock-in. Cons of Matrix: encryption breaks constantly. Right now I’m stuck in a fun loop of endlessly changing recovery keys: https://github.com/element-hq/element-web/issues/31392

bleurgh. that issue is very actively under investigation (modulo xmas). please can you submit debug logs from Element Web referencing that issue.

Re: Gpg.fail

#309

Post by anonym29 »

akerl_ wrote: post #305
anonym29 wrote: post #303

Earlier quoted context omitted.

Great, then it sounds like we agree: your original equivalence of Signal and WhatsApp was misguided, since one offers a verifiable chain of trust that starts with source availability and the other doesn't, to say nothing of the lengthy history of untrustworthiness and extensive, deliberate privacy violations of the company that owns and maintains WhatsApp, right?

No, we don’t agree. There are things that source code is good for, but validating the presence or absence of illicit data stealing code in apps delivered to consumers is not one of those things. For that, source code can show you obvious malfeasance, but since it’s not enough to rule out obvious malfeasance, you’re stuck going to analysis of the compiled app in both cases. The population of users who have a verifiabl…

I think we've both made our positions clear. From my perspective, you're continuing to heavily cite user statistics that are irrelevant to the properties of verifiability or trustworthiness of the applications themselves, the goalposts I am discussing keep being moved, and there is a repeated pattern of neglect to address the points I'm raising. Readers can judge for themselves. Curious readers should also read about the history of Meta's Onavo VPN software and resulting lawsuits and settlements in evaluating the credibility of Meta's privacy marketing.

Re: Gpg.fail

#310

Post by tptacek »

teddyh wrote: post #293
tptacek wrote: post #243

Earlier quoted context omitted.

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 >

I wrote the linked article. I don't care what secure messenger you use. But if you choose encrypted email over Signal because "centralization", you're LARPing. The first criteria for a secure messenger has to be that it is plausibly secure, and email isn't. You'd use encrypted email (for "decentralization") because you understand the cost of losing the plaintext of your message is nil. If you tell strangers to do that, without certainty that their messages are also valueless, you're committing malpractice.
Post reply on HN