Data security

[Martin Gräßlin]

On Thursday 05 January 2012 22:24:29 Ivan =?utf-8?B?xIx1a2nEhw==?= wrote:
> > I used it several years ago and the impact on CPU was so noticable that I
> > stopped using it. I think the system I had back then is comparable to
> > low-end ARM devices we have today.
> 
> Did you use it for /home and / or just for specific folders with
> documents. I have used it (and still am) for the later and it is fast
> enough (TM) :)
that was before encfs was invented. So at least all of home - not sure any 
more about /
> 
> > AFAIK the key is needed always in RAM as each read and write operation on
> > the encrypted disk needs the key. At least there would not be any use of
> > cold boot
> > attacks if the key is not in RAM:
> Well, we can't make a perfectly secure/unbreakable system - nobody can
> and nobody has, so we shouldn't really go this deep into analyzing
> this. That is, we can ask for EU-funded 1 year project to try to solve
> the security issue, and we might not go much further than we already
> are. (though, I'm all for the idea - used to be encryption-enthusiast,
> not a bad field to do science stuff in)
sure we cannot make the system completely secure - nobody can. But what I 
don't like is pseudo-security which gives the feeling of security and can be 
broken by the right googling in five minutes work.

But your encfs solution sounds good if that is really possible to get each 
activity encrypted and gives the possibility that a user says he doesn't care 
about encryption (/me belongs to those as I know that it can be broken). It 
would also reduce the RAM attack vector to just the current loaded activity
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20120105/c7aa9548/attachment.sig>