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

351–360 of 376 posts

Re: Gpg.fail

#351

Post by palata »

ahlCVA wrote: post #330
palata wrote: post #227

Earlier quoted context omitted.

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)

Oh, I need to check this! Thanks!

Re: Gpg.fail

#352

Post by jedisct1 »

raphinou wrote: post #199

I'm working on a multi sig file authentication solution based on minisign. Anyone knows the response of the dev regarding minisign's listed vulnerability? If I'm not mistaken, the response of the authors are not included in the vulnerabilities' descriptions.

Because the authors found out about it by chance on Hacker News.

That said, these issues are not a big deal.

The first one concerns someone manually reading a signature with cat (which is completely untrusted at that stage, since nothing has been verified), then using the actual tool meant to parse it, and ignoring that tool’s output. cat is a different tool from minisign.

If you manually cat a file, it can contain arbitrary characters, not just in the specific location this report focuses on, but anywhere in the file.

The second issue is about trusting an untrusted signer who could include control characters in a comment.

In that case, a malicious signer could just make the signed file itself malicious as well, so you shouldn’t trust them in the first place.

Still, it’s worth fixing. In the Zig implementation of minisign, these characters are escaped when printed. In the C implementation, invalid strings are now rejected at load time.

Re: Gpg.fail

#353

Post by tptacek »

upofadown wrote: post #245
jcranmer wrote: post #103

Earlier quoted context omitted.

Don't you think it's time to update it, given you start by saying that "If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument"? Because you're clearly presenting it as a defense of PGP on a thread from a presentation clearly delineating breaks in it using exactly the kind of complex…

The mechanical analogy is particularly interesting here because at least one of the claimed vulnerabilities involves tricking the victim into decrypting an encrypted message for the attacker and then sending it to them. If someone can be tricked into opening a safe to let the burgler rummage around inside then few would consider that a failure of the safe technology. I mean there is still a problem there but it is a…

The constraint that you have implicitly applied to cryptosystems forecloses on using GPG as a base layer in other computing systems; in your view, GPG is a "safe", which can only be opened by the owner of the contents to retrieve and remove those contents.

Re: Gpg.fail

#354

Post by upofadown »

Valodim wrote: post #347
upofadown wrote: post #343

Earlier quoted context omitted.

Yes, the OpenPGP standards schism was all about personality conflicts. Those conflicts still came from a fundamental difference of philosophy. Who's idea was it to have Koch lead the most recent attempt at a process? Why was that supposed to make a deadlocked process somehow work? None of this matters now. Everyone is cheerfully walking into an interoperability disaster that will cause much harm. There isn't any real…

Sorry, but no. This is not a 50/50 situation where a bonkers position is inexplicably backed by half the populace. There is one faction that is a single person on a large lever, and another who are everybody else . Werner made it clear he will accept nothing less than an unquestioning BDFL hierarchy, but has over many years demonstrated no competence to actually fill that role (TFA being a small example of this).

This is not about what is most popular. This is about what can work. The current situation can not work.

Re: Gpg.fail

#355

Post by Arathorn »

goldsteinq wrote: post #341
Arathorn wrote: post #336

Earlier quoted context omitted.

Weird. Encryption these days (in Element Web/Desktop and Element X at least) should be pretty robust - although this whole identity reset thing is a known bug on Element Web/Desktop. You can submit debug logs from Settings: Help & About: Submit Debug Logs, and hopefully that might give a hint on what's going wrong.

No “Submit Debug Logs” there, as far as I can see. Do I need to be on matrix.org homeserver for this to work or something? https://photos.goldstein.lol/share/OIgowBN4Wmi4zlm8DmDP0s8jH...

looks like whoever’s run that Element has disabled debug log reporting. not sure i can do much to help here :/

Re: Gpg.fail

#356

Post by pseudohadamard »

some_furry wrote: post #254
xeonmc wrote: post #191

Earlier quoted context omitted.

offtopic question: as a recent dabbling reader of introductory popsci content in cryptography, I've been wondering about what are the different segmentation of expert roles in the field? e.g. in Filippo's blogpost about Age he clarified that he's not a cryptographer but rather a cryptography engineer, is that also what your role is, what are the concrete divisions of labor, and what other related but separate positio…

My job title is in the Security Engineer family. I do not have a Ph.D in Cryptography (not even an honorary one), so I do not call myself a Cryptographer. (Though I sometimes use "Cryptografur" in informal contexts for the sake of the pun.)

What you actually want doing crypto is a security engineer, not a cryptographer. To quote Shamir's Law, "cryptography is bypassed, not attacked". No-one ever attacks the crypto, they attack the way it's used, so you need an experienced cryptoplumber to set it up correctly, not a cryptographer who will design a mathematically elegant whatsit and announce "there, solved!".

Ideally, this person will also design the system that uses the crypto, because no matter how skilled the people on a standards committee might be their product will always be, at best, a baroque nightmare with near-infinite attack surface, at worst an unusable pile of crap. IPsec vs. Wireguard is a prime example, but there are many others.

Re: Gpg.fail

#357

Post by pseudohadamard »

johnisgood wrote: post #108
some_furry wrote: post #102

Earlier quoted context omitted.

> I need an alternative to "gpg --encrypt --armor --recipient " That's literally age. https://github.com/FiloSottile/age

No, because there is no keyring and you have to supply people's public key each time. It is not suitable for large-scale public key management (with unknown recipients), and it does not support automatic discovery, trust management. Age does NOT SUPPORT signing at all either.

And when do you need any of that stuff?

As a followup, is there anything in existence that supports "large-scale public key management (with unknown recipients)"? Or "automatic discovery, trust management"? Even X.509 PKI at its most delusional doesn't claim to be able to do that.

Re: Gpg.fail

#358

Post by pseudohadamard »

benchloftbrunch wrote: post #239
tptacek wrote: 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?

Something that doesn't require securing email. Both S/MIME and PGP were solutions for 1980s problems (TFA is slightly off about PGP's start date, the PGP design dates from 1987 and MSDOS, not the 1990s, and S/MIME via PEM is from 1986). They're pretty much irrelevant today because almost all email is encrypted anyway via StartTLS and if you need full end-to-end encryption you use Signal or something similar.

Re: Gpg.fail

#359

Post by pseudohadamard »

Natanael_L wrote: post #294
benchloftbrunch wrote: post #239

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?

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

Use case? We're crypto LARPing dammit, we don't need a use case!
Post reply on HN