Slashdot Mirror

This really, really, REALLY doesn't matter. The cat is out of the bag. If Australians won't rise up against their tyrannous government, they can have SKUs with all of our protections ripped out. But there will be many dead men turning over in their graves before the US succumbs to such a law. We've seen this encroachment before, and it has never passed.

GPG started life as PGPs lesser cousin. And PGP has at least one OSS version available as well. So you're actually using PGP.

"I think if you want encryption to work, what you need is not a clever little article that explains it, nor is it a startup company that stores public keys in a novel way. First, you need standards. Open, free, and universally supported"

Somebody should invent Open PGP!

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.

Well, AES-256 is readily available but I guess only the Feds and the accused know what was used.

Anything that is worth it's salt (pun intended) will cause grief for any person trying to decrypt the data. There's lots of tools out there, just go look at a few.

I would recommend looking at TrueCrypt http://www.truecrypt.org/ and OpenPGP http://www.openpgp.org/ first.

Yes, I know there's lots of tools out there, that's why I asked the question. I've looked at a few, but I don't know which ones are so difficult to crack that the FBI was willing to try to get the judge to compel the defendant to reveal the key and risk having the judge rule that the defendant is within his rights to not reveal the decryption key. It seems like if the FBI secretly had the ability to break the encryption, they would have done that instead of risking that the judge would rule in the favor of the defendant. Though I guess it's possible that they *did* break the encryption and know what's there, but were looking for a way to make the evidence known without revealing that they cracked it.

Well, AES-256 is readily available but I guess only the Feds and the accused know what was used.

Anything that is worth it's salt (pun intended) will cause grief for any person trying to decrypt the data. There's lots of tools out there, just go look at a few.

I would recommend looking at TrueCrypt http://www.truecrypt.org/ and OpenPGP http://www.openpgp.org/ first.

It takes an unreasonably large amount of technical prowess to actually eradicate all of Google's tendrils.

DuckDuckGo, NoScript, and OpenPGP?

What am I missing? A robots.txt file?

PGP got taken over by McAfee / Network Associates years ago. Look here: http://www.openpgp.org/members/nai.shtml

They took it over and killed it.

Well, it was already dead. Although we loved PGP at the time because it was encryption when no one was allowed to have it, the product itself was very badly designed. The user interface was hostile (Trust? Invalid? Implicit? WTF?), and although they provided E-mail plugs for Eudora and Outlook they never supplied one for Mozilla/Thunderbird. You had to copy paste through the clipboard which was a huge pain.

Then there were compatability problems over RSA keys (dropped thanks to those ratbags Rivest, Shamir and Adleman) and the now-thankfully-dead IDEA (why didn't they choose an unencumbered algorithm?) so you couldn't guarantee someone sent PGP mail could actually read it. You couldn't even be sure you could look at your own e-mail with an older version.

Add all this together, and little wonder it tanked.

PGP never got with the times and gave us a nice fluid GUI. Instead their GUI mimiced the CLI. The McAfee / Network Associates take over made it worse; they made parts of payware (so suddenly PGPDisk you were using was no longer available unless you paid CASH) and stopped releasing the source. Phil (creator of PGP) complained they were neglecting it, but McAfee didn't care.

PGP with its confusing interface remained sadly stuck in the world of DOS. Sadly GNU PgP (GPG) copied the same cryptic command line interface, so never improved. There are plug-ins for Thunderbird now, but they're not smoothly integrated and the horse has long bolted.

My friends and I who were all PGP mad gave up and now exchange e-mail plaintext via Gmail. As Scott McNeally said, "You have no privacy. Get over it." He was wrong, but I guess we did.

... the Chinese, Russians, Americans, etc come looking for me because I use http://www.openpgp.org/, http://www.truecrypt.org/, and http://www.openvpn.net/.

-terrified Canadian

A real solution would be end to end authentication and encryption. I wonder why none of the supreme innovators have thought of this yet. But then again the NoSuchAgency wouldn't be able to monitor our inbox or product vendors spam our inboxs.

The point of OpenID is to be dead simple, short-comings and all, so it's actually adopted.

The above is taken from a discussion of vulnerabilities. The problem with this lowest common denominator approach is that it's horribly broken. OpenID is currently no better than just giving the URL of your blog.

The number one problem is the complete lack of integrity checking. Everything in OpenID seems to be perfectly happy to let their requests be modified in transit. I think the problem with this are pretty damn obvious: nothing can be trusted. Fortunately, fixing this is pretty simple: use TLS. In today's shared hosting environment, you probably want to require support for server name indication.

Another brilliant idea: transmit the key that you'll use for signing later in plaintext.

Yes, you can ask for DH-SHA1 encryption and get back a plaintext secret. If this troubles you, don't use the handle and instead use dumb mode with that server. (and if somebody sniffed the plaintext secret, it won't matter, since you'll never accept queries using that assoc_handle). If the server can't do DH, it's probably limited in some way, but using dumb mode is still safe, if not a little slower.

I believe "limited in some way" means "completely insecure." "Dumb mode" is not safe because there's no key associated with the server, so there's no way to ensure you're talking to the same one or that someone isn't tampering.

I also don't see much point in using a symmetric key for speed and security when you're just encrypting a short string. It's so tiny that both improvements are similarly small.

Perhaps the biggest problem with OpenID is it's reliance on sending a user to another page to login. It's just too easy to spoof a page and fool most people. Even better, you can open a window using Javascript and hide the location bar. Even if you normally use TLS, most people probably won't notice if it's missing or the certificate is different. Also, most sites (including LiveJournal) include a completely insecure assurance that you're secure. For example, LiveJournal says "LiveJournal Secure Site "

A simpler and more secure alternativeThe only way to fix this is (gasp) get users to carry their own keys. If you stored your key in a bookmarklet or extension, you could sign something with it. This is completely feasible because Javascript cryptography implementation is done. You could submit your public key with the signed comment. If you wanted to associate yourself with a URL, all you need to do is link to a page with the public key. If the same public key can be used for the signature.. That's right, no special identity server is needed. The public key could be submitted directly or it can be linked to. It might be a pain to write out the entire URL to the key, so perhaps autodiscovery-from-HTML should be supported:
<link rel="openpgp.key" href="http://www.livejournal.com/pubkey.bml?user=a trustheotaku" />
Note that no TLS is needed. The signature is secure in and of itself. If you want to support all the fanciness (e.g. revocation) of OpenPGP (spec), then you just need the

You're kidding, right?

If you like the Google interface (my main reason for using it), and you don't want Googlebot "reading your email", you don't have to let it.

Agreed - I think OpenPGP is simpler to implement and use (due to the lack of a need for a centralized "certificate authority"), but S/Mime is what always gets built in[1]. Either way, between OpenPGP and S/Mime there are already two documented standards with one or more genuinely open implementations available, so I don't imagine this new one is going to go very far.

[1] - Although I like the idea of blaming it on a proprietary software conspiracy, who prefers to encourage the "pay someone else to deal with things for you because you just can't handle it" model [e.g. a Certificate Authority], I think the reason S/Mime gets in is because it seems to use the same algorithms and methods that SSL does in the first place. Since any real email client has to support SSL for secure communication with servers anyway, extending that code just a bit to add S/Mime is a lot less work that adding support for OpenPGP would be. I'm just hoping Enigmail and other OpenPGP[2] interfaces for email clients become ubiquitous and trivial to install and use. If they do, I can imagine OpenPGP taking back the role of "preferred mail signing and encryption standard"

[2] - In case anyone doesn't already know - "OpenPGP" is the name of the standard. "PGP" is the company that currently owns the original implementation of that standard and still provides semi-proprietary[3] software for it. "GnuPG" and others (including, obviously, PGP Corporations products) are implementations of the OpenPGP standard (and therefore interoperate with each other just fine).

[3] - they are a "software license fee" company and the software isn't properly "open source". However, they DO apparently publish their source code for peer-review (just not for redistribution).

Let's say you receive an OpenPGP (PGP, GPG) encrypted email which requires your public key to decrypt. Once your key expires you're going to switch to a new key. Even if you're good at keeping old legacy expired keys around, eventually the message will become unreadable (forgot passphrase etc.) I don't know where I'm going with this mind you

OpenPGP is a standard implemented by a few programs including PGP (non-free), and GnuPG (aka GPG) (Free). GnuPG support is either integrated into or supported via plugins on Kmail, Eudora, Mutt, Outlook, and many other clients. See http://www.gnupg.org/(en)/related_software/fronten ds.html for more details. There are a couple of Mac related links there. About the last two, GPG's privacy lies in the key, and thus you wouldn't want anyone else to be able to use your key -- they could sign messages as you otherwise. A hackish way to use GPG with these would be to manually use gpg to sign (and possibly encrypt a message) on the commandline, and then pasting them in. Someone could write client side code for dealing with webmail (Browser plugins that allow one to replace the current contents of a text input field with a signed message, but they could easily be security holes if not written correctly).

Who would issue the certificates?
Would it be a central authority (VeriSign?)?
Would a certificate holder need to provide extensive personal info to the issuer or pay a periodic fee to the issuer in order for the certificate to remain valid?

How are certificates better than signing with PGP/GPG/OpenPGP?
PGP signing is an easy, effective way of identifying a sender that relys on an established web of trust rather than a commercial agreement. It allows for persons to remain anonymous if they need to while providing information on who it is that has signed the senders key as being authentic. The same technology also provides for very effective encryption (using the recipients public key)that can be automated to ensure the maximum level of available privacy without being unneccessarily difficult to implement.

How is this better than rejecting emails that do not originate at a mailserver that has a mx reccord in dns?
Emails can be sent through your providers server using smtp_auth, smtp_after_pop, etc. from anywhere on the internet. This would not prevent you from sending when you are on an unfamiliar network such as when you are traveling. Rejected emails could be bounced back to the sender explation of why it was rejected and asking the sender to contact their provider or system administrator if they have any questions.

I get very wary of certificate based solutions, as I tend to prefer decentralized systems over central authorities. The recent behavior of VeriSign is a good sign of what can happen to any company that is permitted to set itself up as an "official authority", and I cannot help but believe that there will be certificate issuers that abuse their position. Also, I do not like the idea of requiring registration with centralized databases of users personal information, when it is entirely unneccessary for sender identification.

I don't know why more stuff doesn't use S/MIME early on. PGP/GPG and the others are not really standard and don't work off-the-shelf with a lot of big software (Mozilla and Outlook being two of them).

Have you looked at the OpenPGP standard? It's an IETF standard (RFC 2440) - a Proposed Standard. I have no idea whether Mozilla or Outlook support it, but I think mutt does.

Given the end-to-end argument is it much more important that we start to use OpenPGP, even if some one discovers our userid/password the encrypted email will be only readable by the addressee, and no one else.

This IMHO also put a end to the discusion that WEP is weak. Why shouldn't be? If it was strong it would be even more expensive, and regulated, and it would have been overkill for most applications. If a application needs encryption, like email, the application should provide encryption and not the lower protocols.

Why there are still mail clients with out openpgp surport I really do not understand, email is as privat as a postcard... Is nobody telling users that?

Just set up a procmail filter to block any mail that isn't signed or encrypted with PGP.

Of course, you'd miss out on a lot of legitimate mail.

but since they are modular, we could also use them for traditional pgp style encryption, no? instead of symmetric keys, you could use a public key.

SSL and PGP (or preferrably the newer OpenPGP) standard both use a hybrid scheme which uses both asymmetric and symmetric encryption algorithms.

If you mean could elliptic curves schemes (ECDLP, ECDSA, ECDH) be used in OpenPGP as well as SSL/TLS; then yes as long as it was added to the OpenPGP standards which I don't think includes ECC yet but has spaces reserved for future ECC use.

While doing this, I discovered that quite a few companies do support OpenPGP but it's our job to continue this effort in 2 ways:

1. Educating others about it
2. Participating in development efforts (and this also means bug reporting, translation and documentation, stuff that even I can do!)

For a sample of companies supporting OpenPGP "movement" as Salon calls it, see:
http://www.openpgp.org/members/

It's a shame that the Salon article totally ignored to mention at least two of the easier (although not easiest) ways to use OpenPGP: Enigmail (for Mozilla/Netscape) and WinPT (for Windows/clipboard-based), among others.

They also fail to mention that GnuPG really is the command line application/libraries, and then there's a layer of front end or integration to other products. A thourough visit of GnuPG.org will reveal this.

Finally, for the webmail-oriented crowd, there's also Hush Mail (which is, BTW, a company that PZ joined after leaving NAI). What's so technically difficult about using this ?

While doing this, I discovered that quite a few companies do support OpenPGP but it's our job to continue this effort in 2 ways:

1. Educating others about it
2. Participating in development efforts (and this also means bug reporting, translation and documentation, stuff that even I can do!)

For a sample of companies supporting OpenPGP "movement" as Salon calls it, see:
http://www.openpgp.org/members/

It's a shame that the Salon article totally ignored to mention at least two of the easier (although not easiest) ways to use OpenPGP: Enigmail (for Mozilla/Netscape) and WinPT (for Windows/clipboard-based), among others.

They also fail to mention that GnuPG really is the command line application/libraries, and then there's a layer of front end or integration to other products. A thourough visit of GnuPG.org will reveal this.

Finally, for the webmail-oriented crowd, there's also Hush Mail (which is, BTW, a company that PZ joined after leaving NAI). What's so technically difficult about using this ?

Anyway, about PRZ and incompatibility: Will there be incompatibility between OpenPGP applications? I mean, will NAI really have any option but to comply with OpenPGP? After all, most PGP users thinks of PRZ as a man with very high integrity, and will not use anything that comes out of NAI if it isn't completely OpenPGP compliant. If businesses still trust closed source, that's their problem, but wouldn't widespread use of OpenPGP force compliance? (I haven't read the RFC, so I must admit I don't know if it does....)

Excuse me? I'm sure M$ would like to pick a standard and shove it through everyone's throat. And I'm also sure that in the first one or two versions it would actually be compatible with PGP. But not in the long run. And I am very sure that M$ would build in some back door (what, a back Gate is more likely *grin*).

Nah, I'd rather go for a nice open source project. There's already OpenPGP, no need to let M$ invent the wheel again (they'd come up with a wheel that's incompatible with all wheels used so far anyway and it would require a license). In my opinion, the software isn't really the problem. There's enough software with which you can send decently encrypted messages. Problem is the majority of the users: users who don't know and don't care about their privacy. George W. Bush can serve as a nice example here: he said he quit sending e-mail because it was too insecure. This means he doesn't know about encryption (well, surprise, is there anything he does know about?) but at least he cares (not about world peace or environment, but that's not as important as an e-mail message of course). If people could be taught just a few little things about privacy and security, the situation could change quite dramatically. People don't use encryption because it's not worth the effort. What effort? It's not difficult or complicated if you have any idea of what you're doing. With a decent plugin, all it takes is one extra click and the typing of a passphrase. Explain them the basics of encryption and show them the few extra clicks it takes and they can use it.

Most people here on /. know about security and how to use PGP. Too bad that probably 90% of all people on the Internet don't. Change that and encryption will become commonly used. Explain your nitwit-friends, e-mail your colleagues that don't have a clue, put up a page on the Net that explains a few basic things about encryption and include some links to OpenPGP and PGP and make sure people start wondering what you mean by including the line Public key: http://www.here.com/mykey in all of your e-mails.

Excuse me? I'm sure M$ would like to pick a standard and shove it through everyone's throat. And I'm also sure that in the first one or two versions it would actually be compatible with PGP. But not in the long run. And I am very sure that M$ would build in some back door (what, a back Gate is more likely *grin*).

Nah, I'd rather go for a nice open source project. There's already OpenPGP, no need to let M$ invent the wheel again (they'd come up with a wheel that's incompatible with all wheels used so far anyway and it would require a license). In my opinion, the software isn't really the problem. There's enough software with which you can send decently encrypted messages. Problem is the majority of the users: users who don't know and don't care about their privacy. George W. Bush can serve as a nice example here: he said he quit sending e-mail because it was too insecure. This means he doesn't know about encryption (well, surprise, is there anything he does know about?) but at least he cares (not about world peace or environment, but that's not as important as an e-mail message of course). If people could be taught just a few little things about privacy and security, the situation could change quite dramatically. People don't use encryption because it's not worth the effort. What effort? It's not difficult or complicated if you have any idea of what you're doing. With a decent plugin, all it takes is one extra click and the typing of a passphrase. Explain them the basics of encryption and show them the few extra clicks it takes and they can use it.

Most people here on /. know about security and how to use PGP. Too bad that probably 90% of all people on the Internet don't. Change that and encryption will become commonly used. Explain your nitwit-friends, e-mail your colleagues that don't have a clue, put up a page on the Net that explains a few basic things about encryption and include some links to OpenPGP and PGP and make sure people start wondering what you mean by including the line Public key: http://www.here.com/mykey in all of your e-mails.

That's OpenP2P, OpenPGP is an under construction consortium founded by Phil Zimmerman, whose PGP (Pretty Good Privacy) is the standard OpenPGP originally derived from.

OpenPGP != OpenP2P