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

321–330 of 376 posts

Re: Gpg.fail

#321

Post by woodruffw »

tptacek wrote: post #318
woodruffw wrote: post #283

Earlier quoted context omitted.

> I just wish all the crypto experts doing that would point me to an alternative that is functionally equivalent. The entire point of every single valid criticism of PGP is that you cannot make a single functionally equivalent alternative to PGP. You must use individual tools that are good at specific things, because the "Swiss Army knife" approach to cryptographic tool design has yielded empirically poor outcomes. I…

Point of order: there are valid and important criticisms of PGP that have nothing to do with its jack-of-all-trades philosophy. There's no modern cryptosystem in the world you would design with PGP's packet scheme.

Yeah, that was just the low-hanging fruit I reached for.

(I think you can make a tie-in argument here, though: PGP's packet design and the state machine that falls out of it is a knock-on effect of how many things PGP tries to do. PGP would maybe not have such a ridiculously complicated packet design if it didn't try and do so many things.)

Re: Gpg.fail

#322

Post by anonym29 »

tptacek wrote: post #312
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…

No, you're completely off the rails from the first sentence. It is absolutely possible --- in some ways more possible[†] --- to make a chain of trust without source availability. Your premise is that "reverse engineering" is somehow incomplete or lossy with respect to uncovering software behavior, and that simply isn't true. [†] Source is always good to have, but it's insufficient.

Never once anywhere in this thread have I claimed that source code alone is sufficient by itself to establish a chain of trust, merely that it is a necessary prerequisite to establish a chain of trust.

That said, you seem to be refuting even that idea. While your reputation precedes you, and while I haven't been in the field quite as long as you, I do have a few dozen CVEs, I've written surreptitious side channel backdoors and broken production cryptographic schemes in closed-source software doing binary analysis as part of a red team alongside former NCC folks. I don't know a single one of them who would say that lacking access to source code increases your ability to establish a chain of trust.

Can you please explain how lacking access to source code, being ONLY able to perform dynamic analysis, rather than dynamic analysis AND source code analysis, can ever possibly lead to an increase in the maximum possible confidence in the behavior of a given binary? That sounds like a completely absurd claim to me.

Re: Gpg.fail

#323

Post by tptacek »

anonym29 wrote: post #322
tptacek wrote: post #312

Earlier quoted context omitted.

No, you're completely off the rails from the first sentence. It is absolutely possible --- in some ways more possible[†] --- to make a chain of trust without source availability. Your premise is that "reverse engineering" is somehow incomplete or lossy with respect to uncovering software behavior, and that simply isn't true. [†] Source is always good to have, but it's insufficient.

Never once anywhere in this thread have I claimed that source code alone is sufficient by itself to establish a chain of trust, merely that it is a necessary prerequisite to establish a chain of trust. That said, you seem to be refuting even that idea. While your reputation precedes you, and while I haven't been in the field quite as long as you, I do have a few dozen CVEs, I've written surreptitious side channel bac…

I see what's happening. You're working under the misapprehension that static analysis is only possible with source code. That's not true. In fact: a great deal of real-world vulnerability research is performed statically in a binary setting.

There's a lot of background material I'd have to bring in to attempt to bring you up to speed here, but my favorite simple citation here is just: Google [binary lifter].

Re: Gpg.fail

#324

Post by palata »

some_furry wrote: post #253
palata wrote: post #213

Earlier quoted context omitted.

> The only downside to Sigstore is it hasn’t been widely adopted yet. Which, from where I stand, means that PGP is the only viable solution because I don't have a choice. I can't replace PGP with Sigstore when publishing to Maven. It's nice to tell me I'm dumb because I use PGP, but really it's not my choice. > Use SSH Signatures, not PGP signatures. Here I guess it's just me being dumb on my own. Using SSH signature…

> Which, from where I stand, means that PGP is the only viable solution because I don't have a choice. You don't have a choice today . You could have a choice tomorrow if enough people demanded it. Don't let PGP's convenience (in this context) pacify you from making a better world possible.

I agree with that. But I feel like I have been reading for years that there is really no reason to use PGP, and I have tried for years to use alternatives, but the fact remains that I still need to use PGP, either because it is mandatory or because in some cases the alternatives are not practical.

To me, there will be no reason to use PGP the day I find practical alternatives for the remaining use-cases I have. And I feel like signing git commits is not a weird use-case...

Re: Gpg.fail

#325

Post by anonym29 »

tptacek wrote: post #323
anonym29 wrote: post #322

Earlier quoted context omitted.

Never once anywhere in this thread have I claimed that source code alone is sufficient by itself to establish a chain of trust, merely that it is a necessary prerequisite to establish a chain of trust. That said, you seem to be refuting even that idea. While your reputation precedes you, and while I haven't been in the field quite as long as you, I do have a few dozen CVEs, I've written surreptitious side channel bac…

I see what's happening. You're working under the misapprehension that static analysis is only possible with source code. That's not true. In fact: a great deal of real-world vulnerability research is performed statically in a binary setting. There's a lot of background material I'd have to bring in to attempt to bring you up to speed here, but my favorite simple citation here is just: Google [binary lifter].

This assumption about me is not accurate at all, I've done static analysis professionally on CIL, on compiled bytecode, and on source code. Instead of being condescending and patronizing to someone you don't know that you've made factually inaccurate assumptions about, can you please explain how having just a binary and no access to source code gives you more information about, greater confidence in, and a stronger basis for trust in the behavior of a binary than having access to the binary AND the source code used to build it?

Re: Gpg.fail

#326

Post by tptacek »

anonym29 wrote: post #325
tptacek wrote: post #323

Earlier quoted context omitted.

I see what's happening. You're working under the misapprehension that static analysis is only possible with source code. That's not true. In fact: a great deal of real-world vulnerability research is performed statically in a binary setting. There's a lot of background material I'd have to bring in to attempt to bring you up to speed here, but my favorite simple citation here is just: Google [binary lifter].

This assumption about me is not accurate at all, I've done static analysis professionally on CIL, on compiled bytecode, and on source code. Instead of being condescending and patronizing to someone you don't know that you've made factually inaccurate assumptions about, can you please explain how having just a binary and no access to source code gives you more information about, greater confidence in, and a stronger b…

I have no idea who you are and can only work from what you write here, and with this comment, what you've written no longer makes sense. The binary (or the lifted IR form of the binary or the control flow graph of the binary or whatever form you're evaluating) is the source of truth about what a program actually does, not the source code.

The source code is just a set of hints about what the binary does. You don't need the hints to discern what a binary is doing.

Re: Gpg.fail

#327

Post by amluto »

some_furry wrote: post #319
upofadown wrote: post #291

Earlier quoted context omitted.

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?

> How long should something like a key fingerprint be? At least 128 bits for most threat models. 192+ is preferable for mine. https://soatok.blog/2024/07/01/blowing-out-the-candles-on-th... My threat model assumes you want an attacker advantage of less than 2^-64 after 2^64 keys exist to be fingerprinted in the first place, and your threat model includes collisions. If I remember correctly, cloud providers assess mul…

> attacker advantage of less than 2^-64

Why so high? Computers are fast and massively parallel these days. If a cryptosystem fully relies on fingerprints, a second preimage of someone’s fingerprint where the attacker knows the private key for the second preimage (or it’s a cleverly corrupt key pair) catastrophically breaks security for the victim. Let’s make this astronomically unlikely even in the multiple potential victim case.

And it’s not like 256 bit hashes are expensive.

(I’m not holding my breath on fully quantum attacks using Grover’s algorithm, at high throughput, against billions of users, so we can probably wait a while before 256 bits feels uncomfortably short.)

Re: Gpg.fail

#328

Post by tptacek »

palata wrote: post #324
some_furry wrote: post #253

Earlier quoted context omitted.

> Which, from where I stand, means that PGP is the only viable solution because I don't have a choice. You don't have a choice today . You could have a choice tomorrow if enough people demanded it. Don't let PGP's convenience (in this context) pacify you from making a better world possible.

I agree with that. But I feel like I have been reading for years that there is really no reason to use PGP, and I have tried for years to use alternatives, but the fact remains that I still need to use PGP, either because it is mandatory or because in some cases the alternatives are not practical. To me, there will be no reason to use PGP the day I find practical alternatives for the remaining use-cases I have. And I…

Does the GnuPG project sign its git commits with PGP?

Re: Gpg.fail

#329

Post by technion »

fn-mote wrote: post #269
tptacek wrote: post #262

Earlier quoted context omitted.

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.

There is a downloadable binary, I doubt many people recommending age are recommending every server using it also download a Go compiler and build it themselves.

Re: Gpg.fail

#330

Post by ahlCVA »

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.

This is a per-credential setting, so you can have your SSH signing key be a no-touch key and still use touch confirmation for everything else.

(see "uv" option here https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-cl... - the -sk key types in SSH are just a clever way of abusing the FIDO protocol to create a signing primitive)

Post reply on HN