wiki:doc/TorifyHOWTO/GnuPG

Read first!!!

Visit GnuPG (GPG) site, and obtain GnuPG which is suitable for your OS (operating system) or platform.

GnuPG site's current self-signed SSL cert is under CAcert.org, and CAcert.org's root CA cert may not exist in some web-browsers yet, for such cases, check: SHA1 fingerprint of SSL cert for https:www.gnupg.org is: 5A:AB:77:27:14:8A:5D:6D:6D:B3:B4:43:11:09:79:56:AC:FE:18:8A, and this SSL cert's domain is actually trithemius.gnupg.org and valid upto 2015-09-09, this SSL cert is still valid for https://www.gnupg.org, as it at-least allows to obtain files more securely & view info more securely, than using http (non-encrypted connection). Using https (encrypted connection), is very important when using any type of proxy, and Tor is a proxy.

PGP was re-invented as OpenPGP, then OpenPGP was again re-invented as GnuPG, aka GPG. GnuPG (Gnu Privacy Guard, "GPG") or PGP (Pretty Good Privacy) or OpenPGP, allows to send "signed" (integrity signature) and+or "encrypted" (confidential) email messages, and also allows to "verify" (authenticate) and "decrypt" (decipher) email messages. GnuPG/GPG/PGP also allows to "sign" and+or "encrypt" files, and can also "verify" and "decrypt" files. There are many other use cases for GPG/PGP/OpenPGP other than this two mentioned cases, as newer edition of software now able to handle more algorithms, ciphers, etc. Also see wikipedia GPG page for related info and other tools.

GnuPG, GPG, OpenPGP, PGP, etc related IETF RFC list: rfc4880 (OpenPGP Message Format) (Nov 2007), rfc3156 (MIME Security With OpenPGP) (Aug 2001), rfc2015 (MIME Security With Pretty Good Privacy), rfc4086 (Randomness Requirements for Security) (Jun 2005, BCP 106), rfc2440 (OpenPGP Message Format) (Nov 1998), etc.

Offical information from torproject.org

  • About GPG Signatures
  • GPG signing keys from Tor core people

    Note: TorProject.org domain-name is DNSSEC signed, and it has also publicly declared it's SSL cert hash in TLSA/DANE DNS record. Next advanced version of DNS, is DNSSEC, and DNSSEC is even further improved with DANE. Do not always stick with older DNS. So use your own local full DNSSEC supported DNS-Server or DNS-Resolver software (BIND from ISC, Unbound from NLnet Labs, etc), and use DANE aware addon/extension or DANE supported web-browser, to very accurately verify, if your HTTPS (encrypted) connection (with TorProject.org) is really using the correct & declared SSL cert or not. In this way you can be sure, that, no one in the middle has altered/modified any content shown on an encrypted webpage. DANE helps to lower or (almost) eliminate SSL/TLS cert based & related forgery/fakery/forwarding, etc attacks.

Newer advice October 2012

From Jacob Appelbaum

Jacob Appelbaum recently worked on GPG torification. Read: #2846 Patch GPG to support SOCKS proxies and help expand this section.

Things you should know

  • Getting the GPG key or GPG fingerprint from a TLS secured website is only as secure as TLS and the webserver, see TLS / SSL / https.
  • GPG short key IDs are not safe! Anyone can easily create a duplicate and upload it to a keyserver.
  • A secure connection with the keyserver, no matter if .onion or https, hkps, DNSSEC or everything together, is a good goal, but...
    • A good goal, because it prevents (or makes it much harder) third parties to inject malicious traffic (exploits) into the traffic.
    • Otherwise it does not buy you much. Anyone can upload any key for anyone to a keyserver. Keyservers do not delete malicious keys. If you get a key from a keyserver, you still have to verify the fingerprint of the GPG key.
      • You still to obtain the GPG key over a pre-shared secure channel.
        • TLS does not buy you much either, see first point.
        • Or you still need to use the Web of trust.
  • Key servers only for convenience: you only need to securely share the comparable small fingerprint of a GPG key and can download the big full blown public key from the keyserver.
  • Uploading your key to a keyserver can result in receiving spam.

List of OpenPGP & X.509 Keyserver or Pool Keyservers

PGP/OpenPGP/GnuPG/GPG 'keyserver' which supports HKPS or HTTPS, those keyservers use TLS or SSL certificate (cert) based encryption and authenticated communication. Users who will use any type of proxy, then using encrypted connection is very important aspect for keeping data integrity intact/unmodified. By default, HKP uses non-encrypted TCP port 11371, HKPS uses encrypted TCP port 443, HTTP uses non-encrypted TCP port 80, HTTPS uses encrypted TCP port 443. Keyservers, which use (keyserver) domain-name owner's own created/self-signed (stand-alone, domain-issued or end-entity) server SSL/TLS cert, or keyserver which uses other free CA's (Certificate Authority) Root cert based certs which are not (yet) included with OS or GnuPG/GPG tools, or keyserver which use domain-name owner's own created/self-signed ROOT CA cert (or TA, Trust Anchor cert) and own server/domain cert under such ROOT CA or TA cert, then for such cases, in client side, users need to specify such SSL/TLS certificate using the "ca-cert-file" gpg option in gpg command-line, and then users also need to specify SSL/TLS cert file's directory location & file-name. Such SSL/TLS certificates can also be pre-specified inside the "gpg.conf" configuration file, by using the "keyserver-options" gpg option. A keyserver can use alternate (or, a different) port, than previously mentioned network ports. Some keyservers which support HKP, they usually or may also support HTTP. Keyservers which support HTTPS, may also support HKPS. Keyservers, in below, which show "DNSSEC" support, their DNS data are DNSSEC-signed for enhancing connection's security, and keyserver which shows "DANE" support, they have declared/shared their SSL/TLS cert's hash or full hex code in the TLSA DNS record, so that client-side users can check if connection using a correct SSL cert or using a fake/forge SSL cert. Keyservers which shows the word "server pool", are able to obtain key from other keyserver(s), and they sync(share) key collections with each others.

Few keyservers are listed below:

A = IPv4 IP-address. AAAA = IPv6 IP-address. NS = Name Server. AS = Autonomous System Number. CNAME = Alias canonical name.

  • zimmermann.mayfirst.org : supports HKP (11371), HKPS (443). Uses own domain-issued own/self-signed cert. Root/CA-cert is here.
    • keys.mayfirst.org : supports HKP (11371), HKPS (443). Uses own domain-issued own/self-signed cert, same as above.
    • Location (checked ~ Nov 11, 2013) & Publicly available information : IP-address (A) : 216.66.15.2. Country: United States (US). Datacenter: Hurricane Electric. Inc. AS#: 6939 (HURRICANE). Registry: ARIN. Other IP-address (A, AAAA) : 81.95.52.77, 216.66.23.39, 2001:470:1:116::6, 2001:470:1:116::4. NS: b.ns.mayfirst.org, a.ns.mayfirst.org.
  • keys.indymedia.org : supports multi-protocols: HKP (11371), HTTPS (443), HKPS (443), HTTP (80). Uses CAcert.org signed cert, few Linux distro pre-includes this Root cert, for others use "ca-cert-file" gpg option. Root cert is here (CAcert.org, get the Class 1, and also Class 3).
    • qtt2yl5jocgrk7nu.onion (Indymedia) : supports HTTPS (443), HTTP (80) & HKP (11371).
    • 2eghzlv2wwcq7u7y.onion (Indymedia) : supports HKP (11371), HTTP (80). Tails (source and reasons: Tails Design), Whonix (source: gpg.conf) and Torbirdy prefer 2eghzlv2wwcq7u7y.onion
    • Location (checked ~ Nov 11, 2013) of keys.indymedia.org and Publicly available information : IP-address (A) : 204.13.164.120. Country: United States (US). Datacenter: SWIFT VENTURES Inc. AS#: 25700. Registry: ARIN. NS: ns2.riseup.net, ns2.fs-dl.net.
    • Location (checked ~ Nov 11, 2013) of https://www.indymedia.org and info : IP-address : 72.232.204.178. Country: United States (US). Datacenter: Layered Technologies, Inc. AS#: 22576 (LAYER3-ASN). Registry: ARIN.
    • Connect with CAcert.org over HTTPS (443) by using this site-address: https://www.cacert.org, it is currently using a SSL cert with these info : CN: www.cacert.org. SHA1: 21:64:C0:49:B0:01:B7:A8:4E:45:9B:A6:F0:D7:EF:23:2C:FC:AD:58. Valid upto 2014-05-06. Then obtain CAcert.org's Root Cert(s) from here. If you are using or connecting with CAcert.org via TorBrowser, then you must make sure that CAcert.org's Root Certs have info shown below, best is to connect with https://www.cacert.org directly without TorBrowser, and get CAcert.org's both root cert files. CAcert.org domain-name is DNSSEC signed, and TLSA/DANE signed/declared, so if your computer using a full DNSSEC supported DNS-Server or DNS-Resolver software (or if you use a remote trusted full DNSSEC supported DNS-Server over encrypted connection), then no one in middle can use a forged SSL cert or give you fake info.
      • CAcert.org's Class 1 Root CA cert uses CN: CA Cert Signing Authority. SHA1: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33. Valid upto 2033-03-29. SN: 00.
      • CAcert.org's Class 3 Root CA cert (under above class 1 root cert) uses CN: CAcert Class 3 Root. SHA1: AD:7C:3F:64:FC:44:39:FE:F4:E9:0B:E8:F4:7C:6C:FA:8A:AD:FD:CE. Valid upto: 2021-05-20.
  • hkps.pool.sks-keyservers.net : supports HKP (11371), HKPS (443). To use HKPS get TLS cert from here, and follow instruction shown there.
    • Connect to SKS-Keyservers over HTTPS, and received SSL cert should have these: SHA1 fingerprint is: 5B:8B:C9:B4:FC:EF:3A:42:B7:B1:38:D7:AF:E8:57:82:AD:BA:D4:1A, it's domain is www.kfwebs.net, valid upto 2014-01-05.
    • pool.sks-keyservers.net : server pool. supports HKP (11371). More info and overview of pool list.
    • sks.fidocon.de : part of server pool. Supports HTTPS (443), HTTP (80). IP-address: 79.140.41.143. Country: Germany (DE). Datacenter: vollmar.net GmbH. AS: 31333 (VOLLMAR-AS). Registry: RIPE NCC.
    • Location (checked ~ Nov 11, 2013) & Publicly available information : IP-address (A) : 91.205.174.236. Country: Germany (DE). Datacenter: Contabo GmbH. AS#: 51167 (CONTABO). Registry: RIPE NCC. Other IP-addresses (A, AAAA) : 5.135.166.171, 79.140.41.143, 80.239.156.219, 84.215.15.221, 85.10.205.199, 89.68.150.88, 91.205.174.236, 176.9.51.79, 192.146.137.11, 193.17.17.6, 79.143.214.194, 144.206.6.71, 199.74.220.4, 83.169.43.165, 5.45.182.194, 131.155.141.70, 83.160.80.43, 208.68.39.189, 2001:67c:26b4::2c6b, 2001:16d8:ee3d:ee30:215:5dff:fe00:120d, 2001:41d0:8:e9ab:4e72:b9ff:fe4f:422, 2001:4d88:1ffc:477::7, 2a01:4f8:a0:4024::2:, 2a01:4f8:150:7142::2, 2a01:7a0:1::6, 2a02:c200::10::404:211, 2a00:1280:8000:2:1:1:0:53, 2001:1868:53::53, 2a02:e00:ffff:fffb::e721:4ebc, 2001:610:1108:5011::70, 2001:980:d7fe:1::7, 2001:4830:1662::53. NS: ns1.kfwebs.net, ns2.sks-keyservers.net, ns5.sks-keyservers.net, ns6.sks-keyservers.net, ns7.sks-keyservers.net, ns9.sks-keyservers.net, ns10.sks-keyservers.net, ns11.sks-keyservers.net, ns12.sks-keyservers.net.
  • subkeys.pgp.net : server pool. supports HKP (11371).
    • Location (checked ~ Nov 11, 2013) & Publicly available information : IP-address (A) : 195.113.19.83. Country: Czech Republic (CZ). Datacenter: Cesnet. AS#: 2852 (CESNET2). Registry: RIPE NCC. Other IP-addresses : 116.240.198.71, 202.125.45.72. PTR: keys.riverwillow.net.au, pks.gpg.cz, keys.keysigning.org. NS: orgo.progsoc.uts.edu.au, dns0.cl.cam.ac.uk, ns0.pipex.net, ns1.pipex.net, robin.dfn-cert.de, nac.no.
  • pgp.mit.edu : supports HKP (11371).
    • Location (checked ~ Nov 11, 2013) & Publicly available information : CNAME: cryptonomicon.mit.edu. IP-address (A) : 18.9.60.141. Country: United States (US). Datacenter: Massachusetts Institute of Technology. AS#: 3 (MIT-GATEWAYS). Registry: MIT (LEGACY).
  • keys.gnupg.net : server pool. supports HKP (11371).
    • Location (checked ~ Nov 11, 2013) & Publicly available information : CNAME: pool.sks-keyservers.net. IP-address (A) : 216.66.15.2. Country: United States (US). Datacenter: Hurricane Electric, Inc. AS#: 6939 (HURRICANE). Registry: ARIN.
  • keyserver.pgp.com : supports HKP (11371).
    • Location (checked ~ Nov 11, 2013) & Publicly available information : IP-address (A) : 216.168.253.144. Country: United States (US). Datacenter: Symantec Inc. Origin AS#: 25485, 53401 (SYMAN-5). Registry: ARIN. Other IP-address: 207.7.148.111. NS: udns1.ultradns.net, udns2.ultradns.net, pdns1.ultradns.net, pdns2.ultradns.net, pdns3.ultradns.org, pdns4.ultradns.org, pdns5.ultradns.info.
  • pgp.surfnet.nl : supports HKP (11371). DNSSEC signed.
    • Location (checked ~ Nov 11, 2013) & Publicly available information : IP-address: 145.100.185.229. CNAME: kerckhoffs.surfnet.nl. Country: Netherlands (NL). Datacenter: SURFnet, The Netherlands. AS#: 1103 (SURFNET-NL) (NET145). Registry: RIPE NCC. Other info: NS: ns1.zurich.surf.net, ns1.surfnet.nl, ns3.surfnet.nl, ns0.ja.net, ns2.surfnet.nl.
  • pgp.webtru.st : supports multi-protocols: HKP (11371), HKPS (11372), HTTP (80), HTTPS (443). Uses Startcom SSL Cert, usually pre-included in most OS/platform.
    • Location (checked ~ Nov 11, 2013) & Publicly available information : 173.164.61.44. Country: United States (US). Datacenter: Comcast Cable Communications, Inc. AS#: 7922 (COMCAST-7922). Registry: ARIN. Other Ip-address (A) : 173.164.61.33. NS: ns3.afraid.org, ns2.nayr.net, ns4.afraid.org, ns2.afraid.org, ns1.afraid.org, ns1.nayr.net. CNAME: webtru.st.

Note: Usually in Enigmail, Kleopatra, OpenPGP, etc GUI tools, under the "keyserver" field, you can specify just keyserver's host-name, no need to specify protocol or scheme portion (HKP/HKPS/HTTP/HTTPS) ahead of it, as there are usually other drop-down select option to choose a scheme for each keyserver, but inside "gpg.conf" or in command-line or in other configurations or to be more specific about protocol, it is better if you specify it specifically, (for example):
To use HKPS, specify : hkps://zimmermann.mayfirst.org
To use a specific or alternative network port based HKPS keyserver, use like this : hkps://pgp.webtru.st:11372
To use HKP, specify : hkp://zimmermann.mayfirst.org

Note: Here, "CA cert" or "CA certs" or "CA-cert" is also known as "Root Cert", it means "Certificate Authority" based certificate(s). It is not the "CAcert" or "CAcert.org" which is a certificate signer company. So, "CA cert" usually indicate towards a X.509, TLS, SSL, S/MIME etc certificate, which is used for signing other certs. Most widely known and used CA certs or Root Certs, and commercial CA's root certs, are already pre-included with major OS, or, in your (major) Web-Browser, or, in your (major) Email-Client, or in your (major) IRC client software etc. If a CA's root cert (or your own created root cert) is not pre-included, then you will have to manually add it in your root cert (bundle or database) file, it's location and filename varies based on OS & platform, or manually specify it's location & name in the software which will use (TLS) encryption. Most CA's Root Cert now uses Intermediate root cert, so you will have to add such Intermediate root cert as well. View this section on how to use ca-cert in GnuPG for keyservers.

Extra Note:

  • (Bry8Star's opinion) When you want to forward GPG/PGP traffic through any type of Proxy, then, use keyservers which supports HKPS (Secured HTTP Keyserver Protocol) or HTTPS and should be preferred & used, HKPS or HTTPS uses TLS/SSL (port 443) protected & encrypted connections, from client side to server side, and if connection in between client and server, is using another/further layer of encryption+decryption for both side's ending-points, then it is even better. And such should be avoided : using HTTP (port 80), HKP (port 11371) or other non-encrypted ports or connection, because "unknown" proxies and middle nodes and gateways and possible MITM exists in the path of Web of Trust(WoT), with "unknown" level of chance of alteration at various stages & components, DNS cache poisoning, etc. Hidden Service (aka, HS, onion-host) based server is better than an open internet servers. And HKPS/HTTPS based HS is better than HKP/HTTP based HS servers. And avoid using such keyserver which falls under the jurisdiction or physically located inside the oppressive & abusive & MASS scale SURVEILLANCE supported country/location.
    Various client software automatically starts to download keys/certs in various client software, if & when HKPS is used, HKPS makes sure, such client software has at least connected securely with that keyserver, so someone in middle do not know what exact query or info a user has obtained or delivered. Its about connection's Privacy & Security (stronger TLS/SSL creates more Privacy), and accuracy (advanced DNS that is DNSSEC, creates more Accuracy).
  • (adrelanos's opinion) You should blend in and use the same keyserver as many other people and projects do.

You may skip below WoT related section, and goto next section: Torify GPG on Windows.

WoT, GPG, Security, Proxy

WoT (Web of Trust) : People or PERSON, or a Person representing a group/organization/team/entity, when physically (face to face, human to human, directly) has shown/displayed you, trustworthy enough Photo Identity credentials & documents(docs) with his/her Name and Photograph, and if this Person has also provided you, his/her own GPG/PGP key full fingerprint, AND/OR also the GPG/PGP full PUBLIC-KEY in a file, which must include his/her NAME and email address (RFC2822), then (FIRST STAGE is), after checking documents and files, if you find identity verifying document's NAME portion, is a (exact) match with the NAME portion used with the provided/given full fingerprint info (AND/OR, also exactly matched with the NAME portion in the provided GPG/PGP full public KEY file), then first portion of a User-ID (or UID) field, which is the NAME portion, is verified. So SECOND STAGE, is to make sure the provided/given fingerprint or KEY, really belongs to the correct Person whose NAME portion of UID is already verified, so you will have to send an encrypted only email toward the associated email-address which is shown next to the verified NAME of that UID field, by typing a secret long code-number or word in email's message/body/content field. If this person can receive & decrypt, and can reply with that secret long code-number or word, at that moment it proves, that Person really owns the correct PRIVATE key associated with the provided/given public KEY. Then all portions of User-ID (or UID) verification process will complete. After those two stages of checking or verification, you can "Sign the pub key", or "Sign key" of that Person. By using GnuPG/GPG/PGP/OpenPGP software you can now do the "Sign key" steps, what software does is: it uses your own GPG/PGP (secret PRIVATE) key, and adds a "Certification" type of "signature" packet/code, based on the public KEY of that Person, inside that public KEY. There are common four types of Certification signature to indicate level of verification for UID/User-ID (NAME & EMAIL-ADDRESS) and KEY : 0x10 = Generic, 0x11 = Persona, 0x12 = Casual, 0x13 = Positive. For the fairly thorough checking procedure mentioned in this paragraph, you should select GPG/PGP software option, like: "I have done very careful checking" (it is a Type 0x13 signature code/packet). Few other "signature" shown in para 5a. Many users do not want their key to be present in a keyserver, so if someone requested you not to uplaod signed-keys into any keyserver, then do not do it, so after "Sign the pubkey" of that person, export that person's pubkey to a file, and "copy" codes from it, and "paste" into the message/body/content area in an encrypted email (do not attach as file, but if you do make sure to encrypt the attached file as well), send encrypted email to that Person. If that person do not mind placing key into a keyserver, then you may upload it if he/she has permitted you, upload only to a "trust-worthy" keyserver, by using a "secured" connection. Finally set KEY Owner-Trust level in GnuPG software for users. Select any one of the owner trust level choices : 1 = Don't know, 2 = I do NOT trust, 3 = I trust marginally, 4 = I trust fully, 5 = I trust ultimately, based on how far you are willing to trust the owner of the KEY, to correctly verify other users' (public-)keys by checking Passports/Photo-ID, GPG/OpenPGP/PGP pub key fingerprints from different sources, etc. Owner-Trust is stored in a type-5 subpacket/code, under a "signature" packet/code. for . , . of Type 0xProcess (of "Signing the pubkey") mentioned in this paragraph (from paragraph's beginning), is considered to be the top-most & very strong step of growing a Web of Trust (WoT) among humans/users.

  • 1. WoT is a decentralized PGP/OpenPGP/GPG key certifying PKI mechanism for message & file data integrity, much different structure, than a centralized key certifying authority which is used for commercial SSL/TLS, S/MIME, (X.509), certificates.
  • 2. In WoT, people/users need more & other people/user to "sign" & trust their public-key, to increase trust level, of their own public-key. So attend Key-Signing-Party, where you can connect with like minded people/person.
  • 3. So a non-lazy user must try first such direct path, then try other alternative WoT paths, steps & inquiries (which can provide authentic verification of who is the actual owner of what KeyID or fingerprint.
    • 3a. First thing you will have to (try to) do (for WoT) is to physically meet/connect with the PERSON/HUMAN/ENTITY who you are trying to communicate, DIRECTLY (physically face to face, human to human), without using ANY type of MEDIUM/MIDDLE-MAN/MEDIATOR, (not even a GnuPG/GPG/PGP keyserver, as keyserver is also a middle-man, neither Video over IP (like Skype).
      • 3a-1. It is already explained few paragraph above. Exchange PGP/GPG public keys (and other public keys, certs, fingerprints, secret-codes, user-ID, etc) directly, by using non-infected FAT16 or FAT32 USB flash drives/sticks, Floppy-drive, etc. (Make a backup of your current (public+private) keypair with date+time and compress into a password encrypted file, so keep a command-line or portable 7-zip or similar software in your USB drive, along with last stable GnuPG command-line software). After both side signs, get back your disk/USB drive/stick, import your own public-key, this trusted public-key will show, who trusts you, inside its signature area.
      • 3a-2. But it is not practically possible for all people/person to meet all other type of people/person they communicate with, to exchange + sign each other's public-keys (and/or fingerprints), and many people will not even like or want to or have time to meet all other people face to face. And it is also possible that a person is somehow impersonating/faking someone else with fake/forge documents, so you should/must also have PRE-KNOWLEDGE on the Person's known Photo and correct Name, who you are trying to "trust" or "sign" keys. You must also have PRE-KNOWLEDGE on Identity documents (docs), which docs are genuine and which docs are false, to sign with 0x13 Trust Type level. And such PRE-KNOWLEDGE also needs other reference(s) and also needs depending on AND trusts in other Systems/Agencies/Groups, (like: Government agency issued Photo ID, etc).
    • 3b. If you cannot meet the Person physically face to face, then in next step (for WoT), you will have to try to reach the next closest (physical) TRUSTED OBJECT/THING of that person, which that Person "trusts".
      • 3b-1. Things that Person himself/herself trust, can be : what he/she himself/herself has published for others/publicly, so check for PGP & GPG info on such long-lasting printed/physical materials (like: Book, Novel, Research paper, etc), or that Person's own hand written materials, which that Person himself/herself has published or distributed or given directly in your hand. Not such material which others (another middle-man) has published on behalf of that Person (who you are trying to communicate).
      • 3b-2. Some People/users share/publish full GPG/PGP fingerprint, KeyID, etc over their own phone-line, own visiting-card, own website on their own server (not rented server), etc.
      • 3b-3. Some users have published phone#, website address, GPG fingerprint, email address, etc on his/her local location's yellow-pages, white-pages, etc (which he/she himself/herself has also subscribed).
    • 3c. And next thing for WoT (after a physical Trusted OBJECT/THING), which that Person may completely trust, can be a TRUSTED MEDIATOR, which that person (you are trying to communicate), himself/herself has completely trusted. Original message's/file's content is BELIEVED to be not altered (that is, message content's integrity will remain intact).
      • 3c-1. Trusted Mediators in this category can be or are : In physical world, other publicly declared personal-assistant, professional-lawyers, employee type of person/entity, whom/who are personally working for that Person (who you are trying to communicate), to represent that Person, and to convey message/file to others on behalf of that Person. In digital-world (aka, cyberspace), ICANN (ICANN's root.key is used for authenticating DNS, DNSSEC, DANE (DNSSEC), etc data for entire Internet all over the world. Not all but few publishing company who publishes written materials (physical paper, book).
      • 3c-2. DNSSEC-Signed data from that Person's own domain-name, (on his/her own server computer), which this person controls completely, can be trusted. Many users, authors, developers who own their own domain-names, or who works in a group which has its own domain-name, such type of user now publish/share their various types of (SSL/TLS, GmuPG/OpenPGP/PGP, etc) certificate/key fingerprint(s), full public key(s) & full certificate(s) via their own domain-name's PGP, CERT, TLSA, etc related DNS records. Such users usually publish info specially for those public-key & email-address which are used/associated for signing shared & distributed files, or used for "signed" communication with public for product/service related notice/alert etc. So first use a local full DNSSEC supported DNS-Server or DNS-Resolver, and then use simple GnuPG (or DiG or OpenPGP or PGP) command-line tools accordingly, to obtain & authenticate such received key/cert, from that Person's own (DNSSEC-signed AND DANE-signed) website's DNS information. Or, connect with that Person's own website (which should be operated from his/her own server) over a HTTPS (SSL/TLS encrypted) connection, use DANE-aware (and DNSSEC-aware) web-browser software to make sure connection is indeed using correct SSL/TLS cert or not, and find that Person's GPG key's full fingerprint or full KeyID or FULL (public) gpgkey/pgpkey, etc or find SSL/TLS cert's full fingerprint or public crt/pem/cer file, (if that Person has indeed shared it over his/her won https supported website). For enabling DANE-awareness in web-browsers, search for such addons/extensions : "Extended DNSSEC Validator", "DNSSEC Validator", etc.
      • 3c-3. Because of DNSSEC mechanism, users who use their own self-signed free SSL/TLS cert, now have a very efficient way to tell/declare to other people/visitors, what exact free SSL/TLS cert they approve & used in their web server. Without paying to Commercial CA companies, to get their chained & over-priced SSL cert under their Root Cert. For EV (extended verification) SSL/TLS cert, people/users (server-owners) still have to goto Commercial CAs. Maintaining DNSSEC-signed domain-names properly, requires non-lazy activity from domain-name's owner or/and domain-operator (and/or server-operator). Encrypted packets of data when massively and very very frequently used, then encryption keys should be changed in a periodic manner/schedule to thwart few types of weaknesses/attacks. A harmful entity can weaken encryption strength by logging/recording lots of packets over time. Those who are not efficient in doing DNSSEC related maintenance works, they can get DNSSEC maintenance related paid services from few Commercial CAs, Domain-name sellers, etc. Many of these companies are actually owned by only handful of few owners, who runs their multiple business with different product name & service name.
      • 3c-4. DNSSEC supported server can be configured to use statically defined DNSSEC/DS key for name-spaces or zones, like: ROOT, TLDs, few SLDs, etc, (by default DNS-Server gets them dynamically, in some configurations except for ROOT), even known (SLD) site's key (which you control and you are owner), can be added manually & statically inside DNS-Server configuration, then you can be sure-of that, someone in middle has not changed any codes dynamically even for a short time. Those who will use such configuration, will have to keep their DNS-Server upto date when any of those statically/manually defined zone changes their DS DNSSEC key. ROOT, TLDs usually do not change DNSSEC related keys, except for changing the initial test period's key. But, if someone do able to modify somehow and targeted some specific (one or set of) DNSSEC-signed website, then massive amount of users, (an entire TLD users), will not be able to visit those targeted DNSSEC-signed sites or may even see altered web-pages or blocked. Such never happened, even for once.
      • 3c-5. It is theoretically possible that primary secret private key, associated with the (public) root.key from ICANN, that is used for all type of DNSSEC authentication for entire world, is in hand of one Power-Hungry and/or Abusive entity who can alter/modify stuff to suppress and oppress and alter and block visitor's connection, but SUCH HAS NEVER HAPPENED for even ONCE, and if it does happen ONLY once, no one will ever trust (such) DNSSEC anymore. So then, older/current DNSSEC system which uses just one root.key will not be trusted or used anymore, as a result, a voting based selection mechanism (with multiple root.key) for a newer DNSSEC, would be needed. Ideas, concepts & technologies used for DNSSEC will not go away, it will be improved further to remove more bugs, and that is what has happened & happening to all kind of technologies, products, services.
    • 3d. And next thing even after that can be what OTHER people/users THINK/ASSUME/BELIEVE to be an Assumed-Trustworthy MEDIATOR. And there are various types of such MEDIATOR, and you will have to decide which one is more trust-worthy in which area currently. Message's/File's content can be comparatively or easily altered (that is, message content's integrity may not remain intact).
      • 3d-1. Assumed-Trustworthy Mediator(s) which other people/user think/assume/believe can be : snail-mail, keyserver, etc.
      • 3d-2. So if possible send snail mail (with return envelope & pre-paid postage) to sender, (better is to use sealed envelope, package or wrapper, etc), with request for sending you back : a paper printout of full gpg-key/pgp-key, (and also, which exact DNSSEC signed website has that Person's/sender's full gpg-key or full fingerprint or full key-ID, etc). In some areas even snail-mail cannot be trusted as they are opened, tampered with, photograph taken, etc. So complete trust on snail mail carriers, is not possible for all cases or in all areas around the world.
      • 3d-3. Use such keyserver which supports HKPS and HTTPS connections, and which itself is DNSSEC-signed and DANE-signed.
      • 3d-4. Some/Many online-public SERVICE COMPANY recently has CLOSED DOWN their service/servers, to avoid massive FINES & (legal) threats by SECRET court, controlled by country's Surveillance Agencies, which OPERATEs under the radar, without taking people's direct vote, by using self-profit driven/motivated, corrupted agenda driven, commercial profit driven, and secret minority agenda driven/motivated mediator person's approval (like: senators, congress-mans, etc type of "public-servant" people, who now loves to call themselves "law-maker"). SERVER OWNERS HAD/HAVE NO CHOICE BUT TO SHARE VARIOUS "SECRET" & "PRIVATE" KEYS, which are then in turn used for targeting (and wire-tapping), and also used for Surveillance ON MASS SCALE on all people on that/those servers, instead of targeting very SPECIFIC users/INDIVIDUALs, such is not legal or ethical at all. Court (by using secret "GAG-ORDER"), ORDERs server/service owner & company, NOT-TO DISCLOSE ANYONE, THAT SERVER'S PRIVATE/SECRET KEYS ARE GIVEN TO COURT, FOR SURVEILLANCE AGENCY, OR ELSE, STRAIGHT JAIL TIME & IMMEDIATE SHUTDOWN. So DO NOT EVER EXPECT such service owner will come to you and tell you that PRIVATE/SECRET keys are now/ALREADY COMPROMISED and now they have BACKDOOR access. So BLIND "trust" in any online/remote server(s) or service-provider(s), which are operating inside jurisdiction of such oppressive or abusive or EXCESSIVE SURVEILLANCE or MASS SCALE SURVEILLANCE supporting countries+governments, is NOT-WISE at all.
  • 4. When using any type of PROXY, then "security" of a communication system/process becomes depended on even more weakest point(s) and more factors. And doing activities ANONYMOUSLY requires even more extra careful steps. And then, creating server(s) & service(s) anonymously, and maintaining anonymously, requires even much much more efforts and very extra careful steps. Even a slightest mistake or wrong connection can destroy anonymity instantly, by relating your anonymous identity or connection, with your real identity or real Internet connection. And, absolute anonymity is most likely not possible or very very hard to create and maintain.
    • 4a. When you've created a GPG/OpenPGP/PGP key, only for ANONYMITY or PSEUDONYMOUS related usage purpose or for mostly cyberspace usage purpose, then DO NOT do or use or show or tell or display or send anything that can be used to create a connection or relation with your real-life's exact real physical identity. You MUST create email-address for such cyberspace identity also via proxy. Again, do not use your real physical life's any identifiable item/object inside cyberspace. Operating system or physical computer, which you use for daily, real-life usage purpose, have too many identifiable items & codes in each software and embedded inside each generated files & network-packets, if you send any of those to any one else, your cyberspace/anonymity will be broken. Create a VM, install all software without mentioning and without using any real-life (or real-identity) related information, then use such VM for anonymity purpose.
    • 4b. If the Person (who you are trying to communicate) have his/her own webpage (on his/her own webserver) and that web-server does not support TLS/SSL/HTTPS encrypted connection (and that server is using Non-DNSSEC based older DNS), then no matter how you obtain data from that/such webserver, through any type of proxy or even by using direct internet connection, obtained data cannot be completely trusted. So probably only choice, when using (any type of proxy, or) Tor-proxy, is to visit that Person's web-server multiple time over HTTP (non-encrypted) connections, via using multiple different Tor-circuits, by utilizing Vidalia's Tor Network Map (TNM), which can show circuit details, and allows to close a specific circuit to use a new circuit.
    • 4c. If this Person (who you are trying to communicate) have his/her own webpage (on his/her own webserver) and that web-server do support TLS/SSL/HTTPS encrypted connection and that server's domain-name is using Non-DNSSEC based older DNS, then, connections via Tor-proxy is only secure IF YOU have obtained the SSL/TLS cert used by that server, in early, via some direct or trustworthy Internet connection. Always apply common sense, if you obtain SSL/TLS cert directly via a direct internet connection, then do not use SSL connection via Tor-proxy instantly right after that, as that tell's/discloses to server (IP-address logging/recording services inside the server), who visited directly and who visited right after that, via a proxy. Use some time/hours/days later, for test/visit.
    • 4d. If this Person (who you are trying to communicate) have his/her own webpage (on his/her own webserver) and that web-server do support TLS/SSL/HTTPS encrypted connection, and that server's domain-name is also using new & advanced DNS, aka DNSSEC, and this Person (server's owner) has also added the FULL hex-code of SSL/TLS cert in TLSA/DANE dns record, then, very authentic data from such webserver can be obtained very very accurately and very securely, which explained in above, goto para/section 3c-2. One extra step you will have to do is, connect with such a remote/online DNS-Server which supports complete/full DNSSEC based DNS resolving, and supports clients to connect with server via TLS/SSL encrypted connections or via SSH encrypted tunnels. See below, para/section 7c, and, also see the PublicDNSResolver torproject wiki page for such DNS-Servers.
    • 4e. If Tor software is further improved, to include its own/built-in or internally embedded own DNSSEC-resolver, then such will help Tor users, greatly. Tor-software also need to create & run inside its own Sandbox or Jail/Container or Memory-Space, and it need to use its own software components. And Tor-software need to allow/give easy option for users to to choose random hops from 3 to 6, or 4 to 6, etc. Random hops/nodes is an important aspect to become more anonymous like what happens in real world. And using random exit-nodes for TLS encrypted connections is also another important factor, Tor-software need to adopt such features.
  • 5. Another way to COMMUNICATE with a Person (who you are trying to communicate), (this step is VERY IMPORTANT for Tor PROXY USERS), first step is to get+/find+/obtain+/investigate for such Person's full public PGP/OpenPGP/GPG key from his/her own website, and get full fingerprint, or get the entire public key from a keyserver (which is physically located inside a such location/country which at-least honors & respects people's/user's Privacy Rights, does not do any Logging/Recording or MASS scale Surveillance), by using HTTPS or HKPS encrypted connection, and encrypted connection can become even better (and more secured) if DNSSEC + DANE supported & authenticated connection with the keyserver is used. In second step, send a PGP/OpenPGP/GPG "Encrypted"-only email to that person's known and established email-address (using a TLS encrypted STARTTLS or SSL/TLS connection with your own email-service provider or with your own server (port 25, 587, 465), and additionally also use DNSSEC authenticated connection with your email-service provider or your email-server), paste full PGP/OpenPGP/GPG public key code (not as a file attachment) inside email's body/message area as a message, and also send him/her some secret LONG-NUMBER, and request him/her to send you back a response email with that secret long-number, and also request him/her to make sure to return a PGP/GPG/OpenPGP "Encrypted"-only email, using your public key which you have sent inside your encrypted email's body/message area. If this person can really return a response using an Encrypted-only message including the secret LONG-NUMBER which you have sent, then that proves he/she have the correct private/secret key to decrypt, encrypted messages. So from then on, you two, can use "Encrypted" or "Signed" or "Encrypted+Signed" email messages. See para/section 7c on how to run your own server anonymously.
    • 5a. For increasing your cyberspace WoT with proxy users, use the way mentioned in above paragraph 5, then such users can be trusted with 0x11 Trust level ("I have not checked at all",) or with 0x10 Trust level ("I will not answer"). I'm showing both & other level's RFC info, so you can decide:
      • 0x10: Generic certification of a User ID and Public-Key packet : The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the User ID.
      • 0x11: Persona certification of a User ID and Public-Key packet : The issuer of this certification has not done any verification of the claim that the owner of this key is the User ID specified.
      • 0x12: Casual certification of a User ID and Public-Key packet : The issuer of this certification has done some casual verification of the claim of identity.
      • 0x13: Positive certification of a User ID and Public-Key packet : The issuer of this certification has done substantial verification of the claim of identity.
        Note: If you have at-least exchanged "encrypted" emails with another proxy user (anonymous or pseudonymous user) in the way described in paragraph 5, then at-least email-address portion (part of "User ID" packet) and gpg-key packet, are verified, so you MAY select 0x11. Since "Name" portion of the User-ID is not verified, you cannot select 0x12. And if you did not exchange any encrypted email the way described in para 5, then you have not verified neither email-address nor the gpg-key, so you will have to select 0x10, IF you want to sign.
    • 5b. If you want to communicate very securely with another ANONYMOUS USER then both user have to create a local onion-host (aka, Hidden Service, HS) in their own side, (connecting with a specific local server port, where a server software is running & listening/waiting for connection). And any ONE of you, have to install & run a small XMPP or IRC server software in the local computer or inside a VirtualBox (or any other hypervisor) software based VM (Virtual Machine). Then other side can connect to it and can communicate with you in a live/instant chat/conversation. OR, (instead of using an IRC or XMPP server), if both user side installs their own small web-server, like "nginx", and allow an onion-host to connect with that nginx server's listening port (usually port 80 or 443), then both side can display/serve/share their GnuPG/GPG/OpenPGP/PGP key from a shared webpage, so that others can view it, for sending you an "Encrypted"-only email, like the process, described in above paragraph 5. Make sure to use Chroot/Jail etc container for the nginx, and set all shared webpages on read-only mode, and also set their access level onto read-only mode. Better would be to use TLS encryption and TLS supported port like 443, for sharing information with visitors over encrypted HTTPS webpages, even for a Hidden Service (onion-host) based webpages. Then, you will have to inform, the other side user in-early, what exact SSL/TLS certificate fingerprint & domain-name, to Trust temporarily, for connecting with your onion-host / Hidden-Service.
    • 5c. Exchange GPG/OpenPGP/PGP Key via IRC-Server : If both user have connected to same IRC server/network (which have massive amount of public users) using SSL/TLS encrypted connections, without using any IRC-Bouncer or IRC-proxy services/servers in middle, then create a temporary IRC channel, which begins with two ## (pound/hash) symbols, and use your own name and then add some number after it, like this IRC command: /join ##user-name-GMT-TIME#
      Tell other side to use exact same command. After other user/side joins into that new IRC channel, then copy & paste your entire public side GnuPG/OpenPGP/PGP key, in IRC software's message sending box, and press enter, it should appear to both of your screen, check it, if its correct or not. Some servers will accept only limited number of lines and characters, so best is to send 5 or 7 or 10 lines at a time, until you finish posting the entire full key, in this way at-least each line's format & code should remain intact. Any GnuPG/GPG/OpenPGP/PGP full key has a top-side boundary text lines (ASCII Armor Headers), and then in middle it has random-code-lines, and then in end or bottom-side it has ending text boundary lines (ASCII Armor Tail). So, another pre-caution can be, post those middle random-code-lines at first, without top and bottom text boundary lines. Complete sending, and then at the end, tell other person to add few extra text lines in top of those random-code-lines, and post those few top text lines. And then post the text lines which needs to be added at bottom/end of those random-code-lines. (You are removing boundary text code lines to stop triggering monitoring apps if there are any). Then other side's user will have to copy-paste all codes from IRC software screen and paste into a text editor software and remove IRC usernames, time, spaces, etc to get the actual full public gpg key. And then other side user need to send you an "Encrypted"-only email, so you can get it and confirm that other side has received correct public gpg key. This process is not as good as or as secure as, using a Hidden Service (onion-host) based communication or webpages, but not very bad either (that is, it is better than nothing).
  • 6. Sometime (some), Person/people/user/sender WRONGFULLY trusts their own or other's (wrong) thing, like, any website's non-encrypted webpage, or trusts encrypted webpage without checking DANE/TLSA DNS. DANE/TLSA contains encryption creating component's (SSL/TLS cert's) public hash or full code. DANE/TLSA & DNS records are DNSSEC authenticated, (when DNSSEC supported DNS-Resolver/Server is used), DNSSEC + DANE make sure of this: used TLS/SSL certificate for encrypted webpages, is indeed what the web-site's/domain-name's ACTUAL OWNER has approved for visitors and used in his/her server for encryption purpose. And DNSSEC + DANE also make sure, used SSL/TLS certificate is not a FORGED/FAKE certificate provided by a MIDDLE-MAN. When any type of proxy is used to visit a website, then such checking is a MUST.
    • 6a. You will have to understand and LEARN, which components/portions are more weak & easy to attack or modify, and which are harder to attack or modify. And depend more on those which are comparatively more trustworthy.
    • 6b. We know based on public information and based on news of after-affects of harmful hacking/cracking, it is very very easy to alter/change such (even SSL/TLS encryption supported webserver's) webpages, entirely or partially, and/or steal passwords, names, address, DOB, etc or other information of millions of users from database or webserver(s). Such hackers/crackers attack the web-server software's bugs, weaknesses, and then exploits, abuses them, its not the DNSSEC or the DNS-Server itself. Most DNS-Server runs inside Jail/Chroot container, and have RRL type of various protection features to protect from DNS-amplification attacks or from DoS attacks, so DNS-Servers (or DNS-Resolvers) are much much more protected than, HTTP or HTTPS based server software, like: Apache, nginx, IIS, etc, and DNS-Servers are better protected than even data-base server software. DNS-Servers handle much limited and same type of data mostly, but other type of servers utilizes variable & large amount of data.
  • 7. Always use IMAPS (Secured IMAP, port 993) or POPS (Secured POP, port 995) protocol for accessing email messages, those protocols uses SSL/TLS encrypted connections, from your email-client software (Thunderbird, IceDove, etc). Always use HTTPS based encrypted connection if you are accessing/sending emails via using web-browser (Firefox, IceCat, etc) software based webpages. Specially when using (any proxy or) Tor-proxy. Online email service providers have an option or configuration page, for enabling SSL encryption, enable that, and also change password after enabling SSL. Best is to use such an email service or server provider who honors & respects all user's Privacy Rights and opposes any kind of Logging/Recording and Surveillance, and MOST IMPORTANTLY, physically located in such country which also honors such basic fundamental civil rights, Privacy Rights, etc. Then using of such email-service provider is comparatively safer. Best is to use your own email server paired with an online/remote server, described in para/section 7c in below.
    • 7a. Tor-ify your email-client, web-browser, GnuPG/OpenPGP, etc software. See more info here.
    • 7b. Postfix and Exim email server/daemon software now supports DNSSEC authenticated connections and features, so email servers should be upgraded into those software. And features like : DNSSEC & DANE, should be enabled, for accurate checking & authentication purpose, and meta-tag adding features (related to DNSSEC) should be enabled to indicate when DNSSEC+DANE checking has succeeded or failed for each email.
    • 7c. Run a Remote/Online Server, PAIRed with Your Own Server : It is even better if you completely ANONYMOUSLY rent & configure your own online virtual or dedicated private server. But you will must have to configure it such way : you are using the remote online email-server only for its Internet IP-address. Forward/reflect/tunnel/bounce all incoming traffic (on service software ports, like: 25, 53, 80, 110, 123, 143, 443, 465, 587, 993, 995, etc) from that remote/online server, through SSH encrypted tunnels via using the Tor SOCKS-5-proxy & a local onion-host (Hidden-Service, HS) running on the remote/online server, and tunnel back into YOUR OWN home server or home-office server or community-location server or into such location, where your-side server is physically-"LOCKED-UP" BY YOU, where you have very controlled access, and it is in such a place, where NO ONE CAN COPY-out YOUR ANY PRIVATE/SECRET KEYS. SSH tunnel(s) from remote online server will connect with a onion-host (Hidden-Service server) running on your-side Server. In your server side make sure, SSH tunnel (from remote/online server) only have access to limited and certain necessary folders & files placed inside Chroot/Jail/etc container, including the SSH-server itself. Also configure your side Server in such way that, remote online server can be used as a remote full DNSSEC supported DNS-Server. DO NOT be very focused on slowness of such system, you want a "SECURED" system, that is THE 1ST & TOP most PRIORITY and Requirements, a secured system can be slow and that is OK, ok. Use very VERY strong ENCRYPTION. And even better is to use one layer of SSH inside another SSH layer. Again, do not worry or focus about encrypting again & again, etc, AGAIN, IT IS ABOUT "SECURING" something, which means, your objective is to make it harder & HARDER for someone else to DECRYPT your stuff. (Run tests to decrypt packets/protocols, and see if its easier or harder). There are many ways to do these type of tunneling & pairing setup/arrangements, see which is/are better and best suit(s) your need and purpose and SECURE.
    • 7d. Many Hosting service provider company, Domain-name service provider company, etc, accept money-order or cash or paypal or visa/mc/amex/etc Gift-card based payments. Some also accepts bitcoins (virtual currency).
  • 8. Ultimately, what we will ALWAYS HAVE TO KEEP ON TRY TO DO, is, to keep on increasing the strength of Keys, as power of encryption breaking tools like (SUPER-)computers, Quantum computers, (cryptanalysis and cryptography), etc will also be keep on increasing, (computing power of such tools will never go down, unless there is a lack of production (or building) of powerful encryption code breaking tools). It will remain similar to chasing of Dog, Cat, Mouse etc. We MUST have to STAY FEW STEPS AHEAD of, what those tools can do for significant amount of time, only then an expected level of "security" can be achieved for some limited amount of time. And another issue is, even if an encryption itself is strong (or weak), the software which implements it has bugs, some are purposefully planted there by corrupted & greedy (and Privacy-Rights dis-respecting) software developer groups, and also be careful about other software which are running along side by side of it, or even your OS, many of these also have purposefully planted bugs (weak-points, backdoors, etc), which can lower or completely eliminate percepted "security" greatly, so again, be VERY careful of those, and stay-connected with related groups of experts, and learn, and bypass those bugs, exploits.
    • 8a. A consensus in NIST article yielded such as below table, but be alert that, strength of given algorithm may evolve:
       
      -----------+------+----------
      |Asymmetric| Hash |Symmetric|
      | key size | size | key size|
      |----------+------+---------|
      |   1024   | 160  |   80    |
      |   2048   | 224  |  112    |
      |   3072   | 256  |  128    |
      |   7680   | 384  |  192    |
      |  15360   | 512  |  256    |
      -----------+------+----------

Torify GnuPG on Windows (Gpg4win or Cygwin)

It is best if a software itself can provide its own gnupg configuration options for its own purpose from its own wrapper/container, then one single copy of GnuPG can be used & shared by multiple different software with multiple different settings.
(Windows users usually need more detail instruction).

How To Torify GnuPG/GPG in Windows

Primary components which you will need are:

  • Thunderbird, Icedove, etc email-client software. Torify your email-client, see info here.
  • GPG4Windows (gpg4win) vanilla edition or GPG-Portable edition or OpenPGP minimal (command-lines) files or Cygwin based GnuPG binary/executable files.
    • The self-signed SSL cert used by wald.intevation.org (GPG4WIN) has these : SHA1 fingerprint is: 70:64:F4:F2:E3:A7:7B:96:18:48:74:59:79:7E:A6:CE:BB:FB:7D:FD, valid upto 2013-11-28.
    • The cygwin site's self-signed SSL cert has these : SHA1 fingerprint is: DE:C4:9C:3B:7A:20:0A:50:83:35:CD:AC:E5:F3:A9:75:6D:B8:08:54, valid upto 2014-08-19, even though SSL cert is actually for domain www.sourceware.org, it is still valid for https://www.cygwin.com/cygwin/. Used SSL cert is under the Root CA cert from StartCom CA, Ltd, which is still not available in many/all web-browser software.
  • Enigmail addon/extension for your email-client software, Enigmail is a graphical & user friendly wrapper or interface (GUI) for you to use simple mouse clicks to run advanced or complex GnuPG commands.
  • Also install/load Torbirdy. TorBirdy is an experimental/beta addon/extension for Mozilla Thunderbird, Icedove, etc email-clients software. It can set Anonymity and Privacy related various configurations, to block various leaks from those email-client software. Please see TorBirdy project's page/area, or TorBirdy wiki docs at TorProject area for more up-to-date information.

In following ways above components can be mixed & combined & configured, to achieve anonymity and privacy friendly/supported communication and data exchange environment:

  • Windows Implementation-A: Keep default or local system's default "gpg.conf" file unmodified, and also leave all other files intact for whichever GnuPG/GPG or PGP software you have chosen to install & use.
    • Create a folder named similar to GPG-NymPriv (GnuPG Anonymity and Privacy). Copy all binary/executable files from your chosen GnuPG or OpenPGP software folder, and paste into GPG-NymPriv folder. Change files inside GPG-NymPriv folder, and force them to use binary/executable files from inside GPG-NymPriv folder.
    • Install a safer HTTPS-to-SOCKS proxy software (or HTTP-to-SOCKS proxy), or install simple & older Polipo for forwarding all HTTP traffic from a specific network port, inside the Tor SOCKS-proxy tunnel/network.
    • Get "gpg.conf" file either from github Torbirdy (gpg.conf), or from torproject Torbirdy (gpg.conf), and place inside GPG-NymPriv folder.
    • Use custom .cmd, .bat etc batch script file for all your gpg, gpg2, pgp, etc related (shell or command-prompt) command-lines, to temporarily override default settings and use (polipo based) HTTPS-to-SOCKS proxy. There are also tools for converting batch scripts into a .exe file, use such tool if that is what you need to use, in some application. Only apps which will specify their own custom settings for using HTTPS-to-SOCKS proxy, will use Tor SOCKS-proxy, all other will by default will system's default and direct internet.
    • You must use strong Security software (Firewall and Anti-Virus, Anti-Spamware, etc), to block/deny any/all direct internet connection, originating from any binary/executable files and folders and software, which are assigned ONLY for anonymity & privacy usage purpose. Executable files and folders which are assigned for anonymity and privacy purpose ONLY, they ONLY need to access 127.0.0.1:8118 and 127.0.0.1:9150, nothing else. Such software may need 1 or 2 local loopback access in windows, which is fine/ok. Such software must not be allowed to use any DNS (port 53) connection toward any local or internet DNS-Servers. Some exceptional software (for anonymity & privacy) will need specially configured virtual network interface and DNS access, only such can be allowed, as those will be configured to forward all traffic toward the Tor SOCKS-proxy, and toward a HTTPS-to-SOCKS proxy.
    • If you use your computer or VM, for both "Anonymity" and "Personal" purpose, then you should prefer to use this Implementation-A option. But using computer for both "Anonymity" and "Personal" purpose, is not wise or very-easy.
  • Windows Implementation-B: Change "gpg.conf" file with proxy server settings, so that all software which does not use or specify their own options or own command-lines related to GnuPG, then those software & command-line, will by default use settings specified in "gpg.conf". This is useful, when you want all software or command-line related to GnuPG to by default use Tor SOCKS proxy. And, whichever software or command-line will specify their own option, then they will automatically override the settings of "gpg.conf" file. As of this writing (and testing) (Sept, 2012), the Gpg4win (Gpg4win 2.1.1 Beta version) does not support HTTPS, HKPS completely.
  • Windows Implementation-C: Use GnuPG from Cygwin. It is same as above option B, (please read option B) except, that, this will allow to use HKPS scheme based keyservers via TLS based encryption, via Polipo and through Tor-network.

Option B (Torify GnuPG from Gp4win, via gpg.conf on Windows)

Get Gpg4win, and Install it.
If you want GnuPG/GPG to use Tor SOCKS proxy by default, only then apply below instruction. (Actually, Gpg4win will use Polipo (HTTP-proxy), then that will link with Tor SOCKS proxy). When a software or component (for example, software component like Torbirdy) which is able to provide it's own options, then such software can override these below default settings. (Torbirdy torifies Thunderbird, Enigmail. When Enigmail calls or uses GnuPG, because of Torbirdy, GnuPG is then temporarily Torified. Torbirdy does not permanently change GnuPG. You will must have to use Torbirdy to Torify Thunderbird.) Software which cannot specify their own options, will use Tor network by default, if you use below settings. And when you will use simple gpg, gpg2, etc commands, then those will use default settings. For example, to verify files which were downloaded by using Torified (or Anonymized) software, like: Tor Browser Bundle (TBB), (torified) file downloading software, (torified) IM software, etc, through Tor-network, then you can use below settings.

GnuPG (from Gpg4win) will take this path for those Keyservers which are on Internet:

GnuPG <--> (port 8118 of) Polipo <--> (port 9050 of) Tor <--> Tor-network <--> (port 443 or 11371 of) Keyserver(s).

GnuPG (from Gpg4win) will take this path for those Keyservers which are running as Hidden-Service (onion host) inside Tor-network:

GnuPG <--> (port 8118 of) Polipo <--> (port 9050 of) Tor <--> Tor-network <--> (port 11371 of) Hidden-Service based onion host Keyserver(s).

Torification steps:

  • Get Gpg4win, install it.
  • Download "Polipo" (a HTTP-proxy to SOCKS proxy software), install it, add a configuration file "polipo.conf" or "8118-to-9050.conf". Also modify "vidalia.conf" file as shown inside Polipo instruction page, restart Vidalia.
  • Goto or browse to this folder location, using Windows Explorer (press & hold on Windows Flag/Logo button, and press once on "E" button on keyboard, release both button) -> C:\Documents and Settings\<YourWindowsUserProfileName>\Application Data\gnupg\
    This folder is equivalent of using this: %APPDATA%\gnupg\
  • Open the file "gpg.conf" for editing, with a (recommended) editor software like: Notepad2(2), Notepad++ etc. (If not obtainable, then try with Microsoft Windows Notepad).
  • You must add or edit a "keyserver-options" (a configuration command-line), manually. Add below line, above the "keyserver" line, (whether a configuration line exists & starts with "keyserver", or not):

    keyserver-options http-proxy=http://127.0.0.1:8118,debug,verbose

  • Add these lines, if not already present (in gpg.conf file):
    utf8-strings
    no-emit-version
    no-comments
    throw-keyids
    
  • Change the keyserver to match with below line:

    keyserver hkp://hkps.pool.sks-keyservers.net no-cert-check (pls see Note 2)

    or add this line:

    keyserver hkp://2eghzlv2wwcq7u7y.onion

    Multiple keyservers are allowed and ok. Though you can manually add or change a "keyserver" configuration line, but it is always recommended (and effective), to use the Kleopatra GUI of GnuPG, because it sets extra data in "gpg.conf" files. Start Kleopatra -> goto main menu -> Settings -> Configure Kleopatra... -> Directory Services -> if the list is empty, then click on "New" button -> double click on new keyserver-name (keys.gnupg.net) shown under "Server Name" column -> change or modify it to "hkps.pool.sks-keyservers.net" (without double-quote marks) -> make sure you see "hkp" under "Scheme" column (if you don't see "hkp" under Scheme column, double-click on the Scheme word (http, https, ldap, etc), then click on down-arrow to view the drop-down list -> select "hkp" from the list) -> use port 11371 (for hkp) -> Apply -> Ok. Try to search or receive a Keyid or cert-id on this keyserver.
    • If above "keyserver" setting is not working for you, then change it to another from above alternative keyserver list. Like described above, add more Keyservers.
    • To use a self-signed CA-cert or Root-cert or server cert based keyserver which uses HTTPS, HKPS, download their root-cert (aka, CA-cert) ( Pre-caution: please use Vidalia's "Tor Network Map" and make sure you are downloading same cert file multiple times via multiple different Tor circuits and using totally new nodes for each circuit each time, also use the "Use a New Identity" feature, compare all files, only then accept or use if correct, these site will show their root cert's fingerprints, also view fingerprint via multiple circuits ) and place inside "pub" folder, and use like below:

      keyserver hkps://zimmermann.mayfirst.org check-cert,ca-cert-file="C:\Program Files\Gnu\GnuPG\pub\mfpl.crt"

Note: for HTTP, HTTPS the "gpg2keys_curl.exe" file is used and creates connection toward Internet. For HKP, HKPS the "gpg2keys_hkp.exe" file is used and creates connection toward Internet. Even though these does not leak DNS (when Polipo proxy is used), but for another level of fail-safe, set rules in your firewall to allow these exe to connect with only 127.0.0.1:8118 Polipo proxy, nothing else. Local loop connections, above port 1025 can be allowed. If those two files want to connect with 127.0.0.1:53, 127.0.0.1:DNS, localhost:DNS, then deny, that means, do not allow.

Note 2 : As soon as sks-keyservers.net provides their downloadable CA-cert, then remove "no-cert-check" option, and use like above.

Option C (Torify GnuPG from Cygwin, via gpg.conf on Windows)

Use Cygwin based solution, if you want to use only HKPS based keyservers. (though you can use HKP, HTTP as well).

Warning: you must use a firewall that is capable of blocking application based DNS queries, and you must also use a local (3rd party) DNS-Resolver software, because cygwin's gnupg ("gpgkeys_hkp.exe" & "gpgkeys_curl.exe") leaks DNS. In below you will find options to block DNS leaks, and choose which you prefer.

Cygwin is a very popular tool, and it (developers of cygwin) provide various POSIX (Linux/Unix) software bundle & tools for using on Windows. Cygwin has its own specialized DLL file, (and uses various compiler tools to convert source codes into binary programs), which allows Linux/Unix etc OS & various platform based software, to run on Windows.

  • Warning: As of this writing (Sept, 2012), Cygwin does not provide a SHA1 or MD5 or SHA256 hash/digest/checksum etc for the "setup.exe" file, which they should. Simple tools like HashTab, etc can allow to check hash code of a file, and that is also a popular way to verify files on Windows platforms. And the website does not have HTTPS (SSL or TLS based encryption) support either. So please connect directly via your local Internet, to get the "setup.exe". This "setup.exe" will connect with Internet and will obtain various source code (& binary) packages suitable for Windows, from various mirror download sites based on your choice, and it at-least checks downloaded file's integrity with MD5 hash.

You should first read/scan once the above Option B to understand what terms and detail process we are using, and then come back here for this (option C), which is using shorter explanation, so it is easier for you to understand.

GnuPG (from Cygwin) will use Keyservers which are on open Internet:

GnuPG <--> Polipo <--> Tor <--> Tor-network <--> (port 443) HKPS Keyserver(s).

GnuPG (from Cygwin) will use Keyservers running as Hidden-Service (onion host) inside Tor-network:

GnuPG <--> Polipo <--> Tor <--> Tor-network <--> (port 443 of) HTTPS Hidden-Service based onion host Keyserver(s).

Torification steps:

  • Install Cygwin & Get GnuPG From Cygwin: Install Cygwin (from here). Download their 'setup.exe' in "C:\cygwin\Install" folder (or in it's equivalent location, here: "%windir%\..\cygwin\Install" folder, if 'cygwin' folder or 'Install' sub-folder do not exist, then create them. Here %windir% variable indicating your actual location of 'Windows' folder, where 'system32' or 'system' sub-folder exist). Run the 'setup.exe' installer -> select 'Install from Internet' -> Root Directory: C:\cygwin -> All Users > choose 'C:\cygwin\Install' as Local Package Directory (packages contain pre-compressed source & binary files) -> Direct Connection -> choose a https (or else a http) based Download (mirror) site (that appears closer to your location) -> Next -> on 'Select Packages' Category stage, inside Search box, type "gnupg" (without using double-quotes) and wait few seconds for it to search & show result of that, and click on [+] symbol on "Util" category line/row to expand it -> find the package line which shows "gnupg". On that line/row, click once on the word 'skip' and it will change into 'Install' or 'Keep' or change into the version # of gnupg which is available at that moment -> Next -> Cygwin Installer will show you a popup window with other software or tools list, which are necessary for the 'gnupg' utility to work, as 'GnuPG' depends on those -> Ok/Next -> when downloading & installation process finishes, then press on 'Finish' button.
    • Add Cygwin's Folder Location In PATH: To use gpg.exe from any folder location, add Cygwin's "bin", etc folder(s) in PATH (environment variable). Press and hold Windows Flag/Logo button on keyboard and then press R button once, and let go both buttons. On 'Run' window, type: sysdm.cpl ⏎ and then goto 'Advanced' -> 'Environment variables' -> under the 'System variables' box, scroll down and find 'Path' and click on Path once -> Edit -> inside 'Variable value:' textbox, go at the end (by pressing the right arrow button or "End" button) and then type: ;C:\cygwin\bin\;C:\cygwin\usr\sbin and then press on OK button -> OK -> OK. To see folder locations list inside PATH, in Command-Prompt, type: echo %PATH%
  • Download "Polipo", install it, add a configuration file "polipo.conf" or "8118-to-9050.conf". Also modify "vidalia.conf" file as shown inside Polipo instruction page, restart Vidalia.
  • Goto or browse to this folder location: C:\cygwin\home\ folder location. Create a sub-folder which has exact same name as your Windows user profile, (for now, later we will change it to a generic user name, by changing related Windows Registry as well).
  • Goto C:\cygwin\bin\ folder, run: gpg.exe --version
    Go back to C:\cygwin\home\<YourWindowsUserProfileName>\ folder, and you will see new folder ".gnupg" now exist and also few files inside it. Go inside the folder: C:\cygwin\home\<YourWindowsUserProfileName>\.gnupg\
  • Open the file "gpg.conf" for editing, with an editor software like: Notepad2(2), Notepad++ etc. (If not obtainable, then try with Microsoft Windows Notepad).
  • You must add a "keyserver-options" (a configuration command-line), manually:

    keyserver-options http-proxy=https://127.0.0.1:8118,debug,verbose
  • Add these lines, if not already present (in gpg.conf file):
    charset utf8
    utf8-strings
    no-emit-version
    no-comments
    throw-keyids
    
  • Change the keyserver to match with below configuration command-line (if such line with "keyserver" exist):

    keyserver hkps://zimmermann.mayfirst.org ca-cert-file="/home/Bry8Star/.gnupg/mfpl.crt"

    Change above folder "Bry8Star" into your actual Windows user profile name. To use a self-signed CA-cert or Root-cert or server cert based keyserver which uses HTTPS , HKPS scheme, download their root-cert (aka, CA-cert) ( Pre-caution: please use Vidalia's "Tor Network Map" and make sure you are downloading same cert file multiple times via multiple different Tor circuits and using totally new nodes for each circuit each time, also use the "Use a New Identity" feature, compare all files, only then accept or use if correct, these site will show their root cert's fingerprints, also view fingerprint via multiple circuits. Very very widely used CA cert (like, cacert.org etc) can be downloaded via direct Internet connection ) and place inside "C:\cygwin\home\<WindowsUserProfileName>\.gnupg\" folder, and then specify like above keyserver configuration command-line.
    Multiple keyservers are allowed and ok.
  • To block DNS leak of 'GPGKEYS_HKP.exe' & 'GPGKEYS_CURL.exe' file : you must have to use such a firewall which is capable of blocking application(app) based DNS query, like (free) Commodo Personal Firewall, Agnitum Outpost Firewall, etc. Some firewall cannot block Windows SVCHOST which performs multi functions, and some firewall cannot block an specific app from connecting with DNS-client, so for these reasons, you will also must have to install a local 3rd party DNS-resolver, Firewalls are capable of blocking connection to such local 3rd party DNS-Resolver. Advantage of using local (3rd party) DNS-Resolver, instead of using Window's default stub-resolver (or DNS-client), is that, you will be able to block any kind of app's any DNS leaks, even if you by accident make a mistake, or block an app which started up with wrong configuration, etc.
    • Install your choice of DNS-Resolver software, and you must use configuration file mentioned in those article, so that you are protected from DNS Leaks, properly.
    • When firewall will show you a popup alarm or window (similar to below), and ask you to response (aka, prompts you with):
        A software GPGKEYS_HKP.exe (or GPGKEYS_CURL.exe) is trying to connect with (local) 127.0.0.1:53 (or 127.0.0.1:DNS) or trying to connect outbound (using UDP network traffic), Do you want to, "Allow", or "Do Not Allow" or Just allow for once or this time ? Remember your Answer or not ?
      Then, (deny, which means,) DO NOT allow 'GPGKEYS_HKP.exe' & 'GPGKEYS_CURL.exe' to connect with 127.0.0.1:53 (or 127.0.0.1:DNS or localhost:DNS or any DNS-Server). And it is even better, if you create such blocking rules for these two app(s), before using. Those two files must use Polipo (HTTP-proxy) by connecting with 127.0.0.1:8118 (network location & port), and Polipo is capable of resolving DNS via Tor. Select the option to 'Remember' your choice (or select apply always) on firewall. So it does not keep on showing you Popup messages, everytime. Exact shown terms & words will vary in between different firewall software, but read again this para/section so you understand what you will have to do.
  • If you are using GnuPG inside a VM or a Container, and you are using this VM (or Container) only to be used for Anonymous-usage purpose, then, enable Tor's DNS resolver feature (by adding DNSport 53 in 'torrc', and specify 127.0.0.1 as preferred or primary DNS Server and remove other DNS servers, inside VM's Network Interface settings), then all apps will resolve DNS via Tor DNS. But if you will use VM for both anonymous and non-anonymous purpose, then do not use Tor's DNS resolving feature, instead use local (3rd party software based) DNS-Resolver, which can be configured appropriately.
  • Try to search or receive a Keyid or cert-id from this keyserver.

Old outdated advice

Anyone checked if these are still recommend?

GnuPG: Method 1 (Privoxy)

Add or edit the following lines in your $HOME/.gnupg/gpg.conf:

keyserver x-hkp://yod73zr3y6wnm2sw.onion
keyserver-options honor-http-proxy broken-http-proxy

You may obviously use any public keyserver, like subkeys.pgp.net, but hidden services are preferred. At the time of this writing, only three key servers running as hidden servers are publicly available -- http://d3ettcpzlta6azsm.onion/, http://yod73zr3y6wnm2sw.onion and hkp://2eghzlv2wwcq7u7y.onion. Last one is also available at http://qtt2yl5jocgrk7nu.onion.

After that is done, just run

export http_proxy=http://127.0.0.1:8118/
gpg --refresh-keys

If you don't want to write the export line every time, you can add alias gpg='http_proxy=http://127.0.0.1:8118/ gpg' to your .bashrc file as well; if you have set the http_proxy environment variable, you may skip this step.

GnuPG: Method 2 (torify)

At least a couple of people have had problems with using GPG over Privoxy. It is possible to use GPG with torify instead. If you have http_proxy set, GPG will try to use it. Add no-honor-http-proxy to your keyserver-options to prevent that.

Remember that torify doesn't handle DNS! Use tor-resolve to get the IP of your keyserver and use that. Either add it to $HOME/.gnupg/gpg.conf as the keyserver option or put it on the command line.

Now run

torify gpg --refresh-keys

or

torify gpg --keyserver [result of tor-resolve] --refresh-keys
Last modified 4 years ago Last modified on Nov 17, 2013, 2:29:14 PM