lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Dec 2010 15:32:27 +0100
From: <news@...cean.net>
To: Levente Peres <sheridan@...sz.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: 
 Possible issues with encrypted Linux filesystems?

 I am not an expert either, but I think this is known as watermarking 
 attacks. That's why I mentioned CBC in my previous mail, because it is 
 vulnerable to IV guessing.
 However there are other methods which are not vulnerable.
 Read:
 http://en.wikipedia.org/wiki/Disk_encryption_theory

 If you are really paranoid, then buy a Thinkpad or a similar laptop. 
 These support disks with hardware encryption like FDE of Hitachi.
 There is nothing as strong as hardware encryption (I can't imagine that 
 watermarking is even possible at raw level), plus it is faster.

 Phocean

 On Mon, 13 Dec 2010 15:16:05 +0100, Levente Peres <sheridan@...sz.org> 
 wrote:
> Dear All,
>
> Yesterday I had a very interesting conversation with Anthony G. 
> Basile,
> Ph. D. of D'Youville College about filesystem security. We thought 
> that
> we should continue this discussion here, so we could all contemplate 
> on
> the possibility of such a thing being possible.
>
> After reading Anthony's article, which you may find here...
>
> http://opensource.dyc.edu/random-vs-encrypted
>
>
> ...I've became worried about something very alarming, which I'd like
> to hear your opinion about.
>
> You see, it's one thing that you encrypt data, and then make backups,
> encrypt those backups, and the attacker could get valuable 
> information
> by comparing the patterns of the two... But when encrypting an entire
> operating system space, you actually encrypt much more than the data
> you wish to protect: you encrypt your system files, your packages, 
> all
> of it. Now this may sound like an ideal thing to do, but I'm not so
> sure about that anymore.
>
> Now, as we know, most Linux distributions have at least some files,
> directories, whatever that are bound to be the same on all systems.
> For example, binaries of gcc, some base directory names like /var,
> /usr, /home, layouts, and things like that. Even more, if you are
> using a "standard" distro like CentOS, you are assured to have
> literally gigabytes of data in forms of binary RPM packages on a
> default "base" installation, which not only are sure to be the same 
> on
> all systems, but even their distribution across filesystems are prone
> to be predictable. For simplicity's sake, let's just put these into
> one bucket and call them "known artefacts".
>
> I'm now worried that if an attacker knows, or "guesses" that you are
> using, say, CentOS Linux 5.5, (or at least some mutation of Red Hat),
> he might use this knowledge of "known artefacts" to his advantage, by
> starting out from the data he knows "must be there", and looking for
> it's "patterns". I don't know... This may be a longshot, wishful
> thinking or both, but somehow it feels to me like it's a lot easier 
> to
> break a code when you already know exactly what the decrypted data 
> is,
> and what it looks like. It should be like reverse-engineering
> ancient-egyptian text by seeing the same damn text in two or three
> other different languages you can actually understand... Essentially
> you could at the very least improve your chances at success if you
> have several certain, fixed points of reference for the decryption
> procedure (these "artefacts" we mentioned).
>
> I'll dare to go even further... Even if you are not encrypting your
> entire system, just the data... you could be leaving behind arefacts
> like file format headers, etc etc... or in case of LVM, logical
> flesystems within the LVM could leave behind headers, identifiers to
> mark the type, end or beginning, etc. of FS, whatever. I agree it's
> not much, and probably no concern, but if you want to be extremely
> paranoid, it's something.
>
> Now I'm not pretending to be an encryption expert... But I've go to
> tell it to you, If there's any possibility to this - then it creeps 
> me
> out. Worst case scenario, we could be looking at the possibility of
> breaking virtually any
> "standard" distro as long as one could "guess" (or
> "brute-force-guess") the version and type of the distro, AND the
> system is encrypted along with the data to be protected...
>
> I'd like you guys to put me back to ease by either proving me fatally
> wrong, or if there's anything to this... well, then we should discuss
> anyway.
>
> Best Regards,
>
> Levente Peres
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ