RFC: backporting GEOM to the 4.x branch

[Roland Dowdeswell]

On 1109641515 seconds since the Beginning of the UNIX epoch
"ALeine" wrote:
>

>> And, GBDE is obviously already less secure than a simpler
>> approach such as CGD with AES-256 (which is around twice as fast).
>
>I believe it is not less secure because eventhough it might require
>less steps to brute force a sensitive part of the filesystem (some
>directory structure), the impact is completely localized and can't
>be used to leverage a wider compromise, while that is not the case

But, I said that it requires less steps to brute force the entire
disk not just some parts of the filesystem.  Every last sector of
a 512GB disk can be brute forced in 2^158 steps using the most
naive method.  All of the key-key sectors can be brute forced in
2^153 steps.  This is much less than 2^256 which is what it would
take to brute force 256 bit AES.  So, until someone can crack 256
bit AES in < (2^25 * O(AES128)) steps, yes it is less secure.  Or,
one should say 256 bit AES with a lot of known plaintext in less
than 2^25 * O(AES128).

>with CGD. As I said, I believe the speed of GBDE could be greatly
>improved by implementing my ideas, but AFAIK there seems to be very
>little you can do to improve the speed of CGD beyond how fast it is
>now because it is already using the most simple approach and any
>additional optimization attempts would only increase the complexity,
>which is something you seem to want to avoid at all cost.

I am not against adding complexity, just against adding needless
complexity which has every appearance of introducing new methods
of attacking the disk without appreciably increasing the cost of
brute forcing it.

CGD does contain a reasonable amount of complexity in some areas:

	1.  it has a modular mechanism for defining crypto algorithms,
	    these do not need to be restricted to AES vs DES but
	    could include things like ``GBDE'',
	2.  it takes care to turn passphrases into keys properly, and
	3.  it allows for the addition of new mechanisms to do (2).
	4.  etc.

But, I also believe that one should solve first things first.
That's why I put most of my effort into defeating dictionary attacks
and making the sytem modular, etc.  There is no point in worrying
about what happens if someone breaks AES next year if you are
putting out a system this year which can be compromised in months
with a dictionary attack.  Focus on the weakest links first and
right now AES is not the weakest link.  There is little point in
replacing your front door with a steel reinforced door if all of
your windows are open.

>I believe PHK's calculations are based on the fact that even if you want
>to brute force a GBDE volume, you have to assume it's encrypted using GBDE
>and then try to break the structured multilayered mechanism, because
>otherwise you can only hope to brute force a very minimal part of the
>disk that would do you no good in leveraging that knowledge to break
>the encryption of the rest of the disk.

But, you do not have to break the structured multilayered mechanism
at all.  You can just brute force each sector one by one in much
less than 2^384 steps and hence the claim is both trivially and
obviously false.  Or just crack one key-key sector in 2^128, reverse
the MD5 in 2^128 to obtain the salt and get the rest of the disk
in < 2^128, for a grand total of O(2^129).  Together these methods
seem to indicate that 2^384 is a little exaggerated.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/