6,663 karma · joined February 25, 2016
Previously AWS Cryptography (2019 - 2023).
Unless otherwise stated, my opinions are my own and do not reflect my employer.
https://scottarc.blog/about/
Loss of control of the hard disks may have many different ways it can manifest in the real world, but from a cryptography and software development perspective, is congruent to other flavors of the same underlying problem.
That's not being "restrictive", it's recognizing the common denominator.
I've heard this quote a lot over the years, but the first person who said it was probably Lea Kissner, the former CISO of Twitter.
Here's their most recent post of the same statement: https://hachyderm.io/@leak/110784289970982813
The point of my article was not "Encryption-At-Rest Is Bad" as you seem to have taken it to mean.
Rather, the point is that other techniques, when you sit down and actually think them through, do not provide any significant value over just phoning it in with Full Disk Encryption.
How you get from "software libraries that encrypt-at-rest routinely fail to provide value on top of full disk encryption" to "Scott says FDE is bad" is unclear.
Additionally: From a software perspective, the risks you all outlined are morally equivalent to the hard drives grew legs and walked because they are the same risk; namely, loss of control of the actual hard drives.
The article in question is focused on threats when those drives are plugged in and the keys are being used to encrypt/decrypt data. As several others have pointed out already, I explicitly state this, repeatedly. I don't know how to make it more clear.
There are a lot of different approaches, but the one CipherSweet uses is actually simple.
First, take the HMAC() of the plaintext (or of some pre-determined transformation of the plaintext), with a static key.
Now, throw away most of it, except a few bits. Store those.
Later, when you want to query your database, perform the same operation on your query.
One of two things will happen:
1. Despite most of the bits being discarded, you will find your plaintext.
2. With overwhelming probability, you will also find some false positives. This will be significantly less than a full table scan (O(log N) vs O(N)). Your library needs to filter those out.
This simple abstraction gives you k-anonymity. The only difficulty is, you need to know how many bits to keep. This is not trivial and requires knowing the shape of your data.
https://ciphersweet.paragonie.com/security#blind-index-infor...
I proposed the same technique to AWS, who adopted it under the name Beacons for the AWS Database Encryption SDK.
https://docs.aws.amazon.com/database-encryption-sdk/latest/d...
Contrast JWTs with PASETO implementations when you make that sort of analysis.
i.e., pick any that support v3/v4 and try to attack them the same way that JWT implementations have been vulnerable, or worse ways: https://paseto.io
See, for example:
Implementing it securely, however, is far from dead simple.
https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l...
Could you provide some examples? I wrote a lot of PHP libraries over the years, and while some are definitely stale because nobody uses them (and thus I have no incentive to keep the lights on), the only time I see dead packages, they're actually forks of other open source software that people contributed exactly one commit to (to change the package name).
The implication is: This new insurance would be legally obligated to actually fund stuff.
Sure, with some caveats: You can scope it down to only very large companies very easily.
> They would pass the costs to customers. In essence, your suggestion leads to a Cyber tax collected by the IRS.
That's a bit oversimplified, I think. To the companies affected by the regulation, sure. Not every company would need to buy in. (At least, I hope not. Mom and pop shops aren't exactly flush with cash!)
> Next they have to divvy up the funding to pay OSS developers. Now you have the same problem you started with.
It's the spirit of the same problem, but the distribution is different.
Before, it's "make the US government funnel taxpayer dollars into OSS directly". Now it's "the US government forces megacorps to buy insurance, and the insurance companies figure out how to minimize risk by investing in the supply chain" one layer removed.
One reason why this might be better than the original version of the problem is that you can simply (but not easily; nothing in politics is ever easy) reproduce the same regulations and insurance business models in other countries, and the load is now balanced across the globe. Then the whims of individual countries' leadership is no longer a single point of failure.
In the abstract, you are correct. But the details matter.
Of course, I could be wrong. I'm not an expert on policy, economics, or law.
The legal/regulation problems here are valid concerns, but the model is a bit different.
The primary corruption of insurance has a lot to do with their ability to deny paying for what they ought to cover. That's a problem. The incentives at play pretty much guarantee it will always be a problem, for which strong regulations are necessary. We don't have strong regulations in the USA for e.g., health insurance, so I can understand why the word "insurance" is unattractive.
> Why this would work differently in the case of open source.
Great question.
The very incentive that makes insurance highly corrupt is what I'm proposing be leveraged to benefit open source developers.
A hypothetical insurance company would want to minimize their downside (paying money out), in order to maximize profits, because that's the economical system we live in today. The model I'm proposing is that investing in "the supply chain" would provide resources to offset risk.
On the other side, companies will want to minimize their spend on insurance. An insurance provider may offer reduced rates for companies that demonstrate some measurable commitment to security and responsible data handling practices (a.k.a. not collecting data they don't need in the first place, in case a breach does occur).
This insurance provides a currently absent mechanism for security assessors to affect positive change that protects the rest of us even if the company doesn't want to actually put in the effort.
That's why I proposed it as a contender.
Fair.
> This person/team used a VPN. Masking your location is a big red flag for just dev work like this. These things could be exposed in UI.
I disagree strongly, and am surprised to hear this argument on Hacker News of all places.
I don't believe that "identity verification" for F/OSS developers is a good idea. Suppliers? Sure. That can be a contract negotiation when you decide how much you pay for it.
Also, I don't think identity verification helps when your adversary is a nation state, which can just falsify government identification if it suits them.
[1] https://scottarc.blog/2024/04/04/open-source-supply-chains-a...
There's multiple factors behind this.
For one, the IETF already has a JOSE working group. This working group doesn't see it necessary to have a competing standard, and will stonewall any effort within the IETF to make a competing design. Dealing with their gatekeeping and tut-tutting over "why make a new design instead of just ironing out the deficits of JOSE?" is a full time job.
For the past few years, I've also not been able to email any IETF mailing list without Legal's permission from my employer. This is due to how broadly the IETF interprets "IP contribution". It was so stupid that I had to harass our IP lawyer for 2 weeks (in conjunction with a Sr. Principal Engineer who was deeply confused why they wouldn't even respond to my tickets, emails, or Slack messages) to get them to let me send an email to the COSE working group mailing list to inform them of a security footgun that was being proposed: https://mailarchive.ietf.org/arch/msg/cose/k6VnQkSNgyD1TsCMQ...
The permission I finally eeked out of Legal was only to send that initial message and nothing else, so Google's Sophie Schmieg had to fill in the blanks when they responded with questions: https://mailarchive.ietf.org/arch/msg/cose/BPKWnJraRblWEC9nu...
There are no technical reasons why there cannot be a PASETO RFC, or a PASERK RFC. The only objections are political or (from Amazon's side) very stupid.
I'm likely to be fired soon for refusing to relocate in accordance with Andy "Jasshole" Jassy's top-down RTT mandate, so I don't feel any incentive to hold my tongue on this matter.
I've personally given up on the IETF, and will instead be contributing PASETO and PASERK to the C2SP initiative, which I believe is more suitable for cryptographic specifications.
Systems thinking is broader in scope and responsibility. You're going to have to cross the rubicon eventually (unless all the software projects that hire you fail gloriously before they achieve any significant scale, I guess).
Code quality, best practices, etc. involve the same values and priorities as systems thinking, but is scaled down to a bus factor of 1. (i.e. the code you, personally, write or review).
Going beyond n=1 requires building mechanisms and guard-rails to prevent a failure of the individual level from affecting the larger system in a bad way. Thinking about it early won't significantly kneecap you from writing good code.
If it interests you, go for it.
The only reason you might not want to do so is if it doesn't interest you right now. You'll likely get there one day, once a project you care about scales up enough.
The notion that priests and monks should be holier than the common folk strikes me as very Abrahamic. This forms a hierarchy in the mind.
I'm not a Buddhist, but if I were, I would interrogate (and probably reject) such hierarchies.
The strpos() check just prevents the IV from containing ::
No. This is security theater, and it stands as an obstacle to security. They were better off with plaintext.
> I could set my bar higher, but for living in the real world and that a higher bar would conflict with the high bar of assuming people are of good will and doing the best they can.
Or you could just point PHP developers to my open source libraries, which have a cost of $0.00 to use and are actually secure?
Your bar should be a little higher.
> I mean any sophisticated adversary will use the traditional methods of bribery and coercion with violence to obtain intelligence and influence the course of events.
Okay, but we're not talking about someone who failed to meet an ultra paranoid threat model. We're discussing an encryption technique that can be bypassed by anyone who bothered to do the first 2 sets of the cryptopals challenges.
> Yes it doesn't handle an edge case in the same way body armor doesn't handle a 20mm depleted uranium chain gun, but it probably handles the likely threats well enough.
The edge case is "someone with any knowledge about applied cryptography decided to kick the tires, even if only for the laughs". The code is that bad.
I don't know what their PHP configuration is set to in production.
As a rule, I don't test systems that require me to send packets. I only look at code. This keeps me from having to care about the Computer Fraud and Abuse Act.
What I know: The particular bit of code that Paul tweeted is vulnerable, and the mitigation you're asking about only reduces it from a "grep the HTTP response body" oracle to a timing oracle, so it doesn't actually eliminate the issue.
Yes, their fucking thing is vulnerable, because of how PHP + ext/openssl handles padding errors by default. They can mitigate this behavior by suppressing error reporting, but the underlying behavior will still be observable later in the application when `false` is provided instead of a string.
To trigger the vulnerability, you would need the ability to modify a ciphertext. This requires privileged access to where the encrypted data is stored.
Exploit procedure:
1. Modify ciphertext
2. Access PHP script that processes said ciphertext under-the-hood
3. Did it spit out a PHP error?
* Yes -> Invalid padding
* No -> Valid padding
I don't generally write articles with the premise that my audience needs every logical conclusion spoon-fed to them.
> I note that you have not explicitly stated that the system is susceptible to a padding oracle attack either. That's because you have read the same article and can not.
I wrote it, actually.
I posted a link to a Getting Started guide in my comment above.
Once you've exhausted those resources, your best bet is to join a cryptography team at a tech company to round off your education with some real-world experience.
For example, https://www.amazon.jobs/en/search?business_category[]=amazon...
> Well was this particular system actually vulnerable to a padding oracle attack?
Yes. That's what the thing you just quoted says.
This isn't a theoretical leap, either. It's unauth CBC with PKCS#7 padding with OpenSSL's API.
> I hate these security writeups that prime the reader but never actually get to the punch line.
But it did. "X uses Y which is vulnerable to Z" does, emphatically, state that X is vulnerable to Z. Your rant is unnecessary.