In practice it will depend on various circumstances whether the use of encryption can give you more privacy, security or anonymity.
We suggest the following guidelines when it comes to secure your communication or to secure any other kind of documents than emails. Please follow the instructions given in this document thouroughly if there is some information which you wanna handle to us in encrypted form:
At first you will need to obtain a genuine copy of our public gpg key i.e. the estellnb.pubkey.asc file. Try to download the key file from different computers over different networks as available via the contact link from our main page; at best also via Tor: do nothing more than booting a clean computer from CD/DVD and execute sth. like torsocks wget http://www.elstel.org/auxil/estellnb.pubkey.asc. Use a Tails DVD for Tor or make sure with netstat -atupn that no harmful programs are running like f.i. an ssh daemon. Compare the obtained key files for equality. Do not take your USB stick with the key to an online computer which may always be compromised. Either compare for equality offline or use a read-only USB stick. You may also ask for the fingerprint via telephone though this is not a panacea either as telephone calls can be re-routed and eavesdropped as internet connections can. Be sure not to use a personal phone but perhaps a phone of a friend from a friend of yours. This is important because you will never know whether you are visiting the original site elstel.org or perhaps just an NSA mirror. You may additionally try to fetch the public key from one of the following key servers: keys.gnupg.net, pgp.mit.edu:11371, keyserver.ubuntu.com, pool.sks-keyserver.net, subkeys.pgp.net:11371 although we can not guaruantee the keys available there to be up to date which is a major disadvantage. Only the latest key must be used.
Now supposing you have obtained a genuine copy of our public gpg-key you need to follow some precautions in order not to render encryption useless or even harmful. At first never create your messages on a computer which is online if you wanna encrypt this messages later on. Any computer connected to the internet can be compromised and rooted within seconds as soon as you just open your web browser or email program. Even worse since about 2008 all modern PCs have a component called Intel ME (Management Extension). This component was virtually designed to allow remote maintenance for your PC. However intelligence services may exploit security vulnerabilities of this component in order to log into any computer they want to (learn more here). Consequently use an own offline computer which is booted from a known-to-be-clean boot CD or DVD for creating and encrypting your message; delete the original message from RAM or with shred from disk, put the encrypted plain text message (no other file formats!) on an USB stick and transfer the encrypted message to a computer which has access to the net. At best unplug your network cable and blacklist your wifi device driver before booting. This is so important because we need to trust in encrypted messages not having already been eavesdropped at the sender.
If you wanna have a response on your message please pack the public key of yours into the message. We wanna be sure that the response is directed to the originator of the message; thus we will not download your public key from the web. Create the private key (or that is to say the pair of private and public keys) on a clean offline computer and store it on an USB-stick or SDcard with read-only switch for later use. Always keep the private key with you. Never leave it on a computer at home. Intelligence agencies or other players may be able to enter your home when you are away because you can always be located by your mobile phone. Entering your home does not pose a problem: There are “universal keys” as also used at airports to examine your luggage which can open any physical lock. It may be hard or impossible to detect the loss of a private key as it can just be copied like any other data. Chip card readers may be a way out of this dilemma because then you need to steel the chipcard in order to take posession of the private key.
In case that you should already be targeted by a surveillance agency - whether you know about it or not - try to make sure that your hardware is clean. Note that f.i. the NSA regularely intercepts laptop shipments so that hardware ordered for your name may already be manipulated. The best way out may be a desktop computer built by your own where you can always see the mainboard and all components inside; notebooks tend to be hard to disassemble and you cannot do that every time you leave your computer unattendedly. Errors on a machine which can not be reproduced on another machine with the exactly same setup may either point to damaged or to manipulated hardware. Note that the necessary hardware manipulations may be rather hard to see, f.i. small alterations of the width of your USB-plugs.
Before you send your message consider whether it can be a disadvantage that a possible surveillance authority knows on who has communicated with whom. You have the possibility to send your message from a temporary disposable/throwaway e-mail address like those listed by TorVPN via Tor. Select one or two email providers of your choice from this list and do not do anything else than sending your encrypted message via the providers you have selected once you enter the Tor network. Tor users are under heavy attack by the NSA and other services and you may be traced back once you are attacked. The shorter you stay in the Tor net the lower is your likelihood of being cracked. The only thing which can prevent you from giving away anonymity may be Whonix. It puts the Tor client into a virtual machine so that compromising it does not abandon anonymity. However the only problem may be that you will not have a clean boot CD for Whonix. Likewise you may prefer a real OSS, i.e. a non commercial virtualization technology i.e. qemu because even virtualization does not constitute an invincible shield (while it is certainly somewhat harder to get bugs inserted in OSS software for intelligence agencies).
Last but not least tell us what security measures you have taken when sending your message to us. What kind of security mesaures may be appropriate depends on your threat scenario and the sensitivity of the information you wanna pass to us. Nonetheless we need to consider online encryption or openly storing private keys on computers which are used for web access and browsing to be piggery as that pretends some sort of elevated security where there is none. One of the worst fallacies when it comes to any kind of security need is to trust in something that should not be trusted in. Either consider sending your message as plain text or try to take some minimum security measures to escort encryption.
Finally we do not use our private key forever. All your encrypted messages may be stored by surveillance agencies or by some other party. Once they get the private key they can suddenly decrypt all of your messages! We are trying to avoid this by ultimately destroying our private keys at least whenever we have received information which can be considered sufficiently sensitive or whenever we did not succeed in shielding our private key as a mere preventive measure. We may save less sensitive messages in plain text along with our private key. New public keys will likely be signed with the old private key to make it easier for you to assert the source of the new key. However checking such a signature may be an insufficient measure because those who may have stolen the private key may also create their own successive key for eavesdropping; i.e. we believe there is little value in doing so. At best begin another time at point one. Revoked keys will be listed together with the new key under «contact» at the main page. Handle your own private keys likewise; at least those used to communicate with us.
Note that we consider anonymity to be the better security measure than the so called «web of trust» which can be infiltrated easily at an arbitrary point. Buy the CD/DVD you boot your clean system with at a newspaper stand. No eavesdropper or no intelligence agency can sell compromised versions of hardware or software to all the people as this would quickly be brought to public attention. It is almost always the case that certain people are targeted individually for any reason you may or may not know. Remaining anonymous means to remain save with a few exceptions: Users of the Tor network tend to be targeted or also such users who just wanna inform themselves about how to encrypt or stay anonymous. Users like you who have just read this text. Note that by reading this text you may already be under suspicion. This is not a joke.
The following is a quick reference about how to use gpg. You may additionally want to consult other sources of information:
> /usr/sbin/tor & > torsocks wget http://www.elstel.org/auxil/estellnb.pubkey.asc > also: gpg --keyserver xy.net --recv-key / --send-key email/key-id > gpg --armor --export yz.pubkey.asc
root> tor-resolve keys.gnupg.net
root> torsocks/torify gpg --keyserver 126.96.36.199 --recv-key 0x9981E39D
It should not matter which keyserver you consult since they are known to synchronize themselves regularely. A key retrieved like this can no more be compared via --armor --export file and cmp with estellnb.pubkey.asc because signatures of other people may already have been appended to the key as retrieved from the keyserver. Once you also have the gpg keys of these persons that will nonetheless pose a potential advantage in verifying the authenticity of the estellnb.pubkey (see for the «Web of Trust»).
Now reboot from DVD and take your computer offline (You may need to blacklist your wireless adapter.).
> gpg --import estellnb.pubkey.asc > gpg --fingerprint > gpg --list-keys > gpg --output mymessage.txt.gpg --encrypt --armor --recipient firstname.lastname@example.org mymessage.txt ( armor creates an ascii-output which can be sent via email. )
The so called fingerprint is a hash value which should allow you to check whether your copy of a public key is authentic. This is especially useful whenever you have received the fingerprint in person f.i. via a business card or whenever there is no other possibility to check two keys for equality. Remember that two copies of the same key may differ by the number of signatures attached to them (see: keyserver).
Or if you wanna have a response create a 4096bit RSA key. It is best to use the same level of encryption as we do. A chain is as strong as its weakest part. We suggest you to create a key without a passphrase and without automatic expiry date. A keylogger is installed easily so that a password does not give you any additional security.
> gpg --full-generate-key > gpg --list-secret-keys > gpg --edit-key C824B271CAEDF21BE9A28B785CA6AA8CBE270325 gpg> showpref gpg> setpref TwoFish AES SHA512 SHA384 SHA256 SHA224 BZIP2 gpg> save
If you have created a new key you should set your cipher/algorithmic preferences next. We recommend TwoFish as a symmetric cipher. Whenever you use assymetric encryption like RSA the whole message will still be encrypted symmetrically the assymetric algorithm just being used to encrypt the symmetric key because symmetric encryption is much faster. TwoFish is an algorithm invented by Bruce Schneier. TwoFish has made it to the final round of selecting an encryption algorithm for the Advanced Encryption Standard. Nonetheless we do not believe the actual choice of the NIST (National Institute of Standards and Technology) for AES as optimal (Rijndael). That is because government agencies do not only have interest in secure encryption but also in breaking the encryption of others. There is no known method to attack TwoFish while different methods have been discussed for AES. There exist some known cryptoanalytical attacks against AES-256 (key length of 256bit) which may be less safe than AES-128 because of the special properties of the algorithm (look at this article). Note that we have stated TwoFish before AES (which means AES-128) at setpref so that it will become the default choice when encrypting messages for this key. Unfortunately TwoFish is not selected by default as usable algorithm so that specifying --cipher-algo twofish on the command line will not help under most circumstances. We have chosen bzip2 as compression algorithm which does compress better than gzip. Besides this bzip2 has several asserts (checking of consistency conditions) in its code so that it should be more hard to infect a computer by merely executing the uncompression algorithm. It is basically desireable to encrypt compressed data because compressed data has a higher entropy and thus less redundancies which could be used to crack encryption.
> gpg --armor --export maxmustermman.pubkey.asc > chmod 444 maxmustermann.pubkey.asc; > gpg --armor --export-secret-keys /media/usbstick/maxmustermann.privkey.asc; > chmod 400 /media/usbstick/maxmustermann.privkey.asc; ( you may also touch and chmod the file first; chmod also the .cpio ) > or: find ~/.gnupg | cpio -H crc -o >/media/usbstick/maxmustermann.gnupg.cpio > cpio -tdv </media/usbstick/maxmustermann.gnupg.cpio > at a later bootup use: cpio -idvu </media/usbstick/maxmustermann.gnupg.cpio … > gpg --output amassage.txt --decrypt amassage.txt.gpg
Note that the --armor option is required as soon as you want to print or transmit a message via email. It converts to an ascii/character based notation rather than creating binary data.
If you are planning to have a longer correspondence or if you just wanna communicate in both directions then you should sign your messages. A message being signed says that you have been in the possesion of the secret key and thus that the message comes from you. Signing is especially important if both parties undisclose their public key. Please also mind that you should apply the same security measures to the key you use for signing as the one you use for encryption (as opposed to some suggestions in the context of the «Web of Trust»). Getting messages signed may be hardly less important than encrypting at least for a mutual dialogue. Thus the keypair for signing and encrypting should always be generated and destroyed together.
> gpg --output mymsg.txt.signed --personal-digest-preferences SHA512 [--local-user email@example.com] --clearsign mymsg.txt > später: gpg --verbose --verify mymsg.txt.signed
Now you can sign and later on encrypt your messages. Even so it is possible to just sign and publish a message. That way other people will be able to gain some sort of certainty that a message was in deed published by you (the sender of an email address can be faked very easily for everyone who knows the SMTP protocol.). gpg just appends a trailer to your message which contains the signature. We recommend that you specify the SHA-512 algorithm for signing as otherwise the known unsafe SHA-1 might be used. The key-number or the key-email may in case of ambiguity be specified by --local-user or -u.
> or: gpg --output mymsg.txt.gpg --encrypt --sign --personal-digest-preferences SHA512 --armor --recipient firstname.lastname@example.org mymsg.txt > später: gpg [--output mymsg.txt] --verbose --decrypt mymsg.txt.gpg
You can furthermore combine both steps easily. Then gpg will output an additional message that it has verified the authenticity of the sender on decryption. The --verbose flag is here to show the used hash algorithm (SHA-512/256) and the RSA-key-lengths (f.i. 3072 or 4096). However we rather prefer to keep both steps separated.
If you have some material which you wanna hand to us once and that`s it so then you do not need to sign (though it still might be interesting for us). You just need our public key; don`t even generate your own keypair. Possibly you want nobody to know who has brought that to the public. Then signing would be a bad idea.
Once you have used gpg it will create a file called ~/.gnupg/gpg.conf (a default ‘skeleton’ configuration file to do so may reside below /etc/skel/.gnupg/). It is worth to have a look at this file as you may not only set some default preferences like f.i. your default-key there but as it can also relieve you from the act of retyping the same long-options like --personal-digest-preferences again and again which is a security risk as you may forget them one day. Just have a look at the following example excerpt of our gpg.conf:
default-key 02530C63 charset utf-8 personal-cipher-preferences TwoFish AES128 personal-digest-preferences SHA512 group online = 02530C63 group offline = 9981E39D
Having a default-key is useful for the purpose of signing so that you do not need to specify the --local-user option. The group option is also interesting as it allows you to define aliases for certain keys (as returned by gpg --list-keys). While the email adress is more often used as an alias for the key ID the group option may be a viable alternative once you have two keys associated with the same email (f.i. one key used for online encryption and another one for offline usage). Personal digest preferences should default to SHA5-512 or SHA-256 in order to avoid the unsafe SHA-1 (as stated above). Finally utf-8 is the default charset on most distributions nowadays so that you should instruct gpg to use this charset for metadata (the charset of the message itself will be preserved unchanged.).
> gpg --card-status > gpg --card-edit gpg> help
Once you would also like to use gpg on a computer connected to the internet you may need a OpenPGP encryption smart card like those from the FSFE (Free Software Foundation Europe) in order to prevent your key from being stolen. To make use of such a card you will first need a card reader. Alternatively you may purchase a so called shell token which turns the card-chip together with an USB stick into an integrated chip card reader (see at the FLOSS shop). Then you have to install scdaemon in addition to gpg2. Make sure that you have not installed pcscd as this program is known to interfere with scdaemon. As pcscd may be required for other types of chipcards like the Austrian citizen card (via Java) you may alternatively start/stop/boot-enable/disable the pcscd via systemctl status/start/stop/enable/disable pcscd. After that you may mainly use the two commands from above to access your card. Though various other manuals will recommend you to make a backup of your secret keys before loading them on the card we wanna discourage you strongly from doing so. If someone else finds your backup medium that will compromise your key without your knowledge which is a worst case scenario. Not to use GnuPG is far better than to deceive unsuspecting people by a non-existant security. Just generate and backup a revocation certificate for your secret key (We will show you in 'Web of Trust' how to do that). Once the card gets lost and you do not find it any more you will have to tell your friends about the new key again after having quickly published your revocation certificate. Remember f.i. that intelligence services have universal keys and may enter your home while you are away (something they can easily see by locating your mobile phone). An additional interesting function of your gpg smart card is that you can use it to authenticate with SSH.
Concerning us our online encryption smart card is only used with a specially secure workstation booted from a carry-with-you USB-stick. We merely use it with an ftps program and a browser where all default certificates have been removed. The only DANE and Tor verified certificate on there currently is to access our hosting provider including a web mail facility. Graphical email programs may have their own flaws and we currently use none. Using a smart card in a secure environment is so important for encryption as the attacker may view your message in plain text when using a compromised machine. Smart cards can only shield against the case of stolen keys (as long as you do not “backup” your secret key which is fool´s instruction) because there is no way to get a key out of the card once it is in there. If you do only want to sign (but never encrypt), that can still be secure on a compromised machine as long as you keep an eye of the signature counter of the card which increments on every usage. Note that your PIN may already have been grabbed by a key-logger without your knowledge (a good cracker does not leave any traces in the logs). Changing the PIN all the time is not a solution either as you never know in an insecure environment when your machine would have been compromised the last time. Additionally the gpg card will destroy itself when you forget and enter the PIN wrongly too often.
An important information for the usage of your gpg card is that unfortunately it often will only keep your secret key but not your public keys. As a consequence you need to keep a save backup of your own public key; it contains additional information being signed by but not being part of your secret key on the card!
Though some practices which are usually associated with the Web of Trust have been criticized in here we believe it is still important to know something about it. Our critics do mainly pertain to the usage of unsafely stored, unsafely used and outdated master keys as used for signing. Nonetheless under certain circumstances it can be very useful to trust in a key verifiably signed by someone else presumed that you have no verifiably authentic master copy of the key.
Now let us start with something very simple. Suppose you have decided to import your private key into an empty and fresh gpg database instead of restoring a backed up old database with cpio. Now gpg will not know that the private key is really yours. This may become a problem when it comes to check signatures (Encrypting and decrypting would already work well.).
amnesia@amnesia:~$ gpg --import estellnb.privkey gpg: keyring `/home/amnesia/.gnupg/secring.gpg' created gpg: key 9981E39D: secret key imported gpg: key 9981E39D: public key "Elmar Stellnberger (…) <email@example.com>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: secret keys read: 1 gpg: secret keys imported: 1
You can circumvent this problem by assigning ultimate trust in the “signing capability” of your own key. This means that you will trust any key which you have signed. Signing known good keys may be a good practice in order to suppress warnings on decrypting signed messages. By signing a public key you tell gpg that you consider it good f.i. because you have checked its fingerprint as obtained from a reliable source.
amnesia@amnesia:~$ gpg --edit-key firstname.lastname@example.org gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 4096R/9981E39D created: 2015-01-10 expires: never usage: SC trust: unknown validity: unknown sub 4096R/0D5B5869 created: 2015-01-10 expires: never usage: E [ unknown] (1) Elmar Stellnberger (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <email@example.com> gpg> trust sub 4096R/0D5B5869 created: 2015-01-10 expires: never usage: E [ unknown] (1) Elmar Stellnberger (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <firstname.lastname@example.org> Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y pub 4096R/9981E39D created: 2015-01-10 expires: never usage: SC trust: ultimate validity: unknown sub 4096R/0D5B5869 created: 2015-01-10 expires: never usage: E [ unknown] (1) Elmar Stellnberger (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <email@example.com> Please note that the shown key validity is not necessarily correct unless you restart the program. gpg> save Key not changed so no update needed.
Note that the 4096R/9981E39 says that it is a 4096 bit RSA key with the given hashed key id written after the slash (the last seven digits of the fingerprint). You need the key id whenever you want to retrieve a key via a key server since the email address alone is not enough information to do so. Here we switch the trust in our own key from unknown to ultimate. Do not let yourself be irritated by gpg showing an unknown validity for our ultimately trusted key by now. After another --edit-key with a gpg> list - command it shows ultimate trust and the implied ultimate validity for the public/private keypair we have just imported. The editing mode can be left with save or quit where you are asked once more whether you wanna keep your latest changes.
As you can see gpg had not just generated one key for us but one master key for signing (usage: SC, «sign, certify») and a subkey for encryption (usage: E). This is the default option for --gen-key (RSA and RSA). RSA is a well known, founded and analysed assymetric encryption algorithm based on factoring primes which you can trust in if it is implemented correctly. If there are many subkeys you can select a specific subkey with key Number when being in the --edit-key mode. You may enable and disable subkeys so that they either can or can not be used for encryption. However usually when you add a new key with addkey you will first revoke the previously used and selected key with revkey because there is hardly any reason to have two keys used for encryption at the same time. The newer one tends to be the better one as it will less likely have been compromised.
Subkeys can be revoked but never more deleted once they have been uploaded to a keyserver. Nonetheless it may likely be necessary to exchange your master key from time to time as well especially when it is not stored on a special encryption card and can be copied any time. Use gpg --output mykey.revoke.asc --gen-revoke firstname.lastname@example.org to achieve this; publish your revocation certificate and then a new master key at best also signed with the old master key. The passwd command can be used to reset the password you need for decryption and signing. You may want to do this if you should ever have plugged a secure encryption card in an online computer (or a computer compromised in any other way). Your keystrokes could have been monitored. As keystrokes can be monitored easily on a compromised machine you may want to decide to do even without such a password. However then you will need to be quick to publish your revocation on loss of the card.
There are a few other things you may want to know. At first if you wanna get rid of warnings issued by gpg when checking signatures you need to sign public keys from other parties you wanna communicate with. Do so by issuing an --edit-key on the others` public key, type fpr, check the fingerprint and finally use sign to assert the validity of the key. Basically you should not sign a key which you do not think of as trustworthy but rather check the fingerprint on every decryption; at least do not upload your signature to a keyserver if you do not know or if you are not persuaded by the key handling and security measures taken by the other person. Once you have signed a public key your signature for it will be exported on every --export you issue on it. You may do this for your own later use or if you wanna show the world that you consider a key and its user as having been verified by you as well as having good security practices. If you do not wish to do so just use delsig to remove your signature from the other key before exporting that public key.
Finally there is some additional feature by gpg called user id management. A user id always pertains to the master key and can indicate mutlitple usage purposes as well as email addresses to be used together with that key. The commands to select an uid, to make it the primary one to add and delete an uid are uid Number, primary, deluid, adduid.
These are all basic commands you need to know (more are listet in the gpg man page). Let us now come back to the Web of Trust and why it is called like this. We have mentioned in the beginning that it is possible for gpg to check the validity of a key based on the signature of other people whom you trust. This is good practice.
Now consider the following example: You have just communicated with email@example.com over gpg and are now assigned to a specific staff member who has his own key. Now you may assign full trust in the key signing policy of the firstname.lastname@example.org key. If your staff members` key has been signed by the email@example.com key and you already have imported that key then gpg will establish a chain of trust from the info key up to your staff members key so that you do not need to re-check, verify and sign the new key no more. Note that such a chain of trust may only entail a limited number of hops (as given by the --max-cert-depth option). It should be clear that a linear chain is broken if any of its keys gets compromised. Don`t trust anyones signed keys fully if your security needs should be critical.
That is why you would normally only assign marginal trust to the key signing customs of other people. Then you need --marginals-needed Number signatures from other peoples unless gpg trusts that key (There is even a --completes-needed option.). Not a too bad problem if you have enough time to collect and assert other peoples` public keys you may say. However too old master keys may not be trustworthy either. That is where the cat starts to hunt for its own tail and why the Web of Trust is only half as good in practice as in theory; at least unless everyone had a secure encryption card where the private key is generated on the card an will never leave the card; and unless everyone using gpg entailed good security practices as described herein. In that case only a loss of the card would trigger an invalidation of your master key. It certainly needs to be mentioned that a secure card will not alleviate you from the issue of having to encrypt on a clean offline computer because eavesdropping a message when it is still in plain text is always most easy to do (secure cards only used for authentication via ssh do of course pose an exception to the “offline rule”).