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

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

GNU Privacy Guard (GPG) PGP Alternative 43

Posted by CmdrTaco from the and-its-free-from-us-crypto-law dept.
Scrub writes " The GNU Privacy Guard (GPG) 1.0.0. has been released. GPG is intended to be a free replacement for PGP. The good thing about it is, that it doesn't make any use of patended algorithms and that its development was outside the US. US crypto-laws just dont apply here, what a pity!"
This discussion has been archived. No new comments can be posted.

GNU Privacy Guard (GPG) PGP Alternative More

GNU Privacy Guard (GPG) PGP Alternative

Comments Filter:
  • Gosh, I would think that the NSA is not too happy about this!! Obviously there are other strong crypto systems avalible and from non-U.S.A. sources, but this is like slapping the NSA in the face, and saying "hahahahaha". Well, I'm sure it doesn't bother the majority of you out there who(like me) hold the US goverment in contempt. The big issue here is not that it is from another country, but that it is open source.

    The US goverment considers crypto to be a form of munition abeit not a very deadly munition, but a munition non-the-less.

    now that everyone has the right to poke around in the sources for this kewl crypto system the US goverment should think twice about its ongoing push to create back doors in the various crypto systems developed inside the country. I mean, if everyone has the code, how are they going to hide a backdoor entry? We all know the answer to that question: they can't!! Yippy!!!

    Now what needs to happen, or may already be happening(?), is to port the sources to other operating systems. Yes...yes, even the nasty old windows operating system too. Once this happens to a good number of OS's it will become a standard crupt system and no goverment will be able to snoop around in your data.

    Well, guess its time to start porting the sources over to my prefered OS, the BeOS. Letme just say thanks to the nice people who hate the goverment as much as I do for makeing this possible. Your sooo kewl!!! :)
    -Diz
  • The patent you refer to was claimed by PKP to cover all of PK crypto, but it expired before it ever got tested in court (1997, IIRC). So it's all good. And the RSA patent expires in about a year.
  • When I considered my first domain name, I kinda thought I'd use it forever. (I didn't.)
    When I considered my first public key, I kinda thought I'd use it forever.
    Reading about the GPG replacement for PGP, my first thoughts were
    1. why in the heck would I relinquish or muddy my established identity contained within my existing uncompromised PGP public key and signature?
    2. since stock PGP wouldn't handle GPG keys and methods, who could send me secure messages?
    3. if I can't get around (1) and (2), why bother with GPG?
    4. if GPG is OpenPGP, does that mean my rsa-patent-encumbered PGP5.5.5 or 6+ will be able to send to all those people who do make GPG keys?
  • I've been using this (well, a pre 1.0 version), in a production environment for a little over a month. It get's hammered everyday and has yet to barf.

    It is also smoothly interoperable with the Network Associates "Desktop PGP" product, which is a clever little windows program that lives in your task bar, and thus makes life easy for the users.

    Now if I could just get them to stop taping the passwords to their monitors!

    My only complaint is that it's not option compatible with PGP.

    I'm very impressed. Question though: I thought that PKP had a patent on the very notion of Public Key encryption, regardless of the actual algorythm. Can someone clarify this for me?

    Thanks,

    Loopy
  • I've been using PGPGPG (I found it on the same page as GPG when I started using it a few version points ago). It's a wrapper that "translates" PGP options for GPG. Works like a charm for all the PGP options I've thrown at it so far.
  • See Matt Blaze's My Life as an International Arms Courier [epic.org] for more on this.

    I don't think your advice on 3DES is terribly clearly thought out, but that's an article for another time: 3DES is perfectly good as you say.
    --
  • I see now. If you name a function SpellCheckAndSend, you are safe. If you name an identical function EncryptAndSend, you go to jail.

    Now I have a question. If I make an API that makes it easy to use any kind of plugin, including a crypto plugin, am I safe?
    --

  • I can think of several reasons:

    • Verification. Signing a message in a way that prevents forgery or alteration (without having the private key) requires strong cryptography. There are lots of reasons for wanting to insure that nobody can forge messages from you, or alter one of your messages in transit.
    • Privacy. If I'm sending credit-card information, my address or the like to someone, it'd be nice if J. Random Bad Guy couldn't read it.
    • End-system privacy. Sometimes I correspond with people who have other family members using their computer. Some of what I send them is not for the consumption of those other family members for one reason or another. Without encryption, if one of those other family members picks up the mail before the intended recipient does, they get a face-full of things they were not supposed to see. Not good.

    That's not counting local-system use, like insuring that even if a cracker gets on my local system he can't read the spreadsheet containing my bank account details.

  • A decent way to use GPG with Pine is to use pgpenvelope, available from http://www.neverending.org/~ftobin/resources.html [neverending.org]

    Yes, I know mutt has good interface also, but Pine is also a decent mailer, and a lot of people use it, so I support it.
  • Couldn't the GPG people just put something like:

    #DEFINE MAX_BITS 4096

    So that if you wanted to get thru US customs you could just change this to 40 ?

    (And of course change it back before you arrive at your destination ;-) )

  • Plus the RSA patent expires next year, so it's not that big of a deal.
  • It would be nice if everyone routinely used encryption. Todayy a lot of sensitive stuff is sent as openly as postcards just because most users don't know how to open an envelope.

    I do it myself... because only really hardcore privacy advocates use encryption it isnt practical to encrypt anything ather than the most extremely top secret stuff (thus branding it: "THIS IS A SECRET MAIL"... not so clever)

    What do we need to make e-mail encryption a hit?

    • A stable and reliable key distribution network (perhaps like the DNS system is for ip-addresses)
    • Easily installed client software
    • Perhaps a web-based de-encrypter with https thingys?
    • A way for a user to read his home-mail at work and vice versa, without compromising his/hers private keys

    Oh well...

  • Actually, I believe that GPG and PGP use a symmetric algorithm to encrypt the main body of data; the key is encrypted and stored somewhere else in the file (I guess at the beginning would make sense :) ) So if you were using a *really* insecure algorithm, someone could crack your messages one by one without ever breaking the asymmetric algorithm.
    As you point out though, all the symmetric cyphers are 'good enough'.

    Daniel

  • Mailer (and other apps) integrations issues (Score:3)

    by IIH ( 33751 ) on Tuesday September 07, 1999 @08:53PM (#1696766)
    Encryption as a routine for normal people can not really become an reality, until it becomes integrated easily with existing programs such as email, browsers, etc. However, work on doing this is made very difficult by the US export laws.

    As evidenced in the Mozilla Crypto FAQ [mozilla.org] any program that is designed to call crypto plugins (a.k.a Crypto with "holes") comes under the same export restrictions as crypto, regardless of if the program uses crypto. This would mean that, technically, if you want to add GPG support to YFM (Your favourite Mailer) then just by the addition of GPG compatibility, YFM has fallen under the US export laws, and US citizens have a lot of trouble to try and work on it.

    For those of you that noted it, this was the basis of the Microsoft crypto function that caused so much hassle of late. Technically, windows with the crypto API (even with no "crpyto") is "cryto with holes" and falls under export restrictions. To get around this, MS agreed to restrict the loading of crypto modules that they themselves signed (hence the need for the MS key). So this "loading restricted crypto with holes" was allowed to be exported without restrictions.

    AFAIK, the only restriction to the export of "crpyto with holes" is if the API can only be used for verification, but for GPG to be useful for its full range, it needs encrption also. Hence, any program that integrates it fully, would be subject to restrictions.

    So, to add GPG to "Your favourite mailer", it would split the development into several camps. One, maintaining the original email program as a base and others (maybe us and non-us) adding the cryto API's. This would add work of course, and in many cases would be dropped because the only version that could be worked on globally (which the open source model is) would be the original version. Thus, the export laws naturally make the work gravatate towards the non-gpg version. Funny that.
    --
  • I've seen a lot of posts where people are concerned about the US crypto export laws. I can understand that US developers are afraid that the NSA will knock on their door should the contribute to the GPG source. But, if GPG is as good as it claims, why don't you send your source patches encrypted with GPG(!) It is not illegal to work on the source in the US, and the NSA will never get proof that you have sent any patches out of the country because they're encrypted with 4096(+/-)-bit keys.

    "The future is already here,
    it's just not evenly distributed yet"

  • Future GUI designers should read "Usability of Security: A Case Study" [cmu.edu] by Alma Whitten and J.D. Tygar.

    It shows that A LOT of improvement is needed to make PGP-like security usable for the avarage user.

    Klaus
  • You'd be amazed at the sorts of things one can learn about someone by observing their innocuous actions. For example, a supermarket may offer its customers a discount card, allowing it to track the purchases of individual customers. A database query can then find, for example, all the people who bought a bottle of champagne and a box of condoms, in a supermarket that was not their regular supermarket...
    --

  • Just to dispel a few honest mistakes people made.. (Score:5)

    by Anonymous Coward on Tuesday September 07, 1999 @03:38PM (#1696772)
    Firstly, it is *NOT* illegal for a U.S. citizen to have hard encryption (in this case, >56 bits) on his laptop when taken abroad. Export rules *specifically* exempt this, because otherwise anyone travelling abroad with a laptop full of crypto (for which there are countless valid business uses which the gov't wants to sponsor, to secure U.S. corporate secrets) would be forced to apply for an export permit. So, you can have crypto on your laptop when going abroad, you just cannot distribute it abroad and must only use it yourself. No problem there. Now, as for the guy who questioned cipher strength: 3DES is arguably stronger than 128-bit Blowfish, CAST, or any other such comparable algorithms. I say "arguably" because all are secure from all currently known attacks. See, 3DES uses a combination of 3 56-bit DES encryptions with 3 different keys to produce a 168-bit encrypted ciphertext. Now, because of some mathematical vagaries I won't bore you with, the actual strength of the encryption hovers between 112 and 128 bits, but is in any event as secure as any other strong algorithm with 128 bits or so of key material. So no, it is neither weak nor a poor choice for symmetric encryption, but that's beside the point--something like GPG is primarily used for asymmetric crypto, and you should use different programs each for their forte. Personally, for symmetric crypto, I'd like to see someone port freeware Scramdisk to Linux. Scramdisk is a well-regarded open-source Win9x application developed by denizens of sci.crypt and offers 9 algorithms ranging to 256-bit Blowfish which can be used for encrypting "virtual filesystems" or whole partitions. I don't know of anything comparable for Linux yet...
  • cat myletter.txt | encrypt -key joe-users-key | mail joe.user@random.org
    Now we clearly see that cat(1) and mail(1) are not exportable. All Linux developers in the US go to jail. Or something

    Not quite. The export laws apply to programs with crypto api's, i.e. api's that are designed for used in such ways. It does not cover general usage cases (or else every exe that uses DLL's could be restricted)

    For example, case 1. A mailer could quite legally have a function SpellCheckAndSend which calls an external spell checker on the message and sends the message. Could someone replace ispell with pgp? yes. Does this make the mailer crypto with holes? No.
    Case 2. A mailer adds an interface with pgp/gpg and if the message is marked as such, before sending it calls EncrpytOnlyForReaders which calls an external program pgp/egp program. Is there crypto in the mailer? No. Does this make the mailer crypto with holes? Yep.
    IANAL, of course, but this is the way I see the cryto laws with plugins working. In some ways its very much like the Demon libel suit, and their follow up actions, that deemed a link to a deflamlatory article was itself deflamatory.

    In other words, the attitude is: Action A is against the law. If you do Action B, which deliberately makes Action A easier to do, then you are also breaking the law.
    --
  • good idea its good to know ppl are out there helping out with more power toys.
    i wonder how secure this stuff can be?
  • For encrypted filesystems, try www.kerneli.org -- the International Kernel Crypto patch.

  • Re:GPG Works Great with (Score:1)

    by Anonymous Coward
    US Patents 4200770 and 4218582 (Diffie-Helman/ElGamal) are the patents that PKP claimed cover all public key cryptography. Both patents have expired. The RSA patent (#4405829) expires September 20, 2000.

  • Migrating from PGP to GPG (Score:4)

    by ksheff ( 2406 ) on Tuesday September 07, 1999 @05:15PM (#1696778) Homepage

    Check out the Moving from PGP to GPG [technocage.com] guide. It will show you how to move pgp5 keys to gpg for exchanging encrypted messages with people using pgp5.

  • It can interoperate with PGP5/6 users as long as they use DH/DSS keys and the associated default symmetric encryption (3DES or CAST128?).

    See the GNUPG Homepage [gnupg.org] for more info.

  • On the other hand, Wassenaar specifically excludes regulating "public domain" (not in the copyright sense, but in the "publically available" sense) software.

    Since GNU PG is freely downloadable, it's exempt from the Wassenaar rules. (Of course, Janet Reno's ticked about this loophole and has been trying to get it closed for the past couple weeks, but so far has been unsucessful.)

  • Are any of the anonymous remailers using keys that can be used by gpg? The ones that I downloaded tonight are all RSA-type keys.

  • There are products available (and more in the works, I might add) that will help make encrypted e-mail easier to use and more ubiquitous.

  • Paranoia & Silly Export laws (Score:1)

    by Anonymous Coward


    First, I can't really see the need for encryption for normal users.
    Obviously, I wouldn't like my mail to be read by everybody, but fooling with encryption ?
    Nobody I know, uses or have used encryption for their e-mail. ( But well, none of them are linux nerds ).
    Resembles very much the giggle and whispering among the teenage girls that visits my 14 year old son.

    Secondly, a have another silly example of the exports laws in action.
    A few years ago, I worked with implementing a new credit card service here in Sweden. It required the use of DES. We had bought an IBM S/88 non-stop computer for processing.
    Then the fun started.
    The software on the IBM was incomplete, in that the DES algorithm part could not be exported from the US !
    Observe that it was the implementation which could not be exported.
    The algorithm itself were public and perfectly available in document form.
    So we just took the document and coded a DES encrypter/decrypter in less than a day.
    Weird.

  • Has anyone ever heard about 'the Wassenaar arrangement [wassenaar.org]'?
    It's full name is: The Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies.
    It's signed by 35 countries (including the US) and restricts the export of crypto-software and a lot of other things from all these countries.
    If GPG is made in one of these countries you might get into trouble too.
  • I thought Wassenaar specifically exempted Public Domain code and Internet distribution?
  • Yeah, but presumably most developers would like
    to take credit for their work. If their names
    show up in a crypto package developed in Finland,
    the authorities in the US wouldn't have to decrypt
    their actual submission.

    Alex.
  • cat myletter.txt | encrypt -key joe-users-key | mail joe.user@random.org
    Now we clearly see that cat(1) and mail(1) are not exportable. All Linux developers in the US go to jail. Or something.
    --

  • >gnupg 1.0.0 is available as an rpm in ftp://ftp.replay.co m/pub/crypto/incoming/gnupg-1.0.0-1.i386.rpm

    (2:37pm EDT 9-8-99)

    This URL is already slashdotted/down.

Slashdot Top Deals

FORTRAN is not a flower but a weed -- it is hardy, occasionally blooms, and grows in every computer. -- A.J. Perlis

Close