yes, NSA as in US's National Security Agency

you wrote "That is not what I hear from NSA cryptologists."
i believe my english was clear. i am 100% confident that no NSA cryptanalyst (a person) would be telling you (a person) or anyone else (other people) their (NSA) capabilities or lack of.

you can contemplate the NSA's abilities as to how they could achieve such (i dont), but i am rather confident that they (the NSA) have the ability to decipher anything if they (the NSA) need to.

Aside from fueling a personal debate between the two of you, what does this discussion have to do with Linux Security, especially as it pertains to the mission of LQ.org?
One of you should know by now that this is the sort of tangent that gets threads closed. The other seems to like making antagonistic posts that border on making things personal and I don't mean just in this thread. It wouldn't surprise me in the least to see this thread take a nice long nap, which would not be fair to the OP and several others who have a vested interest in this topic.

+1 from me.

That said, even though this thread is InfoSec-themed it's just way too non-Linux and therefore I've made an executive decision to move it to General (I will, however, leave a permanent redirect behind in LQSEC). The same rules (no personal attacks, etc.) apply in General, so all thread participants are reminded to keep things civil and on topic.

As far as the general topic of "e-mail security" is concerned (for any future Gentle Readers who get this far ... "hello!") ...

(1) E-mail is routinely transported among mail servers using 'https' encryption, or through VPN (Virtual Private Networking) links, so that the general communications that takes place between the various servers is both encrypted and authenticated. (More about that in a moment...) But the message content, itself, of each message is routinely sent "in the clear." In other words, the mail server can ascertain the content of the message while handling it. This is the capability that Google, e.g. now seeks to exploit for marketing purposes. (But it has always been there.) Furthermore, messages are often stored in unencrypted form, making them vulnerable to disclosure at any time in the future ... hence, "WikiLeaks."

(2) E-mail content can easily be secured through the use of standard facilities that are supported (either directly, or through plug-ins) by every e-mail client program out there. Two of the most commonly used types are:

• S/MIME
• GPG

To the mail-server, and to an "unaware" e-mail client, an encrypted message appears as an empty message with an unreadable attachment.

Encryption technology provides you with two fundamental capabilities: privacy, and message integrity:

• Privacy: Your message is encrypted using strong commercial-grade encryption, using methods that are entirely open and public, and peer-reviewed.
• Message integrity: Also known as "message signing," this ensures that the message has not been forged or tampered with. Encrypted messages are always signed, but messages can be signed without being encrypted.

All of these systems employ public-key infrastructure (PKI), which involves the use of two keys, one that is "private" and one or more that are "public." A message encrypted with one can only be decrypted with the other, and vice-versa. Public keys are commonly stored on keyservers, which let you refer to a key by its signature, or fingerprint.

Let's say that Alice and Bob want to send secure e-mails to one another:

1. They both generate private keys, encrypting them with a password so that if Eve (the quintessential "eavesdropper") steals their laptops, she won't get the keys. Next, they use those private keys to produce private keys which are published to a keyserver.
2. Now, they send digitally signed (but not encrypted) messages to one another: [i]"Alice, my keysig is 12345678." "Thank you, Bob. Mine is 9ABCDEF1." Not trusting that Eve hasn't intercepted that message to substitute a keysig of her own (thus placing herself as the "(wo)man in the middle," Alice and Bob retrieve the keys and use them to check the signatures of the messages they just received. The signature checks out: the messages did come from Alice or Bob, and not Eve.
3. Alice and Bob each store the keys into their e-mail programs and associate them with the appropriate recipients in their address books, so that (if they wish), every message they now send to one another will be digitally signed and encrypted (or, just signed). Eve, and the various mail servers, can handle the messages but cannot discern their content. For Alice and Bob, however, the messages pop open instantly, along with a message that confirms the message's source and integrity. Each of them knows that the messages are private, that they were received exactly as-tendered, and that they actually came from the purported source. It's just as "transparent" and "easy" as using a secure web-site.
4. If at any time a key is compromised, or Alice leaves the company or what-have-you, a key can be repudiated to notify all concerned that henceforth the key should not be honored.

Of course, Alice and Bob's company could employ encryption technologies in their mail servers, instead of or in addition to whatever encryption they may use on their own. Key management can be centralized, through a variety of techniques, and integrated into the centrally managed security practices of the company at large. Since e-mails these days are very important in terms of future litigation, many companies now digitally sign and encrypt every message so that they can argue that a message produced by a litigant is, in fact, a forgery. (Especially sensitive messages, e.g. those used by senior executives or Board members, may employ additional layers of protection.)

You can do these things right now, on any type of computer, tablet or phone, and you can exchange messages freely regardless of system type.

HTH...

sundialsvcs,
wow, that's a completely extraneous non-linux-related post.

can you explain your statement
and as far as pki goes, some implementations do not always use asymmetric (aka public/private) method 100%. they can initiate a key exchange using public/private method and then switch over to symmetric encryption. in this case, even if Eve finds Bob's private key sometime after the conversation starts (and assuming Eve did not capture the initiation of the Alice-Bob conversation), Eve still cannot decipher the Alice-Bob conversation because its not Alice's or Bob's private key that is doing the decryption. i guess this applies more at, as example, the TLS layer than an app overlay/plugin to Outlook email client. email at the app layer can be considered a type of user-to-user one-way communication.

a snipet:
"However, asymmetric algorithms are much slower than symmetric ones. Therefore, in many applications, a combination of both is being used. The asymmetric keys are used for authentication and after this has been successfully done, one or more symmetric keys are generated and exchanged using the asymmetric encryption. This way the advantages of both algorithms can be used. Typical examples of this procedure are the RSA/IDEA combination of PGP2 or the DSA/BLOWFISH used by GnuPG."

What I mean is:

1. Alice and Bob separately generate their own "private/public key pairs." They encrypt their private key with a password so that it is useless if stolen. (The encryption used here is strong, so if they forget their password, they're screwed.)
2. Now, they somehow need to get their public keys available to each other. One way they could do so is by e-mailing the actual public keys in a signed message. (Signing the message requires the private key in order to sign it, but the public key to verify it, so the authenticity of the message can be verified by checking that it matches the public-key which it, itself, contains.) But that's rather cumbersome.
3. So, what Alice and Bob elect to do is to upload their public key to a keyserver, then send each other the "signature" of the key, which is a short token that anyone can use to retrieve the key from that server.
4. When Alice sends a message to Bob, her e-mail program (IIRC...) uses both her private key and Bob's public key to encrypt it, and attaches a digital signature to the encrypted content. Bob decrypts the message using Alice's public key, succeeds in doing so, verifies the signature, and the uses his private key to decipher the message content. Only Bob can succeed in doing this, only for a message that did, in fact, come from Alice. And yet, "It Just Works," as drop-dead easy as using a secure web site.

Of course, there are other ways to do it. Other ways to do every step of the process. All of them thoroughly and completely implemented in every run-of-the-mill e-mail program using completely open, peer-reviewed code and techniques. Such that, once again, "It Just Works."

Eve (and Google...) is totally scroo'd, yet both Alice and Bob are not even inconvenienced.

(Honest. It really does take about 5 minutes total to set the whole thing up, and then, "fuhgeddaboudit.")

---

As far as I know, every PKI-based protocol uses public key technology only during the initial "handshaking" exchanges, where they generate and agree-to a randomly generated key for use in a (faster) asymmetric algorithm such as Blowfish, AES, DES-3 or what-have-you. The key is used only once and then thrown away. (In the case of, for example, VPN or even your favorite wireless router, a new key can be securely re-negotiated on the fly at any time.) The reasons are not only for speed and convenience, but to minimize the amount of traffic that actually uses the PKI encryption. A few PKI-enciphered transfers (Diffie-Hellman Exchanges) to confirm both the choice of cipher and the key, and "that's it for PKI." There are very good, very fast hardware implementations of these conventional ciphers.

In the case of e-mail, again AFAIK, the message begins with a PKI-enciphered block containing a conventional key and cipher-selection, and the remainder is conventionally encrypted ... but don't quote me on that.

---

I still do like what Dr. Phil Zimmerman said, all those years ago, in (especially, the original version of) "Why Do You Need PGP?" Here is a link to a fairly-recent and therefore fairly corporate-sanitized version of that: http://sattlers.org/mickey/tech/priv...hy-u-need.html. He's entirely right. We l-e-g-i-t-i-m-a-t-e-l-y need e-mail encryption for the very same reasons that we need secure web-sites and encryption on our credit-card and ATM machines. It's available, it's reliable, and it's pretty much always been there ... just rarely explored or used, "don't ask me why."

We've so far had only marginal success in persuading our grandmothers to look for the "s" in "https," but e-mails continue for some odd reason to be less guarded than the "snail" mail which we stuff into envelopes. Yet the information content of those e-mails may well be just as security-important as anything which we transfer over the secure pages. The complete absence of security in one channel, virtually defeats the effectiveness of the other. Companies send all kinds of important business communications to their customers, and yet, it never occurs to them to digitally sign those messages!

a password protected key? shouldnt be too difficult to brute it open, especially if using a Linux system. is this post Linux related since i said "using a Linux system"?

if i digressed, i sorry.

Obviously, the key in question probably is a plain phrase of moderate length, and so, yes, this is a vulnerability of the system if the key itself is successfully stolen. At that point, it is merely a last-gasp safeguard to prevent the key from being "casually used." As with every cryptosystem, though, the entire security of the scheme rests upon the requirement that the private key must be "private."

Private keys are routinely encrypted using a well-known strong cipher algorithm, but you are entirely correct that the attack will be against the key and that brute-force or even dictionary attacks may well work against it. (So might waterboarding. Ugh.)

But... it's a damm sight better than sending important stuff ... stuff that legitimately justifies protection against forgery or unintended disclosure or both ... "in the clear, on postcards!" When you have a need to send such information by e-mail, as I have described it is very easy to achieve that.

i suspect the emails in question from wikileaks were bound within your "easy" process. so the question still remains, how did it happen? certainly a good forensics team can figure it out. perhaps a culmination of circumstances, like when you record all the bits from the wire at the edge, and, you also do full backups of the desktops.... so oooops, the encrypted message is now stored on a security device or san location, and oooops, the private key is now somewhere in backup job on tape or disk. many ways to skin this cat, but as i mentioned early on, i am more curious about the how and not so interested in the content.

so, sounds nice to record every bit on the wire and to do full backups, some security programs demand that for things like "can we restore?" and "what was that data stream?", yet these strategies pose their own inherent hard-to-track issues when they come together.

and i forgot, this thread was moved to the General section...

Well, of course, the public version of the story is that some twenty-something soldier in a war zone found that he had access to vast quantities of high-grade diplomatic cables, so he copied them all onto a CD-ROM labeled with the artwork of some rock band and simply spirited the whole thing away.

Do I believe that? Frankly, no. But, it is a plausible cover-story in a situation where there is no "need to know" the gory details. I would be more than a little bit alarmed if we did get more than just the "cover," but even that story is certainly very much a human story. Someone, so we are told, who had an unprecedented and thoroughly unwarranted level of access (how? why?) chose to turn the security of the entire system on its arse. (As any disgruntled employee could do, mind you, if he had access to "the" private keys!)

"The problem is 'wetware,' not 'software' and not 'hardware.'" ('Wetware,' of course, is the stuff that is located in-between two ears.)

Nevertheless, it points out the truth that "security is a process, not a product and certainly not a technology." It also points out that, the bigger and more complicated a security infrastructure becomes, the more difficult it is to ensure adequate security and integrity of that system .. even as more and more people become utterly reliant upon those very things.

Any of our employers run exactly the same kinds of risks, and you can be bloody sure that we are gonna be among the folks looking for jobs if it ever happens.

But, I think, here we really do begin to digress too far from the original premise of the thread, which was "e-mail security," this being a rather small subset of the much larger can of worms that we seem to be poking our fingers into now.

i have my own view of email, which is more inline with what it was designed for in the 1st place, informal exchange of non-sensitive non-confidential information. then pgp/pki came along and suddenly everyone felt the need to use email to transfer highly confidential/sensitive data = fail. the wrong approach leads to bad outcomes.