Slashdot Mirror
Encrypted Images Vulnerable To New Attack
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."
naivjdae4ovhnrBuAbrf!AbjLbhPnaFrrZlPbzzrag!;wfqudnwrenfyihltred
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)?
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?
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.
The article points out that this attack only works with uncompressed bitmaps with extremely low entropy. This is hardly a cause for alarm.
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.)
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.
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
The summary title and summary write up are a little ambiguous.
That which does not kill me only postpones the inevitable.
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
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.
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.
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). 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.
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
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 this attack has been known for a while.
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.
It doesn't? What about the part in TFA that reads:
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
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.
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)
I linked the article that explains what to actually do, you know.
Ken Starling!
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Ah ha, sorry, must learn to read!
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.
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.
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.
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)."
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.
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.
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).
IranAir Flight 655 never forget!
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?
IranAir Flight 655 never forget!
These aren't backups.
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).
Kythe
Plain JPEG uses runlength and huffman encoding 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}"
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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.
"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)."
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Why would you need to encrypt your porn... unless....
Dude! Won't anybody stop you thinking about the children?
Privacy mode FTW!
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 guess what page appeared when they opened up Internet Explorer... obviously, the kids didn't keep their mouths shut.
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
IranAir Flight 655 never forget!
Oh, so terribly sorry, let me just change that to "none of those except one".
Maybe this amateur cryptographer should read a few more cryptography books (or even Wikipedia) before claiming something new.
No sig today...
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:
The society for a thought-free internet welcomes you.
The government has been known to nationalize whatever patents it wants, if it's too much bother to license them. It's then presumably free to re-license them to whomever it pleases.
"They were pure niggers." – Noam Chomsky
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.
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.
from TFA : "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"
-- OMG !eleventy-one - if you encrypt 2 slightly different things with the same key you can almost recover the pattern of differences between them. The example on the 'site only works because they take a blank image then compare it to a real one, of the same size encrypted with teh same key. The only way this attack would work in real life is if they had the key (unless people have a large habit of saving, and then backing up, large blank images before storing a picture (which has a large blank background) at the same location.
to avoid : a) initialize the "blank" space in any ecrypted volume to random numbers. b) don't store 2 hours worth if pure black video uncompressed at the same location as any data which has large blocks of ones or zeros.
In other words, if you use a block encryption scheme, then change the data in 1 of the blocks, the encryption only changes in that 1 block, and so you can recover the pattern of differences.
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?
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
No one modded you up, but kudos anyway. That sounds like a workable scheme - but it still costs twice as much disk io. There is probably a way to optimize that as well. I wonder also if having two IVs on disk is a security weakness?
So, this means ant in an encrypted volume, where the directory and node structure are not visible, you need to 1) identify where an encrypted image is, and apply this comparison algorithm to the EXACT same unencrypted image, to see if it's there.
In other words, the best that this can really do is prove is an image is is in the encrypted volume, by applying the comparison algorithm every 512/4096 bytes along the volume's byte array.
Good for providing a law enforcement case, not much for detecting evidence of a crime - unless you are stupid enough to leave the images around as unencrypted versions as as well as encrypted.
lyalc
False. I use XTS. If you use well-written software (dm-crypt + luks) you barely take a speed hit. I'm on serpent-xts-essiv:sha256 with a 256 bit key and I lose 20% disk access speed or so. Not even noticable unless I'm copying large chunks of data.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.