Forgot your password?
typodupeerror
Encryption Security IT

Encrypted Images Vulnerable To New Attack 155

Posted by kdawson
from the bye-bye-deniability dept.
rifles only writes "A German techie has found a remarkably simple way to discern some of the content of encrypted volumes containing images. The encrypted images don't reveal themselves totally, but in many cases do let an attacker see the outline of a high-contrast image. The attack works regardless of the encryption algorithm used (the widely-used AES for instance), and affects all utilities that use single symmetric keys. More significant to police around the world struggling with criminal and terrorist use of encryption, the attack also breaks the ability of users to 'hide' separate encrypted volumes inside already encrypted volumes, whose existence can now for the first time be revealed." The discoverer of this attack works for a company making full-disk encryption software; their product, TurboCrypt, has already been enhanced to defeat the attack. Other on-the-fly encryption products will probably be similarly enhanced, as the discoverer asserts: "To our knowledge is the described method free of patents and the author can confirm that he hasn't applied for protection."
This discussion has been archived. No new comments can be posted.

Encrypted Images Vulnerable To New Attack

Comments Filter:
  • Confusing (Score:5, Insightful)

    by Rui del-Negro (531098) on Sunday October 05, 2008 @04:10PM (#25266623) Homepage

    Is it just me or does anyone else get the feeling that the original story confuses two completely different concepts (digital photos and drive images)?

    • by mikesd81 (518581) <`mikesd1' `at' `verizon.net'> on Sunday October 05, 2008 @04:17PM (#25266707) Homepage
      In fact I had to read the fine article (I know, unheard of) to figure it out. Maybe that's the new thing to get us to RTFA. Use even more confusing summaries?
      • Re: (Score:3, Funny)

        by Anonymous Coward

        Can you tell us what you figured out so we can RYFC instead of TFA?

  • Watermark? (Score:5, Insightful)

    by Lord Byron II (671689) on Sunday October 05, 2008 @04:12PM (#25266655)
    How is this different from the well-known watermarking attack? Doesn't the fact that most encryption systems now use the block number as a salt render this attack useless?
    • Re:Watermark? (Score:5, Interesting)

      by profplump (309017) <zach-slashjunk@kotlarek.com> on Sunday October 05, 2008 @04:17PM (#25266715)

      Or CBC mode? Or any of a dozen other ways to prevent this well-known attack on ECB mode encryption? http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation [wikipedia.org]

      Yes. And apparently TurboCrypt now supports such things too, hence the press release.

      • Re:Watermark? (Score:4, Interesting)

        by Goaway (82658) on Sunday October 05, 2008 @04:29PM (#25266807) Homepage

        How would you use CBC on a disk image that requires fast random access?

        Here's what you should have been reading on Wikipedia: http://en.wikipedia.org/wiki/Disk_encryption_theory [wikipedia.org]

        • Re:Watermark? (Score:5, Informative)

          by mikenap (1258526) on Sunday October 05, 2008 @04:39PM (#25266887)

          By breaking the disk up into sectors, each of which start a new chain. The problem is an IV is used to "start" the CBC chain, and this IV is static as the underlying plaintext changes. So new changes on the same point of the HD get encrypted with the same IV.

          • by Goaway (82658)

            There are better methods. Some are mentioned in the article I linked!

          • Re:Watermark? (Score:5, Informative)

            by kasperd (592156) on Sunday October 05, 2008 @06:42PM (#25267671) Homepage Journal

            The problem is an IV is used to "start" the CBC chain, and this IV is static as the underlying plaintext changes. So new changes on the same point of the HD get encrypted with the same IV.

            It actually makes me happy to see that some people are starting to get the point. I have been pointing out these weaknesses for years.

            Some of them are actually even worse. If the IV is just the sector number, then the difference between two neighbor sectors is known, and you can construct a file that will cancel out that difference and the two sectors get the same cipher text. I constructed a file [kasperd.net] some years ago, that demonstrated the problem. At that time Truecrypt was vulnerable to this attack. Truecrypt did apply some whitening after the encryption, but that didn't really make the pattern much worse. Put the file I mentioned on a Truecrypt volume encrypted in CBC mode, and somewhere in the encrypted image there will be two neighbor sectors that can be XORed together and will cancel out all the data leaving only the whitening pattern, which is easily recognizable because it repeats over many times through the sector.

            Encrypting the IV is better, but still vulnerable to the problem you describe. In fact the problem you describe applies one way or another to almost every single disk encryption in existence. All the encryptions need some nonce or randomness, and since it doesn't fit in the sector, they cut a corner and use the sector number, which doesn't change when the sector is overwritten. (I have seen one that used extra space by mapping 32 logical sectors to 33 physical sectors, but that encryption had other problems including a weak pseudo random number generator, and potential data loss caused by the need to update two sectors which isn't done atomically).

            Recent Truecrypt versions are no longer vulnerable to the attack I described above. They now use tweakable block ciphers. But just like CBC needs a unique IV for each time you encrypt, tweakable block ciphers need a unique tweak. Truecrypt use the sector number for tweak, so if a sector is overwritten, you have the same problem again. In fact it is even worse because there is no longer any chaining, just a tweak for each 16 byte block, which means changing a byte in a sector would keep changes in the cipher text within the 16 byte block. I didn't verify this in practice, I just read the specification. I mentioned this problem to the authors a long time ago, but they didn't consider it a problem.

            • Re:Watermark? (Score:4, Interesting)

              by DamnStupidElf (649844) <Fingolfin@linuxmail.org> on Sunday October 05, 2008 @10:55PM (#25269267)

              Recent Truecrypt versions are no longer vulnerable to the attack I described above. They now use tweakable block ciphers. But just like CBC needs a unique IV for each time you encrypt, tweakable block ciphers need a unique tweak. Truecrypt use the sector number for tweak, so if a sector is overwritten, you have the same problem again. In fact it is even worse because there is no longer any chaining, just a tweak for each 16 byte block, which means changing a byte in a sector would keep changes in the cipher text within the 16 byte block. I didn't verify this in practice, I just read the specification. I mentioned this problem to the authors a long time ago, but they didn't consider it a problem.

              LRW should fall to the bitmap attack presented in the article, so long as the bitmap is overwritten in place between ciphertexts. Any other weakness in LRW using the same key is minimized unless you are filling your disk with 127th degree polynomials in GF(2) represented as 128-bit vectors, that happen to differ from each other by n*k in GF(2) where n is the sector number they're stored in and k is the LRW tweak key. Most people don't do that. The probability of doing so with normal use is roughly the probability of accidentally guessing the tweak key.

              The only real solution for the bitmap problem is modification of the file system to contain secure IVs for each block on the disk. Reusing IVs has *always* been shown to be a bad idea. It's broken more thought-to-be-secure schemes than I can count.

              As an aside, once I actually found two files from a Slackware distribution that were detectable inside a truecrypt volume. One problem truecrypt had back then was that they were using 512 byte CBC blocks, while most file systems used larger blocks, so it was trivial to insert a file that would guarantee that the resulting ciphertext would be vulnerable to detection by starting at an even sector boundary and having just simple bit differences. I am guessing that in both cases the files being detected were executables with a large dynamic link section, since that would contain a whole lot of simple offsets that could match up with the sector IV vulnerability.

              • Re:Watermark? (Score:4, Interesting)

                by kasperd (592156) on Monday October 06, 2008 @02:59AM (#25270431) Homepage Journal

                The only real solution for the bitmap problem is modification of the file system to contain secure IVs for each block on the disk.

                Since the encryption is done at the block device layer, it shouldn't be part of the file system but rather a part of the encryption layer. Except from that detail, I agree with you. However doing it is tricky. When you take a logical sector with 512 bytes of data and put it together with a small IV, it no longer fits in a 512 bytes sector. So you have to come up with a layout on disk that is efficient. And then you have the problem of updating it. Because you cannot write two sectors to disk atomically (with some disks you can't even write one). So you end up having the potential of data loss if an update does not complete because of a power failure. And the data loss is not guaranteed to affect only the logical sector you were writing at the time. I am still thinking about the problem. A raid layer have some similar problems, and I have been considering whether merging those two layers would help solving this problem. A can see a few other advantages you could get from merging a raid layer with an encryption layer.

                Reusing IVs has *always* been shown to be a bad idea. It's broken more thought-to-be-secure schemes than I can count.

                Indeed. And the damage depends on the kind of encryption used. CBC is actually dealing pretty well with reused IVs compared to other encryptions. RC4 and counter mode are two examples where reusing IVs is so bad that you might as well not be encrypting at all.

                As an aside, once I actually found two files from a Slackware distribution that were detectable inside a truecrypt volume.

                Interesting. Though the patterns are simple, I wouldn't have thought they would show up unless they were carefully constructed.

                One problem truecrypt had back then was that they were using 512 byte CBC blocks, while most file systems used larger blocks, so it was trivial to insert a file that would guarantee that the resulting ciphertext would be vulnerable to detection by starting at an even sector boundary and having just simple bit differences.

                That's the vulnerability I was referring to. And this is what is demonstrated by the file I linked to. It requires just one or two bits of difference between neighbor sectors depending on which parameters you used to set up the volume. My file contains just a lot of variants of that to cover different byte orderings so as to demonstrate the weakness not just in truecrypt, but also in some early Linux loopback encryptions.

                The fact that a file system block consists of multiple disk sectors just makes the exploit slightly more reliable. Even if the sizes were the same, the file system would still try to put consecutive blocks from your file right next to each other on disk. (If it didn't do that, performance would go down by orders of magnitude).

            • Re: (Score:3, Informative)

              by Fweeky (41046)

              I have seen one that used extra space by mapping 32 logical sectors to 33 physical sectors, but that encryption had other problems including a weak pseudo random number generator, and potential data loss caused by the need to update two sectors which isn't done atomically

              That would be GBDE [wikipedia.org]. Shouldn't it be relatively easy to replace the PRNG?

              • Re:Watermark? (Score:5, Informative)

                by kasperd (592156) on Monday October 06, 2008 @02:40AM (#25270361) Homepage Journal

                That would be GBDE.

                Correct.

                Shouldn't it be relatively easy to replace the PRNG?

                Depends on whether you are worried about breaking compatibility. There is nothing you can do for existing encrypted volumes. If you want to improve security for your existing volumes, a complete reencryption of the volume is needed. If you want to protect new volumes while remaining compatible with the existing implementation, a small change to the way the master key is generated would help. There is a 256 byte lookup table, in which having two identical bytes is a weakness. The table is generated randomly, which means master keys vary in quality. The best master keys are those were all 256 bytes are different, but the chance of that happening at random is negligible. If the key was instead generated by taking an array containing all the values from 0 to 255 and permuting those randomly, you would always get keys that are resistant to the known attack.

                If you don't need compatibility with the existing code, you can do even better. The PRNG makes use of MD5. Before anybody starts talking about MD5 being broken, keep in mind that the known attacks against MD5 do not apply to the way GBDE use it. The input that GBDE passes to MD5 is 24 bytes, which have 128 bits of entropy (with the best keys). Obviously the output will have no more than 128 bits of entropy, but it could have less. Though the input is just 24 bytes, MD5 is going to add a length field and pad the result to a multiple of 64 bytes. So you could actually double or triple the key size and pay no extra cost in performance on the MD5 operation.

                Since three byte quantities are difficult to work with, I'd only suggest to change the lookup table from having 256 8-bit values to having 256 16-bit values. The risk of having two identical values if you pick them randomly, is reduced significantly. But still generating it in a way that guarantees it is still better. This would produce a 40 byte input to MD5. If you wanted to make use of the full MD5 block size, you could append another random key to the 40 bytes such that you would make the input as large as what would fit in a single MD5 block. Doing all of this would increase the key size from 272 bytes (16+256) to 584 bytes (56+16+512), and would not spend any additional time on the cryptographic operations in the critical paths.

                You could also ditch the PRNG altogether and use a standard PRNG. But that would mean a significant performance hit, so you'd have to reduce the size of the master key. So I am not sure that would really make it any stronger than fixing the known vulnerabilities in the current PRNG.

                As for the potential data loss goes, I suppose you could live with it and just make sure to have a good backup strategy. When doing that of course you have to keep in mind that you shouldn't make backups by copying the encrypted container. The correct way would be to copy the files from the encrypted container to a different encrypted container. Or you could copy the files to an encrypted archive that does not support random access, like tar + gpg. Or you could back up your container by creating an encrypted copy of the container. If you use asymmetric keys, you could create a gpg encrypted copy of the encrypted container even while it is not mounted.

                Problem is that the only way to detect that corruption has happened is by trying to open the files with applications understanding the format, and see them barf. However fixing the potential corruption is tricky. If I find a good solution, I am probably going to write my own storage encryption layer some day.

                • by Fweeky (41046)

                  You could also ditch the PRNG altogether and use a standard PRNG. But that would mean a significant performance hit

                  How much random data does it need? An amount equal to what's being written? I guess that would be quite nasty; Yarrow can just about pump out 50MB/s given a couple of GHz of Opteron.

                  Problem is that the only way to detect that corruption has happened is by trying to open the files with applications understanding the format, and see them barf. However fixing the potential corruption is tricky. If I find a good solution, I am probably going to write my own storage encryption layer some day.

                  You could put ZFS on top of it, scrub would then pick it up. Backing the disk with multiple crypted volumes would get you redundancy. You could use block level journaling (gjournal) to help avoid partial writes, though with ZFS and ZIL that would probably be unnecessary.

                  GELI also supports using cryptographic hashes for authe

        • By using a counter, it provides random access, stops this class of attacks, and is easy to implement.

          wiki [wikipedia.org]
          • by Goaway (82658)

            ...and isn't CBC.

          • by kasperd (592156)

            By using a counter, it provides random access, stops this class of attacks, and is easy to implement.

            Counter mode is one of the least secure ways to encrypt a disk. Counter mode generates a pseudo random one time pad, which in itself is secure if the pseudo random number generator is secure. However when used for disk encryption, the one time pad is reused whenever you overwrite a sector. Reusing a one time pad is not secure.

        • by profplump (309017)

          Apparently you missed the part about "or any of a dozen other ways", or the grandparent's comment "use the block number as a salt"?

          Also, it's not impossible to use CBC in random-access mode, it's just inefficient -- but if you read the preceding block you have all the necessary data. You'd have a lot of re-writing to do when you made changes, but it could certainly be done without any algorithm tweak or special treatment.

          And if *you* bothered to read the page you linked to, you'd see that people actually *d

      • Re: (Score:2, Informative)

        by mikenap (1258526)

        The problem is many CBC and other disk-encryption modes used an IV based on the disk sector number. So when that sector changes, the changes continue to be encrypted with the same IV and key.

      • Re: (Score:3, Interesting)

        Exactly. Use of ECB mode is pointless. All ECB mode does is change one block value to another since they are encrypted the exact same way. Thus, two similar blocks will have exactly the same output.

        If you're using AES and you supposedly know what you're doing, you use CBC or CFC or another chaining mode. These feed the results of the previous encryption operation rendering the type of attack discussed in the article moot.

        I can't believe they gave them any press time on this. Argh!

        • by CustomDesigned (250089) on Sunday October 05, 2008 @07:02PM (#25267793) Homepage Journal

          The problem is the IV for CBC never changes for a given sector - mainly because there is no provision to atomically write both a 512 byte sector and its 48+ bit IV. I *have* read about a disk designed for full disk encryption which provides 520 byte sectors instead of 512 byte sectors. That completely solves the problem.

          Some disk encryption uses non-atomic sector writes (store IVs in a separate physical sector). This risks data loss should one get updated but not the other.

          I will note that the problem is more easily completely solved for flash media - where it is easier to (atomically) tag sectors with additional data.

      • Just looking at ECB ciphertext reveals patterns in the plaintext. This attack requires plaintext with known properties to be encrypted with the same key and IV as the text of interest, and it affects many other modes.
      • by hairyfeet (841228)

        I have a couple of questions,seeing as it seems you know more about this stuff than I do(I admit I haven't gotten very deep at all with crypto.Simply not enough hours in the day) and after reading TFA a couple of things are unclear to me.

        One,quoting TFA " if the police have access to two backup volumes created with a single key, one of which has changed over time, Roellgen's technique can be used to compute that such a volume must exist within the primary volume. Although police cannot decipher the data, th

        • simply using zips would obfuscate this, yes, since compression works by removing redundancy (thus increasing entropy).

          As to backups out of date,
          All you need is the previous backup and the current encrypted volume. Since most people do not back up after every file change, there is your required delta.

          There are three easy solutions:
          *backup to a separate encrypted volume with unique encryption keys.
          *use entropy increasers in your encrypted volume (zip, rar, etc.)
          *don't backup your encrypted volumes.

      • It's not news. This is an advertisement.

    • Re:Watermark? (Score:5, Informative)

      by mikenap (1258526) on Sunday October 05, 2008 @04:24PM (#25266759)

      The cause is similar to the watermarking attack, but the idea is used backwards. The watermarking attack reveals the presence of maliciously constructed decoy plaintext encrypted by the user, whereas this attack reveals information about the change in an unknown plaintext.

      In both attacks the issue is that the salt, as you call it, is constant for a given disk block. If that salt can be predicted, a decoy plaintext can be revealed in the ciphertext. If data is changed while using the same salt, sections of identical plaintext before and after the change can be identified.

    • Not new (Score:5, Interesting)

      by TheLink (130905) on Sunday October 05, 2008 @04:27PM (#25266787) Journal
      It's not new, it's old stuff.

      As long as you backup the entire drive image - they will know that you made changes. Salt does not render this attack useless.

      This is why you do not backup images of encrypted drives (or reencrypt changed documents with the same key - this is normally not a problem for decent file crypto).

      If you are going to backup data that's on an encrypted drive, you copy the files and reencrypt them to your backup media.
  • Compressed images (Score:5, Insightful)

    by Lord Lode (1290856) on Sunday October 05, 2008 @04:12PM (#25266663)
    Does this also count for compressed images like PNG and JPG? After all those aren't bitmaps anymore - and removing redundancy by compression is always a good idea for encrypting afaik.
    • by cjonslashdot (904508) on Sunday October 05, 2008 @04:16PM (#25266691)
      I had the same thought. From the description it sounds like the attack is based on the existence of regularity (low entropy) in the file. Any technique such as compression that increases the entropy should defeat the attack as it is described. Since most images today are compressed, it would seem that the attack would have no practical impact. But perhaps it works differently than explained.
    • by mrbah (844007) on Sunday October 05, 2008 @04:16PM (#25266701)
      Anything that's gone through run-length encoding is going to have very high entropy, so JPG and PNG images are safe.
      • Re:Compressed images (Score:4, Informative)

        by Goaway (82658) on Sunday October 05, 2008 @04:30PM (#25266825) Homepage

        Run-length encoding doesn't give you all that high entropy, and neither JPG nor PNG uses it.

        • by jbengt (874751)
          IIRC, jpeg uses run-length encoding (at least to a limited extent). It avoids individually storing all those 0's arising when the quantization throws out unimportant high frequencies.
          • by Goaway (82658)

            Oh, right, it does. But it certainly doesn't account for all of the entropy increase.

    • by mikesd81 (518581)
      See this quote [slashdot.org] with this article [techworld.com].
    • by perlchild (582235)

      I was actually thinking the compression headers and other well-known features of such formats would be used as cribs for decryption...

  • by mrbah (844007) on Sunday October 05, 2008 @04:13PM (#25266673)
    The article points out that this attack only works with uncompressed bitmaps with extremely low entropy. This is hardly a cause for alarm.
    • by clarkkent09 (1104833) on Sunday October 05, 2008 @04:28PM (#25266799)
      Whew, thanks for pointing that out. Most of my encrypted porn is jpgs
      • Most of my encrypted porn is jpgs

        Why would you need to encrypt your porn... unless....

        Dude! Won't anybody stop you thinking about the children?

        • Most of my encrypted porn is jpgs

          Why would you need to encrypt your porn... unless....

          Dude! Won't anybody stop you thinking about the children?

          Privacy mode FTW! [geekculture.com]

          But speaking seriously, securing your privacy is something you should ALWAYS do if you have a family - especially if you watch porn. Moral issues aside, depending on where you live, if your little brother (and/or his friends) finds your collection, you could get in serious trouble.

          It happened in the city where I live. A teacher was fired because his son (who attends the same school) invited some of his friends to play on the computer. Unfortunately, the browser history wasn't cleared and g

    • by martinw89 (1229324) on Sunday October 05, 2008 @04:29PM (#25266811)

      Not only is the sensationalist article/summary only pertinent to uncompressed bitmaps, TrueCrypt has warned their users about backing up hidden volumes for a long time (source [truecrypt.org]). In fact, it's the first precaution in how to keep your hidden volume secure.

      So people worrying about steganography on TrueCrypt volumes shouldn't, they've been telling you how to keep these volumes secure already.

    • by Artraze (600366)

      Indeed. However, it is still very interesting news. This demonstrates an attack against encryption without actual decryption. While perhaps not exactly a first, the fact that it is exploitable under real world circumstances* makes it quite important. Indeed, this may be the first nail in the coffin of simple block cyphers.

      *While most people don't store uncompressed bitmaps, I have to imagine that camera RAW files wouldn't be too uncommon, and the attack may be adaptable to include those (they usually us

      • Re: (Score:3, Interesting)

        by strstrep (879828)

        The attack shown works on an image with a bit depth of 2. Camera RAW files have much higher bit depth, and unless you're saturating the whole sensor, I would imagine the image does not contain significantly large values of the same exact pixel value.

        • Except nightsky picture who are mostly black... But why encrypt these ? :D

          • by HTH NE1 (675604)

            Except nightsky picture who are mostly black... But why encrypt these ? :D

            They can reveal the time and location you took your naked-girls-on-trampolines-at-night fetish porn.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      To expand on your point:

      What they are doing (although they don't put it like this) is searching for blocks in the compressed data whose pre-image is all zeroes (i.e. a large patch of white in the original image). For this to produce anything useful the image must be huge (so that a single scanline spans several blocks) and must contain large of areas of pure white.

      In other words, their technique only reveals enormous, low colour-depth, uncompressed images. Do such images actually exist in real life?

      • by vlm (69642)

        In other words, their technique only reveals enormous, low colour-depth, uncompressed images. Do such images actually exist in real life?

        Yes tactical military maps

        • by caluml (551744)
          Like this [blogg.no], you mean? (Couldn't remember the link to that nuyd place, so hot linked - sorry :( )
      • In other words, their technique only reveals enormous, low colour-depth, uncompressed images. Do such images actually exist in real life?

        ASCII Porn?

      • In other words, their technique only reveals enormous, low colour-depth, uncompressed images. Do such images actually exist in real life?

        Since native windows desktop backgrounds are BMP format images and often mostly one color except for an image on the side or bottom. they would be perfect targets.

        I don't know if any of the backdrops in the standard Windows install qualify, but I suspect not.

    • by tyler_larson (558763) on Sunday October 05, 2008 @09:34PM (#25268805) Homepage

      The article uses images encrypted with in ECB mode (a well-known insecurity) as a visual analogy to the backup-file problem.

      The backup-file problem is that when you have two volumes encrypted with the same key (not the same password, the same internal encryption key), the difference between those two volumes can reveal some information about the encrypted data. Perhaps all you can determine is what parts of the volume have changed, but that's more than nothing, and therefore unacceptable.

      The is a "backup-file" problem because you NEVER have two volumes encrypted with the same internal key unless one starts out as a "backup" copy of the other.

      The product mentioned in the article "fixes" this problem by providing an explicit "backup" function. This function creates a new volume containing the same data as the original, but which is encrypted using a different internal key. The hope is that because such an option exists, users will be dissuaded from simply storing bit-for-bit backups of their encrypted volume.

      Nothing about this is ground-breaking or even novel, but the concepts at play are important for consumers of encryption products, so the attention is worthwhile.

  • by Anonymous Coward

    It was always risky to have two versions of a block-structured file encrypted with the same key. You can see the changes. That may tell an attacker things about the encrypted data (filesystem, size of files, etc.) If you backup encrypted volumes, either put them in another container or decrypt the files and store them in another container with a different key. Never keep different volumes with the same key. The attack is of significance for law enforcement, which may be able to enter the premises of a suspe

  • by boldi (100534) on Sunday October 05, 2008 @04:16PM (#25266695)

    I just scanned these articles, but just from the fact I don't see a single occasion to talk about crypto modes, such as ECB,CBC,OFB,CFB,CTR etc., I'm unhappy.

    20+ years old knowledge, probably badly designed software, some special attack against very bad design, and then a panic-like hype against encryption.

    So please, tell the newspaper writers to learn somewhat about security and only after that start to write hype-like articles..
    Sad.

    • by Goaway (82658) on Sunday October 05, 2008 @04:32PM (#25266837) Homepage

      You don't use any of those modes on disk images, because you need fast random access.

      http://en.wikipedia.org/wiki/Disk_encryption_theory [wikipedia.org]

      • Erm why do you need fast random access to backups? The weakness is only if there are to images(disk images) containing the same image(bitmap).

        • by Goaway (82658)

          These aren't backups.

          • Erm why do you need fast random access to backups? The weakness is only if there are two images(disk images) containing the same image(bitmap).

            OOPS

            as you cant compare a single image of a disk, and why would you have 2 images of a disk around for anything other than backups?

            *if your running raid-1 with 2 disks youd have to identical images making the attack useless

    • I just scanned these articles, but just from the fact I don't see a single occasion to talk about crypto modes, such as ECB,CBC,OFB,CFB,CTR etc., I'm unhappy.

      It doesn't? What about the part in TFA that reads:

      ...This attack requires NO knowledge of the key used for encryption and it applies to ECB Mode (Electronic Codebook), Counter Mode (CM), Galois/Counter Mode (GCM), LRW, XEX, XTS, as well as CBC-based modes of disk encryption applications (OTFE).

      • in fairness i stoped reading after i saw

        PMC Ciphers demonstrated TurboCrypt's defence against another great weakness of encryption software, Trojan keyloggers

        oh right that was the end, but seriously WTF that doesn't make any sense, hardware keyloggers? rootkits?

  • It seems (Score:5, Informative)

    by mikesd81 (518581) <`mikesd1' `at' `verizon.net'> on Sunday October 05, 2008 @04:21PM (#25266747) Homepage
    this attack only works on volumes containing bitmap files. From the article:

    The problem is that bitmaps often display low levels of entropy, such as would be the case in pictures taken at night with large areas of high contrast. Roellgen's attack is based on comparing two volumes encrypted into scrambled ciphertext using the same symmetric or 'static' key, where the original subsequently has new files added. This yields a pattern of structured similarities and differences that can be used to reveal some of the original information in plaintext form.

    The attack doesn't work for other types of data, for instance text files, because the entropy levels are too high. But it is believed to effect almost any encryption program currently on sale as long as the two volumes being compared use the same encryption key whilst being slightly different from one another.

    The summary title and summary write up are a little ambiguous.

  • The problem is most likely that they use ECB-mode and no IV. Using a different mode, like CBC might solve the problem. The problems with ECB are well known, even wikipedia has an entry about this problem http://en.wikipedia.org/wiki/Cipher_mode [wikipedia.org]

    • by Goaway (82658)

      Once again, CBC doesn't work on disk images that need fast random access.

      http://en.wikipedia.org/wiki/Disk_encryption_theory [wikipedia.org]

    • Yup. "Everyone knows" that reusing the same key/IV on more than one piece of data means that you're screwed. The Soviets learned this lesson in a painful manner on what were supposed to be one-time pads during WWII. If these programs are really re-using the same key and IV for different revisions of the data, then they are horribly broken and this is just the barest beginning of how.

      The bad news is that this would seem to indicate that a fair amount of full-disk encryption software is absolutely, horribly b

      • by Free the Cowards (1280296) on Sunday October 05, 2008 @04:52PM (#25266985)

        Oh, and if you follow the link from the article you'll find that this attack is being published by the makers of TurboCrypt, which was incompetently designed and thus vulnerable to this attack, but has now been fixed. The makers of this app (which you should probably stay away from, if they made such an elementary mistake then who knows what other problems it has) are essentially hyping this fairly inconsequential discovery in order to sell their product.

        In conclusion: lame.

    • The problem is most likely that they use ECB-mode and no IV. Using a different mode, like CBC might solve the problem.

      "This attack requires NO knowledge of the key used for encryption and it applies to ECB Mode (Electronic Codebook), Counter Mode (CM), Galois/Counter Mode (GCM), LRW, XEX, XTS, as well as CBC-based modes of disk encryption applications (OTFE)."

  • If I am reading this correctly, they are describing a well known problem with plenty of well known solutions. One such is XTS, which is what TrueCrypt uses.
    • "This attack requires NO knowledge of the key used for encryption and it applies to ECB Mode (Electronic Codebook), Counter Mode (CM), Galois/Counter Mode (GCM), LRW, XEX, XTS, as well as CBC-based modes of disk encryption applications (OTFE)."
  • As this requires at least 2 images with the same key, encrypted 'working' hard drives are not vulnerable unless you make sector level backups. I would imagine that anyone who has illegal images (such as child porn) on their encrypted hard disk would not make backups of such images.

  • This is far from a new revelation, they used AES in ECB mode to encrypt the uncompressed bitmap.

    As you can see on the wikipedia page for ECB [wikipedia.org] this attack has been known for a while.

  • Ok, so they are able to extract some information from a ciphertext that was created from a low entropy plaintext. It is quite obvious that redundancy in data creates vulnerabilities. This is exactly the reason why any serious encryption software applied data compression (entropy coder) before encrypting.

    Actually simply storing images in any format with data compression would completely invalidate this method. (eg. JPG, TIFF, PNG, GIF)

  • In order to be able to use this attack, the image needs to be completely uncompressed, you need to be using a dumb encryption system, and you need to know where the bits making up the image are stored. In practice, none of those are going to be true.

    • by Jesus_666 (702802)
      Actually, I found an equally serious security hole that all encryption schemes are succeptible to: The known plaintext attack. If I already know the plaintext I can write a program that produces it, no matter how strongly its encrypted form is. I can even produce the known plaintext without any ciphertext at all!
  • It sounds like if the image is included in the encrypted message and you have a copy of the unencrypted image, it may be possible to break the entire message. That is what is known as a "known plaintext attack." It isn't exactly a new idea, although its application to files/messages with embedded images might be.

  • Maybe this amateur cryptographer should read a few more cryptography books (or even Wikipedia) before claiming something new.

  • Two issues... (Score:3, Interesting)

    by gillbates (106458) on Sunday October 05, 2008 @08:57PM (#25268583) Homepage Journal

    But it is believed to effect almost any encryption program currently on sale as long as the two volumes being compared use the same encryption key whilst being slightly different from one another.

    There are two issues that immediately come to mind:

    1. Any encryption solution which has a halfway decent key management scheme will have a low probability of using the same keys... (However, key management is still a relatively nascent field within cryptography; the lack of serious, public study of this issue is one of the reasons why even public key cryptography is not secure in the hands of a novice - a simple "sign my sig" attack can be used against those who don't know any better. I know I'll probably get flamed for this, but the lack of a good, easily managed key-management scheme is one of the reasons why gpg has not been widely adopted, in spite of the fact that it is rather easy to install and use. As the matter of how best to make the tradeoffs between security and usability is not mathematically provable, progress in this area has been and will continue to be slow.)
    2. One of the enduring tests for encryption algorithms is the degree to which they disguise the degree of entropy in the plaintext. The issue of the "proper" way to do secure disk encryption is also relatively nascent. The problem of what to do with the relatively low entity in filesystems, the prevalence of easily predicted data (for example, inode tables and FATs are relatively predictable) has been one of the enduring problems of full disk encryption. Wikipedia [wikipedia.org] can give one an idea of where this has been and is going. The oldest listed disk encryption software is only 15 years old. Considering that DES, is ~30 years old, and the concepts of public key crypto were discovered shortly after WWII, there has not been a lot of time for the study of this area.
  • Quote: "the attack also breaks the ability of users to 'hide' separate encrypted volumes inside already encrypted volumes, whose existence can now for the first time now be revealed."

    Excuse me, but wasn't this mentioned right here some months ago? And turned out to be a special case?

    Not to mention the poor grammar. "whose existence", indeed.
  • by SmilingSalmon (1143805) on Sunday October 05, 2008 @11:56PM (#25269647)
    Lots of people here are talking about users backing up their own data, but what about a border agent backing up your data? There's some real danger. Let's say you regularly pass through an international border where the country has a policy of making back ups of your laptop drives. Many corporate travelers are in this situation. The border agent takes a quick snapshot of your drive on Monday morning. You leave the country on Friday, but return the following Monday. When you return next Monday, they take another snapshot. Bingo. If any of your files have changed but the drive key is the same, they've got the backup they need to prove you have a hidden drive and even find the vulnerable images.
  • by rhythmx (744978) on Monday October 06, 2008 @01:46AM (#25270115) Homepage Journal
    This is neat, but it seems like a whole lot of hyperbole. What this is a chosen plaintext attack with a very small domain to choose from.
    • The attack requires an encrypted bitmap, and another encrypted bitmap of the exact same size and color palette.
    • The two ciphertexts must be saved and extracted from the exact starting block number on the disk (because the block number seeds the cipher)

    This attack will only effect uncompressed images, because compression increases the entropy so that pixel information will be entirely different as the colors change.

    Finding a pair of encrypted twin images like this is nearly impossible. How can they even tell where an image starts on disk when the filesystem itself is encrypted? Not to mention the very strict (and unlikely) requirements on the images themselves. The odds of actually being able to exploit this on a live system are very low IMHO.

  • I can use this to collect the bounty on the Gpcode virus? [computerworld.com]

We will have solar energy as soon as the utility companies solve one technical problem -- how to run a sunbeam through a meter.

Working...