Encrypt and Sign Gmail messages with FireGPG 206
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
Encrypt and sign Gmail messages with FireGPG
The Fascination with Encryption (Score:5, Funny)
Keeps the snoops on their toes.
Re:The Fascination with Encryption (Score:5, Funny)
I keep them on their toes by acting completely normal, having them looking for steganography.
Re:The Fascination with Encryption (Score:5, Funny)
Re:The Fascination with Encryption (Score:4, Funny)
1. You noted that you use encryption when acting normal.
2. However, you were posting on
3. Since you were not "acting completely normal", it is obvious that you were not employing any encryption scheme.
4.
5. Profit!
Re:The Fascination with Encryption (Score:3, Funny)
Re:The Fascination with Encryption (Score:3, Interesting)
"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.)
Re:The Fascination with Encryption (Score:4, Insightful)
Re:The Fascination with Encryption (Score:5, Insightful)
Re:The Fascination with Encryption (Score:3, Insightful)
Re:The Fascination with Encryption (Score:4, Funny)
Re:The Fascination with Encryption (Score:2)
Re:The Fascination with Encryption (Score:5, Funny)
And for the chat (Score:5, Informative)
Re:And for the chat (Score:5, Insightful)
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!
Re:And for the chat (Score:3, Interesting)
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:And for the chat (Score:3, Interesting)
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 (Score:4, Insightful)
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.
Say 'no' to gaim-encryption, use OTR (Score:5, Interesting)
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.)
Re:Say 'no' to gaim-encryption, use OTR (Score:3, Insightful)
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.
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. This is one of those rare instances where a BSD licensed implementation would be a whole lot more likely to solidify the de-facto standard. Realistically, I doubt that the major players are going to go open source for their clients, and as such I doubt there will be adoption of OTR unless it is submitted as a real, well documented standard and/or a BSD reference implementation is made available. We're a lot more likely to see Microsoft or AOL take over this space with a proprietary encryption scheme, which will be reverse engineered and pseudo-supported on other platforms/clients simply because people will need to communicate with the majority.
Re:Say 'no' to gaim-encryption, use OTR (Score:2)
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.
Re:Say 'no' to gaim-encryption, use OTR (Score:2)
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 that does things differently and since there is not a documented standard, that will probably not be compliant with OTR's.
This is why basic building blocks like the TCP stack are often BSD licensed. It is a lot more motivation to adopt a standard, when you can incorporate a free, reference implementation without maintaining all the tracking for the licensing the LGPL brings with it. I just don't see Microsoft pulling LGPL code into default Windows applications so that Messenger, or whatever it called now, can interoperate with then tiny number of OTR users. I can see them grabbing some BSD code and embedding it for a quick bullet point.
Re:Say 'no' to gaim-encryption, use OTR (Score:2)
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?
Re:Say 'no' to gaim-encryption, use OTR (Score:2)
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 deal to manage LGPL code. Other places, however, that do not already manage LGPL and/or GPL libraries have a lot more risk and pain involved. They might do it to get something vital, but there is not really all that much about OTR that makes it better than something that could be written in house or contracted elsewhere. The only real advantages are time to market (not much demand yet so not a big motivator), cost (cost of tracking over a few years may well exceed cost of contracting this), and compatibility with the existing OTR user base, which is pretty tiny compared to the IM market. If any major player (AOL, MS, Yahoo, Google, or Apple were to standardize on something else and pre-install it, they would automatically have a bigger chunk of the encrypted IM market than OTR does).
I wouldn't think google would like this (Score:5, Interesting)
"BUY jjhHDJEy6786ERLKLXhdfeprERIOUPewoenOIhgshgrgeyrew now for a low price on Ebay.co.uk"
Re:I wouldn't think google would like this (Score:5, Funny)
Re:I wouldn't think google would like this (Score:3)
Re:I wouldn't think google would like this (Score:4, Informative)
Re:I wouldn't think google would like this (Score:5, Insightful)
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.
Silly Rabbit (Score:3, Insightful)
Altered for slashdot (Score:5, Funny)
Version: GNUPG v0.4.0 (GNU/Linux)
Comment: Wonderful
ewurnfi3u834j9few4jf9oewfqvi7y&H*&HAwr8hw78er7hfw
wf8943f89jw3r8j9fesajaejro5gvl;rhyklyfp[ult0h43jg
fnw98efj89324rtuerjgeiorgtjerilgtjireogniregunren
werj
-----END PGP MESSAGE-----
I have nothing more to add
Re:Altered for slashdot (Score:5, Funny)
Re:Altered for slashdot (Score:2, Funny)
Does not this break GMAIL's business model? (Score:4, Interesting)
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?
Re:Does not this break GMAIL's business model? (Score:5, Funny)
Re:Does not this break GMAIL's business model? (Score:2, Funny)
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.
Wellbutrin.
You see how well my encryption has kept me under your radar? Don't you feel foolish trying to sell me anti-depressants, when I'm in my MANIC phase right now!?! Ha ha ha!
Re:Does not this break GMAIL's business model? (Score:2)
Hmm, maybe that's the reason I need to start using encryption.
That, and to annoy the NSA of course.
Point & Click Encryption? (Score:4, Insightful)
Where is the it-just-works email encrytion for dummies?
Re:Point & Click Encryption? (Score:3, Funny)
Re:Point & Click Encryption? (Score:2)
Re:Point & Click Encryption? (Score:2)
I don't know, but it seems really
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)
Is 3) or 1) working against 2)?
Re:Point & Click Encryption? (Score:5, Insightful)
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
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.
Re:Point & Click Encryption? (Score:2)
Re:Point & Click Encryption? (Score:3, Insightful)
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 the message--is encrypted with the public key. But that's mainly an implementation detail, and the need for key exchange still stands.)
However, if I'm reading my mail in Thunderbird on a personal SMTP server hosted on my own DSL connection, and I want to send an encrypted email to you at your GMail address, I first need to request your public key for encryption. As it stands, there is no standard method for my server, when I click the "encrypt" button, to submit a request to Google's server and then receive in response a public key for encryption. Currently only integrated solutions, such as Microsoft Exchange or Lotus, where all the email is being routed through a single server that can hand out keys, can have this approach.
It would require either a call-and-response system, where Server A could send a specially formatted email to Server B which would then send another specially formated email back to Server A containing the public key, or a registry lookup system, where each user would register their public key with a public keyserver which would act like a DNS, translating email addresses into public keys for systems that request them. Both types of systems have the requirement that everyone you send email to be able to use the same system. If I'm sending an email from my home SMTP server to your GMail account, either my SMTP server has to be able to communicate with GMail in a meaningful way, or both servers (mine and GMail's) need to be set up to talk to the same system of keyservers. I imagine a workable system would include both, just like TCP/IP and DNS.
Only when such a system is used by the majority of email systems will encryption ever be universally available.
Re:Point & Click Encryption? (Score:2)
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... ).
Where would one get a public key from a particular sender, anyhow? From the sender? A central repository? If the sender, how do you trust them if you've never met them? If a central repository you've still got the trust issue, but also who'd manage it?
For the "it just works" crowd, you'd also have to explain why encryption is necessary. The people I've tried that with usually respond with something like "I'm not a secret agent! LOLLZ" or some such.
Re:Point & Click Encryption? (Score:2)
S/MIME, which is built in to Thunderbird, Apple Mail, Outlook, and every other major e-mail client. You just need to get yourself a certificate and install it.
http://www.dartmouth.edu/~pkilab/pages/Using_SMIMRe:Point & Click Encryption? (Score:2)
I think it's the same as all true forms of message validation: delivery in person.
* grin *
javascript RSA cryptography demo (Score:2)
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 to a file to store the keys, but i havent got around to it.
Ehm... (Score:2)
GMail S/MIME plugin for firefox (Score:4, Informative)
This is not painless and easy, and IMHO S/MIME is alot nicer implemented than PGP signatures.
Re:GMail S/MIME plugin for firefox (Score:3, Interesting)
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:GMail S/MIME plugin for firefox (Score:2)
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.
Something with WEAK authentication, like PGPfone, is STILL going to require extra work on the end user's part, but does not depend on large companies cooperating. It's nice, but I just can't see this happening because, instead, it relies on an enormous group of non-technical people cooperating.
Email encryption will come eventually, but it will probably be in the form of S/MIME and be pushed by the likes of Google and Yahoo. There is no other way that is even remotely feasible.
Re:GMail S/MIME plugin for firefox (Score:2)
Re:GMail S/MIME plugin for firefox (Score:2)
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.
Unfortunately, PGP and the 'web of trust' are often conflated, but you can have webs of trust in a S/MIME model (Thawte's free certificates are like this), and you can do centralized authentication in PGP.
Honestly, I think that fans of PGP need to stop pushing the WoT model, because it's too cumbersome for normal users, who really only want about the same level of security offered by landline phones. It's available, for people who want to participate in it, but it's not an essential feature for most users.
Re:GMail S/MIME plugin for firefox (Score:2)
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."
Re:GMail S/MIME plugin for firefox (Score:2)
But it works wonderfully to sign short messages, but nothing more complicated.
It took quite sometime for the S/MIME extension to mature enough to be usable, so this may work in a couple of months..
Re:GMail S/MIME plugin for firefox (Score:2)
Re:GMail S/MIME plugin for firefox (Score:2)
Does that plugin actually support signatures yet? Encryption is great and all, but has way less useful security properties without signatures.
Only Gmail? (Score:3, Interesting)
Works with any textarea, by the way (Score:5, Informative)
Won't AJAX textboxes kill this? (Score:5, Interesting)
That data would be all cleartext wouldn't it? Seems a tad risky to me.
Re:Won't AJAX textboxes kill this? (Score:2)
Re:Won't AJAX textboxes kill this? (Score:3, Informative)
I can't help it.. (Score:2)
Useless if GMail accessed only via POP3 (Score:2, Insightful)
In fact, FireGPG actually benefits Google and its advertising goals, since it only functions via Firefox and Google's ad-infested Web interface.
Re:Useless if GMail accessed only via POP3 (Score:2)
PGP/GPG - inherent legal problem? (Score:3, Interesting)
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:PGP/GPG - inherent legal problem? (Score:2)
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 to pass on our private emails to our competitors.
Yes, we are paranoid.
But, we have encountered situations where it seems everything we did was known by our competitors (Big US corporation).
It does give us the freedom to discuss business and financial matters confidentially and ensure that information such as bank account details is authenticated.
If the police want to see that information, we'll gladly trust them and hand it over. Then immediately revoke the keys and issue new ones
Re:PGP/GPG - inherent legal problem? (Score:2)
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.
But to obtain a search warrant all the police need to show is a reasonable belief that a crime has been committed and that the search they propose is an appropriate response.
Re:PGP/GPG - inherent legal problem? (Score:2)
To be honest, I've never used PGP/GPG to encrypt outgoing messages. I mean, I understand the use some subset of people may have for shared-key encryption like that, but for far more people, it's more usable as a signing mechanism.
Re:PGP/GPG - inherent legal problem? (Score:2, Informative)
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 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).
That's what gpg --show-session-key is for. If you get subpoena'd, you can give them just the session keys for the specific emails they want, and they'll be able to read them but not any other messages you received for the same public/private keypair.
Thanks, most informative! (Score:2)
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 future. Whereas if your ciphertext becomes useless shortly after it is sent, you only have to trust the recipient in the present.
Re:PGP/GPG - inherent legal problem? (Score:2)
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.
What's All the Hubub? (Score:2, Informative)
Why can't Google do this? (Score:2)
Re:Nerds with something to hide (Score:5, Funny)
Nope. It's secret terrorist plots to overthrow the tyrannical American Government!
Oh, wait! I wasn't supposed to say that, was I?
Re:Nerds with something to hide (Score:5, Funny)
Re:Nerds with something to hide (Score:5, Insightful)
Re:Nerds with something to hide (Score:3, Insightful)
I'm more concerned about the letter (or worse, a check) falling out.
Re:Nerds with something to hide (Score:2, Insightful)
Re:Nerds with something to hide (Score:5, Insightful)
I use security envelopes to obscure the contents of my mail. You probably would want to use that as an analogy instead.
Re:Nerds with something to hide (Score:5, Funny)
Re:Nerds with something to hide (Score:2)
Here's a tip for you. Use a piece of tape to hold the pages of the letter shut. Write the address on the back, and add a stamp. You just saved the cost of an envelope.
Re:Nerds with something to hide (Score:2)
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.
Re:Nerds with something to hide (Score:5, Informative)
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.
Re:Nerds with something to hide (Score:3, Interesting)
Re:Nerds with something to hide (Score:3, Interesting)
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.
Re:Nerds with something to hide (Score:5, Informative)
Or maybe from your secret lover, etc. You get the picture.
Re:Nerds with something to hide (Score:5, Insightful)
Re:Nerds with something to hide (Score:5, Funny)
Re:Nerds with something to hide (Score:3, Informative)
Re:Nerds with something to hide (Score:3, Informative)
Re:Nerds with something to hide (Score:3, Funny)
Re:Nerds with something to hide (Score:3, Insightful)
As always, XKCD is so relevent, it's not even funny, except it is, and so are chair dancing on the heads of penguins.
Re:Nerds with something to hide (Score:5, Funny)
Your girlfriend called... (Score:5, Funny)
Re:Nerds with something to hide (Score:3, Funny)
Re:Nerds with something to hide (Score:3, Insightful)
Re:Nerds with something to hide (Score:3, Funny)
taxes (Score:2)
Re:Or you can use an actual mail client (Score:5, Informative)