Slashdot Mirror
GPG vs. PGP?
OctaneZ asks: "What are the relative merits and drawbacks of using Gnu Privacy Guard vs. Network Associates' PGP. I am not referring to the fact that GPG doesn't use any restricted implemtations or algorithems; or that GPG was not affected by the recent PGP hole; but other more everyday issues. How is interoperability between the two. As well as integration into common applications such as Eudora in windows and others, possibly PINE, in LINUX. Could this be deployed such that the learning curve of transitioning users from PGP to GPG is not too steep? I am a strong beleiver in encryption, and have used PGP for a very long time, however I would prefer to use an OpenSource/Non-restricted program; however the usefullness of said program, as well as the security takes precidence, at least in my book."
If you're in a windows environment, there's really no choice -- pgp is by far the more integrated and useful solution. If you're using a Windows mail reader, then go for PGP for Windows.
In a unix environment, you'll find either to be roughly equivalent. Some minor differences I've noticed since making the migration to gnupg:
- gnupg has a nifty feature that makes it automatically grab a key off the keyserver if I read a signed email by someone whose key I don't have. This is nifty.
- gnupg apparantly doesn't have a way to retrieve a key from the keyservers by email. This is a real pain in the ass. With pgp, you can just import the key for "nugget@slacker.com" and if there are keys on the server for that email, they'll be imported. gnupg requires you to know the key ID (like E43C5FC3).
- The pgp command line syntax and commands are cryptic and obtuse
- The gnupg command line syntax and commands are unnecessarily verbose and will push you over the edge with your carpal tunnel if you're doing much manual work
- PGP has the edge for application integration, but this is rapidly changing. gnupg works fine with mutt, which is the mail reader you want to be using anyway, so it's a moot point.
:)
- gnupg's key management is vastly superior to pgp's in both conveying key-management information as well as allowing access to key-management functions.
Plus, there's a nifty GUI for gnupg that's usable but which is called GPA (It's inIf you're already using pgp, the differences aren't enough to justify conversion, but if you're just starting out -- gnupg seems to be the most viable option. And, of course, mutt is too good to believe.
The learning curve for either is the same, mainly just getting past public key crypto concepts and mechanisms. Wrapping your brain around "public key" and "private key" and the difference between "signing" and "encrypting" is well over half the battle.
As others have pointed out, your objections to mutt are all basically invalid. A couple of things I don't think others have touched on:
/proc and readability - if someone can read /proc for your process they've either hacked your account or they have root. In any case, if they've done either of those there's nothing stopping them from using any of a dozen other ways to get your password (trojanned gpg/pgp binary perhaps?). Bottom line: If you ever type your password in, you're implicitly trusting that machine.
* "protected memory"? You mean you want to mlock() the page with your password on it? That would require mutt to be suid root since only root can wire pages in memory. Hardly seems like a good idea.
*
People keep mentioning that PGP is free for personal use, but have you checked the prices for commercial use? I just got a quote for the PGP SDK. They charge 6% of your companies gross revenue! Seems like a good reason to use anthing else.
Has anyone written a tool that inspects a public key received by a keyserver and reports if an ADK is in use and whether it's been tampered with by adding the ADK outside the signed key region?
That would seem like a good way to prevent any 'infection' of our keyrings by tampered ones
cat newkey.asc | adkcheck | pgp -ka
where 'adkcheck' would strip any 'tampered' keys from its input and holler about it on stderr.
---
"Central clearinghouse" PKI is what SSL uses. SSL certificates are signed by Certificate Authorities (CAs), such as VeriSign. CAs are trusted entities who verify an applicant's identity before issuing them a certificate. A certificate is the same as a public key except that it has more information about the owner - usually the x.509 Distinguished Name which consists of a "common name" (CN), "organizational unit" (OU), "organization" (O), "locality" (L), "state" (S), "country" (C), and sometimes email. For instance, Microsoft's DN is CN=www.microsoft.com/OU=mscom/O=Microsoft/L=Redmon d/S=Washington/C=US. How do you know which CAs to trust? Web browsers typically have a built-in list. Anyone can act as a CA, but when someone views a website which is using one of that CA's certificates, the user's web browser should (and most do) display a warning. Go to Fortify's SSL test page and my HTTPS website. Fortify's certificate was issued by Thawte (who I believe is now owned by VeriSign), a widely-known CA whose certificate is in most/all browsers. My certificate is signed by the "Zevils CA", which doesn't really exist. Your browser should display a warning when accessing the zevils site but not when accessing the Fortify site.
The other popular method of PKI is known as the "web of trust." This is what PGP and GPG use. If you know someone in real life, you have proof of their identity (such as a driver's license), and you both have GPG/PGP keys, you should sign each other's public keys and upload the signed keys to the keyserver. Here's how the web of trust works (with help from the GNU Privacy Guard Handbook):
Alice knows Bob in real life. They both use GPG. Alice knows with absolute certainty that a certain key is Bob's key, and that Bob is who he says he is, so she signs Bob's key with her key. Alice and Bob discuss PKI every day at lunch and Alice knows that Bob has excellent judgement on when to sign a key, so she tells GPG that she trusts Bob's signature on a key as much as her own (she can also give Bob marginal trust or no trust - see GPG documentation for details.) Bob has signed Charlie's key. Thus, Alice trusts Charlie's key. The web of trust, at least in the GPG implementation, is quite flexible and does extend to a depth of more than one. See the GPG handbook for more information.
Of course, PKI is not a magical security fairy that sprinkles security dust on your keys while you're asleep at night. Bruce Schneier and Carl Ellison have written an excellent paper, Ten Risks of PKI (Computer Security Journal, v 16, n 1, 2000, pp. 1-7)
Well, in my state there's a registry of trusted certificate authorities. If BillC has his key in a cert. signed by one of these authorities, and it's the highest-confidence-level cert, then he had to go in person and sign papers and give up authentication just like at the bank. Of course, he could give his key away, just like Mordecai could spend his new car money on drugs (if he were to get a bank loan instead of on-the-spot).
The digital signature has the ability to convey that a person knows the secret to a specific key, and that they signed the document. There must be another mechanism (like a signed certificate authenticated by a trusted CA) to connect that key to a person, and a deterrent (like liability) to prevent that person sharing the secret. Again, process, not technology.
Lots of people have specified this (broken clients exist, bad people exist) as a reason to create v3 keys using PGP 2.6.2 and "accept no alternative".
This problem (attacker compromises friendly user, intercepts message) is ALWAYS present in a PGP system.
To mitigate it, EVERY person who communicates with you must take steps to ensure that they have a "known good" version of PGP, a secure working environment (preferably unwired) and a strong passphrase.
Note that, as always, Mallory risks giving everything away for the attack. Smart users would notice (even in PGP) that something was odd about these "stealth ADK" keys, there were so many tell-tale signs.
However, most of us don't know that many smart users, and in that case, Mallory could equally replace their copy of PGP, insert a forged key for your name, steal the plaintext, or compromise the system a million other ways.
Only the most paranoid groups could possibly use PGP without significant risk in the face of a determined and resourceful enemy.
Fortunately, most of us don't have such enemies, and can relax our deathgrip a little.
Now that RSA is public domain, will GPG be adding the formerly-proprietary RSA algorithm?
11*43+456^2
In mutt you can wipe your PGP passphrase from memory using Ctrl-F.
But who allows other people on their machine, anyway? I thought multi-user just means more accounts for *me*.
"Life has improved immeasurably since I have been forced to stop taking it seriously." - Hunter S. Thompson
Mainly, PGP rolls off the tongue better than GPG does.
My big gripe is that there's no integration between GPG and Netscape (what I use for email), but that's not the fault of GPG... :-(
--
Your Servant, B. Baggins
Now, for some reasons not to use GPG:
To finish, I'll mention some software that can use GPG:
Hope that helps, in some way or another.
Why are people signing their e-mail with PGP/GPG?
When I was young, the advice from grown ups was "do not sign anything you don't have to, be it a contract, a letter, a memo, anything. If you sign it it means that you meant it, if you don't is just idle chatter".
So, /.ers out there: how about it, why do you sign your e-mail letters?
Another plus for GPG in a unix environment is that it was designed to be used in unix. PGP works fine in unix of course, but its behavior can be a little strange since it was originally made to be used under DOS.
For example, pgp -kxa will prompt for the file it should write the key out to. gpg --export -a simply dumps the key to stdout, a behavior a unix person will find much more intuitive.
--
see shy jo
The more recent mutt distributions come with example .muttrc files to use both PGP and GPG. These make the task of configuring mutt to use encryption very easy. The debian package of mutt installs these into /usr/share/doc/mutt/examples/
If you're building from source, you should be able to find these example files in the contrib/ directory. They have intuitive names like "gpg.rc", "pgp2.rc" and "pgp5.rc"
This has been mentioned elsewhere, but it bears repeating, since you're looking for what the "most common issues" are. (that's a note to moderators, that in a situation like this, "redundant" isn't a viable moderation). I use Eudora for MacOS, and PGP integrates BEAUTIFULLY with it. So far, there's not even a GPG for MacOS, and I certainly doubt it'll have the nice integration with Eudora I currently enjoy. And that's not to say that I don't want to use GPG -- I do. Near as I can tell from lurking on the -devel list, I can't even see that someone is TRYING to do anything on that front. Until then, I'll suffer with my nice integration that PGP provides me. :(
D
The pgp commercial plug-in for Outlook is a no brainer. It's just so damned easy to use, I have yet to see anything as pleasant as that on *nix. You compose your email, then, from the pgp menu, choose encrypt now; voila! It's done. It's too bad that Mozilla or Navigator never had that whole crypto plug-in concept, 'cos the interface would work on any platform. I'm not against CLI, but there's times when it gets in the way, and I'd have to say that sending and recieving email with Outlook beats all the stuff I've tried. Now, if someone plugged GPG into the Mozilla mail-eater client, I would sit up and take notice BIG TIME.
You're still missing the point. Certificate authorities don't really solve much of anything, if anything at all.
Let's say that I go to Trusted Certificates, Inc., "Where We Make Even Our Mother Show Six Forms of ID". I register my key, and lo and behold, I have "verified identity". Anyone who wants to can check my signature with the CA and discover it's valid.
Guess what? That's still not enough.
Let's say that I want to steal $10,000 from the bank. First, I need a conspirator--I hand over my keys, then go on vacation in Aruba. While I'm in Aruba, sipping mai-tais on the beach, my conspirator is posting innocuous messages, as me, to newsgroups.
I come home and send an email to the bank, asking it to transfer $10,000 from my account to the First Bank of Never-Say-Anything. The bank checks out my keys with the CA, and lo and behold, it checks out. Since they've "verified" that it's really me, they make the transfer. (In reality, they haven't verified anything--only that someone who knows a specific string of bits asked for a transfer.)
At that point, I raise holy hell and scream "What the hell is going on here? I didn't authorize anything!" The bank can't get the money back from the First Bank of Never-Say-Anything, and so they're stuck trying to prove that it really was me who sent the authorization.
At that point I just have to point out the various postings to alt.sex.hamsters, which were signed with my key. "Look! I was in Aruba, sitting on the beach drinking mai-tais! Someone compromised my keys!"
... and at that point, the only way, the only way, for the bank to show that I'm lying is to find my conspirator. And in the meantime, I get to repudiate every single message that bears my signature ever since the compromise date. The $10,000 transfer? I didn't do that. Sending incriminating emails to government officials? Wasn't me. This, that and the other? Unh-uh.
Compare this to a real signature, which--by its very physical nature--possesses forensic value. It isn't just a string of bits; it's evidence, and oftentimes is enough to get convictions in court. Real signatures are also not wholly invalidated simply by the appearance of forgeries, as opposed to digital signatures. If I send a paper letter to my bank authorizing the $10,000 transfer, they'll have a handwriting expert compare the signature to the signature on file. They'll compare everything from the shape of letters to the inks used in the paper. And even then, they won't trust it--they'll have a bank teller who knows me well give me a call and ask me, "Do you really want to do this?" If the bank teller recognizes my voice, then the transfer goes through.
We have extremely robust identification and verification mechanisms in real life which are composed of interlocking parts. We don't have anything like it in electronic life yet. We have things that bear a strong resemblence, but the devil is in the details.
Digital signatures are not real signatures. They're different beasts which serve a different purpose. As long as all parties involved are committed to using digital signatures honestly, digital signatures work.
The instant someone realizes that there's money to be made by false repudiation, things change.
Yes, you can interoperate PGP and GPG in that GPG can be made to use PGP-compatible DH/DSS keys. But, there is a lack of support for PGP RSA keys which is a fatal flaw at this point. From what I've read, I think there are unofficial and still-buggy source code patches available from Europe for RSA compatibility--though I may be wrong--but overall the only way to maintain near-100% compatibility with most PGP users is to make RSA keys.
The only versions of PGP which don't support RSA keys are early and now-defunct versions of PGP Freeware 5.x. Other than those--which can easily be replaced by a later international version or later freeware version--all PGP incarnations can use RSA keys. This is important because many of the more privacy-conscious people are still using good ole version 2.6.x, which cannot use any keys but RSA.
This especially comes into play if you ever want to use the Cypherpunk remailer system--there have always been some cypherpunk remailers who don't have support for DH/DSS keys, but now almost all of the remailer operators who used to support DH as well as RSA have revoked their DH/DSS keys and switched to solely having RSA Type 3 keys produced by PGP 2.6.x and thus invulnerable to any ADK issues.
So, PGP is a necessity for compatibility with Type 1 (Cypherpunk) remailers. More than that, the most privacy conscious individuals are still using PGP 2.6.x for their own private correspondence, so you won't be able to communicate with those stalwarts via GPG.
That being said, now that RSA is unencumbered I'm sure GPG will be incorporating full RSA key support. But until then, it's frankly unusable unless all the other people you privately correspond with aren't using RSA, and forget about remailers unless you stick with Type 2 Mixmasters only--which are vulnerable to the NSA thanks to their short key sizes, according to one of the Mixmaster developers Lance Cottrel.
And BTW, the new version of PGP which supposedly solves the ADK issue really doesn't--it won't decrypt to the ADK if present, but it also won't notify you of the presence of an ADK--so you'd never know if someone tried to bug the key in question. That sucks.
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
Am I the only one who thinks passphrases have only slowed down pgp/gpg acceptance? Without passphrases, decryption could be completely handled by the MUA without user intervention, thus making the encryption totally transparant. With passphrases it's a royal pain in the ass to have to retype your (secure, and thus long/using weird chars) password every time you restart your MUA. (Which I do a lot, I just kill it and relaunch if I need it. mutt all the way.). You may say 'But that would mean if someone cracks my box they've got my key!'. YES. tough luck. You won't detect a sufficiently sophisticated attacker anyway, so he might as well just snag your passphrase as you type it in next time you use your key.
I think I'm going to remove the passphrase from my key now, unless anyone has any good reasons why not...
Wow! Just downloaded GPG last night.
And I have this to say about the command-line syntax: although it didn't say it anywhere, specifying the full and LOGICAL names for operations makes it so that there's much less chance of a screw-up. I could tell this right off just by looking at gpg --help. In a security application most of all, this is quite critical, and most of us cmd-ln usrs are used to typing stuff fast, and sometimes making mistakes... well, GPG makes you verify just what you're doing before you do it. A big plus in my book!
-----
As a person who has written a couple Perl modules to handle both PGP and GnuPG, most recently GnuPG::Interface, I can honestly say GnuPG is a much, much more well-designed program for those who want to interact with it on a higher level.
GnuPG has a great system of interaction via pipes, which are the means to to pass in the passphrase, get status output, interact with terminal-ish interfaces, and much more. To know more about these, look up status-fd, passphrase-fd, and several others in the GnuPG manpage.
GnuPG also has a well-thought-out syntax for interaction. Each option has a long, useful name, and the more-used ones have useful shortcuts. Also, GnuPG uses cool things like command-completion, so that you don't have to type all of --list-keys; you can just type --list and it will work fine.
PGP, on the other hand, has commands like -a meaning armor, and -ka meaning add-key, which is confusing, if you are used to bundled parameters.
Yes you are correct my original statements where unfounded and I apoligize for spread misinformation.
However with mlock is it not possible to mlock the page and then immediatly give up the root permisions?
If you liked this thought maybe you would find my blog nice too:
Well, I think the scenario you describe could be done the same way with physical signatures. You could teach someone to forge your signature convincingly, especially if you have a loose scribble of a signature like many do. I really think you're overestimating the forensic value of a paper signature; they're only rarely used in court to convict. It's not hard to forge a signature convincingly, and further a person's signature can look very different depending on their mood, their writing angle, distractions, etc. Have you ever signed something and looked at it thinking, "that doesn't look like my signature!" I know I have.
And yes, a given digital signature is rendered invalid if a forgery appears. So are physical signatures -- if you find out someone is forging your signature, you sure better tell everyone you know so they can verify that things came from you!
Fraud has always happened and always will happen. There are no plug-in solutions for fraud. Real signatures have failed miserably time and time again, and digital signatures won't solve it either. The only solution for fraud is constant examination of the facts. Why do you think your credit card company will call you if you make an odd random withdrawal from an ATM that you haven't used before?
Digital signatures are a tool, and used properly, they convey numerous advantages. Trusted blindly, they are a trap; just like paper signatures, trusted blindly, are a trap. Certificate authorities do not solve this; neither does having your signature written on the back of your credit card. The purpose of digital signatures is to make forgery more difficult in a world where every letter comes printed with the same kind of printer and on the same kind of paper. Just like real signatures.
I have seen the future, and it is inconvenient.
I don't mean to flame but I can't help responding. I'm using windows/IE as I write this, and I use SuSE (daily) and Irix (sometimes daily)as well. MS Windows is not the "useability" king the myth would have one believe. Gnome or KDE both excell at fundamental functions such as virtual desktops (which is too slow to be usable under windows) and configurability. I use windows but I also jump through the MS hoops to do so. The constraints of which I speak are *lack of feature* obstacles.
Apologies for responding to an obvious bias.
Your face, maybe... your retina, certainly (though that's quite useless for strong security, unless someone can make an entirely consistant, sufficiently unique digital fingerprint of it which may be one-way-hashed).
Neither of these, however, is truly secure in the way that a challenge/response protocol is; someone observing the information coming off a face scanner or pen can then play back that data later (perhaps slightly munged) and pretend to be you. Challenge/response doesn't have these issues.
The rubber hose thing _is_ an issue, of course. If you anticipate that sort of thing being an problem, though, and your attacker is after a decryption key rather than a signing one, you can use stenography and other such fun techniques to hide the data.
GPG plays nice with email to/from my coworkers who are mostly PGP for Windows users (using everything from Eudora to Outlook). And I've been able to use my old keys generated via PGP 5.x (on a Windows box).
GPG, pgpenvelope, and Pine make an excellent combination.
Umm...you might want to read the documentation that comes with mutt. There is a macro in /usr/local/doc/mutt/PGP-Notes.txt that allows old-style clear-text PGP signatures.
.muttrc or wherever (could require some fiddling, I don't use these clear-text signatures myself):
.muttrc files, which is where these came from. Good luck.
For gpg, try this in your
set pgp_clearsign_command="gpg --no-verbose --batch -o - --passphrase-fd 0 --arm
or --textmode --clearsign %?a?-u %a? %f"
Check out mutt.org for more details. There is a section linking to users'
If everyone were in the habit of signing their documents, forging an E-Mail from someone would be a lot harder. Recent fraudulent stock market manipulations would have been a lot more difficult (What's this? A press release saying that 4th quarter earnings are going to tank? It's not signed... they ALWAYS sign their press releases. I'll call them before I do anything...) Several companies would not be having to recover from having their stocks tank now. If only for that reason, it'd be a good thing.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
They interoperate seamlessly with the exception that I couldn't import my ultra-huge GPG secret key into PGP.
Did you try one of the CKT variants?
--
-=DaveHowe=-
...is that the higher the learning curve is, the more difficult it is to convince someone they need something in the first place.
--Perianwyr Stormcrow
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
That's silly. You simply don't want an MUA setuid root. PERIOD. How many security notices have you seen where a program doesn't give up privs properly? More than I can count for sure. The lesson is that unless you have a really really good reason for it, an app should not be setuid anything. Not trusting swap space on a machine isnt' a good reason - as I noted before, if you don't trust the machine you're typing something into, there are already tons of other ways to get your password.
Now I've got a lot more trust about the robustness of mutt programming than, for instance, pine (*gag*), but I still wouldn't want it setuid root.
Just the fact that GPG is open-source software is enough to choose it over PGP if you use pine.
that's an interesting statement, since pine is released under a restrictive license. they don't allow distribution of binaries from patched source.
--
While it's true that said cracker could install a keyboard sniffer and pick up your passphrase anyway, at least you've got half a chance of detecting him before that happens if you keep your passphrase on your key.
I use MD5 passphrases for all my login accounts now, too. My root passphrase is two paragraphs long!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Anyways, as I was saying, there have been a bunch of people complaining about getting software to run on different machines. Now, I know this is a bit of a utopian view of Java, as I'm well aware of the problems of "Write Once, Run Anywhere", but surely the use of something like Cryptix 3.1.2 alongside a standard such as JavaMail would be a good basis for dealing with all these problems. The Cryptix code has interoperability with PGP 2.x (which may not be enough for everyone, but it shows it's been moving in the right direction), and it links in with the cryptography hooks that Sun has defined. As for JavaMail, well, that speaks for itself.
Difference in detached signatures -- I'm not sure what changed, but it broke Eudora's verification on the remote end, which verified the detached PGP message fine, but refused to deal with the GPG one. Also, signed-and-encrypted messages from GPG that look like a single block seem to appear as detached-signature-inside-encryption to some Windows programs (this latter may have been user error on the other side, as it went away at some point).
Difference in the treatment of newlines at the end of clearsigned messages. GPG doesn't add one (deliberately, I'm told, to match the OpenPGP standard), and PGP does. This may break some scripts that are expecting a newline before the signature marker no matter what the situation.
Even when using the RSA plugin, GPG refused to create RSA keys. That may be about to change, and it may have been at least partially the result of a bug. I was told on IRC today that GPG key generation suffered from brokenness.
As it currently stands, have three PGP programs in use on my machine -- PGP 2.6 so I can create v3 RSA keys, PGP 5.0 to get around some of the problems mentioned above, and GPG 1.0.2 that I've patched to remove the RSA warning and announcement of system type in the version string. If you are planning to use GPG, I heartily recommend keeping those other two around as well.
UHM?
By this argument, a paper signature is meaningless because all it proves is that someone ran an ink producing device over a piece of paper in a certain pattern.
A pattern which, oddly enough, can easily be represented as A SEQUENCE OF DIGITS and in fact, is FAR EASIER to forge, since this sequence of digits is represented in its ENTIRETY on EVERY SIGNED DOCUMENT!
On the other hand, with a cryptographic signature (as opposed to a plaintext sig like a handwritten one) the sequence of digits is NOT expressed in the signature.
Please, actually bother to read one of the books that you cited.
I have seen the future, and it is inconvenient.
They interoperate seamlessly with the exception that I couldn't import my ultra-huge GPG secret key into PGP. Since the department wanted one department wide secret key, this was a bit of a problem, but taking a key from PGP to GPG worked fine, so we just did that.
As far as mailers go, VM for Xemacs is the obvious choice in UNIX. mailcrypt adds a menu entry which is handy for those lesser used functions and people not yet familiar with its keystrokes. It handles mime, has a really cool citing engine (Supercite, or you can write your own) and BBDB is really ultra-cool for address book handling. AND it does xface, which is just ultra-spiffy.
Given all that, if you're doing Windows it's probably worth paying for PGP. Outlook integrates with it well (I hate myself for knowing that) and the extra polish is worth the money. You're used to paying for software anyway.
If you're doing UNIX, GPG is probably the way to go. The UNIX PGP doesn't have all that extra polish anyway and is nastilly encumbered, even without the RSA patent. GPG avoids all that and integrates as well as possible with most mailers (And exceptionally well with vm.)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
You don't really need scripts or anything to integrate gpg with pine. Just edit the pine config in the nice userfriendly menu to pipe stuff with a leading -----BEGIN PGP to gpg, and add a send filter of gpg --clearsign to sign mail you send.
/usr/local/bin/gpg
/usr/local/bin/gpg --clearsign
For anyone who actually wants to do this, it's:
display-filters = _LEADING("-----BEGIN PGP ")_
sending-filters =
F0 07 C7 C8
It seems to me that the encryption could be much more transparents over IM as well. You have a central place to store keys for one thing. I really wish that ICQ would stick pgp or something similar in with the download.
Digital signatures are far more secure than real signatures. Below, the primary advantages:
1. Digital signatures verify that a document has not been altered since the point of signing.
2. Digital signatures are much, much more difficult to forge than real signatures.
As for #1... well, it speaks for itself.
As for #2, you can come up with something that looks an awful lot like someone's physical signature just my looking at a document which they've signed. Digital signatures have no comparable attacks. I assure you, it'd be much easier for some master forger to make a signature consistant with those off the records of the documents/checks I've signed in the last several years than for an attacker to break into my computer, steal my private key and determine my passphrase -- or, ever more difficult, retroactively determine a private key after the real one has been decomissioned and destroyed.
Digital signatures are every bit as unique as physical ones; unless you're signing the exact same document, one won't look the same twice.
As for the court's-satisfaction thing, there are laws (in place and in process) to handle that. And as for a physical signature proving that *you* did something... trust me, given a few grand and a suffiently large bank of samples, I could hire someone to forge a Handcock even you couldn't catch. You just can't do that with digital sigs.
How about taking that passphrase and printing the bar code on a card. Anytime you need it, just swipe it in with CueCat. You could then use a very random passphrase that no-one could crack. The down side is that your passphrase is written down on a sheet of paper as a bar code... Keep it close to you.
There are a number of scripts available to integrate both PGP and GPG into Pine; among them are pgpenvelope and pinepgp. There's also a little wrapper script out there called pgpgpg that allows you to use pgp syntax with gpg - I'm sure this would do wonders for the learning curve. IMO, though, if you want a really good MUA with great GPG support, mutt is the way to go.
Mike Markley - *NIX Sysadmin and all-around geek - finger for PGP key
Well, it can use PGP 5.0+ keys, giving decent interoperability (most people have pgp 5+ now as it offers significantly more secure encryption).
As well, according to the GnuPG website gnupg.org:
GnuPG is not vulnerable to the faked ARR (aka ADK) attack as PGP 5 and 6 is. The reason for this is that GnuPG does intentionally not handle those "additional recipients requests". BTW, those Big Brother packets are not defined in the OpenPGP standard - they are a proprietary PGP extension.
Also according to gnupg.org, these are the GPG features:
Full replacement of PGP.
Does not use any patented algorithms.
GPLed, written from scratch.
Can be used as a filter program.
Full OpenPGP implementation.
Better functionality than PGP and some security enhancements over PGP 2.
Decrypts and verifies PGP 5.x messages.
Supports ElGamal (signature and encryption), DSA, 3DES, Blowfish, Twofish, CAST5, MD5, SHA-1, RIPE-MD-160 and TIGER.
Easy implementation of new algorithms using extension modules.
User ID is forced to be in a standard format.
Supports key and signature expiration dates.
English, Danish, Dutch, Esperanto, French, German, Japanese, Italian, Polish, Portuguese (Brazilian), Portuguese (Portuguese), Russian, Spanish and Swedish language support.
Online help system.
Optional anonymous message receivers.
Integrated support for HKP keyservers (wwwkeys.pgp.net).
Yeah. That's it. There's decent integration with GNOME, so try it out.
Forgot to mention in my above comment, both GPG and recent versions of PGP conform to the OpenPGP standard (RFC2440 IIRC). As long as you're not using proprietary features, interoperabability should not be a problem...
Mike Markley - *NIX Sysadmin and all-around geek - finger for PGP key
PGP and GPG interoperate nicely. I use GPG for a project at work that requires a good API to the encryption pipe, and GPG has that. The resulting files are emailed and transparently decrypted by NA's PGP. The key files are also entirely compatible.
Now, I can appreciate the desire to do things Right. And I applaud the developer's dedication to a standar that, apparently, he was involved in creating. But by forcing this format, it made Mutt incompatible with my environment. Mutt went. I was sad to see it go.
Maybe I was missing a finer point in configuration? Or does the newer Mutt releases allow ditching the PGP/MIME format? Or perhapse Mutt's primary users tend to not communicate with Windows users. :)
Any insight is apprecated.
The company where I work uses PGP on NT to encrypt sensitive data before transmission, but our primary generator/consumer of this sensitive data is our line-of-business application which runs on an AS/400.
Currently, our developers have to write scripts which FTP the files down from the AS/400 to an NT machine, where the files are encrypted with PGP and then FTPd to the destination.
Later in the day, the company we're doing business with FTPs their responses to us, where once again, an NT machine FTPs the files down, decrypts them with PGP and FTPs them to the AS/400.
This is all necessary because NAI doesn't offer an OS/400 version of PGP. It sure would be nice if somebody had GPG running on OS/400, because then our AS/400 developers could reduce the number of steps and FTPs involved.
Unfortunately, our AS/400 admin isn't the kind of guy who'd tackle making GPG work on OS/400, and I don't know squat about OS/400 -- I'm a Unix/Linux/NT geek.
Any thoughts?
The GPG developers wisely chose to reject this feature, so if you use GPG or another non-ADK-supporting variant on PGP to encrypt a message to somebody who has an ADK stuck on their key, it will not encrypt the message to the ADK. This is good, but it's not enough - it only protects your outgoing messages, not incoming messages encrypted to you.
The recently discovered ADK attack found that if a Bad Guy attaches an ADK to somebody's key, it doesn't invalidate the signatures on their key, and doesn't require their signature, so the Bad Guy can distribute that bugged key, and anybody who uses a pre-6.5.8 version of PGP that supports ADKs and uses the bugged key will encrypt to the Bad Guy as well. If you use GPG to encrypt all your PGP messages, you won't accidentally encrypt to the Bad Guy's ADK, which is good. BUT, if you use GPG or other safe PGP version to create a Diffie-Hellman key, and some Bad Guy adds an ADK to the your public key and distributes it, people who send messages to you using unsafe versions of PGP will still encrypt to the Bad Guy's ADK if it's on their keyring.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Straight off the Mutt Index Page... but I'll refrain from editorializing:
Using Mutt with PGP/GPG
--
No--a paper signature is meaningful because verification is simultaneous with signing.
Let's say that I want to buy a new car. I go to the car dealership and ask about the rate I'll get from GMAC. The dealer and I quibble, he drafts up a loan agreement, and I sign it as Mordecai McWhirters.
At this point, the car dealer asks me for identification--a lot of identification. If any of these forms of identification fail, then the car dealer is within rights to say "no, you're not really that person; I'm not going to enter into this contract with you". And since my name isn't Moredecai McWhirters and I don't have the technical skills required to forge a passport and driver's license, well... my ID isn't going to check out.
Compare this to a letter that arrives in the emailbox PGP-signed. The return address on the email is billc@whitehouse.gov. You check the key database, and lo and behold, there's a key there for billc@whitehouse.gov. Does that mean you really received an email from Bill Clinton?
No--it means someone signed the email, and you have no idea who. This is why so-called "digital signature laws" scare the bejeezus out of me. Under most of them, if I want to take all the money from your bank account--legally--I just have to register a key in your name, write an email to the bank that's signed with this key authorizing a wire transfer of $10,000 to the First Bank of the Caymans, and then laugh all the way to Aruba. People mistakenly think that digital signatures are a verification of identity: they're not, and that's the biggest difference between digital signatures and real signatures.
Verification of identity is not a part of the current public-key infrastructure. Every single scheme which has been devised to give verification of identity to digital "signatures" is a dismal failure--certificates aren't a good solution, far less the CA+RA model which seems so common nowadays.
Signatures are forgeable, yes... but there's a good reason why people use them to enter legal agreements.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
I've used both GPG and PGP, and there isn't much commandline-level difference. It's been treating me just as well as anything can, and with pgp4pine, there is seamless integration with the pine mailer.
I'm not sure of the integration of it and GUIs besides GNOME, because i'm a console kind of person... If you're using pine, it'll work fine!
Just the fact that GPG is open-source software is enough to choose it over PGP if you use pine.
I use Windows, MacOS, and Unix most every day and I can use PGP with all three so that's what I use. I'd go for GPG if their was a Mac version but last time I checked there wasn't (I can't code so I can't port).
-Fyre
- Apple Computer......proudly going out of business for over twenty years.
GPG and PGP are not competitive in my view. PGP is a mature, stable product which runs everywhere and integrates with nearly everything. GPG is a little command line which runs on some unix platforms only. GPG for Windows is a joke. GPG for Mac does not exist. It does annoy me when people write software like GPG for the sole purpose of some supposedly righteous licensing thing. Even with the RSA patent expired, IDEA has not expired and thus GPG will remain difficult (ie impossible for normal humans) to make compatible with pre-5.0 PGP versions.
For several reasons (a proper RFC, a standard which is separate from its implementation, elegant extension of MIME, etc.) I've got a soft spot for S/MIME.
Yes, S/MIME as it stands relies on a hierarchical PKI, with the unappealing-to-some feature of a top-level root Certificate Authority - but it seems to me that PGP is edging in that direction anyway, as large bodies have begun to offer to sign PGP keys and act as trusted signers.
I strongly feel that both hackers and the Industry need to agree on a standard for encrypted/signed messages, and at the moment it appears to be hackers->PGP/GPG, industry->S/MIME
S/MIME has the advantage right now of being built into Navigator and Outlook by default.
I'd be curious to know what other Slashdotters think should happen, so that we can all settle on a common standard (or interoperate between standards)
--
Better, but your argument is still asymetrical. Let's do the symmetry work here:
Point 2, inverted: "Let's say I get a letter in my postal mailbox. The printed return address is 'Bill Clinton, White House, Washington D.C.' and the cancel stamp is DC. It's got a signature that looks exactly like the President's." Obviously the signature is not relevant and therefore this is a completed cancellation of point 2, Q E D.
Point 1 is so weak that it doesn't even have to be inverted, since obviously your signature has nothing to do with the authentication process of checking id's, etc. Incidentally this is why important signed documents are always notarized and witnessed.
BTW, your standing point to date reads "signatures are not really signatures", where the first "signatures" means "spewed chunks of unverified identification data" and the second "signatures" means "verified, binding authentication". Note that both meanings of the word can easily be attained with any signature, cryptographic or plaindata.
so we have "spewed chunks of unverified authentication data isn't really a verified authentication" which I can agree with. There is a lesson to be learned here but it has nothing to do with digits or cryptography.
I have seen the future, and it is inconvenient.
Versions of PGP prior to 5 used (formerly) patented RSA and (still) patented IDEA; supporting RSA won't get them any closer to compatibility with pre-5.0 keys until the IDEA patent expires.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
Now, for some reasons not to use GPG:
PGP is more well known
Now, for some reasons not to use GNU/Linux:
Windows is more well known
I don't know; it just came out sounding silly.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
GPG looks very cool, but it has one major problem, at least for me - a lack of implementations for us *other* OS users - you know, MacOS? (i guess Windows too, but that doesn't bother _me_ as much :) That may change with OSX, as it might be fudged to compile, but i find it rather annoying that no-one has bothered to write a non-*nix client. So i stick with the less-secure and fewered-features, but at least i get a GUI that works :)
:)
:)
Then again, you don't see me writing any code, so i can't complain too much
-me
I have been using PGP for 3 years on Windows. The main reason I started it is because of a friendly interface between my mail agent (at that time Eudora) and PGP which made it possible to encrypt and sign my mail without learning to use wrappers or command prompt PGP. The reason I did not like the idea of using command promtp PGP was because the manual stared with introduction to cryptography which was not what I wantend and did not tell my simply what to do to get it up and running.
After the latest security scare I looked að GNUPG and saw to my dismay that I would have to give up the auto promtping windows and userfriendlyness (relevtivly speaking) of the windows versions of PGP for command prompt switches and to read the introduction to cryptography again and probably start using mutt as my email client.
So I cross my fingers and use the latest verion of PGP and hope that Echelon will have fun reading the encrypted conspirecy theorys I mail myself.