Re: RFC: backporting GEOM to the 4.x branch

["ALeine" <aleine@xxxxxxxxxxxxxxxx>]

elric@xxxxxxxxxx wrote: 

> You would need to maintain some sort of journal.  With CGD, I
> specifically avoided any strategy which tied the write of one
> sector to the write of another sector for this reason.  And so,
> I use one key to encrypt the disk rather than storing randomly
> generated keys upon every write.
>
> GBDE already explodes a single sector write into two sector
> writes, which makes its performance quite suboptimal.  Adding a
> journal would make it even worse.  I do not think that maintaining a
> different key for each sector actually provides enough benefit to
> justify this.

I find using a single key for the whole disk less secure and not
very practical when one wants to change the key because it takes
a very long time to re-encrypt the entire disk. However, having
a separate per-sector key which is changed on every write seems
to go too far in the opposite direction, so IMHO the best solution
would be to use the same key for a definable number of sectors
(set at initialization) and then having a sysctl variable to
control after how many writes you want the key changed. This
would speed things up quite a bit and users would be allowed to
decide how much assumed security they are willing to sacrifice for
noticable speed. This would also make it possible to implement my
key shadow sector idea without a performance penalty in comparison
to the current implementation of GBDE.

> This is basically implementing a journal.  It adds a lot of
> complexity for IMO very little gain over moving to a simpler solution such
> as CGD.	The whole thing (GBDE) is already pretty brittle, i.e. hard
> to change without breaking.  This would make it more so.

Well, it does not need to be very complex and I am more interested in
getting this kind of functionality in 4.x, so I think that porting GBDE
would be more work than writing my own implementation from scratch and
just using the same principles, only adapted and implemented in a way
to suit my ideas and needs.

> 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
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.

> Many rather dubious claims have been made about GBDE such as in:
> 
>	  http://www.bsdcan.org/2004/papers/gbde.pdf
> 
> PHK claims that it will take O(2^384) to crack GBDE if the lock
> sector is destroyed.	Perhaps my maths is a little rusty, but it
> perplexes me how it could possibly take 2^384 steps to
> individually crack 2^30 sectors that are encrypted with 128 bit AES.
> That comes out to a [not at all strict] upper bound of 2^158 steps to
> entirely crack a 512GB disk.  So, already it is less secure than CGD
> using 256 bit AES.	But, obviously you'd just crack the ``key-key
> sectors'' which would knock another 5 bits off.  Now, consider that
> really an attacker doesn't really care about the whole disk.  By chasing
> directory structures, etc., they could find what they wanted in
> very little more than O(2^128).  So, what's the point of all of
> the gymnastics...  a few bits.

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.

> It is also structured in such a way that substantial
> breakthroughs in the cracking of many different encryption algorithms,
> hashes and random number generators will bring the house of cards down.
> I do not believe that it has had an appropriate amount of peer
> review to be considered trustworthy, and I have seen some pretty
> obvious weaknesses that I've been meaning to write up but haven't
> quite found the time that would knock a few more bits off.

I believe PHK is well aware of the threats, he even commented on them in
the code itself and his papers, his choice of SHA2/512, for example, shows
that he is planning for those advances that pose a threat. I am sure there
is room for a lot of improvement in GBDE and eventhough not that many
reputable cryptographers have reviewed GBDE so far, those who have are
very well respected, like Lucky Green, for example. I hope you will find
the time to write an analysis of the weaknesses you found, I would be
very interested in seeing if they would apply to what I have in mind.

ALeine
___________________________________________________________________
WebMail FREE http://mail.austrosearch.net