Think about Loose Coupling | |
PerlMonks |
Getting Started with GnuPG and GPGby derby (Abbot) |
on Mar 18, 2002 at 15:25 UTC ( [id://152489]=perltutorial: print w/replies, xml ) | Need Help?? |
Since there have been enough posts to this fine site asking
about encryption, I thought a nice tutorial would be appropriate.
This tutorial will start of with a general overview of security,
move into an overview of cryptography and then specifically demonstrate
how to set up and use GnuPG and GPG.
SecurityEncryption alone will not solve your security concerns. Too many people believe that encryption will magically make their data safe and secure. Not so. In the security realm, security is often described as an onion. The layers as a whole are the true security and each individual layer will always have issues and problems. You can have the largest encryption key and the best algorithm but store that key in a weak container and you're screwed. So before you proceed implementing encryption, ensure you're firewalls are up-to-date, ensure your OS is patched with the latest and greatest and ensure the people working with your data are trustworthy.EncryptionTo encrypt data is simply to jumble it up so others cannot read it without doing some extra work. There are two parts of most encryption systems - the key and the algorithm - the batman and robin of encryption (or is that robin and batman?).In symmetric encryption the key is shared by both the sender and the receiver. DES is the most widely used symmetric encryption algorithm. While better that storing/sending in plaintext, symmetric has one big problem - how do you share the key? Anyway you think about it, that key is one big Achille's heel. You either have to pass it out of band (can be difficult and time consuming) or you have to wrap it in another encryption which really just pushes the issues to the wrapper. In asymmetric encryption (aka public key), the key is not shared. Each user has two keys - a public key and a private key. These two keys are mathematically related in such a way that if another user encrypts using my public key then only my private key can decrypt it. There are a lot of other things going on but that's the crux of the situation. With asymmetric cryptography, we have to worry less about the distribution of the key. (But we should still worry - remember the onion). GnuPGGnuPG is an implementation of asymmetric cryptography. More to the point, it's an implementation of RFC 2440 which describes the OpenPG standard which was derived from the work of Phil Zimmerman (another implementation is OpenPGP). I strongly recommend reading the The GNU Privacy Handbook from start to finish. It's available in six languages and is extremely informative.Installing GnuPGThe folks at GnuPG have made it easy and provide GnuPG as either source(tar, debian archive, or mac archive), or precompiled (MS-Windows 95/98/NT). Once you install GnuPG, just follow the Privacy Handbook on how to create your newpairs (private and public keys). This will create .gnupg file in your home directory. Remember the onion? Be sure to not expose this directory and it's contents in an unreasonable fashion. You can do all types of fun stuff putting extra layers on top of the directory. Move it to a floppy or burn it on a cd and then remove it from the filesystem and lock it in a safe (not always practical but you get the picture).Once you have GnuPG installed and keys generated, you can do all types of encrypting and decrypting - but only for yourself. You need to get some other keys so you can communicate with others. If you're going to use GnuPG with the outside, you need to build your web of trust. If you're going to be using it by yourself, generate another keypair (as another user) and then exchange keys (that is, if you trust yourself). update: Of course, you can use a single keypair if you just wish to encrypt/ decrypt stuff for yourself. I was going to give more examples of using GnuPG/GPG in a web environment where the user running the httpd process would encrypt data with the public key of another user. This would have been a good example of another layer of security. If the web user is compromised, the data is still fairly secure because it's encrypted with the other user's keys and that keyring is stored in a safe somewhere and only brought out to run reports (isn't it?). GPGThere are several cpan modules that interface with GnuPG (and still more with OpenPGP). For simplicity, I prefer GPG. It's the easiest to start with. GPG utilizes IPC::Open3 to communicate directly with the GnuPG executable. That does have it's drawbacks but doesn't everything?For example, let's say you created two users - alice and bob. Here's two simple scripts. One where alice encrypts a message for bob, the other where bob decrypts it. alice.pl
Which is rougly equivalent to the gpg command:
This will produce something like this:
Send that to bob and he can decrypt it like so: bob.pl
Which produces:
note: I leave how to get the bob's passphrase as an exercise. Just remember the passphrase is the Achilles heel of GnuPG - lose it and you've lost your ability to decrypt records (or worse, you've given someone else the opportunity to read your data). Write it down, seal it in an envelope and lock it in a safe and have dual control to open it up (remember - onion). Conclusion and ResourcesThat should get you started on using GnuPG with GPG. There are many other things to consider. First and foremost, read The GNU Privacy Handbook. Also, take a look at Bruce Schneier's Crypto-gram newsletters. And read his book Applied Cryptography. Some may find that book a hard read (especially if you're weak on mathematics). A more approachable first book is Network Security - PRIVATE Communication in a PUBLIC World. Also many thanks to all those who labored on works like PGP and GnuPG when it was an extremely scary time to work on crypto in the US.
Back to
Tutorials
|
|