Last updated - 28 January 2004
This document forms a set of working notes as the author read up and learnt how to use Gnupg. They are not yet verified or complete and are still being edited. Any comments from third parties would be gratefully received and may make the notes more useful to others. Thanks. Email to sinister@computertorture.com
Gnupg uses a mixture of symmetric and public-key cryptography so that users may communicate securely across insecure networks (such as the internet). In a public-key system, each user has a pair of keys consisting of a private key and a public key.
A public and private key each have a specific role when encrypting and decrypting documents.
It is computationally infeasible to deduce the private key from the public key. In other words, only the person who holds the private key can recover a document encrypted using the associated public key, and then only with their chosen passphrase.
Thus if you want to encrypt a message to Alice, you encrypt it using Alice's public key, and she decrypts it with her private key. If Alice wants to send you a message, she encrypts it using your public key, and you decrypt it with your private key.
A passphrase is required to unlock your private key and from the perspective of security, this passphrase is one of the weakest points of public-key encryption systems since it is the only protection you have if another individual gets your private key.
Also public-key cryptography is not secure without personal verfication of another key's owner. Users should be extremely careful and always check a key's fingerprint with the owner before signing the key (by personal communication).
By personally checking the fingerprint you can be sure that the key really does belong to the owner, and since you have signed they key, you can be sure to detect any tampering with it in the future.
The process of handling public keys is made easier by the concept of a keyring, on which you place other's public keys validated and signed by you. Unfortunately the procedure becomes awkward when either you must validate a large number of keys or communicate with people whom you do not know personally.
Groups generally follow one or another trust model, which dictates how users will go about establishing certificate validity. There are three different models:
At this point, unless you are part of a very small group or governed by a hierachy, you start or join a "Web of Trust", where a trust level is allocated to the owners of public keys by other users and depending on the quantity of trust and the distance between you and the user each key is calculated to be valid or not for your use.
A high priority should be placed on avoiding the following high cost mistakes:
$gpg --gen-key
You will be asked to provide a passphrase to create your key pair. You will have to type this passphrase often into the future and it means a lot to the privacy of your communications. It is not advisable to rush your choice of passphrase. More advice on choosing a passphrase.
Selecting DSA key at 1024 bits
Set expiry to never - unless security requires otherwise. (The easiest way of communicating new keys seems to be a keyserver.)
You need a User-ID to identify your key;
Enter Real Name, Comment and Email Address.
$gpg --export --armor keyname
$gpg --gen-revoke keyname
generates revoke.asc
If you forget your passphrase or if your private key is compromised or lost, this revocation certificate may be published to notify others that the public key should no longer be used.
Keep the revocation certificate as safe as your private key. (It could be used to disrupt your private communications)
A new public key should probably be attached to this document at time of sending.If continuity of communications are really crucial look to using a keyserver.
Your public key is most securely given encrypted and preferably signed.
$cat > filename [then paste key in] [Return] [Ctrl-d]
$gpg --import filename
$gpg --fingerprint
Before signing a key, check with the owner of that key that the fingerprints match.You must be certain that the person is who they say they are. Sharing of fingerprints does not compromise your privacy. In fact some people put them on their business cards.
$gpg --edit-key keyname
command> sign
command> trust
command> save
command> quit
To check the signings given to a public key:
command> check
Try not to artificially leave this process, as it leaves lock files (in .gnupg)
$gpg -r keyname --encrypt filename
$mv oldfilename newfilename
Do not forget to remove copies of plain text files after encrypting.
$gpg --decrypt filename targetfilename
Remember that it was thought wise to encrypt the document in the first place, thus determine whether it is safe to leave as plain text on a hard drive, or any environment where it may fall into the wrong hands. If not then read, shred and remove.
$shred --remove filename
$rm filename
$info shred - gives more information on (almost) permanently and safely deleting data. The only way to do this properly is taking a mallet to your harddrive).
$gpg --sign filename
$gpg --verify filename
Using the Web of Trust, responsibility for validating public keys is delegated to people you trust. For example, suppose
If Alice trusts Blake to properly validate and sign keys, then Alice can infer that Chloe's and Dharma's keys are valid without having to personally check them. She simply uses her validated copy of Blake's public key to check that Blake's signatures on Chloe's and Dharma's are good.
In general, assuming that Alice fully trusts everybody to properly validate keys they sign, then any key signed by a valid key is also considered valid.
The root is Alice's key, which is axiomatically assumed to be valid.
In practice trust is subjective. For example, Blake's key is valid to Alice since she signed it, but she may not trust Blake to properly validate keys that he signs. In that case, she would not take Chloe's and Dharma's key as valid based on Blake's signatures alone. The web of trust model accounts for this by associating with each public key on your keyring an indication of how much you trust the key's owner.
There are four trust levels. It is worth noting that these trust levels are not a reflection on whether you trust the person, it is only your trust in their ability to validate keys that you are rating.
Nothing is known about the owner's judgment in key signing. Keys on your public keyring that you do not own initially have this trust level.
The owner is known to improperly sign other keys. i.e You do not trust them.
The owner understands the implications of key signing and properly validates keys before signing them.
The owner has an excellent understanding of key signing, and his signature on a key would be as good as your own.
A key's trust level is something that you alone assign to the key, and it is private information. It is not packaged with the key when it is exported; it is even stored separately from your keyrings in a separate database.
The gnupg key editor may be used to adjust your trust in a key's owner. In this example Alice edits her trust in Blake and then updates the trust database to recompute which keys are valid based on her new trust in Blake.
$gpg --edit-key blake
pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/f
sub 1024g/C19EA233 created: 1999-07-02 expires: never
(1) Blake (Executioner) blake@cyb.org
command>trust
pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/f
sub 1024g/C19EA233 created: 1999-07-02 expires: never
(1) Blake (Executioner) blake@cyb.org
Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?
1 = Don't know
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
s = please show me more information
m = back to the main menu
Your decision? 3
pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: m/f
sub 1024g/C19EA233 created: 1999-07-02 expires: never
(1) Blake (Executioner) blake@cyb.org
command>quit
Trust in the key's owner and the key's validity are indicated to the right when the key is displayed. Trust in the owner is displayed first and the key's validity is second.
Gnupg overloads the word "trust" by using it to mean trust in an owner and trust in a key. This can be confusing. Sometimes trust in an owner is referred to as "owner-trust" to distinguish it from trust in a key. Where possible in this manual, however, "trust" is used to mean trust in a key's owner, and "validity" is used to mean trust that a key belongs to the human associated with the key ID.
The four trust/validity levels are abbreviated:
In this case, Blake's key is fully valid since Alice signed it herself. She initially has an unknown trust in Blake to properly sign other keys but decides to trust him marginally.
The web of trust allows a more elaborate algorithm to be used to validate a key. Formerly, a key was considered valid only if you signed it personally. A more flexible algorithm can now be used: a key K is considered valid if it meets two conditions:
The path length, number of marginally trusted keys required, and number of fully trusted keys required may be adjusted. The numbers given above are the default values used by Gnupg.
The Web of Trust is a flexible approach to the problem of safe public key exchange. It permits you to tune Gnupg to reflect how you use it. At one extreme you may insist on multiple, short paths from your key to another key K in order to trust it. On the other hand, you may be satisfied with longer paths and perhaps as little as one path from your key to the other key K.
Requiring multiple, short paths is a strong guarantee that K belongs to whom you think it does. The price, of course, is that it is more difficult to validate keys since you must personally sign more keys than if you accepted fewer and longer paths.
Web of Trust A web of trust encompasses both of the other models, but also adds the notion that trust is in the eye of the beholder (which is the real-world view) and the idea that more information is better. It is thus a cumulative trust model. A certificate might be trusted directly, or trusted in some chain going back to a directly trusted root certificate (the meta-introducer), or by some group of introducers.
Perhaps you've heard of the term six degrees of separation, which suggests that any person in the world can determine some link to any other person in the world using six or fewer other people as intermediaries. This is a web of introducers.
It is also the PGP view of trust. PGP uses digital signatures as its form of introduction. When any user signs another's key, he or she becomes an introducer of that key. As this process goes on, it establishes a web of trust.
In a PGP environment, any user can act as a certifying authority. Any PGP user can validate another PGP user's public key certificate. However, such a certificate is only valid to another user if the relying party recognizes the validator as a trusted introducer. (That is, you trust my opinion that others' keys are valid only if you consider me to be a trusted introducer. Otherwise, my opinion on other keys' validity is moot.)
Stored on each user's public keyring are indicators of
You indicate, on your copy of my key, whether you think my judgement counts. It's really a reputation system: certain people are reputed to give good signatures, and people trust them to attest to other keys' validity.
Levels of trust in PGP The highest level of trust in a key, implicit trust, is trust in your own key pair. PGP assumes that if you own the private key, you must trust the actions of its related public key. Any keys signed by your implicitly trusted key are valid.
There are three levels of trust you can assign to someone else's public key:
To make things confusing, there are also three levels of validity:
To define another's key as a trusted introducer, you
For example, suppose your key ring contains Alice's key. You have validated Alice's key and you indicate this by signing it. You know that Alice is a real stickler for validating others' keys. You therefore assign her key with Complete trust. This makes Alice a Certification Authority. If Alice signs another's key, it appears as Valid on your keyring.
PGP requires one Completely trusted signature or two Marginally trusted signatures to establish a key as valid. PGP's method of considering two Marginals equal to one Complete is similar to a merchant asking for two forms of ID. You might consider Alice fairly trustworthy and also consider Bob fairly trustworthy. Either one alone runs the risk of accidentally signing a counterfeit key, so you might not place complete trust in either one. However, the odds that both individuals signed the same phony key are probably small.
How you should use Gnupg depends on the determination and resourcefulness of those who might want to read your encrypted messages. An eavesdropper may be an unscrupulous system administrator casually scanning your mail, it might be an industrial spy trying to collect your company's secrets, or it might be a law enforcement agency trying to prosecute you. Using Gnupg to protect against casual eavesdropping is going to be different than using Gnupg to protect against a determined adversary. Your goal, ultimately, is to make it more expensive to recover the unencrypted data than that data is worth.
Customizing your use of Gnupg revolves around five key issues:
Key size affects encryption and decryption speed since the cost of these algorithms is exponential in the size of the key. Larger keys take more time to generate and take more space to store. Ultimately, there are diminishing returns on the extra security a large key provides you. After all, if the key is large enough to resist a brute-force attack, an eavesdropper will merely switch to some other method for obtaining your plaintext data. Examples of other methods include robbing your home or office and mugging you. 1024 bits is thus the recommended key size. If you genuinely need a larger key size then there are many other areas of data security you need to be looking at.
A good passphrase is absolutely critical when using Gnupg. Any attacker who gains access to your private key must bypass the encryption on the private key. Instead of brute-force guessing the key, an attacker will almost certainly instead try to guess the passphrase.
The motivation for trying passphrases is that most people choose a passphrase that is easier to guess than a random 128-bit key. If the passphrase is a word, it is much cheaper to try all the words in the dictionaries of the world's languages. Even if the word is permuted, e.g.: k3wldood, it is still easier to try dictionary words with a catalog of permutations. The same problem applies to quotations. In general, passphrases based on natural-language utterances are poor passphrases since there is little randomness and lots of redundancy in natural language. You should avoid natural language passphrases if you can.
A good passphrase is one that you can remember but is hard for someone to guess. It should include characters from the whole range of printable characters on your keyboard. This includes uppercase alphabetics characters, numbers, and special characters such as } and |. Be creative and spend a little time considering your passphrase; a good choice is important to ensure your privacy.
Protecting your private key is the most important job you have to use Gnupg correctly. If someone obtains your private key, then all data encrypted to the private key can be decrypted and signatures can be made in your name. If you lose your private key, then you will no longer be able to decrypt documents encrypted to you in the future or in the past, and you will not be able to make signatures.
Losing sole possession of your private key is catastrophic.
Regardless of how you use Gnupg you should store your public key's revocation certificate and a backup of your private key on write-protected media in a safe place. For example, you could burn them on to a CD-ROM and store them in a sealed envelope somewhere you trust to be safe (taking into account natural disasters such as fires, floods etc.). Alternatively, you could store them on a floppy and hide it in your house (avoiding strong magnetic sources). Whatever you do, they should be put on media that is safe to store for as long as you expect to keep the key, and you should store them more carefully than the copy of your private key you use daily.
To help safeguard your key, Gnupg does not store your raw private key on disk. Instead it encrypts it using a symmetric encryption algorithm. That is why you need a passphrase to access the key. Thus there are two barriers attackers must cross to access your private key:
$gpg --list-keys
This will list your public key/s, with an output similar to this:
/home/jopublic/.gnupg/pubring.gpg
----------------------------------
pub 1024D/183D69EF 2001-08-02 Jo Public (local account) <jo@hotmail.com>
sub 1024g/C839BA5C 2001-08-02
$gpg -ao filename.key --export 183D69EF
This exports the public key, ASCII armoured and writes it to filename.key
$gpg --list-secret-keys
This will list your secret key/s, with an output similar to this:
/home/jopublic/.gnupg/secring.gpg ---------------------------------- sec 1024D/183D69EF 2001-08-02 Jo Public (local account) <jo@hotmail.com> ssb 1024g/C839BA5C 2001-08-02
$gpg -ao filename.key --export-secret-keys 183D69EF
This exports the private key, ASCII armoured and writes it to filename.key - be very careful with this file, keep it in a very careful place off-site - do not leave copies of this file lying around - remove them using shred.
$shred --remove filename.key
$rm filename.key
By default, a DSA master signing key and an ElGamal encryption subkey are generated when you create a new keypair. This is convenient, because the roles of the two keys are different, and you may therefore want the keys to have different lifetimes. The master signing key is used to make digital signatures, and it also collects the signatures of others who have confirmed your identity. The encryption key is used only for decrypting encrypted documents sent to you. Typically, a digital signature has a long lifetime, e.g.: forever, and you also do not want to lose the signatures on your key that you worked hard to collect. On the other hand, the encryption subkey may be changed periodically for extra security, since if an encryption key is broken, the attacker can read all documents encrypted to that key both in the future and from the past.
It is almost always the case that you will not want the master key to expire. There are two reasons why you may choose an expiration date. First, you may intend for the key to have a limited lifetime. For example, it is being used for an event such as a political campaign and will no longer be useful after the campaign is over. Another reason is that if you lose control of the key and do not have a revocation certificate with which to revoke the key, having an expiration date on the master key ensures that the key will eventually fall into disuse.
Changing encryption subkeys is straightforward but can be inconvenient. If you generate a new keypair with an expiration date on the subkey, that subkey will eventually expire. Shortly before the expiration you will add a new subkey and publish your updated public key. Once the subkey expires, those who wish to correspond with you must find your updated key since they will no longer be able to encrypt to the expired key. This may be inconvenient depending on how you distribute the key. Fortunately, however, no extra signatures are necessary since the new subkey will have been signed with your master signing key, which presumably has already been validated by your correspondents.
The inconvenience may or may not be worth the extra security. Just as you can, an attacker can still read all documents encrypted to an expired subkey. Changing subkeys only protects future documents. In order to read documents encrypted to the new subkey, the attacker would need to mount a new attack using whatever techniques he used against you the first time.
Finally, it only makes sense to have one valid encryption subkey on a keyring. There is no additional security gained by having two or more active subkeys. There may of course be any number of expired keys on a keyring so that documents encrypted in the past may still be decrypted, but only one subkey needs to be active at any given time.
As with protecting your private key, managing your web of trust is another aspect of using gnupg that requires balancing security against ease of use. If you are using Gnupg to protect against casual eavesdropping and forgeries then you can afford to be relatively trusting of other people's signatures. On the other hand, if you are concerned that there may be a determined attacker interested in invading your privacy, then you should be much less trusting of other signatures and spend more time personally verifying signatures.
Regardless of your own security needs, though, you should always be careful when signing other keys. It is selfish to sign a key with just enough confidence in the key's validity to satisfy your own security needs. Others, with more stringent security needs, may want to depend on your signature. If they cannot depend on you then that weakens the web of trust and makes it more difficult for all Gnupg users to communicate. Use the same care in signing keys that you would like others to use when you depend on their signatures.
In practice, managing your web of trust reduces to assigning trust to others and tuning the options
$gpg --marginals-needed
$gpg --completes-needed
Any key you personally sign will be considered valid, but except for small groups, it will not be practical to personally sign the key of every person with whom you communicate. You will therefore have to assign trust to others.
It is probably wise to be accurate when assigning trust and then use the options to tune how careful Gnupg is with key validation. As a concrete example, you may fully trust a few close friends that you know are careful with key signing and then marginally trust all others on your keyring.
From there, you may set:
$gpg --completes-needed to 1 and
$gpg --marginals-needed to 2
If you are more concerned with security you might choose values of 1 and 3 or 2 and 3 respectively. If you are less concerned with privacy attacks and just want some reasonable confidence about validity, set the values to 1 and 1. In general, higher numbers for these options imply that more people would be needed to conspire against you in order to have a key validated that does not actually belong to the person whom you think it does.
When getting started using Gnupg it is important to realize that you need not securely communicate with every one of your correspondents. Start with a small circle of people, perhaps just yourself and one or two others who also want to exercise their right to privacy. Generate your keys and sign each other's public keys. This is your initial web of trust. By doing this you will appreciate the value of a small, robust web of trust and will be more cautious as you grow your web in the future.
In addition to those in your initial web of trust, you may want to communicate securely with others who are also using Gnupg. Doing so, however, can be awkward for two reasons:
The first reason occurs because people do not always advertise that they use Gnupg. The way to change this behavior is to set the example and advertise that you use Gnupg. There are at least three ways to do this: you can sign messages you mail to others or post to message boards, you can put your public key on your web page, or, if you put your key on a keyserver, you can put your key ID in your email signature. If you advertise your key then you make it that much more acceptable for others to advertise their keys. Furthermore, you make it easier for others to start communicating with you securely since you have taken the initiative and made it clear that you use Gnupg.
Key validation is more difficult.
If you do not personally know the person whose key you want to sign, then it is not possible to sign the key yourself. You must rely on the signatures of others and hope to find a chain of signatures leading from the key in question back to your own. To have any chance of finding a chain, you must take the initiative and get your key signed by others outside of your initial web of trust. An effective way to accomplish this is to participate in key signing parties.
If you are going to a conference look ahead of time for a key signing party, and if you do not see one being held, offer to hold one. You can also be more passive and carry your fingerprint with you for impromptu key exchanges. In such a situation the person to whom you gave the fingerprint would verify it and sign your public key once he returned home.
Keep in mind, though, that this is optional. You have no obligation to either publicly advertise your key or sign other people's keys. The power of Gnupg is that it is flexible enough to adapt to your security needs whatever they may be. The social reality, however, is that you will need to take the initiative if you want to grow your web of trust and use Gnupg for as much of your communication as possible.
It is important that you protect the revocation certificate carefully. Anybody can add the certificate to your public key and distribute it, and there is no way to revoke a revocation certificate. Therefore, you should store the revocation certificate in a safe place such as with the backup of your private key.
Only the certificate's owner (the holder of its corresponding private key) or someone whom the certificate's owner has designated as a revoker can revoke a PGP certificate. (Designating a revoker is a useful practice, as it's often the loss of the passphrase for the certificate's corresponding private key that leads a PGP user to revoke his or her certificate -- a task that is only possible if one has access to the private key.)
Random seed & secure ring need to be well hidden with no read access for others. Keep your public ring safe as it does read like a phone book. Solid list of good advice needed. Notes on what the random seed is etc.
How to validate fingerprints
Check there is no existing backup on your computer. If you have a revocation certificate it may be with this. If you have completely lost the key you need to revoke your private and public key, and hand out your revocation certificate to all the people you communicate with. (You will be able to this via a keyserver if you use one) You also need to go through the all the process outline steps again to create another key pair and hand out your new public key.
A revoked public key only prevents future use of the private key. Others will neither be able to encrypt documents to the key nor will they be able to check signatures made with the private key. Documents signed in the past can still be checked, however, and documents encrypted in the past can still be decrypted.
This should not occur if all the process steps have been followed. Thus, not sure what to do at all yet.
Same as for losing your private key.
Same as for losing your private key (or self hypnosis maybe...)
Uh-oh
It is not at all nescessary to understand how it works to use it.
Gnupg uses Hybrid ciphers. The session key (a symmetric key given for each transmission), encrypted using the public-key cipher, and the message being sent, encrypted with the symmetric cipher, are automatically combined in one package. The recipient uses his private-key to decrypt the session key and the session key is then used to decrypt the message.
A hybrid cipher is no stronger than the public-key cipher or symmetric cipher it uses, whichever is weaker. In Gnupg the public-key cipher is probably the weaker of the pair. Fortunately, however, if an attacker could decrypt a session key it would only be useful for reading the one message encrypted with that session key. The attacker would have to start over and decrypt another session key in order to read any other message.
When you distribute your public key, you are distributing the public components of your master and subordinate keys as well as the user IDs. Distributing this material alone, however, is a security risk since it is possible for an attacker to tamper with the key. The public key can be modified by adding or substituting keys, or by adding or changing user IDs. By tampering with a user ID, the attacker could change the user ID's email address to have email redirected to himself. By changing one of the encryption keys, the attacker would also be able to decrypt the messages redirected to him.
Using digital signatures is a solution to this problem. When data is signed by a private key, the corresponding public key is bound to the signed data. In other words, only the corresponding public key can be used to verify the signature and ensure that the data has not been modified. A public key can be protected from tampering by using its corresponding private master key to sign the public key components and user IDs, thus binding the components to the public master key. Signing public key components with the corresponding private master signing key is called self-signing, and a public key that has self-signed user IDs bound to it is called a certificate.
PGP combines some of the best features of both conventional and public key cryptography. PGP is a hybrid cryptosystem. When a user encrypts plaintext with PGP, PGP first compresses the plaintext. Data compression saves modem transmission time and disk space and, more importantly, strengthens cryptographic security. Most cryptanalysis techniques exploit patterns found in the plaintext to crack the cipher. Compression reduces these patterns in the plaintext, thereby greatly enhancing resistance to cryptanalysis. (Files that are too short to compress or which don't compress well aren't compressed.)
PGP then creates a session key, which is a one-time-only secret key. This key is a random number generated from the random movements of your mouse and the keystrokes you type. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient's public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient.
Decryption works in the reverse. The recipient's copy of PGP uses his or her private key to recover the temporary session key, which PGP then uses to decrypt the conventionally-encrypted ciphertext.
The combination of the two encryption methods combines the convenience of public key encryption with the speed of conventional encryption. Conventional encryption is about 1, 000 times faster than public key encryption. Public key encryption in turn provides a solution to key distribution and data transmission issues. Used together, performance and key distribution are improved without any sacrifice in security.
There is a known vulnerability: a sender (Alice), a receiver (Bob) and an eavesdropper (Eve). When Alice wants to send Bob a message, she encrypts the plaintext of her message with Bob's public key. No one can decrypt the message except for Bob, but Eve does manage to intercept the message.
Deciding that she wants to figure out what the message says, Eve applies a specific set of mathematical functions to the so-called ciphertext, corrupting it. Eve then sends the corrupted message, essentially a damaged version of Alice's encrypted message, to Bob without encrypting it. Bob decrypts it with his public key and gets a lot of garbage. Puzzled, Bob contacts Eve, who asks Bob to send the garbage text back. Eve then reverses the mathematical functions and removes the corruption from the message, and is left with the original message that Alice sent.
The mathematical sleight of hand is possible because there is a specific class of mathematical function that can be applied to an encrypted message and can be removed after the message is decrypted. Known as a homomorphism, the flaw opens the door to social-engineering attacks--that is, those that trick humans rather than break a code directly.
"The moral is not to send gibberish back to the person you got it from," said Bruce Schneier of Counterpane. "You decrypted it and sent it back to me. Unbeknownst to you, you have decrypted the message, but because of the corruption, you don't know it."
A major benefit of public key cryptography is that it provides a method for employing digital signatures. Digital signatures enable the recipient of information to verify the authenticity of the information's origin, and also verify that the information is intact. Thus, public key digital signatures provide authentication and data integrity. A digital signature also provides non-repudiation, which means that it prevents the sender from claiming that he or she did not actually send the information. These features are every bit as fundamental to cryptography as privacy, if not more.
A digital signature serves the same purpose as a handwritten signature. However, a handwritten signature is easy to counterfeit. A digital signature is superior to a handwritten signature in that it is nearly impossible to counterfeit, plus it attests to the contents of the information as well as to the identity of the signer.
Some people tend to use signatures more than they use encryption. For example, you may not care if anyone knows that you just deposited $1000 in your account, but you do want to be darn sure it was the bank teller you were dealing with.
The basic manner in which digital signatures are created is illustrated in Figure 1-6 . Instead of encrypting information using someone else's public key, you encrypt it with your private key. If the information can be decrypted with your public key, then it must have originated with you.
What about permissions on the keyrings?
Here follows a list of unanswered questions by the author's enquiring mind. These questions form the basis for more research and understanding.
I believe you can change your passphrase - how? Why?
How do you ensure that no-one else can reach your private key? Cryptographic file system for storing the keyrings?
What to do with old encrypted archives if you lose your private key? Maybe archive using a separate key? or backup using someone else's?
DSA or ElGemal? notes are vague - clarify
Part Answer
Elgamal (named for its inventor, Taher Elgamal), RSA (named for its inventors, Ron Rivest, Adi Shamir, and Leonard Adleman), Diffie-Hellman (named, you guessed it, for its inventors), and DSA, the Digital Signature Algorithm (invented by David Kravitz).
Somehow publicising your fingerprints must compromise your security? No! does it improve it?
What other encryption systems are out there which follow similar principles? what other operating systems support encryption.
Can you create a revocation certificate retrospectively?
How do you deal with suspicion that a compromise has occurred, rather than proof?
Hope this manual has been of help. The author does not condone the use of this information for illegal purposes in any way. Any comments or additions email sinister@computertorture.com
Author: sinister@computertorture.com
Validate this page with w3.org
Copyright (c) 2002 ComputerTorture. Permission is granted to copy, distributed and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".