Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

GPG vs. PGP? 158

Posted by Cliff from the better-living-thru-encryption dept.
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."
This discussion has been archived. No new comments can be posted.

GPG vs PGP More

GPG vs PGP

Comments Filter:
  • Actually, it's pronounced:

    I like cheese.

  • There's really not much difference between the two (Score:5)

    by Nugget94M ( 3631 ) on Wednesday September 06, 2000 @01:57PM (#800019) Homepage
    I just recently migrated from pgp5.0 (for unix) to gnupg and frankly the differences are quite superficial.

    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 [gnupg.org] (It's in /usr/ports/security/gpa).

    If 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 [mutt.org] 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:

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

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

  • Re:But there ARE compatibility issues... (Score:1)

    by Anonymous Coward

    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 [sourceforge.net] 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 [gnupg.org].

    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.

  • Cost for commercial use (Score:2)

    by Anonymous Coward
    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...
  • 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.
  • 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.
    ---
  • The points you raise are identity verification issues. You know that a document was signed by 0x600A0342, but how do you know that 0x600A0342 is really Matthew Sachs? Today, this is addressed by Public Key Infrastructure (PKI.) The two main types of PKI being used are "central clearinghouse" and "web of trust."

    "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 [fortify.net] and my HTTPS website [zevils.com]. Fortify's certificate was issued by Thawte [thawte.com] (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 [gnupg.org]):

    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 [counterpane.com] and Carl Ellison [std.com] have written an excellent paper, Ten Risks of PKI [counterpane.com] (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".
  • 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?

    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 [entrust.com]? 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.
    1. Law Enforcement "profiling"
    2. Law Enforcement's legal power of "Discretion"
    3. Predator
    4. strong crypto isn't just for privacy, its for authenticity and plausible deniability.
    5. your military firearm won't stop anyone from emptying your bank accounts

    Flamebait! [slashdot.org]

  • A mini-ask-slashdot:

    Now that RSA is public domain, will GPG be adding the formerly-proprietary RSA algorithm?

  • 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/ [mutt.org] and check this out yourself. :)
  • Have a look at the international versions of mutt.

  • complex question, simple answer (Score:1)

    by Anonymous Coward
    OctaneZ:

    -----BEGIN PGP MESSAGE-----
    Version: 5.5.3a

    kDLAR1KDlU4K89m32dL/aJ1KDIE8VePe8LaCweknhE3k623LLn xmM32lRz4MbqUR
    dkla32KDJu34kalkdKADMb5cI9WkedKpLO09Lmcj733Kk3Dmdd LjyhGkT23M9dWw
    x9kk3J9J82kd6GhTkdaldDiuYM8EE9dfk73K/Wwkkdc7VbTizm c5Ku81MdkzBqU7
    dKldl34Mk39Jdk7EkmcKei93kJd/98ee/3KhcgEmHcuZwWk8Qa kdm/56rZ5KjL/9
    Po02Kz/MknWxw8UnbVt93Kei9gH8gS8Ewq/qzAz8k54/lMcuR8 rt3u81MdkzBqU7
    lKo923McUgkUi/83dFdnmJwkDj8U741M/s9kI81j733Kk3Dmdd LjyhGkT23M9dWw

    =Ewq1
    -----END PGP MESSAGE-----

  • The 6% revenue is for developing products that leverage PGP code, not for using PGP in a corporate setting.
  • Correction:
    ...any other name would smell as sweetly
  • How about taking that passphrase and printing the bar code on a card. Anytime you need it, just swipe it in with CueCat.
    Better yet, put your secret KEY on the barcode.

    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?

  • 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?
  • 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*.

  • PGP For ICQ on Windows is available here [samopal.com] 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.

  • Pronunciation (Score:3)

    by sxyzzx ( 125040 ) on Wednesday September 06, 2000 @01:32PM (#800046)
    Mainly, PGP rolls off the tongue better than GPG does.
  • Interesting contrast.

    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' .. I work for an engineering company :-)). Of course, there are less valid reasons too.

  • Learning curves, steep or not, are invariably scaled by those with a need to master them.

    The point is moot. If an individual needs a service / product / etc. s/he will find a way of acquiring it.

  • SOS? I thought that was only what people who tried running Solaris OS on random home x86 machines called their OS. ;>
  • And, of course, Eudora/PGP works fine on Windows, too (my solution of choice - still the best mail client out there).

    --
  • Slightly better than SXYZZX too ;)
  • 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... :)

  • Interoperability (Score:3)

    by Bilbo ( 7015 ) on Wednesday September 06, 2000 @01:35PM (#800054) Homepage
    I'm using GPG here in an otherwise PGP shop, and I've had no problems.

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

    --

  • I went through both a long time ago (Score:5)

    by jfunk ( 33224 ) <jfunk@roadrunner.nf.net> on Wednesday September 06, 2000 @02:06PM (#800055) Homepage
    I settled on GPG, for numerous reasons, which I shall list:
    • GPG is much easier (for me) to use than PGP for UNIX (PGP for Windows is another matter altogether...). I like having one binary, as opposed to pgpv and pgpk, with GNU-style readable commandline options (--whatever) and informative, easy to read interactive text output
    • GPG is free (beer and speech)
    • Due to it's free nature, future free software has more reason to integrate GPG support
    • It's OpenPGP compliant, thus compatible with PGP
    • It's GNU. While RMS really bugs me sometimes (I'll not get into that...), GNU software is generally held to a high standard
    • I dunno, it just feels right

    Now, for some reasons not to use GPG:
    • There is more software that is compatible with PGP (that's changing all the time, though..). Specifically, StarOffice and KMail
    • PGP is more well known

    To finish, I'll mention some software that can use GPG:
    • Mail Agents
      • PINE
      • Mutt
      • XFMail
      • I assume Mozilla will at some point
    • Utilities
      • Geheimnis (formerly KPGPShell). I use this for key management
      • TKPGP. I use this for working with the clipboard, and for reading and saving sensitive information. I like it a lot
      • There's a GNOME package that works like Geheimnis (I forget the name), but wasn't as mature as Geheimnis when I tried it out


    Hope that helps, in some way or another.
  • Actually it's not even how you use it...it's how well your worst user uses it. Just like any security policy.

    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.

  • PGPing your email? (Score:4)

    by Alomex ( 148003 ) on Wednesday September 06, 2000 @02:07PM (#800057) Homepage
    This is not a rethorical question:

    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.
    --
  • My understanding is that they have already integrated it into the working tree, so when 1.0.3 comes out, it will be there.
  • Mutt supports both PGP and GPG very nicely. I use GPG (1.0.2) and mutt (1.2.5i) on a daily basis to read and send encrypted/signed mail. It works flawlessly.

    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.

  • Re:Digital signatures are not really signatures. (Score:3)

    by rjh ( 40933 ) <rjh@sixdemonbag.org> on Thursday September 07, 2000 @10:38AM (#800073)
    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.

  • But there ARE compatibility issues... (Score:4)

    by Sir_Winston ( 107378 ) on Wednesday September 06, 2000 @06:59PM (#800075)
    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.

  • 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!


    -----

  • It's a matter of pipes (Score:3)

    by ftobin ( 48814 ) on Wednesday September 06, 2000 @02:27PM (#800083) Homepage

    As a person who has written a couple Perl modules to handle both PGP and GnuPG, most recently GnuPG::Interface [sourceforge.net], 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?
  • When you paper-sign, the connotation is largely "I mean this" or "I promise to agree to it"

    An electronic signature, despite having the name "signature", means "This DID come from your buddy Tom, and you can verify this fact yourself with very little uncertainty" Kinda like having it notarized.

    Of course, with a legal signature, an electronic signature means both. The very fact that you are signing it implies the first, and the second lends it credibility.

    "What a waste it is to lose one's mind. Or not to have a mind is being very wasteful. How true that is"

  • Re:Digital signatures are not really signatures. (Score:3)

    by timster ( 32400 ) on Thursday September 07, 2000 @06:06PM (#800089)
    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 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.

  • Pine Integration (Score:3)

    by _Sprocket_ ( 42527 ) on Wednesday September 06, 2000 @02:29PM (#800098)
    I've been using PGP with Pine for awhile now via various filters. My current favorite is pgpenvelope [sourceforge.net]. It offers a nice interface with some powerfull features when properly installed and used with the suggested filter and procmail configuration.

    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.

  • I dissagree, to understand recursion, you first have to understand 'understand'

  • Re:Mutt and MIMEs (Score:4)

    by GianfrancoZola ( 6069 ) <jkoepp AT gmail DOT com> on Wednesday September 06, 2000 @03:11PM (#800100)
    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.

    For gpg, try this in your .muttrc or wherever (could require some fiddling, I don't use these clear-text signatures myself):

    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' .muttrc files, which is where these came from. Good luck.

  • Habitual signing of documents (Score:3)

    by Greyfox ( 87712 ) on Wednesday September 06, 2000 @02:35PM (#800101) Homepage Journal
    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 don't think that's the case at all. There are lots of people working on Mac products. Are there as many as work on Windows? No, of course not.

    Do I have one whit of programming ability to write it myself? Nope.

    Would I write it, if I had the appropriate skills? Absolutely.

    For some of us, it is less about freedom and more about [to quote ESR] programs which don't suck. In this case, PGP sucks less than GPG because it at least works on my platform. :)

  • Yeah, that's why you take precautions with your key, like not storing it on a computer other people use and things like that. And you verify that it's Joe by having him read you the fingerprint. If you excercise proper key management, there shouldn't be a problem.

    "What a waste it is to lose one's mind. Or not to have a mind is being very wasteful. How true that is"

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

  • Re:But there ARE compatibility issues... (Score:3)

    by Sir_Winston ( 107378 ) on Wednesday September 06, 2000 @09:13PM (#800114)
    > If you've never tried these patches, how can you say they aren't 100% compatible?

    Because the official GPG pages used the words "unofficial" and "buggy" and "beta" when I looked into GPG just a month or so ago. If GPG devs themselves say there are compatibility issues, I would be inclined to believe them.

    > Also, they're plug-ins, not patches.

    Joy. Either way, it isn't ready for prime time until RSA support is written into the GPG code itself. Even so, compatibility will be a big issue--in the world of those who are *serious* about communications privacy and security, legacy applications are still the norm since they are tried-and-true, proven, and free from code bloat. As such, these applications are typically not going to be GPG-compatible for some time. Such popular software includes Jack B. Nymble for remailer client/nym use, Private Idaho for nym creation and use, and Reliable for use as a remailer server. Some such applications have to make calls to PGP, which cannot be duplicated in GPG; there are wrappers and such for GPG, but that's a very klumsy kludge since it's far easier and more reliable to just install PGP 2.6.x with its 100% compatibility with those calls and low overhead since no wrapper is necessary.

    Personally, I use PGP 2.6.3ckt for compatibility with Private Idaho calls and for creating the more secure non-ADK type 3 RSA keys, and also have Reliable and Jack B. Nymble configured to use the 2.6.3ckt install. Then I use PGP 6.02ckt for general usage, since the keys import nicely from my 2.6.3ckt install when necessary and since it's far quicker to use the GUI tools that come with 6.x versions than to bring up a CLI and type long strings of commands. Of course, it's set to warn before encrypting to an ADK.

    Point being, until GPG has full RSA compatibility and can take PGP commands, it's useless for those who operate remailers, it's useless for those who still use good ole' Private Idaho (a lot of people who use remailers or nyms still do), and I believe it's also still useless to those who use Jack B. Nymble although I haven't looked at the latest release yet. There also needs to be a GUI with tools as functional as those in PGP 6.x for it to gain widespread acceptance among those who currently use PGP--if you use PGP on a daily basis, nothing is as useful as that PGPtray util. further, I started to install GPG a couple weeks ago since I do want to show support for Open Source and Free Software, but the damned thing was more difficult to set up and configure than the ancient PGP 2.6.x is, so I just said "fuck it" since I was happy with PGP anyway.

    > I've got the RSA and IDEA plug-ins running with
    > my GPG just fine.

    That's nice. Good for you. Do you use it with Nym and remailer applications? I doubt it. Have you sent messages through notoriously finicky Cypherpunk chains with it? Again, doubtful.

    > I imported my PGP 2.6 secret key and keyring just grand. I've had
    > zero problems encrypting to people with RSA keys and decrypting messages sent from
    > them.

    That's nice and all, but don't think that just because it works *for you* means it works universally. Even the GPG folks say it doesn't, and it's useless to use something so unproven in critical areas such as remailer use.

    > Please don't knock something if you've never even tried it.

    Again, I mentioned its lack of complete compatibility because the GPG site mentioned it, and because no one in the remailer world that I know of uses it. Even amongst the non-remailer-guys in the alt.privacy* and alt.security* hierarchies, I have seen a GPG signature only twice in my two years of involvement. Very, very few amongst those truly quite into communications privacy use GPG, and this will remain the case until a 100% compatible right-out-of-the-box version is released.

    I really question the rationale behind GPG anyway. PGP source code is available for free--it ain't Free Software, GPLed "Free," but it's good enough and it gets hacked on a lot to create custom versions with extended features. The tried-and-true PGP 2.6.x codebase has been reviewed for security for years, with no holes. Put a GUI and extended functionality into that code, and hand it over to pgpi.org, and you'd have the best, most compatible, most proven, most useful application of the type. So, it seems that GPG is more about FSF style philosophy than about making the best application. I'm all for the Open Source and FSF ethos, I really do appreciate the philosophy and worldview involved; but I and most people into securing our communications won't use a product just for its philosophy, we need a product with a proven track record and 100% compatibility with the applications which are necessary in the field. I hope that'll be GPG someday, but it won't be for a long while. Instead of cloning PGP, the industry standard, developers went off on their own with everything from command syntax to ciphers. Would StarOffice and WordPerfect and others have any chance of succeeding if they didn't try to be as compatible as possible with handling of the evil but industry-standard .doc file format? No fscking way. I'm sure GPG will eventually be fully compatible with PGP, but until then those of us *really* into private communications and Type 1 remailers and nyms will be sticking with PGP.

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

    --
  • Invariably someone will crack into your system and send mail out as you, signed, to every news group in existence, requesting kiddie porn. With the digital signature laws now bubbling to the surface, you'd have a hard time explaining yourself when the FBI comes to arrest you.

    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!

  • Oops, pressed the wrong thing at the wrong time :/

    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 [cryptix.org] alongside a standard such as JavaMail [sun.com] 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 encountered the following problems when switching from PGP to GPG (on a Unix system), sending messages to someone using PGP for Windows on the remote end:

    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.

  • PGP vs GPG (Score:4)

    by Greyfox ( 87712 ) on Wednesday September 06, 2000 @02:50PM (#800128) Homepage Journal
    While I was working at IBM, I ended up specifying that all documents sent to our outside world contractors be encrypted with PGP or comparable encryption. The department got PGP for Windows and I set all the UNIX boxes up with GPG. If you don't want to pay for an extra license fee GPG is nice, since it's not encumbered with any patents either.

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

  • PINE (Score:2)

    by Kev Vance ( 833 )
    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.

    For anyone who actually wants to do this, it's:

    display-filters = _LEADING("-----BEGIN PGP ")_ /usr/local/bin/gpg
    sending-filters = /usr/local/bin/gpg --clearsign

  • Instant Messaging (Score:4)

    by DeadSea ( 69598 ) on Wednesday September 06, 2000 @03:45PM (#800131) Homepage Journal
    I wan't encryption built into an instant messanger. Almost all of the communication that I do that I would like to keep private is done over and IM.

    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.

  • Good use for CueCat? (Score:2)

    by Anonymous Coward
    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.

  • MUA integration (Score:4)

    by mike_markley ( 69586 ) on Wednesday September 06, 2000 @01:37PM (#800135) Homepage
    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.

  • GPG features (Score:5)

    by talonyx ( 125221 ) on Wednesday September 06, 2000 @01:38PM (#800136)
    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.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...

  • Interop. (Score:2)

    by Anonymous Coward
    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.
  • Aargh, I can't find the link I was looking at last time. Last time I was there, which was within the last couple of months, there was a link right on the main page to a site which linked to pages with the RSA and IDEA modules and information about them, I took this to be a site by the modules' developers. I guess the site was reworked a bit when the FAQ came out--the date on the FAQ is 6 Sept. 2000, just yesterday. So yes, the words I ascribed to the GPG people themselves are no longer there. But since the FAQ came out just yesterday, and there is no other link on the site about the modules, we can assume that 1) there used to be such a link before the link was put into the new FAQ, therefore 2) I am not entirely full of shit even though I can no longer back my claim since the original link was deleted when the info was added to the FAQ, published *yesterday*.

    Take my characterizations cum grano salis, if you want, but the FAQ is less than a day old and that link to the modules' developer site was there, before the link to the files on the gnupg server was put into the FAQ. If I feel up to it I could always go to Google and look for that site for the modules, but...hell, it's 5:22 in the morning. I'm going the fuck to bed... ;-) Feel free to flame me in my absence, but I repeat: the FAQ came out only yesterday, and I swear that link with the characterizations I used was there recently. I hate change...

  • 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

    You are wrong. They are not buggy. They are not patches as they cannot be patches because of the GPL. They are extenal loadable modules. Most importantly they work. The latter is the most important point when comparing it to the RSA reference implementations which suck rotten eggs through a thin straw on any system with more than 32 bits and/or proper endian order. I wish they finally learn what an integer is. Agrgh....

    I can hardly comment on the rest but on purely technical grounds seems like loads of bulls to me.

  • I really question the rationale behind GPG anyway. PGP source code is available for free--it ain't Free Software, GPLed "Free," but it's good enough and it

    ,b>Bollocks. You are full of shit. Have you actually had a look at the PGP source. It is DOS/WINHOZE peace of crap. Barely ported to crawl on unix with some ifdefs. Usually does not compile on 64 bit/big endian systems for a few years after the next major release. Does not know which is the random device on the appropriate system (urandon vs random). List can be continued ad naseum.

    On the contrary both GPG and the patented alogorithm plugins for it are actually portable well written source. It is vastly superior on this grounds. This is sufficient rationale. And until RSA learns to write proper unix code this will be the rationale behind peoplpe using pgp 2.6.x (it is also quite MSDOSy but it is at least audited) and GPG.

  • Mutt and MIMEs (Score:3)

    by _Sprocket_ ( 42527 ) on Wednesday September 06, 2000 @02:53PM (#800146)
    IMO, though, if you want a really good MUA with great GPG support, mutt is the way to go.
    A year or so ago, I had tried Mutt. I liked the client and was glad to see a MUA with PGP (and GPG) support built in. But in the end, I had to drop it. The insistance on using the PGP MIME format hurt interoperability with my Windows PGP-using coworkers. I suspect it had something to do with Outlook's handling of MIME types.

    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.

  • How about support for OS/400? (Score:2)

    by Anonymous Coward

    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?

  • Why GPG is STILL partly vulnerable to ADK attack (Score:5)

    by billstewart ( 78916 ) on Wednesday September 06, 2000 @03:53PM (#800150) Journal
    PGP added a feature called the "Additional Decryption Key", which you or your administrators can add to your PGP public key record so that they can decrypt your messages if Bad Things happen, such as you getting hit with by a truck or a subpoena or a great offer from a pre-IPO startup. If you have a version of PGP that supports this feature, and you encrypt a message to somebody whose key has an ADK field attached to it, and you have a public key matching the ADK's KeyID in your keyring, your message will also be encrypted to the ADK's public key.

    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.

  • Re:on a related note: pgp/gpg+mutt possible? (Score:3)

    by CoughDropAddict ( 40792 ) on Wednesday September 06, 2000 @03:00PM (#800151) Homepage
    Straight off the Mutt Index Page... but I'll refrain from editorializing:

    Using Mutt with PGP/GPG [mutt.org]

    --

  • Re:Digital signatures are not really signatures. (Score:5)

    by rjh ( 40933 ) <rjh@sixdemonbag.org> on Wednesday September 06, 2000 @04:02PM (#800154)
    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.

  • security is process, not technology (Score:3)

    by The Pim ( 140414 ) on Wednesday September 06, 2000 @01:44PM (#800155)
    Barring egregious mistakes in the software, your overall security is dominated not by what's inside, but by how you use it. That said, I think the important considerations may be:

    • How easy is it to use properly? Does it take a lot of configuration to get right? Does it err on the side of paranoia? Is there a front-end that makes it easy to do the right thing?
    • How good is the documentation? Does it recommend good practices and explain why they're right?
    • How's the support? Where can you get your questions answered?


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

  • Cross platform (Score:3)

    by FyreFiend ( 81607 ) on Wednesday September 06, 2000 @01:47PM (#800157)
    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

  • Different markets (Score:2)

    by Anonymous Coward
    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.

  • S/MIME (Score:2)

    by slim ( 1652 )
    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)
    --
  • Here is the link. I will recommend reading the HOWTO to see if there are any specific restrictions you may need to comply to: ftp://ftp.gnupg.org/pub/gcrypt/contrib/

  • Re:Digital signatures are not really signatures. (Score:3)

    by timster ( 32400 ) on Wednesday September 06, 2000 @04:23PM (#800164)
    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.

  • Re:Mutt and MIMEs (Score:3)

    by logicnazi ( 169418 ) <gerdesNO@SPAMinvariant.org> on Wednesday September 06, 2000 @04:27PM (#800167) Homepage
    I use gpg and mutt but am a little scared about my passphrase. As far as I can determine from both the mutt source code and documentation mutt stores the pgp key in unprotected memory and then passes the key to gpg via a command line.

    Now it was a simple fix to let mutt declare the memmory private or protected or whatever (so it won't get swapped to disk) but I didn't bother as the week link really seemed to be passing the key tpo gpg. Maybe I am mistaken or things have changed but it seems to me anyone with a script and read access to /proc can get my passphrase.

  • 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! [8m.com]

  • 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! [8m.com]

  • Cool, but lacking implementations (Score:3)

    by Ambidexter ( 61363 ) on Wednesday September 06, 2000 @01:52PM (#800171)
    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.

Slashdot Top Deals

Anyone can make an omelet with eggs. The trick is to make one with none.

Close