BRS: PKI Cryptosystems for SA/Ms: A Tutorial

[Chris Hillman]

[size=+2]I. Getting Started[/size]

[size=+2]About this Tutorial[/size]

This tutorial is intended to help Physics Forums SA/Ms use GnuPG (Gnu Privacy Guard, GPG for short) to

• exchange public keys and build help build a "web of trust" among sci forum/blog administrators
• sign important plaintext posts (usually in SA or Mentor forum) for purposes of authentication
• exchange encrypted communcations with each other, either via email or via PM

GPG is a widely used and trusted implementation of personal public-key infrastructure (PKI) cryptography, which is freely available in versions which should work on any personal computer or laptop using any of the more popular operating systems (unix, linux, Mac OS, Windows). GPG is an open source near-equivalent of PGP (Pretty Good Privacy), a widely used commercial implementation of PKI. Users of GPG and PGP should be able to communicate easily with each other, modulo some quibbles which SA/Ms are unlikely to encounter unless they experiment with some of the fancier features of GPG.

As some of you already know, PKI has historically been troubled by some highly contentious issues of public policy. These issues are difficult, complex, highly fluid, and by no means unworthy of our consideration, but to avoid distraction, I propose to focus in this thread on the problem of explaining how to use GPG in practice. It would be impossible to avoid any suggestion of implicit (and possibly politically controversial) stances on public policy issues, but I'll try my best.

[size=+2]Secure Cryptography is Normative and Good[/size]

PKI encryption of emails and PMs is analogous to putting a personal letter or personal check in a sealed envelope. (One of Ben Franklin's revolutionary ideas was that the U.S. Mail should be inviolate, quite unlike the mails in monarchial Europe c. 1774.) Encryption of a file (or your hard drive) is analogous to locking your private diary in a drawer. The postman could not deliver a letter, or he could open the envelope and misdirect your check, and your wife could break the lock and read your diary--- but we trust them not to do that. You trust your wife because you know her (you hope). You trust the postman because historically, AFAIK, the U.S. Postal Service has not become embroiled in known abuses affecting large numbers of ordinary Americans, unlike... some other U.S. governmental institutions.

In contrast, sending plaintext emails or PMs, or archiving email in a web server, or archiving PMs in your PM Inbox, is analogous to posting a personal letter on a bulletin board in the local laundromat, where it remains visible for years, and where anyone who happens by can read it at any time, without your knowledge, and quite possibly without the knowledge of anyone else but the snoop.

When I frame the use of personal PKI this way, I hope that most SA/Ms will see that on occasion they will have a legitimate need to use PKI cryptosystems, for example if they discover a security flaw in VB, or need to discuss in private a sensitive issue. Using PKI is not wrong!

Not only is using crypto not wrong, most people are almost certainly-- but quite possibly without being aware of it--- using crytographic software already. If you do your banking on-line, you probably connect to your bank's servers using https, which "tunnels" your connection through SSL (Secure Socket Layers), which in lay terms provides fairly strong cryptographic protection for your connection. (SSL is not the same as GPG, and there are many other ways besides SSL in which strong cryptography is used routinely for all kinds of web transactions.)

Tragically, many people have been given the impression--- apparently as a consequence of the infamous "crypto wars" between advocates of strong cryptography for citizens and the U.S. secret police in the 1990s--- that using PKI is illegal everywhere but the US. Which is not true. But the situation is fluid and current information about crypto laws in various nations is hard to come by. My advice (possibly very bad advice) is to ask around locally, but if all you hear are unsubstantiated rumors, I urge you to assume that crypto is legal in your locality--- unless and until your local government representative can provide a citation to the exact section of your local/provincial/national legal codes which says otherwise!. Just the same way you would assume that eating and breathing are legal in your locality unless your local government can cite the exact section of the applicable legal codes which says otherwise--- secure crypto is really that vital for virtually every aspect of on-line existence.

Just one quotation, if I may, from someone who knew a lot about betrayal and about speaking up for the disenfranchised, because I seem to be writing for two audiences, one legitimate, and one convinced that trying to teach citizens how to use strong cryptography is literally traitorous:

A time comes when silence is betrayal.

[size=+2]Secure Cryptography is Hard[/size]

Unfortunately, secure cryptography is notoriously hard to achieve, even if you are not doing any coding yourself. PKI software has the reputation of being challenging for newbies to use. And some vitally important points about using PKI properly are hard for newbies to grasp. Heck, there are points which are hard for me to grasp, and I've been worrying about this stuff for years.

One "metaprecept" seems noteworthy: cryptography is the kind of field which by its very nature is full of mutually contradictory maxims, all having more than a grain of truth. Trust no-one. Never do-it-yourself. You yourself pose the greatest security risk to your own cryptosystem. All crytosystems are broken eventually--- usually at the worst possible moment. And so on.

One of the scariest facts of life about crytography is that the one thing you can be sure of is that there are considerations you have never even dreamt of which could vitiate all your efforts to provide a safe way to transmit your private letters, to store your private diary, &c. Does that mean that one should just give up and not even try to use strong cryptography? Of course not. It just means that you should try to be prepared for possible compromises, insofar as it is possible to prepare for unknown future catastrophes.

One particularly scary fact about current PKI is that it depends upon the factorization of primes remaining hard. Several other "hard" problems which have been designed into the heart of alternative PKI systems turned out not to be so hard after all. If there were ever a huge advance in prime factorization, GPG could become insecure overnight. Then the world would turn, I guess, to algorithms based upon elliptic curves, unless quantum cryptography has become practical.

One bit of good news: strong cryptography provides an essential component of a robust response to crytographic compromises, and indeed to all kinds of computer security and privacy compromises. Just one more reason why it is so important for the key people in any organization (in this case PF) to have some familiarity with using strong cryptography--- before an emergency situation arises.

[size=+2]Do I Really Need to Read This Tutorial?[/size]

I think so, but for those who find it tough sledding on first reading, there are some shortcuts which may help.

If your primary interest is in using gpg with gmail, there are now many GUIs (graphical user interfaces) which make using GPG relatively painless for those who are afraid of "the shell" (in Linux-speak; I think Windows users call this "the command line interface"). Some of these are Windows, Mac, or Linux specific; many are available for all popular operating systems and platforms.

If you use Windows, you can find and read Steven Shankland's tutorial of Jan 14, 2010; search

http://news.cnet.com/

for "Want really secure Gmail? Try GPG encryption". Using Gmail is a really, really bad idea unless you routinely use strong encryption. By strong contrast, using Gmail with GPG is probably not a bad idea at all, assuming you don't perform your cryptographic processing "in the cloud"!

[size=+2]Some Important Points to Bear in Mind[/size]

Before you start learning to use GPG, there are some things you should know:

• PKI serves two equally vital but distinct functions
  • authentication: proof that you are who you claim to be, that a post was written by the author named in the byline, etc.
  • privacy: assurance that no-one but the intended recipients of a private communication can read a private written communication (or spoken, if you are using Skype).
• To use PKI properly it is vital that you and your correspondents be related by a "web of trust" (WOT). The idea is this: suppose that A wants to email a cryptogram to X. Suppose that A knows B well enough that B could swear in court that A is who he claims to be. Similarly B knows C well enough... and finally, Y knows Z well enough. Then, assuming trust of strength S is transitive, Z and A can each be confident that the other is who they claim to be. It's a bit difficult to explain briefly why the WOT is so critical--- or in other words, why secure authenticiation is essential for secure privacy--- so for the moment, please take my word for this. The important point here is that at present there is nothing approaching a WOT connecting PF SA/Ms. That can change if we all make a point of attending key-signing parties in our localities, but it will take time to build enough connections. In the mean time, we should start using PKI anyway, and hope for the best.
• Any cryptosystem is only as strong as its weakest component. More generally, any computer implementation of a cryptosystem is only as strong as its most carelessly written code. In particular, if you use a GUI for PKI encryption, and it turns out that there is a weakness in the code of the GUI, your crypto could be compromised.
• Similarly, the WOT is only as trustworthy as its most duplicitous/careless node. Thus, it is important for all SA/Ms to share some reasonable minimum of knowledge about using PKI properly.
• As with any software package, using GPG or PGP involves making tradeoffs between security and convenience; knowing something about the most critical issues can help you to make better choices adapted to the needs of your community (in this case, PF SA/Ms).
• GPG (and PGP) encrypt messages using a conventional "symmetric" block cipher such as Blowfish or CAST5; this means that the message is encrypted and decrypted using the same key, using a publically known algorithm, so the message can be read by anyone who obtains the key. A public-private keypair "trapdoor" type encryption algorithm, such as RSA, is used only to transmit the "one-time key" used to encrypt/decrypt a particular message. This is because trapdoor encryption is less computationally efficient than conventional block ciphers.
• Assuming proper use of PKI, the weakest point of GPG itself is probably the keyring where each user keeps his public-private key pairs, even though these are stored in hashed form rather than plaintext (and checksums are autoverified by GPG). Thus, it is vitally important to keep your key-ring someplace safe. Ideally, you'd keep it off-line, or only encrypt/decrypt on a computer which never connects to the web. That wouldn't be practical for most of us; below I will try to explain what I think is a reasonable compromise.
• Using PKI improperly could be much worse than simply sending sensitive information in plaintext over the InterNet! The reason is that anyone who is able to obtain your keyring can probably (with some effort)
  • read all your past "private" communications,
  • (if you do not learn immediately of the compromise) read all your future "private" communications,
  • plausibly impersonate you.
  GPG provides a way to securely revoke a compromised key, using "revocation certificates" (to be explained below), which must be protected even more strongly than your keyring. You will probably need to access your keyring daily, but hopefuly you will only rarely need to access your file of revocation certificates, so ideally, you really should store these off line in a (say) a floppy diskette in a safety deposit box.
• Examples of inappropriate and dangerous misuses of PKI cryptosystems include (in reverse order of self-destructive idiocy):
  • using telnet or http to contact a remote server where you have installed GPG and where you keep your keyring, because in order to encrypt or decrypt remotely, you will then be transmitting your secret pass phrases in the clear over an insecure connection,
  • using a computer which you do not own to perform personal PKI processing (companies which give out company laptops often install key loggers to check up on how their employees are using "their" laptop),
  • storing a PKI pass phrase in an electronic device, such a PDA, or a "wallet" (software) on your computer, or anywhere in any form in any electronic medium (except possibly a smart card),
  • storing plain text decrypts of sensitive messages in a PDA, smart phone, or on a webmail server not under your physical control,
  • keeping your keyring in an unencrypted area of your hard drive, particularly if you use a laptop,
  • storing plain text decrypts of sensitive messages in an unencrypted area, particularly if you use a laptop,
  • making such elementary cryptographic blunders as using a poor passphrase, leaking information about your pass phrase, (possibly) posting the plaintext of a "test" cryptogram...
• Expanding on the last point, in practice, operator error has historically proven to be the single greatest threat to the security of cryptosystems--- and of "secrets" generally. Recent examples include the rushed British official, apparently late for a meeting, who was photographed outside the residence of the Prime Minister clutching a typescript. Blowing up the photograph revealed a clearly legible image of a top secret briefing on an alleged terrorist plot--- a revelation which led to a panicked series of "premature" arrests of some persons who were being entrapped by the British secret police and who were visibly named in the document. And you wouldn't believe (unless you read the same news stories I have read) the things which people have left in taxis, on trains, in airplanes, or confided to people they just met. Trained people who are supposed to know better.
• To emphasize a critical point: unless you are using a very secure VPN and really know what you are doing and really have very strong reasons to trust the owner/operator of a remote server, you really should not even think about mixing PKI and "cloud computing"; in particular, you should not trust Google and other providers of commercial cloud computing services, at least not for performing personal crytographic processing,
• Contrary to my assessment of only a few months ago, it is probably no longer safe to assume that your hard drive is unlikely to be seized and seriously attacked at some point in the next five or ten years. "All other things being equal", you say? Well yes, but all other things are not equal. As a SA or Mentor, you are not just any PF user. And PF is not just any web forum. Bearing this in mind, there are various security issues associated with risk of your hard drive being stolen or seized and studied in detail. For example, various kinds of "information leakage" can seriously compromise PKI, but the risks can be difficult to estimate or mitigate without considerable technical expertise.
• Making regular backups of your files on your computer is a very good idea. Backing up your keyring and any archive of sensitive emails/PMs involves somewhat tricky issues. Later I might try to explain some practical advice by encrypted comms.
• GPG tries hard to avoid having your operating system carelessly write to disk sensitive information (such as as your passphrase as you typed in in plaintext into your keyboard). The problem is that a sophisticated attacker who steals or scans your laptop can possibly recover your passphrase in plaintext if it was ever written to disk, and this would completely compromise that particular key. GPG uses setuid (ouch!) to lock memory (whereupon root privileges should immediately be dropped) to try to ensure that sensitive information won't be written to disk. But if you use a laptop, you should look into measures you can and should take to ensure that if your laptop goes into a power-saving "sleep mode", you passphrase won't be written to disk.
• These days, sensitive information can often be recovered from RAM by a sufficiently sophisticated attacker who has possession of your computer. And of course a keylogger will completely compromise any keys you have used, because the attacker will learn the passphrase in the clear. TEMPEST technology is said to already be more common than most people realize, and is currently difficult to circumvent. Your CPU, your browser, your router, and other items of equipment you use--- even your printer--- all log much more information than (most likely) you realize. Some software you require may well surreptitiously "call home" with possibly sensitive information about you. Any and all of these phenomena can potentially vitiate some or all of your crytographic protection.
• If you use a laptop and travel by air, the chances that your laptop will be scanned are fairly high. Some travelers have been ordered to provide border control officers with the password to unlock their personal laptop. Since we know that you are not using PKI to abet anything but the legal privacy of a citizen who has a legitimate need to transmit and store some personal information secretly, consider using steganography, so you won't have to try to explain difficult concepts to a policeman who may not be as well educated as we are, or who may not be fluent in a common language--- or who simply doesn't like your looks.

[size=+2]Installing GPG[/size]

If you've read this far, I'm sure you are eager to get started, so let's begin at the beginning, by installing GPG.

If you use Debian Linux or a related distro (good for you!) you can install gpg in a few clicks using the package manager, or more likely a GUI which interfaces with the package manager, like kpackage or synaptic. Note that Debian packages are cryptographically signed (using GPG!) and also have checksums, which should be automatically checked by the package installer prior to installation. This is important because it provides reasonably secure assurance that the source code has not been tampered with before you install it on your computer--- obviously an important consideration when dealing with critical software such as crypto software!

If you use another Linux distro like SUSE or Mandrake or Ubuntu, these have their own package managers and you should ask on appropriate Linux forums for help if problems arise.

In general, if you use a Linux distro with a package manager, it is a very good idea to try to install software using the package manager rather than trying to install from source code. Howver, the option of installing from source code is available as a last resort.

If you use Mac or Windows, I can't help with installation issues, but I know it is possible to install gpg without pain. See

gnupg.org

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms: A Tutorial. II. Key Management

[size=+2]A Bit of Background about Trapdoors and PKI keypairs[/size]

Recall from Part I that GPG (and PGP and other PKI cryptosystem software packages) use a version of the RSA key-exchange protocol, which uses keypairs (public and private) to allow two persons who have never met each other to, in effect, exchange a message key used for a conventional block encipherment of a specific message, in a manner which ensures that this message key is not easily available to adversaries.

The basic idea here is to use a "trapdoor" procedure, which is computationally easy to do if you know the secret key, but computationally hard to undo if you know only the public key. Or so we hope! There's good reason to doubt that it is possible to prove that a procedure thought to be a genuine trapdoor is as safe as we hope it is.

The details of how the RSA algorithm works are fun (especially if you like number theory), but all that matters here is that the algorithm depends upon the software using a really good pseudorandom number generator (aided and abetted by some "genuine entropy") to generate keypairs consisting of a public key and a private key; the first can be shared with the world; the second must be kept an absolute secret (or else the keypair has been irreparrably compromised and must be revoked; more later on that).

Once the message key has been created and transmitted, the plaintext can be encrypted with the message key, using a conventional block cipher algorithm. The recipient uses the same message key to decrypt the ciphertext; hence the term "symmetric" cipher algorithm. (I am oversimplifying for clarity: in fact, GPG combines these conceptually distinct procedures, so that only one message need be transmitted, not two.)

To guard against the possibility that a given block cipher is shown to be vulnerable to some previously unknown but practical attack, GPG allows you some freedom of choice as to which block cipher algorithm you use. (More later on that.)

Thus, the whole point of using PKI is to gain the ability to safely (we hope!) transmit "message keys used once" to encipher/decipher a specific message. And the security of PKI rests upon keeping the secret half of a public-private keypair private. By default, in a Linux system, GPG stores your keyring (and a bunch of other stuff) in a directory called

/home/youruser/.gnupg

Even though the directory is accessable (check!) only by your user (and root), it is really not a good idea at all to keep your keyring in a default location, even though only crytographic hashes of the all important plaintext passphrases which unlock your secret keys are (in theory) stored on disk. Once we get basic encryption running, I can distribute some advice by encrypted communications about some solutions which I have found practical.

[size=+2]The Shell is Your Friend[/size]

I don't plan to discuss crypto GUIs in this tutorial, in part because, as already mentioned, the more software code you utilize for crypto, the greater the chances that some of this software code will open security holes. On all platforms, you can carry out all GPG functions with greater and precision, control, and security by using the shell. I don't know much about using the shell ("line command interface") in Windows or Mac operating systems, but I believe the syntax will be identical to the syntax used in the shells used by Linux users. Certainly this should be true of Mac OS, since this shares a common ancestry with Linux, namely Unix. I plan to suggest a few scripts, which Windows users will probably need to modify as appropriate.

So learn to use the shell on your computer, and learn the basic GPG line commands. Even if you plan to use a GUI eventually, learning the line commands will give you a greater appreciation of the GUI, and will also give you failsafe if security holes are found in your favorite crypto GUI.

For the Linux literate: I will assume your default shell is the bash shell.

[size=+2]Generating Keypairs[/size]

Before you can use GPG to encrypt and decrypt personal messages,

• you must generate your own public-private keypair,
• you must import the public key of at least one correspondent into your keyring,
• this correspondent will need to import your public key into his own keyring.

But for now, you can create two keypairs and pretend that they belong to two people, in order to test your burgeoning crypto skills. Which means that before you even try to encrypt anything using PKI, you will need to confront one of the trickiest and most dangerous aspects of PKI, key management.

Let's first generate a keypair which GPG will store in a "keyring" in some default location. Unless you use strong whole disk encryption, you will later need to figure out some compromise between keeping your keyring safe and making it accessible for personal PKI processing, but there's no need to worry about that now.

The line command you need is

gpg --gen-key

But before you type that in, here's what to expect:

• You'll need to choose a long passphrase which is easy to remember (by you) but hard to guess (by anyone else). Ideally it should not consist entirely of words in a dictionary in any language, or of a literal quotation from any literary work or pop song, and it should not contain obvious alphanumerics such as your birthdate. So you probably will want to think about this for a bit before you even start typing.
• You'll be asked to provide a username and email address. You don't need to use a real email address unless, of course, you want to post your public key to a "keyserver" so that anyone can obtain it and use it to email you an encrypted message. For encrypted PMs and PF, I use a public-private key pair which is not associated with a genuine email address, and I share my public key only via PMs at PF.
• You'll also be asked for an expiration date; I choose one year. This can be easily extended later if you choose.
• You'll also be asked for a key length: you should choose the maximum, currently 4096 bits. Note that to get N bytes worth of keylength security, you need to choose keylength 2N. This is relevant to deciding how large a keyspace you want to force a "brute strength" attacker to search. Choosing the maximum keylength increases the time to encrypt/decrypt, but you should hardly notice the difference for encrypted personal messages.
• You should be ready to provide some "genuine entropy" while GPG is generating a pseudorandom keypair for you. A good way to do that is to have another shell ready to start a meaningless lengthy task which will run in the background and which will access your hard disk, such as grepping the entire disk for all occurrences of the word "the". You can also move your mouse around randomly, and you can open a text file in the other shell and randomly type characters. Actually, you should probably do all of these things for the two minutes or so which your computer will probably need to generate a keypair.

Next, examine some basic "publicizable" information about all key-pairs currently stored in your keyring (currently, presumably, just the one you created moments earlier) using

gpg --list-keys

The output should look something like

pub   1024D/8BD94B16 2010-03-24 [expires: 2011-03-24]
      Key fingerprint = 295B F087 7439 C444 12BF  B542 1A5B 3C60 8BD9 4B16
uid                  Chris Hillman (PF Science Advisor) <byteme@physicsforums.com>
sub   4096g/38525846 2010-03-24 [expires: 2011-03-24]

Here, the fingerprint of the key-pair is the publicizable unique identifier (written in hex as a sequence of ten bytes)

295B F087 7439 C444 12BF  B542 1A5B 3C60 8BD9 4B16

and the last two bytes are the keyid, here 8BD94B16, which also appears after "1024D". GPG is pretty flexible, so for most purposes you could substitute "byteme" for the hex keyid. For example, looking ahead to the time when you have hundreds of keys in your keyring, try

gpg --fingerprint 8BD94B16
gpg --fingerprint byteme

Either of these will show the fingerprint of the unique public key with keyid 8BD94B16. Needless to say, substitute here the username and keyid of the keypair you just generated, or GPG will complain that your keyring has never heard of this particular key!

Next, you should immediately generate a key revocation certificate, which you should store in the most secure place you can possibly find. Ideally, not on your computer, but in an encrypted file on a floppy you keep in a safe deposit box. (Encrypted by some widely used and trusted cryptosystem other than GPG PKI itself, of course. You can use GPG's "symmetric" encryption feature, which is explained below, with a special keyphrase you won't forget.)

gpg --gen-revoke byteme

(again, substitute your own username).

Next, repeat all this with a second keypair (choose a different user name!), so that you can try encrypting and decrypting some messages to yourself (see next part). Now you should see two keypairs in your keyring, and you should be able to request the fingerprint of either one.

[size=+2]Sharing Public Keys[/size]

Next, you need to know how to import a key into a your keyring, i.e. obtain the public part of someone else's key and add it to your keyring, and how to export a key, that is, give to someone else the public part of one of your own keys. There are basically two ways to do that:

• Tell the entire world, by uploading one or more of your public keys to a keyserver. Conversely, you can import any public key from any keyserver. Note that uploading a key will expose your email address. Keyservers do attempt to foil spammers, but there is no guarantee you won't see an uptick in spam if you upload a key to a keyserver. However, most of us now use good spam filters, so I don't think this is likely to be a serious concern.
• Exchange public keys in the form of text files with specific correspondents, e.g. by email or in a PF post.

To experiment with keyservers, surf to

subkeys.pgp.net

to make sure your keyserver is up and running (God hates keyservers, so a particular keyserver may be down at any given time). If not, search for an alternative keyserver. Then try

gpg --send-keys 8BD94B16 --keyserver [PLAIN][PLAIN][URL]http://subkeys.pgp.net[/URL][/URL]

Then search to check that your public key is now available. Most keyservers offer web tools for searching, but if not, try this:

gpg --search-keys Hillman --keyserver [PLAIN][PLAIN][URL]http://subkeys.pgp.net[/URL][/URL]

(Not all of the keys you see are associated with me! One more reason why the WOT is not just an abstract concept--- you really do need to check by other avenues that you are contacting the person you are actually trying to reach.)

Most keyservers synch with others, so within a day your key should be posted at all the keyservers.

Next, search the keyserver for public keys posted by some people whose email address or email handle you know. (Probably a good idea to be pretty sure you really do have the right email before you email anyone, however! Getting ahead of myself, according to the WOT you should call up your party to verify their email address and to arrange to have them sign your new public key.) When you find a public key you want to import, try this:

gpg --recv-keys KEYID --keyserver [PLAIN][PLAIN][URL]http://subkeys.pgp.net[/URL][/URL]

You should see the new key listed in the output when you type this:

gpg --list-keys

Most keyservers will allow you to obtain a textfile version of any public key they list. Or you can get a textfile containing the public key of a prospective correspondent by email. VB hates textfiles, but you can try cutting out this and pasting it into a file called Hillman.byteme.asc (for ASCII code):

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (GNU/Linux)

mQGiBEuqVwwRBACHVi9wLcEGtwEGb/g+mNPFcGFCq+smME4ZnWETpOBRokVpYBiL
yEefsX+YleFsb39LAa1bzGjxqLbUij1Soq0F0MvwijGg5aY7DccwF6RUnCRRkVQm
UEUM+Jb6QlrPYog9ydl3PBLwBEPHydQp9nXDhC+yp/ofwtZ48uVIWmhupwCg8Dyn
SyE9Yp5jfzB3EM26tKvOmd0EAIUylqNpXy6waBssSyfEMnWltG7/IbyENBPLLK1v
BNcCThYkUsydP1cfFBX5GlBFU4UH39Uej4bR005ZeQqbZan7Ap34balwivQ7uSAt
EyZC1gsxNFJDKr6inENsZELNBVhc0SwuAtpx1qI3FU/Xna9LOvQC4M09YoZYMCIj
Oe5DBACBUhF84apDMo8Fhp56GEShCU78NUSRsHPmqCsTsIcHlwHZjyh1Z30DUb8V
9Npfm80h8D+uxYoyfT6sL2XOTxBhTEHn5xfdsFeesFg274+47AHVhrX7vToH3KpS
qFx6FxB1rWViCmSWNGXv4a0KxUCR1LjNpJs2tAQOxq9bM4kSI7Q9Q2hyaXMgSGls
bG1hbiAoUEYgU2NpZW5jZSBBZHZpc29yKSA8Ynl0ZW1lQHBoeXNpY3Nmb3J1bXMu
Y29tPohmBBMRAgAmBQJLqlcMAhsDBQkB4TOABgsJCAcDAgQVAggDBBYCAwECHgEC
F4AACgkQGls8YIvZSxaPwwCfY8BmYDtZl1Es18oZ4lI1euVi3V8An08ASnjlpp2I
Dz5mzBl3fyE/CQv/uQQNBEuqVwwQEACJ7HpdFa0o7iPaPM8oi/r90sviAnr8Qp1n
Ea3KZ1B5bapmbyva4qr9ztwhu8UJlxJh3ZoZX+rryz5ZAzCiWEqfD5UTKHbIjeg5
z7KfHEce/rF9vgUgTHz7IuSXwO/cOv1pThdcr0ItaPk54b5EhNuP6Zase+euVNDh
mAnZOo+EnSE2qDeuWcN2j2mLY2CssGB4rUlJ0bRwrmH8TyIXGF7PQxgJexSwX3iO
EGB+VnZ8U/M5WKFCDc/1y6WB+tOXwyjwx5u5vs7NV9up68aF0YUWUCFLKbW2ret5
q2x0ezjE6psVgcN/iNrozBmR5FmDTxbCizyhj8/Hh32zXDFjGjjyM1KPdLrBMQhO
eRGaSL+t9TMKhzennL3M9H/D0DwxV1QMNKz8WHVS7IojV9Q00TocGp/x0MvUF03b
beq6mA7mau7+O0Hn77gWlyoE5aziUNGSuALBXw92vpTf09+PJ3SDaKNEkRmhM/IC
kKtrOUEl/cp/GhGUYCxNo2HlcLkemdi6F+igMIbhcOfNjVLcWSlF2Ue6ymZwDwkG
hynOO0MGGoQHkvAC+8eObTZmjhnj0gp9SBY+qDIrE+hX8GxLvS44fAi8LTOmej43
dnpD8PtVj2m0mGaF9/oWvG9QwHMSn4X86Cuj22s2/htmEUmw/5UDtNh6N0+qsAFP
7n0C2I+WtwADBQ//RqUcyYrWRljdUaU363yQrRr/RupyDa2RH2pD3bq5yIfkEJ65
pJFxQzgt9p3Yb+ISUPQnNa+SeAoSr+yMP9hFuqpeXzDV0zK5jPDY+EioKQSfis7m
/8thoq8bRQGsQ8vmJNhYQqhLC2iP/7K9iXtuTCZu+xEdxK59YH+7Wd5KID4+ZeAT
drjdkYxjXZtP7iqqiyYY7BiV1ZKRTlw8PpZ+81DioIpH25L6XBGCHgX1FbBOmxNM
wNxzhlWe/KyEYXtLwyEycTaVbaopQpfRtFg6uaGqRS3Ka2v5sxT8o0fsm7SZzkI+
E9iZxp1b48wvWDp/gFxsmeii/vbpqofaOagAHN0+v0bgVqYZ5pLWbK+lQCOOh2qp
wioqjHPA+ARXMnOR5BYQ28Y7aLXX0d2XfWCuvwsrm6bhjOyAlaA3KQNWljGEAddE
glNwFlXgA1+iYhG869cdubG1hoNBMltJW6i3gDC1VtgsXoPolnx1xolVyc7/ZyoQ
AgT3PQ5bs2zFBBYVJr7MzJiWU02F8dAYhKLAutQr6xVxO2nnEDTB/c6YCb+oLnTm
WLHP5wTuxGRc/1u5c5/aARd+M5YGyVU334aWUKhOki4kyQsLox9mz26eqOIzIC5T
qOuebvLbs6MRNxHRG6QUWGZmfV6M6FJVTxomPwEtBTgz65/YqTFvY2bRTmWITwQY
EQIADwUCS6pXDAIbDAUJAeEzgAAKCRAaWzxgi9lLFiM+AKDI6SX5UK5+1aSTEe1I
lZy3X2RlrwCgsMRe0l3NH/FH3QFI+Z2xm/WEdPM=
=zyQg

Note well: I have found that kwrite, kate, and other such editors work better for cutting and pasting a textfile exactly as written to or from a VB post than does vim. Your mileage may vary.

Assuming the file "Hillman.bytme.asc" is in your present working directory (PWD), try

gpg --import Hillman.bytme.asc
gpg --list-keys
gpg --fingerprint byteme

You should see that my public key with keyid 8BD94B16 has been added to your keyring. Once I add your public key to my keyring, we can now communicate safely.

To export one of your own public keys into a text file which you can share by email or PF post, try this:

gpg --armor --export byteme

If you omit the "armor" flag, you will see some unpleasant binary gobbledygook. I think it impolite to email a public key in non-ASCII form. Especially since some linux users have complained that email from Windows users containing a binary attachment is an executable binary attachment, if you catch my drift.

[size=+2]Modifying "Publicizable" Data In Keypairs[/size]

Before using my public key to encrypt, ideally you should verify by another communication channel that it really does belong to me. Suppose you call me on the phone and ask me to verify the fingerprint. It it matches you can sign my key and then check that your signature has been added:

gpg --edit-key 8BD94B16 
Command > fpr
Command > sign
Command > check

Later, when you upload the publicizable part of your GPG trust database to a keyserver, the fact that you know and trust me will be recorded. Similarly, once I import your public key into my keyring, once I verify by some other channel that it really does belong to you, I can sign your key and upload that information to a key server.

(Alas, making social relationships public turns out to be dangerous in various ways. One precept which I didn't have room to mention in Part I states that every security feature is also a security flaw.)

You can also experiment with trust levels:

Command > trust

Remember that the edit-key command is interactive; to return to the shell simply hit return.

From time to time you may want to extend the lifetime of a keypair. Try

gpg --edit-key 8BD94B16 expire

If you have uploaded your public key to a key server, you should upload it again so that correspondents know you have extended the expiration date. Everyone should periodically check the keyservers for updates to all the keys in their keyring--- this will show whether any have been revoked for any reason, and just as important, will show progress in building your web of trust.

To see what crypto options are available for a given key, try

gpg --edit-key 8BD94B16 showpref

(substituting your own keyid, of course). You should see ouput resembling

Cipher: AES256, AES192, AES, CAST5, 3DES
Digest: SHA1, SHA256, RIPEMD160
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify

Of these options, AES256 is currently thought to be a good block cipher (and 3DES a not so good option), SHA256 is thought to be good digest (and SHA1 not so good), and BZIP2 is a good compression algorithm. In the next part, we'll see that you can specify which of these algorithms to use for various tasks, but note that specifying a particular block cipher method may be incompatible with the capibilities of some of your correspondents.

I'll discuss later how to revoke identities, keys, and signatures, should that become neccessary.

There are many other things you can do with keypairs, like add a second user name, or designate some ultimately trusted party (whose identity you can keep secret) as being authorized to revoke your keys in case you vanish or die. (Sad to say, a very real possibility for human rights activists.) In Linux, the gpg man page contains all these details.

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms: A Tutorial. III. Authentication and Encryption

Recall from Part I that PKI cryptosystems accomplish two equally vital tasks: authentication and encryption. Let's start with authentication, because in good cryptography, everything starts with authentication.

[size=+2]Digital Signatures[/size]

You can use GPG to add a digital signature to any text file (for example, the source code of a software package), or to create a detached signature which can be transmitted seperately from the file itself. Either method can provide assurance to your readers that you are the true author of the file, and can also guard against tampering (much like crytographic hashes).

In both cases, GPG uses a standard cryptographic hash algorithm (SHA-1 is the current default, but SHA-256 would be better) to compute a hash of the plaintext file, and then uses your keypair to encrypt the hash, which is typically output as an ASCII string so that you can safely include it in email, post, or webpage.

For example, consider the text file

Should a wise man utter vain knowledge,
and fill his belly with the east wind?
Should he reason with unprofitable talk?
or with speeches wherewith he can do no good?
Shall vain words have an end?
or what emboldeneth thee that thou answerest?
I have heard many such things:
miserable comforters are ye all.

He teareth me in his wrath, who hateth me:
he gnasheth upon me with his teeth;
mine enemy sharpeneth his eyes upon me.

Try cutting that out and saving it exactly as written as a text file. (Fans of vim take note: probably better to use another editor such as kwrite to cut and paste text files from VM posts.) To sign the file, try

gpg  -u byteme --clearsign myfile

(substituting your userid for "byteme" and the file name you used for "myfile"). You should obtain a file called "myfile.asc" which looks much like this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Should a wise man utter vain knowledge, 
and fill his belly with the east wind?
Should he reason with unprofitable talk? 
or with speeches wherewith he can do no good?
Shall vain words have an end? 
or what emboldeneth thee that thou answerest?
I have heard many such things: 
miserable comforters are ye all.

He teareth me in his wrath, who hateth me: 
he gnasheth upon me with his teeth; 
mine enemy sharpeneth his eyes upon me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkyuDbAACgkQGls8YIvZSxbABACgqCq2XHs6dXvjbAaz5cQ/R6iY
3O4AoKrMKFhU0rq2jmzoDAn2uFTunHpW
=Ejet
-----END PGP SIGNATURE-----

If you successfully imported my public key (given in Part II), try verifying my signature:

gpg --verify myfile.asc

You should see

gpg: Signature made Thu 07 Oct 2010 11:13:04 AM PDT using DSA key ID 8BD94B16
gpg: Good signature from "Chris Hillman (PF Science Advisor) <byteme@physicsforums.com>"

Try tampering with the signed file, e.g

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Should a wise man utter vain knowledge?
Should he reason with unprofitable talk? 
Or with speeches wherewith he can do no good?
Shall vain words have an end? 
I have heard many such things: 
miserable comforters are ye all.

He teareth me in his wrath, who hateth me: 
the wicked plotteth against the just, 
and gnasheth upon him with his teeth;
mine enemy sharpeneth his eyes upon me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkyuDbAACgkQGls8YIvZSxbABACgqCq2XHs6dXvjbAaz5cQ/R6iY
3O4AoKrMKFhU0rq2jmzoDAn2uFTunHpW
=Ejet
-----END PGP SIGNATURE-----

Try verifying the signature again. You should see

gpg: Signature made Thu 07 Oct 2010 11:13:04 AM PDT using DSA key ID 8BD94B16
gpg: BAD signature from "Chris Hillman (PF Science Advisor) <byteme@physicsforums.com>"

"BAD signature" is an indication that either

• the signature is forged,
• the file has been tampered with!

In this case, we know that the second condition is true.

You might notice an awkward feature with such signatures: adding the signature itself alters the original document. You might want to provide a signature for an original document which has not been altered in any way, and which can be kept and transmitted separately. To do that, try

gpg --output myfile.sig --detach-sig myfile
gpg --verify myfile.sig myfile

[size=+2]Encrypting a File[/size]

Some years ago a governmental agency in the UK, charged with ensuring the welfare of the children of the realm of her Brittanic Majesty QEII, was required by law to transmit their database holding vast amounts of personal information about tens of millions of young children to a second agency, which is charged with auditing the first agency. Which turned out to be ironic, because the first agency sent the database on two unencrypted CDs (or two DVDs; accounts differ) by an ordinary parcel post service, and they disappeared somewhere en route. Result: the credit agencies estimate that the possible future cost of this one data breach to the UK could exceed one hundred billion pounds over the next five decades. Because the UK will basically have to somehow provide new identities for every citizen of the UK, or else all their identies will be stolen. Potentially. This incident may well prove to constitute the single most damaging data breach which has yet occurred in human history.

Think about this for a minute. One hundred billion pounds of potential damage over five decades. And all of this could have been prevented had someone simply encrypted some files before creating and mailing off two CDs!

(One government spokesman initially claimed that the files were "password protected", whatever that means, but this apparently was a misunderstanding; the files were not encrypted, simply encoded in a standard format used by some widely used database such as Oracle, which is not the same thing at all.)

One of the most valuable things you can accomplish with GPG does not involve PKI per se: you can encrypt any file using a symmetric cipher. (By default, GPG uses CAST5, but you can choose to use Blowfish, 3DES, or AES256. Of these, the most secure choice is probably AES256 and the least secure is 3DES.) Every citizen should know how to do this! With GPG its pretty simple:

gpg -c filename

The output will be a binary file called "filename.gpg". You'll be prompted for a passphrase, which will uniquely unlock this particular encrypted file. To avoid leaving traces of the original file on disc, you can use

shred -zuvn 25 filename

If you need to create a signed and encrypted file you will email to someone, use this instead:

gpg -sac filename

This will create a textfile called "filename.asc". You should of course use PKI encryption to encrypt an email to the recipient containing the secret passphrase which will unlock the attached encrypted file!

You can use the same passphrase to encrypt many files, e.g. encrypted signed backups on CD of your not-terribly-private personal files

tar -cvf DATE.mylife.tar /home/myuser
gzip DATE.mylife.tar
gpg -sc DATE.mylife.tar.gz

(How hard is that?) For really important files you can employ a distinct passphrase used once.

[size=+2]Encrypting a Personal Communication[/size]

Encrypted emails, at last! Its pretty simple with GPG. Suppose Alice wants to email Bob. Since she may have several keypairs in her keyring, she may want to specify one associated with the handle "wonderland". Suppose Bob uses the email address "bob@bob.org". Then

gpg --output DATE.asc -u wonderland -sea -r  bob@bob.org  DATE.txt

will encrypt a text file called "DATE.txt". The sea flag ensures that the plaintext is both signed and encrypted and that the output is an ASCII file, "DATE.asc", suitable for attaching to an email. When he gets the email, Bob can decrypt the attached cryptogram by saving it as a textfile and running the command

gpg --output DATE.alice.txt --decrypt DATE.asc

Assuming you created two keypairs as I suggested, try encrypting a test message from one user to the other user. When you decrypt it, you should see something like

gpg: encrypted with 4096-bit ELG-E key, ID 38525846, created 2010-03-24
      "Chris Hillman (PF Science Advisor) <byteme@physicsforums.com>"

followed by the plaintext.

Alice can email several recipients the same message using

gpg --output DATE.asc -u wonderland -sea -r  bob@bob.org  -r byteme@physicsforum.com   DATE.txt

Both Bob and myself will then be able to decrypt the encrypted message using the secret parts of our respective keypairs. Alice can add herself as a recipient too without damaging the security of the encrypted message. Remember, GPG is flexible about how you designate keyids; you can use the hex code (unambiguous), an email address, or even just a handle. If it gets confused, it will probably ask you to be more specific.

I'd like to see all SA/Ms install GPG, create keypairs, and post their public keys in their PF user pages!

[size=+2]Shell Scripts for Personal PKI Crypto[/size]

GPG line commands can get rather long, as you might have noticed. I find it useful to collect some scripts in the directory

/usr/local/bin

For example, a bash script which can be used to create cryptograms which should be readable only by a small mailing list could look something like this:

#!/bin/bash
# Encrypt signed eyes-only message for mailing list
# Syntax      mailthelist filename
gpg -u 8BD94B16 --for-your-eyes-only -sea -r 7B140D12 -r 8BD94B16  $1

This script will fail if any of the keypairs included in the mailing list are no longer valid. The "for-your-eyes-only" flag encourages recipients to archive at most the cryptogram, not the plaintext. It might also provide some resistance to TEMPEST snooping.

If everyone on the mailing list has installed a reasonably recent version of GPG, they will be able to use the AES256 block cipher. Then an even better script would be

#!/bin/bash
# Encrypt signed eyes-only message for mailing list
# Syntax      mailthelist filename
gpg -u 8BD94B16 --for-your-eyes-only --cipher-algo AES256 -sea -R 7B140D12 -R 8BD94B16  $1

Capitilizing the R's ensures that the recipients will be hidden, which can foil traffic analysis. Recipients can decrypt the message using

#!/bin/bash
# syntax        readthelist file
gpg -u  8BD94B16--decrypt $1

(substituting the appropriate fingerprint for my own keyid, of course).

If you try experimenting with such scripts, when you decrypt a test message you should see GPG noting that it is trying multiple secret keys to find which one unlocks the file, since it doesn't know which of your own keyids is listed among the intended recipients are. And when it prompts you for the appropriate key phrase and decrypts the message, you should see something like

gpg: encrypted with ELG-E key, ID 00000000
gpg: encrypted with 4096-bit ELG-E key, ID 38525846, created 2010-03-24
      "Chris Hillman (PF Science Advisor) <byteme@physicsforums.com>"
gpg: NOTE: sender requested "for-your-eyes-only"

followed by the plaintext.

A similar script could be used to occasionally post in the Mentors forum encrypted messages readable only by Mentors. This could be very useful for alerting Mentors to a serious security breach of PF, for example, which might require sharing sensitive information under circumstances when it is known that the Mentors forum is being read by an intruder.

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms: A Tutorial. IV. When Things Happen

Things happened.

In this post I will try to explain some measures you can take when things change, or even worse, when something breaks. In particular, what to do when (as will probably happen sooner or later) you believe your crypto may have been compromised.

[size=+2]Keep Your Keyring Safe![/size]

You say: but I don't want my crypto to be compromised! Of course not. What is the one thing you can do to lessen the chances of that happening? The answer depends on circumstances, but assuming you aren't doing anything as cryptographically suicidal as using a computer you don't own for cryptoprocessing, or transmitting your passphrases in the clear over some unprotected channel, I should mention an issue which might be too sensitive for an unencrypted communication: finding a sensible compromise between keeping your keyring safe and making it sufficiently accessible to use personal PKI routinely.

If you use whole disk encryption (using of course strong cryptographic software other than GPG, such as truecrypt) you probably don't need to worry about this. If not, you do. I keep mentioning this issue because it is really important.

I can explain by encrypted comm several practical compromises. It helps that GPG is perfectly happy with your using not only multiple keyids, but keyids kept in multiple keyrings, none of which need to be aware of the others. (Which last raises further concerns, once again illustrating the maxim that every security feature is also a security flaw.) This means that you can adopt different compromises for different keyrings holding keys used for different purposes and requiring more or less security.

[size=+2]Revocations[/size]

Suppose you have been using a GPG user ID which gives your email address at a certain academic department, but you move to a new department. Your old email will no longer be valid, and you may be using a new computer to do cryptographic processing (probably in violation of the precept that you should never do personal PKI crypto processing on a computer you do not own). In such a case you should revoke your old userid and create a new one

gpg --edit-key KEYID revuid

Next, you can update the keyservers so that your change of circumstances becomes publically known. As a matter of fact, GPG may well do this automatically on your behalf, depending upon your GPG configuration. (Every security feature is also a security flaw: this can leak to possibly unfriendly third parties information about which crypto identities are associated with a given IP address. To some extent, torifying DNS lookup, or running your own DNS private server, can mitigate this problem.)

I hope you never have to revoke a public key, but you should know how, just in case. In fact, just for practice you should probably create a keypair and then revoke it after a few days. The first step is to modify your own keyring so that your own installation of GPG knows the key is no longer valid:

gpg --edit-key KEYID disable
gpg --edit-key KEYID revkey

Once a key has been revoked, effective immediately, you can no longer use it to encrypt messages, but you and your correspondents can still use it to decrypt old messages stored as ciphertext.

Next, use your revocation certificate to tell the keyservers that you are revoking the keypair (you can give a reason), assuming you posted the public half.

One reason why you don't want an intruder messing with your GPG keyring is that a sophisticated malefactor could revoke your keys improperly, making it impossible for you to communicate, at least until you can generate new ones and get your correspondents to import them--- which you obviously should never do on a computer known to have sufferered an intrusion. If you have kept a secure copy of all your key revocation certificates on a write-protected floppy which has been kept in a locked safe, in such an event you can probably use a live CD like Knoppix to revoke your keys. Then you can install from scratch and generate new GPG keypairs and reestablish communications.

Suppose a PF SA loses his badge for some reason. (Rare, but its been known to happen.) Or even worse, suppose you discover that someone whose public key you signed, believing he is Greg B, turns out to be an imposter. In such a case, you need to revoke your signature of someone else's key, so that you are no longer certifying his identity or membership in some group. And if you know your own keypair has been compromised, you should revoke your own signatures of other persons keys. In all cases, the procedure is the same, and it is interactive:

gpg --edit-key MYKEYID revsig

You'll be asked, for each key ever signed using MYKEYID, whether or not to revoke it. Depending on circumstances, you probably want to revoke either a particular signature, or all of them.

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms: A Tutorial. Interlude.

Already some corrections:

• I have had second thoughts about the title, but it is too late to change it now! Technically, PKI is an authentication framework (it includes things like X.509 certificates); PKI is centralized (and has proven controversial), whereas the GPG and PGP "web of trust" model is distributed. I should have titled this thread "Personal Public-key Cryptosystems for SA/Ms", or more accurately "Hybrid Personal Cryptosystems" (referring to the fact that GPG and PGP use a public-key cryptosystem to transmit the secret message key which is used in a block cipher to encrypt/decrypt a particular message).
• I wrote
  

  One particularly scary fact about current PKI is that it depends upon the factorization of primes remaining hard.

  I was of course thinking of the original RSA public-key crypto algorithm. The security of GPG rests upon
  • the strength of the El Gamal public-key cipher, i.e. upon the assumption that computing discrete logorithms is hard,
  • the strength of the CAST-128 cipher (aka CAST-5), or whatever other block cipher among the choices on offer from GPG you choose,
  • the strength of the DSA signing algorithm used for authentication.

Coming attractions (not neccessarily in expected order of appearance):

• a brief summary of current crypto laws comparing the US, Canada, UK, EU, Australia, FSU, India, according to my understanding--- corrections urgently desired!
• discussion of useful options you can put in a GPG configuration file,
• (possibly) my attempt at a nontechnical concise survey of some specifically cryptographic issues every crypto user should probably know about,
• (possibly) a discussion of some issues which arise when backing up and/or transferring to another computer a GPG keyring,
• (possibly) a discussion of setting up and using Tor, and "torifying" certain applications, plus known intelligence abuses of and security flaws in Tor,
• (possibly) a discussion of random permutations in large symmetric groups (because everyone should probably know a bit about this),
• (possibly) a bit about the promise of quantum cryptography and the threat to RSA, El Gamal, &c. from quantum computers,
• a look "under the hood" at what GPG actually does, and my attempt to briefly assess its level of security, plus a bit more about possible flaws lying outside GPG itself (but just as dangerous as a direct cryptographic attack on El Gamal or CAST-128),
• a small bibliography of useful printed books,
• some useful links,
• a discussion (I hope) of experimenting with an encrypted mailing list or encrypted posting system, by which SA/Ms can read encrypted emails or posts.

Some ironical historical facts:

• fact: the early development of GPG was funded by the German government,
• fact: the early development of Tor was funded by the U.S. government, in fact, the U.S. military.

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms: A Tutorial. V. Bibliography & Links

[size=+2]A Brief Bibliography[/size]

• Ferguson and Schneier, Practical Cryptography, Wiley, 2003. Fine overview of issues involved in striving for strong crypto in practice.
• Schneier, Applied Cryptography, Second edition, Wiley, 1996. "The bible"; more technical than Ferguson and Schneier.
• Menezes, van Oorschot, and Vanstone, Handbook of Applied Cryptography, CRC Press, 1996. The complete handbook is available for personal use at
  
  www.cacr.math.uwaterloo.ca/hac/
  An invaluable reference; clear and concise descriptions of various cryptosystems, state of the art (c. 1996) of various number-theoretic problems related to cryptography, &c.
• Diffie and Landau, Privacy on the Line, MIT Press, 1998. Sets out some of the arguments why strong personal cryptography should be legal everywhere.
• Kahn, The Codebreakers, MacMillan, 1967. The classic history (somewhat superseded by information released since 1967).
• Bamford, The Puzzle Palace. Readable history of the NSA.
• Bamford, Body of Secrets, Random House, 2002. Equally readable update to include events 1990-2001 inclusive. Also revealed Operation Northwoods, a Kennedy era plot which forms the kernel of truth behind the wackiest 9/11 conspiracy theories. (Post-Ellsberg cynic that I am, I had believed that nothing the Pentagon could dream up could shock me, but I was wrong.)

[size=+2]Some Useful Links[/size]

• The GnuPG home page
  
  www.gnupg.org/
  Make sure to grab a copy of The Gnu Privacy Handbook from the documentation section (old but still useful).
• Archives of the GnuPG-Announcements mailing list, including occasional security alerts
  
  http://lists.gnupg.org/pipermail/gnupg-announce/
  (quick reassurance: AFAIK, there are no unfixed bugs in the current stable edition of GnuPG, which as of October 2010 is v. 1.4.10, or v. 1.4.9-3+lenny1 for Lennians; more recent versions are "testing" versions and may contain as yet undiscovered flaws),
• The Tor project
  
  blog.torproject.org/blog
  www.torproject.org/overview.html.en
  www.torproject.org/docs/debian
  www.torproject.org/eff/tor-legal-faq.html.en
  wiki.torproject.org/noreply/TheOnionRouter/TorFAQ
  wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms
• The Seul mailing list (for Tor-related discussions)
  
  archives.seul.org/or/talk/
• Bert-Jaap Koops's indispensable international survey of crypto laws
  
  rechten.uvt.nl/koops/cryptolaw/
  Be sure to check out the handy maps which compare three types of legal proscriptions which may apply: on exporting" crypto (probably irrelevant here), on "importing" crypto (in principle, such restrictions might apply to downloading crypto software from servers in certain countries), and on using personal cryptography.
• The EFF opposes laws outlawing cryptography and free speech; some of the most relevant pages include
  
  https://ssd.eff.org/
  https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy
  www.eff.org/issues/bloggers/legal
  www.eff.org/deeplinks/archive
  www.eff.org/deeplinks/2010/01/trends-2010
  Note that the Deeplinks blog provides some of the best information about the latest attempts to outlaw cryptography, Tor, peer-to-peer softare, Skype, etc., in the U.S. (and everywhere the U.S. has influence). The US DOJ has recently proposed to propose next year laws restricting personal cryptography, laws which would be remarkably similar to ones which even the UAE recently abandoned as too harsh. As I said in Part I, however, this thread is not the place to discuss these proposals.
• Some relevant pages from some other organizations generally opposed to censorship and bigbrotherism:
  
  www.cdt.org/
  www.aclu.org/spy-files
  www.aclu.org/national-security/surveillance
  www.aclu-wa.org/issues/surveillance
  epic.org/
  voices.washingtonpost.com/top-secret-america/
  At the ACLU website, be sure to look for several whitepapers which provide an excellent overview of privacy concerns and why they matter
  • Jay Stanley, The Surveillance-Industrial Complex, August 2004,
  • Jay Stanley and Barry Steinhardt, Bigger Monster, Weaker Chains, January 2003
• Key servers useful for GPG users include
  • servers which offer www interfaces (i.e. you can search them and download keys via your web-browser, useful if you use Tor and have torified DNS lookup):
    
    keys.gnupg.net
    wwwkeys.us.pgp.net
    wwwkeys.uk.pgp.net
  • servers which use the HKP protocol (gpg uses this protocol to export/import keys to/from a keyserver using the line commands discussed in Part II):
    
    hkp://subkeys.pgp.net
    hkp://pgp.mit.edu
    hkp://pool.sks-keyservers.net (random server)
    hkp://keys.nayr.net
    (Warning! A distinctive protocol is easy to filter for, monitor, block, &c, so using the line commands discussed earlier could be dangerous.)
• What to bring to a key-signing party:
  
  commandline.org.uk/command-line/ten-steps-for-attending-a-keysigning-party/
  www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html#overview
• So far, it seems that Wikipedia articles on cryptography have (surprisingly) so far mostly escaped the problems of cranky edits, edit wars, and so forth, and generally seem to be pretty good. Some of the most relevant articles are
  
  secure.wikimedia.org/wikipedia/en/wiki/GnuPG
  secure.wikimedia.org/wikipedia/en/wiki/Topics_in_cryptography
  secure.wikimedia.org/wikipedia/en/wiki/ElGamal
  secure.wikimedia.org/wikipedia/en/wiki/Digital_Signature_Algorithm
  secure.wikimedia.org/wikipedia/en/wiki/CAST5
  secure.wikimedia.org/wikipedia/en/wiki/Web_of_trust
  secure.wikimedia.org/wikipedia/en/wiki/Chosen-plaintext_attack
  secure.wikimedia.org/wikipedia/en/wiki/Chosen-ciphertext_attack
  secure.wikimedia.org/wikipedia/en/wiki/XSL_attack
  secure.wikimedia.org/wikipedia/en/wiki/Data_remanence
  secure.wikimedia.org/wikipedia/en/wiki/Differential_cryptanalysis
  Notice that I have given links to a Wikimedia server offering https connections to your browser; this is particularly useful in conjunction with Tor.
• Neal Koblitz, "The Uneasy Relationship Between Mathematics and Cryptography", Notices of the AMS 54 (2007)
  
  www.ams.org/notices/200708/tx070800972p.pdf
  Believe it or not, this charming essay, which among other things cautions against the development of a mathematics-cryptoindustrial complex, ignited a flame war within mathematics. (Those of you who already knew this will no doubt have recognized the inspiration for my ironical mangling of the Bible to illustrate digital signatures!)
• Bruce Schneier's website offers some of the most readable and well-informed commentary on crypto and computer security generally:
  
  www.schneier.com/
  www.schneier.com/essays.html
  www.schneier.com/crypto-gram-back.html
  Schneier was one of those who criticized Koblitz's essay; some of his own claims have been criticized equally harshly. Cryptography is powerful stuff and consequently it should probably surprise no one that it excites powerful passions.

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms: A Tutorial. Interlude (cont'd)

Add to the bibliography:

• Steven Levy, Crypto, Viking, 2001. An entertaining popular account of the tangled history of strong publically available cryptography.

Add to the coming attractions: a timeline of the history of modern personal cryptography.

The history is full of rather delightful ironies, which I cannot resist highlighting here. Accordingly, for your amusement, here are some trivia questions (to be answered in a subsequent post):

• What long-running comedy routine was the inspiration for the name "Pretty Good Privacy"?
• Leslie Lamport, author of LaTeX, also has a cryptographic claim to fame. What is it?
• How did the Church of Scientology almost gain control of personal cryptography in 1984? It failed, and then turned against personal cryptography. In 1995, how did it shut down a famous cypherpunk service?
• In 1991, how did then Senator Joe Biden inadvertently induce Phil Zimmerman to release PGP into the public domain, thus ensuring that strong cryptography would be publically available overseas, the very thing Biden wanted to prevent?
• What Clinton era initiative was opposed by figures and groups as diverse as Rush Limbaugh, Bill Gates, and the ACLU?
• In 1994, an NSA official, in the presence of witnesses, insisted that he wanted to immediately take outside Jim Bidzos (CEO of RSA Data Security), in order to do something to him in the parking lot. What was it that the official wanted to do?
• In 1994, why did a lap dancer interrupt her performance over Phil Zimmerman's crotch?
• What backhanded complement did NSA official Howard Rosenblum pay to Alan Konheim, a member of the IBM team which developed the DES block cipher?
• In 1994, the NSA threatened to declare Lotus 1-2-3 illegal. In December 1996, the NSA attempted to make six million users of Lotus Notes subject to criminal prosecution which would have carried long prison sentences. On what grounds did it base its legal argument in these incidents?
• Which three U.S. Senators were most critical of the NSA's position during the late nineties? Which one of them had a connection with the Moonies?
• The RSA algorithm is patented. What historical fact makes this patent highly ironic?
• In 1971, Joseph Meyer, without revealing his employment at NSA, published a paper in an IEEE journal proposing a then very novel idea which a few decades later became commonplace, even being featured in such popular TV series as "Desperate Housewives". The scheme Meyer proposed would not be possible without something I often discuss in the BRS. What did Meyer propose, and what is the connection with many other BRS threads?
• In his 1971 paper, Meyer went much further, suggesting that government surveillance coupled with extensive databases holding sufficiently detailed amounts of information on the daily activities of all citizens fitting a "profile" could predict crimes in advance, leading to guaranteed apprehension before the commision of any crimes. In this way, he proposed, a crime-free society could be created by the use of computer technology. This idea, which some refer to as "the surveillance state" or "massive wholesale population surveillance", has since been enthusiastically adopted by what has been called the fastest growing component of the military-industrial complex during the past decade. Buzzwords associated with this sector, which some estimate is currently a 50 to 100 billion dollar per year industry, include "precrime", "public-private intelligence partnership", and "intelligence-led policing". Many examples of companies engaged in modern attempts to realize Meyer's vision are listed in this WP article:
  
  https://secure.wikimedia.org/wikipedia/en/wiki/Inqtel
  Ironically, in 1977, Meyer--- again without revealing his employment by the NSA--- wrote an influential letter to the IEEE, attempting to shut down part of the then nascent software industry. Had he succeeded, he would have prevented the development of on-line banking and on-line shopping. What did his letter concern?

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms: A Tutorial. VI. All Your Base R Belong to Us

In order to use GPG wisely, I think it is important to know a bit about how it works.

Recall that GPG rests upon three patent-free pillars:

• CAST-128 (aka CAST5), the block cipher used by default to encrypt the actual message in 128 bit blocks,
• ElGamal encryption, the public-key cipher used to transmit the message key (the encryption/decryption key for CAST-128),
• DSA, the NIST-approved signature algorithm, used in GPG to authenticate the ElGamal encryption of the CAST-128 encryption/decryption key.

Thus, DSA is used to authenticate the source of the message, ElGamal encryption is used to transmit to the recipient the encryption/decryption key used in the CAST encryption of the message itself. Because ElGamal encryption does not depend upon the keypair of the sender, it is appropriate for "anonymous" enciphered messages intended for a specific recipient, but this feature is undesirable here, hence the need to incorporate DSA.

Of these cryptographic ingredients, the simplest to explain is probably the ElGamal encryption/decryption algorithm.

First, some notation: if n is a positive integer, ${\mathbb Z}_n$ denotes the ring of integers modulo n, and ${\mathbb Z}_n^\ast$ denotes the multiplicative group of units (i.e., ring elements with an inverse). This is an abelian group of order $\phi(n)$ (Euler's phi function from elementary number theory); it has $\phi(\phi(n))$ generators. (Recall from elementary group theory that g is said to be a generator of a multiplicative cyclic group G if every element of G arises as some power of g.)

Notice that when n=p is a prime, the group of units is the cyclic group of order p-1, which has $\phi(p-1)$ generators. In what follows, we work modulo p, i.e. in the ring ${\mathbb Z}_p$, although we are really only interested in the invertible elements in this ring, i.e. "the nonzero elements".

To create a public-private keypair, choose a large prime (hundreds of digits), call it p. (Efficient ways to do this are known.) Next, choose any generator $g \in {\mathbb Z}_p^\ast$. Now choose (almost) any $x \in {\mathbb Z}_p$; this will be the secret key. Finally, put $y = g^x \in {\mathbb Z}_p^\ast$; the public key is now the triple $(p,g,y)$.

Next, represent the plaintext (the CAST-128 encryption key) as some element $m \in {\mathbb Z}_p$. In ElGamal's scheme, in order to encrypt this for transmission to some recipient, we need only know his public key; we need not even have generated our own keypair! Specifically, choose any generator $k \in {\mathbb Z}_p^\ast$; then the ciphertext corresponding to (m,k) is
$$\begin{array}{rcl} \bar{m} & = & ( a, b) \in {\mathbb Z}_p^\ast \times {\mathbb Z}_p \\ a & = & g^k \\ b & = & m \, y^k \end{array}$$
Thus, in ElGamal encryption, the ciphertext is always twice as long as the plaintext; given a plaintext, one of many possible ciphertexts is in effect pseudorandomly chosen for transmission to the recipient. Because the usual laws of exponentiation work fine modulo p, we have
$$y^k = \left( g^x \right)^k = g^{xk} = g^{kx} = \left( g^k \right)^x = a^x$$
Thus, the recipient can decrypt the message as $m = b a^{-x}$, independent of choice of k.

Here is a concrete example: suppose p = 104779. Then 2,3 are not relatively prime to p-1=104778, but 5 is, so let g=5. Suppose the recipients secret key is x=99999. Then y=g^x = 35422 (remember that we are working modulo 104779), so the recipient's public key is (104779, 5, 35422). Then message m = 85703 encrypts as follows:

• if we choose k= 15001, we obtain ciphertext (34509, 82914), and then $82914 \cdot 34509^{-99999} = 85703$,
• if we choose k = 2003, we obtain ciphertext (73605, 101435), and then $101435 \cdot 73065^{-99999} = 85703$.

You are probably wondering: why introduce k? Why bother to perform two exponentiations modulo p, and to transmit a ciphertext which is twice as long as the plaintext? I'll let you think about that for a bit, while I move on to some other matters.

You may be suspicious that the specifications for ElGamal encryption are quite vague about what primes constitute "acceptable moduli". Clearly, the security of ElGamal encryption rests upon the assumption that given p, g, it is easy to compute $y = g^x \mod p$ from x, but hard to recover x from y. Is it possible that this is not true for all "large" primes p?

Indeed, it is not. It turns out that for primes p such that p-1 happens to have only small prime factors, the Pohlig-Hellman algorithm provides an efficient computation of any discrete logarithm modulo p. For example, compare these adjacent primes:

• $p = 104779, \; p-1 = 104778 = 2 \cdot 3^2 \cdot 5821$
• $p =104789, \; p-1 = 104788 = 2^2 \cdot 17 \cdot 23 \cdot 67$

The Pohlig-Hellman algorithm is efficient for the second prime. You don't want to use such a prime in your ElGamal keypair. Fortunately, such primes are rare, so you are unlikely to choose a "bad" prime if you chose a "large" prime "at random".

In addition, bias in choosing the "random" exponent k during the encryption step can facillitate a "baby-step giant-step" search for secret keys, so it is important to code up a very carefully designed pseudorandom selection of exponents k which are relatively prime to p-1.

Furthermore, it may be important to know that if for some prime p the discrete logarithm problem modulo p turns out to be feasible for any reason, then any ElGamal keypair which was ever generated using that modulus must be considered to have been compromised.

Because the enemy can use the public key of his target to encrypt arbitrary plaintexts, he can create arbitrary (plaintext, ciphertext) pairs, and thus he can mount a chosen ciphertext attack on his target's secret key. This feature was of course recognized from the beginning, and in the paradoxical way of cryptography, it need not be seen as an "intrinsic weakness".

So how strong is GPG, cryptographically? The general discrete logarithms problem is still thought to be hard, and ElGamal is still thought to be strong. I'd be happier if CAST-128 used a larger block size, and I worry about the mode it uses for block by block encryption, but AFAIK the consensus is still that CAST is a reasonably strong block cipher. Which leaves the signature component of GPG, the DSA algorithm.

The first area of worry about DSA becomes evident when we consider the sources of the three cryptographic ingredients of GPG:

• the block cipher CAST-128 was designed by the British academic cryptographers Carlisle Adams and Stafford Tavares, apparently independently not while clandestinely working for any intelligence service,
• ElGamal encryption was designed by the Israeli-born academic cryptographer Taher ElGamal, who was then a graduate student at Stanford, and who was apparently not clandestinely working on behalf of any intelligence service,
• DSA was designed by the American cryptographer David Kravitz, an employee of NSA.

That's right: the security of GPG rests crucially upon a message authentication scheme which was produced by NSA for "civilian use". NSA experts have represented this scheme to NIST as "acceptably strong", but that is not neccessarily the end of the story. To begin with, GPG uses a 1024 bit key for DSA, which NIST acknowledged in the original 1994 specification will yield keys valuable for only a decade. Ouch! But that's not all: NSA experts have on occasion proven to be either duplicitious or fallible: at least one major "civilian" system which NSA had declared to be "adequately secure" was soon afterwards shown (by a civilian cryptographer!) to be insecure. Second, although people don't like to talk about this, at one point in the 1990s NSA seriously considered promulgating a deception in which they would certify as "strong" to NIST [sic] a cipher which in fact NSA knew how to break. (The agency decided against this scheme after realizing how quickly the civilian cryptologists were catching up to their best experts, concluding that such a scheme would probably soon be uncovered, with consequent severe embarrassment to the U.S. government.) This is one reason why many people have been mistrustful of SELinux, an NSA elaboration of linux used by many major corporations to lock down things like on-line banking databases. Third, while people don't like to talk about this either, Tor is known to have originated as a successful deception in which a "security" system with a known weakness was highly touted and was adopted by many foreign embassies. So cryptographic deceptions perpetrated upon the public, and even upon Fortune 500 conglomerates, can and do occur.

Despite such legitimate and serious concerns, I advocate using GPG and Tor because the currently available alternatives appear to be even worse.

All in all: using GPG may not prevent your private email being read by NSA, but it should help to establish in court that you had a reasonable presumption of privacy in some PF-related communication, if it ever comes to that, as I fear it may. And it should help establish in any class action suit against commercial snoops such as Google or Accenture that "I desired privacy when I sent that message". This is important because the presumption of privacy in internet communications appears to be both legally ill-established and under constant threat from many quarters.

Perhaps never more so than at the present time, when the top officials in the U.S. secret police agencies are now the same officials who some years ago pioneered some of the most ethically vacuous and legally outrageous policies ever pursued by the U.S. government, such as extra-judicial assassinations of persons (and anyone nearby) who simply "fit a profile"--- recall the vision of Joseph Meyer. See for example

• Spencer Ackerman, "Charlie Wilson’s Warrior Becomes Top Pentagon Spook", Wired, Threat Level, 30 September 2010
  
  www.wired.com/dangerroom/2010/09/charlie-wilsons-warrior-becomes-top-pentagon-spook/
• Chris Williams, "CIA used 'illegal, inaccurate code to target kill drones", The Register, 24 September 2010,
  
  www.theregister.co.uk/2010/09/24/cia_netezza/

Sad to say, threats to civil liberties and due process of law appear to have become even more dire under the current administration than they were under the previous one, which is certainly saying something.

 

[Chris Hillman]

Delete me

Sorry, inadvertent duplicate post. If we had an encrypted mailing list I could say why this illustrates a problem with VB.

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms: A Tutorial. Interlude (cont'd)

I have quite recently successfully exchanged public keys and encrypted PMs with another SA/M, and have previously done so with several other SA/Ms. Therefore, it seems safe to state with confidence that it is quite possible to exchange encrypted PMs at PF.

Answers to trivia questions:

• Zimmerman is a fan of Garrison Keilor's long-running NPR variety show "A Prairie Home Companion", which featured a regular comedy skit called "Ralph's Pretty Good Grocery". Zimmerman says this was the inspiration for the name "Pretty Good Privacy", which was meant to suggest that he felt PGP should provide decent but far from stellar protection. The earliest version of PGP in fact used an insecure block cipher of Zimmerman's own devising; current editions of PGP use the IDEA cipher by default, while GPG uses CAST-128 by default; these block ciphers are still generally considered to be secure.
• In 1981, Lamport published the first digital signature scheme.
• In the 1985 incident, Ralph Bennett, a majority shareholder in RSA Data Systems, was allegedly a scientologist who expressed interest in transferring his shares to the Church of Scientology. In August 1986, the threat of CoS ownership was neutralized when Bennett ended his business relations with RSA Data Systems, which was going bankrupt. (It's fortunes later improved.) In the 1995 incident, CoS induced the Finnish police to shut down the Penet remailer. Their lawyers argued that Penet clients were quoting from Scientology scripture, which the Church has copyrighted.
• On 24 January 1991, Senator Biden quietly inserted into S. 266 a paragraph proposing a new requirement which would ensure that the U.S. government could recover the plaintext of any encrypted communications. When computer scientists, software industry leaders, and privacy groups became aware of this proposal--- which became known as "key escrow", later "key recovery"--- in April 1991, a firestorm of protest ensued. Zimmerman says he was impelled to release PGP into the public domain in response to a message on a mailing list from a well-informed crypto advocate who pointed to Biden's bill and warned of a determined effort within the government to outlaw strong personal cryptography. Zimmerman says he hoped to act while he could still legally release a strong cryptosystem for personal use, in hope of presenting the Clinton administration with a fait accompli. It worked. Advocates of strong personal cryptography, especially Senators Cantwell, Murray, and Weldon, used the argument that strong cryptography (PGP and other products) was already widely used overseas to block the adoption of three successive Biden sponsored bills informally called Clipper I, II, III. Unfortunately, they were unable to enact the SAFE bill, which would have explicitly protected strong personal cryptography. Consequently, the status of cryptography was left unresolved, and in 2010, a proposal we might call Clipper IV is once again being touted by members of the Obama administration, including of course V.P. Biden, who apparently remains committed to the cryptographically disastrous notion of "key escrow".
• The NRA, Rush Limbaugh, Bill Gates and a coalition of Fortune 500 companies, and the ACLU all opposed the successive key escrow laws (Clipper I, II, III) which the Clinton administration tried to enact during the 1990s. Eventually, in a 1999 backroom deal, the administration dropped the key escrow plan, and Senator Cantwell (D, WA) agreed to drop the SAFE bill, which would have explicitly guaranteed the legality of strong personal/corporate cryptography. Laws similar to Cantwell's bill were enacted in various other countries, such as Germany.
• The NSA official repeatedly stated (ignoring the efforts of others in the room to shut him up) that he wanted to run over Bidzos with his car.
• The lap dancer asked Zimmerman what he did for living, Zimmerman replied that he was a programmer who had written a program called PGP. It turned out she was an enthusiastic cypherpunk, and she stopped to discuss PGP with its inventor.
• Konheim says that Rosenblum complained "You did your work too well". IOW, NSA had expected IBM to come up with a weak block cipher they would be able to break, and was dismayed to find that the cipher which is now known as DES provided a serious challenge to the raw computing power of the NSA.
• Senator Biden was the most active proponent of outlawing strong cryptography during the 1990s; his most determined opponents were Senators Cantwell, Murray, and Weldon. (All four are Democrats. But this might not be a natural "wedge issue" for the Republicans in the November 2010 US elections, since the Tea Party would, I guess, favor strong personal cryptography while mainline Republicans would, I guess, oppose it out of deference to the wishes of the FBI. Thus, both parties probably want to suppress discussions of encryption, at least until after the elections.) Senator Weldon later lost a re-election bid, possibly due in part to his alleged relationship with the Moonies.
• The basic idea of public-key crytography had been invented by James Ellis in 1969, years before it was independently reinvented and published by Diffie and Hellman, and the RSA algorithm had been previously invented by Clifford Cocks in 1973. Both men were employees of GCHQ (the UK counterpart of NSA), which apparently failed to recognize the importance of these developments, but by force of habit elected to keep them secret. Later, GCHQ decided not to contest the RSA patent. Thus, the RSA patent recognizes as "original work" an algorithm which had in fact been described in a secret UK memo four years earlier than the publically published work of Rivest, Shamir, and Adleman. Ironically, HRH Prince Charles could have greatly benefited from secure encryption of certain phone calls he placed in 1989, using a cellular phone. Just imagine: we could have all been paying royalties to HM QEII in order to use strong personal cryptography while browsing (using an https connection to "secure website"), or while enaging in on-line financial transactions. God save the GCHQ!
• NSA claimed that cryptography is a "munition" and thus subject to the provisions of the International Traffic in Arms Regulation (ITAR) law, which does in fact list "privacy devices and cryptographic devices", meaning cipher machines similar to WWII era machines such as Enigma. The NSA claimed that ITAR language mentioning "documentation" covered academic papers discussing novel cipher algorithms. NSA's real target in its threats against Lotus was the Mailsafe component of Lotus Notes, which had been designed by Ron Rivest and which incorporated RSA key exchange with various block ciphers, originally DES and later RC-2, RC-4, etc. (designed by Rivest), which Lotus progressively weakened in response to NSA demands. In the 1994 incident, NSA threatened to declare Lotus 1-2-3 illegal because while it included no cryptography, it did store a hashed password. (I swear, I am not making this up!) In the 1996 incident, NSA strongly urged enactment of a bill which would have made the six million users worldwide who had already purchased Lotus Notes (which includes Mailsafe) subject to felony prosecution. The bill failed.
• Meyer's 1971 paper proposed to use radio transponders (something like a passive RFID chip) to monitor in real time the location of parolees and persons released on bail. GPS monitoring of persons required to wear an ankle bracelet has become commonplace and was featured in the American TV show "Desperate Housewives". GPS is so sensitive that if it did not employ several relativistic corrections, including some gtr effects, the system would require constant intervention from ground operators.
• Meyer's 1977 letter to the IEEE claimed that an upcoming crypto conference to be held in Ithaca, NY, would violate ITAR and would place the organizers, presenters, and attendees at risk of prosecution under ITAR. IEEE quickly responded with a cowardly letter saying that the researchers bore responsibility for complying with ITAR. Although Meyer did not reveal his NSA employment in his 1977 letter, his argument was in fact the first expression of NSA's official position during the 1990s, that strong personal/corporate crypotography was illegal. Had this view prevailed, on-line banking and other on-line financial transactions, on-line medical records, etc., would have been impossible, or at least, even more risky than is presently the case.

Here are two further trivia question I forgot to ask in my Post #7 above:

• PFC Bradley Manning has been held in solitary confinement since June but apparently has not been charged. I don't know whether he has been waterboarded. His principal alleged offense appears to have been allegedly leaking to Wikileaks footage taken from a U.S. military helicopter showing the "collateral damage" deaths of a team of Reuters newsman, whose camera equipment the U.S. soldiers had apparently mistaken for weaponry. The U.S. military is also said to be trying very hard to arrest Julian Assange, founder of Wikileaks, anywhere in the world they can find him, on any charge they can concoct. What is the cryptographic irony in the strenuous condemnation by the U.S. military of the unauthorized appearance of such sensitive footage in Wikileaks?
• Then V.P. Gore was a loyal proponent of Clinton era key escrow initiatives, in deference to the NSA's wishes. Since leaving office, Gore has become famous for his grave concern about a certain widely publicized phenomenon. What is this phenomenon and why is Gore's concern highly ironic in view of his previous advocacy for the NSA?

There's something about cryptography which seems to attract legal and political controversies far too bizarre for fiction. And more hilarious than a Saturday Night Live skit. You just can't make this stuff up.

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms. VI. All Your Base R Belong to Us (cont'd)

Correction: CAST-128 encrypts messages in 8 byte (64 bit) blocks, not 128 bit blocks. The length of the key is 128 bits. Sorry! (Ideally, I wouldn't try to write while ill, but time is short, so...)

Before I forget, a random list of does and donts:

• do stash your GPG keyring in a protected location (ideally, off-line or in a computer which never goes on-line, but at the very least, in an encrypted area),
• don't violate standard precepts of good cryptographic practice which apply to using any block cipher, irrespective of whether the block encryption/decryption key is transmitted using public-key cryptography,
• in particular, don't quote other messages in your plaintext, don't mix plaintext and ciphertext; even though the ElGamal cipher is exposed by design to "chosen ciphertext attacks", you don't want to leak information which could aid an attack on the CAST-128 encryption of a particular message; remember, all kinds of sophisticated attacks have been fully automated and are more widely employed than most people realize; the principle cryptographic adversaries of the private citizen are sophisticated and control scads of computing power,
• don't store unprotected decrypts of GPG encrypted messages, even ones you consider not to be particularly sensitive; reasons include
  • you don't want to develop cryptographically bad habits,
  • you don't want to help your adversary by in effect telling him which encrypted messages he should focus his efforts on.

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms. All Your Base R Belong to Us (cont'd)

Just a few simple does and don'ts can greatly improve the security of sensitive PF-related comms. Violating some of these simple rules not only might utterly compromise communication security, but is very likely to do so!

Let's start with a few simple don'ts; later we can discuss other examples of poor practices:

Do not repeat not:

• use a laptop, a desktop computer, a dumb terminal connected to a server or mainframe computer, or any computing device which you do not own--- at the worst extreme, some form of "cloud computing"--- to
  • perform your cryptographic processing
  • keep your GPG keyring
  • store sensitive messages in any form
• store your GPG keyring in an unencrypted area (use Truecrypt or some other cryptographic package which encrypts part or better all of your hard drive),
• transmit plaintext decrypts over an unencrypted channel (e.g. using ftp, telnet, a wireless channel) to another computer you control (or even worse, one you don't control),
• store plaintext decrypts in an unencrypted area,
• use a poorly secured computing device--- for example, smart phones and PDAs are almost impossible to secure--- to perform crypto processing, store your keyring, or store messages.

These commonsense rules apply to all encrypted messages, not just to ones you deem sensitive!

A fundamental maxim of cryptography is that an impressive cryptosystem provides something very dangerous--- a false sense of security--- if said cryptosystem is used in a manner which virtually guarantees compromise. Taking account of the likely threat environment, I believe that violations of the above rules are quite likely to utterly compromise PF-related encrypted comms. On the bright side, I believe that obeying them, while not ensuring communications security, will go a long way toward guarding against snooping.

 

[Chris Hillman]

BRS: PKI Cryptosystems for SA/Ms. All Your Base R Belong to Us (cont'd)

On second thought, let me be more flexible:

Regarding my proposal to experiment with an encrypted mailing list, in the SA forum, "Cryptography: Use It or Lose It?"

www.physicsforums.com/showthread.php?t=438623

the important thing is to get SA/Ms started using encryption. If some participant is unable or unwilling to follow a minimal standard of good practice (I think my preceeding post sets the bar about as low as we can go), as long as well all know that we can't actually discuss anything sensitive in the messages, I think the important thing is to get people started using GPG. I recognize that there could be legitimate reasons for being unable to follow minimal good procedure: e.g., not every SA/M owns a personal computer.

So if we want to just set up a "testing" mailing list, Windows users please note again that the column I cited in my Post #1 discusses a very easy and convenient way to use encryption routinely with your email. This involves a GUI which could very possibly introduce security holes, but again if one simply wants to get used to using cryptography routinely, true communications security is not a major issue. For Linux users, there are comparable GUIs such as kgpg.

But I still need to stress that if you get in the bad habit of storing plaintext decrypts in an insecure location, well, that's not a habit you want to get into. But what would be truly disastrous would be slipping into the habit of discussing truly sensitive material in an encrypted mailing list where you and possibly others on the list are not using minimal good practice!

 

[Chris Hillman]

BRS: Personal Cryptosystems for SA/Ms: What Would Einstein Have Said?

The idea of a modest mailing list as mentioned in the previous post has now been tested at PF using encrypted PMs, and it works.

In my Post #8 above, I mentioned the prevailing legal wisdom that

the presumption of privacy in internet communications appears to be both legally ill-established and under constant threat from many quarters.

To the surprise and gratification of privacy advocates, the U.S. 6th Circuit Court of Appeals has recently issued a landmark ruling holding that emails do enjoy much the same constitutional protections against warrantless search and seizure as snail mail. Which didn't stop the secret police from operating, for several decades, a highly illegal snail-mail-opening operation, as was revealed in the rush of post-Watergate disclosures. And the recent ruling probably won't do much to stop Google from reading your gmail (even your encrypted gmail, if you use their "encryption in the cloud" service.) So I don't think this ruling reduces in any way the urgency of getting everyone (or almost everyone) to use strong personal cryptography, just as everyone (or almost everyone) seals personal letters inside envelopes before tossing them in the mailbox.

In my Post #10 above, I mentioned the

NSA's official position during the 1990s, that strong personal/corporate crypotography was illegal.

This remains their position, according to a recent NY Times article which divulged the intention of the Obama administration to introduce yet another "key escrow" bill in the next Congress, a bill which may become known as Clipper IV. From the NY Times I get the impression that the draft, as dictated (allegedly) by secret police operatives, would cripple on-line banking, on-line payment systems, on-line credit card transactions, etc., and if so it will no doubt be staunchly opposed by (how ironic!) such irresistably powerful supercitizens as Bank of America and Microsoft. The concern of privacy advocates is that the draft presumbly represents a deliberately overly ambitious proposal, which NSA hopes will be "watered down" to something very close to the language they think they can actually push through the next Congress. For example, the final version of the bill might mandate hardware backdoors, which virtually guarantees cryptographic disaster which could bring down the economy (because Wall Street depends on cryptography for authentication and integrity [prevention of tampering] in e-trading).

As a followup to my warnings that strong cryptography is pointless if one ignores other vulnerabilities (generally non-cryptographic) which are all too easily introduced by misuse of an otherwise strong cryptosystem:

There is a recent and semi-reliable claim that c. 2000 an FBI task force attempted (one conspirator says they succeeded, another says that they failed) to place a back door in the OpenBSD crypto suite. For those who don't know, OpenBSD is a unix distribution (a distribution consists of the operating system proper plus core software) based on the Berkeley version of unix which was long popular in academic mathsci departments.

A compromise of the OpenBSD crypto suite might not directly affect crypto suites used in Linux distros. However, privacy advocates have not forgotten that the NSA has admitted that decades ago it seriously considered introducing a crippling cryptographic weakness into the cryptosystem which eventually became DES; such a weakness would constitute a backdoor. And privacy advocates remain suspicious of a rather mysterious incident in which an independent expert recently discovered that for many years, the routines used by Debian for SSL contained a subtle but devastating mathematical flaw (essentially, a miscoded pseudorandom number generator) which would have made cryptanalytic attacks by expert attackers possessing substantial computing resources on information "protected" by SSL rather feasible. This is precisely the kind of flaw one would expect the NSA to try to secretly introduce into open source projects. And don't forget that several popular open source tools are known to have originated as U.S. intelligence collection projects (exploiting subtle flaws in the tools which were not generally recognized for many years). Also, the notion of hardware backdoors is not merely a "scaremongering rumor"; AMD chips were recently shown to have a hardware backdoor, and other backdoors have been found in other critical hardware elements.

All these disclosures (rumors?) underline the point that compromise of a "strong" modern cryptosystem is probably less likely to arise from classical cryptanalysis than from non-cryptographic vulnerabilities exploiting TEMPEST, programming errors, hardware backdoors, and various user blunders, all of which can potentially enable an attacker to evade any cryptographic challenges.

Here are my answers to the trivia questions in Post #10:

• Bradley Manning has been imprisoned without charge, allegedly under horrific conditions (which the UN apparently considers to constitute torture), for some six months. His nominal (alleged) offense under the UCMJ code appears to be the allegation that he leaked to Wikileaks the now notorious videotape taken by the crew of a U.S. helicopter as they killed a Reuters team of photojournalists, apparently under the mistaken belief that they were insurgents. Manning's lawyers suggest the real reason for his mistreatment is that the secret police want to compel him to sign a statement implicating Julian Assange so that the U.S. can charge JA with espionage against the U.S. The cryptographic irony is that similar footage taken by U.S. drones in both Iraq and Afghanistan--- including footage depicting "collateral damage", i.e. deaths of innocent civilians, in gory detail--- was for many years transmitted unencrypted to ground stations which relayed the footage to controllers in Florida. The insurgents quickly learned how to use inexpensive consumer electronics to intercept this drone surveillance footage; in some cases, insurgents were apparently able to see in real time what the drone operators were seeing, and some pre-Manning videos depicting civilian deaths were apparently obtained by the insurgents this way and used to support their propaganda efforts.
• The NSA's interest in intercepting and reading all communications rests upon the assumption that they will possesses sufficient computing power to sort through the resulting torrent of data, hunting for keywords and so forth. This requires, among other things, huge data centers, each drawing as much power as a large American city. Thus, the surveillance state is a major (but secret) consumer of increasingly scarce and expensive electrical power in the USA. The surveillance state could not possibly be less "green", which makes Gore's former involvement in furthering its agenda appear ironic, given the fact that he is now best known for his efforts to curtail global warming.

Anyone who has been reading the headlines lately has probably noticed that a certain organization seems to have been somehow involved in many watershed events in the history of personal cryptography. I am speaking of course of the Church of Scientology. In several year-end reviews of the most important computer/net security news of 2010, pundits named the "hacktivism" of the group calling itself Anonymous as being particularly noteworthy. I myself decry "hacktivism" as extremely contrary to the goals of privacy and net security advocates--- it would be difficult to imagine an activity more counterproductive to the work of legitimate advocacy groups like EPIC and the ACLU than DDOS attacks on Mastercard, allegedly in "revenge" for Mastercard stopping individuals from donating to Wikileaks--- but my point here is that apparently reliable sources state that the "hacktivist" group Anonymous grew out of the anti-scientology "hacktivist" group known as Chanology.

Here is one more trivia question:

Every powerful thing (mathematical logic, general relativity, cryptography...) which is sufficiently difficult to acquire a whiff of the occult in popular culture seems to attract cranks. Thus, there are mathematical cranks, physics cranks, and crypotographic cranks. Some of the latter are discussed in David Kahn's classic survey, The Codebreakers (along with heroes of American cryptography such as W. F. Friedman, Solomon Kullback, and Claude Shannon, but not including more recent heroes such as Whitfield Diffie and Phil Zimmerman, since Kahn's book was published before the advent of public key cryptography--- the NSA, incidently, tried to prevent it from being published at all, but fortunately for us all, they failed).

And as we all know, one favorite ploy used by cranks is to cherry pick quotations from Einstein in order to "argue" that Einstein "would have supported" [sic] their fringe position.

Question: which of the cryptofringe figures discussed by Kahn authored one of the earliest expressions of the promise of strong personal cryptography? What is his connection with Albert Einstein? How can one--- by "quoting" not words but underlines in a book once owned by Einstein--- argue (perhaps) that Einstein appears to have favored the suggestion that strong personal cryptography should be available to everyone?