Email Clients with Encrypted Archives? 49
jasonbrown asks: "If your like a lot of us, you want to keep all your good email for later viewing. Then again, who wants to have all that personal stuff laying around when some higher power decides to dig through it. I was wondering if the Slashdot community knows of any good, preferably linux compatible, email clients with an encrypted archive to keep your old email away from prying eyes."
re: Email Clients with Encrypted Archives? (Score:5, Funny)
fk9aoeka89ok7aozeka.iKHAOEKauoe7kaeyFH43%YG.
--- END ENCRYPTED COMMENT ---
Good luck. (Score:1)
Re:Good luck. (Score:1)
Timing!! (Score:2)
use the filesystem, luke (Score:3, Informative)
Simple: Encrypt the filesystem. (Score:5, Informative)
Save, Simple, and you can use any email software you want.
Re:Simple: Encrypt the filesystem. (Score:1)
What about if the email is on the company's or university's Unix box, where you ssh to run pine on a server on which you can't mount filesystems to any directories? And you still have to keep the mail in one place in order to access it from anywhere. A mail client that'd crypt its archive mboxen would be nice, not that I knew of any :(
If you're using a personal computer then of course you can use whatever encrypting filesystem/loopback hack you want to. But that's a big "if".
Re:Simple: Encrypt the filesystem. (Score:1)
What about if the email is on the company's or university's Unix box, where you ssh to run pine
It doesn't really matter then if you encrypt the files or not, if they really give a toss about your mail then there's many ways of reading it (eg. attaching gdb to your program, having a second xterm pop up whenever you login that shows them exactly what you're doing). Ultimately if you don't trust your admins you're fucked.
Re:Simple: Encrypt the filesystem. (Score:1)
Re:Simple: Encrypt the filesystem. (Score:1)
I had it working right on windows but this should be a lot easier to implement on a Linux-like system.
I discontinued my use because I didn't find it worth my effort. I don't have that much conspirational stuff going on that I have to encrypt my email. And any encrypted email I receive is decrypted for viewing but is still stored in encrypted form so that doesn't need a second level of encryption on top.
But hey, if you're paranoid, go for it.
my setup (Score:3, Interesting)
Strange... (Score:2, Informative)
But seriously, if you are working on a Winbloze platform, I think that Pegasus stores the mail file in an encryped format - password protected at least - to keep people away. Not for sure on that one, but I will check. May not be heavy enough encryption to keep the Feds off your back, but it should keep the old lady or your less-than-saavy computer friends out. (Or in the case of some, your parents)
Re:Strange... (Score:1)
For example, create a 600Mb file called email.pdg using PGPDisk, mount it as X:\ (or whatever) with a password or the passphrase to your public key and copy your e-mail archives into it - maybe into a folder called X:\mail\, then tell your mail client to use the X:\mail\ folder as the mail store.
Every time you boot you can be prompted for the password and when you unmount the PGPDisk, or shutdown, your data becomes safe.
I choose a file size of 600Mb so it will fit on a CD without any hassle.
Lotus Notes (Score:1)
I hate to say it, but use lotus notes (if it's possible to get it to sync to a real mail server rather than a notes one). Notes allows you to store encrypted local copies of stuff on your machine, protected by your notes ID and password
I don't like encouraging people to use notes, but it seems like the answer in this case.
Notes won't work, and here's why.... (Score:3, Interesting)
Where Lotus Notes breaks down in this situation is the certifier IDs. In LN, an administrator uses a "god" (or certifier) ID to create other IDs. That "god" ID can also go back and alter the IDs that it created (like to extend expirations, do name changes for marriage/divorce), which means that forgotten passwords can be unlocked.
So, using Lotus Notes will keep anyone who's not your boss, and anyone who's not the government, from reading your email.
There are other encryption keys that the end-user can create in Notes (the ID file can store several encryption keys in it, in different formats, so it's somewhat like a key manager), and they can use these for encryption, but these other keys are used to encrypt fields only, which means you'd have to write something that would take all the fields in your emails, and create new documents in your archive, and encrypt the fields along the way. (Simple, really, and it'd probably take me an afternoon to do.) The on-disk encryption is for the ID only (the one issued from the certifier), which means Bosses and Governments still can get it.
Oh, but Notes is reasonably stable running under WINE.
Brings me to one other bit. In the 4.x family of Notes, there were 3 encryption versions. 64-bit (U.S./Canada only, but strangely titled "North American" as if everything north of Panama isn't in North America), 40-bit (International), and this strange French version (unknown encryption, but the French Government didn't want any encryption, really, so it was even lower encryption).
The U.S. and International versions both used the same 64-bit encryption. However, the U.S. held 24-bits of the 64-bit international key in escrow. That, to me, means that the U.S. could crack 40-bit encryption back in the mid 1990's. In the newest release, the encryption level is higher (128?), and there's only one level for all distributions (I'll exclude France as I really don't know), but that's partly because of eased export laws on encryption, and partly because I think the Feds realize they can get around encryption.
If you have your own certifiers, and can digitally shred these as the Feds are knocking down your door with a search warrant in hand, then maybe it'd work.
Re:Notes won't work, and here's why.... (Score:2)
This is straightforward because your "password" is not your encryption key. The key is generated by encrypting the password with itself (skipping a *lot* of details) and the ciphertext is the encryption key. It's trivial to add another step that replaces some of these bits with known values. As long as the same password->encryption key algorithm is used the user will never know this happened.
(It's worth nothing that DES 64-bit keys are actually 56-bits of real key, the rest is parity. I don't know if the 40-bit keys were true 40 bits, or if they were as few as 32-bits of real key.)
As an aside, you're confusing the geographic and legal definitions of "North America." The US and Canada have very similar cultures since both are former British colonies which absorbed earlier French colonies (Quebue, Louisiana). Mexico and points south, former Spanish colonies, might be on the same side of the equator but have a very different culture.
North America (Score:2)
Offtopic now, but about ten years ago, the media did one of their famed polls about how little adults know, and one of the results was how few people could name 3 countries in North America.
(I always love those polls where they ask adults something, then schools are forced to teach kids what the adults didn't know.)
Back to encryption, I should have added that once the Feds (or whomever has resources) has your Notes ID file, or your GPG/PGP private key file, then brute force attack becomes much easier. Lotus Notes uses PKI, with the ID file holding the private key, and the directory of Notes users holding the public key.
Having said that, I don't know if it was 56-bit DES, or what, but I do remember the password hash was stored in the ID file, and not the actual password (I think it was the MD5 checksum, but I don't think there was a salt used). I did do a diff on an international vs. a north american version, and only 5 files differed. 2 files each were only in one distribution, and a single DLL had differently named functions in it.
Re:Notes won't work, and here's why.... (Score:2)
I work in a Lotus Notes shop, and the one thing that keeps people from wiping their Microsoft partitions is the lack of a good native Lotus Notes client for Linux. Most of the Lotus guys I know say that the biggest question they get is "When will there be a Notes client for Linux?"
So, what the answer? Why doesn't Lotus develop a native-Linux Notes client?
As for the "it works under Wine" point, that's probably true, but our IT weenies don't let us get our hands on the Notes install CDs. Grrr...
Re:Notes won't work, and here's why.... (Score:2)
Well, the version of Notes 5 under Linux I first saw was an RPM that -- the source told me -- was created in IBM by some frustrated users, and contained Note R5 plus a limited part of Wine. (Install the one RPM, and you were gold.)
I think what's keeping Lotus from going after a Linux version of the client is:
lack of market sharelimited OLE functionality
non-unified GUI
The Lotus Domino server is fully supported on Linux, and you can buy SuSE bundled with the Domino, and SuSE is going to distribute IBM's linux offerings for IBM, so there's potential.
Slightly off topic, but the other thread on Slashdot right now about LindowsOS shows Lotus Notes running on a Linux box. Mirrored screen capture:
http://members.rogers.com/kawaichan/1.gif [rogers.com]Re:Notes won't work, and here's why.... (Score:2)
Consider: How could Microsoft keep the Lotus people from porting and releasing a Notes client for Linux? Could they threaten to withhold APIs and hooks into Windows from Lotus or perhaps even raise the tax...er...licensing fees they charge Lotus/IBM now?
Did this with mutt once (Score:1)
Instead I wrote a little script run from cron which moves my sent-mail to sent-mail-(date) and encrypts the whole thing. This runs once a month. I find it's a good compromise between security and usability.
Outlook (Score:4, Informative)
Depending on how much grief other people reading your mail is going to cause (legal, or merely embarrassing), it's worth noting that several countries already have laws requiring you to give up the keys to your encrypted mail in certain situations, and others are considering similar laws.
Pretty easy cribs for this. (Score:2, Insightful)
X-crack-this-poor-dope's encryption: SOMEVERYLONGSTRING.
The odds are, he'll never see it, and now you have a known cleartext string to look for.
I have got to say, an encrypted fileseystem is probably the best, as at least you don't know where you are supposed to be looking for this string, then.
Re:Pretty easy cribs for this. (Score:3, Informative)
If the crypto was done right, the message was compressed and then encrypted in "chaining" mode with DES, 3DES, IDEA, AES, or a similar strong cipher. Having known plaintext won't help much in this case.
Back up a step. Why keep it? (Score:3, Interesting)
True, I don't like the idea of someone going back through years of email and reading private things. But maybe messages shouldn't be saved by default. And how often do we really go back through our old email for something? Not trolling here, but the majority of email I get isn't worthy of digital immortality.
At one of the client sites I consulted, they deleted all Inbox mail after 30 days, and had a 3-year maximum retention on everything else in the mail file. (To keep it past 30 days, you basically had to move it to another folder.) Sent mail was also deleted after 90 days, but you could override that, up to the 3 year max. (Contrast that with another site where SEC made them keep _everything_ for years and years.)
I gotta say, I love it. I've even tweaked my email client to ask me if I want to save a copy, for everything I send.
useless (Score:4, Informative)
If you are planning on doing stuff you would rather not have extra evidence of later, don't talk about it over e-mail! If you are conspiring with other folk stupid enough to send incriminating information over e-mail, you have bigger problems to worry about. If you are already sending all your e-mail in an encrypted form, you simply need to keep the encrypted e-mails in the archive as well.
Re:useless (Score:2, Insightful)
Unless the e-mail is encrypted during transmission there is little point in worrying about storing it on your local machine in an encrypted format.
Sure, the email should be encrypted during transmission, but there are instances where you are required to keep a paper trail for later reconstruction. A good example is the government. Also, when an organization is actively beefing up security, the fact that they've basically used ignorance in the past as their security protocol, has no bearing on future activity.
If they already have copies of some of the clear text that resides in the encrypted archive, it will be child's play to find your encryption keys and decrypt the entire archive.
Too true. Don't send it unencrypted. But that's not part of their information request.
If you are already sending all your e-mail in an encrypted form, you simply need to keep the encrypted e-mails in the archive as well.
The problem with this methodology is that if leads a cracker directly to all the "loot". Encrypting everything means they have a lot more work on their hands.
Get a grip (Score:4, Insightful)
The issue most of us face isn't somebody actively snooping into our lives at all times, it's our boss taking a peek around our system to try to find some dirt. Nothing criminal, not even acting in bad faith, but a discussion of how much the VP looked like a drunk duck or a dancing Balmer at a "rally the troops" meeting would do nicely in damaging our image with senior management.
Of course the boss could ask IT to search the mail archives kept by the company, but then they would have dirt on him! Nope, much better to make a midnight raid and 'accidently' forward the incriminating message to the topic of discussion late some night....
Re:useless (Score:1)
Most modern encryption systems are not vulnerable to "known plaintext attacks". Although DES can be attacked with this it is still not easy. Far from it in fact.
And if you use a serious system you do not have the same key for each message. Each new mail is encrypted using DES/AES/or similar with a random key which in turn is encrypted with RSA. (This way the program doing the encryption can't be studied to learn the decryption key.) This is what PGP/GPG already do BTW.
So although that particular mail has been compromised the rest of the archive is safe.
Next to be secure you need to make sure that your email client / OS is not vulnerable to trojans. If you can't trust your own system you need to use a trusted system to view the messanges. (This is rather theoretical and mainly applicable on public terminals in libraries and internet coffe houses.)
If you want to be paranoid about it it's far easier for someone with access to listen in on your telephone conversation or use a tele-microphone to listen in when you take a stroll in the park than it is to crack an encrypted transmission.
Re:useless (Score:1)
False. One of the criteria for a strong encryption algorithm is resistance to known plaintext attacks. For symetric key algorithms this means the fastest attack is bruit forcing all of the keys, even if you have an arbitrary ammount of known plaintext. In other words, you cannot recover the key any faster than guess-and-check. For AES with a 256-bit key, this means an average of about 32,000,000,000,000,000,000,000,000,000,000,000,000 ,000,000,000,000,000,000,000,000,000,000,000,000,0 00 tries. All of the world's computers (assuming current trends, and remembering that symetric ciphers are not obviously broken by quantum computation) will not cover this many keys until long after the formaldehide diffuses out of your corpse and soil microbes have devowered all but your coffin.
Re:useless (Score:5, Insightful)
Furthermore, for any reasonable cryptosystem, having even tons of plaintex and encrypted text available is not sufficient to recover the key.
mutt (Score:3, Informative)
You could pretty easily do this with mutt and the compressed folders patch.
It allows you to specify a regex for a folder, and then operations for opening and closing. It wouldn't be that much different than using bzip2 or gzip on a folder.
IMAP is your friend (Score:2, Interesting)
1. Use IMAP instead of POP; this keeps the mail on the server.
2. set up an IMAP server on a box that you control, preferably at home. Put the server behind SSL.
3. When you want to archive an email, drag it over to your home server, and delete the original.
This assumes that you use an email client that can talk to multiple IMAP servers at once.
Try Crypto Heaven (Score:1, Informative)
PGP Your Archive (Score:2, Interesting)
1. Save all your old mail to a file other than the default.
2. PGP encrypt that file.
3. It would be pretty simple to write a script to first decrypt the file with a password and then launch your mail reader to read old mail from that file.
I know its not elegant or the perfect solution but it is much simpler than writing a client todo it. I know a lot of people will be talking about encrypted filesystems. The problem with this, is that your root or user password is usually much shorter than your PGP passkey. The second problem is that not everyone owns the system thier mail is stored on, you have to consider that with systems such as IMAP your mail is stored in TWO places.
I've never even considered encrypting my old mail, this is a very good idea. Good luck in finding a more elegant solution, and if you do please post it here!
Re:PGP Your Archive (Score:1)
Eudora and Netscape conveniently let you choose your mail directory,
unlike the Microsoft clients. You can save your mail directory on a
PGP disk (PGPDisk). This worked very well for me for years. You can of
course do the same thing with any Linux client using volume [sourceforge.net]
encryption (preferably on a single partition -- not root
-- as small as possible to avoid losing performance).
But what are you worrying about? They say Linux is invincible...
Mcrypt (Score:1)
http://mcrypt.hellug.gr/
"At the time writing this, it supports the algorithms: BLOWFISH, TWOFISH, DES, TripleDES, 3-WAY, SAFER, LOKI97, GOST, RC2, RC6, MARS, IDEA, RIJNDAEL, SERPENT, CAST, ARCFOUR and WAKE."
then write a wrapper script for your mail client
to unencrypt the mail folders, run the client, and
then re-crypt them before exiting.
works well for me.
Pine + PGP4Pine + GnuPGP (Score:2, Informative)
Of course, this assumes you want to use PGP while sending and recieveing messages too (and why wouldn't you..)
use an encrypted file system (Score:2)
If you must, Emacs/XEmacs can be set up to automatically decrypt/encrypt on load/save, and that should work with any of the Emacs/XEmacs mail clients. The packages are crypt.el or jka-compr.
The Bat (Score:2, Informative)
Of course, you could also just encrypt your old mail file. How often do you go through mail from 1998 anyway?
burn it (Score:1)
Ralf
Storing data (email and files) securely (Score:1)