Another weakness is that the keystream suggested is not evenly distributed: in a list of numbers like this, numbers are more likely to start with small digits.

Crptonomicon references a crypto scheme which uses a deck of cards (or, really, two matched decks of cards: one for encrypt, one for decrypt). The algorithm is in the back of the book, and on Wikipedia.

[Googles...]

It's the opening of The Valley of Fear.

And in response to the present and likely future comments on how this isn't really mathematically much better than ROT13... Honestly if you're using anything better than a Caesar cipher, your crypto is fairly likely to be the strongest link in the chain*. Think hard about whether your end is safe from black bag work, traffic analysis, etc, and whether your correspondents are scrupulous and trustworthy before you work any harder than something like this or a tableaux cipher, if it really has to be pen and paper. If you're corresponding in email anyhow, you might as well use GPG etc, but make sure you don't save the plaintext, you scrub everything, etc etc.

*Certain channels can expect technologically sophisticated attackers, but few of us ever need to think about how to secure those channels. The stuff we need to think about, usually the attacker will have more human savvy than tech savvy, and so checkbook, black bag, traffic analysis, and subornment are more likely modes of attack.

Let me suggest something much simpler and harder: two code words which you arrange with your ally. One word means "I'm in trouble"; the other word means "Don't trust anything from me until you see me in person." The words should be common enough that you can work them into a phone conversation or an email, but not so common that you will use them by accident. An uncommon synonym for a common thing is plausible.

Phone books, TV guides, and newspapers (depending how often one wants to change the source of the key) are handy and unremarkable sources of pseudo-random letters and numbers.

Basically you pick a key word or phrase, and write out rotated alphabets where A goes to each successive letter in the key. So for example if the key were MAKING LIGHT you'd have

MNOPQRSTUVWXYZABCDEFGHIJKL
ABCDEFGHIJKLMNOPQRSTUVWXYZ
KLMNOPQRSTUVWXYZABCDEFGHIJ
IJKLMNOPQRSTUVWXYZABCDEFGH

...and so on. Then to encipher, you go through your successive alphabets one by one. So the word FOOL, say, here would go to ROYT.

Whoops -- I see that Zeborah (#8) just pointed that out. I'll add that the advantage of what James described is that they key -- the sequence of letters or numbers you use to generate the substitution -- is intended to be long enough that it doesn't repeat before the message ends. If the sequence of numbers is genuinely random as well (unlike, say, a passage of text in a particular language), then you have a proper one-time pad, which is unbreakable. Unless you re-use it for later messages...

A slightly better approach might be for you and your friend to use some regularly updated, public source of pseudo-random numbers. E.g., the last digit of each price or trading-volume amount, taken from the most recent close-of-market summary in a particular newspaper or other widely available listing. Now you've got a (nearly) inexhaustible source of numbers. (Of course, this only works if no one knows that's where you're getting the random numbers from. But the same is true with using numbers from an almanac.)

But that would be a false complication, because the security is in the arithmetic, derived from the keytext. Even with a poor key source, such as described, it's difficult. It's going to need professional cryptanalysis.

And if you keep your messages short, it can be practically unbreakable.

You can combine the idea of a "don't trust me" code with any means of sending a message. You might pad out the beginning and end of the message with a couple of random words--it helps avoid easy-to-spot patterns--and that's where your warning code will go.

And if you're using a book of statistical information, agree to drop the first couple of digits of each number.

A nice example of steganography is given in Dorothy L. Sayers' novel The Nine Tailors (worth reading for other reasons). You can find the coded text by Googling for the opening words "I thought to see the fairies in the fields", but for the solution you may have to read the book. (I'd love to know how long it took Sayers to compose the text.) It has some nice twists: the decoding 'key' is a method of English change-ringing, which an opposition without knowledge of this rather arcane subject might miss (also, you don't have to memorise the key, only the method that generates it); and the result of decoding is itself cryptic, requiring further understanding to reveal the actual message.

I think there's a bit in a John LeCarre novel when a directive comes down to stop calling all their operations Operation $Whatever but just $Whatever.

I came up with a rather nice method of steganography that has the added advantage of being encodable in any format that will allow you to transmit ones and zeros. Fits on a 3x5 card, too.

Of course I'm not going to post it here. :)

The presence of a one-time pad is difficult to conceal and a functional admission of guilt.

I remember seeing an Edwardian-era spy drama on A&E once, in which the main character begins to suspect that the lady to whom he's been attracted is in fact the enemy agent he was sent to discover. So he searches her room and finds a bunch of papers covered in incomprehensible strings of letters and numbers, and, sick at heart, turns her in. I don't remember if he killed her himself or if other agents of his employer did so after she was in custody. Her code-sheets get taken back to headquarters to be deciphered, but the codebreakers are utterly stumped until a secretary gets a look at them and wonders why everyone's making such a big fuss over a bunch of knitting patterns...

Which of course raises the possibility of a code based on knitting/crochet/cross-stitch patterns. You could even have different keys based on, say, the first letter of the second word of the pattern's "name": if it's called "Chinese Lantern", use Transcription 4, but if it's called "Chinese Dragon", use Transcription 17, etc.

All you need for the system above is the source of pseudo random numbers, which is innocuous and easily replaceable, and your two five-digit keys, which you can memorise.

You can combine the idea of a "don't trust me" code with any means of sending a message. You might pad out the beginning and end of the message with a couple of random words--it helps avoid easy-to-spot patterns--and that's where your warning code will go.

Simply leave it out if you are transmitting under duress. And pray that your handlers are better at their jobs than the SOE handlers for the Dutch agents caught and forced to transmit by the Gestapo during Operation NORTH POLE; at least one captured agent, sending from Gestapo HQ, was horrified to receive a stern reminder from Broadway - "next time, do not forget to include your security check!"

Neal Stephenson, "The Confusion" - gros-point embroidery.

That's why you do your best to never use the same key twice.

Ha! Benford's Rule! Good catch. I think you could get round it, though, by omitting the first digit of every value in the list. Mathematicians - would that work?

Don't give a cryptanalyst a known plaintext by either:

* Extensively quoting something in current events that is also widely quoted in news sources, such as the text of the State of the Union (anything of more than around 900 characters will create enough text to analyze rather thoroughly using 1970s computing equipment and software). This kind of attack is behind how CSS was broken so quickly.

* Avoid unique terms wherever possible, and in particular avoid overrepetition of proper names that will be directly linked to either the sender or receiver. One of the best examples of this is Yardley's decryption of Japanese codes during the World War Interregnum by assuming that they would include extensive repetition of "Irish independence"... in a language that Yardley did not speak.

So if I were the eavesdropper, knew that my targets were using this type of scheme, and had access to a computer and some clerical staff, I'd probably want to have some files preloaded with the tables from common reference works, like the World Almanac. (And if my agents noticed some uncommon reference works in my target's houses, I might also get someone to copy from them, particularly if two targets had the same uncommon reference work.)

Then, if I intercepted a message, I could try running it against *all* the starting rows in my repertoire, and see which ones result in something looking like a checkerboard cipher. If I'm lucky, there are only a few that do; and I can then try seeing if any of them can be solved as a cryptogram.

If one can, I not only have the message, but I know what book they're using, where the two "control strings" are being put, and since I know the starting row, I also know what 5-digit keys they're using for this message. All of these
extra bits of information can make it a lot easier to decode the next intercepted message.

There's obviously a lot of prep work involved here, but once the files are prepared, a computer could potentially grind through the problem in seconds, without needing keys, and unlike rubber-hose or checkbook cryptanalysis, neither the sender nor the recipient would get an obvious indication that their code had been cracked.

One of the brilliant bits of Bruce Schneier's Solitaire Cipher (referenced above--it's the cipher in Cryptonomicon) is that the decryption pad is a deck of cards. Everyone has a deck of cards. You can key the deck to a Bridge column in a newspaper that both the sender and receiver reliably get, or (these days) to a Bridge website.

I've long thought that Usenet, esp. the binaries newsgroups, would be a great source of random data for one-time pads and a great hiding place for steganographic messages.

Any delivery system is susceptible to man-in-the-middle attacks. E-mail and snail mail* messages can be intercepted, copied, and allowed to continue (to prevent either end of the communication link from sending up the red flag via alternate methods), and then analyzed (via brute-force if necessary) at leisure.

Let me suggest something much simpler and harder: two code words which you arrange with your ally. One word means "I'm in trouble"; the other word means "Don't trust anything from me until you see me in person." The words should be common enough that you can work them into a phone conversation or an email, but not so common that you will use them by accident. An uncommon synonym for a common thing is plausible.

This kind of scheme is useful, and can be implemented in addition to other methods.

One useful tool for something like this is to incorporate a "Start word" - a word that allows you to use those other flag words in conversation - as long as they are not used after that word.

For example, let's take the following set -
"Absolutely" - START WORD.
"Supper" - In trouble. Send Lawyers, Guns, and Money.
"Dinner" - In trouble. Attempt No Rescue. Abandon.
"Bibliophile" - Person mentioned in this sentence is a traitor!
"Automobile" - Trust no communication from my cell until I speak with you directly.

Then the communication -

Sure, Abi, that's great. Look, we should get together sometime soon. Say, Dinner next week? I'll see if Daniel wants to come along - he's been dying to meet you - says he's a real bibliophile, and wants to talk to you about book-binding.

is totally innocuous, but

Absolutely, Abi, that's great. Look, we should get together sometime soon. Say, Dinner next week? I'll see if Daniel wants to come along - he's been dying to meet you - says he's a real bibliophile, and wants to talk to you about book-binding.

means that I'm compromised (and likely my cell is as well), the situation is precarious enough that I don't want even an attempt to rescue (time for a Burn Notice), and that I know my turncoat is Daniel - who should either be encysted, or killed.

*It should be assumed, at all times, that any and all broadcast based data transmission methods are compromised - this includes not just radio and cell phones, but also bluetooth (infra-red might be okay), and electronic devices in general (unless TEMPEST rated, or operated inside a Faraday cage). There are just too many snooping devices out there, and too many ways to capture signal.

Another useful source of pseudo random numbers would be the day's closing stock prices as printed in the Financial Times.

Or a Numbers Station! All you have to include in your key is which frequency to listen on and when to start listening. And those are probably much more robustly pseudo random than stock prices or almanac data.

It may have been. This type of scheme has been used in fiction quite a lot, AIR (Didn't they have a similar schema in The Moon is a Harsh Mistress?)

Such systems have to be kept pretty small - the whole "seven +/- two" deal, and should, of course, never be written down in "exploded" format - but this is true with all codes.

Code systems, other than very small ones like this, have mostly been supplanted by ciphers like the one James describes above, one-time pads, and computer-aided cryptography like PGP, because if you capture the codebook, you've cracked the whole system, while a cipher *should* (theoretically) be resistant to analysis unless samples of the plaintext are available, *even* if you know the encryption schema, as long as you don't have the keys used to encrypt and decrypt.

(Theoretically because not all encryption schemas are created equal, and some are more susceptible to brute-force analysis than others).

WEP is one very nice, public example of incompetently done crypto that is the weak point of real-world communications. I think the crappy cellphone encryption and truly embarrassing cordless phone "encryption" (aka frequency hopping with a short pseudorandom spreading sequence, for the best ones, as far as I can tell) are other examples of the crypto being the weak point. Similarly, NSA apparently imposed a 56-bit key on DES (IBM wanted a 128-bit key; left to their own devices, I think they'd have produced a cipher that was weaker with respect to academic attacks, but which would also have been secure in practice even today), and required dumbing down commercial crypto products for export to 40 bits for many years. Those both indicate places where the crypto is liable to be the weak link, because the cryptanalysis can be done efficiently and automated. (In particular, keysearch attacks as on DES and those 40-bit ciphers are very susceptible to doing a godawful precomputation, storing a lot of intermediate information, and then pretty quickly being able to break a given instance of the cipher.)

More to the point, you need to think about what resources your attacker has. If he's installed malware on your computer, all ciphers done on that computer are trivially breakable to him[1]. If not, you will do much better with a computer-mediated cipher than you can with any paper-and-pencil cipher, not least because even using some random shared information as a one-time pad and just doing mod 26 addition on it is a massive pain, and so you'll be tempted not to encrypt everything. (And you don't want to encrypt known stuff under a weak paper-and-pencil cipher!)

The flaw with Jim's comment here about cryptography buying you time is that once someone has spent the time to work out an effective break against the paper-and-pencil cipher you're using, they can code up their break or the tools needed for their break. Developing the attack requires a moderately bright person, but using the tools to break future things usually doesn't. (Sometimes, Bruce Schneier calls this phenomenon a "class break"--once the thing is attacked once, the attack spreads throughout the whole world very quickly.)

If you decide to use paper and pencil ciphers and books for running key material, you really, really want a book that's not online anywhere. That's kind-of hard to guarantee, but maybe you can manage it. But if there's any way you can get a trusted computer, you're going to to much better. You can leverage the trusted computer to do some really cool things. For example, there are visual one-time-pads and visual secret sharing schemes that are amazingly cool, and that can be used to communicate with computerless agents in the field using magazine or newspaper photos, faxes, etc., of completely innocuous things. See this Wikipedia article for more information.

I think paper-and-pencil schemes are really hard to use to secure communications, though one-time-pads will work if you can avoid messing up handling your key material. (Note that a one-time pad is unconditionally secure, and a two-time pad is unconditionally insecure.) It's probably a lot easier to use paper and pencil to authenticate a message, and that's often just as important.

[1] Modulo the assumption he can get information back out, or knows your crypto scheme well enough to target the malware at it specifically.

Terrorists' phone calls would most likely sound like, "Hey, Fred, are you coming to the party on Saturday? Maude is making potato salad!"

Where the Bug Every Phone program would be actually useful would be in making sure Halliburton is never underbid again, and in finding out what the Democratic National Committee is planning in the way of ad buys over the next couple of weeks.

I think the (rather old) state of the art is that you destroy (burn) the one-time pads as you use them, and that (modulo screwups) nobody on Earth but your sender and recipient have the one-time pads. An interesting question to ask is how you would know if your one time pads (or computer) had been tampered with--the police sometimes get warrants to silently come in and install keyloggers on computers, and criminals or spies obviously won't care a bit about warrants.

One known weakness for PGP and similar systems is the use of passwords to derive symmetric keys; for PGP, if I capture a copy of your keyring, plus guess your password, I have your private key. (And for encryption, as with encrypted disks and such, I just have to guess your password.) The countermeasures to this in practice involve making the mapping from a password to a key unique to an instance (so you have to guess the passwords for every distinct encrypted file, not once for all of them) and more expensive (by making you do a million iterations of some computation before you get the key out). But that's not a great solution, because doubling the amount of work the attacker does also doubles the amount of work the legitimate user does! To make dictionary attacks really hard, I probably want to set an iteration count so it takes me several seconds after I type the password in until the key is derived.

The underlying problem here is that people aren't very good at making up or remembering good passwords, especially if you know any of their other passwords, as a lot of people use a pattern: ("Xxxamazon123", "Xxxmyspace123", "Xxxgmail123", etc.) A lot of practical cryptanalysis of this kind is done by the police at various levels, and the FBI apparently has a large set of computers on which they do massive password searches (aka dictionary attacks). There are some private companies in this business, as well.

Graydon #15:

In any environment in which the presence of one-time-pads is incriminating, so is the presence of ciphertext coming from you, or worksheets on which you were computing your encryption (which are necessary for anyone not named Gauss or Libby for a lot of paper-and-pencil schemes).

On second thought, though, those numbers are very heavily skewed towards 1. A minor version of that skew is also present in the World Book's numbers, though, given any reasonable distribution, and this statistical skew can IIRC be useful in cracking the cipher. Perhaps it would be useful to, instead of copying out all of the numbers on the page, only use the ones that are second (third?) or later digits of numbers counting from the left, which will eliminate a lot of the bias.

Or one could use letters and convert them to numbers, thereby avoiding the need for obvious reference books. A high-school friend of mine could convert letters to numbers in the a=1, b=2, etc., sequence with sufficient ease to be fluent in reading and writing that way.

Sure, but ciphertext is potentially deniable, and potentially concealable in transmission. For a paper-and-pencil cipher, you really need a woodstove, because that's where all your worksheets go as soon as you have completed the ciphertext.

One time pads, by their nature, have to be stored.

Note that pretty much everywhere, encrypted anything is considered an admission of guilt in practise, no matter what the law says.

This is true for one-time pads, where each sheet is destroyed after use - but was not true for old-school codebooks, which were used for a period of time, then destroyed when replaced (on a regular schedule, normally). (OTPs were not developed until the 20th century).

This made these books highly valued, of course (and hard to distribute securely, and annoying in general - one reason why ciphers and OTPs are preferred today).

"Idiot" code systems are secure against casual or limited surveillance, but are susceptible to continued analysis - eventually the code breaks (if every time there's an attack on Lincolnshire, your messages contain reference to the North Field, eventually someone will figure out that North Field = Lincolnshire).

* If you're going for "count as 0", then when you hit, say, the Star and your plaintext letter is A, you just write down 1. If they take up space but you skip them, then if you'd land on the Star and the next card is 5 Pentacle (==5 Diamond), your encrypted value would be 19 because the Star punts to the next "real" card.

I think that's part of why the administration is so reluctant to have these programs subject to Fourth Amendment scrutiny. If you already have legitimate evidence that certain people might be up to something, you can get a warrant to tap their phones specifically. But it'd be much harder to get a judge under this country's constitution to sign off on monitoring *everyone's* calling patterns; hence the attempts to keep the judiciary out of the loop.

It even has a contest (still active).

C.H. Bennett, G. Brassard and S. Breidbart, "Quantum Cryptography II: How to reuse a one-time pad safely even if P=NP"

I may be a bit jaded - I knew (if somewhat peripherally) Mr. Schneier many years ago, when he was a member of URSGA...

(oh, btw, Bruce - Dan Quackenbush says Quack! - or maybe just Hi!)

I think you've pointed out the reason NOT to use the duress signal you suggest: It's much more common to forget to include your security word than it is to actually be captured, even for real spies.

Having a real duress signal makes it easy for your handlers to avoid the mistake you cite.

Excuse me. ML crypto threads are merely pseudo-random.

First use any appropriate polygraphic substitution (e.g. Playfair). This gives a set of letter pairs that can be reasonably easily analysed and turned back into their source message. So we need to break those pairs. For this, we need a grid in which some of the squares are empty and some are filled (e.g. a crossword grid[1]). Write the letters in horizontally. Fill with random letters. Read out vertically.

If you're feeling particularly energetic, repeat.

Decryption is the performed in the reverse order.

For best security, avoid long messages.

[1] You don't actually want to use a crossword grid, particularly not a published one. They're too regular and could be brute forced. One possibility is to take a crossword grid and alter it to make it less regular, e.g. by blacking out the spaces for a pre-selected set of questions.

Another possible use of that programm is to use the fact that terrorist phonecalls would most likely look the way you described to have officials explain at length why this or that case of Fred chatting with Maud about potatoe salad is really code for some evil terrorist plot, if, for this specific Fred and this specific Maud, that interpretation is politically desired.

I suppose one could have a face-to-face conversation while stark raving naked in a portable Schrödinger's catbox (kitty litter optional), but the use of such extraordinary methods to communicate could justify escalatingly intense levels of pervasive surveillance. You can't win.

By the way, Google indexes Making Light comments, citizen. Have a nice day!

Earl: A fact for which I am grateful, as there have been things I wanted to copy from here, and the traffic is high enough that even recalling what thread it was in gets pretty hard.

There are other ways of being secure; and the net has made it a lot easier to be steganographic, as well as for simple coms (plaintext ) which are much harder to spot.

Dead-drops, and other such tradecraft are still really useful.

Hi, Bruce!

Do you know what the best current result on Solitaire is? The best one I'm aware of is Paul Crowley's, but I haven't followed it too closely.

Graydon #37:

This is the reasoning behind (IMO very important) attempts to get crypto turned on by default as widely as possible. Ideally, it would be very unusual for a VoIP call to go out in the clear, cordless phone to base station encryption would be ubiquitous and strong, every hard drive would be encrypted, all e-mails would be encrypted, etc.

"Rubber hose cryptanalysis" just means beating (or intimidating) you until you hand over your key. It's a way to entirely do an end-run around the crypto being used.

Shortwave Morse is the classic.

Or the plaintext.

If I have access to the data from which the running key is drawn (say, I know the almanac), then this is pretty trivially breakable with a computer, or more tediously breakable with paper and pencil. Just slide along through the set of possible starting points of the running key against your ciphertext, and look for decryptions that match the expected character frequencies. (If you're doing it by hand, this will take awhile....)

If the running key is unknown but biased in a known way (I love the idea of using Benford's law here; you could also use common rounding rules.), then it will be breakable or not based on how close to uniform and independent the running key is. But note that XORing (or adding mod 26) long English texts together doesn't obscure them--it's generally possible to extract both texts back out. So the running key needs to, in some sense, be more random than normal text. (This also implies something about the idea of doing the Vignerre thing with a long running key from a book.) I don't recall how long the texts need to be to make this work.

You could use the first letter of each line, starting on a given page and line.

The problem with that is that you'd be required to make public -- as in, public utility, rather than "for profit corporation" -- pretty much all of the network backbone, and then fight a really tough, long term fight to keep someone from installing a back door.

The reason for not encrypting email or hard drives is that these are seen as critical systems, and adding cryptography tends to sharply increase the failure rate; it'd have to be added in hardware somewhere, and that presents a severe design challenge and another severe security challenge with respect to the back doors.

This is more or less impossible in the US given the current legal constructions of liability, too; corporates make the excellent argument that if they're liable for what you say with their email account, their agents must be able to read your email.

(I am, by the way, all for public-utility-izing the entire comms infrastructure.)

Nothing that makes sense is meaningfully random.

I suggest rolling dice.

If you need something that can be referenced by multiple parties, I'd suggest astronomical data; least significant digits of spectral results or something like that.

2) If you are using the "have lots of books of tables" method - for "protect me from my so-called friends or boss" level of security (or "doesn't matter tomorrow" security, which is more common) - READ THEM ALL REGULARLY, carelessly by preference. It doesn't matter how many books you have with lotsa-numbers, if only one is worn or stained, with the spine broken to make it easier to sit on a table, and it opens to a particular page, and the rest are pristine...

For some stuff, getting widespread encryption is hard, because you have to get everyone doing it at the same time. Getting decent encryption in cellphones requires getting the cellphone infrastructure switched over to decent encryption, though a cellphone manufacturer could set things up so that calls from, say, Nokia to Nokia phones did an additional key agreement and encrypted their data end to end. (But cellphone providers and manufacturers are easy to subject to government presure not to strengthen their encryption.) Getting widespread e-mail encryption in use is a pain, because you can't encrypt to me until you're sure I know how to decrypt it. But people could do it, and mostly don't. (But maybe more police state measures all over the place will have an impact on this.)

Other stuff doesn't require any negotiation, or only requires very limited negotiation. Encrypting your own hard drive or files is relatively easy to do, and a bunch of companies (and the feds, too) are establishing policies requiring laptop hard drive encryption, because it's very common for laptops to be lost or stolen. Windows and MacOS have built-in support for this, and there are nice programs that will do it for you, too. Cordless phones (which I think courts have held have no reasonable expectation of privacy) could be made secure pretty trivially by moving them to WPA2 and having the phones and base stations establish shared keys when they are put on the handset to recharge; that would get rid of a huge privacy leak that's waiting for people to exploit it.

Ideally, every website would support https (TLS, encryption for TCP) requests for everything. That would require no great negotiation with anyone, and it would make a whole bunch of data flowing over the internet simply go opaque. As it is, a lot of sites don't support it even when it's crazy not to. Earthlink's webmail doesn't support https for anything but the login screen.

My take on this is that the main problem is that adding casual, automatic encryption impacts performance, complicates design (because key management is usually a big pain to get right), and has very little obvious benefit, at least until it's being done everywhere.

I haven't been running any kind of high-volume webserver recently, but as I recall, if you don't have cryptographic hardware installed in the server - and 99% of webservers don't - using SSL takes a non-trivial chunk of the CPU per session. That means fewer connections you can support on a given machine, which for very busy sites means either adding more servers - maybe two or three times as many - or else adding funky add-on cards to them. The latter is also a big pain for ISPs or hosting companies which want to deal with lots of precisely identical hardware. Given Gmail's scale, I suspect it took a pretty substantial investment for them to announce the checkbox feature where everyone can easily turn on and require https.

I'm not saying it's bad - on the contrary, SSL is Good! - but there's a cost there which is hidden from the end-user's perspective. That's one reason we don't see it everywhere all the time.

There was an episode of ST:TNG that included a similar idea ("Darmok and Jalad at Tanagra"). See also classic Chinese poetry.

(Come to think of it, bad fanfiction would be a great place to hide all kinds of things. The Sturgeon's Law Cipher!)

One million years from now when humans are the new Vorlons:

Human (in an encounter suit): Ok, so, here's what you need to know. There will be a big battle. You will need to pick sides. We're the good guys, so we'll tell you everything you want to know. Go on, ask me anything.

New younger race: Darmok and Jalad at Tinagra?

But that's one more book to find for the pile, so thank you.

Assume there are 500 pages in your book, and each page contains 100 lines of numbers. That's 50,000 possible keys to try.

For each key, decode 10 letters of the ciphertext. Compare those 10 letters to a table of English letter frequencies. Do you get "zqadtv.mlp"? It's not English text. Try the next line. At a billion instructions per second, this won't take long. English text is incredibly distinctive, so your computer will have no problem recognizing it.

If you're impatient, sort the lines of numbers, and store them in a trie. Decode the first character of the ciphertext using the digits from 1 to 10. Pick whichever digit decodes the first letter to "E", and walk down that branch of the trie recursively. If that results in nonsense, try the other branches in order of letter frequency: "EATOIN SHRDLU".

With a reasonably large database, you will be able to decrypt the message as fast as you can type it into your computer.

What if you don't have an electronic copy of the table of numbers? First, see if you can find out what book is in use. (This is left as an exercise for the reader.) If that fails, just pick the 200 best-selling books of numbers, and run them through an OCR system like that of Google books. You'll have a ton of OCR errors, but that's OK--you can adapt the algorithm to work with error-filled tables; it will just take longer to run.

If you want a reasonably strong pencil-and-paper cipher, follow Bruce Schneier's Solitaire link upthread.

I haven't been running any kind of high-volume webserver recently, but as I recall, if you don't have cryptographic hardware installed in the server - and 99% of webservers don't - using SSL takes a non-trivial chunk of the CPU per session.

It's not so much of a problem these days. Sure, it would add overhead, but most web server applications are IO bound, so doing something that uses CPU wouldn't be too much of an issue.

No, the *really big* problem is that SSL only allows you to have one domain per IP address, whereas 99.something% of web sites share their IP address with one or (more usually) 50 others.

We have a real shortage of IP addresses, and if every web site suddenly decided to do SSL, we'd run out pretty quickly.

It seems to me that the best solution to this is to extend SSL to let you list multiple sites in the certificate, but I haven't looked into it closely.

(Given that I'm trying to run four-ish Web apps off a sad little hosted VM with 128MB of RAM that's running near capacity, I won't be enabling SSL on all my sites any time soon, because the overhead would kill it; there's only one that really needs it. I do send grumpy e-mails to web sites I run across which really should use SSL and don't, like the VoIP provider I was looking at a few days ago, and I encourage others to do the same. :-)

I'm sorry, I have yielded to temptation.

I know what rubberhose cryptanalysis is. When I wrote that comment, the OP referenced "rubberhose cryptography." It appears Jim's fixed that, or perhaps I was hallucinating in the first place (maybe Jim will tell us which?) Please do re-read my comment in light of that, so that I look like a smartass with a little bit of clever instead of confused and nonsensical.

Also, my original point there was really that using nontrivial pen and paper crypto probably makes your ciphertext a harder point of attack for the sorts of people likely to be trying to attack it than any other link in the chain. In my life, the sorts of folks I'd be concerned about (if I had concerns, which right now I don't) are like business rivals, potentially local police, the odd reporter, neighborhood kids, personal rivals, that sort of thing. Some of those people (cops and reporters for sure) are very good at social engineering and may have considerable resources at their command for attacks on human links, but none of them tend to have cryptanalytic resources.

Your advice about class breaks is extremely relevant, however. This sort of cryptography is very useful when you have a day or even a week of messages to pass, but if it remains in use... It may take local cops six months to get the FBI to send your stuff to the NSA and have it decrypted, but once they've done that, assume that they can decrypt any further messages as fast as they need to. Further, cut that lead time in half for any country without the US's peculiar law-enforcement/intelligence rivalry, and reduce further as appropriate to the organization/country.

It's also not as subject to the sort of brute force described by Eric K., (though most of the values are the same, some of the ordering is different) you can choose a column, instead of a row... or checkerboard the selection criteria (even build a version of the Vingiere cipher to manufacture the key).

And they are both inexpensive, and easy to come by.

I dunno, these days I've gotten sensitive or something.

hmmm... perhaps not, but it's also not a book that would go amiss on most shelves, especially given the miscellany many of us seem to accumulate - I've got a copy (22nd edition) that I picked up cheap in a "going out of business, moving someplace warm" bookstore sale recently - it's currently sitting on my shelves next to Kipling, Paine, the Poetic Eddas, Lies My Teacher Told Me, and some SimCity manuals (otherwise known as Nonfiction: unsorted...).

(and I live in an apartment, so it's not like there's a workshop downstairs for it to go with).

(Note that with traffic analysis, and some B&E work, it might become obvious if everyone you communicated with via e-mail had a copy of the 25th edition of the Machinists Handbook somewhere in their library).

As far as I know I am the only physician bluegrass fiction writer on wordpress.

Maybe I picked the wrong genre.

Dr. Tom Bibey

drtombibey.wordpress.com

If you want to stop teacher or mom reading a diary, it doesn't need to be this complicated. The simple Julius Caesar cipher (ROT-13 is an example) is too simple, but you don't need anything much more complicated. It's the sort of thing you can learn to do in your head as you write, even if you use a keyword to jumble the alphabet.

It stops people just picking up your diary and reading it.

The method described is good enough to protect a message for a few days, even against government-level attack. Especially if the messages are short. But if you're up against a government, there are all sorts of ways they can mess things up for you. Lose the letter in the mail for a few days, and your escape plans are FUBARed.

If you're entangled with heavy-duty Spooksville, you almost need to play by what some have called "Moscow Rules". And anything like that can be a giveaway.

That sort of situation needs somebody on the outside. It is very unusual for a wholly internal resistance to survive against a Police State.

But it's a way cool book for other things, and anyone who has a shelf of useful information ought to get one. Unless one is doing CNC machining, with with a powered mill, there's no need to get anything more recent than the '50s, and it's not that strange a thing. The articles on acme threading are interesting all by themselvses, as are the disquisitions on the various uses of allow steels.

But I digress.

If we didn't digress, this wouldn't be the Making Light we know and love.

Phone book?

I haven't had a phone book in my home since I first got wifi, lo these many years ago. To be fair, that may be an artifact of living in large cities (=ginormous phone books + high-rent-induced small apartments).

Yes, there are other reasons why people are being tortured in my name, mostly because it makes some people look effective and all butch and electable and such, but maybe torture consciousness is encouraged by the presence of one situation in which it 's easy to think that it would be all you've got---it knocks the dust off that tool, making it stand out just a little bit more....

We expect spies, and terrorists and crooks (more or less) to do things to hide their activities. The amazing thing is how rarely they use strong encryption (or good tradecraft).

Yeah, any commercial encryption, even the lame ones that often come with word processors and such, will keep your prying mom out of your files. That should be done on a computer unless you're worried about keyloggers or some such thing.

Terry #99:

That's the sense I have, too. Some criminals manage to use good crypto, but most of them apparently use crappy crypto. I suspect part of this is that they don't know the difference between good and bad crypto, but laziness and the fact that it hasn't bit them before probably also come into play.

One of the really hard things about trying to make casual eavesdropping/spying harder is that if you produce a strong encryption product or strong anonymizing service, some notable subset of the folks who want to use it will be obvious bad people. Child pornographers need anonymity more than random citizens commenting on weblogs under a pseudonym.

I suspect that there's a kind of J-shaped curve describing well being of the society as strong cryptography becomes widespread--the early adopters are some combination of cryptographers and privacy fanatics and bad guys, and total social well being likely goes down. Then, further adoption makes total social well being go back up, and eventually it ends up better. (Shorter me: We're best off when everyone has privacy, not too bad off when nobody has privacy, and in the worst state when only the bad guys have privacy.)

The obvious one here is replay attack, and more broadly, reordering/delaying messages. If I note that you're sending messages that set up meetings, I can delay one till I figure out where the meeting is supposed to be, then send it to your recipient and be waiting for him. Or I may be able to cause him to return to the same place twice.

Depending on the cipher, you can sometimes splice together information or alter information in the ciphertext without knowing the plaintext, or without knowing all the plaintext, or without knowing the key. For example, in Jim's cipher above, suppose you know that the first word in the ciphertext is "Don't," and want to change it to "Won't." D is encoded as 15, W is encoded as 27, so if you add (without carries) a 1 to the first number in the ciphertext, and a 2 to the second number, you change the ciphertext from "DONT LET THEM SCARE YOU" to "WONT LET THEM SCARE YOU". (That's a pretty standard thing to do to this kind of cipher.)

I suspect you can use this, in practice, to test guesses about the plaintext. In a real-world system, there will be encryption errors. If you cause a rare garbled message, it may not be detected as an attack. So, if you think you know what a given word at some place in the text should be, alter it into a similar word using this technique, and then observe the reaction of the receiver.

It's also obviously easy to "jam" the transmissions by blocking transmission of anything that looks like ciphertext. More interestingly, it's easy to wait till you think they've got something interesting to send, and then silently block the ciphertext. (99% effective way to prevent the use of encrypting telephones in practice: Introduce enough line noise to mess up the call whenever you detect ciphertext. Eventually, the users will give up and just use normal unencrypted voice, if they are given a choice.)

This particular one is a little cooler than Caesar: you need two words that total 13 letters with no repetition. e.g.

DOLPHINSAFETY
then write the remaining letters in order
BCGJKMQRUVWXZ

and encode straight up and down.

wurz! Cqgz xec ecsb xc seougg.

Useless for anything serious ... although short messages - like passwords for something stronger ... are hard to break.

Software for Palm, phone, or Nokia tablet platforms may also make it harder to install a hardware keylogger. These probably also protect you against the bit where they can tell what you're typing from the sounds.

Unfortunately, hardware write-lock USB keys are harder to find these days.

But one big key, which I'm glad to see others mention here, is "how long?" and "against whom?" Unfortunately, if "how long?" > a week, the law is getting to the point where strong cryptography is no longer useful, because they'll just put you in jail/force decryption through discovery requests anyway. Strong Crypto == good for anything involving money, because "against whom?" is "about 10 000 people who are getting paid to get banking information from people like ME."