Encrypt and Sign Gmail messages with FireGPG

Linux.com (Same owners as Slashdot) has a story up about FireGPG and says "Gmail may be an excellent Web-based email application, but there is no easy way to use it with privacy tools like GnuPG. The FireGPG extension for Firefox is designed to solve this problem. It integrates nicely into Gmail's interface and allows you...
Encrypt and sign Gmail messages with FireGPG

I wouldn't think google would like this

[kentmartin]

I thought their business model worked on the idea that they could datamine all your email and (among other things) offer you targeted email based on the content therein... this'll screw with that idea...

"BUY jjhHDJEy6786ERLKLXhdfeprERIOUPewoenOIhgshgrgeyrew now for a low price on Ebay.co.uk"

Does not this break GMAIL's business model?

[mi]

I thought, their ability to automatically parse the messages — so as to show users the relevant advertisements, was the reason, I am getting an unlimited mailbox with nice interface for free.

If all/most of my messages are encrypted, how will they know, what to peddle to me? Can't do much on Subjects alone... Or can they?

Say 'no' to gaim-encryption, use OTR

[Kadin2048]

OTR is miles better than the gaim-encryption/pidgin-encrypt. Honestly, I don't understand why they won't just kill it and move to OTR for good; it's a fundamentally better security model for something transient like instant messages.

Particularly since having two mutually-incompatible encryption packages is a pretty crummy state of affairs; it just means that the few users who do use encryption, are going to be fragmented between incompatible systems.

OTR probably has the greatest market penetration of any IM-encryption system, outside of corporate clients (Sametime, I think, uses encryption by default, although I don't think it's end-to-end, only client-server, because there they want the ability to intercept on the server), because it's built into the fairly popular OS X Adium [adiumx.com] client. So there's already quite a few users out there who have software that supports it. If only some of the other IM clients would start building it in by default, rather than making it an optional addon, I think it would quickly gain traction as a de facto standard. (And that would be a good thing, since it's a good system and open source.)

Only Gmail?

[Rob T Firefly]

While the site says only Gmail is supported, could this be made to work with other web apps? It'd be neat to have something like this for webmail on my own domains, forum-based messages, and so on.

Won't AJAX textboxes kill this?

[biftek]

I haven't used gmail that much, but I was under the impression that it saved drafts of what's in the composition textbox at intervals.

That data would be all cleartext wouldn't it? Seems a tad risky to me.

Re:GMail S/MIME plugin for firefox

[Kadin2048]

This is not painless and easy, and IMHO S/MIME is alot nicer implemented than PGP signatures.

S/MIME is oftentimes more slickly implemented, because it tends to get more use on the corporate side, but I think that it's unsuited for wide use because of its reliance on centralized certificate authorities. The whole certificate-based infrastructure isn't anything that most people want to have to deal with.

For 90% of all communications, what people want is an email (or IM, or whatever) version of PGPfone -- they just want the data secured in transit, with the actual user authentication done via some side-channel (calling them up on the phone and exchanging key fingerprints, etc.).

If people have to get and install certificates, they're not going to use the system.

Re:Nerds with something to hide

[XrayCharlie]

I use FireGPG along with It's All Text! [mozilla.org] plugin, which I can edit a textfield with an external editor such as Vim. Vim handles wordwrap for me. The only problem I have is that Gmail automatically makes links for URLs or email addresses, which breaks the signature.

Re:Nerds with something to hide

[Anonymous Coward]

So if I'll sell you envelopes that stay closed by some mechanism that is easily, unnoticeably opened and re-closed at a price that is substantially lower than that of the adhesive-using ones, will you buy and use them?

Re:The Fascination with Encryption

[UbuntuDupe]

Actually, I heard that one old prank was to send postcards back and forth between major cities with simple, but cryptic sounding statements. For example:

"The birds rise at sundown. Where are the minnows?"
"All is well, north of the river."

Supposedly, the government would see them and get suspicious, thinking they were coded messages.

I've also wondered: why doesn't someone test whether the government is reading emails? For example, have some guys plot an imaginary terrorist attack via unencrypted email and see if they get questioned. Leave physical corroborating evidence in case they follow up. (Make sure to document with several third parties first, so you can prove it's an experiment.)

PGP/GPG - inherent legal problem?

[Cheesey]

I understand that in some countries, you are legally compelled to provide the keys to access files encrypted with PGP, GPG, etc. if the authorities demand access. If you refuse to produce a working key, or claim to be unable to do so, a judge is able to assume that you are deliberately hiding something.

Firstly, I wondered if anyone could confirm this? I have heard that it is the case for Britain at least, although I don't see how it can possibly be legally compatible with the presumption of innocence.

Secondly, I wanted to suggest that perhaps this is a reason not to use PGP, because PGP encrypted information can always be decrypted using the recipient's key - even many years after the message was originally sent. So law enforcement officers will be able to get old PGP-encrypted documents from your email account (probably even if you delete them, thanks to backup tapes). They'll then be able to force you to decrypt them, and if you don't, they can assume you are witholding the key because the files are full of terrorist plans or whatever.

I suggest that people should only use cryptosystems where the session keys are destroyed immediately after use, such as SSH and (possibly) some secure instant messaging services. Even if law enforcement officers use a wiretap to record everything sent by you over an SSH connection, and then seize your computers, they still can't recover the plaintext because the session keys have already been deleted. It's impossible for you, the suspect, to produce the keys, which should help your legal defense. Here's a way to chat securely by SSH [vanemery.com].. if you need to transfer files, you can use SFTP.

Re:And for the chat

[Kjella]

No. You're thinking of `downloading` - one of the main things any source-forge style system is supposed to make difficult. Under NO circumstances should you offer a link which you click once to receive and executable. You MUST have to register with your email address and agree to terms and conditions and then try and find the executable - not the source, resource files, the forum etc - but the program you just signed up for the sole reason of downloading.

Well, that qualifies for a -1, troll since I've never signed up to download anything from SF.

Deniability is handy for denying that what the pigs have found on your computer is an encrypted file. It's supposed to look like any piece of random data used by encryption systems.

And this one I can't tell is clueless or trolling again. What this is about is that the other plugin doesn't negotiate a throw-away session key, so that the session can't be replayed later. You're thinking of steganography - hiding encrypted data. However, in this case there's no reason to store anything, unless you're storing an encrypted log. There's two separate issues here: If you are a party to the conversation, you want non-deniability about what the other party said. But both want deniability to third parties on what was said or not, unless they choose to keep a record of it.

Re:And for the chat

[fwr]

It's called nonrepudiation, and yes it is usually a desired if not required feature of public key encryption. There have been some recent issues with in-the-clear messages that are signed with a private key in that the hash algorithm used (MD5 and/or SHA-128) have particular known weaknesses. If you sign a message/file like a PDF that can contain comments that are usually not shown in a viewer then someone could possible add in comments with the appropriate "garbage" text that would make a modified message produce the same hash key. However, for encrypted messages this has not been shown to be as big of a deal, that I'm aware of, because you'd not only have to decrypt the message in order to edit it you'd also have to be able to re-encrypt the message with the necessary added junk bytes required in order to produce the same hash.

In any case, NIST sent out a notice and request for comments for the development and/or selection of a new, more secure, hash. You'll probably see it out in products in 5 years or so, as most hardware-acceleration gear out there is specifically designed for MD5/SHA-128. Just as a lot of people had to replace crypto hardware when AES was developled as the replacement of DES, you will likely see a similar upgrade required in the future for a new hash algorithm.

For normal encryption protocols to work correctly nonrepudiation is required. Otherwise it would be easy to launch man-in-the-middle attacks. This particular protocol, from what I gather from other posts, has things confused. They seem to desire the ability to identify the other end, and supposedly encrypt the sessions, yet have no mechanism for nonrepudiation. So the only comparison I could make would be sending a "signed" message in the clear without the critical hash of the plaintext message. So you'd send the message and attach your signature but anyone could modify the message en-route.

I think people are confusing the encryption protocol with the application program. I'd hazard to guess that there is nonrepudiation in the actual encryption protocol being used. However, it sounds like the application program stores logs of the unencrypted messages in plaintext on the hard drive. The messages are, at that point, out of the scope of an encryption protocol. How messages are handled may be part of an encryption standard, but not really a single encryption protocol. If unencrypted messages are stored in plaintext someone could steal or break into your computer and put all kinds of incriminating material in your logs. Since they are not signed there is no way you could repudiate the contents, which you would want to be able to do if they were faked. I could also edit the stored messages myself and make it look like you sent me anything I desired, even something that would incriminate you and shift the blame from me, which you would certainly want to repudiate.

For a proper encryption standard, something which encompasses more than just the transmission of messages between two endpoints and may address other issues such as message storage, the messages should be stored in encrypted format, and/or at least including the sender's original hash signed with their private key. This way someone that sent you a message would not be able to deny the contents of that message, which you would want if say you were sent a threatening message or something similar.

For those thinking of privacy and dissidents, etc, nonrepudiation would also be something that people would want. Say you were part of a secret organization that was working to overthrow some fictional evil government. If you had a mole in your group you wouldn't want them to be able to deny that they sent particular messages to their contact. Or, you wouldn't want them to deny that they received particular messages, saying that you just planted them there yourself because you are the mole.

Re:Nerds with something to hide

[Tarquin Sidebottom]

Unfortunately wrap, htmlization and all that marlaky is a general problem when it comes to signing via web interfaces, be it gmail or some generic php webforum. I came across the same issue when I made a few comments in relation to the now stillborn EnigWeb [sourceforge.net] project.

Perhaps it's time for a GPG-wide standard for 'verification-lite', aimed at web-traffic. The idea being to trade a small amount of security for method robustness. Rather than signing a bit-for-bit copy, sign a version where anything other than the main visible characters are ignored. New lines, carriage returns, tabs, multiple consecutive spaces, rare symbols that might by mangled by php scripts: all are ignored. So rather singing:

The cat sat on
the mat.

, you sign instead: 'Thecatsatonthemat.'.

Obviously, greater minds than mine need to sit down and assess the pros, cons and risks (more freedom to try and create collisions), but it strikes me as an idea worth considering.