Why is proprietary #software so bad and full of #vulnerabilities?

The sales department probably doesn't know any better and only has its commission in mind and just sells the software, that's their job. I'm not so sure about the management, whether they are clueless or just think that no matter how bad the software is, we can earn even more money with support contracts. There are certainly a few clueless developers who are kept so busy that they barely manage to complete their tasks but have no time for quality assurance. However, a large part of the developers will realize what is being played and then either change jobs after 2 years if it becomes unbearable or try to justify the quality of the software according to the motto it is a feature and not a bug. Ultimately, the only option left to cybersecurity is to secure vulnerable software with supposedly better security software. Bugs are not fixed unless public pressure is so strong that it is unavoidable and with one fixed bug, three new ones are installed. The supposedly secure security software all too often turns out to be snake oil, which only brings further security risks, which then have to be secured by further security software and you find yourself in a never-ending cascade, which becomes ever more dangerous and expensive but brings no security gain. There is even a technical term for this, called security theater. At the end of the day, all the management wants to say in its press release is that the hackers were diabolical criminals and probably had state support, but that the company had done everything it could to defend itself with the latest security software. The starting position is therefore clear. There is money to be made from security vulnerabilities and proper security means a lot of work. Economic considerations are therefore made here, according to which quality assurance can be saved because the customer can find and report the errors after all.

I'm pretty sure I'm not the smartest or the best developer, but I've figured it out and I'm always surprised that I often meet colleagues who are very confident about cybersecurity in the company because there is security training every year. I don't see any possibility of developing secure software at all under capitalism because profit is always valued higher than security.

#developer #management #economy #capitalism #profit #finance #security #cybersecurity #bug #fail #system #problem #hack #hacker #malware

What To Use Instead of PGP

It’s been more than five years since The PGP Problem was published, and I still hear from people who believe that using PGP (whether GnuPG or another OpenPGP implementation) is a thing they should be doing.

It isn’t.

I don’t blame individual Internet users for this confusion. There is a lot of cargo-culting around communication tools in the software community, and the evangelists for the various projects muddy the waters for the rest of us.

Harubaki

The part of the free and open source software community that thinks PGP is just dandy, and therefore evangelize the hell out of it to unsuspecting people, are the same kind of people that happily use XMPP+OMEMO, Matrix, or weird Signal forks that remove forward secrecy and think it’s fine.

Not to mince words: The same people who believe PGP is good are also famously not great at cryptography engineering.

If you’re going to outsource your opinions on privacy technology to someone else, make sure it’s someone who has actually found vulnerabilities in cryptographic software before. Most evangelists have not.

CMYKat

I’m not here to litigate the demerits of PGP. The Latacora article I linked above makes the same arguments I would make today, and is a more entertaining read.

It is of my opinion as a security engineer that specializes in applied cryptography that nobody should use PGP, because there’s virtually always a better tool for the job you want to use PGP for.

(And for the uncommon use cases, offering a secure, purpose-built replacement is a work-in-progress.)

Note: I’m deliberately being blunt in this post because literally more than a decade of softspokenness from cryptography experts has done nothing to talk users off the PGP cliff. Being direct seems more effective than being tactful.

If you want a gentler touch, ask your cryptographer. If you don’t have a cryptographer, hire one.

If you can accept that every billionaire is the result of a failed system, that’s how cryptographers feel about people using PGP.

Instead, let’s examine the “use cases” of PGP and what you should be using instead. (Some of this is redundant with the Latacora article, but I’m also writing it 5 years later, so some things have changed.)

CMYKat

Instead of PGP, Use This

This section contains specific tools to solve the same problems that PGP tries to solve, but better.

What makes these recommendations better than PGP?

Simply, they don’t make cryptographers want to run the other way screaming when they look under the hood. PGP does.

Some people are forced to use PGP because they work for a government that legally requires them to use PGP. In that corner case, your hands are tied by lawyers, so you don’t need to bother with what cryptographers recommend.

CMYKat

Signing Software Distributions

Use Sigstore.

Note that this is an ecosystem-wide consideration, not something that specific individuals must manually opt into for each of their hobby projects. The only downside to Sigstore is it hasn’t been widely adopted yet.

If you’re a Python developer, you can just use PEP 740 to get attestations with Trusted Publishers, which gives you Sigstore for free. For most developers, this is as simple as setting up a GitHub Action to publish to PyPI.

This is a developing trend: Other programming language and package management ecosystems are following suit. I expect to see Sigstore attestations baked into NPM and Maven before the next US presidential election. With any luck, your favorite programming language could be on this list too.

Sigstore doesn’t just give you a signature that you check with a long-lived public key, nor does it require you to do the Web Of Trust rigamarole.

Rather, Sigstore gives you a lot for free. Sigstore was designed around ephemeral signing certificates rather than a long-lived private key. It was purpose-built for preventing supply-chain attacks against open source software.

Combined with Reproducible Builds, Sigstore solves the triangle of secure code delivery.

Alternatively, use minisign. If your package ecosystem doesn’t support Sigstore yet, you can get by with minisign (which is signify-compatible) until they modernize.

You can also use SSH signatures, if you’d prefer. (More on that below.)

CMYKat

Signing Git Tags/Commits

Use SSH Signatures, not PGP signatures.

With Ed25519. Stop using RSA.

Art by Harubaki

Sending Files Between Computers

Use Magic Wormhole.

You could also use SSH + rsync to do this job. That’s fine too.

CMYKat

Encrypting Backups

Tarsnap is the usual recommendation here.

There are a lot of other encrypted backup tools that work fine, if you don’t want to give Colin Percival your business. I don’t have a financial stake in any of them, nor have I audited them thoroughly.

Borg uses reasonable cryptography, but I haven’t had the time to review it carefully.

Kopia looks fine, but I really hate that they misuse “zero knowledge” to describe an encryption protocol (rather than a proof system). We should not reward this misbehavior by marketers.

The point is: You’ve got options.

Too many options, in my opinion, to settle for PGP.

CMYKat

Encrypting Application Data

Use Tink or libsodium.

Avoid: OpenPGP, OpenSSL and its competitors.

Not a lot to say here. I’ve written a lot about this over the years. Misuse-resistant cryptography libraries–especially ones that make key management less painful for users–are the way to go.

Harubaki

Encrypting Files

Use age.

Age is what PGP file encryption would be if PGP didn’t suck shit.

Age has two modes: Public-key encryption, and password-based key derivation.

Here’s a quick comparison table between what age offers, and what PGP uses in the installed base:

Like, it’s not even close.

CMYKat

Some PGP proponents will insist that AEAD is possible now, but as long as the installed base of PGP remains backwards compatible with the lowest common denominator, that’s what your software uses.

Just use age. Or rage, if you’re a Rust enthusiast.

(And if you have concerns about “which age key should I trust?”, I’m already planning an age-v1 extension for the Public Key Directory project. More on that below.)

Art by Scruff

Private Messaging

Use Signal.

Security teams around the world insist that they need PGP for bug bounty submissions or security operations, but Signal does this job better than PGP ever did.

Once upon a time, you needed to give people a phone number to use Signal, but that hasn’t been the case for a long time. Still, many people have missed that memo and think it’s a requirement.

My Signal username is soatok.45. Go ahead and message me. You won’t learn my phone number that way.

In the near future, I plan on developing end-to-end encryption for direct messages on the Fediverse (including Mastodon). This is what motivated my work on the Public Key Directory to begin with.

But this is not intended to be a Signal competitor by any measure. It’s a bar-raising activity, nothing more.

CMYKat

Miscellaneous PGP Alternatives

This section contains things people think they need PGP for.

Identity Verification

I’m actively working on something better!

via XKCD

If you want the ability to vend a transparently verifiable public key for a given user, that’s one of the use cases for the Public Key Directory I’m designing in order to build end-to-end encryption for the Fediverse.

Although this is purpose-built for the Fediverse, I’ve deliberately included support for Auxiliary Data messages, whose formats will be specified by protocol extensions.

Rather than trying to grok the Web-of-Trust, you can simply have your software check that multiple independent Public Key Directories have verified the record, since its inclusion is published in an append-only transparency log, secured by a Merkle tree.

My design doesn’t preclude any manual key verification, or key-signing parties, or whatever other PGP cultural weirdness you want to do with these public keys. It just establishes a baseline trustworthiness even if you’re not a paranoid computer nerd.

My project isn’t finished yet. In the meantime, you can manually check public keys when using the other recommendations on this page.

Harubaki

Encrypted Email

Don’t encrypt email. From the Latacora article:

Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.

There isn’t a recommendation for encrypted email because that’s not a thing people should be doing.

Art by AJ

Now, there exists a minority of extremely technical computer user for which Signal is a nonstarter (because you need a smartphone and valid phone number to enroll in the first place).

Because those people are generally not the highest priority of cryptographers (who are commonly focused on the privacy of common folk–including people in poor and developing countries where smartphones are more common than desktop computers), there presently isn’t really a good recommendation for private messaging that meets their constraints.

Not Matrix.

Not XMPP+OMEMO.

Certainly not PGP, either.

What PGP offers here is security theater: the illusion of safety. But it’s not actually a robust private communication mechanism, as Latacora argues.

CMYKat

“I insist that I need encrypted email!”

If you find someone insisting that they “need” encrypted email, read up on the XY Problem. In a lot of cases, that’s what’s happening here.

Do they ipso facto need email (as in, specifically the email protocols and email software)?

And do they care more about this constraint, or the privacy of their communications?

Because if their goal just to communicate privately, see above.

If the tool they’re using being email is more important than privacy, they should consider sending empty messages with an attachment, and use age to encrypt the actual message before attaching it.

That’s serviceable, just beware that everything Latacora wrote about encrypted emails still applies to your use case, so expect someone to CC or forward your message as plaintext.

(Unless you’re legally required to use PGP because of a government regulation… in which case, why do you care about my recommendations if you’re chained by the ankle to your government’s bad technology choices?)

Finally, miss me with the “but someone can screenshot Signal” genre of objections.

As Latacora noted, people accidentally fuck up PGP all the time! It’s very easy to do.

Conversely, you have to deliberately leak something from Signal. There is no plaintext mode.

That’s the fucking bar you need to meet to compete with Signal.

PGP fails to be a Signal competitor, in ways that are worse than Threema, Matrix, or OMEMO.

Watch This Space

With all that said, I am actually designing an encrypted messaging protocol that will have an email-like user experience, except:

1. Everything is always end-to-end encrypted, with forward secrecy.
2. It’s not backwards compatible with insecure email.
3. It doesn’t use PGP, or any 1990’s era cryptography.

I can’t promise a release date yet. I’m prioritizing end-to-end encryption for the Fediverse before I write the specification for that project (tentatively called AWOO, but the cryptography underpinning both projects should be similar).

Maybe 2026? We’ll see!

If someone beats me to the punch, and their design is actually good, I’ll update the post and replace this with a specific recommendation.

CMYKat

Against PGP

I don’t know how to get the message out louder or clearer about how cryptographers feel about PGP than what I wrote here.

Latacora wrote their criticism in 2019. As I write this, 2024 is almost over. When will the PGP-induced madness end?

CMYKat

Header art credits: CMYKat and the GnuPG logo.

Update (2024-11-16)

Someone tried to use their Fediverse software to submit an anti-furry comment to this blog post.

Therefore, I’ve added more furry art to it.

loviesophiee

#alternatives #codeSigning #digitalSignatures #encryption #PGP #security #SecurityGuidance #signing