Slashdot Mirror
GNU Privacy Guard (GPG) PGP Alternative
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!"
"Windoze 95" - this suxx.
Or rulez...
ain't quite shooah
;-))
He who would keep a secret, must keep it a secret that he has a secret to keep. -- Sir Humphrey Appleby :) If we only encrypt sensitive information, then we are effectively flagging that information as sensitive. This causes two problems: 1) The computational effort involved in reading our sensitive information is reduced from decrypting everything we write to that which we bother to encrypt. 2) The very fact that we bother to encrypt some things but not others is construed as suspicious; if everyone encrypted everything this would not be the case.
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
It isn't a lie if you belive it.
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 public key, I kinda thought I'd use it forever.
Reading about the GPG replacement for PGP, my first thoughts were
[
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 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.
--
Xenu loves you!
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?
--
Industrial space for lease in Flatlandia.
I would be interested in using GPG, but will it be able to encrypt/decrypt PGP messages. If it can't then it's completely useless to me.
I can think of several reasons:
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
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.
#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.
-- Virtual Windows Project
The agreement specifically exempts 'public domain' software, which most people assume means that stuff like GPG is not affected by it.
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?
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
Hurry up and jump on the individualist bandwagon!
So I guess this one just shuts US developers out of the circuit. Or is it just a matter of US developers only submitting patches, and never a whole sandbox, to the ongoing development?
After that case in which a 8-second exploit was used against a Linux box, I must ask: how can I know if my box hasn't been compromissed and its kernel modified to make it look like it's not been compromissed?
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 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.
--
Exigo spamos et dona ferentes
"The future is already here,
it's just not evenly distributed yet"
"The future is already here,
it's just not evenly distributed yet"
- William Gibson
Future GUI designers should read "Usability of Security: A Case Study" 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
Of course, the hardware mentioned here is a different matter entirely. PGP (or Scramdisk, GPG, or whatever) on a laptop is fundamentally different from a piece of hardware designed to encrypt voice communications--the hardware is a lot less readily available, and naturally there's a fear that it could be stolen and reverse-engineered whereas software is readily available internationally anyway. Look up the BXA regulations--I don't have an immediate citation, but I have read the regs because I regularly travel to Japan with my laptop, which contains Scramdisk and PGP v. 2.6.3 and Private Idaho. I also seem to recall a ZDNet article from when the regs were relaxed to allow encryption software for personal/corporate use, so a search of ZDNet would probably yield a relevant article (sorry, no time to fetch one myself, sleeep beckons).
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...
--
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.
--
Exigo spamos et dona ferentes
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.
ftp.kerneli.org has a set of international patches to the kernel which include encryption support for the loopback device. You can encrypt a partition or a file containing a filesystem image. It supports blowfish and several AES candidates.
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
Alternatively, you can create the rpm yourself: rpm -tb gnupg-1.0.0.tar.gz will automatically compile and package it to an RPM.
Check out the Moving from PGP to GPG guide. It will show you how to move pgp5 keys to gpg for exchanging encrypted messages with people using pgp5.
the good ground has been paved over by suicidal maniacs
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.
the good ground has been paved over by suicidal maniacs
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'?
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?