Slashdot Mirror

https://lists.gnupg.org/piperm...

From https://lists.gnupg.org/piperm... :

> 1. This paper is misnamed.
Indeed
> 2. This attack targets buggy email clients.
Exactly
> 3. The authors made a list of buggy email clients.
Well said.

The MUA should not allow *any* utilization of HTTP when rendering a HTML E-mail. Any form of doing that is a serious mistake. Not only because of what is reported here, but also because that way *that* use of HTTP will allow spammers to identify when you open the E-mail. They use that to know if your E-mail adress is still alive.

Serious MUAs don't do this without user consent. Most HTML components even have a explicit offline mode exactly for that reason. Meaning that they won't automatically go online and fetch things like the src url of an IMG.

Any MUA that does this without user consent is completely and utterly wrong. Especially in a security sensitive context. This is something most MUA developers know about and if not, should know.

By signing his comment he is proving his identity so that you know it is really him.

Then he should PGP sign it.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org/

GuvfvfnsnxrCTCfvtangheriD8DBQE5Pf 40WyoKbftXl6kRAsWJAJ4hj7FzPX8M9MWZ av9u6yjbHXWGKwCfSiKA wTaJ/lfY1ETv3R/uJrtGTbI=
=BDOH
-----END PGP SIGNATURE-----

In the long term, the only real way to deal with this is for people to sign their posts with public-key encryption.

Of course, even then you can only detect tampering, not outright censorship/deletion. The only way to fix that is by moving back to a decentralized system out of the control of any particular person, like Usenet.

So you neither watched the video nor read my comment. Using a chosen cypher text attack, it is possible to trick the cryptographic software into executing known instructions (or known sequences, anything with a recognisable audio signature will do) in a loop. Watch the video again, and pay special attention around the 16:00 mark.
This issue is serious enough to get GnuPG's developers attention; if you don't believe me you can look up CVE-2013-4576. Also, here's a Git commit with a (partial) fix. But you, self-styled cryptography expert, say it's a non-issue so I guess GnuPG's developers don't know what they're doing and should stop wasting their time.

Canada
Germany

These things are notoriously easy to overlook. For example, there have been versions of cryptographic string comparisons that were vulnerable to a compiler optimisation which caused them to bail out at the first difference, which was really hard to see because at first glance the loop looked like it would iterate over all characters.
Here's an article by the authors with nice graphs (why wasn't that in the summary) and here's what a fix looks like. I'll let you judge for yourself whether you'd have realised you had a problem if you had seen the code.

Why does anyone care what is the "biggest" or "most important" open-source project ? That's like treating software in the same way as all that "Strictly Pop Idol Celebrity Chef Globes" TV garbage.

It's either *good* software, or it isn't, and that's the only criterion worth talking about.

Some of the best and most useful open-source software is also the smallest. Some of the most important and critical open-source software is also among the smallest and least 'recognised'. And some of the biggest open-source projects are also the biggest causes for concern.

Are we all hoping for prizes or something ?
Oh dear ... how childish.

There is no way to avoid being the target of the NSA and CIA if they really want to get your data.

This is too tin-foil-hatish. The thing is, they don't really want your data. They don't care about you, you are just one person who has gotten caught in their wide-ranging net. And further: I don't want to stop them from getting the data of people who they're really going after. If they have a genuine reason to pursue someone, sufficient to pass that tiny speedbump of getting a FISA warrant, then that is what they should do.

What I do want to stop them from doing is sweeping up everyone, including people who they don't really care about, in that wide-ranging net. So the objective is not to absolutely secure my emails and instant messages and phone calls, it's to ensure that getting those personal bits of data is sufficiently difficult that they're not going to do it for no reason. More than that: I am a lot less concerned with the NSA and the CIA doing this, who have some marginal level of oversight, than I am concerned with private companies doing this. The above poster "doesn't want to step out of the mainstream phone ecosystem," but what does that mean exactly?

Let's take it as a given that if you're running a closed-source operating system then you have no control over your own privacy. This rules out iPhones, but you can still use an Android phone with a third-party ROM. That's still mainstream, you can still run standard Android apps with that. Of course, you may have to turn to non-Google sources to get them (I get all my Android games from the Humble bundle, DRM-free). But those apps could be doing who-knows-what, so you'll need to firewall them. Not a problem, we're partway there. How about emails, phone calls, text messages, and location data? Well emails and text messages are essentially the same thing, and securing them means the same thing, the only roadblock comes from the lack of widespread adoption. If we want to noticeably increase our privacy, pushing GPG out there as hard as we can as something which everyone should be using is probably the largest difference that we can make. For you and your privacy, at least, getting your friends to use it should be your goal.

Location data: we've stopped our phone from sending back location data directly, but the phone company can still track us, and they do, by following what cell towers we're connecting to. Can we do something about that? Eh... you can get a SIM card with a pay-as-you-go plan which you register for using a fake name (or no name), paid in cash. This will help a little, but location data can never really be anonymous - how many people live in your house and travel to your workplace and back every day? Probably not too many. The same is mostly true for phone calls, they're not very securable. Encrypted VoIP doesn't work (at least in the US) with the way that data plans are structured, and if you're on a pay-as-you-go program then you don't have a data plan anyway. You could not use your cell service for calls, and only make VoIP calls from wifi hotspots, but this largely nulls the benefits of having a cell phone. I don't know what to say here, if you want to both own a cell phone and use it then regulation is really your only hope for privacy. On the plus side, by cutting out the phone manufacturer and and the various app developers there's only a single point of failure where your privacy is compromised: your phone company. If you can address that problem, somehow, then you've achieved a reasonable, but not bulletproof, level of personal privacy.

Have you stepped out of the mainstream phone ecosystem to do this? Partly. A lot of popular apps which rely on a network connection are off limits in this scenario. Facebook, first and foremost, but you're also excluding yourself from all of the other fad-of-the-moment social networking tchotchkes: Instagram, Yik-Yak, SnapChat, etc. It's not mainstream to care about privacy. I don't know what to say about that. If this is a problem for you, you can either give up or get better friends.

Slight bummer, but not too bad: despite what the docs may say, both libksba and npth are hard requirements. If you're able to build this on IRIX without those libraries, then maybe you're using an older GPG version (I'm testing 2.1.1), not sure.

configure will bail out if it cannot find libksba or npth on your system. The autoconf script has no flag to tell it to ignore these; the code explicitly throws error messages and bails if they're missing. Reference for my statements:

libkbsa requirement: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=configure.ac;h=f07f345b470046af4414fd39c22cc149f112134a;hb=refs/heads/STABLE-BRANCH-2-0#l1530
npth requirement: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=configure.ac;h=f07f345b470046af4414fd39c22cc149f112134a;hb=refs/heads/STABLE-BRANCH-2-0#l1539

As for pinentry: apparently that's needed for gpg-agent to "work securely", but if a person doesn't plan on using gpg-agent, I don't see why this is a requirement. configure does support --disable-agent. However, GPG won't build with --disable-agent -- it appears there's a bug in tests/openpgp/Makefile* that "hard-depends" on gpg-agent existing for it to work, so the build process fails near the very end. :/

Slight bummer, but not too bad: despite what the docs may say, both libksba and npth are hard requirements. If you're able to build this on IRIX without those libraries, then maybe you're using an older GPG version (I'm testing 2.1.1), not sure.

configure will bail out if it cannot find libksba or npth on your system. The autoconf script has no flag to tell it to ignore these; the code explicitly throws error messages and bails if they're missing. Reference for my statements:

libkbsa requirement: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=configure.ac;h=f07f345b470046af4414fd39c22cc149f112134a;hb=refs/heads/STABLE-BRANCH-2-0#l1530
npth requirement: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=configure.ac;h=f07f345b470046af4414fd39c22cc149f112134a;hb=refs/heads/STABLE-BRANCH-2-0#l1539

As for pinentry: apparently that's needed for gpg-agent to "work securely", but if a person doesn't plan on using gpg-agent, I don't see why this is a requirement. configure does support --disable-agent. However, GPG won't build with --disable-agent -- it appears there's a bug in tests/openpgp/Makefile* that "hard-depends" on gpg-agent existing for it to work, so the build process fails near the very end. :/

Hmm, now I wonder why too! Part of me thought "maybe GNUTLS is included with GPG" (as in you can alternately have it link to a shared library version, or you can just include it right into GPG statically), but looking at the git repo for GPG I don't see any sign of it.

You can verify my claims of dependencies here:

http://www.freshports.org/security/gnupg/
http://www.freshports.org/security/gnutls/

All that said: it looks like the gnupg port has an option for GNUTLS dependency (it defaults to being enabled). For whatever reason I never noticed this before, probably because it's the first menu option (I often miss this). Before and after disabling GNUTLS, dependency counts:

Before: 30
After: 13

Much more manageable, although I'd still love to get that down smaller if at all possible. Getting rid of libksba would be nice, especially if it's optional. As you can see here, it's labelled a hard dependency (both for compiling and running):

https://svnweb.freebsd.org/ports/head/security/gnupg/Makefile?revision=376062&view=markup

If it's truly optional, I should be able to submit some patches that provide those knobs (for toggling both libksba and libnpth). I still have no idea what the pinentry stuff is about, but it looks to me like it should be optional: https://www.gnupg.org/related_software/pinentry/index.en.html

I think it may be that the FreeBSD port is just "bloated by default" (similar to what I find on a lot of Linux systems), and lacks knobs to slim it down. But hopefully that gives you some idea why I've avoided GPG for a while, and why it's important port/package maintainers not let things get too out of hand.

Looks like I'll have to do some experimenting. And thanks -- this good /. convo has gotten me considering fixing all that and getting a "slim" GPG going for FreeBSD.

I think what a lot of people want to know is whether 7.1a is still reliable and, if not, how many versions back one must go to get a release that's still feature-complete but not questionable in security.

In the meantime, if you need to encrypt a file, you can use GPG and Cryptophane if you want a GUI. Nowhere near as elegant as TC but it should get the job done.

So, how would you prevent them from using email?

You don't.

That'd be an easier solution than getting every email provider and every server in the transportation chain (including local area networks) to never look at the messages.

Let them. http://www.gnupg.org/

-----BEGIN PGP MESSAGE----- Version: GnuPG v1 hQEMAyC/fm5RhHydAQgAiDnkR3bTq3oU+7y/7WMcvH1/5yfgRdYWC+xu23RXTZvu gbDcg5TA7JNhM8ePB78mmayn0TxWNKJX0vao5qMmi7sZuRI2ILIbFIsvUOLx5ORo gIcLxlLiEKeyjAXwBEc2FASiOGsI83h7HBFWep0MjJSjumXXHWPipQj4WcAhZRlS Y6cPPn8z5Hc+eQVlfMpkpTWbtyOGc41UzBe8U5xt7MzNFjGK/ISAhaqSkwZ+UxOV HmjIUo+Ud1/5PPmLHipaOz2AC4CCecz8/HL6ZHBMKM4ejrKqquL6ZWv5rrGJTKc/ 5plI36As/BQ3qjDG4J462QLJGIp4DLkMlGzB+NnwMdKSAceQglrywpqXm/IL/k28 WTWjGyYiEeGhbhNdWsF0GdXplbA5vkgqFdlt7lgseVrgAODNkkd7r1bUSzsPlmfI TdOAv/ykallaG5CILRp/zAXaz8nNXnRiKwfu/D3dUfVqSivbzC/UNnMVPYVMWFjv EQQ0ggU7c8RJAOyvagg3F32HY67RYMNGKxME2peCY+7iNSk= =KfJ3 -----END PGP MESSAGE-----

"Windows XP does not support any encryption that's still considered secure."

Not only is it not secure, it has been EXTREMELY buggy. People have lost their files to Microsoft's encryption bugs. Also, the U.S. government believes it can force executives to do anything it says, and keep that secret from taxpayers.

It is best to use only GPG and TrueCrypt for encryption, or other open source software. Open source software is much more difficult to manipulate.

GnuPG implements RFC4880. See also the OpenPGP alliance. GnuTLS implements SSL, TLS and DTLS. See also OpenSSL and PolarSSL.

Your userland software may or may not link against GnuTLS. It's probably more likely to link against OpenSSL.

It's important to understand the mechanisms involved with software that provides facilities for securing information both locally and in transit to others. It's nearly as important to do a bit of research on said mechanisms before engaging in discussions on them.

It is if you do it right.

There are two distinct random generators available:

        The Continuously Seeded Pseudo Random Number Generator (CSPRNG), which is based on the classic GnuPG derived big pool implementation. Implemented in random/random-csprng.c and used by default.
        A FIPS approved ANSI X9.31 PRNG using AES with a 128 bit key. Implemented in random/random-fips.c and used if Libgcrypt is in FIPS mode.

http://www.gnupg.org/documentation/manuals/gcrypt/Random_002dNumber-Subsystem-Architecture.html#Random_002dNumber-Subsystem-Architecture

No, they have been telling the truth. They store a picture until the recipient opens it. They have to, how else could they send the picture to the recipient?

Gee, maybe they could encrypt it and just fucking send it?

Oh, right. Even something "simple" like PGP is beyond users at large. Shameful.

Simple and expected processes like this need to be made truly dead simple and nearly automatic. Instead, there are a ton of different formats for keys depending on which the usage and you need to understand a significant amount about what's going on under the covers to do even these kinds of simple actions.

Incidentally, here's the answer to the question. It's anything but clear, but likely to be clearer than any answer you get here.

From the site linked:

Dear God, please don't use Pond for anything real yet. I've hammered out nearly 20K lines of code that have never been reviewed. There are no binaries here for a good reason. Unless you're looking to experiment you should go use something that actually works.

Just FYI. Good encryption is not easy to do correctly. Join the project and help him out, but heed his warning if you need something that has been vetted and is thought to be actually secure.

Like GnuPG?

Encryption Key Management IS a commodity. What in hell are these yahoos talking about?

And this goes especially true for Samba - as GPL3 is worded, you are not allowed to use-it to serve protected files, or, if you do, it's fair game to anyone to steal your data as this whole "domain authentication" stuff is Digital Rights Management. So the lawyers say, and management will listen to the lawyers and not the engineers.

This is utter FUD, no competent legal team can come to that conlcusion, unless they're so computer illeterate they are unable to tell the difference between source code versus data or signals/transactions which might be handled by a running instance of that source code.

For example, please point to me where in the GPLv3 I do not have the freedom to write my own DRM implementation (the next iTunes? eBook reader?) and then release the source under GPLv3.

My last (indirect) experience with our legal team and funding open source development was long and arduous, taking many months but not being able protect data (the entire point of the majority of our work) was never in question.

I mean, GNU would be breaking their own GPG, for crying out loud.

I never understood why people would upload a copy of a file to the Internet, manually/purposefully delete their only local copy, and proceed to complain that they no longer have a local copy.
Why on earth would you delete it from your computer?!?

There is NO excuse for this problem.

This is FAR from a new issue with "the cloud" either.
People used to do the exact same thing with web-hosting.
They would upload their website to a web server somewhere, delete their only copy, then when the hosting company went under, had the server crash, disk failure, whatever... the user would proceed to blame the ISP for the fact the user themselves deleted their only copy from their own computer. wtf?

The standard rule for backups is, if you can't bother to have two copies (One on your computer, one backed up on another device) then it clearly wasn't important enough to warrant bitching about when you lose it. That rule implied ONE copy was not enough... Why on earth would people think ZERO copies is any better?

Hard drives die. It's a fact of life. The "if" is always a yes, only the "when" is variable.
That fact alone is reason enough to already have more than one copy in your own home on your own equipment.
A provider disappearing like this should be nothing worse than a minor inconvenience in finding somewhere else to host it and upload another copy, then chase down URLs pointing there and update them. Sure, that can be a bit of work and is quite annoying, but it should be nothing on the scale of data loss.

Storage is cheap.
Encryption is easy (Thanks to the efforts of projects like PGP, GPG, and TrueCrypt)
BackupPC is free, runs on Linux which is free, and can be as simple as an old Pentium-2 desktop sitting unused in your basement that you toss a couple extra hard drives in.
You set it up once and it does everything for you! It daily grabs copies of other computers, all automated, all by itself. It can backup Linux, Windows, and even OSX via the network. You can feed it DHCP logs to watch for less frequently connected machines like laptops. It de-duplicates to save disk space, and can email you if and when a problem crops up. I only check mine twice or so a year just to make sure things are running (never had a problem yet) and as it deletes older backups only when needed to make room for new ones, with de-duplication I can go grab a file from any date between now and three years ago, at any stage of editing (Well, in 3 day increments for my servers.. but it's all configurable, and should be set based on the importance of the data!)
On ubuntu and debian based systems, it is a single apt-get install away. Likely just as easy on any other distro with package management.
Any true computer geek can slap together such a system with zero cost and spending less than an afternoon. Anyone else can do so for minimal cost and perhaps a day of work.

Apple has ridiculously easy backup software (Time Machine?), and Windows has the advantage of most of the software out there being written for it, so the odds that there are less than five different software packages to do this exact same thing is next to impossible.

Hell, even for non-geeks, most people have that one guy or gal in the family who supports everyones computers. Just ask them! They will likely be ecstatic to help, possibly will donate spare parts from their collection (Or find you the best prices on parts if not) - and be content in the fact they won't have to tell you things like "Sorry, your hard drive has the click-o-death, I can't recover anything from it." which no one likes to need to say.

This is worth repeating: There is NO excuse for this problem.

Personally, if it's important, I have a bare minimum of four copies.
One for actually using, on my system drive.
One that got a

I was thinking of something simpler such as "echo MyPassword69! slashdot.org|md5sum" and then "aaa53a64cbb02f01d79e6aa05f0027ba" using that as my password since many sites will take 32-character long passwords or they will truncate for you. More generalized than PasswordMaker and easier to access but no alpha-num+symbol translation and only (32) 0-9af characters but that should be random enough, or you can do sha1sum instead for a little longer hash string.

DO NOT DO THIS. I don't mean this disrespectfully, but you don't know what you're doing. That's OK! People not named "Bruce" generally suck at secure algorithms. Crypto is hard and has unexpected implications until you're much more knowledgeable on the subject than you (or I) currently are. For example, suppose that hypothetical site helpfully truncates your password to 8 chars. By storing only 8 hex digits, you've reduced your password's keyspace to just 32 bits. If you used an algorithm with base64 encoding instead, you'd get the same complexity in only 5.3 chars.

Despite what you claim, you're really much better off using a secure storage app that generates truly random passwords for you and stores them in a securely encrypted file. In another post here I mention that I use 1Password, but really any reputable app will get you the same protections. Your algorithm is a "security by obscurity" system; if someone knows your algorithm, gaining your master password gives them full access to every account you have. Contrast with a password locker where you can change your master password before the attacker gets access to the secret store, and in the worst case scenario provides you with a list of accounts you need to change.

I haven't used PasswordMaker but I'd apply the same criticisms to them. If an attacker knows that you use PasswordMaker, they can narrow down the search space based on the very few things you can vary:

• URL (the attacker will have this)
• character set (dropdown gives you 6 choices)
• which of nine hash algorithms was used (actually 13 - the FAQ is outdated)
• modifier (algorithmically, part of your password)
• username (attacker will have this or can likely guess it easily)
• password length (let's say, likely to be between 8 and 20 chars, so 13 options)
• password prefix (stupid idea that reduces your password's complexity)
• password suffix (stupid idea that reduces your password's complexity)
• which of nine l33t-speak levels was used
• when l33t-speak was applied (total of 28 options: 9 levels each at three different "Use l33t" times, plus "not at all")

My comments about the modifier being part of your password? Basically you're concatenating those strings together to create a longer password in some manner. There's not really a difference, and that's assuming you actually use the modifier.

So, back to our attack scenario where a hacker has your master password, username, and a URL they want to visit: disregarding the prefix and suffix options, they have 6 * 13 * 13 * 28 = 28,392 possible output passwords to test. That should keep them busy for at least a minute or two. Oh, and when you've found out that your password is compromised? Hope you remember every website you've ever used PasswordMaker on!

Seriously, please don't do this stuff. I'd much rather see you using pwgen to create truly random passwords and then using something like GnuPG to store them all in a strongly-encrypted file.

> How good of a code audit does GPG undergo? IIRC, GPG id
> largely funded by the German government.

As good as you'd like to make your audit:

ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.18.tar.bz2

Surely you jest? Getting amanda to encrypt your backups. Is just a matter of reading some howto files on amanda's website. And, just peeking over at bacula's website, I can see that they have a similar sort of setup. I don't use bacula, but I'm sure it is a matter of following the directions just like with amanda. It is not clear how anyone can consider encrypting backup tapes as a difficult process. For that matter, with TrueCrypt, OpenSSL, GnuPG, FreeBSD's geli, and linux's dm-crypt encryption in general has become easy and accessible. Add to that the hardware acceleration built into most new systems or just pure computational power of modern processors and organizations are remiss for not using encryption at nearly every turn. If you don't, you should lose your job.

Try here, or here, or here, or here.

Every time this topic comes up, people suggest these guys. There used to be PGP, I think it's commercial now, but there's GNU PGP.

I think any manner of Google searches will tell you how to do this. It's something that's been around for quite some time in various incarnations.

I say that if you're going to encrypt, encrypt everything or at least as much as possible. If the authorities want to come after me with a five dollar wrench so be it, anything that important wouldn't be in my email anyway.

And email encryption is not easy? Install Thunderbird, GnuPG and Enigmail. You can even set rules to encrypt emails to specific people by default. I've gotten my family, close friends and coworkers using Enigmail and they love it. Even better, and my ulterior motive from the start, is that I now have a good-sized web of trust.

Just a wild guess, but I presume that if that's the case, you end up making angry posts to slashdot about how all of your friends and coworkers are too stupid to use software which is complicated to install and complicated to use?

If this is the way people are going to get the ability to encrypt/sign emails, then yeah, they're not going to use it.

If this is the list of features "customers" are expected to make sense of, then yeah, they're not going to use it.

GPG is great software, but it's not exactly trivial to set up properly & use, and it doesn't appear as if the developers make much of an effort to make it easy to set up properly and use.

Just a wild guess, but I presume that if that's the case, you end up making angry posts to slashdot about how all of your friends and coworkers are too stupid to use software which is complicated to install and complicated to use?

If this is the way people are going to get the ability to encrypt/sign emails, then yeah, they're not going to use it.

If this is the list of features "customers" are expected to make sense of, then yeah, they're not going to use it.

GPG is great software, but it's not exactly trivial to set up properly & use, and it doesn't appear as if the developers make much of an effort to make it easy to set up properly and use.

s/Internet/web/g

Private communications have been possible on the Internet for a long time now: http://www.gnupg.org/

(Not that anyone can deal with the inconvenience of that sort of thing...)

The Government's Strategic Defence and Security Review, which revealed: "We will introduce a programme to preserve the ability of the security, intelligence and law enforcement agencies to obtain communication data and to intercept communications within the appropriate legal framework.

Yes, it is _just_ a proposal, do you want it to come about? So... time to ramp up development of https-everywhere, ensure that you use GNU Privacy guard for all EMail, bit locker on your drives, and dust off your NT box to run https-everywhere!

> What about running your own mail server? I always wanted to do that anyway.

By all means...go for it. It gives you full control. Of course, you also need to set it up and maintain it to some extent (unless you have somebody do it for you) and, if you lease a server somewhere, pay accordingly. It's not that much though. Ditto for DNS.

> The only problem then is of course that SMTP traffic is unencrypted. Or is it?

The definite answer is: it depends :-)
You can set the MTA up to negotiate the connection settings with the mail server on the other side when sending a mail. Including whether to use TLS (preferred) or SSL.

> It would make sense if that also had an encrypted as well as an unencrypted version.

That's exactly how it works:
Attempt TLS by default...if the other side doesn't support it then go plain-text SMTP.

> But even then I can't force people who mail me to use the encrypted version.

If by people you mean the mail server (usually the users have no idea or influence over that part unless they run their own) then you are correct...you are relying on the coolness of the server admin to have it set up like yourself and happily use TLS if possible.

Am not sure though what you're trying to achieve:
If you want real e-mail security, you must use actual e-mail encryption. Such as offered by GPG - http://www.gnupg.org/
Even then, the other person needs to also use it. That tends to be a chicken and egg issue. If you're talking family, girlfriend etc. you might simply install it for them and show them how to use it. That part even less technical people can deal with...the setup not so much. You can still run your own mail server with TLS-support anyway, but see it as icing on the cake, not real security because of above mentioned issues. But every bit helps. :-)

http://gnupg.org/

GPG is also reliable, reputable, fast, free, open source, and works on Windows, Mac OS X, and Linux.

What we need is a list of things PGP can do that the free, open source GPG can't do. Is there anything? If GPG can do everything PGP can do, then there is no reason to pay a lot of money for a closed-source alternative.

For example, here is the GPG manual: web-of-trust.

It would be difficult to trust closed-source encryption software, especially from a company that so many people who have commented here have said they have found unreliable.

GPG is also reliable, reputable, fast, free, open source, and works on Windows, Mac OS X, and Linux.

What we need is a list of things PGP can do that the free, open source GPG can't do. Is there anything? If GPG can do everything PGP can do, then there is no reason to pay a lot of money for a closed-source alternative.

For example, here is the GPG manual: web-of-trust.

It would be difficult to trust closed-source encryption software, especially from a company that so many people who have commented here have said they have found unreliable.

GnuPG (gpg) is the underlying tools and libraries. As locklin states parralel to me, there are plenty of GUIs out there.

Have a look but realize that there are even more out there, these are just the hilights.

that no matter how hard they try to 'break' someones ability to do something, those someones will quickly circumvent that 'break' in the system, if they wish to. Makes me flash back to the days of the T-shirts with the DeCSS code written right upon it, and all the controversy about them. Also the tshirts that printed with the PGP (probably also gpg)code that were considered munitions by the US government. Makes me chuckle, makes me sad. It's a mad world, to quote Tears for Fears (though I think I adore Jules version more). There are plenty of other examples, from recording a videotape to another, using analog methods (which to me seems one of the easiest and first methods to break most digital methods of 'breakage', though the quality does suffer, in many peoples opinions.)
I really don't forsee a day when people will quite hacking the 'breaks' in systems. Isn't that what they are there for in the first place? Why not spend all those research dollars into the improvement of the platform itself? Or finding new exciting artists? Etc...

Maybe next time they will know to use http://www.gnupg.org/

Which is fairly dangerous in the UK, since it's a crime to not reveal your encryption keys when presented with a warrant. Should you lose your keys you can go to jail for innocently saying that you can't decrypt the message!

Maybe next time they will know to use http://www.gnupg.org/

Windows 95 is a
32-bit shell for a
16-bit extension to an
8-bit operating system designed for a
4-bit microprocessor by a
2-bit company that can't stand
one bit of competition.

(stolen from http://lists.gnupg.org/pipermail/gnupg-users/2003-May/018396.html)

Also, "two-bit" means "(1) cheap; gaudy; tawdry; or (2) Mediocre, inferior, or insignificant".

(stolen from http://www.yourdictionary.com/two-bit. Try to find the definition in-between all the ads.)

http://www.gnupg.org/

PGP or GPG are crypto implementations that run on the client, gpg is all free, PGP can cost money, but has a lot of desktop integration features for the platforms that support it. I also use a certificate on my mailserver, which is self signed, since they only people who need to trust it are inside my house, and I trust me.

The SSL cert is only really in place to protect my credentials during IMAP/S and SMTP+SSL. Using certificates doesn't really help in the transmission of mail between hosts, since that will happen in the clear anyway. That's where PGP/GPG protects your mail content.

But the the best encryption is free and the text of the law doesn't even exclude it. If someone wanted this bill to make money for their friend, they sure screwed up.

It's very easy to create a system where it's possible for anybody to verify that the sender is in possession of a given key but not to gain that key themselves.

SSL does in fact stop a DNS-redirect based impostor, if you assume that the keys that the clients trusts are indeed trustworthy. The problem in all of the above systems is three-fold: a.) making sure the cipher is secure (AFAIK, nobody has an efficient way to break RSA yet), b.) making sure the implementation is sound (hence Debian OpenSSL snafu earlier this year), and c.) knowing which keys to trust.

In a system where all keys are registered by a central, trusted registrar (like easypass), (c) is dealt with. Sadly, a lot of RFID authentication schemes fail tests (a) and (b). Attacks on OpenSSL (Debian debacle aside) often concentrate on (c), because your browser has to trust some other authority to sign off on the validity of a key, and often those authorities are not very rigorous and can be tricked.

My understanding is that this is the big issue about mathematical attacks: They depend on the encryption method. If you merely encrypt things more than once, using two or more different encryption methods, the chances there will ever be a successful mathematical attack are very, very small.

I have an enormous amount of respect for Bruce Schneier, but his writing is designed to get him business, not to give easy answers to big problems.

I recommend GNU Privacy Guard.

At work we send secure student data over FTP to be scored and retrieve the scored data in the same manner. Instead of a secure channel we encrypt the data using each others' public keys. It's fairly easy to set up and use. http://www.gnupg.org/

http://www.gnupg.org/ - The GNU Privacy Guard

http://getfiregpg.org/ - FireGPG, "encrypt, decrypt, sign or verify the signature of text in any web page using GnuPG" (untested by me).
https://addons.mozilla.org/en-US/firefox/addon/3424 - another Firefox extension, also untested.
https://addons.mozilla.org/en-US/firefox/addon/3208 - another one that may be useful (untested).

http://www.gpg4win.org/ - something for MS Windows

Remember folks, even if you aren't in the UK, this still affects you! If you communicate with people in the UK, if you have email based in the UK (I have a Yahoo.co.uk email address, in addition to my 50 other email addresses...), etc. ...

It is as simple as installing Firefox, installing GNUPG, and installing that extension that lets you encrypt text fields when you are emailing...

And don't forget TrueCrypt http://truecrypt.org/ though it isn't strictly relevant in this case, it is always relevant.