I wouldn’t consider that a conspiracy theory, I would consider it common sense that an intelligence agency has a list of common potential sources of intelligence.
In fact it would be extremely surprising if they didn’t have that list.
I think GP was drawing a parallel between Euclid’s fifth axiom of and results like Banach-Tarski since the fifth axiom is independent of the other four, and Bnach-Tarski follows from the Axiom of Choice which is independent of the rest of set theory.
I think the comment well addresses why this situation is different than the situation with banks - Boeing’s manufacturing and employees would not be harmed by a prosecution of its management.
Indeed, criminally charging upper management hardly counts as the business “failing” at all.
AFAIK there is no general purpose, "do this on the ANE" API. You have to be using specific higher level APIs like CoreML or VisionKit in order for it to end up on the ANE.
Notwithstanding the fact that compilers did not fall out of the sky and very much have people that own them at the cognitive level, I think this is still a different situation.
With a compiler you can expect a more or less one to one translation between source code and the operation of the resulting binary with some optimizations. When some compiler optimization causes undesired behavior, this too is a very difficult problem to solve.
Intentionally 10xing this type of problem by introducing a fuzzy translation between human language and source code then 1000xing it by repeating it all over the codebase just seems like a bad decision.
Right. I mean... I sometimes think that Webpack is a malign, inscrutable intelligence! :-)
But at least it's supposed to be deterministic. And there's a chance someone else will be able to explain the inner workings in a way I can repeatably test.
In web applications and cloud services drives could still be misplaced, stolen, or improperly disposed of.
Further, if data is encrypted at rest then there are multiple levels of auth that must fail for a breach to occur, namely access to the data and access to the key.
Definitely true and a layered defense against data loss / theft has obvious advantages. But take for instance a small SaaS running on a cloud PaaS (e.g., AWS, GCP etc). What it the likelihood of improper disposal of a hard disk? And then what is the likelihood this improperly disposed of hard disk survives the process of removal / improper disposal to then be found by someone nefarious? And then, what is the likelihood that that particular drive was in a volume that contained anything sensitive.
Then what is the cost / overhead / complexity / other cons of adding encryption at rest? Cyber budgets often go crazy I see so many clients that are buying tech based on marketing hype or the security teams lusts for cool tech rather than what reduces the risk the most for the dollars available.
Last time I implemented encryption at rest (when I worked for a small cloud provider), it was as easy as adding an option when creating the disk.
The option triggered the implementation of a dm-crypt layer between the physical device and the upper storage layers. Crypto keys were stored in the storage system. Once revoked, the whole server was rendered useless (from a data thief point of view).
We benchmarked the stuff a bit. Indeed, there was a loss. While dm-crypt uses AES (with hardware acceleration) and since we had multi-hundreds of thousands IOPS per device, we did not care.
While threat modeling, you talk about specific scenarios and specific threats. That does not mean other scenarios and threats don't exist. It just means they aren't the focus of that particular conversion.
>In web applications and cloud services drives could still be misplaced, stolen, or improperly disposed of.
This is explicitly called out in the article by the author, despite it not being part of the threat model the author is examining. And people are still bringing it up like some sort of gotcha.
See (again):
>This is not a comprehensive blog post covering every possible use case or threat model relating to encryption at rest.
> I’d say the author is being so restrictive in the scope of threats that it isn’t very useful.
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.
The problem is that after that common denominator is recognized, the post implies that it is outside the threat model of "web applications and/or cloud services", when it is not.
It doesn't need in-depth discussion, and the way data is still highly exposed despite disk encryption is very important, but that implication is not great.
In fact it would be extremely surprising if they didn’t have that list.
reply