Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Encrypted Images Vulnerable To New Attack

kdawson posted about 6 years ago | from the bye-bye-deniability dept.

Encryption 155

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."

cancel ×

155 comments

Sorry! There are no comments related to the filter you selected.

aw4jthpa (1, Funny)

Anonymous Coward | about 6 years ago | (#25266621)

naivjdae4ovhnrBuAbrf!AbjLbhPnaFrrZlPbzzrag!;wfqudnwrenfyihltred

Re:aw4jthpa (4, Funny)

martinw89 (1229324) | about 6 years ago | (#25266687)

Oh god, thanks for the outline of Goatse.

Jerk.

Re:aw4jthpa (4, Funny)

mrsteveman1 (1010381) | about 6 years ago | (#25267699)

You didn't look close enough, there was a hidden volume inside!

Confusing (5, Insightful)

Rui del-Negro (531098) | about 6 years ago | (#25266623)

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)?

Re:Confusing (3, Funny)

mikesd81 (518581) | about 6 years ago | (#25266707)

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:Confusing (0, Offtopic)

phillips321 (955784) | about 6 years ago | (#25266863)

http://rtfa.co.uk/ [rtfa.co.uk]

Re:Confusing (1)

mikesd81 (518581) | about 6 years ago | (#25266951)

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?

So..I stated I read the article...what's your point?

Re:Confusing (3, Funny)

Anonymous Coward | about 6 years ago | (#25267083)

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

Re:Confusing (0, Redundant)

Darkfire79 (1094983) | about 6 years ago | (#25266957)

yea, I was kind of confused at first

Re:Confusing (0)

Anonymous Coward | about 6 years ago | (#25267123)

I thought the same thing at first, but it seems to consistently refer to images of the picture variety. hidden volumes are talked about but not referred to as images.

Re:Confusing (0, Redundant)

andrikos (1114853) | about 6 years ago | (#25267723)

Both digital photos and drive images are still "images", no?

First (-1, Offtopic)

Anonymous Coward | about 6 years ago | (#25266651)

FIRST!

Watermark? (4, Insightful)

Lord Byron II (671689) | about 6 years ago | (#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? (5, Interesting)

profplump (309017) | about 6 years ago | (#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? (3, Interesting)

Goaway (82658) | about 6 years ago | (#25266807)

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? (5, Informative)

mikenap (1258526) | about 6 years ago | (#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.

Re:Watermark? (1)

Goaway (82658) | about 6 years ago | (#25267061)

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

Re:Watermark? (4, Informative)

kasperd (592156) | about 6 years ago | (#25267671)

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? (1)

phantomcircuit (938963) | about 6 years ago | (#25266949)

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

wiki [wikipedia.org]

Re:Watermark? (1)

Goaway (82658) | about 6 years ago | (#25267013)

...and isn't CBC.

Re:Watermark? (1)

kasperd (592156) | about 6 years ago | (#25267577)

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.

Re:Watermark? (1)

profplump (309017) | about 6 years ago | (#25267269)

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 *do* use CBC methods:
http://en.wikipedia.org/wiki/Disk_encryption_theory#CBC-based_approaches [wikipedia.org]

Re:Watermark? (2, Informative)

mikenap (1258526) | about 6 years ago | (#25266851)

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:Watermark? (2, Interesting)

Ronin Developer (67677) | about 6 years ago | (#25267451)

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!

IV problem and flash disk (3, Informative)

CustomDesigned (250089) | about 6 years ago | (#25267793)

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.

NOT the ECB flaw! (1)

Kaseijin (766041) | about 6 years ago | (#25267755)

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.

Re:Watermark? (1)

hairyfeet (841228) | about 6 years ago | (#25268105)

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, they can at least know that it is being hidden." Which sounds to me like they need a backup image of the encrypted volume that hasn't been kept up to date. Would you still be vulnerable to this attack if you didn't have a backup or just used RAID?

Two,it also mentions in TFA that this works because images have low entropy. Since nearly every Operating System out there can treat Zip files as folders would simply keeping all image files in a zipped folder be enough to screw this up?

And I apologize if these turn out to be stupid questions. But I'm just learning when it comes to encryption and it is hard to just jump in and get up to speed on such a complex subject. Oh and thanks for your time and I hope you had a great weekend!

Re:Watermark? (5, Informative)

mikenap (1258526) | about 6 years ago | (#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 (4, Interesting)

TheLink (130905) | about 6 years ago | (#25266787)

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.

hi (-1, Offtopic)

Anonymous Coward | about 6 years ago | (#25266657)

rror

Compressed images (4, Insightful)

Lord Lode (1290856) | about 6 years ago | (#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.

Re:Compressed images (4, Insightful)

cjonslashdot (904508) | about 6 years ago | (#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.

Re:Compressed images (4, Insightful)

mrbah (844007) | about 6 years ago | (#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 (3, Informative)

Goaway (82658) | about 6 years ago | (#25266825)

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

Re:Compressed images (0)

Lord Lode (1290856) | about 6 years ago | (#25267163)

I'm definatly very sure that PNG has runlength encoding (incorporated by LZ77). And Huffman encoding on top of that.

Re:Compressed images (2, Informative)

azgard (461476) | about 6 years ago | (#25267319)

LZ77 is not run-length encoding. Run-length encoding only encodes repeated sequences of same letters, while LZ77 encodes repeated sequences as pointers to the previous instance of the same sequence.

Re:Compressed images (1)

Lord Lode (1290856) | about 6 years ago | (#25267679)

Ok you're right - well, it depends on when you call it runlength encoding :)

Re:Compressed images (1)

Goaway (82658) | about 6 years ago | (#25267329)

Lempel-Ziv is not runlength encoding.

RLE in images (5, Informative)

DrYak (748999) | about 6 years ago | (#25268061)

Plain JPEG uses runlength and huffman encoding [wikipedia.org] on the quantized matrix obtained after DCT.
This is relatively efficient because there are a lot of long string of repeats in the matrix (see Wikipedia article).

(This is where some applications such as Stuffit have been able to non-destructively increase the compression of JPEGs and gain a couple of 1% by using better algorithms to store the quantized results)

In lossless mode, JPEG uses instead Arithmetic coding on the raw non-quantized results of DCT.

PNG uses LZ77 (either on the raw pixels or on a delta) wich is an entirely different beast. As pointed out by other /.ers it's a *dictionary* compression which replace repeat parts with pointer to where to they where repeated first :
"ABACDABA" becomes "ABACD{go back 5 letters and copy 3 letters}"
It doesn't need a separate RLE mode, because the dictionary can be abused as follow :
"ACCCCCC" in RLE is "A{repeat 6xC}" and in LZ77 is "AC{go back 1 and copy 5 letter}"

Re:Compressed images (1)

jbengt (874751) | about 6 years ago | (#25267669)

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.

Re:Compressed images (1)

Goaway (82658) | about 6 years ago | (#25267931)

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

Re:Compressed images (0)

Anonymous Coward | about 6 years ago | (#25267691)

I'm quite sure that jpeg uses run-length encoding after scaling the coefficients.

Re:Compressed images (1)

mikesd81 (518581) | about 6 years ago | (#25266753)

See this quote [slashdot.org] with this article [techworld.com] .

Re:Compressed images (1)

mikesd81 (518581) | about 6 years ago | (#25266761)

Eh. Wrong quote, right article.

Re:Compressed images (1)

perlchild (582235) | about 6 years ago | (#25267093)

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

Only works on uncompressed bitmaps (5, Informative)

mrbah (844007) | about 6 years ago | (#25266673)

The article points out that this attack only works with uncompressed bitmaps with extremely low entropy. This is hardly a cause for alarm.

Re:Only works on uncompressed bitmaps (4, Funny)

clarkkent09 (1104833) | about 6 years ago | (#25266799)

Whew, thanks for pointing that out. Most of my encrypted porn is jpgs

Re:Only works on uncompressed bitmaps (1)

Naughty Bob (1004174) | about 6 years ago | (#25266901)

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?

Re:Only works on uncompressed bitmaps (-1, Troll)

Anonymous Coward | about 6 years ago | (#25267129)

Most of my encrypted porn is jpgs

Why would you need to encrypt your porn...

Because he's tired of walking in to find his mom masturbating to it?

Old news for TrueCrypt (5, Informative)

martinw89 (1229324) | about 6 years ago | (#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.

Re:Old news for TrueCrypt (1)

ORBAT (1050226) | about 6 years ago | (#25267085)

Because telling people not to do something stupid is always effective, right?

Re:Old news for TrueCrypt (1)

martinw89 (1229324) | about 6 years ago | (#25267177)

Not always, but it does certainly go against the following from the summary:

...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.

I wouldn't call something that encryption experts have known about and warned users about for a long time new.

Re:Only works on uncompressed bitmaps (1)

Artraze (600366) | about 6 years ago | (#25266819)

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 use RLE though, IIRC).

Re:Only works on uncompressed bitmaps (2, Interesting)

strstrep (879828) | about 6 years ago | (#25266977)

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.

Re:Only works on uncompressed bitmaps (3, Interesting)

Anonymous Coward | about 6 years ago | (#25267001)

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?

Re:Only works on uncompressed bitmaps (1)

vlm (69642) | about 6 years ago | (#25267307)

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

Re:Only works on uncompressed bitmaps (1)

caluml (551744) | about 6 years ago | (#25267973)

Like this [blogg.no] , you mean? (Couldn't remember the link to that nuyd place, so hot linked - sorry :( )

Re:Only works on uncompressed bitmaps (1)

ColdWetDog (752185) | about 6 years ago | (#25267393)

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

ASCII Porn?

Windows desktop backgrounds (1)

argent (18001) | about 6 years ago | (#25267453)

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.

Based on comparison of two versions of the volume (2, Informative)

Anonymous Coward | about 6 years ago | (#25266679)

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 suspect and get copies of an encrypted volume at two different points in time. (A hint for Truecrypt users: Changing the passphrase does not change the key.)

Re:Based on comparison of two versions of the volu (1)

leuk_he (194174) | about 6 years ago | (#25267185)

Flash media.

Which at the same time makes flash media vulnerable. The wear leveling feature of flash media could cause an old verion of a block to stay on memorychip, making it vulnerable to exactlyy this kind of attacks.

What about crypto modes? Never heard of CBC, CTR? (3, Insightful)

boldi (100534) | about 6 years ago | (#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.

Re:What about crypto modes? Never heard of CBC, CT (1)

exscape (1302123) | about 6 years ago | (#25266743)

Yes, I didn't get this as well. I'm by no meant an encryption pro, but I've at least implemented CBC and CFB modes, and I don't quite see how they could find outlines in a CFB encrypted image (for example!). I mean come on, the wikipedia article has for a long time had an ECB (the "worst" mode) encrypted image in the article about block cipher modes: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 [wikipedia.org]

Re:What about crypto modes? Never heard of CBC, CT (1)

Kaptain_Korolev (848551) | about 6 years ago | (#25266915)

Completely agree, I thought the same although I have seen ECB used a lot simply out of ignorance and/or laziness. Something like counter ( CTR ) mode is very very very easy to implement and increases the security immeasurably. Like in most crypto solutions, there is no point having a strong cipher like AES when the protocol you use it within is a pile of plops, such as here.

Re:What about crypto modes? Never heard of CBC, CT (4, Informative)

Goaway (82658) | about 6 years ago | (#25266837)

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]

Re:What about crypto modes? Never heard of CBC, CT (1)

Kaptain_Korolev (848551) | about 6 years ago | (#25266953)

Maybe, but surely you could implement a sort of low resolution cipher chaining so that you used the chaining on only a small number of blocks. Enough to cover up any entropy analysis of what you were encrypting. Doing this on a small number of blocks would reduce the computation an add to security... I think* * This isn't my area any more, I've been out of the electronic crypto game for several years.

Re:What about crypto modes? Never heard of CBC, CT (1)

Goaway (82658) | about 6 years ago | (#25267021)

I linked the article that explains what to actually do, you know.

Re:What about crypto modes? Never heard of CBC, CT (1)

Kaptain_Korolev (848551) | about 6 years ago | (#25267097)

Ah ha, sorry, must learn to read!

Re:What about crypto modes? Never heard of CBC, CT (0)

Anonymous Coward | about 6 years ago | (#25267487)

A choice of modes is often available for IV generation. Loop-AES, dm-crypt, and TrueCrypt all support a choice for IV generation, and since this is usually well-advertised feature in such packages, the GP was likely talking about a choice of mode for IV generation.

Re:What about crypto modes? Never heard of CBC, CT (1)

RiotingPacifist (1228016) | about 6 years ago | (#25267841)

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).

Re:What about crypto modes? Never heard of CBC, CT (1)

Goaway (82658) | about 6 years ago | (#25267943)

These aren't backups.

Re:What about crypto modes? Never heard of CBC, CT (2, Informative)

Fnord666 (889225) | about 6 years ago | (#25266919)

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).

Re:What about crypto modes? Never heard of CBC, CT (1)

RiotingPacifist (1228016) | about 6 years ago | (#25267873)

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?

Is that it? (0)

Anonymous Coward | about 6 years ago | (#25266713)

So, if you have two similar blocks encrypted with the same key, that also contains bitmaps, an investigator may be able to see the image and or detect the presence of a hidden volume?

Am I getting it right?

It seems (4, Informative)

mikesd81 (518581) | about 6 years ago | (#25266747)

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.

no IV and thus ECB-mode is probably the problem (1)

ion++ (134665) | about 6 years ago | (#25266765)

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]

Re:no IV and thus ECB-mode is probably the problem (1)

Goaway (82658) | about 6 years ago | (#25266841)

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

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

Re:no IV and thus ECB-mode is probably the problem (1)

mikenap (1258526) | about 6 years ago | (#25266903)

As I replied before:

It does work by breaking the disk up into sectors, each of which starts 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.

Re:no IV and thus ECB-mode is probably the problem (0)

Anonymous Coward | about 6 years ago | (#25266945)

But ESSIV together with "chaining" on the file level does. Encryption isn't free, but this allows access to any file at O(1). Though it could be a bit slow for large files, so perhaps a reinit every Megabyte or so might be needed to prevent O(n).

Re:no IV and thus ECB-mode is probably the problem (0)

Anonymous Coward | about 6 years ago | (#25267115)

Please, help me understand what is wrong with this:

# HASH=sha256
# CIPHER=aes-cbc-essiv:sha256
# LEN=256
# cryptsetup -h $HASH -c $CIPHER -s $LEN create sda1 /dev/sda1
# mount /dev/mapper/sda1 /mnt/sda1

If the device, sda1, has been prefilled with random data, then I am under the impression that the device remains a big, random block of bits when mounted without the proper key. It is very much worse than any needle-in-the-haystack problem.

Please, help me understand. Give me some hard facts where this is crack-able.

Re:no IV and thus ECB-mode is probably the problem (1)

Free the Cowards (1280296) | about 6 years ago | (#25266981)

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 broken and cannot be trusted in any way. The good news is that this break is nothing particularly interesting in and of itself, and that it will do nothing against a competently designed product.

Re:no IV and thus ECB-mode is probably the problem (3, Insightful)

Free the Cowards (1280296) | about 6 years ago | (#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.

Why RTFA when you can guess? (1)

Kaseijin (766041) | about 6 years ago | (#25267635)

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)."

TrueCrypt is immune (1)

PhrostyMcByte (589271) | about 6 years ago | (#25266809)

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.

Bullshit (0)

Anonymous Coward | about 6 years ago | (#25266861)

The article is full of errors and so it is hard to judge from this as the sole information source. Anyway, from what the article says it sounds very much like a vendor of snake oil encryption trying to boost his sales. For example, as opposed to what the article seems to suggest in a reasonable implementation of a symmetric crypto algorithm it is usually avoided to use the same key twice (and in some modes like CTR you have to ensure this).

loop-aes (0)

Anonymous Coward | about 6 years ago | (#25266877)

the attack's assumptions are too idealized. but even so, loop-aes, who needs 64 keys for encryption plus one iv given by the user, may be immune to this attack. it uses cbc mode in 512-byte chains. so for aes-256, for an image to be vulnerable, it has to contain identical blocks and be bigger than 256*64*512= 8*(2**20) bytes (8mb). not counting the additional randomess caused by the supplied iv.

btw, gentoo has excellent support for loop-aes :)

Encrypted harddrives not affected (1)

grahammm (9083) | about 6 years ago | (#25266909)

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.

Not New at All (1)

phantomcircuit (938963) | about 6 years ago | (#25266911)

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.

sounds like FUD (1)

Bender_ (179208) | about 6 years ago | (#25266975)

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)

who to blame: (1)

davidsyes (765062) | about 6 years ago | (#25267087)

Ken Starling!

nonsense (1)

speedtux (1307149) | about 6 years ago | (#25267201)

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.

Re:nonsense (1)

Jesus_666 (702802) | about 6 years ago | (#25268025)

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's because you guys are f*****ers. (-1, Flamebait)

Anonymous Coward | about 6 years ago | (#25267241)

I'm going to get modded down or stay at 0 but here's a clue. Just like you DON'T encrypt Skype packets if you expect me not to laugh in your face (what, you expect skype to make similar traffic when there's silence as when you're talking over each other? Freaking moron), the ONLY way to encrypt a drive is to first convert it into a single file.

You then encrypt the file, erase the source files. Decryption is this in reverse.

"BUT I WANT RANDOM ACCESS BOO HOO HOO." Well, tough shit. My wife would like two-way Skype calls. No. You record the ENTIRE call (your end) then pad it to one gigabyte and encrypt. PERIOD. She does the same. You exchange once per day at midnight by uploading it as a series of Youtube videos' night-time web cam (or cell phone video) static.

WHY IS THIS SO HARD TO UNDERSTAND??

Re:it's because you guys are f*****ers. (0)

Anonymous Coward | about 6 years ago | (#25267473)

I guess the mods don't have a sense of humor today.... that was hilarious :)

Patents? (1)

MartinSchou (1360093) | about 6 years ago | (#25267359)

"To our knowledge is the described method free of patents and the author can confirm that he hasn't applied for protection."

Seriously? Can an attack on cryptography, and it's possible counter-defensives be patented? Just how much could you screw up the US financial systems, if you came up with an attack on encrypted trafficing (like the stuff banks and stock markets use), came up with the "only" defense against it, and then patented both?

Of course you'd never license the attack to anyone, but since it's patented, it's well described in public.
And you'd want to get paid quite well to license the defense against this attack, wouldn't you? Say ... 1% of the value of all transactions protected.

Can you say (0)

Anonymous Coward | about 6 years ago | (#25267417)

shitty encryption?

seriously

The amount of misconceptions here is appalling (0)

Anonymous Coward | about 6 years ago | (#25267475)

This is not a problem with block encryption modes at all. Disk encryption software can't rewrite the whole disk every time a block changes. That is a fundamental problem. If a block changes and you have an image before and after, then you can tell which block changed. It's worse if the key and IV stay the same for that block, but often the information which blocks changed between two images is all you need, for example to spot the location of filesystems and consequently to tell if there is a hidden volume.

Re:The amount of misconceptions here is appalling (1)

Kythe (4779) | about 6 years ago | (#25267981)

The point about detecting hidden volumes is certainly a good one, but also obvious and one that has been noted in Truecrypt documentation and elsewhere for a long time now.

That's one reason why I prefer to use hidden volumes with read-only media (e.g. full-volume CD-ROMS).

Is this a "known plaintext" attack? (1)

grandpa-geek (981017) | about 6 years ago | (#25268101)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?