CiPHPerCoder

However, donating money to an open collective is prohibitively hard for most big companies.

You are absolutely correct. However, that's the mechanism that Frank has made available, and that's what the comment I was replying to was asking, so I was just connecting the dots between the question and answer.

Did you also check all of the libraries that implement the check differently to libsodium?

Yes, but it was a breadth-first search sourced from the ianix webpage, so I certainly missed some details somewhere. I'll continue to search over the coming weeks in my spare time (if I can get any).

I found several libraries that simply didn't implement the check, but none that implemented in incorrectly in the same way as the vulnerability discussed above.

If you didn't receive an email from me, either your implementation isn't listed on https://ianix.com/pub/ed25519-deployment.html, I somehow missed it, or you're safe.

From the article:

  If libsodium is useful to you, please keep in mind that it is maintained by one person, for free, in time I could spend with my family or on other projects. The best way to help the project would be to consider sponsoring it, which helps me dedicate more time to improving it and making it great for everyone, for many more years to come.

Hope that helps.

This also affected the PHP library, sodium_compat. https://github.com/FriendsOfPHP/security-advisories/pull/756

I'm planning to spend my evening checking every other Ed25519 implementation I can find to see if this check is missing any where else in the open source ecosystem.

Most people don't make their spam public, but I did when I ran this bounty program:

https://hackerone.com/paragonie/hacktivity?type=team

The policy was immediate full disclosure, until people decided to flood us with racist memes. Those didn't get published.

Some notable stinkers:

https://hackerone.com/reports/149369

https://hackerone.com/reports/244836

https://hackerone.com/reports/115271

https://hackerone.com/reports/180074

It's just an Ed25519 signature of a file. The closest thing we have to runtime code-signing are Phar signatures. https://www.php.net/manual/en/phar.fileformat.signature.php

While I appreciate the sentiment, I don't know that a hard fork is necessarily the right answer.

https://scottarc.blog/2024/10/14/trust-rules-everything-arou...

I'd been staying out of this conflict, partly because I'm not really in the know on WP Engine's behavior behind-the-scenes and, as weird as Mullenweg's plays have been, I don't like to comment on things I'm not fully read into.

But, this touches on a particular hobby horse of mine. It involves some old conflicts too, but I don't want to ruminate on them.

From about 2016 to 2019, I was heavily involved with trying to remedy what I considered an existential threat to the Internet: WordPress's auto-updater.

https://core.trac.wordpress.org/ticket/25052 + https://core.trac.wordpress.org/ticket/39309

If that sounds alarming, consider the enormity of WordPress's market share. Millions of websites. W3Techs estimates it powers about 43% of websites whose server-side stack is detectable. At the time, it was a mere 33%.

https://w3techs.com/technologies/overview/content_management

For the longest time, the auto-updater would pull an update file from WordPress.org, and then install it. There was no code-signing of any form until I got involved. So if you pop one server, you get access to potentially millions.

Now imagine all of those webservers conscripted into a DDoS botnet.

Thus, existential threat to the Internet.

Eventually, we solved the immediate risk and then got into discussing the long tail of getting theme and plugin updates signed too.

https://paragonie.com/blog/2019/05/wordpress-5-2-mitigating-...

https://core.trac.wordpress.org/ticket/49200

You can read my ideas to solve this problem for WordPress (and the PHP ecosystem at large) here: https://gossamer.tools

Here's the part that delves into old drama: Mullenweg was so uncooperative that I wrote a critical piece called #StopMullware (a pun on "malware") due to his resistance to even commit to solving the damn problem. On my end, I reimplemented all of libsodium in pure PHP (and supported all the way back to 5.2.4 just to cater to WordPress's obsession with backwards compatibility to the lowest common denominator), and just needed them to be willing to review and accept patches. Even though I was shouldering as much of the work as I logically could, that wasn't enough for Matt. After he responded to my criticism, I took it down, since he committed in writing to actually solving the problem. (You can read his response at https://medium.com/@photomatt/wordpress-and-update-signing-5... if you care to.)

The reason I'm bringing this old conflict up isn't to reopen old wounds. It's that this specific tactic that Mullenweg employed would have been mitigated by solving the supply chain risk that I was so incandescent about in 2016.

(If you read my proposals from that era, you'll notice that I cared a lot about the developers controlling their keys, not WordPress.)

I don't keep up-to-date on Internet drama, so maybe someone already raised this point elsewhere. I just find it remarkable that the unappreciated work for WordPress/PHP I did over the years is relevant to Mullenweg's current clusterfuck. Incredible.

Since my knowledge on the background noise that preceded this public conflict is pretty much nil, I have no reason to believe WP Engine hold any sort of moral high ground. And I don't really care either way.

Rather, I'd like to extend an open invitation: If anyone is serious about leading the community to fork off WordPress, as I've heard in recent weeks, I'm happy to talk at length about my ideas for security enhancements and technical debt collection. If nothing else comes of this, I'd like to minimize the amount of pain experienced by the community built around WordPress, even if its leadership is frustrating and selfish.

There is not any reason to NOT run hybrid cryptography schemes right now, when the use case allows for it.

This is reasonable, but runs contrary to the stance taken by CNSA 2.0.

All the criticism of cryptographic agility that I have seen has involved an attacker negotiating a downgrade to a broken protocol.

Consider this an additional data point, then: https://paragonie.com/blog/2019/10/against-agility-in-crypto...

In the years since I wrote that, several people have pointed out that "versioned protocols" are just a safe form of "crypto agility". However, when people say "crypto agility', they usually mean something like what JWT does.

What JWT does is stupid, and has caused a lot of issues: https://www.howmanydayssinceajwtalgnonevuln.com/

If you want to use JWT securely, you have to go out of your way to do so: https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l...

But if the protocol is not yet broken, then being agile isn't a concern, and if/when the protocol does become broken, then you can remove support for the broken protocol, which is what you'd be forced to do anyway, so a flexible approach just seems like a more gradual way to achieve that future transition.

This makes sense in situations where you have versioned protocols :)

This doesn't work if you're required to support RSA with PKCS1v1.5 padding until the heat death of the universe.

Thanks for the feedback. I'll add a note after that section to make sure it's referenced appropriately.

And especially thanks for taking the time to share your experiences and observations with me. That's how I improve as a writer.

A lot of posters here are fixating too much on the "stolen hard disk" picture which I think the article addressed by declaring it out of scope. So the real points aren't getting through.

This is a crypto nerd blog post though. The whole point is to talk about cryptographic library design!

Sure, that's why I addressed the government in the immediate statement that followed the thing you quoted.

Okay, this sounds vaguely like a problem that may be solved by "HPKE where the secret key is reconstructed from a threshold secret sharing scheme" (>=2 of N shares needed, 1 held by the service and 1 held by the employee's hardware device, where 1 additional share is held in cold storage for break-glass reasons).

I would need to actually sit down and walk through the architecture, threat model, etc. to recommend anything specific. I'm not going to do that on a message board comment, because I probably am missing something.

So I'm not so sure what's the point of encryption at rest in AWS except just to tick off a compliance and regulatory checklist.

The private key is with them anyway, just don't encrypt and save few milliwatts of power.

"Them" is Amazon, a company with over 1 million employees, last I checked.

It's perfectly reasonable to trust the KMS team to keep your keys secure, even if you don't trust the RDS team to never try to look at your data.

I know it's tempting to think of all of AWS as a sort of "Dave" who wears multiple hats, but we're talking about a large company. Protecting against other parts of the same company is still a worthwhile and meaningful security control.

The author is confusing "it costs us nothing (now that encryption can be done in hardware and is integrated into most desktop operating systems) and protects in some scenarios, so yeah, we just decided to mandate it always be done" with "PEOPLE THINK ENCRYPTION AT REST IS A MAGIC BULLET LOOK AT ME I'M INSIGHTFUL, POST LINKS TO MY BLOG ON LINKEDIN!"

What in the article gave you that impression?

I do not hold this confusion in my mind, nor did I deliberately encode such a statement in my blog. I'm curious why you think this is what I was saying.

The whole post is insulting to the intelligence of even a fairly junior desktop support technician.

If that was true, every time someone posts "Show HN: My Hot New Database Encryption Library in Haskell", they would be mitigating the confused deputy attack by design, rather than what we see today: Namely, failing to even protect against padding oracle attacks.

That's what the article was actually talking about.

If you're using a secure disk encryption technology, and you manage to clear the keys from the TPM or overwrite the header containing the KDF salts and other metadata, that should render the device data unrecoverable.

I find it very hard to believe Amazon's or Google's servers do not already have full disk encryption.

I am confident that they do. Even better, they can be configured to use your KMS key rather than the service key, and you can configure KMS to use external key stores (i.e., an HSM in your datacenter outside of AWS's control, that you could theoretically pull the plug on at any time).

Doing things that outwardly appear to improve security but have de minimus or less effect on actual security.

Right. And that's exactly the situation the article describes.

The accusation of "security theater" was only levied when IT departments reached for the "full disk encryption" potion to mitigate the ailment of "attacker has active, online access to our database via SQL injection", when that's not at all what it's designed to prevent.

They can insist that they're "encrypting their database", but does it actually matter for the threats they're worried about? No. Thus, security theater.

The same is true of insecure client-side encryption.

This is an interesting and important point that you raised.

if you're storing the data on AWS and generating your keys on AWS and managing your keys with AWS ... you're doing it wrong.

This is a reasonable thing to do if you've decided that you trust AWS and expect any violations of this trust to be dealt with by the legal department.

It's less reasonable if you're concerned about AWS employees going rogue and somehow breaking the security of KMS without anyone else knowing.

It's even less reasonable to do this if you're concerned about AWS credentials being leaked or compromised, which in turn grants an attacker access to KMS (i.e., a government would be more successful by compelling IAM to grant access than they would trying to subpoena KMS for raw keys).

(Sure, you can audit access via CloudTrail, but that's a forensics tool, not a prevention tool.)

But that's kind of the point I wrote in the article, no? You need to know your threat model. You've stated yours succinctly, and I think it's a commendable one, but many enterprises are a bit more relaxed.

What's the best practice in managing user data keys so that data is available only when there's an authenticated user around?

What does it mean for an authenticated user to be "around"?

If you want a human to manually approve the decryption operations of the machine, but it can still store/encrypt new records, you can use HPKE so that only the person possessing the corresponding secret key can decipher the data.

At least, you can until a quantum computer is built.

Obvious limitations is that you can't use the fields for sorting in queries (ORDER BY), and depending if deterministic encryption is not enabled, you can't use it in filters (WHERE) either. Same applies for any T-SQL logic on the data fields - because the encrypted blob is opaque to SQL Server - it is decrypted client-side. There is no workaround, except for pulling the data locally and sorting client-side.

This is a reasonable limitation when you're aware of the attacks on Order Revealing Encryption: https://blog.cryptographyengineering.com/2019/02/11/attack-o...

The thing that's security theater isn't encrypting at rest in general.

The thing that's security theater is encrypting insecurely, or failing to authenticate your access patterns, such that an attacker with privileged access to your database hardware can realistically get all the plaintext records they want.

Andy Jassy decided that it was time to Return To Office.

I was hired in 2019 as a fully remote employee. This means my options in 2023 were a) move to Seattle or b) walk. I chose to walk.

The leadership of the Cryptography org fought tooth and nail to get an exception for me, but were unable to do so. I still hold everyone in AWS Cryptography in high regard.

Thanks for clarifying, and confirming at least one of my suspicions.

All I can say here is, "Yikes."

If you (or, well, anyone) ever need an honest third party to audit a cryptography design--whether it's because you suspect bullshit or just want assurance that it's actually a good design--talk to the Crypto team at Trail of Bits.

https://www.trailofbits.com/services/software-assurance/cryp...

I wonder if OP works in healthcare

No, I work in applied cryptography.

When I joined Amazon, the team I was hired on was called AWS Crypto Tools (which owned the AWS Encryption SDK, among other developer tools), while another team was called Transport Libraries (which owned S2N).

When I left in 2023, they started adopting more of the "Encryption At Rest" lingo for what was previously called Crypto Tools. I don't know if they landed on different verbage since then.

after HIPAA passed encryption at rest was the buzz word of the decade as it was one of the primary requirement of HIPAA.

Interesting. Thanks for sharing.

The main threat to encrypting health information is actually dishonest cryptographers.

Wow, okay, you have me hooked.

instead of searching for user Michael Knight in a database of cancer patients, you hash the name, use a bloom filter to determine if the hash exists in the protected data set or not

The protocol you loosely described here could be either totally fine or horrendously broken depending on the implementation details and architecture of the application. Not to mention the universal cryptography concerns; i.e., key management.

and then tell your regulators and the public that the foreign jurisdiction research assistants hired from fiverr don't have access to your health information because everything is encrypted and we only compare hashes.

You've said "hashes" twice now, so I have to ask:

1. Are they only hashing, or are they using a keyed hash (e.g., HMAC)?

2. Are they doing something ridiculous like using MD5?

If you're familiar with cryptography at all, passing around MD5(data) is vastly different from truncating HMAC-SHA384(data, staticKey) to a few bits and protecting staticKey with an HSM.

Without more detail, I can't tell if your assertion that cryptographers are being dishonest is warranted. It's sort of like simplifying RSA encryption to "multiplying integers". Yes, that's what's happening on some level, but some essential information was omitted.

That said, it would be helpful for us i² [i squared] folks to have some of the more basic terms explained. Although "encryption at rest" is somewhat understandable, it would be pleasant to have it explained.

That's helpful feedback, actually. What terms seemed opaque or misleading to you as you read it? I'm always happy to fix mistakes in blog posts to improve clarity.

For example what are the other kinds?

I contrast "encryption at rest" with "encryption in transit" (i.e., TLS) and "end-to-end encryption" (E2EE for short; i.e., what Signal gives you).

Are you the author of the paragonie website? The coincidence was startling. If so, I greatly thank you for the resource.

Thanks. Yes, I'm one of the authors.