I'll let you know how this turns out. Wish me luck!

[laddiebuck]

Just interjecting

Well, let's consider what a large country might be able to do to brute-force any code, assuming they haven't found a special weakness. If the EFF can crack DES (56 bits) in two days, then a government should be able to brute-force 60 to 80 bit keys in a day, with budgets around ten million dollars (60 bits) to hundreds of billions of dollars (80 bits). If the information needs to remain secret for a year, that's another 8 bits. Kick in a few bits for safety (in case of a minor keyspace reduction break) and you need 90 bits, minimum, to be safe from a major government.

So the first step to a mental cryptosystem is finding a way to remember and work with a key at least 90 bits long.

I just felt I could interject for a moment here -- I'm very interested in the original question -- to note that 90 bits of ASCII is just over 11 letters, and memorising passwords of over 12 characters is not a problem for the typical computer user. Even considering that only 40 or so characters are used -- let's assume 5 bits of real information -- only 18 characters need to be memorised. So key length is not really a problem.

 

[CRGreathouse]

For me, at least, memorizing and manipulating an 18-character password of random letters and symbols (26 letters, 6 other symbols) would not be easy. It's hard enough for businesses to enforce strong 8 to 12 character passwords, which are still fairly far from random. This is twice that length and fully random. (If you're allowed to use less-than-random keys, you need to increase the length to ensure that the entropy stays high enough.)

 

[laddiebuck]

True, but given the original question's high goals, we may at least set the bar a little bit higher than for any ordinary problem. It's not /that/ difficult. You could easily invent a mnemonic for your password, a little ditty or rhyme, as long as you choose the password randomly first, and fit the ditty to it afterward.

When this question was asked on Slashdot, by the way, the most reasonable method proposed was RC4.
http://ask.slashdot.org/article.pl?sid=02/03/30/1927236
http://en.wikipedia.org/wiki/RC4

I'll work through some instances of RC4 and Tiny and post the results here later unless I forget. I don't think either has the property that they can't be broken based on the intermediate state, but as another poster pointed out, that may be impossible (without some "hardware", which may be no more than a paper abacus or pack of cards, of course). In any case, they are a start.

 

[NickAlger]

I have been thinking about this as well, and I think RC4 would be feasible given a few months of training. The key to performing the encryption at speed in your mind will be memorizing huge tables of precomputed operations.

 

[laddiebuck]

Hmm, promising! I plan to see how much effort I can save if I write out some key tables (mind I haven't thought much about the actual feasibility, so I'm just writing down my general ideas). Including the full algorithm and generic tables next to my ciphertext is no security risk, and no inconvenience.