Posted
by
CmdrTaco
on Monday June 04, 2007 @10:26AM
from the can-you-spot-the-secret-message-in-this-dept-line dept.

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 keep them on their toes by acting completely normal, having them looking for steganography.

Well, have you found the hidden message in the parent post yet?

Sorry, there is no hidden message.1. You noted that you use encryption when acting normal.2. However, you were posting on/. which has been established (quite conclusively) as abnormal behavior.3. Since you were not "acting completely normal", it is obvious that you were not employing any encryption scheme.4.:)5. Profit!

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

Here is why you don't do that: Because why wouldn't a terrorist leave corroborating evidence lying around proving it was all just a test to psych the government out, so they can be let go? While they are interviewing your "third parties" you are being beaten half to death, electrocuted, water boarded, and raped. IF, and its a huge, colossally massive if, they ever EVER believe you that you were just kidding about bombing NY with a dirty bomb, they will testify that you cannot be released since after your brutal torture you probably are now a terrorist even through you weren't before. Plus you can't exactly be let go since the torture techniques are classified information and you might leak them. Just like Jose Padilla. First he HAD a dirty bomb, then he was building one, then he was thinking about it, then he knew somebody who was thinking about it, then nothing...but they have ruled he can NEVER face trial, and can NEVER be released. Their reasoning is their "interrogation techniques" have irreversibly damaged him mentally, so he's too unstable to stand trial. But these "interrogation techniques" are highly classified matters of national security, so he can never ever be allowed to talk to anybody in case he tells them what they did to him (especially not a lawyer). And that would be you. Now remember, he _WAS_ a citizen, and there was no evidence against him. Still tortured and given a life sentence without the possibility of a trial. What fucking chance do you think you have if there IS evidence against you? Well you might have white skin so you just may have some kind of chance.

How is this different from the gaim-encryption plugin?
The gaim-encryption plugin provides encryption and authentication, but not deniability or perfect forward secrecy. If an attacker or a virus gets access to your machine, all of your past gaim-encryption conversations are retroactively compromised. Further, since all of the messages are digitally signed, there is difficult-to-deny proof that you said what you did: not what we want for a supposedly private conversation!

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 messag

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 in traditional crypto/signature schemes, having a provable relation between a specific message and specific sender is a desired attribute. While there are certainly situations where you would like to verify the identity of the person to which you are chatting (wife/girlfriend/boss/etc), it appears that is not one of the wanted 'features' of this encryption protocol. Forward and backward secrecy would certainly be something most would consider useful, however."

Well, you want to make sure it IS from the person you think it is, but, that doesn't mean you have to know who the person IS in real life.

It would be cool if these email plugins would help make it easy to register and use the nym [iusmentis.com] servers. This way you could set up an email address on each end. PGP sigs can be used, but, there is plausible denyability as to who really is at each end of the email.

Of course if you're really worried about tracability, then set up a nym account to send out on, but, on return messages...just have it post encrypted to one of many USENET groups. You then really have a disconnect 'cause there's no good way to monitor around the world who gets what messages of USENET.

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.)

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.

This is what standards are for. We need a standard for IM encryption, possibly as part of a larger encryption framework. I have no problem advocating a standard, which I think is a lot better idea than advocating a given program/library.

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.

OTR is licensed as GPL/LGPL. As such, I'm not sure a lot of major software makers will be all that keen about implementing it. Take a look at iChat or Yahoo Messenger. They're not going to open source their application just to add an encryption format that is still pret

OTR is licensed as GPL/LGPL. As such, I'm not sure a lot of major software makers will be all that keen about implementing it. Take a look at iChat or Yahoo Messenger. They're not going to open source their application just to add an encryption format that is still pretty rare and where there is not a lot of demand.

Which is why they use the LGPL, which allows usage without forcing openness.

Which is why they use the LGPL, which allows usage without forcing openness.

I'm familiar with the LGPL license, but while it is great for "tivoization" type uses, it is usually a no-no for software inclusion. Most corporate lawyers I know don't want employees including LGPL code in distributed software, because the cost of making sure it is compliant and making sure the developers understand what they do and don't have to resubmit, and the cost of documenting the linkages, is too onerous, especially for this small of a chunk of code. It is easier to simply write their own code th

Most corporate lawyers I know don't want employees including LGPL code in distributed software, because the cost of making sure it is compliant and making sure the developers understand what they do and don't have to resubmit, and the cost of documenting the linkages, is too onerous, especially for this small of a chunk of code.

Is it really this hard to just keep all of the LGPL code in its own files, and only add code to them that needs to be there?

Is it really this hard to just keep all of the LGPL code in its own files, and only add code to them that needs to be there?

For a lot of companies, I think so. We manage a fair number of LGPL and GPL software packages here. Then again, we ship servers preloaded with it, just like Tivo does. The LGPL requires not only changes to the LGPL library, but also all the linkable object files used to glue it to your code base. This means you have to track it all and educate users. Here, most of the developers have a good handle on OSS licensing and we already have to track GPL software we also include on our boxes, making it not a huge

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"

Interesting question, because datamining email to target ads is exactly what Google said they wanted to do when gmail got started. Since encrypted mail would make this impossible, I wonder if they'll take actions to stop the use of encryption tools with gmail. On the other hand, as it stands, unless they offer such tools themselves, I don't see most users encrypting their gmail anytime soon. So the losses may be acceptable to Google.

Gmail supports retrieval of mail via POP3 for free. So there's nothing to stop someone from using GPG and similar support already included in or available for a wide variety of e-mail clients such as Outlook, Thunderbird, Evolution, Eudora, etc.

So... you are saying that the NSA has the ability and desire to break every ElGamel 2048-bit length encrypted message it captures with Echelon? I've seen too much of government from the inside to think that any agency operates as well as the NSA FUD would have us believe. Especially when you realize it is far easier and cheaper to make your enemies believe you have super powers than it is to actually develop those super powers, completely in-house with no outside knowledge or help.

They use programs to determine who is using high level encryption. Afterwards, they plant a keylogger with burst transmitter in your keyboard. By doing it that way, they don't have to spend anytime decrypting. You can any program or level of encryption you want and it won't do any good since you are compromised at a lower level.

You need tin foil to make the hats - mind control rays pass right through aluminum!!! Don't you ever wonder why everyone still talks about "tin foil" even though all you can buy on store shelves nowadays is aluminum? It's because They don't want you to notice the switch!!!

Survival equipment.

Sure, if you want a compass that's got the New World Order's tracking devices already installed. I make my own survival equipment.

I read all my gmail accounts using POP/SMTP in a real mail program, so I don't see any advertising anyway. Won't make a difference. Except if they try to figure out trends by actually keeping statistics on the content of e-mails going through their system.Hmm, maybe that's the reason I need to start using encryption.That, and to annoy the NSA of course./RS 'M-x spook'

This extension seems very cool, and I plan to try it out when I get home. When I first read the summary I thought to myself, "A firefox extension and gmail, how much simpler could it get!" But, unfortunately this is not point & click encryption. It requires an additional external program (GnuPG) to function. Even this small, relatively trivial step is too much for beginning to average computer users. Encrypted email is great and all, but I can only send it to other people with encryption-enabled email clients.

1) Geeks really want such encryption to take off.2) It shouldn't be that hard to implement.3) Governments really, really, really don't want this to happen. (i.e. that everyone can efforlessly encrypt this well)

AFAICT, it doesn't exist. At least not outside of corporate environments. There are lots of companies that have their encryption set up so that it's transparent to non-technical employees, but it's a lot of work for the people who actually make it run. Lotus Notes, for instance, will do public-key cryptography, using company-wide keyservers -- although it's a proprietary algorithm, or was last time I checked. Once you have the infrastructure in place, the users don't have to think much about it, besides clicking 'encrypt and sign' on the emails they want secured.

I've also heard that within Apple, they use Apple Mail with S/MIME to great effect... but if you're just a regular user, getting that feature working is a real PITA. (Though admittedly, most of the trouble is because of the certificate authorities.)

I think the problem with the free encryption tools is that they're still very much a 'hacker's product,' being designed by fairly advanced users, for other advanced users -- or at least, for users who don't have a problem installing extra software in order to communicate securely. This, IMO, is a mistake; in order for an encryption system to be useful, it has to be widely used. And that means getting it into the hands of people who might not even think, in advance, that they want it. There are lots of people who aren't going to go out and download/install encryption software, but if the feature was there, and working, all the time, they'd probably find themselves clicking the 'Encrypt' button quite a bit.

There's no real reason why encryption can't be built in. It's just that it tends to get viewed as a peripheral, rather than core, feature, in everything except some corporate packages. However, I think that if it was incorporated more widely, it would quickly become a core feature; but getting over that 'chicken and egg' hump is hard.

The last I heard, the US Gov will have access to X bits of the Lotus Notes keys (some of the keys bits are taken and encrypted to the US Gov key), so that they get a significant help to cracking stuff if they need to. Something like it's 40bit crypto for the US Gov, and 64 bit crypto for everyone else (other than the intended recipients).

It's not just that not all commonly used products include encryption, it's that there's no standard infrastructure for key exchange.In a standard GPG encryption scheme, each user creates a private key and a public key. Anyone who wishes to send them a message must request their public key in order to do the encryption, and then the private key is used to do the decryption. (Sometimes to save computation time the message is actually encrypted with a symmetrical key, and then the key--which is shorter than th

Encrypted email is great and all, but I can only send it to other people with encryption-enabled email clients.

Where is the it-just-works email encrytion for dummies?

Well, there's one problem. You'd have to have a consistent standard.

Also, how would you handle key exchange? For "it-just-works", you'd likely not even ask the user if they want to get a particular senders public key, which makes a man in the middle attack very feasable ( because no one has ever spoofed email headers... ).

in my travels i can across this javascript-based RSA cryptography demo [stanford.edu]. if you want to use it, hit Generate, then send the first two numbers (Modulus and Public Exponent) to whoever you want to talk to. they have to do the same. you enter their modulus and exponent into another window to encrypt.

the code is BSD-licensed. i've been meaning to write a larger javascript app to hold your keys and everyone elses' in a single window, and with a click of a button create a block of XML that you can copy+paste t

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

One thing that is CERTAINLY true is that most email users have zero interest in maintaining a web of trust. That means PGP is right out.S/MIME relies on people trusting third party certificate authorities and acquiring the certificates of other in order to send encrypted messages. This actually COULD work if the major email vendors agree to cooperate on some sort of certificate distribution method, and provide an easy way for people to get keypairs in the first place. This is at least possible.

One thing that is CERTAINLY true is that most email users have zero interest in maintaining a web of trust. That means PGP is right out.

You don't really need the web of trust for PGP. You can use it without any of that quite easily. You grab the keys from a keyserver, and then if you're paranoid or worried about MITM attacks, you verify the fingerprint with the recipient through a side-channel (voice phone, whatever). It's just like PGPfone.

There is just no way that could reach widespread adoption. Only a PKI model, backed by major mail providers, could have a chance. My mom will never understand fingerprinting. She could understand "This message is signed by John Doe!*" showing up in her mail client, where the asterisk means, "according to Verisign, who is trusted by Gmail."

s/mime is great and simple. This is what geeks should be pushing onto their friends not gpg. Most mail clients support it. The worst of it is that you need to make a cert. That requires some hand holding, but it sure beats endless hand-holding with gpg or old pgp installs.

This works with any textarea, by the way, not just GMail. Not sure why the summary doesn't mention that.

-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1

This works with any textarea, by the way, not just GMail. Not sure why the summary doesn't mention that.-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.6 (GNU/Linux)Comment: http://firegpg.tuxfamily.org/

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.

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.

Yes I believe that is the case in the UK [bbc.co.uk] (I am too lazy to find out if this is actual law now, to be honest I'm a bit confused if it is or not)

However, I don't have a problem with this. We use GPG encryption for all our corporate emails, some of our staff are working in countries where it is quite likely that somebody at an ISP could be bribed

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.

You don't have to be target of an investigation to be searched, what matters is that relevant evidence may be in your possession.

In the american system, the presumption of innocence sets a high standard for conviction in a criminal trial - a standard of civility and caution that ought to be maintained through every stage of the criminal process.

Perhaps, but that's only one use of PGP/GPG. You can also send entirely non-encrypted messages that have a digital signature from your key to authenticate that the message came from you. You can also use it to get a digital signature of files you're distributing. More secure than MD5 (etc, etc) hashing (in theory, at least, given only you have the private key to generate the signature), should prove that you created and approve the file (so you don't have unscrupulous people attacking your server and hid

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.

It's not the case; there was a bill proposed which would have done that, but civil rights activists got it altered so they can only compel you to give up your encryption keys if they can proove you have them.

Secondly, I wanted to suggest that perhaps this is a reason not to use PGP, because PGP encrypted in

Thanks, most informative!The --show-session-key option looks handy - but in a way, this illustrates the second point I was getting at, which is that information encrypted with GPG can be recovered as long as any recipient can be forced to give up his private key (or run --show-session-key). This is something that any GPG user should bear in mind, particularly as GPG ciphertext will sit in email boxes for many years. You're trusting the recipient to keep his key secret forever: you trust him now and in the f

I suggest that people should only use cryptosystems where the session keys are destroyed immediately after use

For realtime communication (e.g. phones), that makes sense, but when does "after use" happen with email? Whatever your answer, many people will disagree. There's no right time to stop remembering the session key.

I highly doubt that, every time you mail something in an envelope, you consciously think about the possibility of the mail falling out if you didn't seal it. Also, with most envelopes, you can simply tuck the flap in and it will be secure enough that the contents won't fall out.

Besides encryption, GPG also allows you to sign messages, ensuring that the message is indeed from you, and hasn't been modified after you've signed it. In the Ubuntu Community, this is important for a) verifying messages from developers are real, b) verifying that uploaded packages were created by trusted developers, c) verifying signatures (such as signing the code of conduct).

While FireGPG is useful, it's not so useful for signing messages; gmail auto-wordwraps messages after you send them, and FireGPG doesn't take that into account. Therefore, unless you wordwrap it yourself, gmail's going to add line breaks, and your signature will be invalid. When I need to sign messages, I either word wrap myself so that gmail doesn't, or send it through Thunderbird using Enigmail.

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.

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

You are forgetting about authentication. Email is trivial to spoof. If you *always* sign your messages, then when some asshat, say, decides to send an explicitly detailed nastygram to your boss from 'you', it is easy to prove otherwise...

Not to be too nit-picky, but usually when talking about encryption, the parties are Alice and Bob (the two legitimate users), and Eve (the person who is either 'evil' or 'eavesdropping'). I don't think I've ever heard 'Cathy' used as one of the parties...

Hey, your girlfriend called. She said she couldn't read the garbled message you sent. However, I passed on your "wanna...tonight" message to her and she said "yes" but I don't think your name came up. So...if you don't mind, I'd like to get out a little early tonight...