I am looking for a way to encrypt a document that is robust to data corruption. Consider the integrity of an image. You can mangle a lot of pixels and still figure out what the picture shows. However if you bury a message in that image using steganography, a small change will render the encrypted message lost. Is there a way to encrypt a document so that even some corruption of the encrypted product does not prevent decryption?
-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
robust cryptography
- Thread starter bwanaaa
- Start date
sm625
Diamond Member
Only if the message you are steganographically encrypting is also in the form of an image with pixels that can be mangled. Take a captcha for example. You can mangle and corrupt the heck out of a captcha's pixels, and still read it. But obviously that form of encryption consumes a lot of data.
On a side note I wish more people knew about steganography, because if they did then they would see the farce in all our alphabet soup agencies and how it is nothing but a huge scam and a racket. We or they nor anyone else has any idea how much encrypted information passes under our noses every day, and we will never know. Did you know that it is possible to encrypt a voice over a smartphone directly into a recorded voice of a completely different person? You could have two male muslim terrorists discussing plans over an open line, but all the FBI will hear in their wiretaps is a scandinavian female voice saying "Honey, can you stop by the store and pick up some bread?" Its such a joke I cannot believe people tolerate such blatant wasting of taxpayer dollars.
On a side note I wish more people knew about steganography, because if they did then they would see the farce in all our alphabet soup agencies and how it is nothing but a huge scam and a racket. We or they nor anyone else has any idea how much encrypted information passes under our noses every day, and we will never know. Did you know that it is possible to encrypt a voice over a smartphone directly into a recorded voice of a completely different person? You could have two male muslim terrorists discussing plans over an open line, but all the FBI will hear in their wiretaps is a scandinavian female voice saying "Honey, can you stop by the store and pick up some bread?" Its such a joke I cannot believe people tolerate such blatant wasting of taxpayer dollars.
It depends on the encryption mechanism, most ciphers these days are "block" ciphers. They work on independent "blocks" of data which are individually encrypted.
To encrypt, you need a key, and your plaintext, but you also need a random (but shared with the decryptor) initialization vector (IV) which pre-randomises the cipher, to help protect "replay" attacks, where the same message will always encrypt to the same value.
Simply using the same IV for each block is simple, but degrades security, as if your document contains lots of repeated data blocks, the encrypted copy will contain repeated data blocks in the same place.
A very popular way of encrypting documents has been to use cipher block chaining (CBC). The first block is encrypted with the shared IV. Then a hash of the block and the previous IV is used as the IV for the next block. This improves security, but has the disadvantage, that blocks must be decrypted in order. If a block is corrupted, all other blocks following will also be corrupted, because the IV that gets chained onto the following block will be junk.
An alternative method, and one that is used for full disk encryption is called Galois Counter Mode (GCM). In this case, the IV used for each encryption block depends on the original IV and the number of the block which are hashed together using a special Galois field hash algorithm.
The advantage of GCM in your case, is that as long your corruption doesn't lead to missing bytes (so that the block counter stays in sync), GCM will only produce corrupted output in the same blocks which were corrupted on the input.
GCM is frequently used these days, as it can be parallelized onto multiple cores (CBC can't, as it is strictly in order), and is convenient for disk encryption (which is inherently random in order). GCM is so frequently used, in fact, that Sandy/Ivy bridge CPUs contain a special GCM instruction to accelerate the computation of this function.
Cliffs:
You need to operate your choice of encryption algorithm (e.g. AES) in GCM mode.
To encrypt, you need a key, and your plaintext, but you also need a random (but shared with the decryptor) initialization vector (IV) which pre-randomises the cipher, to help protect "replay" attacks, where the same message will always encrypt to the same value.
Simply using the same IV for each block is simple, but degrades security, as if your document contains lots of repeated data blocks, the encrypted copy will contain repeated data blocks in the same place.
A very popular way of encrypting documents has been to use cipher block chaining (CBC). The first block is encrypted with the shared IV. Then a hash of the block and the previous IV is used as the IV for the next block. This improves security, but has the disadvantage, that blocks must be decrypted in order. If a block is corrupted, all other blocks following will also be corrupted, because the IV that gets chained onto the following block will be junk.
An alternative method, and one that is used for full disk encryption is called Galois Counter Mode (GCM). In this case, the IV used for each encryption block depends on the original IV and the number of the block which are hashed together using a special Galois field hash algorithm.
The advantage of GCM in your case, is that as long your corruption doesn't lead to missing bytes (so that the block counter stays in sync), GCM will only produce corrupted output in the same blocks which were corrupted on the input.
GCM is frequently used these days, as it can be parallelized onto multiple cores (CBC can't, as it is strictly in order), and is convenient for disk encryption (which is inherently random in order). GCM is so frequently used, in fact, that Sandy/Ivy bridge CPUs contain a special GCM instruction to accelerate the computation of this function.
Cliffs:
You need to operate your choice of encryption algorithm (e.g. AES) in GCM mode.
Last edited:
In encryption there is pretty much a direct correlation between damage done by errors and the strength of the block cipher mode. After all, a good cipher will produce entirely different cipher text for two plaintexts that are slightly different. Vice versa, a tiny change to the ciphertext will produce two entirely different plaintexts. There are block cipher modes that attempt to limit the scope of errors to nearby blocks, but not as a general error correction scheme.
Instead, if you want your ciphertext to be resistant to errors, you should further encode it with an error correction code. The receiver would first decode and correct errors, then decrypt.
Actually, steganography has fallen out of favor for two reasons. First, it's pretty tough to develop a system that isn't easy to detect. The common way to detect steganography is to run a statistical analysis on the data of interest and compare to known distributions. For example, think somebody is encoding information in timing delays between IP packets? Measure the distribution of the time between packets and compare to what you'd get from normal traffic. Statistical tools can do some really in-depth analysis with barely any user input, making it really tough to come up with something undetectable.
Second, you need a huge amount of data in which to hide your information. The general rule is at least 10 times. So if you want to hide a 4 MB picture taken from your phone you need at least a 40 MB picture (for image-in-image steg anyway). And that's suspicious right there. Or you can split it up and take 10 photos for every one you want to hide. Not very convenient.
Your example is actually extremely difficult. Voice encodings are already so compressed (often dynamically, based on the nature of the voice) that it is really tough to do voice-based steganography, to the point that it's basically a no-go.
Furthermore, the point of steganography is to hide in plain site, to not stand out. Which do you think stands out more: a 30 second conversation in Arabic between two Muslim men at the bazaar, or an hour-long recording of a Scandinavian woman's voice ordering groceries on a cell phone in North Africa? 😉
Instead, if you want your ciphertext to be resistant to errors, you should further encode it with an error correction code. The receiver would first decode and correct errors, then decrypt.
sm625 said:
Actually, steganography has fallen out of favor for two reasons. First, it's pretty tough to develop a system that isn't easy to detect. The common way to detect steganography is to run a statistical analysis on the data of interest and compare to known distributions. For example, think somebody is encoding information in timing delays between IP packets? Measure the distribution of the time between packets and compare to what you'd get from normal traffic. Statistical tools can do some really in-depth analysis with barely any user input, making it really tough to come up with something undetectable.
Second, you need a huge amount of data in which to hide your information. The general rule is at least 10 times. So if you want to hide a 4 MB picture taken from your phone you need at least a 40 MB picture (for image-in-image steg anyway). And that's suspicious right there. Or you can split it up and take 10 photos for every one you want to hide. Not very convenient.
sm625 said:
Your example is actually extremely difficult. Voice encodings are already so compressed (often dynamically, based on the nature of the voice) that it is really tough to do voice-based steganography, to the point that it's basically a no-go.
Furthermore, the point of steganography is to hide in plain site, to not stand out. Which do you think stands out more: a 30 second conversation in Arabic between two Muslim men at the bazaar, or an hour-long recording of a Scandinavian woman's voice ordering groceries on a cell phone in North Africa? 😉
sm625
Diamond Member
lol use your imagination. It wouldnt be an hour-long recording of a Scandinavian woman's voice ordering groceries, it would be two girls babbling incessantly back and forth. Hell they could be hired to yap endlessly for like 50 cents an hour from some eastern european country. The computer records it all and puts in a database to be later used for encrypting. And yes you can easily fit an entire voice stream into another compressed voice stream, it just has to be even more compressed. But the fact that these kinds of girls babble so fast makes their voices especially useful for steganographic purposes. One could queue up hours and hours of this stuff for use in steganography. Same goes with pictures. Look at the hundreds of millions of megabytes of meaningless pop culture garbage plastered all across the web every day. There is in fact so much of it that one cant help but think a big part of it is actually already being used for steganography. It certainly wouldnt surprise me.
Don't get me wrong, steganography is definitely possible, it's just not practical. Who is maintaining this gigantic database of recordings? How are they paying for it? How are they implementing non-attribution?
Furthermore, steganography is most useful when you're trying to hide the fact that you're passing encrypted data around. If it requires a giant centralized database with all of the attendant business logic, data transfers, record keeping, costs, and international cooperation, you're so far gone from the purpose of steg to begin with.
This is incorrect and does not reflect the realities of voice compression and channel bandwidth. Voice communication is an extremely poor channel for steganography.
There's lots of images on the web, but image-based steganography requires you to embed data in images that you own. You can't magically embed data in somebody else's Facebook pictures. For every picture of a reptilian overlord shooting JFK on a staged moon-landing set you need at least 10 pictures of your wife and kids. And then you need a way to encode information for the recipient on how to stitch them back together. Then you need many more pictures so an attacker won't know which pictures to try to decode. And then you somehow need to mangle all the photos in a way that the steg'd photos don't include the telltale entropy signs of tampering.
Steganography is not easy. There are vastly superior mechanisms available for LPI/LPD communication.
A block cipher in Electronic Code Book Mode will give you the integrity that you want. Any corruption of the cypher text would only impact that specific block.
Uno
the problem i have is embedding information in an image that can withstand conversion of the image to other formats. so if for example, i save some proprietary information in a schematic drawing that is saved as a tiff. then another person edits the photo saves it as a jpg. then another person rescales that image and sends it by email. then another person adds a caption. when the final recipient converts it back to a tiff, the original steganographically encoded info is not retrievable. however the image is clearly recognizable as the original.
Aside from using a watermark in the original image, is there any other way to encode information into the image that will be preserved despite image editing? or is this not possible due to a fundamental property of information and steganography? Claude Shannon where are you.
Aside from using a watermark in the original image, is there any other way to encode information into the image that will be preserved despite image editing? or is this not possible due to a fundamental property of information and steganography? Claude Shannon where are you.
Format conversions, recompressions, and minor image modifications could all be modeled as different kinds of errors. For instance, a lossy conversion from TIFF to JPG, from high bit-depth to low, might be modeled as a binary erasure channel, where the least-significant bits are erased. Adding overlay text might be an additive error channel. You could model all of the conversions you want your data to survive and then choose an ECC method as appropriate.
It wouldn't be trivial though and I suspect that you would end up with an extremely low bandwidth channel.
Is there a specific scenario in mind here? Or just a general question on error tolerance in steg?
It wouldn't be trivial though and I suspect that you would end up with an extremely low bandwidth channel.
Is there a specific scenario in mind here? Or just a general question on error tolerance in steg?
Let's take the example of image copyright. It is too easy to edit out a watermark with today's powerful tools. But if the copyright is also embedded in the image data (not the metadata which is too easy to edit) then I could very easily prove that someone stole my photograph.
Another way would be to manually alter the data in the file and adding information like copyright somewhere in there that only I know about. For example, in the old days, Macintosh file formats had a data fork and a resource fork. You could even add whole images to the resource fork of a Microsoft word file and no one would know.
I guess I'll just have to play around with a hex editor and see what I can change in a jpg file without corrupting it.
Another way would be to manually alter the data in the file and adding information like copyright somewhere in there that only I know about. For example, in the old days, Macintosh file formats had a data fork and a resource fork. You could even add whole images to the resource fork of a Microsoft word file and no one would know.
I guess I'll just have to play around with a hex editor and see what I can change in a jpg file without corrupting it.
This technology is well established in image and audio watermarking technology.
Photoshop has had the ability to embed encrypted copyright data into the pixel data for nearly 20 years (digimark). This copyright message can survive cropping, scaling, editing, image compression and even rotation. It is also (near) invisible to the human eye.
Similar tech is used in audio to identify movie soundtracks. (cinavia). Mediastreamer boxes and bluray players include detection for this encrypted copyright message. If the media being played is not a pressed, encrypted disc, then the player will abort playback. This message is so persistent that a home movie e. g. a kids party with a tv in the background showing an marked movie, will be unplayable on a compliant media player.
Photoshop has had the ability to embed encrypted copyright data into the pixel data for nearly 20 years (digimark). This copyright message can survive cropping, scaling, editing, image compression and even rotation. It is also (near) invisible to the human eye.
Similar tech is used in audio to identify movie soundtracks. (cinavia). Mediastreamer boxes and bluray players include detection for this encrypted copyright message. If the media being played is not a pressed, encrypted disc, then the player will abort playback. This message is so persistent that a home movie e. g. a kids party with a tv in the background showing an marked movie, will be unplayable on a compliant media player.
That's interesting. Do you have an example of this? A recording of a TV playing a video should encode only the bare minimum to reconstruct the image as seen by the camera. It would seem that either the camera is not compressing well enough or the watermark "channel" has a very low bandwidth.
Sorry, I wasn't clear. The watermark is in the audio and has a VERY low bandwidth - in the region of several seconds per bit.
It takes about 10-15 minutes for a compliant player to detect the watermark.
The very low bandwidth makes the watermark detectable even the watermarked audio is present only as a quiet ambient noise (e.g. a TV showing a movie at a kids party).
Some pirate groups have tried to analyse it, and have found that the watermark is still detected even if the audio is bandpass filtered into 1 kHz bands - each individual band will trigger the watermark detection. The same groups have failed to find any detectable autocorrelations, etc. which suggests some form of PRN spread-spectrum technique with decent code length and relatively low chip rate - or possibly multiple spreading codes.
Last edited:
I wonder if that's what Google uses to detect copyrighted audio on youtube. It takes a few weeks for their spiders to detect and analyze everything, but they do remove clips that use copyrighted audio.
Thanks for that link to digimarc. I did not realize though that it degrades the entire image and also increases file size 40%
http://www.kenrockwell.com/tech/digimark.htm
A gaussian blur has also been found to erase the watermark.
In fact, the increased graininess is objectionable in the examples I have seen but I need to try it myself to see.
I have found that I can add text to the end of a file using a hex editor after the END delimiter and it does not affect the image.
Thanks for that link to digimarc. I did not realize though that it degrades the entire image and also increases file size 40%
http://www.kenrockwell.com/tech/digimark.htm
A gaussian blur has also been found to erase the watermark.
In fact, the increased graininess is objectionable in the examples I have seen but I need to try it myself to see.
I have found that I can add text to the end of a file using a hex editor after the END delimiter and it does not affect the image.
A few seconds per bit is crazy low.. And individually detectable across each 1kHz band.. That's just overkill! I suppose the 'message' is just some nonce signed with a cert whose common name is the copyright holder or something like that. Probably not a lot of information.
Do you have any links?
Do you have any links?
John Connor
Lifer
I used a program that hides stuff inside pictures or music before. In fact my avatar had an encrypted message in it. The best way to prevent corruption is to burn to optical media.
John Connor
Lifer
Well, I have burned Truecrypt containers on a CD with on the flash writing and it never failed. You must have had some bad disks. I betcha I can burn an audio track to CD and take a before and after SHA-1 hash and they will be the same.
SecurityTheatre
Senior member
I betcha you can too.
I also betcha that it's one of the least reliable types of media in the long term.
But I'm sure it worked for you grandmother that one time...
Short discussion of lifetimes of optical media
Looks like they ballpark 20-200 years depending on type of media. That assumes "correct" storage. There's a NIST paper out there somewhere that goes into more detail about humidity levels, light levels, etc.
Edit: Here it is. It's dated back to 2004, but under more aggressive environmental exposure they have estimates in the hundreds to thousands of hours (days to months).
Looks like they ballpark 20-200 years depending on type of media. That assumes "correct" storage. There's a NIST paper out there somewhere that goes into more detail about humidity levels, light levels, etc.
Edit: Here it is. It's dated back to 2004, but under more aggressive environmental exposure they have estimates in the hundreds to thousands of hours (days to months).
Last edited:
John Connor
Lifer
I read an article in a magazine once that said how to keep your optical media for as long as possible. A couple of pointers I took from the article was to store them up right in a shoe box in a cool, dry environment and never write on them. Belive me, I had encryption on the fly with an optical disk and Truecrypt. It never failed. I pity if a nuke bomb goes off and the EMP fries your hard drives. 😛
Things I will not be thinking as the fireball from a nuclear detonation envelops my house: "Oh no, my laptop!" 😛
gsaldivar
Diamond Member
You could encrypt, then archive with PAR2, which will tolerate a certain degree of data loss without compromising the integrity of the archive.
http://en.wikipedia.org/wiki/Parchive
http://www.quickpar.org.uk/CreatingPAR2Files.htm
http://en.wikipedia.org/wiki/Parchive
http://www.quickpar.org.uk/CreatingPAR2Files.htm
1prophet
Diamond Member
1000 year dvd and soon blu ray
http://www.digitalartsonline.co.uk/news/creative-hardware/m-blu-ray-disc-offers-lifetime-of-storage/
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 24K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
