Re: [T(A)ILS-dev] Specification and security design document

Borrar esta mensaxe

Responder a esta mensaxe
Autor: anonym
Data:  
Para: The T(A)ILS public development discussion list
Asunto: Re: [T(A)ILS-dev] Specification and security design document
On 12/21/2010 01:11 AM, intrigeri wrote:
> Also, I do not think we absolutely want to use the "more secure" in
> any category. If LUKS / cryptsetup / dm-crypt is secure enough for
> our threat model, then I think its pretty good integration in Debian
> and in modern desktop environments makes it the best tool for T(A)ILS
> to support.


I agree.

AFAICT the only issue with dm-crypt is the "resolution" of data
modifications: whereas loop-AES would change the complete 512 byte
sector once it's been modified (even is just one bit within the sector
was flipped), dm-crypt would only change 16 bytes within the sector.

I say resolution above because loop-AES also leaks the same type of
information, it's just that it does so on a 512 bytes-block basis, which
obviously is better than dm-crypt's 16 bytes. But the optimal solution
(no leak at all) would be that each modification changes the whole
encrypted partition, which obviously is out of the question.

Loss of entropy open up for more efficient attacks than pure brute
force, so this is certainly a disadvantage of dm-crypt, but let us take
a look on how this leak fits our threat model. Do we assume an attacker
that has access to the ciphertext before and after each modification?
The only reasonable situation I could think of is that the encrypted
partition is accesses over the network, and the adversary is
eavesdropping and continuously logging each modification.

As long as the partition is located on media attached to the user's
computer (which is our aim, right?) the attacker is required to have
physical access to the victim's computer, which would enable far worse
attacks (e.g. hardware based logging). Hence this seems like a non-issue.

Other random, not verified points of loop-AES vs. dm-crypt:

* loop-AES is (supposedly) slightly faster than dm-crypt.

    Personally I don't care about this -- dm-crypt is fast enough.


* loop-AES hides the underlying cipher used whereas dm-crypt doesn't,
which could be said to be an advantage for loop-AES.

    My personal view is that this shouldn't matter for any cipher worth
    its salt.


* loop-AES is (supposedly) much harder to setup, and if you do it wrong
you're just as susceptible from the aforementioned data modification
leak as with dm-crypt.

    Considering how well-integrated dm-crypt is in most distros (and
    Debian in particular). and the amount of maintenance required for
    us to use loop-AES, dm-crypt scores a point.


* loop-AES's code is (supposedly) a mess and very hard to follow, a
point raised by auditor's (which were unable to feel confident it works
as specified), and acknowledged by the developer.

    This, IMHO, is more serious, and definitely makes me more in favour
    of dm-crypt, which after all is in the kernel and thus under more
    scrutiny.


In the end, I feel more in favour of dm-crypt, despite its shortcomings.

Cheers!