Slashdot Mirror

PGP Corp's keyserver uses expiration dates and email verification to let abandoned keys slip away. It's not a bad system, really, although it open its own unique possibilities of abuse.

The problem with PGP/signed-emails is that you're putting the burden on the user.

Okay, I'll bite. (not TOO hard, mind)

So lets use PGP and still put the burden on the ISP / email provider / Facebook / anyone but the user

1. Every email client in the world ships with PGP support
2. Every email provider issues a key to their users. This can be done by the email client getting the key from the server when it authenticates (say a specially crafted email that it then hides from the user. No need to make it complex like extending the protocol! Just use existing technologies like "Magic emails") And emails of this format could be filtered trivially from being recieved (so no emailing someone a new private key!)
3. Every email is signed and verified and those that aren't are flagged as "DANGER DANGER!" or ones signed but from somewhere not trusted, etc etc. PGP has a wonderful system of trust built in. It can be used in any way they want (google, MS, Yahoo, etc publish public keys and sign user keys with it, etc)

Lastly if someone savvy enough wants to use their own PGP key they can. Just get it signed by their email provider or some other such proof that they control that email address. PGP has this sort of thign already, very nice! https://keyserver.pgp.com/

Bonus points to PGP: since it already has the idea of a web of trust it can be used to GREAT effect. The email client could regognize that you seem to work with this person or email them a lot and ask, "Do you know this person in real life? Do you trust that this email is from them?" and sign keys that way. In this way one could have direct evidence that an email comes from someone that they can trust rather than just Google's big red rubber stamp. How novel!

We could really make this work with popular social media sites like facebook (I'm not a member, but lotsa people are) and show where this person is on your social graph (if they are at all)

So that is how we can use PGP, have it be as good AND BETTER than something new and not make the users do it. Sure there are more than a few flaws in the above but that is the basic outline.

Whole disk encryption needs to become mainstream. There are many approaches. Here are a few useful links.

If you want your OS to encrypt everything, Fedora makes it easy. So does Ubuntu.

If you want an add-on software package, PGP works well. In a slightly more involved way, so does Truecrypt.

If you prefer a hardware solution, you can adapt regular, off-the shelf drives with an encryptor such as the Deskcrypt. Fully-encrypted hard drives are available from most vendors, too, but the ones I've found most generally useful (as in, "compatible with every other sort of hardware") are the Eclypt models from Stonewood.

I have owned and used all the products above and like them very much. If you feel different, feel free to Google things like "Momentus FDE" or "WinMagic" or "Guardian Edge Hard Drive" for other vendors and approaches. Take whatever path seems most reasonable and logical to you.

But for God's sake, would everyone please start encrypting your drives? That's not everything you need to do. It's just a minimal first step toward personal security. But it's a start.

I much prefer the diskGenie, which is also a product from istorage-uk.com, however it feels more rugged, has a very nice tactile feel. Has the same encryption level as most of the others and reqires a 6-16digit pin to access the data.I have the 500gb 256 version and a 128gb ssd both reasonably priced.

Whole disk encryption needs to become mainstream. There are many approaches. Here are a few useful links.

If you want your OS to encrypt everything, Fedora makes it easy. So does Ubuntu.

If you want an add-on software package, PGP works well. In a slightly more involved way, so does Truecrypt.

If you prefer a hardware solution, you can adapt regular, off-the shelf drives with an encryptor such as the Deskcrypt. Fully-encrypted hard drives are available from most vendors, too, but the ones I've found most generally useful (as in, "compatible with every other sort of hardware") are the Eclypt models from Stonewood.

I have owned and used all the products above and like them very much. If you feel different, feel free to Google things like "Momentus FDE" or "WinMagic" or "Guardian Edge Hard Drive" for other vendors and approaches. Take whatever path seems most reasonable and logical to you.

But for God's sake, would everyone please start encrypting your drives? That's not everything you need to do. It's just a minimal first step toward personal security. But it's a start.

The problem with freedom is that it never seems to involve corporations or governments.

The the solution to this particular problem is easy, simply let the users run their own encryption with their own software and own keys on their own hardware. I'm surprised such a thing doesn't exist now for the Blackberry. Oh wait, it does. All RIM has to do is tell these dumb governments that "yep, you can read the stuff on our servers," while at the same time paying bloggers under the table to spread word on how to install third party encryption.

If these governments are still really pissed off about it, they can start arresting users for having encryption software and they can keep on doing that until people finally get the notion they are living in a police state and maybe want to do something about it.

First of all, the amazingly high probability should be 2^14 (or 1/2^14 = 1 / 16,384), not "214". This is the danger with cutting and pasting mathematics. In a slightly simplified explanation, distinguishing attacks work by looking at encrypted data and trying to distinguish it from random bits. This means that the distinguisher succeeds with the probability above, which may not seem very high, but believe me --- it's much higher than what it should be for a cipher like this. And as they show, efficient distinguishing attacks can lead to nastier things like key recovery.

I saw Adi Shamir stand up in front of a crowd at Crypto 2008 and introduce a new set of techniques he and his colleagues had developed for simplifying complex algebraic equations. People jokingly asked him if he thought it might work against AES (yes, it did). I haven't seen this paper, but my guess is that they're running around applying their techniques to everything they can find. And so Kasumi bites the dust. (Meaning that I must update my course slides, agh.)

More to the point, this is unlikely to be a practical issue right now because it's a related key attack. You have to encrypt something with multiple keys that are closely related (similar in many respects) before the attack applies. This usually doesn't happen unless the implementers are idiots. But the point is that it's bad news --- related key attacks are the camel's nose under the tent for much worse things to come. I'd say they should upgrade to AES, but I'm not even sure if that's a great idea :)

Oh, and I'm doing the thing I hate the most: giving the senior person all the credit. No doubt an equal or greater share of the credit goes to Orr Dunkelman and Nathan Keller, his hungry PhD student and post-doc who probably spent the last zillion hours of their lives working this out in their lab only to see people like me attribute all of their work to Shamir. Good job, guys.

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...

How about https://keyserver.pgp.com/ or http://www.rossde.com/PGP/pgp_keyserv.html or http://pgp.mit.edu/ or roll your own at http://pks.sourceforge.net/ if you are so inclined.

"This week I received calls from four different customers saying that they were warned that they are dangerously insecure because they run open source operating systems or software, because 'anyone can read the code and hack you with ease.'"

Wow. PGP can be hacked with ease? I'd like to see an example of that one.

The Network Computing article referenced here is ancient history. It says that PGP was "recently acquired by Network Associates" and it talks about support for FAT16 and FAT32. Network Associates sold PGP way back in 2002. See: PGP Corporation History

I recommend the original poster get some current information on the PGP product.

there have been many posts saying use truecrypt, it's free, ubuntu ftw, and so on. if we're talking about home use, then by all means. i use truecrypt at home myself.

however, if you are a company, org, edu, etc, you more than likely need accountability. with free software, written by volunteers, etc, you'll typically find support from the forums, and from the developers when they have the time. open source rocks, but this is a major limitation, especially for prospective business users.

here's an example, both support/contact pages from the 2 encryption products in question:

truecrypt forums and truecrypt contact. they have no true support, as far as i know.

pgp support and pgp partners.

truecrypt is awesome, but you'll never get from them what you get from pgp. and, to the people who said "what if pgp goes away, it's closed source and you're screwed", pgp will not go away; it may be bought, sold, merged, but until we reach some utopian society where encryption is no longer necessary, pgp is here to stay.

anyway, the above links are important because: with commercial products such as pgp, you have a company, with teams of technicians, engineers, etc, all ready and willing to work with you to put together a solution for your problem. the same goes for partners and major resellers. if your company has a preferred channel through which to buy its IT gear, use them. what you get here is assistance, accountability, support, collaboration, SLAs, and so on, all the things a business of any kind typically needs. unfortunately, you don't get that from truecrypt. if your hard drive failure rate goes from 1 per month per site to 50 per month per site, who do you think will be there to fix the situation, replace the disks, and so on?

my first question for you would be, have you engaged pgp directly (as a company), or indirectly throught a business partner? if so, who is represented in these discussions? any sort of management from your department, or is it just IT? if not, i would recommend working internally to find out who is doing this project, and make sure everyone has adequate representation during all the discussions, testing, r&d, etc for this project. maybe WDE isn't for you and people in similar positions. maybe encryption for DB transactions will be sufficient. maybe you don't need anything at all.

despite what many bitter slashdotters would have you believe, most companies realize that selling the wrong solution to a client is a horrible thing, so they are typically quite eager to work with you to make sure it's done right the first time around.

so, in the end, i'd say make sure you or a representative of you and similar co-workers communicates with the project team and pgp/reseller, and that your concerns are being addressed. i guarantee you're not the first person to feel this way, and i'm sure pgp and/or the reseller have tools and procedures in place to make sure this rolls out how it needs to.

one last note. some advice above and below said to make sure your reports prove that it would cost ungodly amounts of money to keep your current productivity levels after instituting WDE. i think this is a bad idea, and like any other science project, you should see what happens, and report the results. maybe WDE would ruin your productivity. maybe it wouldn't...

A quick google for PGP whole disk encryption yield PGP's spec page

Which probably means that the scheme is your typical PGP your symmetric key...

So it seems that an AES acceleration, such as the VIA PadLock, could potentially mitigate the performance issues.
X-bit labs just had a minor blurb recently about how the Via Nano with PadLock trounced the Core 2 Quad...

Their product doesn't seem to run on Linux.
There is better, cheaper F/OSS software to do the same thing though; Ubuntu and FC9 already include a whole disk encryption option at install. (It's better because it's much less likely to have an NSA back door, although obviously never completely certain).
As for performance, when I tried it (luks encryption) on a desktop machine, it wasn't noticeable; but I wasn't moving hundreds of gigs around.
The question now is what are they trying to protect. Encrypting laptops is sensible, and in fact, given how easy & cheap it now is, it's rather stupid not to do it. On desktop PCs, it's not that clear. Whole disk encryption will only protect you against someone with physical access to the machine turned off. It certainly won't protect you against trojans or browser based vulnerabilities. So the question is, do random strangers roam your offices?
And encrypting servers/clusters? That's just silly; unless you expect the men in black to storm in your building.

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.

The PGP page for the effort wasn't up yet when the CNET story broke, but it is now. More information there.

I have useful experience with three products.

SecureDoc from WinMagic is the software solution we use at my big TLA. As administration headaches go, this one isn't so bad. The recovery processes are workable but not (that I can see) hackable by any thief. The way we have it set up, users get 15 shots at screwing up their machine before IT has to get involved, thus allowing most bozos to eventually get it right while not giving infinite opportunites to thieves. It's administrable over the network (in some ways) and, thus, suitable for big organizations.

At home, I still have one Windows machine and it's secured with PGP. I've never used it in a big networked environment so I can't comment on how easy it is to administer. It has one feature that I think is neat, though. You can hit TAB before typing in your passphrase and it will be displayed in clear text. (Normally your pass isn't echoed on screen.) Scoff if you will but on those bad days when I've had little sleep and am, perhaps, a bit hung over, my 59-character passphrase can sometimes be just one hurdle too far. Seeing the text on-screen can be a big help for those times when my head just isn't in the game.

Finally, hardware encryption is better. When my Windows machine was my primary (I now am almost entirely migrated to an Ubuntu installation that I installed from the alternate CD, enabling full disk encryption from the beginning) computer, I relied happily on Flagstone drives. I still have one of their USB Freedom drives for backups. The login schtick is more severe; you get few chances and your data goes bye-bye if you screw up. However, I like the fact that they are a real product, not vaporware like some of the encrypted drives from major manufacturers. You can call them up, give them a credit card number, and actually get the hardware. If you talk to the home office in England, you'll converse with smart, helpful, courteous people. All in all, they're a joy to deal with. Downsides? Prices are high and capacities low, but that's part of the deal when it comes to certified hardware such as they sell. Truly irritating downsides? The documentation, unless they've revised it recently, is not all that it should be. Still, I don't hesitate to recommend them.

Is this really still accurate?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

re: http://www.joar.com/certificates/

I read your MAC OSX article/how-to.

What? Not one mention or link to information on GPG http://www.gnupg.com/

and/or PGP???

http://www.pgp.com/

I support and use the former and recommend the latter to my Microsoft locked-in friends.

What about enigmail http://enigmail.mozdev.org/for Thunderbird

or firegpg http://firegpg.tuxfamily.org/ for firefox?

Open your mind. .mac is not the end-all and be-all...

P.S. Note that this post is signed with firegpg.
- --
Bill Arlofski
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: 'email gpgpublickey@revpol.com for my public key'

iD8DBQFHFDNKcBKMMWOpTtwRAnvtAKCSio6bcxucHd+pMxemwtkb3hwF1ACg5f0E
wdrDjE0Jh0R9szqcerv0OOQ=
=nlx9
-----END PGP SIGNATURE-----

Um, no. One of the first things they did when after buying assets back out of NAI was to re-release the source code.

See http://www.pgp.com/newsroom/mediareleases/2002/sourcecode.html

You can download the code from here: http://www.pgp.com/downloads/sourcecode/index.html#dtsrc

Fabian's web page is in dire need of an update.

Um, no. One of the first things they did when after buying assets back out of NAI was to re-release the source code.

See http://www.pgp.com/newsroom/mediareleases/2002/sourcecode.html

You can download the code from here: http://www.pgp.com/downloads/sourcecode/index.html#dtsrc

Fabian's web page is in dire need of an update.

I don't understand what this post is about. This feature is fully documented on PGP's support website for customers. Saying this is only for big companies is not true in the least. On top of this you must know the password of the drive to even implement this feature. How is it a security risk? Your security is only as strong as your end user in this kind of scenario. An end user could just as easily give someone their password. We need to be careful in the security world when making allegations like this before knowing the truth. If you own a PGP product and have a support contract you can view the documentation here. http://support.pgp.com/

But ... PGP has a peer review, open-source process. They're just a commercial product, too. [In other words, it violates the terms of service for you to compile their source code and use it without licensing it.]

You could, you know, encrypt your data using something like PGP. There's also an older free version of PGP here.

The past few days alone have exhibited an increase in this sort of problem exactly (re: encryption). Why large companies aren't using encryption as a standard is something that needs to be answered. Consider the eBay case where on the 4 May 2007:

The latter being more prevalent in my opinion as a critique of the NHS computer systems is revealed only weeks (16 April 2007) before the breach.

Let's not forget the Los Alamos hard drive scandal, and the countless dozens of other thefts/breaches/losses etc.

Taking into account that I'm a /. user, I am also a professional photographer, and out of simple courtesy to the models that I photograph in revealing states, and also to any other client who has publishing rights to my photographs, I use whole disk encryption (PGP) which cost me (if memory recalls correctly) £85 or so, now up to £114 according to the site. A little expensive, yes, but certainly worth it considering site license discount (I'm ignoring admin, I know)? How many other breaches of data have been kept quiet because they didn't involve employees who could snitch to the press?

The corporations pay big money for licenses to Office, and their proprietary software systems. Why can't they invest in encryption?

• Openoffice.org (use word processor, spreadsheet, presentation, database, and similar applications)
• Picasa (view/edit photos)

Internet Tools

• FireFox (browse Web sites)
• Gaim (chat with users of AIM, YIM, MSN, IRC, etc.)
• Thunderbird (e-mail)
• Pegasus Mail (e-mail)
• Macromedia Flash Player (watch Flash animations within Web browser)
• Java Plugin (run Java applications inside Web browser)

Basic Tools

• 7Zip (compress/decompress files)
• EditPad Lite (edit text files)
• vim/gvim (edit text files--advanced)
• Adobe Acrobat Reader (view PDF files)
• PDF Creator (create PDF files)

Security Tools

• ZoneAlarm (firewall - detect unwanted Internet access)
• Avira Antivirus (detect/remove viruses)
• ADAware Personal SE (detect/remove spyware)
• SpyBot Search & Destroy (detect/remove spyware)
• HiJackThis (detect/remove spyware)
• Discombobulator (make Windows more secure)
• Shoot the Messenger (make Windows more secure)
• Unplug-n-pray (make Windows more secure)
• PGP (encrypt/decrypt files or e-mail for privacy) - see admin for more details

Advanced Tools

• Virtual CD-ROM Control Panel for Windows XP (mount ISO images as filesystems) from MSDN
• IMAPSize (manage/search/backup an IMAP mailbox)

No shit. My Vista Ultimate system uses nearly 1GB RAM at startup, and I don't have many services running or apps installed, since nothing I have works on Vista yet..

At work we decided that having a couple of developers running Vista from day one would the best way to ensure our compatibility. Sounded like a great idea till I drew that particular short straw...

The free trial is also hard to find, likely intentionally so.

http://www.pgp.com/downloads/desktoptrial2.php

It's fully functional for 30 days, then falls back to the functionality of the old PGP Freeware product, i.e. you can encrypt and decrypt files, windows, and the clipboard, and you can create, import, and manage keys.

So you have the option of taking credit for what you say when it turns out that you were right.

I only know of a handful of whole-disk encryption products that support encrypting the operating system disk:

- PGP sells a corporate level product called "PGP Whole Disk Encryption".

- SecureStar sells DriveCrypt Plus Pack

What else is out there that is trustworthy? (Heck, do we even trust that there aren't any weaknesses / or back doors in PGP or DCPP?)

My organization has been looking for a solution for this recently, and is leaning towards PGP Whole Disk Encryption http://www.pgp.com/products/desktop/professional/p gpwholedisk.html. One feature we like is the ability to do whole disk or simply folder encryption, when that is all that is necessary.

Anyone have experience, positive or negative, with this? Our testing has gone well on Win2K and XP so far...

The claim probably comes from this incident:
(quote)
A simulation of Colossus which Sale ran on a top-of-the-range Pentium PC took twice as long as the real thing.

or this:
If you wanted to program a modern computer to do what Colossus does, you'd need a 2GHz Pentium to match it.

Don't forget Colossus was massively parallel:
At 5,000 cps the interval between sprocket holes is 200 microsecs. In this time Colossus will do up to 100 Boolean calculations simultaneously on each of the five tape channels and across a five character matrix.

I love truecrypt, but what I really want is boot time encryption. Boot and the first thing you enter is a password, then the OS gets booted, be it linux or windows.

I know http://www.securstar.com/products_drivecryptpp.php and http://www.pgp.com/products/wholediskencryption/in dex.html claim to do this, but I need an open source solution.

Does anyone know of one?

What do you think of IRC, is that recorded?

The server admin or ISP can log all traffic (/msg, channel text, etc), and popular channels often have a bot that records and publishes all traffic as well.

How can I encrypt my emails so the person recieving can read them, but everyone else can't?

PGP and compatible tools. PGP Desktop has a free trial. There is also GnuPG, a free & compatible alternative, but the GUI might not be as polished. The recipient must also be willing to use one of these as well, and have set it up in advance of receiving an encrypted email.

There is also S/MIME, an incompatible standard. I believe Outlook supports it, but you have to get a certificate from a 3rd party for that to work (excepting setting up your own CA, whch is more work).

Maybe the news is that companies are beginning to realize it? If so, they also need to understand that there is a big difference between knowing that the threat exists and treating all your employees like potential criminals.

Here you will find a very interesting read about the subject. (quote: "This new trend is viewing one's colleagues as literally the enemy. I feel a need to rail against it because I believe it to be not only immoral, but destructive to business")

The article was about the future of tech and not about the politics. All of the "Was the President right?" and "Can he do this?" replies are moot.

The discussion of the future a decade ago was this:

http://www.pgp.com/

Simple.

This new discussion, here today, is about future of tech and the NSA, (with the President ignoring the Constitution of U.S.A.), as in how WE can block an abuse our liberties THROUGH tech...

Make no mistake... when the blessed son has the absolute gall to justify a complete dismissal of the law then we, as techs, in this age, have to get serious. Enough of the politics. I don't want ANYONE to be able to read my own private communication with someone else throughout modern communication methods. There was a utopia when a glued seal on a USPS envelope was enough. Checks and balances were in place... then came email, cell-phones, etc... each with it's own particular loophole. WE know this as techs. We fought back... are we fighting back enough in December 2005?

Give us some answers.

cheers

front

It seems nobody has said the obvious yet ...

Encrypt your private communications.

Use anonymous remailers.

If you actually get charged, they'll require you to give up your keys, but they won't be snooping at your E-mails behind your back.

pgp.com
gnupg.org

In other news, smart people can avoid being caught by doing stuff...

I mean, any dolt can PGP or GnuPG encrypt a message or just hand deliver messages. Things like wiretaps are good for the duller knives in the drawer. We should still use them to "grab the low hanging fruit" and look elsewhere to capture the rest.

If a person knows he's being wire tapped, he won't say anything incriminating anyway, and if the feds/cops don't get what they want over the phone, they'll just bug some offices instead.

Exactly. In that regard, it's like leasing a car. If you're the type of person who buys a new car every 24 months, you're better off leasing. If you drive a car until it costs more to repair than the value of the car, you're better off owning.

PGP software provides a pretty good example of how subscription licensing vs. perpetual licensing could work. PGP Website

From: The Pointy-hairiest of the PHBs
To: IT Engineering-ALL
Subject: 2006 Budget
i lovesh yous guys. u r the bestest engineeers n e where.

hey, check out this websit i found petty god piracy.
we need this!!!111 how sun cn u turn it on?

ceo

Which immediately leads me to thinking that somebody doesn't know the meaning of "non-repudiation".

This is the first level. Hard drive is encrypted from the word go.

This is the second level. Everything on the hard drive from boot onwards is encrypted in software.

This is the third level. Everything you need to store in encrypted containers you can quite easily. You can also encrypt files and then store them in encrypted containers to add a fourth level.

Using all of these, no hack will open the system to unauthorized use. You need the physical and software keys and the password. Without them there's no chance of recovery in this lifetime with any computer technology now or forseen within the next century that will break all of it without the entire resources of the planet being turned to the job for a period slightly in excess of the sun's remaining lifespan.

You can also get hardware encrypted external drives as well and use multiple layers of software encryption on them.

To address the main post, like who didn't know the best way to gain access to a system was to physically pwn it? I mean, really...

(It's just that with prudent countermeasures and the machines not being left on and requiring all authentication for decryption from start to finish, that point is moot.)

Not to mention that a truly secure card reader would cost a lot more than $25. $150 would be much more realistic. To be even somewhat secure, it would need to at least have a display and its own network connection, which adds quite a bit to the cost.

No a `fully secure' card reader costs $25 today and expect prices to keep falling as demand goes up. To be somwhat secure? You still don't seem to get the idea of the signing operation of a transaction done on a card. I suggest you read up on how a JavaCard works.

Customers generally don't need to ship stuff to 20 different addresses, and it's not difficult to call your bank and have them add another authorized address. Most places will still ship to an alternate address, they will just call you first to confirm. Having to use special card reader hardware would be much more of a hassle.

No customers don't have to ship items to 20 addresses, but I'm not about to to register all my acquaintances' addresses to the credit card, just because I want to send them gifts directly.

Your system has exactly the same problem. There is no foolproof way to identify a person remotely. Plus, your system is now susceptible to spyware: put some software on the customer's machine to hijack the card reader and you can do what you want with the credit card. If anything, it's LESS secure.

I believe you're just trying to knock me here, rather than actually first read up and understand how the system works. Read up on how a Java Card works. I'll explain once more for your benefit. The cryptographic signing operation takes place on the card. Your private key is stored on the card and there is no way you can extract the key from the card. You can only present a transaction to the card and have it signed, and retrieve the signed transaction. The signature is only valid for one transaction, done by a particular vendor only, because the signed data contains the transaction ID, the price which it's paying. The signature-request which is supplied to the card contains the price the person would pay for, the vendor details and the transaction ID. This is displayed *on the card* before a customer makes a payment by choosing an option *on the card*. These cards will not be significantly more expensive to manufacture in quantity. Remember card sized calculators? That was back in 1980.

No the system does not have the same problem, nor is it susceptible to spyware. You can hijack a card reader, but you can't hijack the card itself which needs to do the signing after reading the users' input *on the card* which is only powered by the card reader, which also provides the reader interface for communicating with the PC. The card reader is otherwise stupid. No other software on the PC has the private key to do this signing. Even if you were to tap the wire communication, you still cannot fool the system. If you do not follow this, I suggest you read up on even user land items like PGP Corporation's introduction to cryptography which should be reasonable for a newbie to follow. Read on digital signatures and how they are not susceptible to man/monkey in the middle attacks (when the card's public key is known and trusted by the bank), which is exactly what you're claiming by hijacking the card reader.

Why isn't the data encrypted with some sort of strong schema during the transit?

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.

If I take a Maxtor 300GB portable usb drive, plugs it into my pc, loads up with movies, and ships of to a friend? Huge capcity, overnight, or in a few days at least. And besides, ??AA has no real chance of uncovering such transfers.

Well, realistically. What about VPN? Having hard encryption easily obtainable, it should be trivial to share files with friends. If a key is signed by a large enough number of friends, trust it. Otherwise, discard. If a p2p net included strong cryptographi, and trust levels and/or ratings to users, it would be far more difficult for ??AA to eavesdrop those connections. At very least, they'd have to build up a trust, which would probably mean sharing...

This is interesting - do you know of any Sendmail milters / other service that can digitally sign all outgoing emails...

See parent post. PGP Universal seems to indicate that it's Sendmail-compatible.

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).

Speaking of the "web of trust" concept - I've always viewed it as trusting keys that you've personally verified with the owner, trickling out slowly as networks grow.

PGP uses the word "trust" to mean two different things, which has caused me (and I suspect others) some confusion. The first definition is "trusting" that they public key you received is actually the public key of the person whom you wish to communicate with. I've seen this type of trust referred to as the key's verification/validation, as in "Yes, this has been verified as being Alice's public key" or "This is Alice's valid public key." Although I don't think "verified/validate" is the best way to describe this, but I think it is better that "trust" since that gets confused with the second definition.

A key's verification/validity is marked by you digitally signing it (with your private key).

The second definition of "trust" is in how much you trust another person to declare third person keys as being valid. How much do you "trust" someone else to verify another's public key? "Alice has signed Bob's public key. I know Alice is very security conscious, and is adamant about personally verifying key fingerprints before she will digitally sign a key. I trust her, so if she says this is Bob's key, it must be!"

The amount of trust one can hold in a person's key can vary between "not at all" to trusting it as much as their own private key.

When I submitted my key to this story's server, though, I got a message at the end telling me to trust the server's verification key, and thus all keys verified by the server.

I don't really have a good concept of how this stuff works, so I'm wondering - is that a good (safe) idea?

If what you wrote is true, then no, it is not a good/safe idea. In fact, I'm very surprised that the PGP people would post such a message.

After reading the PGP Global Directory description and the Key Verification Policy, it is clear PGP Corporation is not verifying/validating who the people are behind the e-mails. ("...PGP Global Directory allows users to manage lost keys...") For example, I can setup the e-mail address "LinusT@hotmail.com", create a PGP keypair with that e-mail address and "Linus Torvalds" in it, and send it to the server. Although the server will verify that that e-mail address is the owner of the key, it does not verify I am really Linus Torvalds.

Since no true verification/validation is going on, it would be inappropriate to "trust" the server keys as having verifying/validating all those user keys. I am very surprised, especially in light of that Key Verification Policy, that the server would give you that message after you submitted your key.

Speaking of the "web of trust" concept - I've always viewed it as trusting keys that you've personally verified with the owner, trickling out slowly as networks grow.

PGP uses the word "trust" to mean two different things, which has caused me (and I suspect others) some confusion. The first definition is "trusting" that they public key you received is actually the public key of the person whom you wish to communicate with. I've seen this type of trust referred to as the key's verification/validation, as in "Yes, this has been verified as being Alice's public key" or "This is Alice's valid public key." Although I don't think "verified/validate" is the best way to describe this, but I think it is better that "trust" since that gets confused with the second definition.

A key's verification/validity is marked by you digitally signing it (with your private key).

The second definition of "trust" is in how much you trust another person to declare third person keys as being valid. How much do you "trust" someone else to verify another's public key? "Alice has signed Bob's public key. I know Alice is very security conscious, and is adamant about personally verifying key fingerprints before she will digitally sign a key. I trust her, so if she says this is Bob's key, it must be!"

The amount of trust one can hold in a person's key can vary between "not at all" to trusting it as much as their own private key.

When I submitted my key to this story's server, though, I got a message at the end telling me to trust the server's verification key, and thus all keys verified by the server.

I don't really have a good concept of how this stuff works, so I'm wondering - is that a good (safe) idea?

If what you wrote is true, then no, it is not a good/safe idea. In fact, I'm very surprised that the PGP people would post such a message.

After reading the PGP Global Directory description and the Key Verification Policy, it is clear PGP Corporation is not verifying/validating who the people are behind the e-mails. ("...PGP Global Directory allows users to manage lost keys...") For example, I can setup the e-mail address "LinusT@hotmail.com", create a PGP keypair with that e-mail address and "Linus Torvalds" in it, and send it to the server. Although the server will verify that that e-mail address is the owner of the key, it does not verify I am really Linus Torvalds.

Since no true verification/validation is going on, it would be inappropriate to "trust" the server keys as having verifying/validating all those user keys. I am very surprised, especially in light of that Key Verification Policy, that the server would give you that message after you submitted your key.

That's what Sender Policy Framework and DomainKeys are designed to stop.

The expense of verifying real-world identities is why there aren't free SSL certs out there...

Actually, CAcert gives out free SSL certificates, if you can successfully interact with their web of trust.

Now, the PGP Global directory could certainly be subject to man-in-the-middle attacks if a malicious third party can actively read and respond to at least some of your incoming e-mail. That party could upload a bogus key and respond to the confirmation-request for you, then read things sent to you. Of course you'd find out when you saw strange unreadable signed messages coming to your account...

I also don't like the essage I got from the beta keyserver after I submitted my key today:

To ensure that your PGP software trusts keys verified by this directory, you must download and trust this directory's Verification Key.

Download the Verification Key

After downloading, import the Verification Key into your PGP software. Then, sign the key with your key and mark it as Trusted. Please see the documentation for your PGP software for specific instructions on trusting a key.

The directory seems like a highter-quality way to get keys, but I don't want to trust it *that* much; on the other hand, the Key Verification Policy seems to cover the same concerns that have been expressed here.