On Mon, Dec 13, 2010 at 11:40 AM, Everhart, Glenn <[email protected]> wrote: > If you are making an encrypted disk, you must be able to start decrypting > any parts you like. This makes use of common encryption modes other than ECB > harder. CTR (and CTS) or XTS comes to mind. CTR should be considered since its seekable. I would have to read NIST's Special Publication 800-38E for XTS.
> However you have the block number of the disk available. If it is used as part > of the encryption calculation you can have what amounts to a different > encryption > key for every disk block (derivative of course but still all different). This > prevents you from being able readily to get information about each cipher > block > by noting patterns where the ciphertext is identical (due to identical > plaintext). Block Id's, inodes and such should probably be considered public information [under some threat models] and hence, relegated to an IV. In this respect, the block Id or inode is very similar to a counter. I would be wary of trying to use a block id as a key. In addition, id's and inode numbers should be authenticated even though the data contained in the block is encrypted (confer: copy/paste attacks). With that said, authentication is usually shed in an attempt to balance usability and security (confer: Microsoft' elephant diffuser and "Poor man's authentication"). > My VMS cryptodisk back in mid 1980s did that. Don't recall if the RSX > cryptodisk > from 1979 did it or not; those machines were slow enough by modern standards > it > was difficult even to get modestly strong crypto and have the machine do > anything > else useful at the same time. :) Jeff > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jeffrey Walton > Sent: Monday, December 13, 2010 11:12 AM > To: Levente Peres > Cc: [email protected] > Subject: Re: [Full-disclosure] Possible issues with encrypted Linux > filesystems? > > On Mon, Dec 13, 2010 at 9:16 AM, Levente Peres <[email protected]> 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'm aware of a couple of papers which might interest you. First is > "TKS1 - An anti-forensic, two level, and iterated key setup scheme" by > Clemens Fruhwirth. Second is "AES-CBC + Elephant Diffuser, A Disk > Encryption Algorithm for Windows Vista" by Niels Ferguson. > > Fruhwirth's paper relates to LUKS, while Ferguson's paper relates to > BitLocker. Both papers discuss threats and design decisions. Keep in > mind both papers were released well before XTS and other tweakable > modes. > > I'm not well read on LUKS, dmcrypt, cryptsetup, etc. From my 10,000 > foot view, the papers are similar in that they attempt to solve the > same problem in slightly different problem domains. > > Jeff > >> ...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/ > This transmission may contain information that is privileged, > confidential, legally privileged, and/or exempt from disclosure > under applicable law. If you are not the intended recipient, you > are hereby notified that any disclosure, copying, distribution, or > use of the information contained herein (including any reliance > thereon) is STRICTLY PROHIBITED. Although this transmission and > any attachments are believed to be free of any virus or other > defect that might affect any computer system into which it is > received and opened, it is the responsibility of the recipient to > ensure that it is virus free and no responsibility is accepted by > JPMorgan Chase & Co., its subsidiaries and affiliates, as > applicable, for any loss or damage arising in any way from its use. > If you received this transmission in error, please immediately > contact the sender and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
