[dm-crypt] The future of disk encryption with LUKS2
sven at whgl.uni-frankfurt.de
Wed Feb 10 18:13:11 CET 2016
While there is truth in what you say, the same holds true looking at it
from the other side:
If you get everything 'just done', you will endup with a quilt that is
far from being useable and stable and which will fail more often than it
works. (And possibly gets you killed too).
So yes, compromises are needed.
Then again, we all know more than enough examples where cuts in
complexity/security ended in desaster, even though all features 'really
needed' were in place.
Am 10.02.2016 um 17:22 schrieb Arno Wagner:
> On Wed, Feb 10, 2016 at 16:39:03 CET, Milan Broz wrote:
>> On 02/10/2016 04:09 PM, Sven Eschenberg wrote:
>>> So either the layering order is fixed and determined, or you actually
>>> will need intra-layer relationships for proper operation. As an
>>> alternative, leave it to the user's knowledge and handling. But then we
>>> don't need partition tables, LUKS-headers or anything else either,
>>> afterall you can tell each layer the geometry and parameters manually
>>> and use dmsetup for all your tasks.
>> It is not just black and white.
>> (Could we avoid these logical fallacies here please?)
> I very much agree. Reality is that sometimes exceptions need to
> be made and sometimes you need to deviate from "clean" design
> to get good design. The trick is to keep the right balance
> and to keep the overall goal firmly in mind and keep the exceptions
> and added features down to those really needed, otherwise the
> increased complexity kills you (see also "The second system
> effect" by Brooks).
> Systems were everything is designed "correctly" and "clean" have
> a tendency to a) never get finished and b) not work very well.
> Reality requires compromises. The trick is to make it good
More information about the dm-crypt