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."
Actually, it's pronounced:
I like cheese.
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.
*
Is the issue here with user acceptance or with script compatibility?
Yes, the RSA (and IDEA) capabilties are modules and yes, some additional configuration is required. But I find that gpg in the UN*X/Linux arena works better than the 6.5.x version of pgp for scripting.
For testing I signed, encrypted, signed and encrypted between different clients running PINE w/gpg (pgpenvelope is our friend), PINE w/pgp Freeware 6.5.x, and Windows clients such as Outlook 98/2000/Express and PGP Freeware 6.5.8.
On the gpg client I added the the IDEA and RSA modules.
The only issue seen was that if the pine client using gpg self signs an encrypted message and sends it to himself then PGP bitches and say's bad packet data.
Personally I'm sold on gpg for Linux. My keys were generated by gpg. To send them and use them in Win32 environments I temporarily set the secret passphrase to null, export it to a asc file, brought it back into PGP, set the passphrase on both and started using them.
Sure I could use PGP for Linux, but the gpg just works better for me.
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.
You know, maybe you ought to just use a nice binary web browser, like IE...
"Beware he who would deny you access to information, for in his heart he deems himself your master."
a patch can be distributed under any license whatsoever. As long as the end-user is the one combining the patches with the code, the end-user can do anything he wants with GPL code for himself.
Engineering and the Ultimate
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)
R.J. Hansen is ignoring a vital point on on signatures that should be brought up. It does not matter what name, if any, is used when signing a contract. If the signer can be identified, the signature is valid. That is why an "X" can be used by an illiterate person, and is still a valid signature. Signing a document as "Mickey Mouse", then trying to disclaim it, will show the miscreant what "expensive mistake" means.
I am indebted to Willy Robertson, PE, for the following: In a three way conversation, All participants admitted to no schooling, but Alf said he knew how to sign with an "X". Bill said that his mother told him that his birth certificate showed a first, middle, and family name, so Bill signed with "XXX". Charlie then showed them his own signature, "XXX,XX". The others asked him, "Why five x's?" Charlie replied, "Charles D. Evans, Professional Engineer".
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.
Did you look at Entrust? They sell products that do just that.
---
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.
I've been running the latest versions of KMail, straight from CVS, and I've also just installed the latest GPG. They're working fine for me, without any special configuration needed at all.
KMail has a config box for setting it up. All I did was tell it where GPG was, and KMail picked up the rest.
All too easy.
Alas gallinaceas de urbe bovis volo
Flamebait!
--- Nothing clever here: move along now...
Now that RSA is public domain, will GPG be adding the formerly-proprietary RSA algorithm?
11*43+456^2
Both integrate with mutt and its easy to do so.
Yeah, mutt comes with integration with PGP and GPG. The latest mutt's (1.2) have default .rc files that you can source from your .muttrc to
configure your environment for either one. Older mutt's had a few config variables for configuring PGP/GPG support.
I'm surprised you didn't just hike over to http://www.mutt.org/ and check this out yourself. :)
the real at&t mix
Have a look at the international versions of mutt.
You're a suburbanite.
-----BEGIN PGP MESSAGE-----
n xmM32lRz4MbqURd LjyhGkT23M9dWwm c5Ku81MdkzBqU7a kdm/56rZ5KjL/98 rt3u81MdkzBqU7d LjyhGkT23M9dWw
Version: 5.5.3a
kDLAR1KDlU4K89m32dL/aJ1KDIE8VePe8LaCweknhE3k623LL
dkla32KDJu34kalkdKADMb5cI9WkedKpLO09Lmcj733Kk3Dmd
x9kk3J9J82kd6GhTkdaldDiuYM8EE9dfk73K/Wwkkdc7VbTiz
dKldl34Mk39Jdk7EkmcKei93kJd/98ee/3KhcgEmHcuZwWk8Q
Po02Kz/MknWxw8UnbVt93Kei9gH8gS8Ewq/qzAz8k54/lMcuR
lKo923McUgkUi/83dFdnmJwkDj8U741M/s9kI81j733Kk3Dmd
=Ewq1
-----END PGP MESSAGE-----
Then you'll have to swipe the card plus type in a key.
The best security requires two things: something you have plus something you know.
Hmm... could you create a fifo buffer for the cuecat output and tell your MUA to look there for the secret key? How would you know when to start swiping?
The Web is like Usenet, but
the elephants are untrained.
one of the things that handle this ( at least in gpg ) is the concept of a 'web of trust'. you score each of the keys in your database with how much you trust that persons integrety when it comes to signing other peoples keys. if you think they don't bother verifying that so-and-so's public key is really theirs, then you don't trust them very highly. if, on the other hand, you know that they are careful and verify signature finger-prints via some safe method ( face-to-face, may be phone calls ) then you score them highly. then, when you get a key from someone you don't know, you check if that key is signed by anyone you trust. if it is, then you can be quite sure that it is the person it claims to be.
there is no such facility for pen and paper signatures available to the general public ( that i'm aware of ). so, this basically ( using your analogy ) allows someone to 'check your identity' through all the other people that they trust, in effect, matching the signature to your drivers license, passport, id card, library card, etc.
however, as everyone points out, security is an ongoing, active concern. the whole web of trust model does you no good if you don't actively get out there and get your key signed and sign other peoples keys after verifying fingerprints. but, by doing that you also make my life easier when it comes to verifying signatures.
and of course, all of this is also only as secure as your passphrase on your keyfile. although digital signatures are much more anti-forgable than pen and paper, once someone has your private key, they are suddenly a master forger, the like of which isn't possible using pen and paper. however, the nice thing about digital signatures is that they can be revoked if this should happen, assuming you know about it. the first thing everyone should do when they set up a digital signature they plan on using is generate and print out a revocation certificate, then store that in a very safe place. this way you can always revoke your signature if it becomes compromised.
cheers,
CraigL->Thx();
does gnupg have a way of using ldap keyservers like pgp does?
Did you mount a military-grade, variable-focus MASER on an unlicensed artificial intelligence?
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
PGP For ICQ on Windows is available here it works as an ICQ plug-in.
--
From: Aaron "PooF" Matthews
Very simple. I'll publish (or claim to publish) my private key on a site somewhere for ~1 sec. That way, it won't be my private key but a private key known to me and possiblly a number of others... Anyway, just because my email addy is in the key name, doesn't mean I automatically want that key to be legally binding. I haven't got much confidence in the legal system in my country (.nl), but I'm pretty sure they haven't got their heads _that_ far up their asses.
Mainly, PGP rolls off the tongue better than GPG does.
Interesting contrast.
.. I work for an engineering company :-)). Of course, there are less valid reasons too.
At my work, we CAN'T use any mail encryption, because then mimesweeper wouldn't be able to sneak a look in our mail.
Apparently it needs to do this to check for viruses, and whinge pointlessly about words it doesn't like (I got one rejected for having lots of repeats of 'screw'
The point is moot. If an individual needs a service / product / etc. s/he will find a way of acquiring it.
And, of course, Eudora/PGP works fine on Windows, too (my solution of choice - still the best mail client out there).
--
"It's tough to be bilingual when you get hit in the head."
Here's the skinny, folks:
:)
If you are worried that a "client" of yours will want to use encryption then go for PGP. If you want to encrypt your email to your buds then use GPG. If you don't know what the heck you want to do with it but want some sort of encryption then use GPG with you linux box or PGP if you have a PC.
It's just that simple...
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.
I used to be part of a company that evaluated companies for security holes on their networks. My job was to do profiling and actually social engineer "weak points". More than 2/3 of the time, our number one reccommendation to increase security had nothing to do with hardware or software really. Companies needed to educate their employees and set up procedures/plans of action against social engineers.
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
Digital signatures can be made up by anybody with any name (or pseudonym/handle) you like. But the advantage of these signatures is that once you make up a signature and do something with it, (e.g. post a message to a public discussion group,) nobody can claim "I'm that same guy!" except you.
This is why digital signatures were supposed to herald the oncoming of anonymous e-commerce: I was supposed to be able to reveal to you my digital signature and have you NOT know who I was. I could have my credit card company sign a random number for me to prove that I've got credit, and then use that number to buy things online. You don't get my personal info because you don't NEED to know who I am; you just need to fulfill my order.
If I try to back out of paying, you take the money from my credit card company. If you try to back out of fulfillment, I take you to court and prove that *I* was the one who was frauded, that I'm the same guy, by using my pseudonymous signature.
Web of trust? PKI? These were designed because somebody saw the word "signature" and thought that they could use digital signatures like ordinary ones. IMO, this is just another example of the age-old problem: when all you've got is a hammer, every problem starts to look like a nail.
When I moderate, I only use "-1, Overrated". That way, I never get meta-moderated!
About a 1.5 years ago I was looking for a solution to encrypt data before sending it over the Internet.
Naturally I first thought of PGP. A free version was available which would have suited my needs, but it was not available for commerical use. No problem, I had a budget, so I called Network Associates. It took 2 months to get them to sell me a Solaris version, but when I tried to decode it on Windows, it seems they didn't offer a command line interface ( and couldn't due to some "patent" crap. )
I ended up using poor security ( pkzip ) until GPG was ready for production use. I've been using GPG for 6-8 months and it works flawlessly. Now I have my command line, hard encryption, and even got to keep my budget!
Robert
--- If it's worth doing, it's worth doing in Perl!
Correct me if I'm wrong, but... if you create a v3 key and revoke any old key that you might have, then people encrypting to you will have to use your v3 public key, which cannot have any ADKs affixed. Of course there are always vulnerabilities (the sender's system might have been compromised, your drink might have been spiked with LSD, your friends might actually be NSA spies, etc.), but I don't think that Bill Stewart was trying to claim otherwise.
Hamish
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
correct me if I'm wrong, but wasn't the original PGP designed for use under Unix and then ported to DOS? (I'm not emotionally attached to the idea, so if i'm wrong, no need to flame me, just trying to clear up a possible point of confusion in my mind)
The following "features" are mutually exclusive:
Full replacement of PGP.
Does not use any patented algorithms.
Full OpenPGP implementation.
Any full replacement or open PGP implmentation must implement IDEA and RSA, and the former is still covered by patent. So any pre-PGP5 message cannot be handled by GnuPG. You can have a "Full" openpgp implementation that just implements the required algorithms, but that is not what most people mean by the term.
Also, there are severe security problems with *SOME* ElGamal (GPG uses that term for both DH encryption and ElG signing) signatures. Specifically PGP generated keys (using a DH base of 2) are really bad. I don't know if GPG has properly prevented weak signatures. In PGP and opgp (openssl/ssleay based minimal reference implementation - www.cryptography.com's archives have a copy) this was disabled by default.
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.
Ah what fun it must be to be a teen still. Raging hormones, pimples, no sex except in your mind. I wish I could do it all over again...
At work, I must use WinNT. We must encrypt all attachments sent over the net. What are the advantages of GPG for Win32 over PGP? Does it integrate with Netscape? With Outlook98 (shudder)?
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
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*
Here is a sample gpg .muttrc
c omp.tar.gz
- -
.rcs on the net.
--------------------------------
# -*-muttrc-*-
#
# Command formats for gpg.
#
# This version uses gpg-2comp from
# http://muppet.faveve.uni-stuttgart.de/~gero/gpg-2
#
# $Id: gpg.rc,v 1.5 2000/03/03 16:52:41 roessler Exp $
#
# %p The empty string when no passphrase is needed,
# the string "PGPPASSFD=0" if one is needed.
#
# This is mostly used in conditional % sequences.
#
# %f Most PGP commands operate on a single file or a file
# containing a message. %f expands to this file's name.
#
# %s When verifying signatures, there is another temporary file
# containing the detached signature. %s expands to this
# file's name.
#
# %a In "signing" contexts, this expands to the value of the
# configuration variable $pgp_sign_as. You probably need to
# use this within a conditional % sequence.
#
# %r In many contexts, mutt passes key IDs to pgp. %r expands to
# a list of key IDs.
# decode application/pgp
set pgp_decode_command="gpg %?p?--passphrase-fd 0? --no-verbose --batch -o - %f"
# verify a pgp/mime signature
set pgp_verify_command="gpg --no-verbose --batch -o - --verify %s %f"
# decrypt a pgp/mime attachment
set pgp_decrypt_command="gpg --passphrase-fd 0 --no-verbose --batch -o - %f"
# create a pgp/mime signed attachment
# set pgp_sign_command="gpg-2comp --no-verbose --batch -o - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f"
set pgp_sign_command="gpg --no-verbose --batch -o - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f"
# create a application/pgp signed (old-style) message
# set pgp_clearsign_command="gpg-2comp --no-verbose --batch -o - --passphrase-fd 0 --armor --textmode --clearsign %?a?-u %a? %f"
set pgp_clearsign_command="gpg --no-verbose --batch -o - --passphrase-fd 0 --armor --textmode --clearsign %?a?-u %a? %f"
# create a pgp/mime encrypted attachment
# set pgp_encrypt_only_command="pgpewrap gpg-2comp -v --batch -o - --encrypt --textmode --armor --always-trust -- -r %r -- %f"
set pgp_encrypt_only_command="pgpewrap gpg -v --batch -o - --encrypt --textmode --armor --always-trust -- -r %r -- %f"
# create a pgp/mime encrypted and signed attachment
# set pgp_encrypt_sign_command="pgpewrap gpg-2comp --passphrase-fd 0 -v --batch -o - --encrypt --sign %?a?-u %a? --armor --always-trust -- -r %r -- %f"
set pgp_encrypt_sign_command="pgpewrap gpg --passphrase-fd 0 -v --batch -o - --encrypt --sign %?a?-u %a? --armor --always-trust -- -r %r -- %f"
# import a key into the public key ring
set pgp_import_command="gpg --no-verbose --import -v %f"
# export a key from the public key ring
set pgp_export_command="gpg --no-verbose --export --armor %r"
# verify a key
set pgp_verify_key_command="gpg --no-verbose --batch --fingerprint --check-sigs %r"
# read in the public key ring
set pgp_list_pubring_command="gpg --no-verbose --batch --with-colons --list-keys %r"
# read in the secret key ring
set pgp_list_secring_command="gpg --no-verbose --batch --with-colons --list-secret-keys %r"
# receive key from keyserver:
#set pgp_getkeys_command="wrap.sh -g %r"
set pgp_getkeys_command=""
-----------------------------------------------
U will also find pgp
Unix, Computers and science fiction... What else can one want in life ?
Of course, in BillC's case, all you have to do is access his personal computer and type "Buddy" when it asks for the password to his private key and bingo!! your BillC!
Physical security at the White House hopefully protects BillC from himself in this case.
Slashdot: Where nerds gather to pool their ignorance
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.
True, if the learning curve is *too* steep. Nevertheless, if someone needs/wants it badly enough, ways will be found. Observe the medium we're operating in... as just one rather obvious case. In 1990, it wasn't nearly so easy to post in a public forum as it is now. Demand had produced a service. Further demand will produce further services. This will always, thank goodness, be a truism.
http://www.agorics.com/cancun.html
One disadvantage is that a digital signature is not part of you like a combination of your face and your signature (PhotoID) is.
Damned if anyone is going to implant a Digital Certificate in me anyway, especially if it has to be implanted in such a way that only I can produce it and it can't be extracted by surgical means. The "rubber hose key recovery method" may still be effective though.
Slashdot: Where nerds gather to pool their ignorance
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.
Since MacOSX is supposedly POSIX compliant, it should compile with no problems. And someone else will probably code up a quick little aqua frontend, which would be ncessary for the Macintosh. I just wouldn't hold my breath waiting for an OS9 implementation.
Here's my DeCSS mirror, where's yours?
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.
I'm not savvy enough to take a previous release of PGP or GPG and port it to another platform. But, I do know that PGP 5.0 was ported to other platforms besides *ix and Win32. Amiga ports showed up, OS/2 ports, and so on, based on the PGPi source code (scanned from PGP 5.0 source legally exported in textbooks).
Even the original PGP 2.6.x source is available, which was a simpler command line program that could probably be recompiled on any command line platform.
If there were a GNU library and toolkit for OS/400 I'd imagine you could just compile GPG straight away. There were also Perl ports if I'm not mistaken, if not of PGP than at least of RSA.
Use Evolution instead of Outlook? Bewa
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.
---------///----------
All generalizations are false.
--
I like to watch.
Way to spread false information!
mutt pases the phrase via stdin, not on the command line... great research... really!
---------///----------
All generalizations are false.
--
I like to watch.
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?
All these is fine in theory.
But the average person is not going to be able to ensure that their computer system is bullet proof to ensure that their crypto system or software is not tampered with.
So it is very worrying if laws and courts assume that just because it's signed by Mr John Smith's key, and the CAs confirm it beyond doubt, then it's 100% Mr John Smith's responsibility.
Because as far as I see it, forgery will still be there, only the mechanisms will be different - sure the criminals will not be able to forge your signatures in isolation, but they will try to cause you to sign the wrong stuff, steal your keys or use other methods.
I'm not sure if we should put such a heavy reliance on digital certificates even if they are verifiable. Unfortunately I see signs that much legislation is heading that way - because it does greatly help _machine_ processing.
None of my friends or relatives are going to set up a tempest shielded room to do their financial transactions. So should it be totally impossible for them to repudiate their transactions, just because they are using digital certificates?
Should we just raise the penalties for such crimes then? I hope not - because that direction leads to a world and society with very much less mercy.
Same thing for requiring most people to be trained and maybe even licensed before they can use such stuff. All that's making life harder - and the whole point is making life easier or at least not harder.
People have got better things to do. And I hope and pray that most people will continue to have tons more better things to do in their lives than check and monitor their tools daily. Their tools are to serve them not the other way round.
Link.
Yeah? Do you mean I can share my secret ring files between them? Last time I tried, it did not work.
--AP
Plug-ins are by definition not staticly linked. Am I dense or doesn't this nulify the license objection?
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.
PGP's latest version, 7.0 has a plugin for ICQ.
Catch me on AIM: SigningiS
I prefer a void in conversation to a vacuous one.
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 for the above case this is obviously a ridiculous restriction, I can see why RMS generally does not want to allow this. After all, if run-time linking of GPL and non-GPL code were allowed, this would pretty much turn the GPL into the LGPL.
Someone mentioned it in a longer post, so I think I'll just restate it in a more dedicated fashion. :-)
With MailCrypt for (X)Emacs it's not only possible but very practical to use both PGP and GPG alike. I use Gnus and have only good things to say about it, and that other guy seemed to say the same thing, but he used VM.
Now we just need Mozilla to support GPG/PGP, because that, after all, is going to be a very popular mailer, regardless of whether it's good or bad.
http://www.megaloman.com/~hany/sof tware/pinepgp/
hany
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?
Well, for those coming from a PGP world and aren't familiar with the arguments/flags to GPG, or are still on that learning curve, there are programs to help with that, pgpgpg being one of them. With pgpgpg, you can pass normal PGP arguments to the program, which will run GPG with the equivalent arguments. Really good for those production programs (like the stable versions of Tin) that only use PGP. specify the path for pgpgpg to it, and it'll run gpg for you. Sign, encrypt, and off you go.
/pub/gcrypt/pgpgpg.
IIRC, pgpgpg is mirrored on ftp.gnupg.org, in
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.
I'm looking for something that will allow us at work to allow signing or encrypting of mail between people using linux, windows, and clients such as eudora, mutt, pine, netscape mail, xfmail, eventually evolution and outlook express.
GPG/PGP fits the bill perfectly for mutt, pine, and xfmail, but I'm still looking for something that will work with netscape and OE. Netscape uses X509 certs which aren't supported by the other (unix) programs such as xfmail, mutt, etc.
We want these capabilities and I don't want to have to switch my mailer!
Can anyone help?
Signing a physical letter is in some ways insecure, in that a signature can always be forged--but by and large, signatures are always unique. My signature doesn't look anything like your signature, and bears only a slight resemblance to my father's signature and none to my brother's. In this way, a physical signature uniquely identifies me.
Digital signatures bear almost no resemblence to physical signatures. Not only can digital signatures be forged (check Applied Cryptography or Menezes' Handbook of Applied Cryptography), but a digital signature is not unique. It doesn't verify that I actually did anything--it only verifies that someone who has access to a very specific string of digits did something.
Now, if you can prove in a court that I am the only person who knows this very specific string of digits, then you might be able to prove to the Court's satisfaction that I signed the document. Still, that's a far cry from the inherent validity which a paper-and-ink signature possesses.
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.
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
Thanks for your input. It was simple and useful, but I have to tell you: Mutt ain't that great!!!!
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.
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.
Plus, PGP Freeware integrates with almost any mac app. Outlook Express is really nice now for following bugtraq ;-) Nothing like signing ICQ messages...
-- Are you an EFF member yet?
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
As for usability: I didn't use PGP and GnuPG I'm using mostly for signing software packages and for verifying of signatures others produced on software packages (kernel, gnupg, ...). From time to time I'm even signing and/or encrypting/decrypting e-mails.
And for now I didn't find any disadvantage in GnuPG functionality other than the cryptography itself being deployed very rarely in the wild (a lot of people do not know about things like that).
so: if you want, use PGP. if you want, use GnuPG. if you want, use any other OpenPGP implementation (if it exists). but defiitely, use some crypto!
hany
You can't use it with Netscape - but then I did say "decent mail client.
"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"
Why not? They are important points and prove the worth of Open Source solutions.
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.
It's not like you're advocating an "opensource/GNU rules the world" solution here, since you'd like to integrate GPG into Eudora, a non-free-as-in-speech, email program and Windows. If that (the freeness as in speech system) doesn't matter to you, current security hole aside, PGP is free for personal use, if you download it from MIT.
Interoptibility wise, GPG should gain quite a bit, since RSA released their patent into the public domain (probably an attempt at brownie points, since the patent was going to expire in 19 days anyhow). I wonder if the developers have an RSA encrytion module up their sleeves and ready to go already? Yeah, i could go look for myself, but i'm feeling rather lazy...
The thing is though, if you're not into "free as in speech" PGP has always been "free as in beer" for personal use.
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?
Easy. Just place a cute bird in the mail program's .signature, as I did:
Adopt a normal bird today!<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
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
--
Wouldn't the GPL license that GPG no doubt is under prevent integration with a lot of programs? Even turning it into a plug-in for a non-GPL app would violate the license if you apply RMS's strict view on linking.
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.
References please? Otherwise take your troll elsewhere. And a reference that points to goatse.cx isn't what I'm looking for.
--Joe--
Program Intellivision!
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)
--
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?
PGP works with mutt as well. Take a look at your /etc/Muttrc file, it's all explained in there.
;-)
//\
And yes, mutt is the ultimate mail client.
(o_
V_/_
Windows2000: Where do you think you're going today?
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
Anyone have any reference about integrating either one of them with mutt?
If you are looking for integration and useability then I am surprised there is even a point to discuss. PGP is to GPG what the WindowsGUI is to KDE. Clearly superior in ease of use, though not necesarily in quality. Under Windows, PGP integrates into Eudora, Outlook and Outlook Express very nicely. I still haven't bothered to get GPG for Pine because it is a big hassle. User's don't like hassles. Your users will be happier using PGP. As far as interoperability between the two, it is good. I created a (private) key under PGP Win32 and exported it to GPG Linux no problem (if you read manuals). I can open an encrypted e-amil sent to me from either platform. I am not a power PGP/GPG user but the interoperability has been perfect for every day use.
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.