Hushmail Passing PGP Keys to the US Government

teknopurge writes "Apparently Hushmail has been providing information to law enforcement behind the backs of their clients. Billed as secure email because of their use of PGP, Hushmail has been turning over private keys of users to the authorities on request. 'DEA agents received three CDs which contained decrypted emails for the targets of the investigation that had been decrypted as part of a mutual legal assistance treaty between the United States and Canada. The news will be embarrassing to the company, which has made much of its ability to ensure that emails are not read by the authorities, including the FBI's Carnivore email monitoring software.'"

Re:Missing from the article

[Albanach]

The Register ran an article on this last week. From their piece:

US federal law enforcement agencies have obtained access to clear text copies of encrypted emails sent through Hushmail as part a of recent drug trafficking investigation.

The access was only granted after a court order was served on Hush Communications, the Canadian firm that offers the service.

Hush Communications said it would only accede to requests made in respect to targeted accounts and via court orders filed through Canadian court.

Hushmail did NOTHING WRONG

[wurp]

I have used Hushmail for ages, and it is entirely secure. These users did something foolish - they demanded, then got, then used a "more convenient" version of Hushmail that did the encryption on the server instead of on the client.

Standard Hushmail downloads (& caches) an applet on your computer that encrypts & decrypts your private key with your passphrase. Only the encrypted private key is stored on Hushmail servers, and your email encrypted with the public key. They don't give your decrypted email up to authorities, even with a court order. Because, by design, they CAN'T. The unencrypted private key is never on their server.

The new & improved Hushmail works without you having to have Java support or download an applet. It can only work by decrypting the private key server-side, which means Hushmail has (at least briefly) the information to decrypt all your email. Which means that if they get a court order, they must capture that information and provide your decrypted emails or they go to jail.

Of course, with the applet they could give you a new one that sends them the decrypted key - I'm not sure of the legality of them doing so, even with a court order. However, this is not what happened - all they did was provide information they had on their servers, as required by law.

The only way to be sure of your security is to build a device by hand that does all the decryption & display on the device, inspect all of the code you put on it by hand (preferably compiling using a compiler you wrote in machine language). Oh, and only read email on the device in an opaque faraday cage, naked.

Hushmail gives you precisely as much security as they possibly can, and no more.

Re:Missing from the article

[e9th]

From their FAQ [hushmail.com].

Not as big a deal as you think

[headhot]

Hushmail has 2 options, client side encryption which is done via a java plug in, and server side encryption.

They only had the keys to give away for those people who chose server side encryptions. They don't have the private keys for those who cleint side.

Also, when you choose you method, Hushmail tells you that server side is much less secure. They and anybody else operating in the US would have to turn over the private keys they heald with a court order.

Whats the leason? Key your private keys private. Duh.

Wired article with an interview

[tommyatomic]

Here is a link to a wired article about the same issue. However wired actually bothered to contact the Hushmail and got a response from the CTO Brian Smith. Apparently it is not a clearcut as the OP and TFA suggests. http://blog.wired.com/27bstroke6/2007/11/encrypted-e-mai.html [wired.com]

Server-side Webmail Only!

[pavon]

This only applies if you use their webmail service with server side encryption. They have to have your key in order to encrypt/decrypt server-side, and they have to turn it over to the authorities if they have a valid warrent. It's the law.

If you use their client-side Java applet to do the encryption on your computer - as they strongly recommends that you do - then this is not an issue. Hushmail never see you keys and thus cannot be compelled to hand them over.

Several other sites covered this story earlier in the month all without the crappy sensationalism of slashdot. I first saw it at arstechnica [arstechnica.com], which linked to an interview with the CEO by wired [wired.com].

I'm not usually one to hard on individual slashdot editors, but this is the 4th intentionally misleading troll that zonk has posted today. It is crap like this that caused me to not renew my slashdot subscription so many years.

We new they ratted out a week ago

[Jeremiah Cornelius]

It was on the Cypherpunks list - then picked up at CRYPTOME.

http://cryptome.org/hushmail-rat.htm [cryptome.org]

Re:Last time I looked at hushmail...

[jjohnson]

Hushmail wasn't feeding a tainted applet, they were providing the keys of those who were identified and chose to use the server-side encryption option, rather than the applet.

Re:Missing from the article

[bcrowell]

The Wikipedia article [wikipedia.org] has a bunch of good references. The slashdot summary seems to be incorrect in some of its particulars. If you read the various articles, none of them seem to say that hushmail turned over private keys. They turned over cleartext of messages. Yes, there was a court order (see the more recent wired article). No, hushmail doesn't seem to have lied to their users in general -- the wired article praises them for their honesty -- but they do seem to have put a strong marketing spin on the lack of real security in the JS implementation of their service (as opposed to the original, more secure Java applet, in which the private keys never left the client machine).

Entirely secure?

[Pinky's Brain]

Passphrase encryption is weak shit, also it's trivially easy for them to launch a man in the middle attack ... having a secure and valid keychain is just as important as having a secure private key.

Re:No mater how secure

[Anonymous Coward]

http://www.theregister.co.uk/2007/11/08/hushmail_court_orders/ [theregister.co.uk]

The access was only granted after a court order was served on Hush Communications, the Canadian firm that offers the service.

Hush Communications said it would only accede to requests made in respect to targeted accounts and via court orders filed through Canadian court.

(emphasis mine)

They followed a court order, this story is a non-issue.

Re:By the authorise?

[Kadin2048]

How did this happen? Fuck knows. It isn't supposed to be possible. Hushmail's system was supposedly designed so that they couldn't do this, even if they wanted to. Perhaps one of them was running with an incredibly weak passphrase and hushmail cracked it on behalf of the feds...? All I can think of.

TFA is crappy in this regard, there are better articles which explain what happened in more detail. (Full disclosure: I submitted this Wired article [wired.com] to /. but apparently got beaten.)

Basically, Hushmail has two main modes of operation. One of them is (reasonably) secure, the other is a trainwreck.

In one mode, the 'secure' one, you -- the user -- access their site and download a Java applet to your browser, which contains the OpenPGP encryption engine. You type your emails, they're encrypted on your machine, and sent to the server that way. Hushmail never, at any point in the operation, knows the password to your private key.

Now, because a lot of people use browsers that don't support Java, as of a few years ago, Hushmail came up with an alternative, which doesn't require it. Instead of using a Java applet, it works like a regular HTML/HTTPS webmail system, and all the encryption is done on the server. This means you don't need to be able to run the Java applet on your client machine.

However, and this is the crucial part, when you use this second mode even once, you expose the passphrase to your private key to Hushmail. And that's how they could decrypt all the messages. Once a person used the insecure service, they had basically sold themselves down the river. Hushmail had their passphrase, and from there could decrypt their private key, and from there get at all their messages. (Or at least their incoming messages; I don't know whether Hushmail encrypts outgoing messages to the sender's private key as well as the recipient's.)

From what I can tell, if you used Hushmail and were careful to always use the Java-based service, you wouldn't necessarily be vulnerable to this sort of attack. Since Hushmail wouldn't have your passphrase, the most they could do would be to hand over your encrypted messages and encrypted keys to the Feds, who would then have to try to brute-force your private key. (Meaning, everything would rest on how good a passphrase you used...)

Of course, any time you're depending on a downloaded applet for encryption, you're at the mercy of whomever you're downloading it from ... there's no reason (other than it being more difficult) that Hushmail couldn't be forced to "poison" their Java applet, or backdoor its encryption engine. Unless you're going to examine the code yourself each time, you have no way of really trusting it. But that's a lot more technically difficult than just grabbing the password from the server-side decryption engine, which appears to be what they did.

Re:Alternatives?

[DustyShadow]

GPG + the Thunderbird GPG plugin works perfectly.

Re:Entirely secure?

[Kadin2048]

Passphrase encryption is weak shit, also it's trivially easy for them to launch a man in the middle attack ... having a secure and valid keychain is just as important as having a secure private key.

Huh? The security of "passphrase encryption" depends solely on how hard your password is to guess. Aside from that, it's AES-128, which is perfectly good encryption. If you use a trivially-guessable password, you're sunk. But if you used, say, 19 random ASCII characters, you're at more than 128 bits of randomness. At 50 guesses per second you're still talking about a brute-force time that's 2.15805661 × 10^29 years, based on my quick envelope-back numbers. And if you're at all concerned about the government spying on you, you'd better be using those sorts of passphrases.

(Of course, if you use a single dictionary word or only a handful of ASCII characters, then the brute forcing is trivial, but that's a PEBKAC problem, not a cryptographic one.)

Here's the DEA's depostion

[Anonymous Coward]

Detailed here back in October.
https://www.w4ck1ng.com/board/showthread.php/secure-hushmail-6246.html?p=26237#post26237 [w4ck1ng.com]

Additionally here's the DEA's case
http://static.bakersfield.com/smedia/2007/09/25/15/steroids.source.prod_affiliate.25.pdf [bakersfield.com]

Re:We new they ratted out a week ago

[iminplaya]

And the hits [cryptome.org] just keep on comin'. It would be silly to ever trust those people(Hushmail and others like them) to begin with. But, as it turns out, your hardware's giving you up anyway.

Re:That's been recommended to me, but I can't do i

[DMUTPeregrine]

The following is inexact, but illustrative. FireGPG just calls GPG. You click encrypt, it sends the text to be encrypted to GPG, you enter your passprhase in GPG, and GPG encrypts it and returns it to FireGPG, which puts it into the e-mail in place of the plaintext. Enigmail for Thunderbird works the same way.