Slashdot Mirror

I just tried, and it worked. (Granted, it wasn't a very good test: I embedded your post, zipped, inside today's featured picture, with OutGuess, a JPEG steganography tool.)

Unfortunately, due to that compression/resizing Facebook performs, the data did not survive (even with OutGuess' ECC option enabled and using Facebook's "download in high resolution" link).

If your jpgs look like everybody elses jpgs both visually and under close analytical scrutiny they aren't going to bother you.

But steganographic data stored in images (all kinds of images, not just JPGs) is detectable analytically. I would suspect our TLFs (Three Letter Friends) can easily spot steganography in images, especially given privately developed steganographic analysis software like outguess exists today.

I would also suspect they do it on a massive basis, checking images on eBay, Picasa, flickr, photobucket, etc. The TV news has already squawked about "terrorist messages hidden in pictures on eBay." Without further clarification I can't tell if they meant that they detected steganography; or if they meant a guy was selling a book, the picture of which was an opened page written in Arabic that said "start the jihad on the 20th".

If I were pulling images to look for hidden messages, and if I had the resources of the TLFs, I'd run them through an OCR program, a stego detect program, an image verifier program (because no image file contains random data) and I'd probably be looking at all kinds of analysis, such as testing the JPG quantization for consistency with the tables from the same brand of camera claimed in the EXIF info.

Can I analyze all your hard drive picture files while you stand in line in airport security? Not realistically. But can I start analyzing your on-line pictures as soon as you buy a plane ticket? That's a lot more realistic.

One of the easier ways to restrict how your words and ideas are searched and indexed on the net is to to hide them in plain sight. A jpg image of text is very dificult for a search engine to use, yet you and I can read and understand the data quite easily. This ability to scan on line has been around, but not mainstream to my knowledge. I'm guessing Google has been checking jpgs for text as a trial for some time. Once this is gone maybe ASCII art text will work for a while. Hiding/protecting data by steganography is detectable by scan now, eg http://www.outguess.org/detection.php so the battle continues. Of course one can work offline and send letters to each other and be protected by law :-) I wonder if one day sending stuff my mail will seem shady?

Even the best-trained human eyes and ears, according to Kip, can't detect the change.

Maybe not, but I bet outguess can, along with a million other stego tools.

Not 100% correct, you can use a program called StegDetect which will give a probability of hidden data in a file, this has been very useful for me in the past

I ran the image through stegdetect and it came up with a "false possitive". This utility detects images encoded with jsteg, jphide, invisible secrets, outguess, F5(header analysis), AppendX, and Camouflage. Although, steghide is not listed, I have found that false possitives are shown with images that I know to have an embeded file.

I played around with steganography at one time and setup a script to create embed images via the web using Outguess

I ran the image through stegdetect and it came up with a "false possitive". This utility detects images encoded with jsteg, jphide, invisible secrets, outguess, F5(header analysis), AppendX, and Camouflage. Although, steghide is not listed, I have found that false possitives are shown with images that I know to have an embeded file.

I played around with steganography at one time and setup a script to create embed images via the web using Outguess

If I PGP encrypt a file on my disk (say a virtual disk container), why would I covert it to ASCII (base 64 encoding) too? The binary encrypted file would just look like random bytes.

Encrypted files or messages are usually encoded in ASCII (with the headers/trailers you quoted) only for sending over e-mail.

Useful programs for implementing and detecting steganography: http://www.outguess.org/

As stegdetect (last time I checked) easily fails on files created with steghide

Lets see someone put together an app that flips bits here and there within MP3s to make each one it runs against unique enough to create a new MD5 hash!? (I would, but I can only program in a pseudo-language ;) It could even be as simple as adding in a trailing byte to all of your MP3s, though that could be easily filtered. Hell, if you can hide messages within compressed JPEGs without noticeably affecting their quality, why not do something similar to MP3s just to jack up this sort of tracking!?

Sometimes recovering the original image is not as important as hiding the steganography in a harder to detect fashion. Here is a steg tool that tries to do just that, by keeping statistical properties of the steg-carrying data.

I know of no software available which could truthfully be called "industrial strength". But Outguess is alright, and may evolve into something better as time goes by.

Sure, if we FFT the data (or the like) it will survive the transform of one compression, but what about when it is recompressed at a lower ratio? Is there anything we can do about this (like using the lowest frequency coefficients)? Or should we submit our graphics uncompressed and let Tripod compress them once?

You'd have to alter the DCT coefficients by a greater amount. As long as the amount each coefficient is altered is more than the quantization level which Tripod or whatever uses, the data is preserved. I don't know if you can alter this parameter in Outguess.

The problem here is that if you modify the DCT coefficient too much, you can start to see the distortion with the naked eye. That's always going to be a problem when lossy compression schemes are used to combat steganography -- the steganography will (probably) have to cause visible distortion of at least the same level that the lossy compression causes.

Also, inserting the steg into DCT coefficients won't achieve robustness against other compressions, eg JPEG2000. If you want a really robust scheme, you will have to settle for tiny bandwidth - read up on watermarking technologies, as they aim to insert of the order of 10-50 bytes into an image, in such a way that one really has to mangle the image to destroy the data.

Wrong. See www.outguess.org.

(From a steg researcher, who gets rather irritated at everyone thinking they are an expert on this difficult subject.)

It would appear that Camera/Shy puts the "hidden" message in the least significant bits of an image. This is a terrible way to do steganography - researchers have long known that it is extremely easy to detect this method. For example, go to outguess.org for some software which can detect it, and links to papers describing how this works.*

Using this sort of software is worse than not using it at all - you are just attracting attention to the fact that you have something to hide! Whereupon you can expect the full might of the Echelon/Carnivore machines to be used against you. Don't be tempted by the easy UI. As someone else has already mentioned, LSB steganography is the equivalent of ROT13 encryption.

If you want to send truly secret messages, read some steganography literature - which will give you an idea of how difficult real steganography is. Best would be to wait 5 years until we have sorted out which, if any, steganography schemes are secure.

*The concept of how the detector works is not hard, but IMO these papers are rather badly written and you may find them hard to read. They don't really report their experiments fully. But believe me, LSB steganography is extremely poor.

Sorry, the link should have been www.outguess.org

You are absolutely right. I was going to post the same thing. This is asteg'dimage, and this is the original. I don't remember what I used as a key but I used PGP to encrypt a text file then used Outguess to encode the encrypted PGP message into the image. I don't even remember what I used for the steg passphrase so if anyone wants to have a go at it feel free. I think the feds would want you to work for them if you could find the original message.

use OutGuess and store your data across your porn jpegs! I've been collecting porn over the past 8 years for just this purpose!!!

the judge is *most* likely to believe:
"Your Honour, all those files are of naked men and women getting it on. i have 40+ gigs of it for variety!"

like you said...
Steganography only works when the carrier files have utility beyond that of the hypothetical encrypted information.

Looking for a few good crusaders to join the War Against Islam. Strike down the new Satan with your righteousness: outguess.org - purveyors of fine image-based steganography (and steganography detection) tools.

Instead of me rehashing _why_ that implementation is such an infantile attempt at stego check out Outguess by Neils Provos a PhD student at the Univeristy of Michigan.

He also links to his own and other academic papers on the subject

Also, there are other ways to investigate image files.

I've experimented with Provos' steganographic tool, outguess . I encoded a short message in a .jpg using the default option to foil detection by preserving statistical properties of the cover medium. Sure enough, the companion detection tool, stegdetect was not able to detect that a message was concealed.

Then, on a hunch, I converted the original and altered .jpgs to .bmps, and examined them side by
side using od -c | less. In the .bmp produced from the altered .jpg, I noted repeated 'senseless variations' in color values, usually pixel triplets of 377-376-377 (octal), as my sample pic was an object on a white background.

Of course you would need the original image to definitively prove alteration of content. But this could be reduced to process and used to sift through content for likelihood of alteration. Such a tool might prove beneficial as a substitute for blunt instruments such as Carnivore.

Thoughts?

Dug

You are so wrong. This is just like encryption: Intuitively, everyone thinks it is easy to scramble information, but eventually, cryptanalysis got sophisticated, and we learned that only mathematically sophisticated, rigorously reviewed cryptography has a chance at being safe. Similarly, amateur steganography schemes are probably worthless.

-go through the image in a certain direction, and change each pixel value by 1 to encode a binary "1", or leave it alone to encode a binary "0".

Of course the method you describe isn't detectable to the naked eye. But it would be trivial to detect it statistically. Just look at the gradients in adjacent pixels. In you image, they will be jumpier than in a normal image. Go check out stegdetect to see some of their techniques and results.

Yes, it is generally agreed that modern encryption algorithms can hide data with virtually perfect security. But this alone is not relevant, as long as the government can detect the use of these algorithms.

All the government has to do to nail your "Terrorist Tim" is observe that he is using encryption, and check for the existance of a matching escrowed key. Presumably, any key escrow system would allow for verification that a message was encrypted using an escrowed key, without actually retrieving the key or decrypting the message. Thus, it is entirely conceivable to me that the government could enforce the use of key escrow: Whenever they see encrypted traffic that does not use an escrowed key, they trace the user via the ISP and prosecute him. And maybe they drop the connection, so you can't even get one message through then hide.

So, anyone who wants Internet privacy under this regime must hide the fact that they are hiding data. But, you say, there's a whole field dedicated to this end, called steganography, so the goverment loses again. While steganography is exciting and promising, it's not the knock-down argument that you seem to think.

First, I agree that it is easy to covertly communicate a small amount of information to someone with whom you have prepared ahead of time. Any simple system of code words or similar is probably secure for a brief message or two. But, ...

• People need to communicate more than a few messages on a predetermined subject. A naive system will not stand up to statistical analysis of many messages. For example, you might think that coding messages in the first characters of each word would be undetectable. Hardly--just look for anomalies in the letter frequencies of the first letters.

• People need to communicate without having arranged a system beforehand. Even serious steganography (at least the systems I know about and can imagine) requires a shared secret, implying major challenges in key exchange. In the age of public keys (now the lynchpin of virtually all secure communication), we forget about what an enormous breakthrough asymmetric cryptography was.

• Even serious steganography may be detectable! Just as the government can monitor for non-escrowed keys, they can monitor for any steganography system that they have broken. It is currently not known whether undetectable steganography can be developed.

• Steganography does not have the infrastructure, either in software or in familiarity and understanding, that encryption has. We all know that quality of implementation and good practices are as important as mathematical strength in the successful use of cryptography. Thus, people need to have software they can use and an understanding of do's and don't's. At least, it will take some time before steganography reaches the level of encryption in these regards.

(In the above, you may substitute "terrorists" for "people".)

The point: not that the government should or will do this; but that if they decide to do it, it is not futile! It really could (in addition to destroying the privacy of lawful citizens) slow down terrorist communications (assuming that terrorists use the Internet, which people seem to think they do). So we need a better argument against it than "this is stupid, it can't work".

There are method of hiding data in plain sight. Just read "Chaffing and Winnowing: Confidentiality without Encryption" at http://theory.lcs.mit.edu/~rivest/chaffing.txt


Also, said Terrorist could use multiple techniques together:

- write message
- apply method of Chaffing and Winnowing (above) or method of hiding messages in spam.
- hide that message in favorite media with outguess.
- encrypt that with PGP or GnuPG.
- encrypt that with the mandated, key-esrowed, back-doored technique
Now there are several barriers to break down, but only the easy one is known about until an investigation is already under way.

Or:
- said terrorist could avoid electronic communications, and meet face to face in a public park or on a public bus or in a crowd

Ask a gardener how they deal with weeds. Do you just remove what you can see, or do you go after the roots? Ask a doctor how he/she deals with a disease. Does he/she treat the symptoms and hope for the best over time, or does he/she treat the source of the disease?

Yes, cutting off one of their means of communication would be an incovenience for people who have evil plans. But is there a better we that we can deal with their evil plans in the first place?

I don't know the answers, I just ask the questions.

The point of this is not to boast about how I'm looking for a pissing contest with John Ashcroft. The point is that the odds are that they won't catch me, and if I'm willing to take the risk out of mere financial need and defiance to the state, a bunch of wild-eyed fanatics who aren't afraid to die certainly aren't going to be dissuaded either.

Of course, the idea that some laws are so completely unenforceable that they can be casually ignored is lost on these fools if the so-called "war on drugs" is any indication.

Outguess looks like a good start.

All they'd have to do is hide no-backdoor encrypted messages within backdoor-encrypted messages, and it would be undetected unless Carnivore automatically decrypted all messages, which conflicts with what the lawmakers are saying -- "only under the oversight of a court".

As for stenography, check out this link.

The history of cryptography has shown that the seemingly simple goal of transmitting hidden information is actually really, really hard. The suggestion that if the government outlaws the well known digital privacy schemes, people will come up with others just as good, is naive. It's the same reasoning that says that secret encryption algorithms should be more secure than public algorithms. It grossly underestimates the techniques available to detect and break poorly designed systems.

If the author of OutGuess can detect most steganography, I would not feel at all secure using your "hide the encrypted message in an executable" trick.

The history of cryptography has shown that the seemingly simple goal of transmitting hidden information is actually really, really hard. The suggestion that if the government outlaws the well known digital privacy schemes, people will come up with others just as good, is naive. It's the same reasoning that says that secret encryption algorithms should be more secure than public algorithms. It grossly underestimates the techniques available to detect and break poorly designed systems.

If the author of OutGuess can detect most steganography, I would not feel at all secure using your "hide the encrypted message in an executable" trick.

And you might look at Stegdetect, by the author of OutGuess. He claims to detect many other popular steganography techniques. The feds throw stegdetect onto carnivore, and you can expect using steganography to earn you one of those unpleasant visits.

Steganography is a long, long way from offering the practical security of encryption. Is it really possible to create a system that is undetectable even if the algorithm is public? Nobody's sure yet. Do the bad guys have the means to create their own effective algorithms and keep them secret? Questionable. Can they use a stego system correctly on a wide scale? Unlikely at present, since there is no popular, easy (for non-technical users) software, nor is there the widespread understanding of how to use stego that there is about crypto (these things do matter when it comes to the successful implementation of any security scheme).

The point is, the government can (by imposing on everyone's liberty) effectively stop criminals from communicating privately. Therefore, we need to come up with a better argument than "it won't work", in order to prevent it.

With carnivore, the government sees all traffic. They see crypto they can't break, they trace it with help from the ISP, they pay someone a not-so-friendly visit.

But encrypted data can be hidden in non-encrypted data, in ways that make it virtually impossible to detect, using steganography. So the criminals could send photos to eachother, or even have a web-cam feed with data steganographically encoded into the frames.

Take a look at OutGuess, for example. You might also find this article to be interesting, particularly the part with the photos of the Statue of Liberty.

Farid's Publications

say, which one of those papers listed on the page you mention talks about Farid's steganographic detection work?

The best part about Neil Provos' work is that he goes both ways, working on both OutGuess and stegdetect.

While i'm singing the praises of Neil Provos, thanks for your work on OpenSSH and pf, as well as the rest of the OpenBSD work you've contributed.

-f
http://www.blackant.net/

Farid's Publications

say, which one of those papers listed on the page you mention talks about Farid's steganographic detection work?

The best part about Neil Provos' work is that he goes both ways, working on both OutGuess and stegdetect.

While i'm singing the praises of Neil Provos, thanks for your work on OpenSSH and pf, as well as the rest of the OpenBSD work you've contributed.

-f
http://www.blackant.net/

You might also want to check the techreports that I published about my research.

At HAL 2001, I presented on Detecting Steganographic Content on the Internet. You might like that.

Dartmouth certainly seems to know how to do PR. I would just like to know where their publications are.

There's that stenography tool, Outguess, that claims it can hide info into a pic without changing the pic's statistical properties (entropy et al, I surmise). I wonder if it's Outguess that makes false (or misinformed) claims, or if Prof. Farid's research on statistical analysis is already out of date...

Personally, no matter what, I wish Prof. Farid a lot of luck. His work might be what will save our collective ass from SDMI-like schemes down the road.

Learn how the technology works before you post (and get moderated up so quickly, sheesh - moderators, do some research first too). Its not as simplistic as you imply, watermarks can be embedded that are not perceptible by the human ear, yet will still be detectable even after one or more generations of loss (e.g. creating an mp3 from the original, or going Digital -> Analog and re-recording to digital). Its called steganography, and similar techniques can be used for images, e.g. allowing image watermarks that can still be detected even when images are saved in horribly lossy formats such as JPEG (see for example http://www.outguess.org/)

Watermarking should be taken seriously, this is not something you should just brush aside with one hand, this is something that (I think) is going to start being used a LOT within the next 10 years by the media cartels looking to protect their IP. Should it become common to purchase music online (which is a very likely scenario eventually, even though the RIAA is currently fighting this to protect their current monopolising of distribution channels), it should be very easy to embed a unique watermark in each individual song purchased (not unlike the Intel PIII CPU ID); while this alone would not prevent piracy directly, it does provide a very handy powerful facility for tracking pirated music - a pirated MP3 could always be tracked right back down to the specific individual who purchased it. It wouldn't take too many legal threats/fines/arrests before people became too scared to pirate music.

Of course this isn't necessarily entirely "bad" if you assume that piracy is wrong, but there is potential for abuse (and American companies have proven time and again that if there is potential for abuse, there'll be abuse).

You should check out stegdetect. It is an automated tool that detects steganographic content in images. So far it can detect jsteg, jphide and outguess 0.13b. No user interaction, just run it and see the results.

For those wanting more information on stego check out the following link which I found to be one of the most informative. Outguess is probably the top of the line Nix stego program I've found (FYI) and you could see its output here (Statue of Liberty pics)

Personally I think this will piss off Big Brother more than it would Corporations, since it'd be extremely hard on a system to encipher a 700mb video clip into a picture so the stego comment seems off the mark to me where Napster or SDMI is concerned Watermarking yes stego a music file... Sure and $AUTHORITY_FIGURES will believe that pr0n picture is supposed to be 500mb in file size.

As for digital watermarking... Please see this prior post on this subject.

no. i mean steganographic.

stenography is writing in shorthand.
steganography is hiding information in such a way that people cannot tell you are hiding a message.

outguess hides data in image (pnm and jpg) files in such a way that you cannot tell the image is also storing data. There is also StegFS, the steganographic file system, in which other people cannot discern information about the file system, like how much space is being used, how many files there are, filenames, etc.

The whole point is that if no one even knows you are hiding something, then they won't know to look. With information which is just encrypted, then people can see that there is something for them to attempt to decipher. But this means that steganography is security through obscurity, so you'd want to couple it with some strong encryption too.

-f

size would become an issue. you could use compact flash - ibm has that nice gig microdrive though im not sure what cameras that can be used in.

-f

why hasn't this security issue with PGP been address yet? Are they waiting for an epidemic? Less reason to go goo goo over PGP.

Outguess

While tinkering recently with Outguess, I took a simple image about 28k and used a 1k text file to combine it into a new image (steganography owns). Well in certain instances depending on what I decided to embed into the image, the image would drop in size to about 7k some times, and other times it would still drop in size. Only once did it ever go over 28k which was when I embedded about 50k worth of text into the image, which still looked crisp to the naked eye.

Just thought I would share this. At one point I was thinking about making a script to lower the sizing of the many pics I have on my porn section, but I never bothered.

I also noticed there were other tricks to saving space on files but again, never got around to mentioning them, maybe some time I will who knows.

YOUR RIGHT TO PRIVACY INVADED

Ok so I wouldn't use AOL if they paid me to, but one has to be concerned, especially if they're an AOL user and by chance reading here. Users are supposed to have a right to privacy, judging by this article the interviewed person should be sued for violating someone's privacy rights while hiding under TOS bs. Surely I can see he states he is doing his "job" but how much of his "job" would be to post about older women and their cats. I would not be upset if I heard about AOL suing this moron for NDA based stuff.

Sure you can moderate this down and troll it to a -3 wouldn't matter, the facts remain, I'm sure even the typical user would expect to have some form of privacy when using their ISP.

Thanks to $INSERT_DIETY_HERE for PGP, stunnel, SSL, PPTP, Outguess

stor elak javel

That HOWTO is good, but severely out of date. To quote Cha pte r 10 - Encrypting files and drives in Linux, BSD, and other Unices"

By: Kurt Seifried, seifried@securityportal.com, for http://www.securityportal.com/

Do you have files on your computer that you wouldn't want your spouse to read, or perhaps your main competitor. Chances are if you use your computer for work or general usage the answer is yes. Also what happens if you want to send a file to someone, or let them download it from you, but you only have access to a public site (like a free web hosting company). The answer is to encrypt the file, and fire it off. For UNIX you have several choices, PGP, and GnuPG, as well as Guardbot for web based file transfers. If you work with files that are sensitive (such as spreadsheets containing sensitive financial data) the constant hassle of encrypting and decrypting the file (as well as the fact a decrypted copy will be stored on the filesystem, leaving a window of opportunity for an attacker) can get tedious. If this is the case you will want to use software such as, BestCrypt (commercially licensed but free for Linux with source code), or PPDD (Private and Top Secret, GPL licensed) which are both very similar in execution and general usage.

Pretty Good Privacy is available as a command line driven program for most UNIX platforms, and there are a variety of front end GUI programs for it. I would not recommend using PGP on a UNIX platform since a completely OpenSource, and compatible replacement is now available, in the form of GnuPG.

GnuPG is a GPL licensed (a.k.a. completely free in every respect), written in Germany (a very pro-crypto and pro-privacy country). Since it is available in full source code chances are it has been ported to your UNIX platform (and if not try compiling it, it might work). You can download GnuPG as a compressed tarball of source code, and there are links to a number of source and binary packages for various UNIX platforms. Once installed GnuPG behaves very similarly to PGP. The first thing you'll probably want to do is generate a new keypair, simply use the command "gpg --gen-key", it will create a ".gnupg" directory in which to store your keys, option files and so on and exit, you then run it again and it will lead you through the key creation process. Choosing the defaults during key generation is a pretty safe bet, although you may want to use a 2048 bit keysize (realistically if someone manages to crack 1024 bit keys, chances are they can get at your 2048 bit key, however if they are only trying to brute force it a longer key is a good way to reduce the chances of that). For personal keys the expiry is typically set to "0" (that is to say they do not expire), however if these keys are for corporate use, or for really sensitive information it is a good idea to expire keys and rotate them (every month, year, decade, whatever your security policy dictates). The most important thing when generating a key (in my opinion) is the passphrase. This is a string of characters which should consist of letters (upper and lower case) numbers and punctuation marks, the longer the better (I'd say the bare minimum is 10 characters). This controls access to the private key, which is used to sign items (and if compromised means an attacker could easily impersonate you), and to decrypt data (meaning an attacker could access all your data). Keep your private key secure! If an attacker gains access to this key they only have to brute force the passphrase, which is typically a lot weaker then a random 1024 bit (or longer) key. Worse yet they may steal your passphrase, with a keyboard sniffer or similar attack, resulting in a compromise of your key. If the attacker does not have access to your private key they will be forced to guess it, which takes a brutally long time (on average however, there is a chance they may guess the key correctly on their first try).

Signing files is useful if you want to distribute a file to someone, and be able to prove that you sent it, and it was not tampered with. Internally GnuPG takes a hash sum (such as MD5 or SHA1) of the file (basically it reduces the file to a shorter, unique string of data) which it then encrypts with your private key, generating a signature. This signature can then be decrypted with your public key, resulting in possession of the hash sum of the file, simply take the hash sum of the file in question, and if the they match, then obviously the file is what it claims to be. This signature file can be a binary file, or converted into text (for example signing email, or distributing file signatures via email). To sign a file with gpg simply use :

which will create a detached signature of the file.

To verify the signature use "gpg --verify file.sig file". If all is well you should see something like:

If someone has fiddled with the file or signature you will see something like:

Encrypting files is also relatively simple, a person uses your public key to run the data through a one way algorithm which results in a seemingly random mishmash of data, you can then use your private key to recover what the original data was, thus decrypting it. To encrypt a file to someone you first need their public key, you can download it from their homepage (if they have it online of course), or you can go to a public key server, of which there are many:

http://pgp.ai.mit.edu/ - PGP key server
http://www.keyserver.net/ - OpenPGP key server

Once you have their key it is simply a matter of signing and encrypting the file (just encrypting the file is rare as there is no proof of who the data is from, unless you use some other method, like physically handing them a floppy disk with the encrypted file). The following is an example of me signing a file and encrypting it with my public key:

The user ID can either be the key ID (such as: 47D0D9A8), the email address associated with the key (seifried@securityportal.com)or the name (not recommended as these are not unique, there are many John Smith's). You will end up with a "file.gpg" that is binary, if you wish to send the file via email it is advisable to use the "-a" ("--armor") option which will result in "file.asc" and is ASCII text, so you can read it straight into an email, or print it out, mail it, and let them OCR and decrypt it at their end. To decrypt a file sent to you simply:

and it will display the file (hopefully a text file) to your screen, followed by the veracity of the signature (if you have the persons public key):

if you want to save the decrypted file simply use "--output filename" and it will dump the content to "filename". You can also use shell commands such as "|" or ">" to further mangle the output (this is useful if you have automated systems such as a reporting mechanism which sends encrypted emails to a central repository).

BestCrypt

BestCrypt is a disk encryption program available for Windows and Linux. The nice thing is you can create an encrypted container (a file that is then mounted as a filesystem), and use it in Windows or in Linux (as long as it resides on a partition accessible to both, so putting it on your Windows partition is fine since Linux reads almost all Windows partition types). BestCrypt consists of some kernel modules (so your kernel will need to support loadable kernel modules obviously, and it helps if you are using tools like depmod, modprobe and the kernel module loader), and a userspace utility called "bctool". This program is however officially in "beta testing" for Linux, and probably should not be used for critical data (if it is, make sure you have backups). After testing BestCrypt for Linux I am satisfied that even though the software is officially beta, it is probably stable enough for most users, however your mileage may vary, all sales final, and don't blame me for any lost data. The only real problem with BestCrypt is a severe lack of documentation, while there is a man page that explains basic options, there is not a single example of how to create and mount a container (I suspect the release will have documentation, their Windows version documentation is quite good, a half meg helpfile). You need to download the software first, available as a source tarball, and source rpm (very easy to install on an RPM based system). Simply download either one, I would recommend the source rpm if you can.

followed by a lot of text while it unpacks, compiles and assembles the source RPM and binary RPM. You should then have a:

Simply install the binary RPM with a:

If you do not have an RPM based system, or the source RPM doesn't work for you, compiling the source code directly from it's tarball should be possible. Simply download the file, unpack it to an appropriate place (such as /usr/local/src) and issue the commands:

And you should be up and running. The first step is to create a container (a file that is encrypted and mounted as a partition):

You can of course use the "gost" or "des" algorithms, I would not recommend them as gost is less tested then the "twofish" and "blowfish" algorithms that BestCrypt supports, and single des is to easy to brute force. The next step is to format the container, you'll probably want to use msdos if sharing with Windows (i.e. a dualboot Linux and Windows machine), or if just Linux then ext2 is a good bet. You can also specify the size, if you make it so small this can be a problem, but because it is a file and not a true partition you can easily create a new, larger file, move all the data to it and use it instead of the older smaller one.

Once the file is formatted you should be able to mount it:

As you can see it is mounted as a part of the filesystem, just like a floppy disk would be for example. Remember to control access to the directory hosting the encrypted files carefully, no matter how good the encryption, if you have it set world readable you won't have gained any security. Also remember that as a user, root owns the / and can take ownership of any file or directory and see what's in it. Alternatively if an attacker gains root access they can log your keystrokes (or terminal traffic) and gain your password (and access to your files). As always your security is only as good as the weakest link.

PPDD is similar to BestCrypt, but instead of creating a file, encrypting that and mounting it, it actually uses a partition which is encrypted and mounted using the PPDD driver, because of this it can do a few additional things BestCrypt can't. If you only want to encrypt a few directories then I advise compiling PPDD as a kernel module, but if you want to encrypt the entire file system (including what you boot from) you will need to compile PPDD directly into the kernel (although as of 1.0 it's not to hard). Unless you have a GPL only policy I would recommend using BestCrypt if you are new to this (it is easier to install and use, and you can buy support). PPDD does have one enormous advantage over BestCrypt however, you can encrypt all of the system, including the boot drive and swap partition, making it ideal for situations such as laptops with sensitive data and minimizing the risk (to zero if need be) of accidentally leaving sensitive data in an unencrypted location (such as the swap file, /tmp, and so on) so if you need a higher security level I would recommend PPDD over BestCrypt (simply because you can encrypt everything). Another advantage of PPDD is that is uses two passwords instead of just one for each encrypted filesystem, so you can give one administrator one password, and another administrator the other password, meaning no single person can gain access to the data. Unfortunately as of the writing of this chapter PPDD is not available for kernel 2.2.13 or 2.2.14, so you will have to run the older 2.2.12 kernel (which is the stock kernel on many distributions in any case).

Download PPDD, and unpack it in a suitable location, such as /usr/local/src/, there are several files you should read, most notable the README file, and once done install I would recommend reading the PPDDHow.txt file. Installation is rather simply with:

This will first test the kernel source to make sure it's the right version and so on, then it will test the patches, then apply the patches proper, and then create the devices needed (similar to what BestCrypt does). At this point you need to recompile your kernel, first make sure you go into the configuration (via make config or make menuconfig or make xconfig), and enable the PPDD driver (in the Block devices section). Then save the config file and recompile the kernel as your normally would. Once that is done you will have to install the new kernel (copy it to /boot typically, edit lilo.conf and rerun lilo). Once you have rebooted you will want to build the tools for PPDD and install them with:

At this point you should be ready to use it, however I would recommend running the tests with:

They take a while to run, but it will save frustration later on if something is broken. Using PPDD is relatively simple, there are a number of utilities for creating, managing, encrypting file systems, and so on. You will also want to set the permissions and ownership on the /dev/xxxx that contains your encrypted data so that only root has access to it, PPDD will complain otherwise

At this point you should have a directory called /crypt which is /dev/hda3 (although on df and the like it will show up as /dev/ppddx). I will cover how to encrypt you entire filesystem with PPDD, at a later date however (it is extensively documented though).

Another new possibility is Guardbot, which password protects www pages. Essentially there are two components, an applet that encrypts the data, using DES (56 bit keyspace), and an applet that will decrypt the data with the password you provide. The advantage of this over traditional server based methods of control (such as htaccess in Apache) is that the user manages it fully, and can protect each file individually without much setup. To fully take advantage of the keyspace available your password must contain upper and lower case letters, numbers (and punctuation marks, but this can confuse users) of around 10 letters, however since people tend to choose less then random passwords a longer password then this is advisable. This program would be useful for getting files to other people cheaply (simply sign up for some free web space, post the file up, and get the password to the other person securely).

It is no longer enough in some countries to encrypt your data to prevent access to it. Recently in Britain a law was created making it a criminal offence to refuse to give up encryption keys or plain text versions of encrypted data.

StegHide hides data in files such as sound and picture files where not all of the bits in a byte are used. Since the data is encrypted it will appear random, and proving that the data is actually there is difficult. The only downside is to store a one megabyte file you need a sound/picture file of several megabytes, which can be cumbersome (but hard drives and high speed access are becoming cheap so it's a moot point). You can get StegHide at: http://www.stego.com/.

Steganographic File System actually hides data on your harddrive, making it difficult to prove that it even exists. This can be very useful as the attacker first has to find the data, let alone break the strong encryption used to protect it. You can get StegFS from: http://ban.joh.cam.ac.uk/~adm36/StegFS/& lt;/a> .

OutGuess hides data in image files, meaning you can send files in a way that won't attract to much attention (and can't really be prooved either). You can get it from: http://www.outguess.org/.

here - Outguess (haven't tried it, going to now) - Unix source tarball, BSD license.

With steganography you are hiding the fact of encryption.
You can have the strongest encryption in the world, and it will not protect you from a subpoena for the (private) key.
Security through obscurity isn't "bad" any more than lemurs are "bad".
When security through obscurity interferes with the verification and validation of an algorithim, that will make the algorithim weaker. That could be considered bad.
When you think you are hiding information and you are not, that could be considered bad. The link that I gave is to a steganography program that helps to hide the fact of seganography from stegonagraphic analysis.
I should, and do, use a lock on my safe that is so good that I can put that safe on a street corner, complete with a diagram of the lock, and no one can get into it.
But I think I'll put that safe (with that same strong lock) in my house, instead. Maybe behind a portrait.

Rather than using PGP, which is likely to get the undevided attention of any government agency, use steganography.
Take your plaintext, encrypt it, hide it in some of the least signifigant bits in an image, attach the image to an ordinary email, and off it goes!

Information Hiding Techniques for Steganography and Digital Watermarking by Katzenbeisser and Petitcolas is a book that has just been published last year and contains a lot more detailed technical information. However, Disappearing Cryptography is at least an amusing book to read.

There is also a bunch of software out there that can be used to embed hidden information into images and sound files. However, most of the programs can be detected. Read the paper by Westfeld and Pfitzmann, "Attacks on Steganographic Systems".

I myself have written a tool to hide data into JPEGs. It's called OutGuess.

You can find more software here.