xrcltr

It is so much nicer living outside a city compared to living in one.

I might have read past the initial section if they had spelled technical terms properly.

The authors may very well have been knowledgeable when this was written in 2008, but with such a glaring issue I won't take the time to read it.

Except that the wheels didn't fall off the phone. This lockup happens due to code proactively added by Apple. You are confusing three different issues: the design of the system, the legality, and how security should work. In this case, none of those three items align. This is Apple's problem - they chose the easiest option for themselves, not what would benefit customers legally, functionally, or by securing the device properly.

You are fundamentally misunderstanding the threat model. What is the exact threat that Apple is guarding against? Is it an evil maid attack planting new sensors, switched devices, someone's fingers being cut off? All of these require different mitigations - none of which for a general purpose consumer phone are to brick the device when upgrading.

Actual Leonardo: "Why do you want this? I have found upon much observation and reflection that those people of stout character who request Fizzbuzzium would be far better served with the presentation of the solution to an alternative problem that more closely describes the situation. Please find it within yourself to return to first principles, so I may remove the original first problem with quickness and zeal that you have not yet seen."

This is not disk encryption. This is file encryption.

There are a tremendous number of other ways this could be implemented.

Authenticated encryption? GCM? XTS? Salt the CFB? Guard against interblock attacks?

The crypto needs to be completely reworked. This is an asymmetric kek around symmetric encryption, which is done in many other projects.

Half-backed crypto such as this is worse than no crypto at all, as it lulls people into believing they are using a valid cryptographic system. But, the project implements (poorly) a subset of what is needed and pushes the rest into application code - but app writers don't know this and wouldn't know what to implement even if they know of the shortcomings.

Cryptographers see this all the time. People think they invented a new concept but only implemented a well-known design but did it incompletely and with well-known flaws in the crypto. Then, people defend the system, when it would be far easier to use better primitives.

Except that that the kek and horrible crypto are different in this project, it's really not a different approach.