It is a frequently expressed view among computer security experts that cryptography must "just work", hidden from the user's view and requiring no special understanding or knowledge.

This text is based on a different proposition: without a good understanding of the fundamentals, an end user will invariably make some seemingly trivial error that will, unknown to him, completely subvert the security of the system. Without knowledge of the fundamentals, it is difficult to differentiate between trivial and significant issues, or between minor and critical errors. Without an understanding of the functionality of the hardware devices and operating system components, and without a similar understanding of cryptography, participation in any activity that requires a high level of digital security is, at best, imprudent. The following text will provide the absolutely minimal level of understanding of public key cryptography that is required for the effective use of GnuPG, in the manner suggested further down on this web page.

Cryptography is the art of simplifying the management of secrets.

"Classical cryptography" achieves this by reducing the size of a secret. A large volume of text or data that needs to be kept secret (plain-text) is "scrambled", i.e., is processed by a special-purpose algorithm (encrypted) in such a manner that in its processed form (cipher-text) it becomes indistinguishable from a stream of random characters. The encryption process uses a short data string (a key) which defines what operations are carried out on the plain-text in order to transform it into the cipher-text. In addition to that, the very same key also specifies what operations must be carried out in order to transform (decrypt) the cipher-text back into plain-text. Without the key, it is either impossible or extremely difficult to transform the cipher-text back into the plain-text. Cipher-text, of which there might be a very large volume, need not be kept secret; only the key - typically a short string of characters - must be. A "big secret" - voluminous plain-text - is transformed into a "little secret", a short key string, which, by virtue of its size, becomes easier to protect from an adversary.

Over the centuries, a large number of encryption/decryption algorithms (often called cryptographic primitives) have been proposed and extensively studied. This activity accelerated significantly with the advent of digital computers. The purpose of such studies has been, more often than not, the search for methods to defeat the encryption (cryptanalysis); i.e., to turn the cipher-text back into the plain-text without knowledge of the key. The ability of a cryptographic primitive to resist cryptanalysis is referred to as its strength. When a sufficiently easy method of turning cipher-text into plain-text without knowledge of the key has been found, the cryptographic algorithm is considered broken and must be quickly replaced wherever it is used.

There are no methods in existence that would a priory determine the strength of a cryptographic algorithm; the only measure of its strength is the amount of effort that has been devoted to the cryptanalysis of an algorithm without actually breaking it.

If the purpose of encryption is only to safeguard some data at rest, i.e., secret data stored for later use by the same individual who encrypted it, the purpose has been achieved; only the short key must be kept secret between the time of the encryption and decryption. If the purpose of encryption is to exchange some secret data between two individuals, only the key must be transfered from the sender to the recipient in secret; the larger volume of secret data in cipher-text form can be sent to the recipient via an untrusted courier or through a communication channel open to eavesdroppers.

There are two sets of circumstances where the necessity to transmit the key in secret can become a significant problem. The first is obvious: the sender and the recipient can't meet in person to exchange the key and they have no secure channel by which even a small volume of data - the key - can be sent and received securely. The second problem becomes significant only when the number of senders and recipients becomes high. If, for instance, there are a hundred individuals that must communicate in secret, so that the content of communication is kept protected from anyone other than the sender and the recipient, then each individual will have ninety-nine keys that he must transmit in secret, and there will be a total of 9900 (100 participants with 99 keys each) keys that need to be secretly exchanged and kept protected thereafter. As the number of participants grows, the problem of safe transmission and continuous protection of keys becomes harder and harder to solve adequately and reliably.

While describing "classical cryptography", it was stated that the same key specified both the encrypt, as well as the decrypt operations. This, indeed, was the only method by which cryptography was performed for centuries. However, in the second half of the last century, a novel set of algorithms was invented. These use one key to encrypt the data, and a related but entirely different key to decrypt the data.

An analogy to these algorithms might be a strong mailbox, with two openings: the first being a narrow "slot" through which a sheet of paper with a message written on it can be inserted into, but not retrieved from the mailbox. Additionally, the mailbox has a large opening through which all sheets of paper in it can be retrieved in order to be read. Both openings have a cover, protected by different locks, having different keys.

Any number of copies of the key that protects the insertion slot (encryption key, public key) can be made and can be given freely to anybody who wants to send secret messages to the mailbox owner. The mailbox owner is however the only one that possesses the key to the large opening through which messages can be retrieved in order to be read (decryption key, private key, secret key). If the box is physically strong enough, it can be placed unattended at the street corner or it can be sent on message collection rounds by an untrusted courier - as long as the private key is safely in the exclusive possession of the mailbox owner. There is no need for any secure exchange of the keys. Public keys can be distributed with no restrictions; for convenience, they might even be given out by the courier who transports the mailbox. Each participant needs to safeguard only one key: his own private, secret, decryption key.

In the computer implementation of such scheme, the public and private keys are dependent on each other, and they must be created by a single process. However, the private key should be (next to) impossible to create from the known public encryption key. Public keys can be known to everybody - this is why this method of encryption and decryption is known as public key cryptography. Since it uses two different keys, one for encryption and another for decryption, this type of cryptography is also known as asymmetrical cryptography, in contrast to the classical, single-key, or symmetrical cryptography.

It might appear that the public key cryptography is the perfect solution to the previously mentioned problems of key-distribution and key management. In practice however, public key cryptography is burdened with its own imperfections and problems.

The first problem of public key cryptography is that it's algorithms are relatively new inventions and that their strength is consequently still in some doubt. But even if and when they are considered "secure enough", they are slow and can encrypt only relatively short messages; much too short to be of use for the secure transmission of even a single page of secret text. Consequently, the only practical way to use public key cryptography is in a "hybrid mode". The message is first encrypted using a symmetrical algorithm with a random, on-the-spot generated key (session key). This key is then encrypted with the recipient's public key using an asymmetric algorithm, and sent, in this encrypted form, along with the message cipher-text, to the recipient. The recipient must first decrypt the session key using his private key, and then use the decrypted session key to decrypt the full volume of the cipher-text using a symmetrical algorithm.

The second problem of public key cryptography is much more difficult to solve. It has to do with the authenticity of the public key, and we will again use the physical mailbox analogy to describe it.

If the mailbox courier is the one who provides the message senders with the public key, he could easily defeat the security of the channel by carrying not one, but two boxes: one that belongs to the recipient, and his own. He presents the sender with his own box, pretending it is the one that belongs to the recipient, and instead of the recipient's public key, he provides the one to his box. Once safely out of the sender's view, he opens his box (to which he has both keys!), reads the message, and then places it into the recipient's mailbox: its encryption key is known to everybody, including the courier. This method of attack is often called man-in-the-middle, as the mailbox courier (or the communication channel operator) is no longer just a passive transporter, but instead an active adversary who operates clandestinely between the sender and the receiver. In order to prevent the man-in-the-middle attack, there must be a method by which the sender can authenticate the key: i.e., ensure that the public key which he obtained, by whatever means, is indeed the one created by the intended recipient of the message.

To utilize our physical mailbox analogy for one last time, we will assume that the recipient does not only create a pair of physical keys, but that immediately thereafter he measures the depth of indentations of the public key (i.e., the one that opens the message insertion slot). These measurements, represented by a series of numbers (key fingerprint) uniquely describe the key. If they are passed on to the recipient, he can take the same measurements of the key given to him by the mailbox courier, and compare the numbers (authenticate the key). If the numbers do not match, then he knows that whoever provided the sender with the key is attempting to subvert the security of the system.

The public key owner must find a way to ensure that every user of the key has, in his possession, the fingerprint that can be used to authenticate the key. Just like the public key itself, the fingerprint need not be distributed in secret. If it is not transfered in direct personal contact between the sender and the recipient, it must be transfered via a channel which, while possibly open to an adversary eavesdropper, does not allow him to change the information flowing through it, and which does not allow the adversary to impersonate the key owner. (The conventional telephone system comes rather close to this description). If the message recipient is a public persona, he might publish the key and its fingerprint on his or her contact web page (as seen in this example). While it would be simple enough for an adversary to forge the fingerprint "in transit" when the page is accessed, it becomes next to impossible to know exactly when to forge and when not to: the page author himself, as well as possibly a large number of his followers are likely to keep verifying the content of the page by accessing it from multiple, different and anonymous network end-points.

Alternative methods of "remote" public key authentication have also been proposed and implemented, but without complete success. For instance, if the sender and the recipient have someone they both trust, (a trusted third party) that can sign both the public key and with it some information positively identifying the key owner, the signed public key might be considered authenticated and safe to use. Instead of one unreservedly trusted person (or institution), this signing can be done by a large number of individuals, who can sign each other's public keys based on their knowledge of the identity of the individual who requests that their public key be signed. While a sender, who is in possession of a public key with a large number of signatures might not trust any of those signatures, there will likely exist a "chain" of signatures that, over a series of other public keys signed by multiple and different signatories, "leads back" to an individual who is completely trusted by the message sender. This network of multiple public keys, with signatures by numerous, somewhat or partially trusted individuals is called a web-of-trust. It provides a source of information by which the trustworthiness of any given public key can be measured, and the use or rejection of a public key can be decided based on such a measure of trustworthiness.

Both alternative methods of public key authentication (trusted-third-party and web-of-trust) are in current use. However, neither has been proven adequate in practice. Trusted third parties have been cought breaking the trust, either by incompetence or by legal or extra-legal coercion. The web-of-trust, on the other hand, results in such an extraordinarily complex system and a large set of arcane operational rules, that it is of little or no practical value. There is another, even more serious liability of the web-of-trust: the repertoire of signatures on public keys provides the adversary with a wholesale list of self-identified individuals who believe they have a need to communicate in secret and the precise knowledge of their interconnections. In almost any human activity that requires secure communication, such knowledge is typically of greater value to an adversary than is the content of any specific secret message. This is especially true when the adversary has at his disposal methods of coercion for the production of private keys.

All security-related computer applications which are commonly referred to as "public key systems" are, as explained before, actually hybrid systems. When the strength of the underlying mathematical cryptography in a security application is considered, it must always be understood that a hybrid system depends on three critical primitives: the symmetric algorithm, the generation of the random session key and the asymmetric algorithm. In contrast, a purely symmetric system is dependent on only one cryptographic primitive: the symmetric algorithm.

The rest of this text will assume the following:

• Whenever there is a choice, symmetrical encryption is preferable to hybrid.

• If hybrid encryption can not be avoided, the public key fingerprint must be reliably communicated by the owner to the sender without dependence on intermediaries.

If those assumptions are correct, what are the benefits of a hybrid cryptosystem over a symmetric one?

• Hybrid cryptosystems require no secret key exchange, only a positive authentication of the public key. This positive authentication might not be trivial, but it will invariably be simpler than the secret exchange of a symmetric key. Indeed, the solution of the problem of the secret exchange of a symmetric key is the essence of a hybrid system.

• The total number of keys that must be protected from an adversary in the operation of a multi-user hybrid system is significantly smaller than the similar number in a symmetric system. Each participant in a hybrid system must protect only one key: his own.

For the history and current status of the venerable hybrids, PGP and GnuPG computer programs, please consult their respective Wikipedia entries: PGP and GnuPG. Due to the fact that PGP source code is not availale for public inspection, and that the software product is now almost a "corporate orphan", while GnuPG is an Open Source project, with a decade and a half of continuous development behind it, GnuPG is currently the choice of those that need a hybrid cryptosystem. In its suite, gpg (or, in MS Windows, gpg.exe) is the only program we will require. However, the latest version of GnuPG (version 2.x) makes it impossible to use the gpg program in anything resembling the "portable mode". What follows is "a recipe" for using a previous, but still actively developed and regularly updated version of the GnuPG suite, version 1.4.x. We ignore completely the web-of-trust functionality (unfortunately tightly integrated into the GnuPG suite of programs) and rely instead on whatever method users themselves can devise to positively authenticate the public keys using their fingerprints.

Search of the Internet will turn up multiple sources of MS Windows, Mac OSX and Linux version binaries of gpg command-line programs. We need version 1.4.10 or newer. (The GnuPG suite is included in the default installation of most Linux distributions, so it is unlikely that Linux users will need to download the program. Mac OSX versions more recent than 4.10.9 might be somewhat difficult to find.) Since the location of those sources might be changing from time to time, they are intentionally not cited here.

For convenience, the gpg programs (version 1.4.16) have been compiled for all three platforms and made available here. These binaries include all the required functions used for this simplified operation with most of the non-essential components removed. The programs can be downloaded using these links:

MS Windows:
gpg.exe
f087a53a5d3f279514863725c4eaf7d1 gpg.exe
iconv.dll
d7cbbedfad7ad68e12bf6ffcc01c3080 iconv.dll

Mac OSX:
gpg
706cb7243e8306d4e82b20ac23b8e0f6 gpg

Linux:
gpg
38731fe10a3bd2604b4e6ce01ab010ae gpg

Md5 check sums are given under each of the file's download links. Such "light" verification might be considered inadequate in some instances. If that is the case, please search for a verifiable program source on the Internet or compile your own executable from the source available on the GnuPG.org web page.

The MS Windows version of the program might need iconv.dll co-resident with the executable, but only in order to avoid a run-time warning. However, a modified GnuPG configuration file is required to be present for all three (MS Windows, MacOSX or Linux) platforms. It can be downloaded here:

Download gpg.conf (platform independent) configuration file
62d86b80fb0bc36d137e52ee22a5f741 gpg.conf

(gpg.conf is a text file. If your browser displays its content instead of offering to download it, select all displayed text, copy it to the clipboard and paste it into a local file named gpg.conf.)

It is assumed that the user understands the mechanics of the invocation and execution of "command-line" programs and the use of the computer file-system. We will document only how the keys are generated, how the public key may be uploaded to a key server and how the message files are encrypted and decrypted. By what means are encrypted message files transferred between sender and recipient is not addressed: this can be done, among other means, by sending files as e-mail attachments, by physical media transfer, by uploading and downloading from the network servers, by posting files on various web service sites and so on.

After downloading the files, select (or create) the directory which will be the "working directory" when you run the gpg program. Next, create a second directory. (In the following examples we will call this subdirectory "gpg-simple" as the subdirectory of the first one and copy the downloaded executable gpg program for your platform to that directory. Download the gpg configuration file and place it in the same ("gpg-simple") directory.

The following examples use the Linux/MacOSX command-line format. MS Windows uses "\" character (instead of "/"), to separate the path components and requires gpg.exe insted of just gpg to invoke the program execution. If the program is installed in Linux, it will not be necessary to invoke it from the gpg-simple directory; however the --homedir gpg-simple parameter on the command line will be necessary on all three platforms.

After changing to the working directory, confirm that the program operates properly:

gpg-simple/gpg --homedir gpg-simple --version


The program will report on the console its version number (which must be 1.4.10 or higher) and the list of supported crypto algorithms:

gpg (GnuPG) 1.4.11
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: gpg-simple
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


The initial step is to create your public/private key pair. Type the following command:

gpg-simple/gpg --homedir gpg-simple --gen-key

The program will ask several critical questions, which should be answered as follows:
kind of key: (1) RSA and RSA (default)
What keysize do you want: 4096
Key is valid for: 0 (i.e., it does not expire)
Real name: my-pseudonym
Email address: (empty)
Comment: (empty)
Enter passphrase: my-secret-passphrase

Two of the above items - "my-pseudonym" and "my-secret-passphrase" - merit a brief comment. The simplistic assumption of the GnuPG authors is that every user of the program will be prepared to place their real name and e-mail address in the public key file. While some individuals might be inclined to do so, many more will have no desire to make their identity known to all the world, and/or make their e-mail available to those that harvest the web for e-mail addresses. (Note that not only the owner, but any one of his correspondents, perhaps without the owners knowledge and permission, may decide to sign it and/or upload it to a key server!) A judiciously selected pseudonym as the only public key identifier is an obvious alternative. The pseudonym should be a single character string, possibly in the "adjective-noun" form, following a "theme" (e.g., colour-animal: blue-heron, pink-flamingo...). Such naming of public key files might make them memorable to a given circle of correspondents.

The passphrase protects the private (secret) key computer file in case it falls, despite all the precautions, into the adversary's hands. Wikipedia provides a good starting point for anybody in need of the knowledge required for the selection of a good passphrase.

Once the key generation has completed, the program will announce this by some output on the console, of which the following lines are especially important:
...
pub 4096R/5D677315 2014-02-22
Key fingerprint = 03A1 1E36 D8F1 C660 364C 5C89 D96A 9F33 5D67 7315
uid blue-heron
...


The first of those lines tells us, in addition to the algorithm type and key size (4096R) and "short-id" (5D677315), that what follows describes a public key generated on February 22, 2014. Uid is how the public key will be identified when used on the sender's computer and, if placed there, searched for on a public key server. The key fingerprint will further distinguish between two or more public keys with the same uid on the key server or, less likely, on the user's computer. More importantly, as explained before, the fingerprint the critical piece of information that the recipient must reliably convey to the sender to prevent the man-in-the-middle attack.

At this point the program would have created two additional files in the gpg-simple subdirectory: pubring.gpg and secring.gpg. These files are collections of public and private keys, respectively. In the gpg terminology these two files are called "key rings". Both key rings now contain only one key - the public and the private key-pair just generated. We can confirm this by issuing the following two commands:

gpg-simple/gpg --homedir gpg-simple --list-public-keys --fingerprint
gpg-simple/gpg --homedir gpg-simple --list-secret-keys --fingerprint


The public key ring will be, over time, used to store additional public keys - those of the recipients of our messages.

Next, the public key must be made available to the correspondents. This can be done by sending it to the correspondents directly, or by use of a public key server. Public key servers are web-sites operated by various Internet entities, which we may use out of convenience, but which we do not trust; i.e., the public key obtained from the key server must be authenticated before use. Following is the outline of the use of public key servers:

The just generated public key must first be extracted from the key ring in the form of a text file:

gpg-simple/gpg --homedir gpg-simple --output blue-heron-pubkey.text --armor --export blue-heron

This will create a file in the working directory with the name blue-heron-pubkey.text . This file can be listed on the console with the cat (or, in Windows, the type) command. The complete console output, starting with the -----BEGIN PGP PUBLIC KEY BLOCK----- line, can be selected and copied to the clipboard. Next, using the browser, we connect to the public key server of our choice; for instance:

http://pgp.uni-mainz.de/pks-commands.html
  or
http://pgp.mit.edu/
  or
http://keyserver.ubuntu.com/

where, following the instructions on the server web page, we can upload the public key to the key-server. An inverse operation would be carried out to retrieve the public key from the server. The key uid ("blue-heron") would be used to search, among the large number of keys stored on the server, for the specific one. If more than one key with the same uid exists, we would select the one with the key fingerprint that the public key owner has provided together with his key uid.

Most, but not all, public key servers periodically synchronize their databases of public keys. This is why a short time after the public key has been uploaded to one server, we are likely to find it on some other server too. This is however also the reason why a public key, once uploaded to a server, becomes impossible to remove the from the network of public key servers.

If, instead of uploading the public key to a key server, we decided to send the public key to a correspondent as an e-mail attachment, we would omit the --armor modifier in the key export command and we would specify the output file as blue-heron-pubkey.bin (instead of ...text). Instead of creating the public key file in the text form, this would create a binary file, and this binary file could be mailed to the message sender as an e-mail attachment. Importing such key file into a key ring would be no different than importing the key in the text form. Note however that the e-mail system operator can be trusted no more than a key server operator. In either case we must provide the key fingerprint via some additional, different, more reliable method.

Assume that one of our correspondents informed us (for instance, via a telephone call) that his public key uid is "pink-flamingo" and his key fingerprint is "6615 16CF 01BB 1F2A 2F59 972B 5F52 BD82 F448 0D16", and that the key has been uploaded to a key server. Opening the key server web page as before in the browser, we search for the public key with uid "pink-flamingo". If more than one key with that exact uid (but not a key where either "pink-flamingo" or "pink" or "flamingo" are just a substring of a uid) we should select the one where the key fingerprint matches the one provided by the key owner.

The key server will initially report only the key uid's and fingerprints of the pubic keys that were found in its database. Typically, by clicking on the short key-id string, ("F4480D16" in our example), we would get the display of the complete key in the text form. Once displayed, the text of the key must be selected, copied to the clipboard and placed into a local file. In this example, we'll assume the name of this file is "pink-flamingo-pubkey.text". Next, this public key must be included into the public key ring (i.e., into the gpg-simple/pubring.gpg file):

gpg-simple/gpg --homedir gpg-simple --import pink-flamingo-pubkey.text

Finally, the key that has been imported must be authenticated. In order to do that, we let the program calculate locally the fingerprints of all keys on the public key ring:

gpg-simple/gpg --homedir gpg-simple --list-public-keys --fingerprint

This will list on the console all public keys on the public key ring file, together with their fingerprints. If the fingerprint of the pink-flamingo public key is the same as the one we have been given by pink-flamingo key owner, the key can be used to encrypt messages to the owner. Note that we do not base the authentication on the fingerprint that was reported by the key server: that one could have been easily falsified by the either key server operator of by some other adversary while in transit over the network!

We are now ready to encrypt some file which we want to send to the owner of the pink-flamingo private key. Assume that a file with some content that needs to be protected is named "offer-to-purchase.text". We execute the command:

gpg-simple/gpg --homedir gpg-simple --output data.bin --recipient pink-flamingo --encrypt offer-to-purchase.text


The program might issue a warning about the trust in the public key about to be used for encryption. If the key has been authenticated using an independently obtained fingerprint, this warning can be ignored. If the command executed as expected, we would now have an encrypted file named data.bin, which is ready to be sent to the owner of the pink-flamingo public key.

Upon receiving the data.bin file, the owner of the pink-flamingo public key would on his computer with a similar setup execute:

gpg-simple/gpg --homedir gpg-simple --output data.text --decrypt data.bin


In order to decrypt the file, the program would require the same passphrase as the one that was entered when the pink-flamingo public/private key pair was generated.

In this example, we assume that the recipient knows what is the format of the file he received, i.e., what application to use to display or process the file. If that was not the case, the sender of the file might omit the "--output filemame" directive, and the program would then use the name of the input file (i.e., the file to be encrypted, for instance: "bluesky.jpg") and append the ".gpg" suffix to it. The recipient will thus know that what was sent to him (i.e., a file named bluesky.jpg.gpg) is an encrypted photograph, and would use an image viewer application to display it after decrypting it. In this instance, the recipient would probably also omit the output file name, so that the program would create the file with the same name as that of the encrypted filename, but with the .gpg suffix stripped off.

To generate public/private key pair:
gpg-simple/gpg --homedir gpg-simple --gen-key

To list all public keys with their computed signatures:
gpg-simple/gpg --homedir gpg-simple --list-keys --fingerprint

To extract a public key in text form, for uploading to a key server or sending it in the body of an e-mail message:
gpg-simple/gpg --homedir gpg-simple --output blue-heron-pubkey.text --armor --export blue-heron

To extract a public key in binary form, for sending it as an attachment to an e-mail message:
gpg-simple/gpg --homedir gpg-simple --output blue-heron-pubkey.bin --export blue-heron

To extract a private key in binary form, for back-up in a secure off-site location:
gpg-simple/gpg --homedir gpg-simple --output blue-heron-seckey.bin --export_secret-key blue-heron

To import a public key that has been received from pink-flamingo as a "pf_pk.bin" file:
gpg-simple/gpg --homedir gpg-simple --import pk_pk.bin

To list the fingerprint of pink-flamingo's public key, in order to compare it to the fingerprint received from pink-flamingo:
gpg-simple/gpg --homedir gpg-simple --list-key pink-flamingo --fingerprint

To encrypt a file with public key with uid pink-flamingo:
gpg-simple/gpg --homedir gpg-simple --output data.bin --recipient pink-flamingo --encrypt offer-to-purchase.text

To decrypt a file with user's own private key:
gpg-simple/gpg --homedir gpg-simple --output data.text --decrypt data.bin

This document provides only the explanation and operational steps that are necessary for a very simplified use-case of a very complex computer application. In cases where the use marginally deviates from that explained above, the reader should consult the User Guide that comes with the GnuPG program suite.

As mentioned before, hybrid cryptography systems are inherently less secure than pure symmetric cryptosystems. Hybrid systems should be used only for the protection of data that is of limited benefit to the attacker after some period of time: there is a real possibility that advances in computer hardware speed and further cryptanalytic research will affect the strength of asymmetric algorithms more than that of the symmetric ones. The best use of hybrid cryptosystems is to operationally "bootstrap" a more secure communication method, but obviously, not for the direct exchange of long-term-use secret symmetric keys.

Every computer running an operating system that is periodically and automatically updated by the untrusted operating system vendor must be considered untrusted. Even if the operating system vendor is trusted, the process of authentication of those updates is far from perfect, and therefore opens many points of attack for a technically competent adversary. A simple step of running all GnuPG operations on a stand-alone computer (i.e., one that is not connected to the Internet) goes a long way towards the stronger protection of sensitive data. By far the best medium for transfer of plain-text and cypher-text between such a stand-alone computer and the network/communication computer are floppy disks, which are cheap enough to be destroyed after a short period of use.