GPG Tutorial

This was once just a page that contained my public encryption key. It has now grown to become an introduction to how and why to use the GNU Privacy Guard encryption software (GPG) to protect your privacy. It is continually growing. If you have questions, corrections, suggestions, software recommendations, or want to exchange encrypted e-mails, please contact Alan Eliasen. I'm also on the Twitter thingy as aeliasen. Thanks!

Below is the public encryption key for Alan Eliasen, (eliasen@mindspring.com) in armored OpenPGP format. This lets you write encrypted messages that only I can read!

Note: I have recently upgraded to a stronger 4096-bit RSA key. If you were previously using the old key, please see my key migration document for more information on the reasons for this change and how to migrate to the new key.

Don't worry: you don't have to read this. You can cut-and-paste it or obtain it in a plaintext file or import it from a keyserver using the directions in the Importing a Key section of this document.

-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 Comment: See Alan's GPG guide at https://futureboy.us/pgp.html mQINBFPOzTUBEADT1kIEMY1Ix+9DyNfGHE9HPjLSI/Ybnsn/bbx8cWmeAktoYjBS q29mJ0tchjyG8KP38vlkvfNYKn80985a/p7ZKupxOm1dDyAn5TZguDG2fEgCYxcB FxfMjGKLEFOS6hlPVh/3bm7xEvRuB5P/5Wdch9/UK11qLE3hlDlhnT1zq82Sk4G8 OWnH8BLA8XuRAdwAdri7U2OmNPqCldlmpIsTy68MXJQk7tYi0Rwc55c65U4gGSuY qw3QzQ6X4TecFO/jUPBnnVb5YcYKxVw75PYF6NnKbbsnDYJoNg8bpEP2SVC0FWNK 2rKYsGsbcco2/ruJuQsThVcuH3l07cAKaSzt+eb5+FWWzsojbSeXwD8yZocfPvEL eaa0/Jr2220sV6OdSpWBa8mhBI5oTAbD9PDX3C5gyPj78mzDlhytLTCsdtL1Uqgm DTbIqgDPQBEnGr9Ny2XlIQ6AjuyuahBDl+ElmLnz0jI9bjt0vgAUGjmCCp71aioo MXZALwVBsdQH3w2BHQ8wU9sYtMlBPBMZz++oIQthmJ+Gb6myvMZCQ34M9TfpIv5i utAK2xBP/XfBl5BMYl6xNUHOxGhtBj/Pbzcwu/+Sk3mKkC4E2+aUKEjyzs6rDdDs pT+2B4A1nNXLU1PA+AfabdLnlvm7lMgzr30Waejcz4FbSdwCX8oN9UabBQARAQAB tCVBbGFuIEVsaWFzZW4gPGVsaWFzZW5AbWluZHNwcmluZy5jb20+iQJBBBMBCAAr AhsDAh4BAheACgsJDQoIDAcLAwIHFQoJCAsCAwUWAgMBAAIZAQUCVCJ6SwAKCRBf K0dW7Yc9IyAEEACjB/Kwt7WE5E+GEQ6DFVqFGGZpKQaNKI1bLi+xD63+gXuQzu2B 2ujlerjKdiNaI7D2n0fcFOuEouxaRUkizb2/hV9rqAOGqUOwnRBr31wVqQP/s2xU 4MMev46jFecI2FHALpNXA6/mqBh4ODyfpEetxM+DiaN4vUdiiLEtOfjCVggnCS7H +JirccN7MZzt16P7AEbCD9qZwc+Gnob8DbXKm6VbN3sRG00c3zUjL7VLGC+qctWw P2HRKC1/XXxX4Vjidbs+2+ygAxlyLGVB12L2PTA63tR2ppJoRWAh9iLtaK2/uszH h9Gt5EtL4d00rqVhWHtDlPAvjyBAyomTWPysuuwJvob+nR6cSYobsi2/H8rj0F1l zuh0YLCt52dZ9SqiOgA2SCUDa3opO9ECUYbgVABiwpSgj7GP9UTOIoT7gAZlxlEI s9kdkDb2I7y4xkImm0nH5EqAGP9Qt8Sc3Dai0iFK0+k4o4uY1VJD0SZlm2WxjLpJ Zc+CbwGEn0pN5r+g6XsS8bj26l0Lg3ixvLlmiwsDnP2gVoW1/cGYPq+wMf7++Gms wbLhKhN+HSNSbE/thKkxQ14omuhP73kJIrIIHyQr0Z/KSnBDluQoBHWTnQ5SZ6EO bQi9zRGZWhbOyiuF2jnTwoD6glOnOao8viNqKTVH9ItHQywGEcYnC+ztu4hGBBAR AgAGBQJTzuGrAAoJEOSBhLWwVnaxj7EAoMxh7ycVIU2xEee0kkNzif299NXvAKCp FntsiNcSu34mmQeGhikf10LapokCHAQQAQIABgUCU91SFQAKCRCkgk4/+RzmWWbq EACMs+Hq0UulmnXPfTNPJPZbZprPRvWRGSmIr6GPtuX17IP2nDXsD62+Ls6Vitnb laZmfRXwc8M5kggU5n4G7t8VJj4onaoIJv3jNrrJgUwsZsSij9mQdoRxGsjNmhBb 1l3ujsJ4TNvjTc8XxnjtNbSpq94tfg2QvsdCdctjaQjzKzp82sB+/miKMFZDCy0L EF2yKTCebnUWy8F0K0W+GpVaWxrJzfBkmY1772Ruy3ovnIkHApyXB0buTws0u4HN LEJgzJgtmMrtGXL+/ULpGDjjKYyhrGw7ciDvWZ5SuTS5W2N7Fpgn9nfXQWy4zgqv eq8iNZbnT5Bh5hB/lNFLUAiiH+9lh9OpD4noSq9MumTdRlvZTGZVnPDQRipF++J/ 5g0nEq3nEAAIjTHYnmzP7T83Rgfq1+jwjTTD6r6W1KauRdBInbNlNQZeklqLyvwZ qY7QtzA58+tPcyIiwP8gsTF7MR/ZD1/8Zh5OhpbeCIntXs7s+784pfY/Cfd1fwp9 cr7eLQ3BGKTAj06mm3JOFokpU0byjJFADaePe6LRE6Iy5yBL025fIG7yPvTV0mvA SnJERwCFGPAvEOq38V+cXdKxSJBbTt7l/7Ma5M18b/c5z9Ni18BD6iOj+zGuvDA0 /QhAYzgkjvYLC1oEqt3OgwITyapf8twVt3rcZN+/gk2TU4kCPgQTAQIAKAIbAwIe AQIXgAUCU87N3woLCQ0KCAwHCwMCBxUKCQgLAgMFFgIDAQAACgkQXytHVu2HPSMh 5w//fnhk1fU8LUmmnw8qKlIi0l9zAcCep6eYwomJSHqugDLWkP4nXprbufrCXE+l x/nZGcHfnvC2X0+d+pZgufd44TRHTbPNGMe6tL7b9FAhn/sZOMtepXYz0KmDehdy es+/+1KN6Ihen99GieWKcc09nVBoQG0DUlCD2SzC2x4O/fsgzMvHYyLJr8+jfhs1 ZBBY8NMBejOOk6NKe7asLuxTJFDyb/6B2XX1uN/0AJWomIwz4zh8FsKhG2zk6VuI aMcG5hjpzPp7mT/H3BnP/9Rb7q8Jd+yuG4O9mENzz2/2zB1x8WRkF1sNioj7fY53 gDK09vvdjGfJJPLYsHNz7/pPcDlm5J9Nc8Ngp9XDtSG/xBnJwlFTHFYOHCQV+htO xMt+xEL5vURnDa0aCrganDm444NUtQAcXtVpvoHhUpHBtdJna6jz9pWDEsUu28iZ /czPKEgsK+V4IGqh7jLsc97BcOa1PJ0AFpowuKzRCdMLlNhY7DxxeSpmwBylLqd9 I5BN9PEo7Xb8+vmKGRBzhcqLTnMZVMJp2KLOkvgjt7uXrlSlyfO9fot1nQNBW+cM +EeVN0hPEYHacymNdCDem8AkoBlH5SofYSqZE+Wi2NRHFCts7pjMJmifXCDLMSNo g5gGtV6W6H+4dijTiH6xs959VKx5wGRKl+js37SqfPuVroCJAhwEEAECAAYFAlPg oqAACgkQ4xY9x2rQWw6F+w/9Ej1CCsR4XeM40hURsKo7b/ZsMpV1MoQ2+7cewBw3 nWHYEUaWfiKvo1nbluXbnt2oPyxQPgJToJfrlgSF2xD873zHhBOaAqPQexPCCFYP 9YIBiuBrzGXEBIIUd/y/TU65qkiAD4YdeNGaCw5DfV9BzzffoQrHPAe/YHo3JB7v nSN0xy1FBtEoPPyFS0YN4foFC0LwEiyKd3SwkWtkTbvkjgTiXN1A8fx5w8oVPHou QIpzOkzgAbsupCJGPsCyJNK50f5SyRqSYqeE2NuseAPjtdUf/1aI+ahmJ/yNZLq8 N9AR+OfqGVL7djOMifJUxOwpIvTqhBD/P7Es7P+i2vCOA0ww4wh9o1vmzPyfY9LW tq+xH3scd0bU4tEV3CXPwl3Shv3K9y4ezdelK9eHOIt0Fno6M0dgAEQpiZGiVPBm SDN5SDiUMOZ/2eo86vccoj9YN60lsMypJHwqvfIyXiKpqIz4amgxIUWOLWSSdSk8 BK8UnsmnQRYUS0x6/gHS1EOrB5krXtVWgt1xJr01wmCEDb982kva0rBVhVrDHSYC CrOf7G4BwZ2weyGE0kMXbAeaunuK49y6hJEoZCYS+KGnHWhr6eyqRB/oDcnDvbNv APtJrtMV3IpW7Kf5JtSlYDVyail7yMb+dNZumznueQJ5DkC+q4Y+Nfez0dGfbfj/ eVKJAhwEEAECAAYFAlPpRKcACgkQrUNxyt5zEFBu+Q//TTikjaqqEAD++vQxyq70 AU3Xx9sWX/mrMLbVipCIhCZf7A2IHGNaEzyN1dzT6yIX6mmtRsnYRuCwFRs+nv3h 2IkYe3dyOe6jvKBtSs/st2OqGt7WDn877L/h3EC7sLAxMHMHr6mWv3nJKdmCwoDz lRU6j5P9KPH+sNcSjKFAYTiUHhMt5cKo8QkQNPzySCvyOEr2NVwSh9YuvVP/irRJ q3p6ckSOPUBptaSCA/jqMdYqKXDmstf1IRfVqHN8mqA3N4hZ6xRDiq3vbXXxGQwv LR1ZvUD4sUH0Y8u4lRluYPDilqknxgaBC8LtkTHYvtlEYahRSwx3h5IjIcNdUhM1 EyDYsR3NcSoirBcKgqNILEl1ohmpbGdENJPfp4h8VDu+htE2RtflCdHRFXIx4E5X 1MIt1m71+cznrOKW4jbQ+ecIFk3Y+tnJVNVh67O7I3XT0x2tdMTDuVb/jNcd96di +9mp2XgNnMKw5OG9bN47y/x3dgVk/w2x/lun9PEkyocptXX1OB06LB5GlIPi1VIS DLO5lUImj+GV1nrAMsSVRkNlY0bOEAHc745yPbggTqdlZAPa1fQbrR9Y/Y2xiBky cKyXhfQF7vnFFT8h8jqkT+Ry1S712K3lAF6AqXEexAA1lRvFEfyrfXBEDCNPPLQ/ AObahDixWncHDGIyWtLEqdmJBBwEEAECAAYFAlPpt1kACgkQ0L9qe/cpGAlMziAA yLZlWEfaRUBxXCqR1IkNluZae6kYAugYubLIJI5jca3r7SB32tdPBxgZ6X+P+4KU rbZv0Rfoz1hfswXK8isgexTMY1BQCfmIWNwmPZqTI9ozeXQR+qP90Cm/wluA9b5D UUH29o/23hlcu3C/7YMdR6NElJgaxSieAY/bsjfrz/NOkZdFql5ySVJRHL6JozDf Fmvm6bS6hBdXMLILDMA8KKDfx0EW2AUVW/4kw2wKQEgOYPUfhmi5wkcB53BXimtk DS83EkeiImeVZekLgw1NSr8uowH6A059wC1I7zRjXF+i6m/2nmvY56uEVKW3d34G etKkwfZYqqzYBatOlbM+TZ0N7AC2om+Kg3OEDhrKkkCgh4FfACDD51svKKWTrHvG fVgOB0iZiba4+ItcNrlLWTrDHjPNOuWL7CAzpDgNEYS5+n6ZAeRSg71ToDlJUC5q Vp4jB+polO6iyqOswsxerEKLJM6vPvl/IyOpcpBFsG0PlR1S5QKc1ngY+xPLLVA5 e+yZ4GGHmGp6La94QAE/2baW4avS7gkgzIkkWKHw1zfI2zEtDDiO59pXtaT6rLO9 GuOhwgQmdtmIzmj3tIfFvRDmExKy8pHlupYgl8SThomkjrrb6vos550P23XRWWBh qOqHUI+P9eB/yIvg4Gb36lrgjsHnY6wfZEC7Jm1pwqt0Ly1+PdMI1IEDeJERGTJJ owtchT7r5WFsW+VKcOedVt8YLceeYajTnMUWk9v9f2uSppX4yPGncg7wdN331qLa udXdw329+9UJY8BoXHsypC82WYgBApMk4Mwd0/mTRkXEIJzWef8y5mH/VKed9HIo j72RLN+Iv2gaZenn2DjfH+F3BIOMrSgQqvFabOGbuITUqp7Xldgz7OcL6WqgpRjO RFOtym9n405ianjwO3U4a1Rt3br+eFrROJQE655CL2UTOArI5p7jL4XRSIwM5P1a 8F8f/fSnHLuADAkth+m17VQG7dQLJ3kpjuDDgwZkQnNlbpCFdpVk4+Xtxc/Yhxpa 0B3JxOtngYcBMMxloyB57yNkvv73gfRKgclc/UNw7hQWYbnoQDlBMxdvnlPKFiQJ g56j06rq7ZxRiadVpb0smxqP7WDCztIx3d22pF4GRSr/iRgfwZjlG4iUzDaXn4Jz H5/7jE/RAJcGupaJLSDsRjuEvwd2LhTVza6EyPk7HDFKN537F4mtp5LtGTS0ySQs 1comUzRRlVS7EgqbIZxYZ0k9sfHPlNS1obuRi+X5Emku6Le2wRzliWWjkgYFEFkm D0PhGuZjzjkTFavkJsOz3vuYXB/GrXOgKvIXYoTWY3mYPhoL87vlFCwzsdsgfYXh FBsEfx+danfwjojhI/ea6YkBHAQSAQIABgUCU+sBQgAKCRBictNXt1RfXrptCACA nPGcWLfdfcvkbRlE7Yjbw8NGvvJnImZvfWjb5lRaJhOVpxZZ+e77JDle9vezn2cZ JTABikhmI9BMGN9WCYBEETY5SJ0PxaOuptWa1rQUYK1wAoReB6dgT8mG9PODubSU rqt4lQBNIH+7F87nyESnGNUS7GgRHh2656NFnu1TJ/EId0BZIEc35Eifof6AnyLn 5lvcD25bzwrMhZqQUYKD6vkom48AJYBto0LlKJpAkA0b1CWHvtmaxaBQyKFvs8tT dA6kvRGhc3scxQVauNGJxNLIqZ2++mhhdW3trA0iG81+L6iXEiIy/XFqfcj5LNh8 PsJfNt9mtEHF+zK2UlN3iQEcBBMBAgAGBQJT6/NfAAoJEF1pxx6cpVoXb+sIAMJ3 cUa7JXYgNbRaO2I2tQKuNN+KjSJ6mrXrurLq1UCMjFoH3hInX2kfVS35aeGpa1yH mJInS9Dvl4yW+ZPnpiOtvddFWsomxYYDt3LjWda3sF3iTH+DpKuhpQV6SxNWjWQn ygih1BHfSnKV9sieiMziV/U57cr4VeulPLOp5D7aaKZRqoHvoWPk8NfGQf0xM+YM yo9nSG2EbDxwqRvh9aZ34m7rwKefTrECosfb+/N1uFDSYwRzadaBZCXsrd8/dKpQ XjE9XnTbpil4I8DaEKJxBlrmq7F599eIdZaKyqeCk42pqQRtZrrM4YjoU1r0uhmQ AQN6kCOFxb2i/wKcs4CJAiIEEwEKAAwFAlPswA4FgweGH4AACgkQ1jWx3VA74q1F dw/+JNL/i8M93/eQK5WviFcBR2j29/Gql/dX899ZBBQsWSUjv3n5JiTi0SsUpfb0 rPVNhy68Gyv5OAHe8rXHxJvbheKRN1zYV1JEM2/JZHowgOE3/XhKQH+moTOhRRG8 luLu+a6+edix+jLFLyAPvkC7HzF7wJsoeUKxoAlIcoSdORnWaambFyWD21wzlvj0 Mhsh1LOEra9PI36iXiC9UwpAvsqeL6ucHWIBnKCS0IDK2oZ/I51qX+6JmfBIYh4s v6ciyUdoI7n9h1L/7bb1rY5X/BX/xSNHIrcTKKdvDmoD4TBGndsevq0uF4gTtAid 9G8l9nqDKKEzoKLB/V9HWqh7DiUo0yXAGWnOPnVTqwu1v+3Shr7/eE+cNRW+lC+z CFwmOsZu0EpIQ//Y46x7Z6MP4aRirZVbZp6/s6W9gcvosOi+6Cdv+ESh2sA53TgY xv4nR0wYNAbK21lyJCnP4gSJTjjV7SAXQ3sxoSUZvuMrUPTwV/4QephyolVGrhHW /CDSg/GT2G2rgOQflx6PncbgMZyOKtXG+6FSNNQh/qdo4azGUZyPo2lVH8NwVOzb w4m20BUlmdWPAB3We9zWjEDg2oXie+Q/tvjiZqAZ7XuHVSJmfO98fxWh5juW+KKt 2A7b+JkQoe93ABBIMjauT/HN0uttvHA640R1R4BgvgRfAI+JAhwEEgECAAYFAlPu vzAACgkQZhiaXqIZinylwg//UVk7dpUsDeONsVdV7NoAgdk0aBqLi9in2isM4LZo irH5YJ9GDuQdZQ8dI8ZMz92E/u2+iN4CX1aa2u1HW4Lm0BbUXwu73Qxc4d3v1X5D AvXWSQreH0NDReV2J7pvpGqL8jJXf4Ob0X19rh+DfxuEIgXwYFehVOG7JWGNhI5y itZOlfCBH7QN2V6XuaEay5NSWko4N2K91dcCiMgoN71Ya/V6/oSE2OmJWY26DljY CI47e7yYEn81qpO23vWiWxM0ZXFPDrdBt7niLrQZzr6glLMl3jULj4y8ySDm4r3U r99B2bYt8Eyp0Inr+iub3iBuVV9O4Ri67rbZzW+Wpy2VftI6piTFDr1p8GHcUpZu wbRlVh7reAVoHXIxVAmB9VfXk3IR3XZynn7Y2Dq0YchNbQMm8FYTm7xTWJ141/SO 92GYz0k+roF2hiDYlVfLG7lgy6hbDTOw3lT3FctIE+p6V9GJ1DfPR/iUCYREid9y rFmTHKEnGAUduuA36UtZRwvUFgE79xf5UEOklkF1B0wdy0WCPXBVyt156FFtJH6/ inmwn/pQ/e+402I53h5r07SG4aGtROOJEzgUZXZSaSuc0+t2wFgtCgUgf1uN6igf lPzRk8NrQUE/wrUte1WmQWrd5vN05mmQ0iBUpR723RMP8rQuSBbcM778Uli+Lwrs dnSJAhwEEAECAAYFAlPvp5cACgkQb01eanorTvtGCQ//e5uJk3KvRoivoqhZ1p5D QUoZTDnGWf7JYNMptSvHsgGQr2DzxcSJ5e9oTMPuSRwVAqbhguV0noffArJxP0DH zVLulQs59znWNz+S4R9MThhHE9pcHWI+lqlterXeHfb4DpuNWW3Tq4zkoaJSLMwi 20ehpITHZ2TJy1rkwETYljMkNgBTgh4Xsa0CCVqM01D++anivAJ1u0+SpBysSeo0 lqvoMD2N9B5he0ZJzoDE/svziGwJXcEo5HTJdWrXpo2NW+GRToLQQTHeEVxGMgzn YdsQF6IRmiQnCcEzW5kvneyMeSYzbIOmuhTaA9eTJTMf21ll0rKCHzGimlIrvR74 Cnku78ozGZlM4/kRygigFpAqaXJ6kzMQs5BYcoCL+XbIy4Q/m7JQjJlpPYuRdVm+ aHgxXnm8QE72lWBrXMEQcj5wd0TF6zeoP1NoKSrlS30IX+k0doS5b3TV+meyL2ky Zk/v4G9Bvp53HYLvlcPfc7tnC7GcdnPFzDqUOG/iAd3oEYOARBuPKsbwtt0PbwJD rDp85R5dqJnBxtHwy+GhvxsUaQwlSFCWcR8CzIjQtxBy2I+KhFJeBrOr1REcIDjg CFVsrY6qnL2/ko7aqg8L1gtM4MhZB2Rgn5lldYBeqPrG9l13a5sXDpDOahq8IrXD bRVV2co/gkyHAcDyeYoOraSJAhwEEAECAAYFAlPvqrUACgkQvFIAITmUIb7CTA/+ IbFIoFyOY2zygljCeNc0R8GhLHYyVRyRYGSWXzZr1xafNTev0Uzn3OlQBgyWQFnw RU6tFzMy1kPgrVecSd+M4GlYf3UbWL87PbdhnqbQlbhmT6+3zjP7haHYDtwlEmEp v9xEOsiQ3/sMY8E9ymfTUGa/ijgmJdv/3oD17EKlxSfNjGQBl8Sd0bAeCvSTd0UI sUJsn1onc9MTYkg+jMByugzM9X5fk0wqPnezLzNO9RYwL5MWdkHm9rZH3oQt+/kn sCoTmYa3vTF6IPdJJA4wKFhyW8I/Q3ZtuI3G/rpSzfkyBnKsL7EFCsdUVCLBqa36 /oGtH/Ij4Y0VlJNl2fcSIg6ybroF62W1X0d57Vgrpks1nKnb7wQg2kmNN4nQ0tdd V1P7Cvxl0of+Uoa5xkTp21gWn9aTdAzwleR+V20eSdOcY7hK0MTsgO9ew5mmFlTr BcKRUYU7OqqwuOG5aGotcj8DCgITDDtAEuKe4ZSRVyod4uj2+2oNnMs6SuLz3t0B V2aj934wGweJc+Ol34Et1UgpnYKCqdSlnZYVb0VXxb6WAJOK3du7U0F0MuBQ1PEu 0jFUQXeCKeicuoR5fkDPv73vxnKbz4iLK4cqM5mKObkCX++ack1xXeZcPZKfxjrC pecX9NW4qn8iB+/btU5h6mtgG8w0AdOLj8Rw+P9OQBuJAiIEEwEKAAwFAlQGmy4F gweGH4AACgkQF15PwqXDsY3Ffg/8CTqwvw1r6XFV6bYQ0HL3K1Buwu9oW6m9Cckm q0OvwMzQIkL2AAzpbn1+V9piew80Cz6apA5yPsyixHUJM8UDB/D2KXUfUxx9JZCo MdF4eaV+p7BAe7Oza6ZgpWZyxdHmOnu+/ivj+yZwDM0a0FZQyUwmTHMbylq9CTH/ 3E4b1qyE0v/OI8EgMNn+wIggENm006spCsTUN8NGcA8EBrTpRX+uxQWo2Jv768QP 4g+edJpG0wObAxt0Qxx+AOyHBTwQYB099kCWVcfOF1pyWtHlYa3ZPRFco7KW7QAd aB4c9K1bMAKbn0Ayzay9ySmtvks2c2Qrw5aDQPnIWJYx7VjTlQ+/7fwap+lBYBRt RaO7JuSZIkGbh+N4oj3xoOxtct5pSPPvIZfzxwXryl31QkNSCMFrR+QMm3h4ZqYS VUz34qnl1OPC5XwZJXiHzS8O3BmOWUzd2aiBxcAx+6LYeFmoS++eZy9GBzjl5004 IchYXvGn4ugmAC0ij1FjBslC6sZ4QX2gMHZ3+IgRGuvlPmu8lCo2GnplryaOU61Y pHDhNMlpx24Gazj3G7LwbPU/6yufioKh6QzlVqYqcSr/H8cCc11ZmJkoFFq7apzx 6PPfebd1HqlgpqCgzJehY0Hbw/i73EeavXZhSTcAichJfWweBE+cISqpuM4f3M9+ 7z7oYlCJBBwEEgEKAAYFAlQZtkkACgkQH/M+0LxxvETE9SAAjKxVDGAZ1F8ZQ9pT 8AWDUBXpqtBBd4PiEmi45/edLr7ukuH5yn0AAalAjsumJNzH0sVnEySxGaaq/r7p VLNAmodOYNpmZhkKnkuXMPKyE8NiH8ajZ3xFSmpe6UdhJEa9RjsKgZYuoEV+oHPo 3h10d178GOimTYFAG1AxHYZVkYGlwtpNakAO1UGTKYeM0Kg0av4o7aBK+vNGDgQs Xr8+9dK/8JbtfzZQ3RiAIZQYUF7KOf20/7hJwdRtigZJ7qkU04jwk/FBhMk1wsPf qi+qLzr3Xs7L0vAdqyR2sddyZgK/yLEZXwVo25vex+9+3Kk33u6g5eA76Q6IRazp UNeO/WCQcAmLZ94ABF35zHEKlMFIa7FeUzeFW3ZfxQY8bkUy4JvA0uxYPR5iDPxK apKU9vcjKdKSFD0mHbAPOiX+pyAkm70eVNXxG0HdAXxDDTfMOS8x7YYvPLr1ubkU ogBm01V2HS8O6NhwVUgREV6h5g3At2ZQDsvdues9YhvaWfOunP3PliWybzAPvhcz GQdkj9adupu85u/u+MjnZzsG9/ITQ60S5Wg4KtL85UKY6Z2djDy7JZzuSStmt6Zv fkfndM2ZKKj+ZsgLIyyFxZk5pZZTCsxHniquSpXGMeQCVBjbQNp4p8RW0/kLFLIk kfMhF7StdJYJb/LUI6N4UocPq2w1XnD8W+NrzFtDL8Jg1awRg3c3fJrJzTJUCyJe zkvrvk5Z+GeHwa6YFk8kN6dNmBdZ2clBImD9GsOPBdrBFlPTh54lwgskudD9gNM4 GdS0EMrFgL8wOOIbAh7nNi3PE23kaZB8LNERETon2q/vG7a25NMjIZet53zqqe1x qxBiMG6l0u45aadTr5+DFB8pIZArwbHjNZ3k6UbYEzJIdWR8lkSks54lHLvYV1Q0 X9fuBI4Q4mdjBajLwPQpiVmSDkZJckdTkecV+3DOBlylqS7sogKv0Gjva5ls7ghs cKJF7/cAcbWfAIN673TEGBvF//AgmB4yXG1JnlUfLbtLvGktasQ0P/sujX8tMl7n A7Q9h5k/TkUSInZkKuWUovrJSGB0zsdJJdpiv6okgeNPnd8+TnFTubfcCfFSnUa1 gbFqyqvuMVmzNabh3vVPpCFWGCeCYsMon+jPbWcshY+mESVjOM0c5MP/ny3R4d6Q ULibMXCKSkZCDnPlnSH4us+LrAzLRtgw6/e7frnUC/xTd/03IvIM6H0AnFgIv6os /pAXmLEbcCznsqykgBDJgkRdscan4UfrHCR4B1noMxqOJSX00koVG6GeJEQpWns8 hJIvqciT5XUmMInxN1+aPYEWFXJnKmmp49zUCm6nKf4K/Z9vO1Dy9uwLAYq/GG7G xVLD5IkCQQQTAQgAKwIbAwIeAQIXgAoLCQ0KCAwHCwMCBxUKCQgLAgMFFgIDAQAF AlPc0vsCGQEACgkQXytHVu2HPSOB3g/8DNB8UYeB/btVQ+JjOIqOdjtmktyZjjSU p0WLXYQ07ZGX5SghkaBjUEC/nCa/cyREsvvo/B8iYSneZJehU00n3PIb8MEwnCOL BvMWYm6cw93kf+hMtjT3DKoIOpUc+LOve8f900k90K7IqIZIX227L4fD/bQPWxdA 4QYv4pwk9PeY7uHQYuPnQ7QSG1r8RFGX5ubtiC+lZb+P3Gh9BeOAIK4eGPeQjhKZ Yx/A2mH9+qbKWyWSS9Quw6ooR0lAzVU0k/bGx1Oj6AWxO02zt1pjauAUWJRYky2V /aQc2gad41oVeAJ2fkpU5n/paxJyAkFPXkUA9j2bIoVH07YaVvTGH+kBuxgTZCQv UA7ntb8ZIQAXbaOHX+lDJAfiIzfCgjvn2Y4MmMl1NWnYtQYmIOJzk1JvHpfKC54B cA6k+hZh7S0WKBTb6qVcHKi81xortF5uuVpeSvPhlUrJ1FQgIysrtsT3bPS1Hh0Y gVthHC05GzDj3Ij0ry7/QISYtxiq0Z5waAaeNngPlB9zaKste9yKyREm0UHo0bY0 k4K3Ywzj9Rzs2S/YdZrfb2WAIohvi+evsEafLzrZEt78CecRpHfJyhv7BI4vnhB+ 3frR6LaEbdkX5blF3MdsXec2wwPolA48vsGin0/RyUKoIJ3QVvBPwJmc7D0auWMA NE5rfb94NUSJARwEEAECAAYFAlRgzN0ACgkQPogg/4XFQdmIMgf+KWkhiWZZVi+K IyxJoJewniHVd2tnwUB6AeFPXrkc58jkLX+7alQY+CrTFYcZ4ojK5Xv70kX3BUZI Z2hzcy/d13OXPpaLorM5ngcjLhURGjL10/1Rlq8S+jWJzQ2eCv2PtGfbF23dWhKp fyX+V7kO1DRATu6xlmrGD1cY5zFpEMCiC96ZweK1jztN0kFOpjEQqC5RQOwwMsTZ 0rpWZ2TNtdiH2u2SS0+cAr0KP1Tm1HeKQcnUtFDlQd+GFTDO1ofRqbNTy4PQeq+s i1IWGSfRatfR8yW0hE90NEn+09sW75RHtEOL5Kavyh4Io2Ms43Sna3Buv3Nnh6HH uGj4IKMy07kCDQRTzs01ARAA8jMbb8iyvIQJPjYg96ifkwNd1UsqWQqbjgmxHQ93 b27FWzJEr9DrTxFnlHE1Xp/7XbRD83xpVzBhr/0O758HmM14oJFu5pyao4y2xJMz /Y4CSmi650kixhrJefZz7vZ4SEEo2xMbLPnFwQG1h6L3ixw6UYUGuF+YZ42ClDln TshR8npeWax4x+wnWFK3rsfKXMh442IJFIExLhzWlS8amj/Ir6kQUSeRNdry5CRh wPdFwVl9Tj/Nf/H+keMdvar43KzgFNJ/DHh8yshIQBB96ja763gXXH5wJ/mf7CCh dbgZqKXU9RD0t+zumvb+jGTgSrIfdI/D6Lc4r+iC4N1aXhaleH2PUC5vMN1Vxvnr UPPFU1O7O4jZjX3SRPiprmkwqjzfiPYhgLOGT+ejWjOjYuuKBXH7YNzYMc7HUV6p 3BHEylgCmJ96yRzxNDouI1PAgVatu4/d5ZFFj6ibtqObo4UAZQ+8At4Ys5zOjxHX Fst7CtodUWotl8B6ZWv5yHW07qGZ0xdRpwduHWj7mqAUEot+2YLMGry2fSdCbpcg uTWIvKQQnF0tQq8sEuuVpQ2MNosm3hm+u0kajzjltwP/W0TVg96Rt03mZ3IAdYcl VPgoxHIVKOa+pNQLmC0eZk1dZ3X9EFr1D5M3CSdG8VH7HZqKk4N3dzpQ3oBoAkmK or8AEQEAAYkCHwQYAQIACQUCU87NNQIbDAAKCRBfK0dW7Yc9I8aiD/9YS+IgcZla HVrN/H7sewqyNEUa5T4wz6F3QvT44+QxJBKCW/NQuUrnqv7hn2DImXMXeG8/99WP KM3tHf0mxq2/uLOMqi92SzuSP2Qefbp3P/VviaBzqkIEIQWGCczQ//Dg8sWX/UbA xhZ5he/PESjRx0PmWSsPvhGOisxcZV7BVmmpICd9W6l6i55oHWXnpVivVBmAK3+X InQ4ybCJ0+jAZ5FlOmoGuwq1OXX0h97P0h4Hzb3u7jEwdkVsSx4BvtlIwld9+alC 0izsCC6fCHpjrK31nTffFJ/PhvojLGiRla6f7qNKFRHabY7U0ldYMfSgsGInICTv t2py2SdBWQh+SO/K3Y6Pb96Y/tDQUHLay31dmXCoTslcebseZCW+WPOGKehlBFWd hDGuP/2HqJbU/HG1k8OKIqPYIFVFbtzX0rzuq7M4pRlJ1fSg08QMTOQjhfrbm46G NT2xwaAIpHnDBD7BC7R+xrY60wiEqqAPISJsUDJFK7cRQjZV0L7+k9+IjspuzYYv Xr2mKKIAojUE/KLxbd6KuXIk07P+vKse66oC8XVpbn6ckMypftidYyyyH5jej2NP 0FuP9jjl8eYgSZl9tqaU6Y9vDyXzE0h6F4SUPiBx3hEIrVzFJym0d6/t562bstQO pIPGkZxLOFm59msUf9mBqw7rJEs/EqhQ2w== =7DhM -----END PGP PUBLIC KEY BLOCK-----

Fingerprint: EC2392F2EDE74488680DA3CF5F2B4756ED873D23 Long Key ID: 5F2B4756ED873D23 Short Key ID: ED873D23

(Did you notice that the long and short key IDs (of any key) are just the last 16 or 8 digits of its fingerprint respectively? I didn't know that for a long time, but it's obvious when displayed this way. See the Finding your longer key ID section of this document for more.)

This is also available in a plaintext file.

In short, public-key cryptography solves the age-old problem "how do I communicate with someone securely without somehow exchanging a secret password first?" Exchanging a shared password securely is a hard problem. You may have no way to do so if your communications are monitored.

With public-key encryption, instead of sharing a password, each party generates a "keypair" consisting of a "public" key and a "secret/private" key. Each party can then publish their "public" key to the world or send it directly to the other party, while keeping their secret key private and safe.

If you have Person B's public key, you can do a few things with it:

Encrypt a message that only that Person B can decrypt. (They need their secret key to decrypt it.)

Validate that Person B signed a message with their secret key. This also lets you verify strongly that the message was not corrupted nor modified in transmission.

With your secret key, you can do a few things:

Decrypt messages encrypted with your public key.

Sign messages that others can verify came from you (they need your public key to verify the signature.)

I accept and transmit all messages using the OpenPGP format, which is an open standard, (RFC 4880) and the most widely used standard for public encryption, so communication should work with any OpenPGP-compatible program.

For encryption and signing of e-mail (on Windows, Linux, and Mac) you can use a combination of:

If you're on Fedora, you will have infinitely better luck installing Enigmail from the Fedora distribution rather than obtaining the plug-in elsewhere. Install all three packages it by doing the following as root:

dnf install gnupg thunderbird thunderbird-enigmail

After installing or updating in Fedora, you may not see the OpenPGP menus in Thunderbird until going to Tools | Add-ons and then disabling Enigmail, restarting Thunderbird, re-enabling Enigmail, and restarting Thunderbird.

My main gripe is that Thunderbird changes version numbers rapidly and Enigmail sometimes doesn't keep up, which makes Enigmail claim that it's incompatible with your Fedora version. This is an important reason to use a package-manager like dnf on Fedora which tends to keep them in sync. This is another reason it's good to know how to use the gpg executable manually.

The first thing you want to do in Enigmail is to make all of its settings visible. You can do this from the menu items Enigmail | Preferences | Display Expert Settings and Menus . The basic settings are inadequate.

Note: As of the latest update of Enigmail, around July 2014, the text used in several menu items has changed. The old top-level menu item was called OpenPGP and the new one is called Enigmail . You may need to mentally correct these examples if you're using an old version of Enigmail.

In Enigmail, I've had the best luck setting the keyserver to default to pgp.mit.edu , but this may no longer be necessary as it now contains a list of default keyservers which are more stable than they used to be. (But often still down.)

The Gnu Privacy Guard FAQ lists some of the other e-mail programs compatible with GPG. Note that you can use any e-mail program (that doesn't corrupt messages) along with the gpg executable on the command-line.

For Macintosh, you can obtain GPG from the GPGTools website. (I haven't personally used these, but others have recommended them.)

Alternately, I sometimes use the pgg package in Emacs/XEmacs which is a wrapper around the gpg executable's functions. You can do something like highlight a region and do: M-x pgg-encrypt-region and encrypt directly within your documents.

For encrypting files, or doing anything more interesting, I just use the gpg program on the command-line. If you're security-paranoid, the fewer executables, the better. Most of this document teaches you the fun and important things you can do with the gpg program to be secure.

The developers of the Android K-9 Mail application recommend "Install the app OpenKeyChain: EasyPGP to encrypt/decrypt your emails using OpenPGP." Although I use K-9 Mail, I have not tried OpenKeyChain and I can not vouch for it.

On Android, you may want to experiment with R2Mail2. I haven't used it and can't vouch for it.

There is also Android Privacy Guard (APG) (no longer linked here; see below), which integrates with the K-9 Mail program, but I do not vouch for it. APG was not updated for several years, but has seen activity more recently. Warning: This is why I don't trust APG. If I were some corrupt actor, I would look for some cryptography package that nobody has updated for a long time and offer them a bunch of money to buy out and corrupt and back-door their package. This is exactly the model of a product I wouldn't trust.

GPG version 2 may be on your system with the executable name gpg2 . Either executable can be used for these demonstrations. Both are mostly compatible with each other. (If you want to know a million different opinions on which you should be using, do a web search.) Version 1 is more tested, and is usually a single monolithic executable. Version 2 is compiled with crypto libraries like libgcrypt externally linked, and is designed to work better with external password entry tools. That is, gpg2 is designed for graphical environments, while gpg works better for automated and command-line use. From the command-line, I use version 1.

Update March 2017: gpg2 contains elliptic-curve algorithms for generating and importing public keys. (These might show up as " ECDH, ECDSA, EDDSA " when you run gpg2 --version These elliptic-curve algorithms are not contained in gpg . If you attempt to communicate with people who only have elliptic-curve algorithm public keys, you will not be able to import their public keys with gpg , and you may need to use gpg2 . In general, it is believed that elliptic curve algorithms require shorter keys for the same level of security as, say, RSA keys. I will go out on a very solid limb and say that the length of keys is not very important in the contexts where GPG is used, because a public key is only imported once, and the length of the key in this context matters very little. Nor does the time taken to decrypt an e-mail. (Key length only really matters when you're contacting, say, lots of websites and milliseconds and hundreds of bytes matter.) If it takes even several seconds to decrypt, it's usually not important in the context of GPG. The only important factor is security. I do not vouch for the security of elliptical curves over integer factorization over discrete logarithm calculations. A breakthrough in any of these fields can render any superiority moot (let it be noted that many, many smart people have studied factorization and discrete logarithm problems longer than they have studied elliptic curves and have not made any significant published breaks over numbers of the appropriate size.) Some people may only publish their public keys using elliptical curve algorithms which are only usable with new versions of gpg2 . The people who do this are almost always smarter than me or you (but history may not prove them right.)

Update October 2015: I have now seen cases where gpg cannot import keys from some clients, notably keys sent by Mailvelope (link opens in new window,) a client that helps you use encryption with web-based e-mail services like GMail or Yahoo. When importing the key, the error message may look something like: gpg: assuming bad signature from key BACD0190 due to an unknown critical bit

gpg: key BACD0190: no valid user IDs

gpg: this may be caused by a missing self-signature

In this case, the gpg executable is telling you that it doesn't understand some of the subpackets sent in the message, and, according to the OpenPGP specification, (RFC 4880 Section 5.2.3.1), gpg is correct in treating the signature as invalid if it doesn't understand the subpacket type: 'Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error.' 'An evaluator may "recognize" a subpacket, but not implement it. The purpose of the critical bit is to allow the signer to tell an evaluator that it would prefer a new, unknown feature to generate an error [rather] than be ignored.' If you encounter this case, then gpg likely did not import the public key correctly, and you will need to try to use gpg2 to import the public key. (For me, gpg2 could import public keys that gpg could not.) It appears that, once you have correctly imported the public key, you may be able to use gpg or gpg2 to communicate with the other party, depending on the particular feature that was requested. By the way, at this point, I neither endorse nor discourage use of Mailvelope. I have used it to apparently encrypt communications correctly with GMail users, though.

The simplest way to import my key from an e-mail client (like Enigmail) is to import it from a keyserver. In Enigmail, you can search for keys using the menu items Enigmail | Key Management | Keyserver | Search for Keys , and then searching for my name or my e-mail address eliasen@mindspring.com or my key ID, which is 5F2B4756ED873D23 or the shorter ED873D23 . Then select its checkbox from the list and click "OK."

A lazier and more dangerous way to import my public key from Enigmail is to try and send me an encrypted e-mail. (When composing a message, choose the menu item Enigmail and select both Sign Message and Encrypt message .) Then, when you try to send, Enigmail will realize that it doesn't have my public key, and will bring up the Key Management window. From there, you can choose Download Missing Keys .

Another way to import my key is to e-mail the plaintext version of my key to your own e-mail address and choose the option like "Import PGP Key."

If your e-mail client doesn't allow automatic import of keys from an e-mail message, you will need to save the plaintext file listed above key to a file, then import the key manually. From GNU Privacy Guard, this is:

gpg --import [filename]

My key is available from pgp.mit.edu (all the major keyservers mirror each other, so you could probably get it from the keyserver of your choice, but this one seems to be pretty reliable.)

You can browse the keys available on keyservers at pgp.mit.edu or the often-slow sks-keyservers.net. Who do you know who has a posted public key?

From GNU Privacy Guard, you could import my key using the following (but read on to be more secure.)

gpg --keyserver pgp.mit.edu --search-keys eliasen@mindspring.com

Note that in all of these examples, whenever you see an e-mail address, you can usually substitute part of a name or part of an e-mail address, or a key ID. Most of these commands perform a substring search.

Or, even more directly, my full key fingerprint is EC2392F2EDE74488680DA3CF5F2B4756ED873D23 , (it's more common but less secure to use the last 16 or 8 characters of a key, so ED873D23 will work too. (Note that the shorter key IDs are just the last 16 or 8 characters of the fingerprint!) Read the technical note on Short Key IDs below for interesting attack ideas using short keys.) The following gpg command will import my key from a keyserver, using my full fingerprint (you can also use the last 8 or 16 hexadecimal digits of the fingerprint as the short or long key IDs.) You may need to prepend 0x to the fingerprint in some versions of GPG, or when using the key ID with the --search-keys option.

gpg --keyserver pgp.mit.edu --recv-keys EC2392F2EDE74488680DA3CF5F2B4756ED873D23

Read on, though, and see why just importing some key off a keyserver isn't enough to be sure that you're talking with me.

You may not have to specify a keyserver in the lines above. Later versions of GPG have a more reliable keyserver list built in.

sks-keyservers.net monitors the status of keyservers in real-time. (But it's often down.) If you're having trouble importing signatures from a specific keyserver, or want a list of available keyservers, you might want to look there.

gpg --help

is your friend. It will list the most common options to GPG (but not all of them.) Other complete documents are available:

I long resisted the temptation to give an overly-simplified "Getting Started" section here because that may falsely lead you to believe that you're being secure. As this document has expanded greatly, it's becoming a better guide. However, the best way to get started with encryption is to go to the home site for GNU Privacy Guard and read the "GNU Privacy Handbook" (available in lots of formats and languages) under the "Guides" section. This will walk you through setting up GPG on your system, including creating your secret keys.

Creating your secret key will start with:

gpg --gen-key

You should probably use the default settings, except it doesn't hurt to make the key size as large as allowed (4096 bits currently.) The larger the key size, the longer it will take to initially generate your key (and encryption/decryption will be slightly slower. That is a Good Thing, as anyone attempting to break your encryption will also need to spend more time too.)

After generating your key, one of the first things you should do is create a revocation certificate:

gpg --gen-revoke --armor --output=RevocationCertificate.asc your@email.address

This certificate can be used to revoke your key if it is ever lost or compromised. Do not neglect this step! Print it out, save it on a disk, and store it safely. It will be short enough that you can type it back in by hand without much effort if you just print it out.

If you lose your secret key or it is compromised, you will want to revoke your key by uploading the revocation certificate to a public keyserver (assuming you uploaded your public key to a public keyserver in the first place. See below.)

If you have multiple unrevoked public keys and you have messages that say something like "I lost that one, this new key supersedes the other ones," (and I've seen this from people who like to claim crypto experience) then I know instantly that I can't trust you to follow good practice and maintain your secret information, and that I shouldn't trust you with my secrets. So protect your revocation key like you protect your secret keys. Read on to see why the "this key is my new key, ignore the others" excuse is an immediate "red flag" that should make you suspect either cryptographical incompetence or warn you that the person's being impersonated.

Using Stronger Algorithms

This section is optional but important.

By default, gpg uses weaker encryption algorithms than it could. This is to ensure compatibility with older versions.

If you want to start using stronger algorithms from the beginning, jump to the Using Stronger Algorithms section below to see how to use stronger algorithms by default. It may be important to do this from the start, as the algorithms that you want to use are specified in your public key. (To be more specific, your public key lists the algorithms that you request other people to use when they encrypt messages to you.)

Now, since you have my public key, are we secure? Well, no, not at all. Lots of people just getting started with cryptography don't realize that they have to somehow verify that this key belongs to me. To me, Alan Eliasen. The one who wrote this message. How do you know that the public key posted above is the one I posted? After all, the bad guys could have replaced it somehow.

Listen carefully. This is important. Anyone can generate a public key for any e-mail address. Anyone can post that key to any key server. Only by verifying that the key really belongs to the person you think it does does it give you any security. Without this crucial verification, all that your cryptographic software does is ensures that bits weren't corrupted during transmission, and prevents casual observers from reading the message. It does not mean that you're talking to who you think you are. You could be talking to someone else entirely (a bad guy,) or you could be subject to a man-in-the-middle attack.

Update: As proof of the above paragraph, after I posted this document widely, on 2013-07-12, somebody generated a fake public key with my e-mail address and uploaded it to a key server! This is why you need to validate the key directly with the person to make sure you have the right key and the right person! That is, however, an unavoidable problem with public key servers. I thus can't be mad about it, but I can try to educate people to recognize this possibility and do the right thing by validating my public key with me personally! Note that picking a key from multiple options on a keyserver based on which is newest or largest or by comments about "this is my newest key" is dangerous and wrong.

Another Update: Forgery of public keys on keyservers is now widespread. On 2016-08-15, many people noted that someone had uploaded fake public keys and signatures for everyone in (an old copy of) the GPG "strong set". These keys even matched the short key ID of the original key, as well as forging all its signatures! It appears that someone finally uploaded the proof-of-concept that the folks at Evil 32 had posted years before.

Still, if you want to send me encrypted e-mail, that may prevent other people from reading it. That's good, and sometimes that's all you need. Just understand why I don't have any reason to trust that you're who you say you are, and you don't have any reason to trust that you're really talking to me unless you've verified my key with me. Before I trust you with any secrets, I'll validate your identity.

On the other hand, you may not be able to verify someone's fingerprint in person. See the Web of Trust section for more about this.

A key could be verified in many ways (such as, I could read you my whole public key, which is really time-consuming and error-prone. It's also bad because the key you see above can get longer and longer as other people sign it.) The usual alternative is to compare the fingerprint of what you think my public key is with the fingerprint of what I know my public key is.

A fingerprint is a shorter number (usually expressed as a 40-hexadecimal-digit number) that contains a cryptographically strong hash of my public key. It's shorter than my full key, so it's not an unfoolable test, but the probability of finding another key with this fingerprint is very small indeed. Infinitesimally small. So small you don't have to worry about it. If someone else can find a matching fingerprint, they have enough power and money that they could make you vanish from the face of the earth. So, after you've imported my key, type:

gpg --fingerprint eliasen@mindspring.com

This will produce output that looks something like below (I have put the fingerprint in bold.)

pub 4096R/ED873D23 2014-07-22

Key fingerprint = EC23 92F2 EDE7 4488 680D A3CF 5F2B 4756 ED87 3D23

uid Alan Eliasen <eliasen@mindspring.com>

sub 4096R/5314E70B 2014-07-22



Then, you need to verify this fingerprint with me. It's best to do it face-to-face, but if it's someone you know by voice, you can do it on the phone. If you don't know the person, check their driver's license. Ask other people (that you trust) who know them. Even if you don't know them, at least you're verifying that the key belongs to the person you're talking to.

The other person will need to verify that their (unverified) copy of your public key matches what you know your public key to be. So bring a copy of your own fingerprint to the exchange:

gpg --fingerprint your@email.address

Of course, change the e-mail address above to the e-mail address you're confirming.

Corollary: If someone puts the fingerprint of their key in their e-mail signature, or in a web page, they really aren't proving their identity. Think about it. If someone's pretending to be you, and forging your e-mail or your web site, they'd certainly replace the fingerprint too. It's not enough to rely on. If you see someone with their key fingerprint in their e-mail signature, it's not a reliable sign that the key with that fingerprint truly belongs to them.

On the other hand, you may not be able to verify someone's fingerprint in person. See the Web of Trust section for more about this.

If you want to view a person's fingerprint or key ID in Enigmail, you can view that in the "Key Management" dialog, which is the place where you can view and manage public and private keys for everyone in your keyring.

The steps to view the fingerprint are to follow the menu items: Enigmail | Key Management | Search for a name | Right-click the name | Key Properties . This will bring up a dialog containing lots of information about the key, including its key ID and fingerprint (unfortunately, it's not easily printable.)

My Key Verification Protocol

If you wish to verify this key, please contact me and I will verify its fingerprint in a public meeting-place. I will be wearing a trenchcoat and a navy blue ascot. You must wear or carry a yellow tulip. Any other flower signifies that contact should be aborted, even if the exchange below is executed correctly. I must not underestimate the necessity of having an adequate stock of proper yellow tulips on hand for this purpose.

I will say "The adobe is filled with an excess of straw this season."

You must reply "The straw is for the young lambs which roam the heaths near Glasgow in the green, green spring."

If I am satisfied with your response, I will reply "The greens at Saint Andrew's are boiled with ham and contain an excess of bitter kale."

Do not make eye contact or show signs of recognition. If necessary, I will read the hexadecimal digits of the fingerprint while feigning a book order on my cell phone.

Okay, I'm sort of kidding about this section. But you must verify keys with the other person to be truly secure.

If you have verified my key, and trust me (and trust your own verification,) be sure to sign it.

Now that you've verified my identity, and my public key, you need to tell your cryptographical software that you trust my key. Otherwise, your cryptographical software should do the right thing and warn you that you're communicating with someone that you haven't verified. It's telling you that it has no reason to believe that the key you're using is the one that actually belongs to that person.

Below are tips for signing and trusting keys using both GPG and Enigmail.

I'm a bit reticent to recommend using Enigmail to sign keys because some of its dialogs are deceptive and wrong. Read the next part very carefully.

In Enigmail, you can sign keys by going to the menu item Enigmail | Key Management .

Search for the key, and then right-click it. You'll get the option to sign the key.

After signing the key, you should assign a trust level to the person signing the key. Right-click the key name and choose "Set Owner Trust". Warning: This currently pops up a dialog that asks "how much do you trust the key?" but that's not the right question! The meaning of trust in the GPG software is how much you trust the person to validate other people's keys, not how much you trust the key itself! In GPG, the question is stated as:

"Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.)"

As you can see, that's a totally different question. This is why I encourage you to learn by using GPG on the command-line. It tends to be more rigorous and correct. Also GPG gives you more warnings about selecting dangerous choices like "trust ultimately." Read the next section to find out more.

To sign my key from gpg, you'll do something like:

gpg --sign-key eliasen@mindspring.com

(but see below for a better option.)

This will give you some options for signing the key. Even better would be to edit your signature and trust settings for this user using the interactive menu:

gpg --interactive --edit-key eliasen@mindspring.com

Hint: Type help for the interactive commands. The commands sign and trust are the ones you're looking for. These allow you to both sign a key and indicate how much you trust me to verify other peoples' keys. If you think I'm stupid and lax when verifying and signing other peoples' keys, you'd assign me a low trust rating.

After you've signed someone's key, you should send it back to them so they can show other people that you've signed it. You can export their key using:

gpg --export --armor their@email.address

and then sending that output to them. They can then import the changes using

gpg --import

In Enigmail, you can also attach any of the public keys in your keyring to an e-mail. As you're composing the email, select Enigmail | Attach Public Key... and select the e-mail addresses to attach. Note that these will not show up in the body of the message, but as a (possibly-encrypted) attachment, possibly using PGP/MIME. For maximum portability, I recommend attaching using the --export method above and including the public key in the body of the message. My reasons are stated in the Attachments section.

You can also upload that signature to a keyserver, which makes that signature available to the world. See the Publishing your Public Key section below for how to do this.

If you're really not sure about my identity, and don't want to vouch for me publicly, you can locally sign my key, which means that you trust it for your own use only:

gpg --lsign-key eliasen@mindspring.com

Hint: If you publicly sign my key without actually verifying it with me, I'm going to assign you a very low trust rating.

Sure, you can manually send your public key to people you want to communicate with, but what if someone needs to communicate with you securely and you haven't sent them your public key? The usual way is that you publish your public key to a keyserver so that anyone can import your key. Most of the keyservers in the world mirror each other, so a short time after you have posted your key to one server, it will be propagated to the others. As I have said above, I've had good luck for the past decade with pgp.mit.edu .

You have some responsibilities before publishing your public key (or someone else's) to a keyserver, though. As mentioned above in the Getting Started and Procedure for Verification sections, you better have generated a revocation certificate for your key and put it somewhere very safe. Otherwise, if you lose your secret key, or it becomes compromised, the corresponding public key will sit forever on public keyservers, mocking you and demonstrating that you don't know how to protect your secrets properly. If you think you can delete a key from a keyserver, rather than revoking it, read the FAQ at MIT's keyserver. (I think it's funny and awesome that they have a fake "delete a key" field on their website that just redirects to that FAQ no matter what key you enter.)

If someone has your public key, they can basically do a few things with it:

Encrypt messages that only you can decrypt. Validate that messages were signed by your secret key with a strong guarantee of certainty, and ensure that those messages were not tampered with or corrupted in transmission.

These are good things. You want people to have your public key. So below are a few methods of publishing your public key to a keyserver. All achieve the same results.

Now that you have generated a secret key and a public key, how do people find your public key so that they can send encrypted mail to you? You can send someone your public key directly by, say, putting it in an email. To generate a copy of your public key that is easily e-mailed, you can do:

gpg --armor --export your@email.address

This will generate a nicely-formatted "ASCII armored" version of your public key which is suitable for e-mailing. "ASCII armor" is just a way of turning raw binary data (which will probably get corrupted if you try to send it through most e-mail programs) into a format using only limited ASCII characters, line-wrapped, with appropriate headers, and suitable for e-mailing. (Hint: It'll look something like my public key at the top of the page.)

Note that the lines that begin

-----BEGIN PGP PUBLIC KEY BLOCK-----

-----END PGP PUBLIC KEY BLOCK-----

are a necessary part of the message. Don't forget to include them!

Once you have this ASCII-armored public key, you can manually paste it into a form at a public key server like pgp.mit.edu

Again, just because someone seems to have sent you their public key, there's no reason to trust that it's from that person unless you have validated it with them using the instructions in the Procedure for Verification section above. Make sure you verify any keys before trusting them!

One way to publish your key to a keyserver is the manual approach from the previous section: export an ASCII-armored key and manually paste it in to a form like the one at pgp.mit.edu.

The other way is to let your gpg program upload the key. You can't do this by specifying the e-mail address; you need to specify the public key's hexadecimal ID number. So how do you find this for the key you want to upload?

gpg --list-keys your@email.address



pub 4096R/ED873D23 2014-07-22

uid Alan Eliasen <eliasen@mindspring.com<

sub 4096R/5314E70B 2014-07-22



In the above, my public key id is displayed on a line that says pub and contains an 8-character hexadecimal code ( ED873D23 in the sample above.) You will need to know this code to upload to the server.

gpg --send-keys keyID

gpg: sending key ED873D23 to hkp server subkeys.pgp.net

You may want/need to insert --keyserver pgp.mit.edu as options to the above if you want a specific keyserver. (These options have to go before commands like --send-keys . Again, most keyservers mirror each other, but it will take time for keys to propagate across all servers.

Note that after you've signed someone else's public key, indicating that you've verified their key and identity and vouch that the key is theirs, you can use this same procedure to upload your signed version of their public key to a keyserver, so people can see you've vouched for them. See the Web of Trust section below for more information about this.

Again, in Enigmail, everything you do with keys is accessed through the menu item Enigmail | Key Management . Search for the key you want to upload, right-click it, and you have the option to upload it to a keyserver. Couldn't be easier! You still have the same responsibilities to be very careful with signing other people's keys, though.

So you've received a file or message encrypted with GPG, but you don't have a fancy e-mail plugin to help you decode it. So how do you decode manually? Simple. From the command-line, if you just run gpg it will prompt you for input:

gpg

gpg: Go ahead and type your message ...

From there, you can just cut-and-paste your message directly into gpg, and it will decrypt it, or import keys, or whatever is appropriate to the message. When you're done pasting, you may need to send your operating system's "end-of-file" character. This is Ctrl-D in most Unixlike systems and Ctrl-Z in Windows-like systems.

If the encrypted data is in a file, you can automatically process it by just passing the filename to gpg on the command-line.

gpg myfilename



The gpg executable will generally just do the right thing with it, prompting you for passwords when necessary, saving output files, etc.

Warning: When gpg encrypts or decrypts a file, it usually leaves the original file intact!. You must remember to delete the original file yourself, securely if possible. In Linux, you can use shred -u (shred just overwrites by default; the -u is necessary to delete the file afterward) or wipe commands to delete securely. On Windows, sdelete works well. (Although secure deleting isn't guaranteed to work on solid state drives or flash drives due to wear-leveling algorithms. If you're using one of these, and want to securely delete, you have to write over all your free space with a tool like wipe or sdelete ) However, don't believe the hype that you need to do dozens of overwrite steps. This is very likely urban legend, or marketing lies. One overwrite is probably plenty.

While gpg's default action is usually sensible, when you run gpg to decrypt a file without any command-line options like:

gpg filename

You should be warned that the default action (when passed the name of an encrypted file) is to decrypt the file and leave the encrypted and the decrypted file on your disc! This may be dangerous as it theoretically allows an attacker to mount a "known plaintext" attack. You almost never want to have encrypted and decrypted versions of the same file on your system. You must remember to delete one of the files yourself, securely if possible. See the warning above for more details on how to do this.

However, if you just want to view the contents of an encrypted file, and leave it encrypted, without saving the decrypted version anywhere, use the -d or --decrypt option (which are equivalent.) This option just decrypts the contents of the file and displays the file contents to standard output, without saving a file. Your command would look like:

gpg -d filename

This never saves a decrypted file anywhere, and lets you easily look at the contents of encrypted files.

If you don't have a fancy e-mail plugin that helps you encrypt your messages, it's easy enough to do from the command line. You'll need to save your message to a file.

gpg --encrypt --sign --armor -r recipient@email -r your@email.com filename

There are several important things in this command.

--encrypt tells gpg to encrypt the message using public-key encryption.

tells gpg to encrypt the message using public-key encryption. --sign adds a digital signature that lets you guarantee that the message was generated by you and was not corrupted nor modified in transmission. This is theoretically optional, but see the Signing Messages section below for why this is very important.

adds a digital signature that lets you guarantee that the message was generated by you and was not corrupted nor modified in transmission. This is theoretically optional, but see the Signing Messages section below for why this is very important. --armor wraps your output in plaintext "ASCII armor". "ASCII armor" is just a way of turning raw binary data (which will probably get corrupted if you try to send it through most e-mail programs) into a format using only limited ASCII characters, line-wrapped, with appropriate headers, and suitable for e-mailing. This is necessary if you're pasting this into the body of an e-mail, or usenet posting, or forum posting, etc.

wraps your output in plaintext "ASCII armor". "ASCII armor" is just a way of turning raw binary data (which will probably get corrupted if you try to send it through most e-mail programs) into a format using only limited ASCII characters, line-wrapped, with appropriate headers, and suitable for e-mailing. This is necessary if you're pasting this into the body of an e-mail, or usenet posting, or forum posting, etc. -r recipient Specifies recipients of the message. You must already have imported the public keys of the recipients. You can specify multiple recipients. If you don't specify recipients on the command-line, gpg will prompt you to enter them interactively. These recipients can also be key IDs. Warning! This is important and interesting! Note that in the example above, your email address is specified as one of the recipients. If you do not explicitly add your own address to the list of recipients, you will not be able to decrypt the message! That is interesting and important and awesome. You may want to write something and send it to someone that you cannot ever possibly be compelled to decrypt! It will be impossible for you to decrypt, even though you wrote it and encrypted it! That is cool. Read the Why Public-Key Encryption is Cool section below for more about why public-key encryption is cool.

Specifies recipients of the message. You must already have imported the public keys of the recipients. You can specify multiple recipients. If you don't specify recipients on the command-line, gpg will prompt you to enter them interactively. These recipients can also be key IDs. filename is the filename of the file you're encrypting. This is not strictly required. If you don't specify a filename, GPG will listen for input, and you can type a message directly or cut and paste it in. This is awkward, though. When you're done pasting, you may need to send your operating system's "end-of-file" character. This is Ctrl-D in most Unixlike systems and Ctrl-Z in Windows-like systems. Warning: (I'm repeating this again.) When gpg encrypts or decrypts a file, it usually leaves the original file intact!. You must remember to delete the original file yourself, securely if possible. See the warning above for more details on how to do this.

GPG is not just for e-mail! You may want to use it to protect your sensitive files also. Encrypting your files is just about like encrypting an e-mail. The simplest command line is:

gpg --encrypt filename

This will prompt you for the recipients (which should include your own e-mail address so you can decrypt it!)

A more complete command-line might look like:

gpg --encrypt --sign -r your@email.com filename

Some interesting things to note and optional arguments:

--encrypt tells gpg to encrypt the message using public-key encryption. (See the Symmetric Encryption/Decryption section below for alternate ways to encrypt a file with a simple password and no public keys.)

tells gpg to encrypt the message using public-key encryption. (See the Symmetric Encryption/Decryption section below for alternate ways to encrypt a file with a simple password and no public keys.) --sign adds a digital signature that lets you guarantee that the message was generated by you and was not corrupted nor modified in transmission. This is theoretically optional, but very important. Think about it: how do you know that someone didn't replace your encrypted file with a different one? By digitally signing the message, you can get a strong guarantee that you're the one who encrypted the message and that it hasn't been tampered with or corrupted. See Signing Messages section below for more on digital signatures.

adds a digital signature that lets you guarantee that the message was generated by you and was not corrupted nor modified in transmission. This is theoretically optional, but very important. --armor (optional, probably unnecessary) wraps your output in plaintext "ASCII armor". "ASCII armor" is just a way of turning raw binary data (which will probably get corrupted if you try to send it through most e-mail programs) into a format using only limited ASCII characters, line-wrapped, with appropriate headers, and suitable for e-mailing. This is necessary if you're pasting this into the body of an e-mail, or usenet posting, or forum posting, etc. Note that this will increase the size of your message on disk.

(optional, probably unnecessary) wraps your output in plaintext "ASCII armor". "ASCII armor" is just a way of turning raw binary data (which will probably get corrupted if you try to send it through most e-mail programs) into a format using only limited ASCII characters, line-wrapped, with appropriate headers, and suitable for e-mailing. This is necessary if you're pasting this into the body of an e-mail, or usenet posting, or forum posting, etc. Note that this will increase the size of your message on disk. --output filename (optional) specify the output file.

(optional) specify the output file. -r recipient Specifies recipients of the message. Can also be written --recipient . You must already have imported the public keys of the recipients. You can specify multiple recipients with multiple -r arguments. If you don't specify recipients on the command-line, gpg will prompt you to enter them interactively. These recipients can also be key IDs. Warning! This is important and interesting! Note that in the example above, your email address is specified as one of the recipients. If you do not explicitly add your own address to the list of recipients, you will not be able to decrypt the file! That is interesting and important and awesome. You may want to create a file for another person that you cannot ever possibly be compelled to decrypt! It will be impossible for you to decrypt, even though you wrote it and encrypted it! That is cool. Read the Why Public-Key Encryption is Cool section below for more about why public-key encryption is cool.

Specifies recipients of the message. Can also be written . You must already have imported the public keys of the recipients. You can specify multiple recipients with multiple arguments. If you don't specify recipients on the command-line, gpg will prompt you to enter them interactively. These recipients can also be key IDs. filename is the filename of the file you're encrypting. This is not strictly required. If you don't specify a filename, GPG will listen for input, and you can type a message directly or cut and paste it in. This is awkward, though. When you're done pasting, you may need to send your operating system's "end-of-file" character. This is Ctrl-D in most Unixlike systems and Ctrl-Z in Windows-like systems. Warning: (I'm repeating this again.) When gpg encrypts or decrypts a file, it usually leaves the original file intact!. You must remember to delete the original file yourself, securely if possible. See the warning above for more details on how to do this.

What do you do if you want to send an encrypted file attachment in an e-mail?

There is a standard called PGP/MIME that try to standardize the handling of encrypted attchments. You cannot be sure that your recipient's e-mail client will be able to handle them, so I strongly recommend never using them. Enigmail doesn't even handle its own attachments that it creates well.

Examples of situations that will cause PGP/MIME or S/MIME attachments to fail or be lost:

Most web-based email services.

Most phone- and tablet-based email software.

List servers or remailers that strip attachments.

List servers that just don't handle all attachments perfectly.

Corporate firewalls that remove attachments.

Overeager malware scanners.

Simple, secure e-mail clients that can only display plaintext.

Not-yet-ready-for-attachments e-mail tools like Enigmail itself.

Mail servers that create non-standards-compliant attachments like Microsoft Exchange. (Enigmail warns you about broken attachments from Exchange and gives you a button to try and fix them. It works for some simple messages with single attachments, and destroys others.)

I strongly recommend always sending encrypted messages or encrypted attachments as ASCII-armored OpenPGP blocks directly in the body of an e-mail. This will ensure that any e-mail program will still be able to handle them.

You can hand-encrypt any attachments using:

gpg --armor --encrypt --sign -r your@email.com -r recipient@email.com filename

as outlined in the Encrypting Files section above. Then just paste the results into the body of your e-mail. You can paste in multiple attachments this way, too.

Enigmail is buggy and insecure when sending and receiving encrypted attachments or PGP/MIME. I don't recommend it at the moment. In fact, the bugs are so severe that Enigmail's behavior may allow others to obtain your entire secret key.

Enigmail fails, for instance, to import a public key or other attachments that it attached itself. You can test this by sending encrypted attachments and public keys to yourself.

Enigmail is also insecure in handling PGP/MIME (and possibly S/MIME) attachments because it appears to always automatically and silently decrypt the message for you, even if you have Enigmail configured to not decrypt by default! This is very bad if someone's looking over your shoulder, or detecting emanations from your monitor (e.g TEMPEST) or doing sound-based attacks. You may not even notice that the message was encrypted, and forget to encrypt your reply, or forget to verify the signature, or do something that compromises your security. It turns out that this is a known bug Enigmail Bug #226 which the developers have inexplicably labeled as "Minor." Augh. They are obviously oblivious to the literature. In fact, the creators of the RSA algorithm have explicitly stated in one of the most widely-circulated papers on GPG that this particular bug in Enigmail is what lets them completely steal your private key, using nothing but a microphone near your computer or an electrical connection (e.g. touching your skin or monitoring your computer's electricity usage) while you receive an e-mail!

Even if you fix the problem above, Enigmail is still buggy when handling PGP/MIME messages, as it will try to auto-save your messages as you write them, which can pop up a dialog asking you to choose recipients to encrypt to while you're typing, causing you to randomly select recipients as you type. It's just totally broken and annoying.

For these reasons, I recommend using the manual procedure above, but here are some tips for using Enigmail if you're lazy and don't care if your attachments get lost or are unreadable by your recipient.

The place to turn off PGP/MIME in Thunderbird/Enigmail has been continually changing, but now it's currently hidden under each e-mail account on the (usually) left-hand side of your screen under OpenPGP Security where the option Use PGP/MIME by default should be unchecked. Here's the current screenshot from the Enigmail project showing where PGP/MIME should be turned off for each account.

When sending encrypted e-mails with attachments in Enigmail, you will be presented with a dialog asking how you want files to be attached:

Choose the option "Encrypt/sign each attachment separately and send the message using inline PGP." However, this doesn't even do the right thing. Its results are unfortunately not identical to the recommended "hand-encrypt and paste" technique described above. It currently still adds multiple attachments, which may get stripped out by mail filters or lost in web-based e-mail clients. Enigmail is then often unable to open these attachments reliably. It certainly can't open public keys that it attaches. Really, just don't use Enigmail for attachments right now. Hand-encrypt them as shown in the previous section. It'll simply work better for more people.

In short, all encrypted communications will be accessible to the most people if you always just use ASCII-armored OpenPGP blocks in the body of a plaintext message.

In addition to encryption, gpg allows you to digitally "sign" messages, which has multiple benefits:

It lets you ensure that a message has not been corrupted nor modified in transmission.

It allows someone to verify that you signed it. (To be more precise, to verify that the signer of the message used your secret key, given that they've verified your public key with you, and that your secret key hasn't been compromised.)

You should always sign your encrypted messages. Think about it. Everyone potentially has your public key. That's expected. Anyone can encrypt a message to you using your public key, and pretend that it's from someone you know. (It's easy to spoof e-mails, but that's another discussion.) Only if you verify (via the digital signature) that the message was signed by someone whose key you have verified, can you trust the communication.

Corollary: You should actively distrust unsigned encrypted communications. If someone's trying to impersonate your friends, they'll just conveniently "forget" to sign their messages.

A signed message gives a mathematically very strong certainty that the message was signed by you.

In your e-mail client, always choose to sign and encrypt a message. Below are some ways to sign messages manually.

By default, Enigmail does not automatically sign encrypted e-mails. This is a bad choice, in my opinion (stated in the section above.)

You can, however, make Enigmail automatically sign all encrypted mails. The setting is very hard to find, though. You need to do the following:

The first thing you want to do in Enigmail is to make all of its settings visible. If you haven't done so already, you can do this from the menu items Enigmail | Preferences | Display Expert Settings . The basic settings are inadequate.

. The basic settings are inadequate. Start to compose a new e-mail. That is, click the "Write" button.

In the "Write" window, choose the top menubar item Enigmail | Default Composition Options | Signing/Encryption Options .

. Check the Sign encrypted messages by default box.

box. Click OK.

Sometimes you just want to sign an unencrypted message to make it clear that you produced it and that it hasn't been tampered with nor corrupted in transmission. For example:

Sending an important vote.

Important business communications.

Maybe you're mailing a URL that looks suspicious and spammy, and your recipient wants to validate that it's actually from you and not from a spammer or a virus. (Saying "this is really from me" in the e-mail is not good enough!)

Being very certain that the message is not corrupted in transmission.

Allowing recipients to verify that data comes from you and is valid. For example, a school could prove that test scores came from them and were not tampered with. (Institutions should use this more!)

The --clearsign option will wrap the message in an ASCII-armored signature but will not otherwise modify its contents. This allows even the losers who don't use gpg to read the body of the message, but allows gpg users to verify that you wrote it and that the message wasn't changed.

gpg --clearsign filename





-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I vote YES on this important measure. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: See Alan's GPG guide at https://futureboy.us/pgp.html iQIcBAEBCAAGBQJT3MFeAAoJEF8rR1bthz0jslMP/RMRODVKLmLwZ3sMR62COGc/ 0yQSh3c37qkkVjD0RvgdziHuCSSYelhNl7UMQofpdLonnJgPW3svlftE3Gn11JLp ZYv2iMwCzwyM2eLYpSQoJBNnGZzQDGnZRBkFOwdkkohUSBjhPjiszYw3KwnpsuxG I+m81IMJATR0wOylLumVdjbvS1/f9bOzBRvhgu2HS54lfPnl162RRZpycrrb5IOi 07QWIlUGVUdAxFUq4Jlm99KB17lQhri3zm6m7O5k0faD3IKFRTQGKseq7j88pRs6 j85v/cc35CHW9+66jcz7Y3UtOIj3gqDQd/Wj05YP01QSwSCuuVAezvXngljF8fLP OKQhFpLoLnWvDPgX3nKwGbX52qZwLGN0bZduhOmMPYwKAEFAYDOOW7q+i/dyz5xT od54j32QiNkSqDCVkvOT6dKiCdCa8GvtwwXPKa9X7+VZB2xYeJorJiaIesD7wyVN CQDx11uMGMkpZ/BmCIA5mDIkDnUTIxHxNFpn2kS6nHJqmJ/LleTpAKLhPWuY1U28 YVraBzmAZ/Wj2Frq0utPi4cFf5r3x9jXIzie4fYrUjMKCN+CNfLL15Py/z9OY1ux vvYdMiLAzL1Ujvjpyw7sCdc2KnbXaM9jmbBGjmVCMX/wGcGKT6cIxYnkR4NOW62L jaBgelaHIL5kZ+E/kpS6 =wh+e -----END PGP SIGNATURE-----

People who have verified your public key can verify messages that you've signed by passing the output back into gpg:

gpg --verify vote.txt.asc



gpg: Signature made Sat 02 Aug 2014 04:45:50 AM MDT using RSA key ID ED873D23

gpg: Good signature from "Alan Eliasen <eliasen@mindspring.com>"

If they haven't verified and signed your public key, then they will be warned that the key is untrusted. This means that all that they can tell for certain is that the message wasn't corrupted in transmission, but it really could have been written by anyone! Beware "Untrusted good signature!" It means that the signature is by someone whose fingerprint you haven't verified.

Sometimes you want to sign a file, but without modifying it like the --clearsign option above does, because people would need to edit the file or use gpg to get at the contents.

Say, you're sending an executable file to someone. You don't want to tamper with the executable file, but executable files are scary and potentially very dangerous. So how can you guarantee to the recipient that nobody has tampered with the file and that it actually came from you? By creating a "detached signature" which is a separate file that contains a signature for the specified file. This is achieved through the --detach-sign command:

gpg --detach-sign filename

Then you ship the signature file along with the original file. The recipient can verify that you signed the file and that it has not been modified with the --verify command:

gpg --verify filename.sig



gpg: Signature made Sat 02 Aug 2014 04:45:50 AM MDT using RSA key ID ED873D23

gpg: Good signature from "Alan Eliasen <eliasen@mindspring.com>"

Let's say you found out that a huge company (we'll call them Mapple) wrote a really crappy incompetent insecure website that leaked a lot of their customers' information that anyone could access trivially by adding 1 to a number.

Now, you're not sure if the company is awesome and honest and will pay you a handsome bug bounty for pointing out their incompetent security hole and helping them protect their customers' information, or if they are psychotic morons who will claim post-facto that your access of information they intentionally published on a public webserver without any access control was "unauthorized" and have you charged under the insanely incompetently-written and outdated Computer Fraud and Abuse Act (CFAA).

So, how do you report this anonymously? Well, one very strong way would be to generate a new keypair without your name on it, publish that public key, and sign all your messages with the corresponding secret key. This lets you do a few things:

You can prove that all subsequent messages signed with the same key are from the same person, even if you jump to different e-mail addresses or communication channels.

If they decide to be honest and offer you a bounty for your services to them and their customers, you can prove in the future that you're the person in possession of the corresponding secret key that signed the messages, for example, by decrypting something sent to you encrypted with your public key. Nobody else would be able to falsely claim that they're the submitter without verifying that they have the corresponding secret key.

If they are evil about it, you can remain anonymous to them. If you want to prove to others that you made the disclosure, you can, by signing a message with the same secret key or decrypting information sent to you that was encrypted with your public key (by using your secret key.)

(This is a mathematically super-strong version of the old trick of ripping a dollar bill in half, and sending half of it to someone. If they want to verify your identity, only you will have the other half of the bill. A dollar bill, with distinctive tearing pattern and matching serial numbers, is hard to forge.)

People are constantly updating their keys for various reasons:

Keys get compromised or lost and they are revoked.

Keys are signed by more people, building a Web of Trust.

Users change the encryption algorithms they prefer. (See the Using Stronger Algorithms section for more about this.)

Updates to keys can be published to public key servers, including new signatures. You can periodically update your keys by using

gpg --refresh-keys

This lets you ensure that the keys you're using haven't been revoked. You might even find that more people have signed your public key. (And they better have validated your key fingerprint and your identity using the verification procedure outlined above, or they can't be trusted to sign keys properly and you should assign them a low trust rating!)

Note that other people can sign your public key and upload the signed key to a public webserver! So you might even find that your own key has been updated!

Enigmail can update all of the keys in your keyring from a public key server. The way to trigger this is from the menu items: Enigmail | Key Management | Keyserver | Refresh all Public Keys . Again, I might suggest that pgp.mit.edu has been a reliable keyserver for me.

You can get a list of the keys on your keyring and their corresponding key IDs with:

gpg --list-keys

or, equivalently, --list-keys can be abbreviated as -k :

gpg -k

If you enter part of the name or e-mail address or key ID as the last argument on the command-line, then only keys that match that pattern will be listed.

gpg -k Alan

You can list secret keys using the uppercase -K

gpg -K

Now that you've updated keys from a keyserver, you might want to see who has signed your key. After all, anyone can sign any key and re-upload that key to a key server. You can see the signatures with the --list-sigs command to gpg:

gpg --list-sigs your@email.address

In Enigmail, you can see the signatures for a key by going to Enigmail | Key Management , searching for a key, right-clicking on that key, and then choosing View Signatures .

Or you can browse your key on a public keyserver, like pgp.mit.edu. This is advantageous because if you haven't imported someone's key yet, they will just show up as a key ID number.

Again, if someone signed your key without validating the fingerprint with you, they are actively damaging the web of trust. You should import their public key just so you can tell your software to actively distrust it as outlined in the Signing a Key section.

(After I published this document, an out-of-control signer whom I've never met signed my key and published the changes to a public website. I had to download his public key so I could tell gpg to actively distrust his signatures!)

In the examples above, I stress the importance of verifying people's public keys with them. But sometimes you can't do that directly. So how can you verify someone else's public key?

Let's say I want to talk to Bob. I've downloaded a public key with his name from a keyserver, but I can't be sure that key belongs to him. I could maybe call him on the phone and verify his key that way, but I don't know his voice, and I don't have his phone number. Or maybe he's even under duress.

Luckily, my friend Alice has signed his public key. I trust Alice to have verified his key properly. I have validated and trusted Alice's public key personally. Thus I have a good reason to believe that Bob's key really belongs to him.

This is why it's important to validate other people's keys very carefully and to build a web of trust--so you can communicate with people whose keys you can't personally verify.

See the Signing a Key section above to see how to sign someone else's key and upload it to a keyserver.

Conversely, you may not want to publicly sign the keys of people you communicate with. You may not want others to know who you communicate with. You may have more than one keypair, and use them selectively for communications with a single person once they've demonstrated strong cryptographic practices.

This is serious business. An example from Syria shows how people die when others don't protect their communications.

If you don't want anyone to be able to analyze who you're talking to, even by traffic analysis of key IDs, you can specify hidden recipients in your messages.

By using encryption improperly, you can make your encrypted communications easier to break. Some of the tips here are speculative and may not apply to all cryptographic algorithms, but many cryptographic algorithms are subject to common types of attacks. These tips will help mitigate those potential weaknesses if algorithms are found to be vulnerable to these types of attacks.

TODO: Improve ALL THE THINGS. Send me more examples of good and bad cryptographic practice, and ciphers that have been broken by poor cryptographic practice.

Don't be predictable. This is the way that much crypto has historically been broken--by knowing words or phrases that are likely to occur in the message. This is known as a "known-plaintext" attack. For example, the WWII German Enigma machine codes were partially broken because people would end with expected phrases like "Heil Hitler!" or from spelling out numbers. (Looking for the number "eins" , (1), the most common number, was a useful tactic in breaking Enigma.) You think this is academic and known-plaintext attacks can't happen? Well, take a look at this recent break on the widely-used RC4 cipher. (It's used in SSL/TLS and in WEP/WPA in wi-fi.) It was found that if you knew a small amount of plaintext, you could recover the rest of the message (given a fairly large amount of encrypted communications, to be sure.) With as little as 6 bytes of plaintext, and a large number of communications, the rest of the message could be decrypted with high probability. (The more bytes are known, the easier it is to break.) Also, keep in mind that breaks in cryptographic algorithms only break them further.

This is the way that much crypto has historically been broken--by knowing words or phrases that are likely to occur in the message. This is known as a "known-plaintext" attack. For example, the WWII German Enigma machine codes were partially broken because people would end with expected phrases like or from spelling out numbers. (Looking for the number , (1), the most common number, was a useful tactic in breaking Enigma.) Don't be polite. As a corollary of the above, don't start and end your message with predictable phrases or pleasantries.

As a corollary of the above, don't start and end your message with predictable phrases or pleasantries. Don't send HTML-formatted encrypted emails. There's a large amount of predictable boilerplate in HTML.

There's a large amount of predictable boilerplate in HTML. No signatures! As a corollary of the above, when sending encrypted messages, don't include your usual .sig file with your name, e-mail address, phone number, password, website, company policy, etc. This doesn't mean "no cryptographic signatures!" You still want cryptographically strong signatures like the kind you get with --sign . Smart e-mail add-ons like Thunderbird with Enigmail can suppress your signature when using encryption. Or you should encrypt just the meat of your email (and not the signature) if you need that silly signature.

As a corollary of the above, when sending encrypted messages, don't include your usual .sig file with your name, e-mail address, phone number, password, website, company policy, etc. Don't quote previously-encrypted text. When replying to an encrypted message, don't quote the original text. Again, having large stretches of expected text has been the downfall of many cryptographic algorithms.

When replying to an encrypted message, don't quote the original text. Again, having large stretches of expected text has been the downfall of many cryptographic algorithms. Don't encrypt the same message multiple times. Some codes have weaknesses that if the same plaintext message is encoded several times (say, to several different people, or to the same person multiple times,) then more information can be derived about the contents or the key. If someone isn't able to read your encrypted message, don't send it again. After all, they're not following good cryptographic practice if they can't read it, and you should limit encrypted communications with them. Or, if you must send it again, alter it as much as possible before encrypting and sending it again. If encrypting the same message to multiple people, encrypt to all of them at once (assuming you want them to know who you're communicating with. They will at least see the key ID numbers.)

Some codes have weaknesses that if the same plaintext message is encoded several times (say, to several different people, or to the same person multiple times,) then more information can be derived about the contents or the key. If someone isn't able to read your encrypted message, don't send it again. After all, they're not following good cryptographic practice if they can't read it, and you should limit encrypted communications with them. Or, if you must send it again, alter it as much as possible before encrypting and sending it again. If encrypting the same message to multiple people, encrypt to all of them at once (assuming you want them to know who you're communicating with. They will at least see the key ID numbers.) Don't have encrypted and unencrypted versions of the same information. As noted above, gpg does not automatically delete the plaintext version of a file when you encrypt it! Read that section on securely deleting files if possible.

As noted above, gpg does not automatically delete the plaintext version of a file when you encrypt it! Read that section on securely deleting files if possible. Garbage is good. One of the hard problems in cryptography is identifying when a message has been successfully decrypted. How do you know? When it all comes out as mostly alphanumeric characters? When its word frequency looks like English? Make it hard for the bad guys. Jam in a bunch of random bytes into your message if you can. It'll make it harder to even detect the fact that the message was decrypted properly. Send your friends encrypted random bytes every day just for fun because screw the surveillance state we live in! If everyone did this, it would be utterly prohibitive to try and decrypt all of the random data flying around.

One of the hard problems in cryptography is identifying when a message has been successfully decrypted. How do you know? When it all comes out as mostly alphanumeric characters? When its word frequency looks like English? Make it hard for the bad guys. Jam in a bunch of random bytes into your message if you can. It'll make it harder to even detect the fact that the message was decrypted properly. Send your friends encrypted random bytes every day just for fun because screw the surveillance state we live in! If everyone did this, it would be utterly prohibitive to try and decrypt all of the random data flying around. If it's received encrypted, store it encrypted. Some e-mailer plugins will offer to decrypt messages and store the decrypted versions in your mail folder. Don't do this. It allows someone to mount a chosen-plaintext attack on you just by sending you an encrypted message. Yes, it will make your messages impossible to search for content. But that's good.

Some e-mailer plugins will offer to decrypt messages and store the decrypted versions in your mail folder. Don't do this. It allows someone to mount a chosen-plaintext attack on you just by sending you an encrypted message. Yes, it will make your messages impossible to search for content. But that's good. Don't encrypt stuff from untrusted sources. There is a class of attacks called a "chosen-plaintext" attack. Some encryption algorithms can be weakened or completely defeated if the attacker is allowed to choose the text that you are going to encrypt with your key. Always refuse to encrypt something specific that a third party asks you to encrypt, especially if it's lengthy.

There is a class of attacks called a "chosen-plaintext" attack. Some encryption algorithms can be weakened or completely defeated if the attacker is allowed to choose the text that you are going to encrypt with your key. Always refuse to encrypt something specific that a third party asks you to encrypt, especially if it's lengthy. Hide your encryption entirely! There's a branch of cryptography called "steganography" which hides secret communications in innocuous places that are very hard to detect. For example, by slightly modifying the least-significant-bits in the pixels of a JPEG image, you can hide encrypted messages in pictures of kittens! Or, you can hide them by adding slight, undetectable noise to audio files. It becomes very difficult and expensive to determine that a particular image even contains steganographic content. That's the best way to hide your information, especially as the NSA has decided that using cryptography to protect your privacy is probable cause that you're a terrorist, and they allow themselves to keep encrypted content "for as long as necessary" to break it. I have built some web-based Steganographic Tools that let you experiment with steganography from your browser! If you want to be more secure, of course, you'll run the steganography tools on your own machine. That page tells you more about the steghide program. (Hint: in Fedora it's dnf install steghide )

Sometimes you don't want to use public key encryption. You can use old-fashioned "symmetrical" encryption where everyone shares a common password. In gpg, you do this by using --symmetric instead of --encrypt :

gpg --symmetric filename

gpg will then prompt you for a password.

Warning: (I'm repeating this again.) When gpg encrypts or decrypts a file, it usually leaves the original file intact!. You must remember to delete the original file yourself, securely if possible. See the warning above for more details on how to do this.

If you want to paste the encrypted file into an e-mail or something, you can use the --armor option.

The encrypted file can be decrypted by passing it back into gpg:

gpg filename.gpg

If you want to force the encryption algorithm used (the default is maybe CAST5), you can add the --cipher-algo name command-line option, for example --cipher-algo AES256 . The list of available encryption algorithms in your version of gpg can be found by running the gpg --version command.

Symmetric encryption has its problems. It doesn't let you simultaneously sign the message to indicate that it hasn't been tampered with or replaced with another file that someone else generated! (You can, however, sign it manually later using the techniques in the Signing Messages section, but it's theoretically possible that an attacker can replace that file in the brief time between when you encrypted it and when you signed it.)

If you use symmetric encryption, you also need to solve the age-old problem "how do I communicate the password securely?" Read on for the solution to that problem.

In short, public-key encryption solves the age-old problem "how do I communicate a password securely?" You no longer have to. You just need the other person's public key, which can be published to the world.

You can also encrypt a message that you can not decrypt! This may sound silly, but you may want to write something to someone that you cannot ever possibly be compelled to decrypt! It will be impossible for you to decrypt, even though you wrote it and encrypted it and even if you have the file in your possession and even if you have all your secret keys and you know all of your own passwords and have them written down! That is cool. (You can smile serenely while they're beating you with a rubber hose, knowing that you can't endanger the lives of your sources, nor give up your rights, even if you felt like that might be entertaining for a change.) You can see how to do this physically in the Encrypting Messages You Can't Decrypt section. This actually has many important and practical uses: If you're a reporter (or other human) traveling abroad, you can encrypt materials using public-key encryption, to someone else's key, but without encrypting to your own public key. ( Warning : some tools will encrypt to yourself by default. Read on.) It's easy to create a message that you can never possibly decrypt yourself, and cannot possibly be compelled to do so! Ever! You could encrypt them, say, using only the public key belonging to your newspaper's editor or lawyer. (And if your newspaper's editor and lawyer don't have public keys, have them contact me and I will help them. They need to do this. Now. Before they kill people.) You can be detained and couldn't ever be compelled to give up the password, as you never had it! You don't have to be in Syria (although journalists who don't use encryption kill people; read the link) or North Korea for this type of Orwellian police state coercion to happen. Even the otherwise-civilized United Kingdom has vile horrendous laws that can jail you without trial if you don't give up passwords. Edward Snowden has also stated that he has in his possession encrypted documents that he cannot possibly be compelled to decrypt, even under torture. (But maybe other trusted people potentially can decrypt them.) Public-key encryption is probably what he was hinting at. Nice work. Also see the Hidden Recipients section of this document to see how to hide the people to whom you've encrypted. That may be very important for journalists or dissidents or ordinary people who want to assert their rights to free association. It also allows you to post encrypted messages to public forums without anyone knowing who you're talking to. Also see my Steganography tools which let you hide the fact that any hidden communications are happening at all! You can hide secret communications in pictures of kitties. Let's say you have a web server that collects very sensitive user information. You don't trust the security of the web server, but you have to keep the information on that web server for a while before you move it elsewhere. Say, to a computer completely disconnected from the outside world. With public key encryption, you can encrypt information with a public key stored on the web server. However, the secret key would not ever be kept on that server! Even if someone breaks your web server wide open and has total access to every single file, and every single algorithm, and the public key, they will still never, ever be able to decrypt the private information on the server because the secret key needed to decrypt it is not on the server at all! Miracles! If you rent space in a server farm, this can prevent malicious administrators at the hosting company (who probably hold superuser access on your machine, and can read all your files) from being able to do anything with your data. And it keeps your web server administrator or database administrator from seeing that sensitive data, even if they have complete access to every file on the computer. A real-world example of storing sensitive communications: The Federal Communication Commission's (FCC's) Lifeline subsidized cell-phone program for low-income people leaked highly sensitive customer information for over 170,000 people, including Social Security numbers, birth dates, home addresses, and sensitive details about family finances from a public web server. Think about how you could use public-key encryption to collect and encrypt this data securely on the webserver, and only be able to decrypt it somewhere else much safer. Again, see how to do this in the Encrypting Messages You Can't Decrypt section.

It's easy to revoke access to one member of a group. If everyone in a group shared a password, it would be very difficult to remove one person's access. A different password might have to be created, and that password would have to be communicated securely to all other members of a group. Public-key encryption means that you can control exactly who is allowed to read future communications. If you don't want someone to read it, just stop encrypting to that person's public key. Even if they can still see your encrypted communications (like on a public mailing list,) they will no longer be able to decrypt it.

Here are a collection of fun tips and tricks and puzzles for using GPG. Please send me more.

This section is optional but important.

By default, gpg uses weaker encryption algorithms than it could (especially if you generated your keys using an older version of the software.) This is to ensure compatibility with older versions.

Part of your public key specifies your preferences for the encryption algorithms that you want people to use when communicating with you. These are, by default, somewhat weak. You can view and modify these preferences to make your communications stronger.

To view all of the algorithms supported by your version of gpg, type:

gpg --version

or maybe

gpg2 --version

This will give an output that looks something like this:

gpg (GnuPG) 1.4.14

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.



Home: ~/.gnupg

Supported algorithms:

Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA

Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224

Compression: Uncompressed, ZIP, ZLIB, BZIP2



You can modify your public key's cipher preferences by interactively editing your key:

gpg --interactive --edit-key your@email.address

This will display a list of matching public keys. You may need to enter the number of your key in that list so you can edit it.

Hint: You can always type help at the gpg> prompt to see all available commands. There's lots of fun stuff hidden in here.

Next, show your current algorithm preferences by typing at the gpg> prompt:

showpref

Which produces something like:

Cipher: AES, TWOFISH, CAST5, BLOWFISH, 3DES

Digest: RIPEMD160, SHA1

Compression: ZLIB, ZIP, Uncompressed

Features: Keyserver no-modify



The protocols listed first will be used first. Note that the preferences listed are probably not as strong as your copy of GPG supports, and often the stronger algorithms are not requested at all! You can change these preferences by calling the setpref command. I recommend something like:

setpref AES256 CAMELLIA256 AES192 CAMELLIA192 AES CAMELLIA128 TWOFISH CAST5 3DES SHA512 SHA384 SHA256 SHA224 SHA1 RIPEMD160 ZLIB BZIP2 ZIP Uncompressed

You may want to add other algorithms that your software supports, or you may want to disallow algorithms that you think are too weak.

You can see that it worked by typing:

showpref

Check this very carefully. If everything worked right, you can save , (in some versions there's just quit ) and you will be prompted if you want to save your changes:

save

Note: You should then re-upload your key to a public key server and send it to the people you communicate with. Until people have imported your new key, they will still be using the old algorithms when encrypting to your public key!

Warning: Note that the OpenGPG Key Management document states:

"When setting preferences, you should list the algorithms in the order which you'd like to see them used by someone else when encrypting a message to your key. If you don't include 3DES, it will be automatically added at the end. Note that there are many factors that go into choosing an algorithm (for example, your key may not be the only recipient), and so the remote OpenPGP application being used to send to you may or may not follow your exact chosen order for a given message. It will, however, only choose an algorithm that is present on the preference list of every recipient key."

Warning: This means that if you're encrypting to several people at the same time, GPG will only use the strongest algorithm that the weakest person uses! Beware when encrypting to multiple recipients; one person can (accidentally or intentionally) weaken the encryption algorithms used by the whole group!

Corollary: Don't be the weakest link in your group! If you are still using weak encryption preferences, you are bringing down the security of the entire group you're communicating with. You are not weakening the security of your own communications, but those of everyone you communicate with!

Corollary: Inform the weakest links in your group that they could be using stronger ciphers. Point them to this section (Stronger Algorithms) of the documentation and help them fix it. Get their updated public key and help them test their preferences using showpref as described above.

Corollary: Update your keys often, so if someone on your keyring chooses to use stronger algorithms, you respect their preferences.

Corollary: If you update the keys of people you're sending group messages to, make sure they (or someone else) hasn't (intentionally or accidentally) weakened their algorithm choices. Yes, this is painful and hard, but it's one way that an attacker might infiltrate your group and degrade your cryptographic algorithms. TODO: Write some script that determines who is the weakest link in a group?

Technical Note: You may be wondering how these encryption algorithms like AES are even relevant to you if you chose to, say, generate an RSA or DSA public key. RSA and DSA are public-key encryption algorithms, after all, and AES is a symmetric encryption algorithm! I thought we were using public-key encryption here! The answer is that decrypting an encrypted communication in GPG is done in two stages, with both public-key and symmetric algorithms being used: Public-key decryption: GPG uses your secret encryption key to decrypt a session-only secret key that was encrypted with your public (RSA or DSA) key. Symmetric decryption: GPG uses this session-only secret key to decrypt the "body" of the message which was encrypted using a symmetric algorithm like AES or AES-256. Your public key (RSA or DSA) is only used for the first step. The actual body of the message is encrypted with a (faster) symmetric encryption algorithm, so it's important to make sure that you're using strong algorithms for both phases.

You can use the -vv command-line option to gpg to give verbose output about what algorithms are actually being used. (Note that if you're pasting in decrypted text, after you're done pasting, you may need to send your operating system's "end-of-file" character. This is Ctrl-D in most Unixlike systems and Ctrl-Z in Windows-like systems.)

gpg --list-packets can list the packets of any GPG file and give details on what's contained therein. This tends to output not-very-meaningful numeric data about which encryption algorithms were used, but you can decode these by looking at the specification for the Open PGP standard, RFC 4880, specifically Section 9.

You can also use programs like pgpdump to see what's included in a PGP message.

Also see the Automating GPG section below to see more options for dumping detailed information about what GPG is doing.

You can encrypt documents that require several people must cooperate to decrypt, by encrypting with multiple passes, specifying a different recipient each time. They will need to decrypt in the reverse order that you encrypted.

TODO: Make an example, preferably one that writes no intermediate files (e.g. output to stdout using --output - ) and doesn't make you enter passwords multiple times. Naïve versions make gpg complain with weird "broken pipe" errors and races in password entry.

Sometimes you want to hide the recipients of your message from any snoopers. Normally, the key IDs of the recipients are part of the message. However, you can hide these by specifying --hidden-recipient recipient for each recipient you wish to remain hidden (instead of using the -r or --recipient flag to specify recipients.) The decrypting program will have to try all available secret keys to try and decrypt the message. (Hidden recipients' key IDs show up as all zeroes in the encrypted message.)

The --throw-keyids command-line option is essentially the same as using --hidden-recipient for all recipients.

There are other interesting options for hiding recipients in the GPG key-related options documentation.

The section Why Public-Key Encryption is Cool explains reasons that you might want to create an encrypted message that you can never be compelled to decrypt. This section discusses how that is performed.

When you encrypt a message in GPG from the command