PGP Universal - Usable Email Security?
An anonymous reader writes "For years, noted cypherpunks such as Brad Templeton, Ian Goldberg (PDF link), Bram
Cohen, and Len
Sassaman (PDF link) have been calling for easy to use email encryption solutions
which involve little crypto comprehension on the part of the user. Now, it seems like someone has listened: PGP
Corporation has announced its PGP Universal, which says it 'shifts the burden of securing email
messages and attachments from the desktop to the network in a way that is
automatic and entirely transparent to users'." The Register has more information on these newly announced proxy servers.
shifts the burden of securing email messages and attachments from the desktop to the network in a way that is automatic and entirely transparent to users'
If you think that letting the powers that be implement our security by shifting the responsibility for encryption to them is going to make us take off our tin foil hats then you have another thing coming o.0 Methinx that if anything this will make me consider constructing a newer, stronger hat.
Hmm.. wasn't there a patent about that somewhere?
That Jesus Christ guy is getting some terrible lag... it took him 3 days to respawn! -NJ CoolBreeze
But you're still not secure between the client and the proxy as far as network transport is concerned; plus, you've got all your keys in one basket. Furthermore, it seems like they are assuming that everyone will have one of these things set up. Is it so transparent to the people that can't read the email you send them?
This looks a lot like what the company I work for does.
(A box/infrastructure) that does the crypto/key management for you)
If someone really needs to use PGP security, which is almost unbreakable, they would figure out how to use existing programs. Most potential customers for this program have no need for it; the vast majority of people would be fine with little or no encryption. Really, though, who sends their credit card numbers over email? If it's that important, people go to the trouble to figure it out. So, in my view, this is a luxury. People who have a real need for PGP will take the 5 minutes to figure it out. Other people simply don't need the security.
"73% of quotes on the Internet are made up" -Ben Franklin
This looks like it doesn't accomplish significantly more than the existing SMTP option STARTTLS.
People who disagree with you are not automatically evil, greedy, or stupid.
It will near certainly not work as advertised and, regardless, it still defeats the object. The whole point of encryption is so that others can't access your sensitive data without your permission. Having a corporate entity hold the only key is going to help that ideal how?
PGP is a fascinating tool. Most see PGP as a way of sharing files, but the creator of PGP, Phil Zimmerman, really want to make a *privacy* tool. I did not realize this and other things until reading this book.
O'Reilly's PGP book can be divided into two sections. The first section is really a history of cryptography and how PGP fits in this context. I found this section surprisingly enjoyable as you learn about the long and tortuous struggle between the NSA and people who want to promote freedom and privacy. On a more concrete level though, you do learn quite a bit about different encryption algorithms and key algorithms, such as the RSA and Diffie-Hellman as well as other concepts important to cryptography. Admittedly, the history itself makes for pretty interesting reading.
The second section is about PGP usage, and it is very thorough in its coverage. You will learn just about every possible feature in PGP, and how to apply them to a number of possible situations. I like reading this book over the PGP manuals just for the time and care put into it, if not the amusing examples.
One thing other reviewers have rightly touched on is the age of the book. TIme has passed. The RSA algorithm is now free and open, and PGP clone called GPG is now in wide use. I am definitely excited to see a 2nd edition of this book in hopes that it will cover such things.
However, regardless of the age, this book is an excellent primer into PGP and cryptography culture, and newbies like me will certain enjoy reading it.
Quoted from Amazon
Pine/GnuPG ask me for a passphrase each time I encrypt and/or sign a message. This proves that I originated the message (not just some random punk who broke into my computer) for the purposes of authentication and non-repudiation.
The article and FAQ list were light on technical details, and I don't feel like registering for the actual whitepaper, but: since the aim of this service is to make encryption easy enough for common usage, I highly doubt there will be a passphrase prompt or any other method to ensure that the actual alleged sender is in fact the originator of a message. This seems to be confirmed by the statement that desktop mail clients (e.g. Outhouse) will be somehow directly "integrated" (how's that for nebulous?) with these proxy servers.
Without this precaution, I fail to see how this is anywhere as secure as straight-up PGP/GPG.
We have more to fear from the bungling of the incompetent than from the machinations of the wicked.
My first thought is, "Oh great, that'll just mean you need to trust the server."
But then I started to consider what would happen if a lot of the large domain servers were to start signing their mail automatically with a "Yes this really did go through our mail server" signature.
For one, if every message to come from Yahoo was signed with yahoo's key, you could automatically deny every message from yahoo that didn't have that signature. Think of how much easier spam catching would be.
Joe-jobbing could be reduced. If it comes from Intergalactic Orange Smoothie's DNS address without a signature, you know that somebody's been joe-jobbing Intergalactic Orange Smoothie.
And encryption between known partners could be enforced. So every message between Intergalactic Orange Smoothie and their partners could be encrypted.
Problems are, not everybody's got PGP. So Intergalactic Orange Smoothie can't make every message encrypted. So there still needs to be some user-interaction.
Gentoo Sucks
If this thing sits on each side and seamlessly encrypts/decrypts the mail without user intervention than what is the benefit of using this as opposed to using TLS? TLS provides seamless server-to-server encryption also, but its free if you are using an open source mail server that supports it, and TLS is already around and widely (albeit not widely enough) supported.
Said companies are going to be the first to go up in arms when a corrupt entity "loses" or "leaks" the keys. And yes, I am extra paranoid ;)
It seems that a device - like the keyfob-sized USB "memory drives" should be nearly enough for any personal use. Ideally there would be some sort of fingerprint or biometric reader in it too, though the existing passphrase mechanism could suffice. Just put your secret key on it and you can take it with you. I guess the problem is keeping randome machines from snagging a copy, though, since the same machine you plug the fob in to can also snag your keystrokes and thus your passphrase.
If it's not one thing, it's another.
As much as I'd like to RTFA, the meat of the information is in a white paper which you have to register for...
"Please complete the following form - we will email a download link to qualified individuals or organizations over the next few days."
Please hold comments until I get a chance to get the link.
The article states that the network is then responsible for decrypting and encrypting... it has to be clear text someplace on the network to begin with then. Doesn't that defeat the purpose? And, why is this necessary when the future 'ipv6' to be done by 2007 will be completely encrypted anyway (internet version 2 if you will).
What is slashdot?
Yahoo Mail does a superb job of catching spam and scanning for viruses. They also use SSL (optionally) for logging in. If they would just add PGP/GPG to their Mail Plus service, hell, I'd buy it!
The ability to plug-in PGP has been a part of several mail clients for a while... mutt, pine, etc. But, this has been the domain of the "more than casual" user... I would dread explaining to Mom how to setup her private/public keys, let alone why she should use encryption and the dreaded "how does this work" discussion.
;)
There's quite a bit of difficulty, methinks, in adopting this technology at any level the average user is aware of. I mean, the only way I can see wide-spread adoption happening successfully is you don't even let the users know how their mail is being encrypted/decrypted. Otherwise, you leave it open to too much user error: the dreaded "I lost my keys," or "Bob-IT-Guy, can you decrypt this important mail sitting in Sally's inbox... she's on vacation and we need it now!"
You take the (oh... forgive me) Lotus Notes approach (I'm *not* a fan, but I understand this aspect of the software): it can be setup so the encrypt and decrypt happens transparently to the user between Lotus Notes servers. If you had something along this level between mail servers, then you might start getting into secure transmission of e-mail.
Man... there are so many areas to lock-down... while I'm a big fan of PGP, it seems like the whole nature of the e-mail communication system needs to be looked at and (potentially) overhauled. So what if the message is transmitted securely between me sending it and you receiving it? If you do it at a user level, then you need universal support built into all the different mail reader applications. If you do it at the server level, then you need to lock-down the security more tightly at the server level (can your admins read your mail? Sure can! Not that it isn't already that open today). And how are keys managed? And who do you trust? And who manages how public keys get distributed?
Right now, it is all fairly manual (unless the tools have been updated since I last looked at them).
I can hear it now... can... opening... worms... everywhere!
Diplomacy is the art of saying, "Nice doggie!" until you can find a rock.
I didn't see prices on PGP's site, but I'll wager two cattle it's more than my parent's [an ideal audience for `easy crypto'] could afford.
Linux: The world's best text-adventure game.
If you buy Pretty Good Privacy, does that mean you'd shop with a real estate agent who sells pretty good houses? Would you buy a pretty good car from Pretty Good Motors?
Pretty Good ain't good enough for me. I'll take Fuggin' Awesome Privacy, thank you very much.
Fun with Anagarams! LADS HOST, SHALT DOS. HAS DOLTS. AD SLOTHS, HATS SOLD. ASS HO, LTD.
Sounds a lot like what Zixmail (zixcorp.com) and several other companies provide. It would be nice to see some kind of standard emerge that most ISPs offer as a free service -- StartTLS/SSL to an SMTP server, which then looks at a special header or whatnot and contacts a global database of IDs/Keys (e.g.: like DNS for domain names). Problem is that it requires a lot of people to all make up their mind a certain way and it's going to take some time.
Many of the standards of today (DNS/SMTP/etc.) came about while the Internet was a comparatively homogenous collection of universities, government and military sites mostly in English-speaking countries, with little or no commercial interest.
Nowadays I'm less confident in the RFC process -- clearly it is still there and still works, but as the Internet has grown, so has the time for a convergence on new and important standards. Case in point: IPv6 -- it's been around for years, but few sites have actually made the leap.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
Doesn't Anubis do this already? Why would anybody implement something like this, when a free alternative exists.
http://www.gnu.org/software/anubis/
Not to mention it has many more features than this, and no NSA Backdoors =)
-miah
As much of a POS that GroupWise is, it can be set up to generate keypairs for users and be automatically inserted into their clients. You could then make default the option to sign every message and leave it up to them to use encryption. Of course, I doubt most corporate users use passwords that are strong enough to deny someone access to the system, which would then give you access to the private key[s] of the compromised user. Still, it's there.
Linux: The world's best text-adventure game.
Sendmail and Postfix supports it, and generating self-signed certificates is not even difficult.
Got this e-mail this morning...
Dear PGP Customer:
We are pleased to announce the shipment of PGP(r)Universal.
Thank you for purchasing products from PGP Corporation. Over the last year, we have met with customers around the world to help us design a new generation of security products. Our goal was to take trusted PGP technology and deploy it in a way that would allow customers to finally secure all their electronic assets.
The result is PGP Universal, a new architecture and product family deploying proven PGP technology at the network level, making email security both automatic and requiring no user intervention. By combining a
self-managing security architecture with the proxying of standard email protocols, PGP Uiversal enables customers to achieve measurable email security.
In customer meetings it became clear PGP Uiversal must meet the needs of five groups:
- Executives that want to comply with rgulations and minimize risk
- Business units that must communicate privately and securely with customers and partners
- Security groups that must enforce and measure email security
- IT organizations that don't want to change their processes or integrate new technologies
- Users who just want to do their jobs
PGP Universal was built with these needs in mind. It offers:
- Automatic key generation and life cycle management
- Central and uniform security policy control
- Policy enforcement on both inbound and outbound email messages
- Automatic and transparent operation to users
- Automatic and transparent operation to the network
- Easy and incremental deployment
- Practical and cost-effective to secure everything?
- Full compatibility with existing PGP Desktop products
PGP Universal is available immediately for purchase or customer evaluation. An FAQ and white paper with detailed information are available at www.pgp.com/universal.
Information is also available at www.pgp.com, from your PGP sales representative, or a PGP Certified Solution Provider.
Thank you for your interest in PGP products.
Sincerely,
Andrew Krcik
Vice President, Marketing and Products
PGP Corporation
That's not why it's called a "floppy drive," numbnuts.
Are you too fucked in the head to read the artical or do you actually wear a tinfoil hat asshead?
Hushmail has patent (US6154543) on any kind of scheme with server based private key management.
Don't most organizations do this sort of thing with LDAP already?
Conformity is the jailer of freedom and enemy of growth. -JFK
This is a thing for corporations. Private email-crypting will continue to suck big time until PGP/Mime and all that stuff become standard functions in KMail and Thunderbird and don't require some ominous compiling/installing of shoddy beta plugins or a five week full-time training in exim and mutt configuration.
We suffer more in our imagination than in reality. - Seneca
"i don't have any of that. it's too confusing".
"I don't have any of that. We broke it ten years ago and have our own in-house algos. But if I told you that, I'd have to kill you."
I hereby place the above post in the public domain.
The spam can't be scanned while in PGP form, and according to their diagram it won't be decrypted until AFTER hitting the mail server.
I suppose one point up for security, one point down for preventing spam :(
And realistally, if enforced server-side PGP signatures become the norm, then you could watch spammers fall by the wayside anyhow.
After all, it must take a certain percentage of CPU power to encrypt these messages, no? Perhaps it will be fine for your average ISP, with on-demand encryption or perhaps an encryption daemon capable of processing X queued processes/minute, but for a spammer trying to offload several thousand to a million spams? It's going to take awhile to encrypt that spam, at the very least it's going to slow the buggers down.
Can I please make some money, too, by using SSL for some previously plain text protocol and serving as a certifying authority between any two parties?
"Provided by the management for your protection."
Personally, I'm just going to use jwz's new script for all my communications:
Aoccdrnig to rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer be at the rghit pclae. The rset can be a total mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe."
http://jwz.livejournal.com/256229.html
Was I the only one that read the article like:
"Oh.. PGP corporation.. thankyou from the bottom of our hearts for caring so much about our email that you just HAD to develop this amazing product that sells for a mere three installments of $29.99. But wait! There's more! Order now and you'll also receive.."
Thanks, anonymous submitter!
Ever since US NSA money polluted PGP its bad to trust anything labelled 'PGP' for any reason.
:
C T= 104&STORY=/www/story/04-09-2001/0001464825&EDA TE=
:
:
NAI admitted they took significant funding for engineering work while they owned PGP trademark.
NAI does not deny this.
They do deny the NSA moeny resulted in holes, yet we all know PGP was tamperred with at least once to allow a third party to be silently attached to a pgp email.
NAI claimed that the funding mostly ent to a linux group formerly called TIS Labs but that is no wholly true.
here is just one press release exposiong the payoffs for tampering with PGP earlier for "national security" of USA
http://www.prnewswire.com/cgi-bin/stories.pl?AC
(excuse spaces slashcode may have added. the link without tamperred 'spaces" works, i just checked it. silly slashcode).
regrettably source code to PGP 5 and up to 6.5.8 contain faulrty message recovery features ADK (Additional Decryption Key), or ARR (Additional Recipient Request)
it is a serious problem, one of many and the CERT advisory for this pgp exploit is avaialble here
http://www.cert.org/advisories/CA-2000-18.html
(excuse spaces slashcode may have added to the url,usually only after 80 character though)
pgp os discredited on many levels but the main reason pgp is not widely used is because NAI never ever ver gave out free source code to the integration parts to int3egrate with popular email programs (outlook on pc and mac, claris email on mac, netscape email, etc etc).
without the integration, yoiu have to copy to ram clipboard, swap tasks, use the tool, open a text document, after decrypting you then paste into ram based document, (if vm is off), and then read the mail. messy.
people want macintosh-windows ease of use pioneered by the lisa since sept 1982, twenty years ago : GUI !
people want a gui way of doing it and the free pgpclones adn the con-scam pgp of 2003 just do not get it.
the reason people do not use pgp is because
1> its not full source code avaialble in the most pleasing versions ever released
2> its not free for companies to use
3> its tamperred by nsa money and now needs a full code audit or else reversion back to pre 5.0 version.
4> RSA key patent expired long ago and rsa is etter but pig-headed codem mokeys refuse to use rsa as preferred technology for no reason otehr than arrogance and it leaves a sour taste in most gurus mouths to forsake rsa for no valid reason in 2003.
pgp is dead and greed killed if off. greed greed greed (and a little nsa nro involvement)
You take the (oh... forgive me) Lotus Notes approach (I'm *not* a fan, but I understand this aspect of the software): it can be setup so the encrypt and decrypt happens transparently to the user between Lotus Notes servers. If you had something along this level between mail servers, then you might start getting into secure transmission of e-mail.
Yes, we call that STARTTLS in the SMTP world. However, that only provides hop-to-hop encryption, not end-to-end. There is no guarantee that each link in the delivery chain will employ encryption. While I'm not familiar with Lotus Notes, I daresay that once it forwards to SMTP it either stops encryption there, or uses STARTTLS for the first hop out with no control after that.
For those who don't know, Phil stated when he left that every PGP product released while he was there contained no hidden back doors. Knowing that companies like PGP were being pressured, it makes me think the creative differences were them wanting to build something in that he thought shouldn't be in.
LordBodak's journal.
How will this prevent the propagation of email trojans, apart from the fact that they will be encrypted as they get sent across the network. If the receiving party automatically trusts the sender, won't this make it more dangerous?
They seems to support POP3. That means that all the e-mail that someone receive are in plaintext on his harddisk. Not very secure!
For this approach to work, someone would have to BCC himself instead of putting a copy in the sent folder to keep the e-mail he sent. Also, it can be secure only if using IMAP (mail stays on server) and the folder used to as the IMAP cache on the computer should be encrypted.
I don't know what their target market is. Most large corporation use Notes or Exchange, which already support encryption.
Actually, I've been playing with Thunderbird, and setting up encryption is pretty damn easy.
I work for a fairly "hip" company (IBM) and we have this nifty website you can go to, fill out a form, and they send you a nice little PKCS#12 file, signed by a real root cert and everything. To use this with Thunderbird, all you have to do is: "Manage Certificates" -> "Import" -> (password) -> done.
Of course, if you want to generate your own keys, that's a little harder, but nothing a simple script couldn't be created to do.
I'll be an idiot and reply to myself. My point was that this might not cause more users to use crypto if it's cost-prohibitive and nobody buys it. Big companies, maybe - small business? doubtful.
For one, if every message to come from Yahoo was signed with yahoo's key, you could automatically deny every message from yahoo that didn't have that signature. Think of how much easier spam catching would be.
And encryption between known partners could be enforced. So every message between Intergalactic Orange Smoothie and their partners could be encrypted. Problems are, not everybody's got PGP. So Intergalactic Orange Smoothie can't make every message encrypted. So there still needs to be some user-interaction.
First off, signing and encryption can be chosen individually. So yahoo could start signing all messages as "Came through Yahoo" today, without encrypting.
The problem is, where do you get the secure keys from? And yes, you could then upgrade once the end-server supports encryption (The server could simply announce in some X-header: X-Supports-Encryption:Yes. If there's some two-way traffic, you'd know quite quickly.)
The problem is still getting the secure keys. Sure, you can probably keep a database of the biggest ISPs. But it's simply not feasible to keep an up-to-date database of every ISP in the world.
Kjella
Live today, because you never know what tomorrow brings
Why not just have all the mailers settle on a protocol for key exchange that happens passively when you send/receive email?
I wrote up a specification for just this quite a while ago, but stopped working on it because a) I had a new job and b) other people seemed to be moving toward something workable that did roughly the same thing.
Perhaps it's time for me to go back to pps...
No, because you don't have the FUCKING BALLS it's going to TAKE to SEE THIS MISSION THROUGH to the VERY END.
You should try KDE's KMail with gpg integration.
It is milk-simple and as easy to use as a nipple.
-I like my women like I like my tea: green-
If you use SSL-encrypted SMTP on the server and client, and the recipient uses SSL-encrypted POP3/IMAP, you're secure anyway. This method requires just as much, if not more, setup than that method.
I agree with you, and because of their installed base it would be possible for them to make encryption a default for the majority of the population. This is critical for generating a critical mass that is needed to be able to sustain encryption as a routine practice.
Trying to send encrypted files all of a sudden to a few people somehow seems to give the wrong impression, because it seems that you have something to hide. It is as if your communication stands out as a needle in the haystack, and someone using a "magnet" can just suck you off the system ....
But, if Yahoo, hotmail, etc started encrypting by default, then a huge number of emails, I believe enough for the critical mass, shall use encrytion. And so now your desire to send encrypted encrytion is no longer looked at with suspicion. You are now like hay in a hay stack and no magnet can suck you off the system ...
So, I believe, in the spirit of Standing Up against such obscenities as the Patriot Act, companies like Yahoo.com, M$ Hotmail.com, Mail.com, Verizonmail.com, Myrealbox.com, etc. should start provinding encryption by default.
It is the "right" thing to do.
To see a world in a grain of sand, and then to step back and see the beach where the sand lies
If you do it at a user level, then you need universal support built into all the different mail reader applications. If you do it at the server level, then you need to lock-down the security more tightly at the server level (can your admins read your mail? Sure can! Not that it isn't already that open today).
Think of it in terms of regular mail - of course we can do user-to-user encryption. I print something encrypted, you scan it. Safest, but also most complicated.
But the mail is typically handled in a secure manner - even if your mail is sent by car or train or plane, the crew of the transport mediums usually do not have the opportunity to read all your mail like postcards.
Sure, there's SSL between servers but it doesn't quite do the same. If you can gurantee that the connection between the entire server chain between the sending server and recieving server is secure (by being encrypted for the end server only), it's a considerable security upgrade compared to today.
Kjella
Live today, because you never know what tomorrow brings
I think that it's easier than you think.
There's tons of different places you could sequester the data. DNS or IP allocation records, for example -- it's already an up-to-date database of every ISP in the world. DNS already handles caching and whatnot.
It's pretty much like a trust mark in reverse. Step one, all of the servers contain a key and automatically digitally sign the messages as coming through that server. Step two, the server admins create a DNS record containing the key used by the server and the server admin attests to the fact that they don't allow open relays and whatnot. Step three, if an email claims to come from that server and isn't signed, the message can be safely dropped. If an email comes from the server and is signed, it can be whitelisted.
The problem is that any sort of key distribution scheme for intercommunication between two random related groups sucks. There's where the user interface comes in and things become just like normal use of encrypted messages. PGP Universal isn't going to help you there. But at the very least, if two companies are both sending proprietary emails back and forth, you can make sure that any mail between those two parties has been encrypted.
Gentoo Sucks
Something like this would be fantastic for getting users to adopt pgp. If the security part was built right into the machine (which it can be via the localhost proxy) and worked the same no matter what email client was used it would make adoption much simpler. I hope something like this gets added to the gpg tools in short order.
Everyone should be using encryption. That they aren't doesn't change the fact they should.
A simple, yet very secure solution allready exists:
http://www.hushmail.com/
Can't say enough about this free service. It simply rocks.
why don't you retire already old man?
I believe Lotus Notes uses encryption only between Lotus Notes servers. Now if that's strictly internal (internal server to internal server) or if that means between Lotus servers at separate companies, I'm not sure. 8/
But, for Lotus outgoing SMTP, I don't think it uses anything special... even STARTTLS (which isn't in wide adoption yet... I have my postfix instance at home setup to accept/use it if available, though). But, as you pointed out, that's minimal protection at best because anywhere in the chain it might hit a non-TLS encryption server.
The whole system needs to be locked down better/differently. If we find a better way of connecting messages back to the originating sender (ie, we know who sent it because it was authenticated all the way back to a particular user), we might also be able to start curbing SPAM some; I'm sure there are plenty of spammers who wouldn't like being connected non-anonymously with their cruft. Of course, that requires the entire system, end-to-end, be secure and authenticated, IMHO.
Diplomacy is the art of saying, "Nice doggie!" until you can find a rock.
What elitist tripe! This makes no sense. Instead of some artificial barrier like an unreasonably complex setup routine, how 'bout you make it as easy as possible and let the user decide whether they have a use for some software?
People that don't want software won't try to install it. If they try to get it running and can't, that doesn't mean they don't need it, it just means they couldn't install it! If the install routine was impossible to get any easier without compromising features, you might have some grounds, but I don't think that is the case. In fact, I think the setup for PGP sucks rocks.
Why shouldn't people have easy access to security that allows them to send information like a credit card over email? If it's secure, why not, except for paranoia?
plz provide links kthxbye
All errors in this comment are mine. Corrections are considered a derivative work, and punishable under copyright law.
Yahoo Mail does a superb job of catching spam and scanning for viruses.
Er... ok... has someone started a new yahoo or something... is this the same one I use...?
You are replying to my post, though it appears as though you stopped reading after the first line! Although not uncommon on slashdot, please read the rest.
My post was about a system wide change in the way e-mail is done. I know it's not feasible, but it would solve all the problems mentioned and make it real easy to determine whose who and what's what for spam filtering.
1) Require records in DNS to authenticate mail servers to send out e-mail for domains, subdomains even. All @example.com addresses must send out from mail.example.com otherwise the server on the other end will just reject it because the DNS record says so.
2) Require authenticated SMTP. Don't rely on IP based relay (IE, just allow the subnets you use to SMTP out.)
3) Require all SMTP gateways to force TLS
4) Require all POP/IMAP servers to use SSL
This set up would not only solve the encryption problem, but would greatly reduce the anonymity a spammer has and make it very easy to track them down and stop them.
I wasn't talking about relying on existing protocol's the exact way they are currently implemented but rather require implementation.
Can I get an eye poke?
Dog House Forum
Has anyone looked at this thing Yet? Word is its based on Redhat 7.3 but they aren't publishing any source code. Has PGP licensed this product from SCO? Their support and store sites reverse DNS to the same data center as SCO? Maybe that means that they also feel the GPL is invalid and can use Linux anyway they like.
How is this different from server systems currently offered from the likes of companies such as RSA and Entrust?
They are shifting the complexity from the client to the server, which is good. But it has been done before.
Life is like a web application. Sometime you need cookies just to get by.
This won't work, for the same reason that other "anti-spam" measures based on MX-lookups don't work - valid email "from" an email account doesn't necessarily come from the mail server(s) listed as the MX for that domain.
Example : I have users on the road, with email addresses of the form user1@example.com. They're dialling in to the net using an ISP that has the policy of blocking all outbound tcp connections to port 25 (to "prevent spam"). There is no way the user can send email messages via the registered MX host for the domain example.com - the ISP forces you to send email via *their own* mail system. So you get a perfectly valid email coming from the mail server for the ISP, but whose "from" address is in example.com.
My next sig will be ready soon, but subscribers can beat the rush
As it is now, I have a PGP key, but no one else does. So I grit my teeth and send my mail in the clear.
If we buy PGP Universal, everyone at my company will have PGP keys, but no one else will. So we'll all end up sending our mail in the clear (except for internal mail which doesn't cross the Internet anyway), because we have no one else's PGP keys to use for the encryption.
I suppose you could say that everyone signing their email is a good first step, and maybe it is, but I don't see how it will have network effects that get us to universal encrypted mail anytime soon.
why my opinion matters: i have actually used this software as an end user. i have no affiliation with pgp corp. i just got a beta download and a manual, and sorted it out on my own.
let me try to describe how it works. i'm no expert, but i think that might be a good thing in this context.
say you and i are on the same mail server, using the pgpu proxy. i send you a mail. the server says "hey, me@domain.com has no keypair". "me" has authenticated to the smtp server to send the mail, so we're going to trust "me" and generate a key pair. another will be generated for "you". when "you" check mail, it trusts you based on the imap authentication, and decrypts the mail. ultimately, the "passphrase" on the keys is the imap/smtp authentication.
this gets you encryption that took 0 effort on the users' parts, no effort on the part of the administrators beyond the initial server setup.
the user can't forget to encrypt.
you are no less secure than before, as you are still trusting based on imap/smtp authentication. but now the messages are stored encrypted on your normal mail server.
should your server get rooted, the messages aren't readable.
or if an it person with root on the mail server decides to poke at the ceo's mail, it won't be as easy (especially if that person isn't an admin on the pgpu machine).
since this is just a proxy, it can be dropped in seamlessly with a simple dns change, so you don't need to change your clients. assuming they are all using SSL already, you're done. if they aren't on ssl, there is a windows client that can be installed via active directory that will secure the desktop -> server connection. or you can just tick the "use ssl" box in any decent mailer. since it is a standard protocol, the client app doesn't matter, leaving you free to use mac/windows/linux/whatever. in my testing, the clients were macs running apple's mail.app.
it took me about 20 minutes to get it set up and working in the lab for internal mail encryption/signing. that includes installing the software.
the installer is an appliance type thing: boot off the cd, install, reboot, you're done.
regarding the keys all in one basket, there is a backup facility built in to the software to make sure you have your keys in the event of a failure.
i haven't done anything with sending mail to external users (outside of your company), so i can't say anything for/against it).
all in all, i think it's a pretty neat product. i actually don't know a thing about the pricing, but it brings value for a low admin overhead.
new outlook viruses to be safely encrytped all the way to my local mailserver!
Nowadays I'm less confident in the RFC process -- clearly it is still there and still works, but as the Internet has grown, so has the time for a convergence on new and important standards. Case in point: IPv6 -- it's been around for years, but few sites have actually made the leap.
While there are other improvements, the biggest advantage of IPv6 is touted as the address space. But the thing is, there's no advantage for early adopters. OTOH, if you can manage to get a "Secure, better, less spammy (hopefully, at least less fake) email" that's a real feature that sells.
Kjella
Live today, because you never know what tomorrow brings
There's a constant drive to dumb things dwown, make them easier to use without any kind of understanding about what is going on under the hood.
This is good in some areas. People need don't need to understand how their word processor or web-browser works. So long as it works, they can use it effectively.
In the case of information security, it's dangerous. If people use encryption without at least some understanding of security, they won't use it effectively. But they will believe they are safe, because they clicked the "encrypt my e-mail" button.
Surely the real solution isn't to dumb down the software, it's the smarten up the users. Pretty much everyone who really needs encryption is capable of understanding enough of the issues around computer security and use existing software to secure their e-mail. People need to accept that computer security is a complex thing, and like all complex things, you can't do them without at least a bit of homework.
Sure that's great let the ISP encrypt your email! That way the fed's can keep a copy of the keys and decrypt everything on the fly and continue to read those sexy words you say to your wife or mistress via email.
Anyone who wants or needs encryption and who are smart enough to use it would know better to use something that resides on your pc which you have control over not the other way around.
Oh well. As long as they don't get a patent on it (can you spell "o b v i o u s"?), I guess it's fine.
Smart cards won't make PGP that much easier to use. Read "Why Johnny Can't Encrypt" for some sobering facts about how hard it is to just get PGP set up right.
Regardless of the technical merits of this server-based approach, no one solution (particularly not a costly one) will lead to the widespread adoption of email encryption. Which is why I'm happy that IMP (part of HORDE) is integrating PGP into their latest release of their open source web-based email program. I've used IMP for years on a small server, but I have also seen it deployed by a large University, and can say that the only thing it lacked until now is integrated encryption. Hopefully, we will see this type of integration in many web-based email programs (encrypting a message to a Hotmail user, anyone?).
cryptbox
We've been using ZixMail's ZixVPM with great success for over a year. I'm not sure that you can call "management free email encryption" a new thing. :-)
This has already been done. All one need to do is generate a set of keys and send from end user to end user. The thing that is so interesting is that the mail server is supposedly encrypting this as well. Why dont they just use a NES (network encryption system) that can have umteen connections or a TACLANE that can have up to 6 connections while using hardware encryption? Combine a system like that with a eprom usb device that has the private key on it and the public key on one of many public accessable ldap servers and your set. Just have the email programs check one of the mirrors for a valid key, and off goes your email. You just have to make sure you log in to your eprom. 128 bit encryption is not hard on massive networks, its getting it to be accepted by the home user that you cant control that is going to be the issue. Make the eprom a package deal with your isp connections, and your set. Get a net connection, get a usb token that encrypts your email for you automagically. DoD has been doing that crap for years, just do a google search on DMS (defense messaging system). You shouldnt be able to get down to the nitty gritty, but you should be able to get an idea.
Stop signs are only Suggestions
- Something you have
- Something you know
- Something you are
The combination of the keyfob, the biometric, and a password is as good as it gets. To really do it up right, the keyfob has male and female USB ends, which allows the 'connect the keyfobs to trade public keys' and also would allow a USB keyboard to connect through the keyfob, so that it could do the password part without passing the keystrokes on to the computer (that might have a keylogger installed).[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
I setup Procmail to do stuff like this over two years ago, why buy an "appliance" when you can search google and find out how to do it with sendmail / procmail, don't see the benefit myself.....
I've always found S/MIME (a la Mozilla and others) to be easy as eating pancakes. Integrated and simple. Very powerful too (PKCS#11 modules allow access to smartcards and all sorts of devices).
On the other hand I've always found PGP to be a huge pain in the ass since day 1. I don't know why people stick to it. There was a need for it before S/MIME but nowadays it just sucks.
The ratio of people to cake is too big
"entirely transparent to users ... "
The first time I recall hearing that phrase was when my university switched form WYLBUR to VM/CMS.
I suspect it is as true now as it was then.
Anybody remember Paper Tape?
=brian
I am certainly glad we still have all these hackers to continue making things rough, hardcoded and difficult to comprehend short of devoting many solid 24x7 weeks. Hasn't anyone reminded these jerks that we don't want to be like W1ndOw$ and we are 1337? No user should ever be allowed usability if they have not become intimate with every single detail of the system they wish to use.
Oh, btw... pay no attention to my use of higher level programming languages, use of HTML, use of portals like this and uses of compilers in general.
frag-router is cool! thanks for the tip.
(not a black-hat!)
I read about the T/bone SecureMail Gateway on their website over at least a year ago, isn't this the same thing? One neat thing about T/bone vs. PGP Universal? -- the license for this is "free of charge for public research and education". Gotta love that! =) I've been trying to get the faculty in my university to use it, and help get rid of Lotus Notes. =)
Look what was offered on ebay germany...
Do not be alarmed. This is only a test.
Server-signing might be a bit over-kill for the spam killing job. (May be too expensive CPU-wise for most servers to implement?)
One attack that I can think of involves stealing the private key and setting up a rogue server. Another would be to just infiltrate the server and turn it into a zombie.
The first attack is more easily thwarted if there is some sort of reverse-MX/DNS lookup system so that you can check whether e-mail from a given IP address (or system) is authorized to send e-mail for that domain. Such a system needs to provide (2) pieces of information: (a) does this domain have a list of which IPs are allowed to send e-mail and (b) is a particular IP authorized.
I agree that digital signing of e-mail between servers is useful, but DNS and source-IP information needs to be part of the equation to make the attacks more difficult.
Wolde you bothe eate your cake, and have your cake?
Very true. If I remember correctly, there already is an RFC for the reverse-MX/DNS lookup system you describe. It hasn't been supported too widely yet.
Key revocation definately needs to be a concern if you are signing server messages at the server level. Same concern as DNS expiration dates, for the most part.
I think the big point either way is that you don't need to completely ditch all of the existing SMTP code and infrastructure, like some have been suggesting. You just need enough of the large ISPs to start adding and supporting new sets of mail features that will make it harder to set up spam mail servers while not appreciably impacting legitimate users.
It's also should be pointed out that the concerns of convenient spam-proof email and the concerns of completely private email are similar, but not the same.
Gentoo Sucks
Create a key. It has two halves, one public and the other private. What one encrypts, only the other can decrypt. Give the public half to everyone else and keep the private half to yourself. Now they can encrypt with the public key and only you can decrypt it.
Use ISO 8601 dates [YYYY-MM-DD]
Do you trust Verisign? I don't know a damned thing about Verisign. I don't know anything about their employees' integrity (I've never met them), or whether some Men in Black with (or perhaps without) a piece of paper signed by a judge are over there, having them sign false keys for the purpose of a MitM attack.
I don't know if their signing key has been unknowningly compromised. I do know that if their signing key were knowingly compromised, they would have a very strong financial incentive to be quiet about it, since so many private keys' reputation depend on that one cert.
If a bunch of different people all over the world have certified someone's PGP key, and maybe I've even met some of them (or met someone who claims to have met them), that I then have some idea how how much I trust a key to be for real.
S/MIME is illusion. PGP is the real deal. PGP is about responsibility (or knowing when you're taking a big chance (e.g. relying on a Robot CA or something)), where S/MIME is about always putting all your trust into one entity and then burying your head in the sand. Do you want easy answers that might be wrong, or do you want to be informed about how much uncertainty there is? What do you think is really the secure attitude?
Also, GnuPG is a piece of cake to figure out how to use, compared to those infernal OpenSSL tools. (That's a comment on the tools rather than the standards, though.)
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.